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 datacenters 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 que mais de uma seja afetada por interrupções locais ou pelo clima. As zonas de disponibilidade têm infraestrutura independente de energia, refrigeração e rede. Eles são projetados para que, se uma zona sofrer uma interrupção, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas zonas restantes. Para obter mais informações, consulte Zonas de Disponibilidade do Azure.

Os clusters do Azure Data Explorer podem ser configurados para usar zonas de disponibilidade em regiões com suporte. 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 .

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

• REST API
• C# SDK
• Python SDK
• PowerShell
• Modelo ARM

Importante

• Depois que um cluster é configurado com zonas de disponibilidade, você não pode alterá-lo para não usar zonas de disponibilidade.
• Não são suportadas múltiplas zonas em todas as regiões. Portanto, os clusters localizados nessas regiões não podem ser configurados para usar zonas de disponibilidade.
• O uso de zonas de disponibilidade incorre em custos adicionais.

Observação

• Antes de prosseguir, certifique-se de que está familiarizado com o processo de migração e com 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:

• Como configurar o seu cluster para suportar zonas de disponibilidade
• A arquitetura de clusters com zonas de disponibilidade
• O processo de migração e as considerações

Pré-requisitos

• Verifique se o cluster está em uma região onde a migração para várias zonas de disponibilidade é suportada.

• Para migrar um cluster para dar suporte a zonas de disponibilidade, você precisa de um cluster que foi implantado sem zonas de disponibilidade.

• Para alterar as zonas de um cluster, você precisa de um cluster configurado com zonas de disponibilidade.

• Para a API REST, familiarize-se com Gerenciar recursos do Azure usando a API REST.

• Para outros métodos programáticos, consulte 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:

Portal Azure

1. No portal do Azure, vá para a página Visão Geral do do cluster.

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

3. Na linha do cluster, as zonas de disponibilidade são listadas na coluna zonas de disponibilidade.

   

PowerShell

Antes de começar, certifique-se de que tem os cmdlets az.Kusto instalados e de que iniciou sessão, e, em seguida, execute o seguinte comando para obter a lista de zonas de disponibilidade para a região do cluster:

1. Defina o ID do recurso do cluster. Você pode obter a ID de recurso do seu cluster no portal do Azure, na página Propriedades do cluster.

   $resource_id = "<ClusterResourceID>"
   

2. Obtenha os detalhes do seu cluster.

   $mycluster = Get-AzKustoCluster -InputObject $resource_id
   

3. Obtenha a localização do seu cluster.

   Importante

   Get-AzLocation requer o módulo Az.Resources. Se não o tiver instalado, execute Install-Module Az.Resources.

   $location = (Get-AzLocation | where DisplayName -EQ $mycluster.Location).location
   

4. Obtenha o ID do cluster.

   $mycluster.Id  -match "/subscriptions/(.*?)/" | Out-Null; $subscription = $Matches[1]
   

5. Obtenha a lista de zonas de disponibilidade para a região do cluster.

   $bearer = (Get-AzAccessToken).Token
   $rest_result = (Invoke-RestMethod -Uri https://management.azure.com/subscriptions/$subscription/providers/Microsoft.Kusto/locations/${location}/skus?api-version=2022-11-11 -Headers @{Authorization="Bearer $bearer"})
   $zones = $rest_result | select -ExpandProperty Value | where name -eq $mycluster.SkuName | select -ExpandProperty locationInfo | select zones
   $zones
   

Configurar o cluster para suportar zonas de disponibilidade

Para adicionar zonas de disponibilidade a um cluster existente, você deve atualizar o atributo zones cluster com uma lista das zonas de disponibilidade de destino. 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

API REST

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}" ] }
   

C#

1. Se você não tiver o Azure.Identity e bibliotecas Azure.ResourceManager.Kusto instaladas, use os seguintes comandos para instalá-las:

   dotnet add package Azure.Identity
   dotnet add package Azure.ResourceManager.Kusto
   

