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 numa região. As zonas de disponibilidade estão suficientemente próximas para terem ligações de baixa latência a outras zonas de disponibilidade. Estão ligados por uma rede de alto desempenho com uma latência de ida e volta inferior a 2 ms. No entanto, as zonas de disponibilidade estão suficientemente distantes para reduzir a probabilidade de mais do que uma ser afetada por indisponibilidades locais ou condições meteorológicas. As zonas de disponibilidade têm energia, arrefecimento e infraestrutura de rede independentes. Foram concebidos para que, se uma zona sofrer uma indisponibilidade, os serviços regionais, a capacidade e a elevada disponibilidade sejam suportados pelas restantes zonas. Para obter mais informações, veja Azure Zonas de Disponibilidade.

Os clusters do Azure Data Explorer podem ser configurados para utilizar zonas de disponibilidade em regiões suportadas. Ao utilizar zonas de disponibilidade, um cluster pode suportar melhor a falha de um único datacenter numa região para suportar cenários de continuidade de negócio .

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

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

Importante

• Assim que um cluster estiver configurado com zonas de disponibilidade, não pode alterar o cluster para não utilizar zonas de disponibilidade.
• Não são suportadas várias zonas em todas as regiões. Por conseguinte, os clusters localizados nestas regiões não podem ser configurados para utilizar zonas de disponibilidade.
• A utilização de zonas de disponibilidade implica custos adicionais.

Nota

• Antes de continuar, certifique-se de que está familiarizado com o processo de migração e as considerações.
• Também pode utilizar estes passos para alterar as zonas de um cluster existente que utiliza zonas de disponibilidade.

Neste artigo, ficará a saber mais sobre:

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

Pré-requisitos

• Certifique-se de que o cluster está numa região onde a migração para várias zonas de disponibilidade é suportada. Para obter mais informações, veja Regiões suportadas.

• Para migrar um cluster para suportar zonas de disponibilidade, precisa de um cluster que tenha sido implementado sem zonas de disponibilidade.

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

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

• Para outros métodos programáticos, veja Pré-requisitos.

Regiões suportadas

A migração para várias zonas de disponibilidade está limitada a regiões que não têm restrições de capacidade. As seguintes regiões são atualmente suportadas:

• Leste da Austrália
• Canadá Central
• Norte da China 3
• França Central
• Índia Central
• Europa do Norte
• Leste da Noruega
• Norte da África do Sul
• Suécia Central
• Norte dos E.A.U.
• Sul do Reino Unido

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

Pode obter uma lista de zonas de disponibilidade para o cluster das seguintes formas:

Portal do Azure

1. Na portal do Azure, aceda à página Descrição Geral do cluster.

2. Em Definições, selecione Aumentar verticalmente.

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

   

PowerShell

Antes de começar, certifique-se de que tem az. Os cmdlets kusto foram instalados e com sessão iniciada 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 de recurso do cluster. Pode obter o ID de recurso do cluster a partir do portal do Azure a partir da página Propriedades do cluster.

   $resource_id = "<ClusterResourceID>"
   

2. Obtenha os detalhes do cluster.

   $mycluster = Get-AzKustoCluster -InputObject $resource_id
   

3. Obtenha a localização do cluster.

   Importante

   Get-AzLocation requer o Az.Resources módulo. 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, tem de atualizar o atributo do cluster zones com uma lista das zonas de disponibilidade de destino. Siga as instruções para o seu método preferencial, utilizando as informações na tabela seguinte:

Parâmetro	Valor
subscriptionId	O ID da subscrição do cluster
resourceGroupName	O nome do grupo de recursos do cluster
clusterName	O nome do cluster
apiVersion	2023-05-02 ou posterior

Importante

Alterar as zonas de disponibilidade de um cluster existente só altera as zonas de disponibilidade da computação. O armazenamento persistente não é alterado.

API REST

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

