Eseguire la migrazione del cluster per supportare più zone di disponibilità (anteprima)

Articolo
2025-04-21

Molte aree di Azure forniscono zone di disponibilità, ovvero gruppi separati di data center all'interno di un'area. Le zone di disponibilità sono abbastanza vicine da avere connessioni a bassa latenza con altre zone di disponibilità. Sono connessi da una rete ad alte prestazioni con una latenza di round trip inferiore a 2 ms. Tuttavia, le zone di disponibilità sono abbastanza distanti per ridurre la probabilità che più di una sarà influenzata da interruzioni locali o meteo. Le zone di disponibilità hanno potenza, raffreddamento e infrastruttura di rete indipendenti. Sono progettati in modo che se si verifica un'interruzione di una zona, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle zone rimanenti. Per altre informazioni, vedere Azure zone di disponibilità.

I cluster Esplora dati di Azure possono essere configurati per l'uso delle zone di disponibilità nelle aree supportate. Usando le zone di disponibilità, un cluster può resistere meglio all'errore di un singolo data center in un'area per supportare gli scenari di continuità aziendale.

È possibile configurare le zone di disponibilità quando si crea un cluster nel portale di Azure o a livello di codice usando uno dei metodi seguenti:

REST API (Interfaccia di Programmazione delle Applicazioni REST)
SDK per C#
Python SDK
PowerShell
Modello ARM

Importante

Dopo aver configurato un cluster con le zone di disponibilità, non è possibile modificare il cluster in modo da non usare le zone di disponibilità.
In alcune regioni, non sono supportate più zone. Di conseguenza, i cluster che si trovano in queste aree non possono essere configurati per l'uso delle zone di disponibilità.
L'uso delle zone di disponibilità comporta costi aggiuntivi.

Nota

Prima di procedere, assicurarsi di avere familiarità con il processo di migrazione e le considerazioni.
È anche possibile usare questi passaggi per modificare le zone di un cluster esistente che usa le zone di disponibilità.

Questo articolo contiene informazioni relative agli argomenti seguenti:

Come configurare il cluster per supportare le zone di disponibilità
Architettura dei cluster con zone di disponibilità
Processo di migrazione e considerazioni

Prerequisiti

Assicurarsi che il cluster si trova in un'area in cui è supportata la migrazione a più zone di disponibilità.
Per eseguire la migrazione di un cluster per supportare le zone di disponibilità, è necessario un cluster distribuito senza zone di disponibilità.
Per modificare le zone di un cluster, è necessario un cluster configurato con le zone di disponibilità.
Per l'API REST, acquisire familiarità con Gestire le risorse di Azure usando l'API REST.
Per altri metodi programmatici, vedere Prerequisiti.

Ottenere l'elenco delle zone di disponibilità per l'area del cluster

È possibile ottenere un elenco di zone di disponibilità per il cluster nei modi seguenti:

Portale di Azure
PowerShell

Nel portale di Azure, passare alla pagina Panoramica del tuo cluster.
In Impostazioni selezionare Aumenta prestazioni.
Nella riga del cluster, le zone di disponibilità sono elencate nella colonna Zone di disponibilità.

Prima di iniziare, assicurarsi di avere i cmdlet az.Kusto installati e connesso, e quindi eseguire il comando seguente per visualizzare l'elenco delle zone di disponibilità per l'area del cluster:

Imposta l'ID risorsa del tuo cluster. È possibile ottenere l'ID risorsa del cluster dall'portale di Azure dalla pagina Proprietà del cluster.
```
$resource_id = "<ClusterResourceID>"
```

Ottieni i dettagli del tuo cluster.

$mycluster = Get-AzKustoCluster -InputObject $resource_id

Ottieni la posizione del tuo cluster.

Importante

Get-AzLocation richiede il Az.Resources modulo . Se non è installato, eseguire Install-Module Az.Resources.
```
$location = (Get-AzLocation | where DisplayName -EQ $mycluster.Location).location
```

Ottenere l'ID del cluster.

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

Ottenere l'elenco delle zone di disponibilità per l'area del 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

Configurare il cluster per supportare le zone di disponibilità

Per aggiungere zone di disponibilità a un cluster esistente, è necessario aggiornare l'attributo del cluster zones con un elenco delle zone di disponibilità di destinazione. Seguire le istruzioni per il metodo preferito, usando le informazioni nella tabella seguente:

Parametro	Valore
`subscriptionId`	ID di sottoscrizione del cluster
`resourceGroupName`	Nome del gruppo di risorse del cluster
`clusterName`	Nome del cluster
`apiVersion`	`2023-05-02` o versioni successive

Seguire le istruzioni su come distribuire un modello.

Effettua la chiamata all'API REST all'endpoint seguente, sostituendo i parametri con i tuoi valori.

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

Specificare le zone di disponibilità nel corpo della richiesta. Ad esempio, per configurare il cluster in modo che usi le zone di disponibilità 1, 2 e 3, impostare il corpo come indicato di seguito:
```
{ "zones": [ "{zone1}", "{zone2}", "{zone3}" ] }
```

Se non sono installate le librerie Azure.Identity e Azure.ResourceManager.Kusto , usare i comandi seguenti per installarli:
```
dotnet add package Azure.Identity
dotnet add package Azure.ResourceManager.Kusto
```

Nell'applicazione aggiungere il codice seguente:

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

Ad esempio, per impostare le zone su 1, 2 e 3, nell'area Europa settentrionale, usare il codice seguente:

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

Avvia la tua applicazione.

Nell'applicazione aggiungere il codice seguente:

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

Ad esempio, per impostare le zone su 1, 2 e 3, nell'area Europa settentrionale, usare il codice seguente:

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

