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é. Ils sont connectés 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é.

Les clusters Azure Data Explorer peuvent être configurés pour utiliser des zones de disponibilité dans les régions prises en charge. En utilisant des zones de disponibilité, un cluster peut 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 par programmation à l’aide de l’une des méthodes suivantes :

• API REST
• Kit de développement logiciel (SDK) C#
• Kit de développement logiciel (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 pas utiliser de zones de disponibilité.
• Plusieurs zones ne sont pas prises en charge 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.

Remarque

• Avant de continuer, veillez à vous familiariser avec le processus de migration et les considérations.
• Vous pouvez également utiliser 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é
• Architecture des clusters avec zones de disponibilité
• Processus de migration et considérations

Prérequis

• Vérifiez que votre cluster se trouve dans une région où la migration vers plusieurs zones de disponibilité est prise en charge. Pour plus d’informations, consultez Régions prises en charge.

• Pour migrer un cluster pour prendre en charge les zones de disponibilité, vous avez besoin d’un cluster qui a été déployé sans aucune zone 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 gérer les ressources Azure à l’aide de l’API REST.

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

Régions prises en charge

La migration vers plusieurs zones de disponibilité est limitée aux régions qui n’ont pas de restrictions de capacité. Les régions suivantes sont actuellement prises en charge :

• Australie Est
• Centre du Canada
• Chine Nord 3
• Inde Centre
• Europe Nord
• Norvège Est
• Afrique du Sud Nord
• Suède Centre
• Émirats arabes unis Nord
• Sud du Royaume-Uni

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

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

Azure portal

1. Dans le Portail Azure, accédez à la page Vue d’ensemble 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 az. Applets de commande Kusto installées et connectées, 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 de la Portail Azure à partir de la page Propriétés 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 Az.Resources module. Si vous ne l’avez 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 de cluster zones avec une liste des zones de disponibilité cibles. Suivez les instructions de votre méthode préférée, à l’aide des informations contenues dans le tableau suivant :

Paramètre	Valeur
subscriptionId	ID d’abonnement du cluster
resourceGroupName	Nom du groupe de ressources du cluster
clusterName	Nom du cluster
apiVersion	2023-05-02 ou ultérieur

Important

La modification des zones de disponibilité d’un cluster existant modifie uniquement les zones de disponibilité pour le calcul. Le stockage persistant n’est pas modifié.

REST API

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

1. Effectuez l’appel de l’API REST au point de terminaison suivant où vous remplacez 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 requête. 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 installé les bibliothèques Azure.Identity et Azure.ResourceManager.Kusto , 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 Microsoft.Kusto/clusters ressource :

   "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 à l’aide de modèles ARM et d’Azure CLI.

Pendant la migration, le message suivant s’affiche dans la 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 de calcul : Azure Data Explorer est une plateforme de calcul 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 la zone de disponibilité définie 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 persistant : les clusters utilisent Stockage Azure comme couche de persistance durable. Si les zones de disponibilité sont configurées, ZRS est activé, plaçant les réplicas de stockage dans les trois zones de disponibilité pour une résilience intra-ré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 de l’Stockage localement redondant (LRS), le placement de tous les 3 réplicas est 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 s’effectuent dans le cadre 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 jusqu’à des 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, 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 disponibles dans les zones sélectionnées. Le transfert de données historiques peut être un processus 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 de streaming, le recyclage des nouvelles données à écrire en tant que données ZRS peut prendre jusqu’à 30 jours.

À propos de l’installation

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é