Visão geral da continuidade de negócios e recuperação de desastres

A continuidade de negócios e a recuperação de desastres no Azure Data Explorer permitem que sua empresa continue operando em caso de interrupção. Este artigo discute a disponibilidade (intrarregião) e a recuperação de desastres. Ele detalha recursos nativos e considerações de arquitetura para uma implantação resiliente do Azure Data Explorer. Ele detalha a recuperação de erros humanos, alta disponibilidade, seguida por várias configurações de recuperação de desastres. Essas configurações dependem de requisitos de resiliência, como RPO (Recovery Point Objetive, objetivo de ponto de recuperação) e RTO (Recovery Time Objetive, objetivo de tempo de recuperação), esforço necessário e custo.

Mitigar eventos disruptivos

• Erro humano
• Alta disponibilidade do Azure Data Explorer
• Interrupção de uma zona de disponibilidade do Azure
• Interrupção de um datacenter do Azure
• Interrupção de uma região do Azure

Erro humano

Os erros humanos são inevitáveis. Os usuários podem soltar acidentalmente um cluster, banco de dados ou uma tabela.

Exclusão acidental de cluster ou banco de dados

A exclusão acidental de cluster ou banco de dados é uma ação irrecuperável. Como proprietário do recurso do Azure Data Explorer, você pode evitar a perda de dados habilitando o recurso de bloqueio de exclusão, disponível no nível de recurso do Azure.

Exclusão acidental de tabela

Os usuários com permissões de administrador de tabela ou superiores podem descartar tabelas. Se um desses usuários soltar acidentalmente uma tabela, você poderá recuperá-la usando o .undo drop table comando. Para que esse comando seja bem-sucedido, você deve primeiro habilitar a propriedade de recuperabilidade na política de retenção.

Exclusão acidental de tabela externa

As tabelas externas são entidades de esquema de consulta Kusto que fazem referência a dados armazenados fora do banco de dados. A exclusão de uma tabela externa exclui apenas os metadados da tabela. Você pode recuperá-lo executando novamente o comando de criação de tabela. Use o recurso de exclusão suave para proteger contra exclusão acidental ou substituição de um arquivo/blob por um período de tempo configurado pelo usuário.

Alta disponibilidade do Azure Data Explorer

Alta disponibilidade refere-se à tolerância a falhas do Azure Data Explorer, seus componentes e dependências subjacentes dentro de uma região do Azure. Esta tolerância a falhas evita pontos únicos de falha (SPOF) na implementação. No Azure Data Explorer, a alta disponibilidade inclui a camada de persistência, a camada de computação e uma configuração líder-seguidor.

Camada de persistência

O Azure Data Explorer usa o Armazenamento do Azure como sua camada de persistência durável. O Armazenamento do Azure fornece automaticamente tolerância a falhas, com a configuração padrão oferecendo Armazenamento Localmente Redundante (LRS) em um data center. Três réplicas são persistentes. Se uma réplica for perdida durante o uso, outra será implantada sem interrupção. É possível aumentar a resiliência com o Armazenamento com Redundância de Zona (ZRS), que coloca réplicas de forma inteligente nas zonas de disponibilidade regional do Azure para máxima tolerância a falhas a um custo extra. O armazenamento habilitado para ZRS é configurado automaticamente quando o cluster do Azure Data Explorer é implantado em zonas de disponibilidade.

Camada de computação

O Azure Data Explorer é uma plataforma de computação distribuída e pode ter de dois a muitos nós, dependendo da escala e do tipo de função do nó. No momento do provisionamento, selecione zonas de disponibilidade para distribuir a implantação do nó entre zonas para máxima resiliência dentro da região. Uma falha na zona de disponibilidade não resulta em uma interrupção completa, mas sim na degradação do desempenho até a recuperação da zona.

Configuração do cluster líder-seguidor

O Azure Data Explorer fornece um recurso de seguidor opcional para um cluster de líder a ser seguido por outros clusters de seguidores para acesso somente leitura aos dados e metadados do líder. As alterações no líder, como create, appende drop são automaticamente sincronizadas com o seguidor. Embora os líderes possam abranger regiões do Azure, os clusters de seguidores devem ser hospedados nas mesmas regiões que o líder. Se o cluster de líderes estiver inativo ou os bancos de dados ou tabelas forem descartados acidentalmente, os clusters de seguidores perderão o acesso até que o acesso seja recuperado no líder.

Interrupção de uma zona de disponibilidade do Azure

As zonas de disponibilidade do Azure são locais físicos exclusivos dentro da mesma região do Azure. Eles podem proteger a computação e os dados de um cluster do Azure Data Explorer contra falha parcial de região. A falha de zona é um cenário de disponibilidade, pois é intrarregião.

Fixe um cluster do Azure Data Explorer na mesma zona que outros recursos conectados do Azure. Para obter mais informações sobre como habilitar zonas de disponibilidade, consulte Criar um cluster.

Interrupção de um datacenter do Azure

As zonas de disponibilidade do Azure têm um custo e alguns clientes optam por implantar sem redundância zonal. Com essa implantação do Azure Data Explorer, uma interrupção do datacenter do Azure resulta em interrupção de cluster. A manipulação de uma interrupção do datacenter do Azure é, portanto, idêntica à de uma interrupção da região do Azure.

Interrupção de uma região do Azure