2. Em seu aplicativo, adicione o seguinte código:

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

   Por exemplo, para definir suas zonas como 1, 2 e 3, na região Norte da Europa, use o seguinte código:

   using Azure.Core;
   using Azure.ResourceManager.Kusto;
   using Azure.ResourceManager.Kusto.Models;
   using ArmClient = Azure.ResourceManager.ArmClient;
   using ClientSecretCredential = Azure.Identity.ClientSecretCredential;
   using WaitUntil = Azure.WaitUntil;
   
   var tenantId = "{tenantId}";
   var clientId = "{clientId}";
   var clientSecret = "{clientSecret}";
   var subscriptionId = "{subscriptionId}";
   var resourceGroupName = "{resourceGroupName}";
   var clusterName = "{clusterName}";
   
   var credentials = new ClientSecretCredential(tenantId, clientId, clientSecret);
   var resourceManagementClient = new ArmClient(credentials, subscriptionId);
   var resourceIdentifier = new ResourceIdentifier($"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Kusto/Clusters/{clusterName}");
   var cluster = resourceManagementClient.GetKustoClusterResource(resourceIdentifier);
   
   var kustoClusterPatch = new KustoClusterPatch(AzureLocation.NorthEurope);
   kustoClusterPatch.Zones.Clear();
   kustoClusterPatch.Zones.Add("1");
   kustoClusterPatch.Zones.Add("2");
   kustoClusterPatch.Zones.Add("3");
   
   var armOperation = await cluster.UpdateAsync(WaitUntil.Started, kustoClusterPatch).ConfigureAwait(false);
   
   var response = armOperation.UpdateStatus();
   Console.WriteLine($"ClientRequestId: {response.ClientRequestId}");
   
   while (true)
   {
     Console.WriteLine($"{DateTime.UtcNow:o} {response.Status, -5} {response.ReasonPhrase}");
     if (armOperation.HasCompleted)
       break;
   
     await Task.Delay(60000).ConfigureAwait(false);
     response = await armOperation.UpdateStatusAsync().ConfigureAwait(false);
   }
   

3. Execute seu aplicativo.

Python

1. Em seu aplicativo, adicione o seguinte código:

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

   Por exemplo, para definir suas zonas como 1, 2 e 3, na região Norte da Europa, use o seguinte código:

   from azure.identity import DefaultAzureCredential
   from azure.mgmt.kusto import KustoManagementClient
   from azure.mgmt.kusto import models
   import time
   from azure.core.exceptions import HttpResponseError 
   
   subscription_id = "{subscriptionId}"
   resource_group_name = "{resourceGroupName}"
   cluster_name = "{clusterName}"
   
   client = KustoManagementClient(DefaultAzureCredential(), subscription_id)
   lro_poller = client.clusters.begin_update(resource_group_name, cluster_name, models.ClusterUpdate.from_dict({"zones": ["1", "2", "3"]}))
   
   while (not(lro_poller.done())):
       time.sleep(60)
   
   print (f"status: {lro_poller.status()}")
   
   try:
       lro_poller.result()
   except HttpResponseError as e:
       print (f"Exception: {e}")
   

2. Execute seu aplicativo.

PowerShell

Você pode usar o seguinte comando do PowerShell para configurar seu cluster para usar zonas de disponibilidade. Certifique-se de que o de bibliotecas de ferramentas Kusto está instalado e substitua os parâmetros pelos seus valores.

Update-AzKustoCluster -SubscriptionId {subscriptionId} -ResourceGroupName {resourceGroupName} -Name {clusterName} -Zone "{zone1}", "{zone2}", "{zone3}"

Modelo ARM

