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 verminderen dat lokale storingen of het weer van invloed zijn op meer dan één beschikbaarheidszone. Elke beschikbaarheidszone heeft onafhankelijke energie-, koelings- en netwerkinfrastructuur. Ze zijn zodanig ontworpen dat als één zone een storing ondervindt, de resterende zones regionale services, capaciteit en hoge beschikbaarheid ondersteunen. Zie Azure Beschikbaarheidszones voor meer informatie.

U kunt Azure Data Explorer clusters configureren 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 de Azure-portal of programmatisch met behulp van een van de volgende methoden:

REST-API
C#SDK
Python SDK
PowerShell
ARM template

Belangrijk

Nadat u een cluster met beschikbaarheidszones hebt geconfigureerd, kunt u het cluster niet wijzigen om geen beschikbaarheidszones te gebruiken.
Niet alle regio's ondersteunen meerdere zones. Daarom kunt u geen clusters in deze regio's instellen om beschikbaarheidszones te gebruiken.
Voor het gebruik van beschikbaarheidszones worden extra kosten in rekening gebracht voor opslag.

Notitie

Zorg ervoor dat u bekend bent met het migratieproces en overwegingen voordat 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 waarin meerdere beschikbaarheidszones worden ondersteund.
Als u een cluster wilt migreren ter ondersteuning van beschikbaarheidszones, hebt u een cluster nodig dat u hebt geïmplementeerd zonder ondersteuning voor beschikbaarheidszones.
Als u de zones van een cluster wilt wijzigen, hebt u een cluster nodig dat is geconfigureerd met beschikbaarheidszones.
Voor REST API moet u vertrouwd raken met Beheer Azure resources 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
PowerShell

Ga in de Azure-portal naar de pagina Overview van uw cluster.
Onder Instellingen, selecteer Schaal op.
In de rij voor uw cluster worden de beschikbaarheidszones weergegeven in de kolom Beschikbaarheidszones .

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

Stel de resource-id van uw cluster in. U kunt de resource-id van uw cluster ophalen via de Azure-portal op de pagina Eigenschappen van uw cluster.
```
$resource_id = "<ClusterResourceID>"
```

Haal de details van uw cluster op.

$mycluster = Get-AzKustoCluster -InputObject $resource_id

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

Haal de ID van uw cluster op.

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

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, werkt u het clusterkenmerk zones bij met een lijst met de doel-beschikbaarheidszones. Volg de instructies voor uw voorkeursmethode met behulp van de informatie in de volgende tabel:

Kenmerk	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
C#
Python
PowerShell
ARM-sjabloon

Volg de instructies voor het implementeren van een sjabloon.

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}

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

Als u de Azure.Identity en Azure.ResourceManager.Kusto bibliotheken niet hebt geïnstalleerd, gebruik dan de volgende opdrachten om ze te installeren.
```
dotnet add package Azure.Identity
dotnet add package Azure.ResourceManager.Kusto
```

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

Voer uw toepassing uit.

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

Voer uw toepassing uit.

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

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

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

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

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

Implementeer de ARM-sjabloon. Zie Deploy-resources met ARM-sjablonen en Azure CLI voor meer informatie.

Tijdens de migratie wordt het volgende bericht weergegeven in de 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 u beschikbaarheidszones configureert, worden resources als volgt door het cluster geïmplementeerd:

Compute layer: Azure Data Explorer is een gedistribueerd computingplatform met twee of meer knooppunten. Als u beschikbaarheidszones configureert, distribueert het cluster rekenknooppunten over de gedefinieerde beschikbaarheidszones voor maximale tolerantie binnen regio's. Een zonefout kan de clusterprestaties verminderen totdat de mislukte rekenresources opnieuw worden geïmplementeerd in de overlevende zones. Configureer de maximaal beschikbare zones in een regio.
Notitie
- In sommige gevallen zijn vanwege beperkingen van de rekencapaciteit alleen gedeeltelijke beschikbaarheidszones beschikbaar voor de rekenlaag.
- De rekenlaag van een cluster maakt gebruik van een best effort-benadering om instanties gelijkmatig over geselecteerde zones te verdelen.
Permanente opslaglaag: clusters gebruiken Azure Storage als hun duurzame persistentielaag. Als u beschikbaarheidszones configureert, schakelt het cluster ZRS in, waardoor drie opslagreplica's in meerdere beschikbaarheidszones worden geplaatst voor maximale tolerantie binnen regio's.
Notitie
- ZRS brengt extra kosten met zich mee.
- Wanneer u geen beschikbaarheidszones configureert, gebruiken opslagresources de standaardinstelling lokaal redundante opslag (LRS), waarbij alle drie de replica's in één zone worden geplaatst.

Migratieproces en overwegingen

Wanneer u een bestaand cluster configureert dat u hebt geïmplementeerd zonder beschikbaarheidszones ter ondersteuning van beschikbaarheidszones, voert het migratieproces de volgende stappen uit:

Distribueert rekenresources over de gedefinieerde beschikbaarheidszones

Het proces voor het opnieuw distribueren van rekenresources omvat een voorbereidingsfase waarin de cache voor zonegebonden rekenresources 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 ze volledig zijn voorbereid en operationeel zijn. Deze parallelle verwerkingsmethode zorgt voor een relatief naadloze ervaring, met slechts minimale serviceonderbreking tijdens het overschakelingsproces, meestal tussen één tot drie minuten. Queryprestaties kunnen echter worden beïnvloed tijdens de SKU-migratie. De mate van impact kan variëren, afhankelijk van specifieke gebruikspatronen.
Hiermee worden historische permanente opslaggegevens gemigreerd naar ZRS

Het migratieproces is afhankelijk van regionale ondersteuning voor de overgang van LRS naar ZRS-opslag en de beschikbare capaciteit voor 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.
Schrijft alle nieuwe gegevens naar ZRS

Nadat u de aanvraag voor migratie naar beschikbaarheidszones hebt gestart, repliceert en slaat het systeem alle nieuwe gegevens op 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 streaming-opname heeft, kan het tot 30 dagen duren voordat nieuwe gegevens opnieuw worden verwerkt zodat ze als ZRS-gegevens worden weggeschreven.
Status van zone bijwerken

Zodra de migratieaanvraag naar beschikbaarheidszones is voltooid, werkt het systeem de zonestatus bij zodat deze overeenkomt met de ondersteunde zones. Als de zonestatus zonegebonden inconsistentie is, geeft dit aan dat sommige reken- of opslagresources niet kunnen worden gemigreerd en niet zonegebonden zijn. Deze voorwaarde treedt over het algemeen op wanneer er onvoldoende zonegebonden capaciteit beschikbaar is voor sommige resources. In dergelijke gevallen voert u de migratie later opnieuw uit wanneer de capaciteit beschikbaar is.

Overwegingen bij migratie

Capaciteitsbeperkingen kunnen een geslaagde migratieaanvraag voorkomen. Voor een geslaagde migratie moeten voldoende reken- en opslagcapaciteit de migratie ondersteunen. Als er capaciteitsbeperkingen bestaan, wordt er een foutbericht weergegeven waarin het probleem wordt aangegeven.

Overzicht van bedrijfscontinuïteit en rampenherstel

Feedback

Is deze pagina nuttig?

Last updated on 2026-06-21