Migrar o cluster para suportar várias zonas de disponibilidade (pré-visualização)

Muitas regiões do Azure fornecem zonas de disponibilidade, que são grupos separados de centros de dados dentro de uma região. As zonas de disponibilidade são próximas o suficiente para ter conexões de baixa latência com outras zonas de disponibilidade. Eles são conectados por uma rede de alto desempenho com uma latência de ida e volta de menos de 2 ms. No entanto, as zonas de disponibilidade estão suficientemente afastadas para reduzir a probabilidade de interrupções locais ou condições meteorológicas afetarem mais do que uma zona de disponibilidade. Cada zona de disponibilidade tem infraestrutura independente de energia, arrefecimento e rede. São concebidos para que, se uma zona sofrer uma falha, as restantes suportem serviços regionais, capacidade e alta disponibilidade. Para mais informações, consulte Azure Zonas de Disponibilidade.

Pode configurar clusters do Azure Data Explorer para usarem zonas de disponibilidade em regiões suportadas. Usando zonas de disponibilidade, um cluster pode suportar melhor a falha de um único datacenter numa região para dar suporte a cenários de continuidade de negócios .

Pode configurar zonas de disponibilidade ao criar um cluster no portal Azure ou programaticamente usando um dos seguintes métodos:

  • API REST
  • C# SDK
  • Python SDK
  • PowerShell
  • modelo do ARM

Importante

  • Depois de configurar um cluster com zonas de disponibilidade, não pode alterar o cluster para não usar zonas de disponibilidade.
  • Nem todas as regiões suportam múltiplas zonas. Portanto, não se pode configurar clusters nestas regiões para usar zonas de disponibilidade.
  • Utilizar zonas de disponibilidade acarreta custos adicionais de armazenamento.

Observação

  • Antes de avançar, certifique-se de que está familiarizado com o processo de migração e as considerações.
  • Você também pode usar essas etapas para alterar as zonas de um cluster existente que usa zonas de disponibilidade.

Neste artigo, você aprende sobre:

Pré-requisitos

Obter a lista de zonas de disponibilidade para a região do cluster

Você pode obter uma lista de zonas de disponibilidade para seu cluster das seguintes maneiras:

  1. No portal Azure, aceda à página Visão Geral do seu cluster.

  2. Em Configurações, selecione Aumentar a escala.

  3. Na linha do seu cluster, as zonas de disponibilidade aparecem na coluna Zonas de Disponibilidade .

    Captura de ecrã da página Escalar no portal Azure mostrando a coluna das zonas de disponibilidade com as zonas listadas para o cluster selecionado.

Configurar o cluster para suportar zonas de disponibilidade

Para adicionar zonas de disponibilidade a um cluster existente, atualize o atributo do cluster zones com uma lista das zonas de disponibilidade alvo. Siga as instruções para o seu método preferido, usando as informações na tabela a seguir:

Parâmetro Valor
subscriptionId O ID de assinatura do cluster
resourceGroupName O nome do grupo de recursos do cluster
clusterName O nome do cluster
apiVersion 2023-05-02 ou posterior

Siga as instruções sobre como implantar um modelo.

  1. Faça a chamada da API REST para o seguinte ponto de extremidade, onde você substitui os parâmetros pelos seus valores:

    PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Kusto/clusters/{clusterName}?api-version={apiVersion}
    
  2. Especifique suas zonas de disponibilidade no corpo da solicitação. Por exemplo, para configurar o cluster para usar as zonas de disponibilidade 1, 2 e 3, defina o corpo da seguinte maneira:

    { "zones": [ "{zone1}", "{zone2}", "{zone3}" ] }
    

Durante a migração, a seguinte mensagem aparece no portal Azure, na página de visão geral do cluster. A mensagem é removida após a conclusão da migração.

A mudança de zonalidade para o armazenamento deste cluster está em andamento. O tempo de atualização pode variar dependendo da quantidade de dados.

Arquitetura de clusters com zonas de disponibilidade

