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

Molte aree Azure forniscono zone di disponibilità, che sono 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 sufficientemente distanti per ridurre la probabilità che interruzioni locali o meteo influiscano su più zone di disponibilità. Ogni zona di disponibilità ha potenza, raffreddamento e infrastruttura di rete indipendenti. Sono progettati in modo che se si verifica un'interruzione di una zona, le zone rimanenti supportano servizi, capacità e disponibilità elevata a livello di area. Per altre informazioni, vedere Azure zone di disponibilità.

È possibile configurare Esplora dati di Azure cluster per usare le 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
ARM template

Importante

Dopo aver configurato un cluster con zone di disponibilità, non è possibile modificare il cluster in modo da non usare le zone di disponibilità.
Non tutte le aree supportano più zone. Pertanto, non è possibile configurare cluster in queste aree per usare le zone di disponibilità.
L'uso delle zone di disponibilità comporta costi aggiuntivi per l'archiviazione.

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 trovi in un'area in cui sono supportate più zone di disponibilità.
Per eseguire la migrazione di un cluster per supportare le zone di disponibilità, è necessario un cluster distribuito senza supporto per la zona 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 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 Azure
PowerShell

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

Prima di iniziare, assicurati di aver installato i cmdlet az.Kusto e di aver effettuato l'accesso. Eseguire quindi il comando seguente per ottenere 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 dal portale di Azure nella 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, 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 si dispone delle librerie Azure.Identity e Azure.ResourceManager.Kusto installate, usare i comandi seguenti per installarle.
```
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 ARM, aggiungere la proprietà seguente alla risorsa Microsoft.Kusto/clusters:

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

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, vedere Distribuire risorse con i modelli ARM e interfaccia della riga di comando di Azure.

Durante la migrazione, nella pagina di panoramica del cluster viene visualizzato il messaggio seguente nel 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 si configurano le zone di disponibilità, il cluster distribuisce le risorse come indicato di seguito:

Livello di elaborazione: Esplora dati di Azure è una piattaforma di elaborazione distribuita con due o più nodi. Se si configurano le zone di disponibilità, il cluster distribuisce i nodi di calcolo tra le zone di disponibilità definite 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. Configura il numero massimo di zone disponibili in una regione.
Nota
- In alcuni casi, a causa delle limitazioni della capacità di calcolo, sono disponibili solo zone di disponibilità parziali per il livello di calcolo.
- Il livello di calcolo di un cluster usa un approccio ottimale per distribuire uniformemente le istanze tra le zone selezionate.
Livello di archiviazione permanente: i cluster usano Archiviazione di Azure come livello di persistenza durevole. Se si configurano le zone di disponibilità, il cluster abilita ZRS, collocando tre repliche di archiviazione in più zone di disponibilità per la massima resilienza all'interno dell'area geografica.
Nota
- ZRS comporta un costo aggiuntivo.
- Quando non si configurano le zone di disponibilità, le risorse di archiviazione usano l'impostazione predefinita di Archiviazione con ridondanza locale ,inserendo tutte e tre le repliche in una singola zona.

Processo di migrazione e considerazioni

Quando si configura un cluster esistente distribuito senza zone di disponibilità per supportare le zone di disponibilità, il processo di migrazione esegue i passaggi seguenti:

Distribuisce le risorse di calcolo tra le 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 dopo che sono completamente preparate e operative. 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, 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.
Esegue la migrazione dei dati di archiviazione persistenti cronologici a ZRS

Il processo di migrazione dipende dal supporto regionale per la transizione dall'archiviazione con ridondanza locale (LRS) all'archiviazione con ridondanza della zona (ZRS) e dalla capacità disponibile degli account di archiviazione 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.
Scrive tutti i nuovi dati in ZRS

Dopo aver avviato la richiesta di migrazione verso le zone di disponibilità, il sistema replica e memorizza tutti i nuovi dati 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 usa l'acquisizione in streaming, il passaggio dei nuovi dati da scrivere come dati ZRS può richiedere fino a 30 giorni.
Aggiorna lo stato della zona

Una volta completata la richiesta di migrazione alle zone di disponibilità, il sistema aggiorna lo stato della zona 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. Questa condizione si verifica in genere quando è disponibile capacità di zona insufficiente per alcune risorse. In questi casi, riprovare a eseguire la migrazione in un secondo momento quando la capacità è disponibile.

Considerazioni sulla migrazione

I vincoli di capacità potrebbero impedire una richiesta di migrazione riuscita. Per una migrazione corretta, la capacità di calcolo e archiviazione sufficiente deve supportare la migrazione. Se esistono limitazioni della capacità, viene visualizzato un messaggio di errore che indica il problema.

Continuità aziendale e panoramica di ripristino di emergenza

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-06-21