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 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 mediante programación mediante uno de los métodos siguientes:

• 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 estar familiarizado con el proceso de migración y las consideraciones.
• 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:

• Configuración del clúster para admitir zonas de disponibilidad
• Arquitectura de clústeres con zonas de disponibilidad
• El proceso de migración y las consideraciones

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 obtener más información, consulte Regiones admitidas.

• Para migrar un clúster para admitir zonas de disponibilidad, necesita un clúster que se implementó 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 REST, familiarícese con La administración de recursos de Azure mediante la API REST.

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

Regiones admitidas

La migración a varias zonas de disponibilidad se limita a las regiones que no tienen restricciones de capacidad. Actualmente se admiten las siguientes regiones:

• Este de Australia
• Centro de Canadá
• Norte de China 3
• India central
• Norte de Europa
• Este de Noruega
• Norte de Sudáfrica
• Centro de Suecia
• Norte de Emiratos Árabes Unidos
• Sur de Reino Unido 2

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 maneras siguientes:

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 az. Los cmdlets de Kusto instalados e iniciados sesión y, a continuación, ejecutan 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 Az.Resources módulo. 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 de clúster zones con una lista de las zonas de disponibilidad de destino. Siga las instrucciones para el método preferido mediante la información de la tabla siguiente:

Parámetro	Valor
subscriptionId	Identificador de suscripción del clúster
resourceGroupName	Nombre del grupo de recursos del clúster
clusterName	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 REST al siguiente punto de conexión donde reemplace 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 código siguiente:

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

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

   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 código siguiente:

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

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

   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 reemplacen los parámetros por sus 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 Microsoft.Kusto/clusters recurso:

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

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

   {
     "$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 mensaje siguiente 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 zonalidad 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. Se recomienda configurar las zonas máximas 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, ZRS está habilitada, colocando réplicas de almacenamiento en las tres zonas de disponibilidad para lograr la 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), colocar las tres réplicas es 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 pasos siguientes como parte del proceso de migración:

• El proceso se distribuye en las zonas de disponibilidad definidas

  El proceso de redistribuir recursos de proceso implica una fase de preparación en la que se calienta la memoria caché de recursos de proceso zonal. 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 hasta decenas de 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 solo una interrupción mínima del servicio durante el proceso de conmutación, normalmente duradera 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 que consume mucho tiempo, lo que puede tardar varias horas o incluso extenderse hasta 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