Affidabilità in Azure HDInsight

Questo articolo descrive il supporto per l'affidabilità in Azure HDInsight e illustra le zone di disponibilità e il ripristino tra aree e la continuità aziendale. Per una panoramica più dettagliata dell'affidabilità in Azure, vedere Affidabilità di Azure.

Supporto della zona di disponibilità

Le zone di disponibilità di Azure sono almeno tre gruppi di data center separati fisicamente all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di energia, raffreddamento e infrastruttura di rete indipendenti. In caso di errore della zona locale, le zone di disponibilità sono progettate in modo che se l'unica zona è interessata, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle due zone rimanenti.

Gli errori possono variare da errori software e hardware a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori si ottiene con ridondanza e isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.

I servizi abilitati per le zone di disponibilità di Azure sono progettati per offrire il giusto livello di affidabilità e flessibilità. Possono essere configurati in due modi. Possono essere ridondanti della zona, con replica automatica tra zone o zone, con istanze aggiunte a una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sull'architettura zonale e con ridondanza della zona, vedere Consigli per l'uso di zone e aree di disponibilità.

Azure HDInsight supporta una configurazione di distribuzione di zona. I nodi del cluster Azure HDInsight vengono posizionati in una singola zona selezionata nell'area selezionata. Un cluster HDInsight di zona è isolato da eventuali interruzioni che si verificano in altre zone. Tuttavia, se un'interruzione influisce sulla zona specifica scelta per il cluster HDInsight, il cluster non sarà disponibile. Questo modello di distribuzione offre connettività di rete a bassa latenza e conveniente all'interno del cluster. La replica di questo modello di distribuzione in più zone di disponibilità può offrire un livello di disponibilità superiore per la protezione da errori hardware.

Prerequisiti

• Le zone di disponibilità sono supportate solo per i cluster creati dopo il 15 giugno 2023. 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à.

• 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 devono essere creati con l'opzione della zona di disponibilità in una delle aree seguenti:

  • Australia orientale
  • Brasile meridionale
  • Canada centrale
  • Stati Uniti centrali
  • Stati Uniti orientali
  • Stati Uniti orientali 2
  • Francia centrale
  • Germania centro-occidentale
  • Giappone orientale
  • Corea centrale
  • Europa settentrionale
  • Qatar centrale
  • Asia sud-orientale
  • Stati Uniti centro-meridionali
  • Regno Unito meridionale
  • US Gov Virginia
  • Europa occidentale
  • West US 2

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.

Ottenere la risposta dell'API:

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

Aumentare le prestazioni 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à del cluster.

Ridistribuzione della zona di disponibilità

I cluster Azure HDInsight attualmente non supportano la migrazione sul posto delle istanze del cluster esistenti al supporto della zona di disponibilità. Tuttavia, è possibile scegliere di ricreare il cluster e scegliere una zona o un'area di disponibilità diversa durante la creazione del cluster. Un cluster di standby secondario in un'area diversa e in una zona di disponibilità diversa può essere usato in scenari di ripristino di emergenza.

Esperienza di riduzione della zona

Quando una zona di disponibilità diventa inattiva:

• 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.

Ripristino di emergenza tra aree e continuità aziendale

Il ripristino di emergenza riguarda il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare alla creazione del piano di ripristino di emergenza, vedere Consigli per la progettazione di una strategia di ripristino di emergenza.

Per quanto riguarda il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello di responsabilità condivisa, Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, l'utente è responsabile della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e linee guida per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per lo sviluppo del piano di ripristino di emergenza.

I cluster Azure HDInsight dipendono da molti servizi di Azure, ad esempio archiviazione, database, Active Directory, servizi Dominio di Active Directory, rete e Key Vault. Un'applicazione di analisi ben progettata, a disponibilità elevata e a tolleranza di errore deve essere progettata con una ridondanza sufficiente per resistere a interruzioni locali o regionali in uno o più di questi servizi. Questa sezione offre una panoramica delle procedure consigliate, della disponibilità di singole aree e delle opzioni di ottimizzazione per la pianificazione della continuità aziendale.

Ripristino di emergenza nell'area geografica in più aree

Il miglioramento della continuità aziendale con il ripristino di emergenza a disponibilità elevata tra aree richiede progettazioni dell'architettura di maggiore complessità e costi più elevati. Le tabelle seguenti illustrano in dettaglio alcune aree tecniche che possono aumentare il costo totale di proprietà.

Ottimizzazione dei costi

Ottimizzazioni della complessità

Quando si crea il piano di ripristino di emergenza in più aree, prendere in considerazione le raccomandazioni seguenti:

• Determinare le funzionalità aziendali minime necessarie in caso di emergenza e perché. Ad esempio, valutare se sono necessarie funzionalità di failover per il livello di trasformazione dei dati (visualizzato in giallo) e il livello di gestione dei dati (visualizzato in blu) o se è necessario solo il failover per il livello del servizio dati.

  

• Segmentare i cluster in base a carichi di lavoro, ciclo di vita di sviluppo e reparti. La presenza di più cluster riduce le probabilità di un singolo errore di grandi dimensioni che influisce su più processi aziendali diversi.

• Rendere di sola lettura le aree secondarie. Le aree di failover con funzionalità di lettura e scrittura possono portare a architetture complesse.

• I cluster temporanei sono più facili da gestire quando si verifica un'emergenza. Progettare i carichi di lavoro in modo che i cluster possano essere ciclicamente e che non venga mantenuto alcuno stato nei cluster.

