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

Articolo
04/30/2024

Molte aree di Azure forniscono zone di disponibilità, ovvero gruppi separati di data center all'interno di un'area. Le zone di disponibilità sono sufficienti per avere connessioni a bassa latenza ad 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
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à.
Più zone non sono supportate in tutte le aree. 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:

Azure portal
PowerShell

Nella portale di Azure passare alla pagina Panoramica del 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 az. I cmdlet Kusto installati e connessi e quindi eseguire il comando seguente per ottenere l'elenco delle zone di disponibilità per l'area del cluster:

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

Ottenere i dettagli del cluster.

$mycluster = Get-AzKustoCluster -InputObject $resource_id

Ottenere la posizione del 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 sottoscrizione del cluster
`resourceGroupName`	Nome del gruppo di risorse del cluster
`clusterName`	Nome del cluster
`apiVersion`	`2023-05-02` o versioni successive

Importante

La modifica delle zone di disponibilità per un cluster esistente modifica solo le zone di disponibilità per il calcolo. L'archiviazione permanente non viene modificata.

Seguire le istruzioni su come distribuire un modello.

Chiamare l'API REST all'endpoint seguente in cui sostituire i parametri con i 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);
}

Eseguire l'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}")

Eseguire l'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 aggiungere la proprietà seguente alla Microsoft.Kusto/clusters risorsa:

"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 di Azure Resource Manager. 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 permanente: i cluster usano Archiviazione di Azure come livello di persistenza durevole. Se le zone di disponibilità sono configurate, l'archiviazione con ridondanza della zona è abilitata, inserendo le repliche di archiviazione in tutte e tre le zone di disponibilità per ottenere la resilienza massima all'interno dell'area.
Nota
- L'archiviazione con ridondanza della zona comporta un costo aggiuntivo.
- Quando le zone di disponibilità non sono configurate, le risorse di archiviazione vengono distribuite con l'impostazione predefinita di Archiviazione con ridondanza locale, inserendo tutte e 3 le repliche è 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.
La migrazione dei dati di archiviazione persistente cronologici viene eseguita in archiviazione con ridondanza della zona

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 nell'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 dell'archiviazione con ridondanza della zona.
Nota
- Dopo la richiesta di migrazione, potrebbe verificarsi un ritardo fino a diversi minuti prima che tutti i nuovi dati inizino a essere scritti nella configurazione dell'archiviazione con ridondanza della zona.
- Se un cluster ha l'inserimento in streaming, il riciclo dei nuovi dati da scrivere come dati di archiviazione con ridondanza della zona può richiedere fino a 30 giorni.

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

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

Prerequisiti

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

Configurare il cluster per supportare le zone di disponibilità

Architettura dei cluster con zone di disponibilità

Processo di migrazione

Considerazioni

Commenti e suggerimenti

Risorse aggiuntive

Condividi tramite

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

Prerequisiti

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

Configurare il cluster per supportare le zone di disponibilità

Architettura dei cluster con zone di disponibilità

Processo di migrazione

Considerazioni

Contenuto correlato

Commenti e suggerimenti

Risorse aggiuntive