Uw cluster migreren om ondersteuning te bieden voor meerdere beschikbaarheidszones (preview)

Veel Azure-regio's bieden beschikbaarheidszones, die gescheiden groepen datacenters binnen een regio zijn. Beschikbaarheidszones zijn dicht genoeg om verbindingen met lage latentie met andere beschikbaarheidszones te hebben. Ze zijn verbonden door een netwerk met hoge prestaties met een retourlatentie van minder dan 2 ms. Beschikbaarheidszones zijn echter ver genoeg uit elkaar om de kans te verkleinen dat meer dan één wordt beïnvloed door lokale storingen of het weer. Beschikbaarheidszones hebben onafhankelijke energie-, koelings- en netwerkinfrastructuur. Ze zijn zodanig ontworpen dat als één zone een storing ondervindt, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende zones. Zie Azure-beschikbaarheidszonesvoor meer informatie.

Azure Data Explorer-clusters kunnen worden geconfigureerd voor het gebruik van beschikbaarheidszones in ondersteunde regio's. Door beschikbaarheidszones te gebruiken, kan een cluster beter bestand zijn tegen het mislukken van één datacenter in een regio ter ondersteuning van bedrijfscontinuïteit scenario's.

U kunt beschikbaarheidszones configureren bij het maken van een cluster in Azure Portal of programmatisch met behulp van een van de volgende methoden:

• REST API
• C#SDK
• Python SDK
• PowerShell
• ARM-sjabloon

Belangrijk

• Zodra een cluster is geconfigureerd met beschikbaarheidszones, kunt u het cluster niet wijzigen om geen beschikbaarheidszones te gebruiken.
• In alle regio's worden meerdere zones niet ondersteund. Clusters in deze regio's kunnen daarom niet worden ingesteld voor het gebruik van beschikbaarheidszones.
• Voor het gebruik van beschikbaarheidszones worden extra kosten in rekening gebracht.

Notitie

• Zorg ervoor dat u bekend bent met het migratieproces en overwegingenvoordat u verdergaat.
• U kunt deze stappen ook gebruiken om de zones van een bestaand cluster te wijzigen dat gebruikmaakt van beschikbaarheidszones.

In dit artikel krijgt u meer informatie over:

• Uw cluster configureren ter ondersteuning van beschikbaarheidszones
• De -architectuur van clusters met beschikbaarheidszones
• Het migratieproces en overwegingen

Voorwaarden

• Zorg ervoor dat uw cluster zich in een regio bevindt waar migratie naar meerdere beschikbaarheidszones wordt ondersteund.

• Voor het migreren van een cluster ter ondersteuning van beschikbaarheidszones hebt u een cluster nodig dat zonder beschikbaarheidszones is geïmplementeerd.

• Voor het wijzigen van de zones van een cluster hebt u een cluster nodig dat is geconfigureerd met beschikbaarheidszones.

• Voor REST API moet u vertrouwd raken met Azure-resources beheren met behulp van de REST API-.

• Zie Vereistenvoor andere programmeerbare methoden.

De lijst met beschikbaarheidszones voor de regio van uw cluster ophalen

U kunt op de volgende manieren een lijst met beschikbaarheidszones voor uw cluster ophalen:

Azure Portal

1. Ga in de Azure-portal naar de pagina Overzicht van uw cluster.

2. Onder Instellingen, selecteer Schaal op.

3. In de rij voor uw cluster worden de beschikbaarheidszones weergegeven in de kolom Beschikbaarheidszones.

   

PowerShell

Voordat u begint, moet u ervoor zorgen dat u az.Kusto cmdlets hebt geïnstalleerd en bent aangemeld, en voer vervolgens de volgende opdracht uit om de lijst met beschikbaarheidszones voor de regio van uw cluster op te halen:

1. Stel de resource-id van uw cluster in. U kunt de resource-ID van uw cluster verkrijgen via de Azure-portal op de pagina Eigenschappen van uw cluster.

   $resource_id = "<ClusterResourceID>"
   

