Migrer votre cluster pour prendre en charge plusieurs zones de disponibilité (préversion)

De nombreuses régions Azure fournissent des zones de disponibilité, qui sont des groupes séparés de centres de données au sein d’une région. Les zones de disponibilité sont suffisamment proches pour disposer de connexions à faible latence à d’autres zones de disponibilité. Elles sont connectées par un réseau hautes performances avec une latence aller-retour de moins de 2 ms. Toutefois, les zones de disponibilité sont assez éloignées pour réduire la probabilité que plusieurs personnes soient affectées par des pannes locales ou des conditions météorologiques. Les zones de disponibilité disposent d’une alimentation, d’un système de refroidissement et d’une infrastructure réseau indépendants. Ils sont conçus de sorte que, si une zone subit une panne, les services régionaux, la capacité et la haute disponibilité soient pris en charge par les zones restantes. Pour plus d’informations, consultez Azure Zones de disponibilité.

Azure Data Explorer clusters peuvent être configurés pour utiliser des zones de disponibilité dans les régions prises en charge. L’utilisation des zones de disponibilité permet à un cluster de mieux résister à l’échec d’un seul centre de données dans une région pour prendre en charge les scénarios de continuité d’activité.

Vous pouvez configurer des zones de disponibilité lors de la création d’un cluster dans le portail Azure ou programmatiquement à l’aide de l’une des méthodes suivantes :

• API REST
• Kit de développement logiciel (SDK) C#
• SDK Python
• PowerShell
• Modèle ARM

Important

• Une fois qu’un cluster est configuré avec des zones de disponibilité, vous ne pouvez pas modifier le cluster pour ne plus utiliser de zones de disponibilité.
• Le support pour plusieurs zones n'est pas disponible dans toutes les régions. Par conséquent, les clusters situés dans ces régions ne peuvent pas être configurés pour utiliser des zones de disponibilité.
• L’utilisation de zones de disponibilité entraîne des coûts supplémentaires pour le stockage.

Remarque

• Avant de continuer, veillez à vous familiariser avec le processus de migration et autres considérations.
• Vous pouvez également suivre ces étapes pour modifier les zones d’un cluster existant qui utilise des zones de disponibilité.

Cet article porte sur les points suivants :

• Comment configurer votre cluster pour prendre en charge les zones de disponibilité
• L’architecture des clusters avec zones de disponibilité
• Le processus de migration et autres considérations

Prérequis

• Vérifiez que votre cluster se trouve dans une région où plusieurs zones de disponibilité sont prises en charge.

• Pour migrer un cluster pour prendre en charge les zones de disponibilité, vous avez besoin d’un cluster déployé sans prise en charge des zones de disponibilité.

• Pour modifier les zones d’un cluster, vous avez besoin d’un cluster configuré avec des zones de disponibilité.

• Pour l’API REST, familiarisez-vous avec Manage Azure ressources à l’aide de l’API REST.

• Pour découvrir d’autres méthodes programmatiques, consultez Conditions préalables.

Obtenir la liste des zones de disponibilité pour la région de votre cluster

Vous pouvez obtenir une liste des zones de disponibilité pour votre cluster de différentes manières :

Azure

1. Dans le portail Azure, accédez à la page Overview de votre cluster.

2. Sous Paramètres, sélectionnez Scale-up.

3. Dans la ligne de votre cluster, les zones de disponibilité sont répertoriées dans la colonne Zones de disponibilité.

   

PowerShell

Avant de commencer, assurez-vous d’avoir les cmdlets az.Kusto installés et connectés, puis exécutez la commande suivante pour obtenir la liste des zones de disponibilité pour la région de votre cluster :

1. Définissez l’ID de ressource de votre cluster. Vous pouvez obtenir l'ID de ressource de votre cluster à partir du portail Azure à partir de la page Properties de votre cluster.

   $resource_id = "<ClusterResourceID>"
   

2. Obtenez les détails de votre cluster.

   $mycluster = Get-AzKustoCluster -InputObject $resource_id
   

3. Obtenez l’emplacement de votre cluster.

   Important

   Get-AzLocation nécessite le module Az.Resources. S’il n’est pas installé, exécutez Install-Module Az.Resources.

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

4. Obtenez l’ID de votre cluster.

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

5. Obtenez la liste des zones de disponibilité pour la région de votre 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
   

Configurer votre cluster pour prendre en charge les zones de disponibilité

Pour ajouter des zones de disponibilité à un cluster existant, vous devez mettre à jour l’attribut zones du cluster avec une liste des zones de disponibilité cibles. Suivez les instructions pour votre méthode préférée, à l’aide des informations contenues dans le tableau suivant :

Paramètre	Valeur
subscriptionId	L’ID d’abonnement du cluster
resourceGroupName	Le nom du groupe de ressources du cluster
clusterName	Le nom du cluster
apiVersion	2023-05-02 ou version ultérieure

REST API

Suivez les instructions sur le déploiement d’un modèle.

1. Effectuez l’appel d’API REST au point de terminaison suivant en remplaçant les paramètres par vos valeurs :

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

2. Spécifiez vos zones de disponibilité dans le corps de la demande. Par exemple, pour configurer le cluster pour utiliser les zones de disponibilité 1, 2 et 3, définissez le corps comme suit :

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

C#

1. Si vous n'avez pas les bibliothèques Azure.Identity et Azure.ResourceManager.Kusto installées, utilisez les commandes suivantes pour les installer :

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

2. Dans votre application, ajoutez le code suivant :

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

   Par exemple, pour définir vos zones sur 1, 2 et 3, dans la région Europe Nord, utilisez le code suivant :

   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. Exécutez votre application.