1. Faça a chamada à API REST para o seguinte ponto final, onde 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 as zonas de disponibilidade no corpo do pedido. Por exemplo, para configurar o cluster para utilizar as zonas de disponibilidade 1, 2 e 3, defina o corpo da seguinte forma:

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

C#

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

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

2. Na sua aplicação, adicione o seguinte código:

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

   Por exemplo, para definir as suas zonas como 1, 2 e 3, na região Europa do Norte, utilize 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 a sua aplicação.

Python

1. Na sua aplicação, adicione o seguinte código:

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

   Por exemplo, para definir as suas zonas como 1, 2 e 3, na região Europa do Norte, utilize 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 a sua aplicação.

PowerShell

Pode utilizar o seguinte comando do PowerShell para configurar o cluster para utilizar zonas de disponibilidade. Certifique-se de que as bibliotecas de ferramentas do Kusto estão instaladas e substitua os parâmetros pelos seus valores.

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

Modelo do ARM

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

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

   Por exemplo, para definir as suas zonas como 1, 2 e 3, na região Europa do Norte, utilize 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. Implemente o modelo do Resource Manager. Para obter mais informações, veja Implementar recursos com modelos arm e a CLI do Azure.

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

A alteração de zonalidade para o armazenamento deste cluster está em curso. O tempo de atualização pode variar consoante a 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 implementados da seguinte forma:

• 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 são distribuídos pela zona de disponibilidade definida para uma resiliência máxima intra-região. Uma falha de zona pode degradar o desempenho do cluster, até que os recursos de computação falhados sejam reimplementados nas zonas sobreviventes. Recomendamos que configure as zonas máximas disponíveis numa região.

  Nota

  • Em alguns casos, devido a limitações de capacidade de computação, apenas as 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 uniformemente instâncias entre zonas selecionadas.

• Camada de armazenamento persistente: os clusters utilizam o Armazenamento do Azure como camada de persistência durável. Se as zonas de disponibilidade estiverem configuradas, o ZRS está ativado, colocando as réplicas de armazenamento em todas as três zonas de disponibilidade para uma resiliência máxima intra-região.

  Nota

  • O ZRS implica um custo adicional.
  • Quando as zonas de disponibilidade não estão configuradas, os recursos de armazenamento são implementados com a predefinição de Armazenamento Localmente Redundante (LRS), a colocação das três réplicas é uma única zona.

Processo de migração

Quando um cluster existente que foi implementado sem zonas de disponibilidade é configurado para suportar zonas de disponibilidade, os seguintes passos 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 fase de preparação na qual a cache de recursos de Computação zonal é aqueciada. Durante a fase 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 depois de estar totalmente preparada e operacional. Esta abordagem de processamento paralelo garante uma experiência relativamente totalmente integrada, com apenas uma interrupção mínima do serviço durante o processo de transição, que normalmente dura entre um a três minutos. No entanto, é importante ter em atenção que o desempenho das consultas pode ser afetado durante a migração do SKU. O grau de impacto pode variar consoante os padrões de utilização específicos.

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

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

• Todos os novos dados são escritos no ZRS

  Após o pedido de migração para zonas de disponibilidade ser iniciado, todos os novos dados são replicados e armazenados na configuração ZRS.

  Nota

  • Após o pedido de migração, poderá haver um atraso de até vários minutos antes de todos os novos dados começarem a ser escritos na configuração ZRS.
  • Se um cluster tiver ingestão de transmissão em fluxo, a reciclagem de novos dados a serem escritos como dados ZRS pode demorar até 30 dias.

Considerações

O pedido de migração para zonas de disponibilidade pode não ser bem-sucedido devido a restrições de capacidade. Para uma migração bem-sucedida, tem de existir capacidade de computação e armazenamento suficiente para suportar a migração. Se existirem limitações de capacidade, receberá uma mensagem de erro a indicar o problema.

Conteúdo relacionado

• Descrição geral da continuidade de negócio e recuperação após desastre