• Spesso i carichi di lavoro vengono lasciati incompiuti in caso di emergenza e devono essere riavviati nella nuova area. Progettare i carichi di lavoro in modo che siano idempotenti in natura.

• Usare l'automazione durante le distribuzioni del cluster e assicurarsi che le impostazioni di configurazione del cluster vengano inserite nello script per garantire la distribuzione rapida e completamente automatizzata in caso di emergenza.

Rilevamento, notifica e gestione di interruzioni

• Usare gli strumenti di monitoraggio di Azure in HDInsight per rilevare comportamenti anomali nel cluster e impostare le notifiche di avviso corrispondenti. È possibile distribuire le soluzioni di gestione specifiche del cluster HDInsight preconfigurato che raccolgono importanti metriche delle prestazioni del tipo di cluster specifico. Per altre informazioni, vedere Monitoraggio di Azure per HDInsight.

• Sottoscrivere gli avvisi di integrità di Azure per ricevere notifiche relative a problemi del servizio, manutenzione pianificata, integrità e avvisi di sicurezza per una sottoscrizione, un servizio o un'area geografica. Le notifiche sull'integrità che includono la causa del problema e l'ETA risoluta consentono di eseguire meglio failover e failback. Per altre informazioni, vedere la documentazione sull'integrità dei servizi di Azure.

Ripristino di emergenza in area geografica singola

Ogni componente in un sistema HDInsight di base dispone di meccanismi di tolleranza di errore a singola area. Tenere presente che non sempre accetta un evento irreversibile per influire sulle funzionalità aziendali. Gli eventi imprevisti del servizio in uno o più dei servizi seguenti in una singola area possono anche causare la perdita di funzionalità aziendali previste.

• Calcolo (macchine virtuali): cluster Azure HDInsight. HDInsight offre un contratto di servizio di disponibilità del 99,9%. Per offrire disponibilità elevata in una singola distribuzione, HDInsight è accompagnato da molti servizi in modalità a disponibilità elevata per impostazione predefinita. I meccanismi di tolleranza di errore in HDInsight vengono forniti dai servizi a disponibilità elevata dell'ecosistema Microsoft e Apache OSS.

  I componenti dell'infrastruttura seguenti sono progettati per essere a disponibilità elevata:

  • Head head attivo e standby
  • Più nodi del gateway
  • Tre nodi quorum zookeeper
  • Nodi di lavoro distribuiti da domini di errore e aggiornamento

  I servizi seguenti sono progettati anche per essere a disponibilità elevata:

  • Apache Ambari Server
  • Sequenza temporale dell'applicazione per YARN
  • Server cronologia processi per Hadoop MapReduce
  • Apache Livy
  • HDFS
  • YARN Resource Manager
  • HBase Master

  Per altre informazioni, vedere Servizi a disponibilità elevata supportati da Azure HDInsight.

• Metastore: database SQL di Azure. HDInsight usa database SQL di Azure come metastore, che fornisce un contratto di servizio del 99,99%. Tre repliche di dati vengono mantenute all'interno di un data center con replica sincrona. Se si verifica una perdita di replica, una replica alternativa viene servita senza problemi. La replica geografica attiva è supportata automaticamente con un massimo di quattro data center. Quando si verifica un failover, manuale o data center, la prima replica nella gerarchia diventerà automaticamente in grado di eseguire operazioni di lettura/scrittura. Per altre informazioni, vedere database SQL di Azure continuità aziendale.

• Archiviazione: Archiviazione BLOB o Azure Data Lake Gen2. HDInsight consiglia azure Data Lake Archiviazione Gen2 come livello di archiviazione sottostante. Archiviazione di Azure, incluso Azure Data Lake Archiviazione Gen2, fornisce un contratto di servizio del 99,9%. HDInsight usa il servizio archiviazione con ridondanza locale in cui tre repliche di dati vengono mantenute all'interno di un data center e la replica è sincrona. Quando si verifica una perdita di replica, una replica viene gestita senza problemi.

• Autenticazione: Microsoft Entra ID, Microsoft Entra Domain Services, Enterprise Security Package.

  • Microsoft Entra ID fornisce un contratto di servizio del 99,9%. Active Directory è un servizio globale con più livelli di ridondanza interna e recuperabilità automatica. Per altre informazioni, vedere come Microsoft migliora continuamente l'affidabilità di Microsoft Entra ID.
  • Microsoft Entra Domain Services offre un contratto di servizio del 99,9%. Microsoft Entra Domain Services è un servizio a disponibilità elevata ospitato in data center distribuiti a livello globale. I set di repliche sono una funzionalità di anteprima di Microsoft Entra Domain Services che consente il ripristino di emergenza geografico se un'area di Azure diventa offline. Per altre informazioni, vedere Concetti e funzionalità dei set di repliche per Microsoft Entra Domain Services per altre informazioni.
  • DNS di Azure offre un contratto di servizio del 100%. HDInsight usa DNS di Azure in varie posizioni per la risoluzione dei nomi di dominio.

• Servizi facoltativi, ad esempio Azure Key Vault e Azure Data Factory.

Passaggi successivi

Per altre informazioni sugli elementi descritti in questo articolo, vedere:

• Architetture di continuità aziendale di Azure HDInsight
• Case study dell'architettura della soluzione a disponibilità elevata di Azure HDInsight
• Che cos'è Apache Hive e HiveQL in Azure HDInsight?