Avvia la tua applicazione.

È possibile usare il comando di PowerShell seguente per configurare il cluster per l'uso delle zone di disponibilità. Assicurarsi che le librerie degli strumenti Kusto siano installate e sostituire i parametri con i valori.

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

Nel modello di Resource Manager, aggiungi la seguente proprietà alla risorsa Microsoft.Kusto/clusters:

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

Ad esempio, per impostare le zone su 1, 2 e 3, nell'area Europa settentrionale, usare il modello seguente:

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

Distribuire il modello ARM. Per ulteriori informazioni, vedi Distribuire le risorse con i modelli di ARM e l’interfaccia della riga di comando di Azure.

Durante la migrazione, nella pagina di panoramica del cluster viene visualizzato il messaggio seguente nella portale di Azure. Il messaggio viene rimosso al termine della migrazione.

La modifica della zona per l'archiviazione di questo cluster è in corso. L'ora di aggiornamento può variare a seconda della quantità di dati.

Architettura dei cluster con zone di disponibilità

Quando sono configurate le zone di disponibilità, le risorse di un cluster vengono distribuite nel modo seguente:

Livello di calcolo: Azure Esplora dati è una piattaforma di elaborazione distribuita con due o più nodi. Se le zone di disponibilità sono configurate, i nodi di calcolo vengono distribuiti nella zona di disponibilità definita per la resilienza massima all'interno dell'area. Un errore di zona potrebbe compromettere le prestazioni del cluster fino a quando le risorse di calcolo non riuscite non vengono ridistribuite nelle zone sopravvissute. È consigliabile configurare le zone massime disponibili in un'area.
Nota
- In alcuni casi, a causa delle limitazioni della capacità di calcolo, solo le zone di disponibilità parziali saranno disponibili per il livello di calcolo.
- Il livello di calcolo di un cluster implementa un approccio ottimale per distribuire uniformemente le istanze tra le zone selezionate.
Livello di archiviazione persistente: i cluster usano Azure Storage come strato di persistenza durevole. Se le zone di disponibilità sono configurate, Zona di Ridondanza d'Archiviazione (ZRS) è abilitata, distribuendo le repliche di archiviazione in tutte e tre le zone di disponibilità per la massima resilienza all'interno della regione.
Nota
- ZRS comporta un costo aggiuntivo.
- Quando le zone di disponibilità non sono configurate, le risorse di archiviazione sono distribuite utilizzando l'impostazione predefinita di Archiviazione con Ridondanza Locale (LRS), collocando tutte e 3 le repliche in una singola zona.

Processo di migrazione

Quando un cluster esistente distribuito senza zone di disponibilità è configurato per supportare le zone di disponibilità, i passaggi seguenti vengono distribuiti come parte del processo di migrazione:

Il calcolo viene distribuito nelle zone di disponibilità definite

Il processo di ridistribuzione delle risorse di calcolo prevede una fase di preparazione in cui viene riscaldata la cache delle risorse di calcolo di zona. Durante la fase di preparazione, le risorse di calcolo del cluster esistenti continuano a funzionare, garantendo un servizio ininterrotto. Questa fase di preparazione può richiedere fino a decine di minuti. La transizione alle nuove risorse di calcolo avviene solo una volta che è completamente preparata e operativa. Questo approccio di elaborazione parallela garantisce un'esperienza relativamente semplice, con un'interruzione minima del servizio durante il processo di cambio, in genere dura da uno a tre minuti. Tuttavia, è importante notare che le prestazioni delle query potrebbero essere influenzate durante la migrazione dello SKU. Il grado di impatto può variare a seconda di modelli di utilizzo specifici.
I dati di archiviazione persistente cronologica vengono migrati a un'archiviazione con ridondanza della zona (ZRS)

Il processo di migrazione dipende dal supporto a livello di area per la transizione dall'archiviazione con ridondanza locale all'archiviazione con ridondanza della zona e dalla capacità degli account di archiviazione disponibili nelle zone selezionate. Il trasferimento dei dati cronologici può essere un processo dispendioso in termini di tempo, potenzialmente richiedere diverse ore o persino estendersi a settimane.
Tutti i nuovi dati vengono scritti nello ZRS (archiviazione con ridondanza della zona)

Dopo l'avvio della richiesta di migrazione alle zone di disponibilità, tutti i nuovi dati vengono replicati e archiviati nella configurazione ZRS.
Nota
- Dopo la richiesta di migrazione, potrebbe verificarsi un ritardo fino a diversi minuti prima che inizi la scrittura di tutti i nuovi dati nella configurazione ZRS.
- Se un cluster ha l'inserimento in streaming, la trasformazione dei nuovi dati da scrivere come dati ZRS (archiviazione con ridondanza della zona) può richiedere fino a 30 giorni.
Stato della zona aggiornato

Una volta completata la richiesta di migrazione alle zone di disponibilità, lo stato della zona viene aggiornato in modo da riflettere le zone supportate. Se lo stato della zona è Incoerenza zonale, indica che alcune risorse di calcolo o di archiviazione non sono riuscite a eseguire la migrazione e non sono di zona. Ciò si verifica in genere quando è disponibile capacità di zona insufficiente per alcune risorse. In questi casi, è consigliabile ritentare la migrazione in un secondo momento quando la capacità è disponibile.

Considerazioni

La richiesta di migrazione alle zone di disponibilità potrebbe non riuscire a causa di vincoli di capacità. Per una migrazione corretta, per supportare la migrazione è necessario disporre di capacità di calcolo e archiviazione sufficienti. Se sono presenti limitazioni di capacità, verrà visualizzato un messaggio di errore che indica il problema.

Continuità aziendale e panoramica di ripristino di emergenza

Condividi tramite