O Azure Data Explorer não fornece proteção automática contra a interrupção de uma região inteira do Azure. Para minimizar o impacto nos negócios se houver essa interrupção, vários clusters do Azure Data Explorer em regiões emparelhadas do Azure. Com base em seu RTO (Recovery Time Objetive, objetivo de tempo de recuperação), RPO (Recovery Point Objetive, objetivo de ponto de recuperação), bem como considerações de esforço e custo, há várias configurações de recuperação de desastres. As otimizações de custo e desempenho são possíveis com as recomendações do Azure Advisor e a configuração de dimensionamento automático .

Configurações de recuperação de desastres

Esta seção detalha várias configurações de recuperação de desastres, dependendo dos requisitos de resiliência (RPO e RTO), do esforço necessário e do custo.

O RTO (Recovery Time Objetive, objetivo de tempo de recuperação) refere-se ao tempo de recuperação de uma interrupção. Por exemplo, RTO de 2 horas significa que o aplicativo tem que estar pronto e funcionando dentro de duas horas após uma interrupção. O RPO (Recovery Point Objetive, objetivo de ponto de recuperação) refere-se ao intervalo de tempo que pode passar durante uma interrupção antes que a quantidade de dados perdidos durante esse período seja maior do que o limite permitido. Por exemplo, se o RPO for de 24 horas e um aplicativo tiver dados de 15 anos atrás, eles ainda estarão dentro dos parâmetros do RPO acordado.

Os processos de ingestão, processamento e curadoria precisam de um design diligente inicial ao planejar a recuperação de desastres. Ingestão refere-se a dados integrados no Azure Data Explorer de várias fontes; o tratamento refere-se a transformações e atividades similares; A curadoria refere-se a visualizações materializadas, exportações para o data lake e assim por diante.

A seguir estão as configurações populares de recuperação de desastres:

• Configuração deActive-Active ativa (sempre ativa)
• ConfiguraçãoActive-Active
• Active-Hot configuração em standby
• Configuração de cluster de recuperação de dados sob demanda

Configuração ativo-ativo-ativo

Essa configuração também é chamada de always-on. Para implantações de aplicativos críticos sem tolerância a interrupções, você deve usar vários clusters do Azure Data Explorer em regiões emparelhadas do Azure. Configure a ingestão, o processamento e a curadoria em paralelo a todos os clusters. A SKU do cluster deve ser a mesma entre as regiões. O Azure garante que as atualizações sejam implementadas e escalonadas nas regiões emparelhadas do Azure. Uma interrupção de região do Azure não causa uma interrupção de aplicativo. Você pode enfrentar alguma latência ou degradação de desempenho.

Active-Active configuração

Essa configuração é idêntica à configuração ativo-ativo-ativo, mas envolve apenas duas regiões emparelhadas do Azure. Configure a ingestão, o processamento e a curadoria duplos. Os usuários são encaminhados para a região mais próxima. A SKU do cluster deve ser a mesma entre as regiões.

Active-Hot configuração em standby

A configuração Active-Hot é semelhante à configuraçãoActive-Active em dupla ingestão, processamento e curadoria. Embora o cluster em espera esteja online para ingestão, processo e curadoria, ele não está disponível para consulta. O cluster em espera não precisa estar na mesma SKU que o cluster primário. Pode ser de um SKU e escala menores, o que pode resultar em um desempenho menor. Em um cenário de desastre, os usuários são redirecionados para o cluster em espera, que opcionalmente pode ser dimensionado para aumentar o desempenho.

Configuração de recuperação de dados sob demanda

Esta solução oferece a menor resiliência (maior RPO e RTO), é a mais baixa em custo e a mais alta em esforço. Nessa configuração, não há cluster de recuperação de dados. Configure a exportação contínua de dados selecionados (a menos que dados brutos e intermediários também sejam necessários) para uma conta de armazenamento configurada GRS (Geo Redundant Storage). Um cluster de recuperação de dados é girado se houver um cenário de recuperação de desastres. Nesse momento, DDLs, configuração, políticas e processos são aplicados. Os dados são ingeridos do armazenamento com a propriedade de ingestão kustoCreationTime para substituir o tempo de ingestão padrão para o tempo do sistema.

Resumo das opções de configuração de recuperação de desastres

Melhores práticas

Independentemente da configuração de recuperação de desastres escolhida, siga estas práticas recomendadas:

• Todos os objetos, políticas e configurações de banco de dados devem ser mantidos no controle do código-fonte para que possam ser liberados para o cluster a partir da sua ferramenta de automação de versão. Para obter mais informações, consulte Suporte do Azure DevOps para o Azure Data Explorer.
• Projete, desenvolva e implemente rotinas de validação para garantir que todos os clusters estejam sincronizados de uma perspetiva de dados. O Azure Data Explorer dá suporte a junções entre clusters. Uma simples contagem ou linhas entre tabelas pode ajudar a validar.
• Os procedimentos de liberação devem envolver verificações e equilíbrios de governança que garantam o espelhamento dos clusters.
• Esteja plenamente ciente do que é necessário para construir um cluster a partir do zero.
• Crie uma lista de verificação de unidades de implantação. Sua lista é exclusiva para suas necessidades, mas deve incluir: scripts de implantação, conexões de ingestão, ferramentas de BI e outras configurações importantes.

Próximo passo