2. Haal de details van uw cluster op.

   $mycluster = Get-AzKustoCluster -InputObject $resource_id
   

3. Haal de locatie van uw cluster op.

   Belangrijk

   Get-AzLocation vereist het module Az.Resources. Als u deze niet hebt geïnstalleerd, voert u Install-Module Az.Resourcesuit.

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

4. Haal de ID van uw cluster op.

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

5. Haal de lijst met beschikbaarheidszones voor de regio van uw cluster op.

   $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
   

Uw cluster configureren ter ondersteuning van beschikbaarheidszones

Als u beschikbaarheidszones wilt toevoegen aan een bestaand cluster, moet u het kenmerk zones cluster bijwerken met een lijst met de doel beschikbaarheidszones. Volg de instructies voor uw voorkeursmethode met behulp van de informatie in de volgende tabel:

Parameter	Waarde
subscriptionId	De abonnements-id van het cluster
resourceGroupName	De naam van de resourcegroep van het cluster
clusterName	De naam van het cluster
apiVersion	2023-05-02 of hoger

REST API

Volg de instructies voor het implementeren van een sjabloon.

1. Breng de REST API-aanroep naar het volgende eindpunt waar u de parameters vervangt door uw waarden:

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

2. Geef uw beschikbaarheidszones op in de aanvraagbody. Als u bijvoorbeeld het cluster wilt configureren voor het gebruik van beschikbaarheidszones 1, 2 en 3, stelt u de hoofdtekst als volgt in:

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

C#

1. Als u de Azure.Identity- en Azure.ResourceManager.Kusto-bibliotheken niet hebt geïnstalleerd, gebruikt u de volgende opdrachten om ze te installeren:

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

2. Voeg in uw toepassing de volgende code toe:

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

   Als u bijvoorbeeld uw zones wilt instellen op 1, 2 en 3, gebruikt u de volgende code in de regio Europa - noord:

   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. Voer uw toepassing uit.

Python

1. Voeg in uw toepassing de volgende code toe:

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

   Als u bijvoorbeeld uw zones wilt instellen op 1, 2 en 3, gebruikt u de volgende code in de regio Europa - noord:

   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. Voer uw toepassing uit.

PowerShell

U kunt de volgende PowerShell-opdracht gebruiken om uw cluster te configureren voor het gebruik van beschikbaarheidszones. Zorg ervoor dat de Kusto-hulpprogrammabibliotheken zijn geïnstalleerd en vervang de parameters door uw waarden.

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