1. No modelo ARM, adicione a seguinte propriedade ao recurso Microsoft.Kusto/clusters:

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

   Por exemplo, para definir suas zonas como 1, 2 e 3, na região Norte da Europa, use o seguinte modelo:

   {
     "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
     "contentVersion": "1.0.0.0",
     "parameters": {
         "clusters_clusterName_name": {
             "defaultValue": "clusterName",
             "type": "string"
         }
     },
     "variables": {},
     "resources": [
         {
             "type": "Microsoft.Kusto/clusters",
             "apiVersion": "2023-05-02",
             "name": "[parameters('clusters_clusterName_name')]",
             "location": "North Europe",
             "sku": {
                 "name": "{skuName}",
                 "tier": "Basic",
                 "capacity": 1
             },
             "zones": ["1","2","3"],
             "identity": {
                 "type": "SystemAssigned"
             },
             "properties": {
                 "trustedExternalTenants": [],
                 "enableDiskEncryption": false,
                 "enableStreamingIngest": false,
                 "languageExtensions": {
                     "value": []
                 },
                 "enablePurge": false,
                 "enableDoubleEncryption": false,
                 "engineType": "V3",
                 "acceptedAudiences": [],
                 "restrictOutboundNetworkAccess": "Disabled",
                 "allowedFqdnList": [],
                 "publicNetworkAccess": "Enabled",
                 "allowedIpRangeList": [],
                 "enableAutoStop": true,
                 "publicIPType": "IPv4"
             }
         }
     ]
   }
   

2. Implante o modelo ARM. Para obter mais informações, consulte Implantar recursos com modelos ARM e Azure CLI.

Durante a migração, a seguinte mensagem aparece no portal do 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 as zonas de disponibilidade são configuradas, os recursos de um cluster são implantados da seguinte maneira:

• camada de computação: o Azure Data Explorer é uma plataforma de computação distribuída que tem dois ou mais nós. Se as zonas de disponibilidade estiverem configuradas, os nós de computação serão distribuídos pela zona de disponibilidade definida para máxima resiliência dentro da região. Uma falha de zona pode degradar o desempenho do cluster, até que os recursos de computação com falha sejam reimplantados nas zonas sobreviventes. Recomendamos configurar o máximo de zonas disponíveis em uma região.

  Observação

  • Em alguns casos, devido a limitações de capacidade de computação, apenas zonas de disponibilidade parcial estarão disponíveis para a camada de computação.
  • A camada de computação de um cluster implementa uma abordagem de melhor esforço para distribuir instâncias uniformemente entre zonas selecionadas.

• Camada de armazenamento persistente: os clusters usam o Armazenamento do Azure como sua camada de persistência durável. Se as zonas de disponibilidade estiverem configuradas, ZRS será habilitado, colocando réplicas de armazenamento em todas as três zonas de disponibilidade para máxima resiliência dentro da região.

  Observação

  • A ZRS incorre num custo adicional.
  • Quando as zonas de disponibilidade não são configuradas, os recursos de armazenamento são implantados com a configuração padrão de Armazenamento Localmente Redundante (LRS), colocando todas as 3 réplicas em uma única zona.

Processo de migração

Quando um cluster existente que foi implantado sem zonas de disponibilidade é configurado para dar suporte a zonas de disponibilidade, as seguintes etapas ocorrem como parte do processo de migração:

• A computação é distribuída nas zonas de disponibilidade definidas

  O processo de redistribuição de recursos de computação envolve uma etapa de preparação na qual o cache zonal de recursos de computação é 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 computacionais só ocorre quando estiver totalmente preparada e operacional. 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, é importante observar que o desempenho da consulta pode ser afetado durante a migração de SKU. O grau de impacto pode variar dependendo de padrões de uso específicos.

• Os dados históricos de armazenamento persistente são migrados para o ZRS

  O processo de migração depende do suporte regional para a transição do armazenamento LRS para ZRS, bem como 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.

• Todos os novos dados são gravados no ZRS

  Depois que a solicitação de migração para zonas de disponibilidade é iniciada, todos os novos dados são replicados e armazenados 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, a reciclagem de novos dados a serem gravados como dados ZRS pode levar até 30 dias.

Considerações

A solicitação de migração para zonas de disponibilidade pode não ser bem-sucedida devido a restrições de capacidade. Para uma migração bem-sucedida, deve haver capacidade de computação e armazenamento suficiente para dar suporte à migração. Se houver limitações de capacidade, você receberá uma mensagem de erro indicando o problema.

Conteúdo relacionado

• Visão geral da continuidade de negócios e recuperação de desastres