Migración del clúster para admitir varias zonas de disponibilidad (versión preliminar)

Muchas regiones de Azure proporcionan zonas de disponibilidad, que son grupos separados de centros de datos dentro de una región. Las zonas de disponibilidad están lo suficientemente cerca como para tener conexiones de baja latencia con otras zonas de disponibilidad. Están conectados por una red de alto rendimiento con una latencia de ida y vuelta de menos de 2 ms. Sin embargo, las zonas de disponibilidad están lo suficientemente separadas para reducir la probabilidad de que más de una se vea afectada por interrupciones locales o el tiempo. Las zonas de disponibilidad tienen una infraestructura de suministro eléctrico, de refrigeración y de red independientes. Están diseñadas para los casos en los que cuando una zona experimente alguna interrupción, las zonas restantes sigan ofreciendo servicios regionales, capacidad y alta disponibilidad. Para obtener más información, consulte Azure Availability Zones.

Los clústeres de Azure Data Explorer se pueden configurar para usar zonas de disponibilidad en regiones admitidas. Mediante el uso de zonas de disponibilidad, un clúster puede resistir mejor el error de un único centro de datos de una región para admitir escenarios de continuidad empresarial.

Puede configurar zonas de disponibilidad al crear un clúster en Azure Portal o con programación mediante uno de los siguientes métodos:

• API DE REST
• SDK DE C#
• SDK de Python
• PowerShell
• Plantilla de ARM

Importante

• Una vez configurado un clúster con zonas de disponibilidad, no se puede cambiar el clúster para que no use zonas de disponibilidad.
• No se admiten varias zonas en todas las regiones. Por lo tanto, los clústeres ubicados en estas regiones no se pueden configurar para usar zonas de disponibilidad.
• El uso de zonas de disponibilidad conlleva costos adicionales.

Nota:

• Antes de continuar, asegúrese de que conoce el proceso de migración y las consideraciones a tener en cuenta.
• También puede usar estos pasos para cambiar las zonas de un clúster existente que usa zonas de disponibilidad.

En este artículo, aprenderá lo siguiente:

• Cómo configurar el clúster para admitir zonas de disponibilidad
• La arquitectura de los clústeres con zonas de disponibilidad
• El proceso de migración y las consideraciones a tener en cuenta

Requisitos previos

• Asegúrese de que el clúster está en una región en la que se admite la migración a varias zonas de disponibilidad.

• Para migrar un clúster para que admita zonas de disponibilidad, necesita un clúster que se haya implementado sin ninguna zona de disponibilidad.

• Para cambiar las zonas de un clúster, necesita un clúster configurado con zonas de disponibilidad.

• Para la API de REST, familiarícese con Administración de recursos de Azure mediante la API de REST.

• Para ver otros métodos mediante programación, consulte Requisitos previos.

Obtención de la lista de zonas de disponibilidad para la región del clúster

Puede obtener una lista de zonas de disponibilidad para el clúster de las siguientes maneras:

Azure Portal

1. En Azure Portal, vaya a la página Información general del clúster.

2. En Configuración, seleccione Escalar verticalmente.

3. En la fila del clúster, las zonas de disponibilidad se muestran en la columna Zonas de disponibilidad.

   

PowerShell

Antes de empezar, asegúrese de que tiene instalados los cmdlets az.Kusto e inicie sesión y, a continuación, ejecute el siguiente comando para obtener la lista de zonas de disponibilidad de la región del clúster:

1. Establezca el identificador de recurso del clúster. Puede obtener el identificador de recurso del clúster desde Azure Portal desde la página Propiedades del clúster.

   $resource_id = "<ClusterResourceID>"
   

2. Obtenga los detalles del clúster.

   $mycluster = Get-AzKustoCluster -InputObject $resource_id
   

3. Obtenga la ubicación del clúster.

   Importante

   Get-AzLocation requiere el módulo Az.Resources. Si no lo tiene instalado, ejecute Install-Module Az.Resources.

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

4. Obtenga el identificador del clúster.

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

5. Obtenga la lista de zonas de disponibilidad para la región del clúster.

   $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
   

Configuración del clúster para admitir zonas de disponibilidad

Para agregar zonas de disponibilidad a un clúster existente, debe actualizar el atributo zones del clúster con una lista de las zonas de disponibilidad de destino. Siga las instrucciones para el método preferido mediante la información de la siguiente tabla:

Parámetro	Valor
subscriptionId	El identificador de suscripción del clúster
resourceGroupName	El nombre del grupo de recursos del clúster
clusterName	El nombre del clúster
apiVersion	2023-05-02 o posterior

Importante

Cambiar las zonas de disponibilidad de un clúster existente solo cambia las zonas de disponibilidad para el proceso. No se cambia el almacenamiento persistente.

REST API

Siga las instrucciones sobre cómo implementar una plantilla.

1. Realice la llamada a la API de REST al siguiente punto de conexión donde reemplazará los parámetros por sus valores:

   PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Kusto/clusters/{clusterName}?api-version={apiVersion}
   

2. Especifique las zonas de disponibilidad en el cuerpo de la solicitud. Por ejemplo, para configurar el clúster para que use las zonas de disponibilidad 1, 2 y 3, establezca el cuerpo de la siguiente manera:

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

C#