Python

1. Dans votre application, ajoutez le code suivant :

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

   Par exemple, pour définir vos zones sur 1, 2 et 3, dans la région Europe Nord, utilisez le code suivant :

   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. Exécutez votre application.

PowerShell

Vous pouvez utiliser la commande PowerShell suivante pour configurer votre cluster pour utiliser des zones de disponibilité. Vérifiez que les bibliothèques d’outils Kusto sont installées et remplacez les paramètres par vos valeurs.

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

Modèle ARM

1. Dans votre modèle ARM, ajoutez la propriété suivante à la ressource Microsoft.Kusto/clusters :

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

   Par exemple, pour définir vos zones sur 1, 2 et 3, dans la région Europe Nord, utilisez le modèle suivant :

   {
     "$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. Déployer le modèle ARM. Pour plus d’informations, consultez Déployer des ressources avec des modèles ARM et Azure CLI.

Pendant la migration, le message suivant s'affiche dans le portail Azure, dans la page de vue d'ensemble du cluster. Le message est supprimé une fois la migration terminée.

Le changement de zonalité pour le stockage de ce cluster est en cours. L’heure de mise à jour peut varier en fonction de la quantité de données.

Architecture des clusters avec zones de disponibilité

Lorsque les zones de disponibilité sont configurées, les ressources d’un cluster sont déployées comme suit :

• couche Compute : Azure Data Explorer est une plateforme informatique distribuée qui a deux nœuds ou plus. Si les zones de disponibilité sont configurées, les nœuds de calcul sont répartis entre les zones de disponibilité définies pour une résilience intrarégion maximale. Une défaillance de zone peut dégrader les performances du cluster jusqu’à ce que les ressources de calcul ayant échoué soient redéployées dans les zones survivantes. Nous vous recommandons de configurer les zones disponibles maximales dans une région.

  Remarque

  • Dans certains cas, en raison des limitations de capacité de calcul, seules les zones de disponibilité partielles seront disponibles pour la couche de calcul.
  • La couche de calcul d’un cluster implémente une approche optimale pour répartir uniformément les instances entre les zones sélectionnées.

• couche de stockage Persistent : les clusters utilisent stockage Azure comme couche de persistance durable. Si les zones de disponibilité sont configurées, ZRS est activé, plaçant trois réplicas de stockage sur plusieurs zones de disponibilité pour une résilience intrarégion maximale.

  Remarque

  • ZRS entraîne un coût supplémentaire.
  • Lorsque les zones de disponibilité ne sont pas configurées, les ressources de stockage sont déployées avec le paramètre par défaut Stockage localement redondant (LRS), en plaçant les 3 réplicas dans une seule zone.

Processus de migration

Lorsqu’un cluster existant déployé sans zones de disponibilité est configuré pour prendre en charge les zones de disponibilité, les étapes suivantes font partie du processus de migration :

• Le calcul est distribué dans les zones de disponibilité définies

  Le processus de redistribution des ressources de calcul implique une phase de préparation dans laquelle le cache des ressources de calcul zonales est réchauffé. Pendant la phase de préparation, les ressources de calcul du cluster existant continuent de fonctionner, ce qui garantit un service ininterrompu. Cette phase de préparation peut prendre plusieurs dizaines de minutes. La transition vers les nouvelles ressources de calcul ne se produit qu’une fois qu’elle est entièrement préparée et opérationnelle. Cette approche de traitement parallèle garantit une expérience relativement fluide, avec seulement une interruption de service minimale pendant le processus de basculement, qui dure généralement d’une à trois minutes. Toutefois, il est important de noter que les performances des requêtes peuvent être affectées pendant la migration de la référence SKU. Le degré d’impact peut varier en fonction des modèles d’utilisation spécifiques.

• Les données de stockage persistantes historiques sont migrées vers ZRS

  Le processus de migration dépend de la prise en charge régionale de la transition du stockage LRS vers le stockage ZRS, ainsi que de la capacité des comptes de stockage disponible dans les zones sélectionnées. Le processus de transfert de données historiques peut être fastidieux, pouvant prendre plusieurs heures ou même s’étendre sur plusieurs semaines.

• Toutes les nouvelles données sont écrites dans ZRS

  Une fois la demande de migration vers les zones de disponibilité lancée, toutes les nouvelles données sont répliquées et stockées dans la configuration ZRS.

  Remarque

  • Après la demande de migration, il peut y avoir un délai allant jusqu’à plusieurs minutes avant que toutes les nouvelles données ne commencent à être écrites dans la configuration ZRS.
  • Si un cluster a une ingestion en continu, le recyclage des données à écrire en ZRS peut prendre jusqu'à 30 jours.

• État de la zone mis à jour

  Une fois la demande de migration effectuée vers les zones de disponibilité, l’état de la zone est mis à jour pour refléter les zones prises en charge. Si l’état de la zone est Incohérence zonale, il indique que certaines ressources de calcul ou de stockage n’ont pas pu migrer et ne sont pas zonales. Cela se produit généralement lorsqu’il n’y a pas suffisamment de capacité zonale disponible pour certains types de ressources. Dans ce cas, nous vous recommandons de réessayer la migration ultérieurement lorsque la capacité est disponible.

Considérations

La demande de migration vers des zones de disponibilité peut ne pas réussir en raison de contraintes de capacité. Pour une migration réussie, il doit y avoir suffisamment de capacité de calcul et de stockage pour prendre en charge la migration. S’il existe des limitations de capacité, vous obtenez un message d’erreur indiquant le problème.

Contenu connexe

• Vue d’ensemble de la continuité d'activité et de la reprise d'activité