Criar soluções de continuidade de negócios e recuperação de desastre com Azure Data Explorer
Este artigo detalha como você pode se preparar para uma paralisação regional do Azure replicando seus recursos de Azure Data Explorer, gerenciamento e ingestão em diferentes regiões do Azure. É fornecido um exemplo de ingestão de dados com os Hubs de Eventos do Azure. A otimização de custo também é discutida para diferentes configurações de arquitetura. Para obter uma visão mais detalhada das considerações de arquitetura e das soluções de recuperação, confira a visão geral da continuidade dos negócios.
Preparar-se para a paralisação regional do Azure para proteger seus dados
O Azure Data Explorer dá suporte à proteção automática contra a paralisação de toda a região do Azure. Essa interrupção pode ocorrer durante um desastre natural, como um terremoto. Se você precisar de uma solução para uma situação de recuperação de desastre, faça as etapas a seguir para garantir a continuidade dos negócios. Nessas etapas, você replicará seus clusters, gerenciamento e ingestão de dados em duas regiões emparelhadas do Azure.
- Crie dois ou mais clusters independentes em duas regiões emparelhadas do Azure.
- Replique todas as atividades de gerenciamento como criar novas tabelas ou gerenciar funções de usuário em cada cluster.
- Ingerir dados em cada cluster em paralelo.
Criar vários clusters independentes
Crie mais de um cluster do Azure Data Explorer em mais de uma região. Certifique-se de que pelo menos dois desses clusters sejam criados em regiões emparelhadas do Azure.
A imagem a seguir mostra réplicas, três clusters em três regiões diferentes.
Replicar atividades de gerenciamento
Replique as atividades de gerenciamento para ter a mesma configuração de cluster em cada réplica.
Crie em cada réplica os mesmos:
- Bancos de dados: você pode usar o portal do Azure ou um de nossos SDKs para criar um novo banco de dados.
- Tabelas
- Mapeamentos
- Políticas
Gerenciar autenticação e autorização em cada réplica.
Solução de recuperação de desastre usando a ingestão do hub de eventos
Depois de concluir Preparar-se para a paralisação regional do Azure para proteger seus dados, seus dados e gerenciamento serão distribuídos para várias regiões. Se houver uma paralisação em uma região, Azure Data Explorer poderá usar as outras réplicas.
Configurar a ingestão usando um Hub de Eventos
Para ingerir dados dos Hubs de Eventos do Azure no cluster do Azure Data Explorer de cada região, primeiro replique a configuração dos Hubs de Eventos do Azure em cada uma dessas regiões. Em seguida, configure a réplica do Azure Data Explorer de cada região para ingerir dados dos Hubs de Eventos dessa réplica.
Observação
A ingestão por meio dos Hubs de Eventos/Hub IoT/Armazenamento do Azure é robusta. Se um cluster não estiver disponível por um período de tempo, ele será atualizado posteriormente e inserirá mensagens ou blobs pendentes. Esse processo depende do ponto de verificação.
Conforme mostrado no diagrama abaixo, suas fontes de dados produzem eventos para os hubs de eventos em todas as regiões, e cada réplica do Azure Data Explorer consome os eventos. Componentes de visualização de dados, como Power BI, Grafana ou WebApps do SDK, podem consultar uma das réplicas.
Otimizar custos
Agora você está pronto para otimizar suas réplicas usando alguns dos seguintes métodos:
- Criar uma configuração de recuperação de dados sob demanda
- Iniciar e parar as réplicas
- Implementar um serviço de aplicativo altamente disponível
- Otimizar o custo em uma configuração ativa-ativa
Criar uma configuração de recuperação de dados sob demanda
Replicar e atualizar o Azure Data Explorer configuração aumentará linearmente o custo com o número de réplicas. Para otimizar o custo, você pode implementar uma variante de arquitetura para equilibrar o tempo, o failover e o custo. Em uma configuração de recuperação de dados sob demanda, a otimização de custo foi implementada introduzindo réplicas passivas do Azure Data Explorer. Essas réplicas só serão ativas se houver um desastre na região primária (por exemplo, região A). As réplicas nas Regiões B e C não precisam estar ativas 24 horas por dia, 7 dias por semana, reduzindo significativamente o custo. No entanto, na maioria dos casos, o desempenho dessas réplicas não será tão bom quanto o cluster primário. Para obter mais informações, confira Configuração de recuperação de dados sob demanda.
Na imagem abaixo, apenas um cluster está ingerindo dados do hub de eventos. O cluster primário na Região A executa a exportação contínua de dados de todos os dados para uma conta de armazenamento. As réplicas secundárias têm acesso aos dados usando tabelas externas.
Iniciar e parar as réplicas
Você pode iniciar e parar as réplicas secundárias usando um dos seguintes métodos:
Conector do Azure Data Explorer para Power Automate (versão prévia)
O botão Parar na guia Visão geral no portal do Azure. Para obter mais informações, consulte Parar e reiniciar o cluster.
CLI do Azure:
az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>"
Implementar um serviço de aplicativo altamente disponível
Criar o cliente BCDR do Serviço de Aplicativo do Azure
Esta seção mostra como criar um Serviço de Aplicativo do Azure que dá suporte a uma conexão com um único cluster primário e vários Azure Data Explorer secundários. A imagem a seguir ilustra a Serviço de Aplicativo do Azure configuração.
Dica
Ter várias conexões entre réplicas no mesmo serviço oferece maior disponibilidade. Essa configuração não é útil apenas em instâncias de paralisações regionais.
Use esse código clichê para um serviço de aplicativo. Para implementar um cliente de vários clusters, a classe AdxBcdrClient foi criada. Cada consulta executada usando esse cliente será enviada primeiro para o cluster primário. Se houver uma falha, a consulta será enviada para réplicas secundárias.
Use métricas personalizadas do Application Insights para medir o desempenho e solicitar a distribuição para clusters primários e secundários.
Testar o cliente BCDR do Serviço de Aplicativo do Azure
Fizemos um teste usando várias réplicas do Azure Data Explorer. Após uma paralisação simulada de clusters primários e secundários, você pode ver que o cliente BCDR do serviço de aplicativo está se comportando conforme o esperado.
Os clusters Azure Data Explorer são distribuídos pelo Oeste da Europa (primária 2xD14v2), Sudeste da Ásia e Leste dos EUA (2xD11v2).
Observação
Tempos de resposta mais lentos ocorrem devido a diferentes SKUs e consultas entre planeta.
Executar roteamento dinâmico ou estático
Use os métodos de roteamento do Gerenciador de Tráfego do Azure para roteamento dinâmico ou estático das solicitações. O Gerenciador de Tráfego do Azure é um balanceador de carga de tráfego baseado em DNS que permite distribuir o tráfego de serviço de aplicativo. Esse tráfego é otimizado para serviços em regiões globais do Azure, enquanto fornece alta disponibilidade e capacidade de resposta.
Você também pode usar o Azure Front Door com base em roteamento. Para comparação desses dois métodos, consulte Balanceamento de carga com o pacote de entrega de aplicativos do Azure.
Otimizar o custo em uma configuração ativa-ativa
O uso de uma configuração ativa-ativa para recuperação de desastre aumenta o custo linearmente. O custo inclui nós, armazenamento, marcação e maior custo de rede para largura de banda.
Usar o dimensionamento automático otimizado para diminuir os custos
Use o recurso de dimensionamento automático otimizado para configurar o dimensionamento horizontal para os clusters secundários. Eles devem ser dimensionados para que possam lidar com a carga de ingestão. Depois que o cluster primário não puder ser acessado, os clusters secundários obterão mais tráfego e escala de acordo com a configuração.
O uso do dimensionar automático otimizado neste exemplo economizou aproximadamente 50% do custo em comparação a uma escala horizontal e vertical igual em todas as réplicas.