1. Si no tiene instaladas las bibliotecas Azure.Identity y Azure.ResourceManager.Kusto, use los siguientes comandos para instalarlas:

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

2. En la aplicación, agregue el siguiente código:

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

   Por ejemplo, para establecer las zonas en 1, 2 y 3, en la región Norte de Europa, use el siguiente 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. Ejecutar la aplicación.

Python

1. En la aplicación, agregue el siguiente código:

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

   Por ejemplo, para establecer las zonas en 1, 2 y 3, en la región Norte de Europa, use el siguiente 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. Ejecutar la aplicación.

PowerShell

Puede usar el siguiente comando de PowerShell para configurar el clúster para usar zonas de disponibilidad. Asegúrese de que las bibliotecas de herramientas de Kusto están instaladas y reemplace los parámetros por los valores.

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

Plantilla de ARM

1. En la plantilla de ARM, agregue la siguiente propiedad al recurso Microsoft.Kusto/clusters:

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

   Por ejemplo, para establecer las zonas en 1, 2 y 3, en la región Norte de Europa, use la siguiente plantilla:

   {
     "$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. Implementar la plantilla de Resource Manager. Para más información, consulte Implementación de recursos con plantillas de ARM y la CLI de Azure.

Durante la migración, aparece el siguiente mensaje en Azure Portal, en la página de información general del clúster. El mensaje se quita una vez completada la migración.

El cambio de zona para el almacenamiento de este clúster está en curso. El tiempo de actualización puede variar en función de la cantidad de datos.

Arquitectura de clústeres con zonas de disponibilidad

Cuando se configuran zonas de disponibilidad, los recursos de un clúster se implementan de la siguiente manera:

• Capa de proceso: Azure Data Explorer es una plataforma informática distribuida que tiene dos o más nodos. Si se configuran zonas de disponibilidad, los nodos de proceso se distribuyen entre la zona de disponibilidad definida para lograr la máxima resistencia dentro de la región. Un error de zona puede degradar el rendimiento del clúster, hasta que los recursos de proceso con errores se vuelvan a implementar en las zonas supervivientes. Recomendamos configurar el máximo de zonas disponibles en una región.

  Nota:

  • En algunos casos, debido a las limitaciones de capacidad de proceso, solo estarán disponibles las zonas de disponibilidad parciales para la capa de proceso.
  • La capa de proceso de un clúster implementa un enfoque de mejor esfuerzo para distribuir uniformemente las instancias entre zonas seleccionadas.

• Capa de almacenamiento persistente: los clústeres usan Azure Storage como capa de persistencia duradera. Si se configuran zonas de disponibilidad, se habilita ZRS, colocando réplicas de almacenamiento en las tres zonas de disponibilidad para lograr una máxima resistencia dentro de la región.

  Nota:

  • ZRS incurre en un costo adicional.
  • Cuando las zonas de disponibilidad no están configuradas, los recursos de almacenamiento se implementan con la configuración predeterminada de almacenamiento con redundancia local (LRS), colocando las tres réplicas en una sola zona.

Proceso de migración

Cuando se configura un clúster existente que se implementó sin ninguna zona de disponibilidad para admitir zonas de disponibilidad, se realizan los siguientes pasos como parte del proceso de migración:

• El proceso se distribuye en las zonas de disponibilidad definidas

  El proceso de redistribución de recursos de proceso implica una fase de preparación en la que se calienta la caché de recursos informáticos zonales. Durante la fase de preparación, los recursos de proceso del clúster existente siguen funcionando, lo que garantiza un servicio ininterrumpido. Esta fase de preparación puede tardar varios minutos. La transición a los nuevos recursos de proceso solo se produce una vez que está totalmente preparado y operativo. Este enfoque de procesamiento paralelo garantiza una experiencia relativamente fluida, con una interrupción mínima del servicio durante el proceso de conmutación, que suele durar entre uno y tres minutos. Sin embargo, es importante tener en cuenta que el rendimiento de las consultas puede verse afectado durante la migración de la SKU. El grado de impacto puede variar en función de los patrones de uso específicos.

• Los datos de almacenamiento persistente históricos se migran a ZRS

  El proceso de migración depende de la compatibilidad regional para la transición de LRS al almacenamiento ZRS, así como de la capacidad de las cuentas de almacenamiento disponibles en las zonas seleccionadas. La transferencia de datos históricos puede ser un proceso largo, que puede durar varias horas o incluso semanas.

• Todos los datos nuevos se escriben en ZRS

  Una vez iniciada la solicitud de migración a zonas de disponibilidad, todos los datos nuevos se replican y almacenan en la configuración de ZRS.

  Nota:

  • Después de la solicitud de migración, puede haber un retraso de hasta varios minutos antes de que todos los datos nuevos empiecen a escribirse en la configuración de ZRS.
  • Si un clúster tiene ingesta de streaming, el reciclaje de nuevos datos que se escribirán como datos ZRS puede tardar hasta 30 días.

Consideraciones

Es posible que la solicitud de migración a zonas de disponibilidad no se realice correctamente debido a restricciones de capacidad. Para una migración correcta, debe haber suficiente capacidad de proceso y almacenamiento para admitir la migración. Si hay limitaciones de capacidad, recibirá un mensaje de error que indica el problema.

Contenido relacionado

• Introducción a la continuidad empresarial y recuperación ante desastres