Criar soluções de continuidade de negócio e recuperação após desastre com o Azure Data Explorer
Este artigo detalha como se pode preparar para uma indisponibilidade regional do Azure ao replicar os recursos, a gestão e a ingestão do Azure Data Explorer em diferentes regiões do Azure. É dado um exemplo de ingestão de dados com Hubs de Eventos do Azure. A otimização de custos também é abordada para diferentes configurações de arquitetura. Para ver mais detalhadamente as considerações de arquitetura e as soluções de recuperação, veja a descrição geral da continuidade do negócio.
Preparar a indisponibilidade regional do Azure para proteger os seus dados
O Azure Data Explorer não suporta proteção automática contra a indisponibilidade de toda uma região do Azure. Esta perturbação pode acontecer durante um desastre natural, como um terramoto. Se precisar de uma solução para uma situação de recuperação após desastre, siga os seguintes passos para garantir a continuidade do negócio. Nestes passos, irá replicar os clusters, a gestão e a ingestão de dados em duas regiões emparelhadas do Azure.
- Crie dois ou mais clusters independentes em duas regiões emparelhadas do Azure.
- Replicar todas as atividades de gestão , como criar novas tabelas ou gerir funções de utilizador em cada cluster.
- Ingerir dados em cada cluster em paralelo.
Criar vários clusters independentes
Crie mais do que um cluster de Data Explorer do Azure em mais do que uma região. Certifique-se de que, pelo menos, dois destes clusters são criados em regiões emparelhadas do Azure.
A imagem seguinte mostra réplicas, três clusters em três regiões diferentes.
Replicar atividades de gestão
Replicar as atividades de gestão para ter a mesma configuração de cluster em cada réplica.
Crie em cada réplica da mesma forma:
- Bases de dados: pode utilizar o portal do Azure ou um dos nossos SDKs para criar uma nova base de dados.
- Tabelas
- Mapeamentos
- Políticas
Gerir a autenticação e autorização em cada réplica.
Solução de recuperação após desastre com a ingestão do hub de eventos
Depois de concluir a preparação para a indisponibilidade regional do Azure para proteger os seus dados, os seus dados e gestão são distribuídos por várias regiões. Se houver uma falha numa região, o Azure Data Explorer poderá utilizar as outras réplicas.
Configurar a ingestão com um hub de eventos
Para ingerir dados de Hubs de Eventos do Azure no cluster do Azure Data Explorer de cada região, replice primeiro a configuração do Hubs de Eventos do Azure em cada região. Em seguida, configure a réplica do Azure Data Explorer de cada região para ingerir dados dos respetivos Hubs de Eventos correspondentes.
Nota
A ingestão através de Hubs de Eventos do Azure/Hub IoT/Armazenamento é robusta. Se um cluster não estiver disponível durante um período de tempo, será atualizado mais tarde e inserirá quaisquer mensagens ou blobs pendentes. Este processo baseia-se no ponto de verificação.
Conforme mostrado no diagrama abaixo, as origens de dados produzem eventos para os hubs de eventos em todas as regiões e cada réplica de Data Explorer do Azure consome os eventos. Os componentes de visualização de dados, como o Power BI, o Grafana ou o SDK WebApps, podem consultar uma das réplicas.
Otimizar custos
Agora, está pronto para otimizar as réplicas com alguns dos seguintes métodos:
- Criar uma configuração de recuperação de dados a pedido
- Iniciar e parar as réplicas
- Implementar um serviço de aplicações de elevada disponibilidade
- Otimizar o custo numa configuração ativa-ativa
Criar uma configuração de recuperação de dados a pedido
Replicar e atualizar a configuração do Azure Data Explorer aumentará linearmente o custo com o número de réplicas. Para otimizar o custo, pode implementar uma variante de arquitetura para equilibrar o tempo, a ativação pós-falha e o custo. Numa configuração de recuperação de dados a pedido, a otimização de custos foi implementada através da introdução de réplicas passivas do Azure Data Explorer. Estas réplicas só são ativadas se ocorrer um desastre na região primária (por exemplo, região A). As réplicas nas Regiões B e C não precisam de estar ativas 24 horas por dia, 7 dias por semana, o que reduz significativamente o custo. No entanto, na maioria dos casos, o desempenho destas réplicas não será tão bom como o cluster primário. Para obter mais informações, veja Configuração da recuperação de dados a pedido.
Na imagem abaixo, apenas um cluster está a ingerir dados do hub de eventos. O cluster primário na Região A realiza 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 através de tabelas externas.
Iniciar e parar as réplicas
Pode iniciar e parar as réplicas secundárias com um dos seguintes métodos:
Conector do Azure Data Explorer para o Power Automate (Pré-visualização)
O botão Parar no separador Descrição Geral no portal do Azure. Para obter mais informações, veja Parar e reiniciar o cluster.
CLI do Azure:
az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>”
Implementar um serviço de aplicações de elevada disponibilidade
Criar o cliente BCDR Serviço de Aplicações do Azure
Esta secção mostra-lhe como criar um Serviço de Aplicações do Azure que suporta uma ligação a um único cluster primário e múltiplos Data Explorer secundários do Azure. A imagem seguinte ilustra o Serviço de Aplicações do Azure configuração.
Dica
Ter várias ligações entre réplicas no mesmo serviço permite-lhe aumentar a disponibilidade. Esta configuração não é apenas útil em casos de interrupções regionais.
Utilize este código boilerplate para um serviço de aplicações. Para implementar um cliente de vários clusters, foi criada a classe AdxBcdrClient . Cada consulta executada com este cliente será enviada primeiro para o cluster primário. Se ocorrer uma falha, a consulta será enviada para réplicas secundárias.
Utilize métricas personalizadas do Application Insights para medir o desempenho e pedir a distribuição para clusters primários e secundários.
Testar o cliente BCDR Serviço de Aplicações do Azure
Executámos um teste com várias réplicas de Data Explorer do Azure. Após uma falha simulada de clusters primários e secundários, pode ver que o cliente BCDR do serviço de aplicações está a comportar-se conforme pretendido.
Os clusters do Azure Data Explorer são distribuídos pela Europa Ocidental (primária 2xD14v2), Sudeste Asiático e E.U.A. Leste (2xD11v2).
Nota
Os tempos de resposta mais lentos devem-se a diferentes SKUs e consultas entre planetas.
Executar encaminhamento dinâmico ou estático
Utilize métodos de encaminhamento do Gestor de Tráfego do Azure para encaminhamento dinâmico ou estático dos pedidos. O Gestor de Tráfego do Azure é um balanceador de carga de tráfego baseado em DNS que lhe permite distribuir o tráfego do serviço de aplicações. Este tráfego é otimizado para serviços em regiões globais do Azure, ao mesmo tempo que proporciona elevada disponibilidade e capacidade de resposta.
Também pode utilizar o encaminhamento baseado no Azure Front Door. Para comparar estes dois métodos, veja Balanceamento de carga com o conjunto de entrega de aplicações do Azure.
Otimizar o custo numa configuração ativa-ativa
Utilizar uma configuração ativa-ativa para recuperação após desastre aumenta o custo linearmente. O custo inclui nós, armazenamento, marcação e aumento do custo de rede da largura de banda.
Utilizar o dimensionamento automático otimizado para otimizar os custos
Utilize a funcionalidade de dimensionamento automático otimizada para configurar o dimensionamento horizontal para os clusters secundários. Devem ser dimensionadas para poderem processar a carga de ingestão. Assim que o cluster primário não estiver acessível, os clusters secundários irão obter mais tráfego e dimensionamento de acordo com a configuração.
A utilização do dimensionamento automático otimizado neste exemplo guardou cerca de 50% do custo em comparação com a mesma escala horizontal e vertical em todas as réplicas.