Quando configura zonas de disponibilidade, o cluster implementa os recursos da seguinte forma:

  • Camada de Computação: O Azure Data Explorer é uma plataforma de computação distribuída que possui dois ou mais nós. Se configurar zonas de disponibilidade, o cluster distribui os nós de computação pelas zonas de disponibilidade definidas para máxima resiliência intra-rregional. Uma falha de zona pode degradar o desempenho do cluster, até que os recursos de computação com falha sejam reimplantados nas zonas sobreviventes. Configure as zonas máximas disponíveis numa região.

    Observação

    • Em alguns casos, devido a limitações de capacidade de computação, apenas zonas de disponibilidade parciais estão disponíveis para a camada de computação.
    • A camada de computação de um cluster utiliza uma abordagem de melhor esforço para distribuir uniformemente as instâncias entre zonas selecionadas.
  • Camada de armazenamento persistente: Os clusters utilizam o Armazenamento do Azure como camada de persistência duradoura. Se configurar zonas de disponibilidade, o cluster ativa ZRS, colocando três réplicas de armazenamento em várias zonas de disponibilidade para máxima resiliência dentro da região.

    Observação

    • O ZRS tem um custo adicional.
    • Quando não configuras zonas de disponibilidade, os recursos de armazenamento usam a definição padrão de Armazenamento Redundante Localmente (LRS), colocando as três réplicas numa única zona.

Processo de migração e considerações

Quando configura um cluster existente que implementou sem zonas de disponibilidade para passar a suportar zonas de disponibilidade, o processo de migração executa os passos seguintes:

  • Distribui os recursos de computação entre as zonas de disponibilidade definidas

    O processo de redistribuição dos recursos de computação envolve uma fase de preparação em que o cache de recursos de computação zonal é aquecido. Durante a etapa de preparação, os recursos de computação do cluster existente continuam a funcionar, garantindo um serviço ininterrupto. Esta fase de preparação pode demorar até dezenas de minutos. A transição para os novos recursos de computação só ocorre quando estão totalmente preparados e operacionais. Essa abordagem de processamento paralelo garante uma experiência relativamente perfeita, com apenas uma interrupção mínima do serviço durante o processo de transição, normalmente com duração entre um a três minutos. No entanto, o desempenho das consultas pode ser afetado durante a migração do SKU. O grau de impacto pode variar dependendo de padrões de uso específicos.

  • Migra dados históricos de armazenamento persistente para ZRS

    O processo de migração depende do suporte regional para a transição do armazenamento LRS para o ZRS e da capacidade disponível das contas de armazenamento nas zonas selecionadas. A transferência de dados históricos pode ser um processo demorado, potencialmente levando várias horas ou até mesmo se estendendo por semanas.

  • Escreve todos os novos dados no ZRS

    Depois de iniciar o pedido de migração para zonas de disponibilidade, o sistema replica e armazena todos os novos dados na configuração do ZRS.

    Observação

    • Após a solicitação de migração, pode haver um atraso de até vários minutos antes que todos os novos dados comecem a ser gravados na configuração do ZRS.
    • Se um cluster tiver ingestão de streaming, então a reciclagem de novos dados a serem escritos como dados ZRS pode demorar até 30 dias.
  • Atualiza o estado da zona

    Uma vez concluído o pedido de migração para as zonas de disponibilidade, o sistema atualiza o estado da zona para refletir as zonas suportadas. Se o status da zona for Inconsistência zonal, isso indica que alguns recursos de computação ou armazenamento não conseguiram migrar e não são zonais. Esta condição ocorre geralmente quando não há capacidade zonal suficiente disponível para alguns recursos. Nesses casos, tente novamente a migração mais tarde, quando houver capacidade disponível.

Considerações sobre migração

Restrições de capacidade podem impedir um pedido de migração bem-sucedido. Para uma migração bem-sucedida, deve haver capacidade suficiente de computação e armazenamento para suportar a migração. Se existirem limitações de capacidade, recebe uma mensagem de erro a indicar o problema.