Creare un cluster HDInsight che usa zone di disponibilità

Un cluster Azure HDInsight è costituito da più nodi (nodi head, nodi di lavoro, nodi del gateway e nodi zookeeper). Per impostazione predefinita, in un'area che supporta zone di disponibilità, l'utente non ha alcun controllo sui nodi del cluster di cui viene effettuato il provisioning in quale zona di disponibilità.

Con questa nuova funzionalità della zona di disponibilità, l'utente può ora specificare quale zona di disponibilità deve ospitare tutti i nodi del cluster HDInsight. I nodi del cluster sono fisicamente separati da un'altra zona di disponibilità e sono isolati dagli errori in altri zone di disponibilità nella stessa area. Questo modello di distribuzione offre anche connettività di rete a bassa latenza e economica all'interno del cluster.

La replica di questo modello di distribuzione in più zone di disponibilità può offrire un livello di disponibilità superiore per proteggersi da errori hardware.

Questo articolo illustra come creare un cluster HDInsight all'interno di una zona di disponibilità e come usare questa funzionalità per ottenere una disponibilità più elevata.

Operazioni preliminari

La funzionalità Zona di disponibilità è supportata solo per i cluster creati dopo il 15 giugno. Non è possibile aggiornare le impostazioni della zona di disponibilità dopo la creazione del cluster. Non è inoltre possibile aggiornare un cluster di zone di non disponibilità esistente per usare le zone di disponibilità.

Prerequisiti e disponibilità dell'area

Prerequisiti:

• I cluster devono essere creati in una rete virtuale personalizzata.
• È necessario usare il proprio database SQL per il database Ambari e il metastore esterno ,ad esempio il metastore Hive, in modo da poter configurare questi database nella stessa zona di disponibilità.

I cluster HDInsight possono attualmente essere creati usando le zone di disponibilità nelle aree seguenti:

Africa	Americhe	Asia Pacifico	Europa
Sudafrica settentrionale	Brasile meridionale	Australia orientale	Francia centrale
	Canada centrale	India centrale	Germania centro-occidentale
	Stati Uniti centrali	Asia orientale	Italia settentrionale
	Stati Uniti orientali	Giappone orientale	Europa settentrionale
	Stati Uniti orientali 2	Corea centrale	Norvegia orientale
	Messico centrale	Nuova Zelanda settentrionale	Polonia Centrale
	Stati Uniti centro-meridionali	Qatar centrale	Spagna centrale
	Governo degli Stati Uniti, Virginia	Asia sud-orientale	Svezia centrale
	West US 2 (Regione Ovest degli Stati Uniti 2)	Emirati Arabi Uniti settentrionali	Svizzera settentrionale
	Stati Uniti occidentali 3	Israele centrale	Regno Unito meridionale
			Europa occidentale

Panoramica delle zone di disponibilità per i cluster HDInsight

Le zone di disponibilità sono posizioni fisiche univoche all'interno di un'area. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete. In Azure un'area contiene uno o più zone di disponibilità. Questa separazione fisica delle zone di disponibilità all'interno di un'area protegge le applicazioni e i dati dagli errori del data center. Per altre informazioni, vedere Che cosa sono le zone di disponibilità in Azure.

I cluster Azure HDInsight possono essere configurati per la distribuzione all'interno di una zona di disponibilità. Tutti i nodi in questo cluster HDInsight, inclusi i due nodi head, tre nodi zookeeper, due nodi del gateway e i nodi di lavoro verranno inseriti nella zona di disponibilità specificata. Ad esempio, ci sono tre zone di disponibilità negli Stati Uniti orientali. È possibile creare un cluster HDInsight negli Stati Uniti orientali con tutti i nodi nella zona di disponibilità 1.

L'uso delle zone di disponibilità con il cluster HDInsight in questo modo può offrire vantaggi sia per le prestazioni che per i costi:

• Prestazioni migliori a causa della connettività di rete a bassa latenza
• Costo inferiore: il trasferimento dei dati all'interno della stessa zona di disponibilità è gratuito. Il trasferimento dei dati nell'area di disponibilità comporta costi di rete aggiuntivi.

Se l'applicazione richiede disponibilità elevata in più zone di disponibilità, è possibile creare un cluster HDInsight primario in una zona di disponibilità e creare un cluster HDInsight secondario in un'altra zona di disponibilità con dimensioni minime per risparmiare sui costi. Con questa progettazione, se una delle altre zone di disponibilità diventa inattiva, questo cluster HDInsight non sarà interessato. Se questa zona di disponibilità diventa inattiva, i clienti devono passare i cluster secondari in una zona di disponibilità diversa al database primario, instradare il carico di lavoro a questo nuovo cluster primario e aumentare rapidamente le dimensioni del cluster per raccogliere l'elaborazione dei dati.

Creare un cluster HDInsight usando la zona di disponibilità

È possibile usare il modello di Azure Resource Manager (ARM) per avviare un cluster HDInsight in una zona di disponibilità specificata.

Nella sezione resources è necessario aggiungere una sezione di "zone" e specificare la zona di disponibilità in cui si vuole distribuire il cluster.

"resources": [
  {
    "type": "Microsoft.HDInsight/clusters",
    "apiVersion": "2021-06-01",
    "name": "[parameters('cluster name')]",
    "location": "East US 2",
    "zones": [
      "1"
    ]
  }
]

Verificare i nodi all'interno di una zona di disponibilità tra zone

Quando il cluster HDInsight è pronto, è possibile controllare la posizione per vedere la zona di disponibilità in cui sono distribuite.

Ottieni risposta API:

[
  {
    "location": "East US 2",
    "zones": [
        "1"
    ]
  }
]

Aumentare le dimensioni del cluster

È possibile aumentare le prestazioni di un cluster HDInsight con più nodi di lavoro. I nodi di lavoro appena aggiunti verranno inseriti nella stessa zona di disponibilità di questo cluster.

Procedure consigliate

• Eseguire regolarmente il backup delle configurazioni nel database Ambari.
• Implementare la logica per instradare facilmente il carico di lavoro al cluster secondario.

Quando az diventa inattivo, cosa aspettarsi

• Non è possibile connettersi tramite SSH a questo cluster
• Non è possibile eliminare o aumentare o ridurre le prestazioni del cluster
• Non è possibile inviare processi o visualizzare la cronologia dei processi
• È comunque possibile inviare una nuova richiesta di creazione del cluster in un'area diversa