Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo explica como se preparar para uma interrupção regional Azure replicando seus recursos, gerenciamento e ingestão de Azure Data Explorer em diferentes regiões Azure. O artigo inclui um exemplo de ingestão de dados com Hubs de Eventos do Azure. Ele também discute a otimização de custos 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 não oferece suporte à proteção automática contra a indisponibilidade de uma região inteira do Azure. Essa interrupção pode ocorrer durante um desastre natural, como um terremoto. Se você precisar de uma solução de recuperação de desastre, siga estas etapas para garantir a continuidade dos negócios. Nestas etapas, você replica seus clusters, atividades de gerenciamento e ingestão de dados em duas regiões emparelhadas 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.
- Importe os dados para cada cluster em paralelo.
Criar vários clusters independentes
Crie mais de um cluster do Azure Data Explorer em mais de uma região. Crie pelo menos dois desses clusters em regiões emparelhadas Azure.
O diagrama a seguir mostra três clusters de réplica em três regiões diferentes.
Replicar atividades de gerenciamento
Replique as atividades de gerenciamento para que cada réplica tenha a mesma configuração de cluster.
Crie os mesmos recursos em cada réplica:
- Bancos de dados: use o portal Azure ou um dos 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 desastres com ingestão via Event Hubs
Depois de concluir Preparar-se para uma interrupção regional do Azure para proteger seus dados, o Azure Data Explorer armazena seus dados e o gerenciamento deles em várias regiões. Se houver uma interrupção em uma região, Azure Data Explorer poderá usar as outras réplicas.
Configurar a ingestão usando o Event Hubs
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 correspondentes.
Observação
A ingestão de dados via Hubs de Eventos do Azure, Hub IoT ou Storage é robusta. Se um cluster não estiver disponível por algum tempo, ele se atualiza depois e insere quaisquer mensagens ou blobs pendentes. Esse processo depende do ponto de verificação.
Este diagrama mostra que 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 esses eventos. Componentes de visualização de dados, como Power BI, Grafana ou aplicativos web baseados em SDK, podem consultar uma réplica.
Otimizar custos
Agora você está pronto para otimizar suas réplicas usando alguns dos seguintes métodos:
- Crie uma configuração de recuperação de dados sob demanda.
- Iniciar e parar as réplicas.
- Implementar um serviço de aplicação 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 a configuração de Azure Data Explorer aumenta linearmente o custo à medida que o número de réplicas aumenta. Para otimizar o custo, implemente uma variante de arquitetura que equilibre o tempo, o failover e o custo. Uma configuração de recuperação de dados sob demanda otimiza o custo usando réplicas de Azure Data Explorer passivas. 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/7, o que reduz significativamente o custo. Mas, na maioria dos casos, essas réplicas não apresentam desempenho no cluster primário. Para obter mais informações, confira Configuração de recuperação de dados sob demanda.
No diagrama a seguir, apenas um cluster ingere dados dos Hubs 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 acessam os dados usando tabelas externas.
Iniciar e parar as réplicas
Inicie e interrompa as réplicas secundárias usando um dos seguintes métodos:
Conector do Azure Data Explorer para o Power Automate (em 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 configuração do Serviço de Aplicativo do Azure.
Dica
Ter várias conexões entre réplicas no mesmo serviço oferece maior disponibilidade. Essa configuração não é útil apenas em casos de interrupções regionais.
Use este código padrão para um serviço de aplicativo. Para implementar um cliente multicluster, use a classe AdxBcdrClient. Cada consulta executada por esse cliente é enviada primeiro para o cluster primário. Se ocorrer uma falha, a consulta será enviada para réplicas secundárias.
Use métricas personalizadas do Application Insights para medir o desempenho e a distribuição de solicitações entre clusters primários e secundários.
Testar o cliente BCDR do Serviço de Aplicativo do Azure
O teste a seguir usa várias réplicas de Azure Data Explorer. Após uma interrupção simulada de clusters primários e secundários, o cliente BCDR do Serviço de Aplicativo se comporta 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 se devem a diferentes SKUs e consultas entre planetas.
Executar roteamento dinâmico ou estático
Use métodos de roteamento do Gerenciador de Tráfego do Azure para roteamento dinâmico ou estático de solicitações. Gerenciador de Tráfego do Azure é um balanceador de carga de tráfego baseado em DNS que você pode usar para distribuir o tráfego do 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 roteamento baseado no Azure Front Door. 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.
Use o escalonamento automático otimizado para otimizar os custos
Use o recurso de dimensionamento automático otimizado para configurar o dimensionamento horizontal para os clusters secundários. Dimensione clusters secundários para lidar com a carga de ingestão. Quando o cluster primário não é acessível, os clusters secundários obtêm mais tráfego e escala de acordo com a configuração.
Neste exemplo, o dimensionamento automático otimizado economiza cerca de 50% em custo em comparação com o uso da mesma escala horizontal e vertical em todas as réplicas.