Migrar seu cluster para dar suporte a várias zonas de disponibilidade (versão prévia)

Várias regiões do Azure fornecem zonas de disponibilidade, que são grupos separados de datacenters em uma região. As zonas de disponibilidade estão próximas o suficiente para terem conexões de baixa latência com outras zonas de disponibilidade. Elas são conectadas 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 afastadas para reduzir a probabilidade de que mais de uma seja afetada por interrupções locais ou condições meteorológicas. As zonas de disponibilidade têm infraestruturas independentes de energia, resfriamento e rede. Elas são projetadas 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 compatíveis. Ao usar zonas de disponibilidade, um cluster pode suportar melhor a falha de um único datacenter em uma região para dar suporte a cenários de continuidade de negócios.

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

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

Importante

• Depois que um cluster é configurado com zonas de disponibilidade, não é possível alterar o cluster para não usar zonas de disponibilidade.
• Não há suporte para várias 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, verifique se você 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ê aprenderá sobre:

• Como configurar seu cluster para dar suporte a zonas de disponibilidade
• A arquitetura dos clusters com zonas de disponibilidade
• O processo de migração e suas considerações

Pré-requisitos

• Certifique-se de que seu cluster esteja em uma região em que a migração para várias zonas de disponibilidade seja compatível.

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

• Para alterar as zonas de um cluster, você precisa de um cluster que esteja 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 seu cluster

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

Azure portal

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

2. Em Configurações, selecione Escalar verticalmente.

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

   

PowerShell

Antes de começar, verifique se você tem os cmdlets az.Kusto instalados e conectadose, em seguida, execute o seguinte comando para obter a lista de zonas de disponibilidade para a região do seu cluster:

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

   $resource_id = "<ClusterResourceID>"
   

2. Obtenha os detalhes de seu cluster.

   $mycluster = Get-AzKustoCluster -InputObject $resource_id
   

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

   Importante

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

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

4. Obtenha a ID do seu cluster.

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

5. Obter a lista de zonas de disponibilidade para a região do seu 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
   

Configure seu cluster para dar suporte a zonas de disponibilidade

Para adicionar zonas de disponibilidade a um cluster existente, você deve atualizar o atributo zones do cluster com uma lista das zonas de disponibilidade de destino. Siga as instruções de seu método preferido, usando as informações da tabela a seguir:

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

Importante

A alteração das zonas de disponibilidade para um cluster existente altera apenas as zonas de disponibilidade para a computação. O armazenamento persistente não é alterado.

REST API

Siga as instruções sobre como implantar um módulo.

1. Faça a chamada da API REST para o seguinte ponto de extremidade, onde você substitui os parâmetros por 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 forma:

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

C#

1. Se você não tiver as bibliotecas Azure.Identity e 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. Executar 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. Executar seu aplicativo.

PowerShell

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

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

Modelo do ARM

1. Em seu modelo do 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. Implantar o modelo do ARM. Para obter mais informações, confira Implantar recursos com modelos do ARM e a CLI do Azure.

Durante a migração, a seguinte mensagem é exibida 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 alteração de zonalidade para o armazenamento desse 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 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 serão distribuídos pela zona de disponibilidade definida para obter o máximo de resiliência intra-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, somente 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 as instâncias pelas zonas selecionadas.

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

  Observação

  • O ZRS incorre em um custo adicional.
  • Quando as zonas de disponibilidade não estão configuradas, os recursos de armazenamento são implantados com a configuração padrão de Armazenamento Com Redundância Local (LRS), colocando todas as 3 réplicas é uma única zona.

Processo de migração

Quando um cluster existente que foi implantado sem nenhum zona 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 um estágio de preparação na qual o cache de recursos de computação zonal é aquecido. Durante o estágio de preparação, os recursos de computação do cluster existente continuam funcionando, garantindo um serviço ininterrupto. Essa fase de preparação pode levar até dezenas de minutos. A transição para os novos recursos de computação só ocorre quando eles estiverem totalmente preparados e operacionais. Essa abordagem de processamento paralelo garante uma experiência relativamente perfeita, com apenas interrupção mínima do serviço durante o processo de transição, que normalmente dura de um a três minutos. No entanto, é importante observar que o desempenho da consulta pode ser afetado durante a migração da SKU. O grau de impacto pode variar dependendo dos 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 LRS para a transição do armazenamento ZRS, bem como da capacidade disponível das contas de armazenamento disponíveis nas zonas selecionadas. A transferência de dados históricos pode ser um processo demorado, podendo levar várias horas ou até mesmo 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 do ZRS poderá 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 que a migração seja bem-sucedida, deve haver capacidade suficiente de computação e armazenamento 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 de continuidade dos negócios e recuperação de desastres