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 les pannes locales ou les conditions météorologiques affectent plusieurs zones de disponibilité. Chaque zone de disponibilité dispose d’une alimentation, d’un refroidissement et d’une infrastructure réseau indépendantes. Elles sont conçues afin que si une zone subit une panne, les zones restantes prennent en charge les services régionaux, la capacité et la haute disponibilité. Pour plus d’informations, consultez Azure Zones de disponibilité.

Vous pouvez configurer Azure Data Explorer clusters 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 par programmation à l’aide de l’une des méthodes suivantes :

API REST
Kit de développement logiciel (SDK) C#
SDK Python
PowerShell
ARM template

Important

Après avoir configuré un cluster avec des zones de disponibilité, vous ne pouvez pas modifier le cluster pour ne pas utiliser de zones de disponibilité.
Toutes les régions ne prennent pas en charge plusieurs zones. Par conséquent, vous ne pouvez pas configurer de clusters dans ces régions 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, assurez-vous que vous êtes familiarisé avec le processus de migration et les 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 que vous avez 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 :

portail Azure
PowerShell

Dans le portail Azure, accédez à la page Overview de votre cluster.
Sous Paramètres, sélectionnez Scale-up.
Dans la ligne de votre cluster, les zones de disponibilité apparaissent dans la colonne Zones de disponibilité .

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

Définissez l’ID de ressource de votre cluster. Vous pouvez obtenir l'ID de ressource de votre cluster à partir du portail Azure sur la page Propriétés de votre cluster.
```
$resource_id = "<ClusterResourceID>"
```

Obtenez les détails de votre cluster.

$mycluster = Get-AzKustoCluster -InputObject $resource_id

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
```

Obtenez l’ID de votre cluster.

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

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, mettez à jour l’attribut de cluster zones 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 toute version ultérieure

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

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}

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}" ] }
```

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
```

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);
}

Exécutez votre application.

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}")

Exécutez votre application.

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}"

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

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

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"
          }
      }
  ]
}

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 vous configurez des zones de disponibilité, le cluster déploie des ressources comme suit :

couche Compute : Azure Data Explorer est une plateforme informatique distribuée qui a deux nœuds ou plus. Si vous configurez des zones de disponibilité, le cluster distribue les nœuds de calcul 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. Configurez 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 sont disponibles pour la couche de calcul.
- La couche de calcul d’un cluster utilise 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 vous configurez des zones de disponibilité, le cluster active ZRS, ce qui place trois réplicas de stockage dans plusieurs zones de disponibilité pour une résilience maximale au sein de la région.
Remarque
- ZRS entraîne un coût supplémentaire.
- Lorsque vous ne configurez pas de zones de disponibilité, les ressources de stockage utilisent le paramètre par défaut du stockage localement redondant (LRS), en plaçant les trois réplicas dans une seule zone.

Processus de migration et considérations

Lorsque vous configurez un cluster existant que vous avez déployé sans zones de disponibilité pour prendre en charge les zones de disponibilité, le processus de migration effectue les étapes suivantes :

Distribue les ressources de calcul entre 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’elles sont entièrement préparées et opérationnelles. 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, 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.
Migre les données de stockage persistantes historiques 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 et de la capacité des comptes de stockage disponibles 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.
Écrit toutes les nouvelles données dans ZRS

Après avoir lancé la demande de migration vers des zones de disponibilité, le système réplique et stocke toutes les nouvelles donné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.
Mise à jour de l’état de la zone

Une fois la demande de migration effectuée vers les zones de disponibilité, le système met à jour l’état de la zone 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. Cette condition se produit généralement lorsqu’il y a une capacité zonale insuffisante disponible pour certaines ressources. Dans ce cas, réessayez la migration ultérieurement lorsque la capacité est disponible.

Considérations relatives à la migration

Les contraintes de capacité peuvent empêcher une demande de migration réussie. Pour une migration réussie, une capacité de calcul et de stockage suffisante doit prendre en charge la migration. Si des limitations de capacité existent, vous recevez un message d’erreur indiquant le problème.

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

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-06-21