Compartilhar via

Criar soluções de continuidade de negócios e recuperação de desastre com Azure Data Explorer

  • Artigo

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.

  1. Crie dois ou mais clusters independentes em duas regiões emparelhadas do Azure.
  2. Replique todas as atividades de gerenciamento como criar novas tabelas ou gerenciar funções de usuário em cada cluster.
  3. 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.

Criar clusters independentes.

Replicar atividades de gerenciamento

Replique as atividades de gerenciamento para ter a mesma configuração de cluster em cada réplica.

  1. Crie em cada réplica os mesmos:

  2. Gerenciar autenticação e autorização em cada réplica.

    Duplicar atividades de gerenciamento.

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.

Ingerir por meio de Hubs de Eventos do Azure.

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.

Fontes de dados para visualização de dados.

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

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.

arquitetura para uma configuração de recuperação de dados sob demanda.

Iniciar e parar as réplicas

Você pode iniciar e parar as réplicas secundárias usando um dos seguintes métodos:

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.

Criar um 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 instâncias de paralisações regionais.

  1. 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.

  2. 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.

Verifique o cliente BCDR do serviço de aplicativo.

Os clusters Azure Data Explorer são distribuídos pelo Oeste da Europa (primária 2xD14v2), Sudeste da Ásia e Leste dos EUA (2xD11v2).

Tempo de resposta da consulta entre o planeta.

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.

Conteúdo relacionado