1. Voeg in uw ARM-sjabloon de volgende eigenschap toe aan de Microsoft.Kusto/clusters-resource:

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

   Als u bijvoorbeeld uw zones wilt instellen op 1, 2 en 3, gebruikt u de volgende sjabloon in de regio Europa - noord:

   {
     "$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. Implementeer de ARM-sjabloon. Zie Resources implementeren met ARM-sjablonen en Azure CLIvoor meer informatie.

Tijdens de migratie wordt het volgende bericht weergegeven in Azure Portal, op de overzichtspagina van het cluster. Het bericht wordt verwijderd nadat de migratie is voltooid.

De wijziging van de zonering voor de opslag van dit cluster is aan de gang. De updatetijd kan variëren, afhankelijk van de hoeveelheid gegevens.

Architectuur van clusters met beschikbaarheidszones

Wanneer beschikbaarheidszones zijn geconfigureerd, worden de resources van een cluster als volgt geïmplementeerd:

• Compute-laag: Azure Data Explorer is een gedistribueerd computingplatform met twee of meer knooppunten. Als beschikbaarheidszones zijn geconfigureerd, worden rekenknooppunten verdeeld over de gedefinieerde beschikbaarheidszone voor maximale tolerantie binnen regio's. Een zonefout kan de clusterprestaties verminderen totdat de mislukte rekenresources opnieuw worden geïmplementeerd in de overlevende zones. We raden u aan om de maximaal beschikbare zones in een regio te configureren.

  Notitie

  • In sommige gevallen zijn vanwege beperkingen van de rekencapaciteit alleen gedeeltelijke beschikbaarheidszones beschikbaar voor de rekenlaag.
  • De rekenlaag van een cluster implementeert een best effort-benadering om instanties gelijkmatig over geselecteerde zones te verdelen.

• permanente opslaglaag: clusters maken gebruik van Azure Storage als duurzame persistentielaag. Als beschikbaarheidszones zijn geconfigureerd, wordt ZRS ingeschakeld, waardoor opslagreplica's over alle drie de beschikbaarheidszones worden verspreid voor maximale veerkracht binnen de regio.

  Notitie

  • Voor ZRS worden extra kosten in rekening gebracht.
  • Wanneer beschikbaarheidszones niet zijn geconfigureerd, worden opslagresources geïmplementeerd met de standaardinstelling van Lokaal redundante opslag (LRS), waarbij alle drie replica's één zone zijn.

Migratieproces

Wanneer een bestaand cluster dat is geïmplementeerd zonder beschikbaarheidszones is geconfigureerd ter ondersteuning van beschikbaarheidszones, worden de volgende stappen uitgevoerd als onderdeel van het migratieproces:

• Compute wordt gedistribueerd in de gedefinieerde beschikbaarheidszones

  Het proces voor het opnieuw distribueren van rekenresources omvat een voorbereidingsfase waarin de zonegebonden rekenresourcescache wordt opgewarmd. Tijdens de voorbereidingsfase blijven de rekenresources van het bestaande cluster functioneren, waardoor een ononderbroken service wordt gegarandeerd. Deze voorbereidingsfase kan tot tientallen minuten duren. De overgang naar de nieuwe rekenresources vindt alleen plaats zodra deze volledig is voorbereid en operationeel is. Deze parallelle verwerkingsmethode zorgt voor een relatief naadloze ervaring, met slechts minimale serviceonderbreking tijdens het overschakelingsproces, meestal tussen één tot drie minuten. Het is echter belangrijk om te weten dat de queryprestaties mogelijk worden beïnvloed tijdens de SKU-migratie. De mate van impact kan variëren, afhankelijk van specifieke gebruikspatronen.

• Historische permanente opslaggegevens worden gemigreerd naar ZRS

  Het migratieproces is afhankelijk van de regionale ondersteuning voor de overgang van LRS naar ZRS-opslag, evenals de beschikbare capaciteit van opslagaccounts in de geselecteerde zones. De overdracht van historische gegevens kan een tijdrovend proces zijn, mogelijk enkele uren duren of zelfs langer duren tot weken.

• Alle nieuwe gegevens worden naar ZRS geschreven

  Nadat de aanvraag voor migratie naar beschikbaarheidszones is gestart, worden alle nieuwe gegevens gerepliceerd en opgeslagen in de ZRS-configuratie.

  Notitie

  • Na de migratieaanvraag kan er een vertraging van maximaal enkele minuten optreden voordat alle nieuwe gegevens in de ZRS-configuratie worden geschreven.
  • Als een cluster streamingopname heeft, kan het recyclen van nieuwe gegevens die als ZRS-gegevens worden geschreven, tot 30 dagen duren.

Overwegingen

De aanvraag voor migratie naar beschikbaarheidszones is mogelijk niet geslaagd vanwege capaciteitsbeperkingen. Voor een geslaagde migratie moet er voldoende reken- en opslagcapaciteit zijn om de migratie te ondersteunen. Als er capaciteitsbeperkingen zijn, wordt er een foutbericht weergegeven waarin het probleem wordt aangegeven.

Verwante inhoud

• Overzicht van bedrijfscontinuïteit en rampenherstel