Servizi a disponibilità elevata supportati da Azure HDInsight
Per offrire livelli ottimali di disponibilità per i componenti di analisi, HDInsight è stato sviluppato con un'architettura unica per garantire la disponibilità elevata dei servizi critici. Microsoft ha sviluppato alcuni componenti di questa architettura per fornire il failover automatico. Altri componenti sono componenti Apache standard distribuiti per supportare servizi specifici. Questo articolo illustra l'architettura del modello di servizio a disponibilità elevata in HDInsight, il modo in cui HDInsight supporta il failover per i servizi a disponibilità elevata e le procedure consigliate per il ripristino da altre interruzioni del servizio.
Nota
Questo articolo contiene riferimenti al termine slave, che Microsoft non usa più. Quando il termine verrà rimosso dal software, verrà rimosso anche dall'articolo.
Infrastruttura a disponibilità elevata
HDInsight offre un'infrastruttura personalizzata per garantire che quattro servizi primari siano a disponibilità elevata con funzionalità di failover automatico:
- Server Apache Ambari
- Server sequenza temporale dell'applicazione per Apache YARN
- Server cronologia processi per Hadoop MapReduce
- Apache Livy
Questa infrastruttura è costituita da molti servizi e componenti software, alcuni dei quali sono progettati da Microsoft. I componenti seguenti sono univoci per la piattaforma HDInsight:
- Controller di failover slave
- Controller di failover master
- Servizio di disponibilità elevata slave
- Servizio di disponibilità elevata master
Sono disponibili anche altri servizi a disponibilità elevata, supportati da componenti di affidabilità Apache open source. Questi componenti sono presenti anche nei cluster HDInsight:
- Hadoop File System (HDFS) NameNode
- YARN ResourceManager
- HBase Master
Nelle sezioni seguenti vengono fornite informazioni più dettagliate sul funzionamento di questi servizi.
Servizi a disponibilità elevata di HDInsight
Microsoft fornisce supporto per i quattro servizi Apache nella tabella seguente nei cluster HDInsight. Per distinguerli dai servizi a disponibilità elevata supportati dai componenti di Apache, vengono chiamati servizi a disponibilità elevata di HDInsight.
| Servizio | Nodi del cluster | Tipi di cluster | Scopo |
|---|---|---|---|
| Server Apache Ambari | Nodo head attivo | Tutte le date | Monitora e gestisce il cluster. |
| Server sequenza temporale dell'applicazione per Apache YARN | Nodo head attivo | Tutti tranne Kafka | Gestisce le informazioni di debug sui processi YARN in esecuzione nel cluster. |
| Server cronologia processi per Hadoop MapReduce | Nodo head attivo | Tutti tranne Kafka | Gestisce i dati di debug per i processi MapReduce. |
| Apache Livy | Nodo head attivo | Spark | Consente un'interazione semplice con un cluster Spark tramite un'interfaccia REST |
Nota
I cluster HDInsight Enterprise Security Package (ESP) attualmente forniscono solo la disponibilità elevata del server Ambari. Server sequenza temporale applicazioni, server cronologia processi e Livy sono tutti in esecuzione solo in headnode0 e non eseguono il failover in headnode1 quando Ambari non esegue il failover. Il database della sequenza temporale dell'applicazione si trova anche in headnode0 e non in Ambari SQL Server.
Architettura
Ogni cluster HDInsight ha due nodi head rispettivamente in modalità attiva e standby. I servizi a disponibilità elevata di HDInsight vengono eseguiti solo su headnodes. Questi servizi devono essere sempre in esecuzione sul nodo head attivo e arrestati e messi in modalità di manutenzione sul nodo head di standby.
Per mantenere gli stati corretti dei servizi a disponibilità elevata e fornire un failover rapido, HDInsight usa Apache ZooKeeper, che è un servizio di coordinamento per le applicazioni distribuite, per eseguire l'elezione del nodo head attivo. HDInsight effettua anche il provisioning di alcuni processi Java in background, che coordinano la procedura di failover per i servizi a disponibilità elevata di HDInsight. Questi servizi sono: il controller di failover master, il controller di failover slave, il master-ha-service e slave-ha-service.
Apache ZooKeeper
Apache ZooKeeper è un servizio di coordinamento ad alte prestazioni per le applicazioni distribuite. Nell'ambiente di produzione ZooKeeper viene in genere eseguito in modalità replicata in cui un gruppo replicato di server ZooKeeper costituisce un quorum. Ogni cluster HDInsight ha tre nodi ZooKeeper che consentono a tre server ZooKeeper di formare un quorum. HDInsight dispone di due quorum ZooKeeper in esecuzione in parallelo tra loro. Un quorum decide il nodo head attivo in un cluster in cui devono essere eseguiti i servizi a disponibilità elevata di HDInsight. Un altro quorum viene usato per coordinare i servizi a disponibilità elevata forniti da Apache, come descritto in dettaglio nelle sezioni successive.
Controller di failover slave
Il controller di failover slave viene eseguito in ogni nodo di un cluster HDInsight. Questo controller è responsabile dell'avvio dell'agente Ambari e del servizio slave-ha-in ogni nodo. Esegue periodicamente una query sul primo quorum ZooKeeper sul nodo head attivo. Quando i nodi head attivi e di standby cambiano, il controller di failover slave esegue i passaggi seguenti:
- Aggiornamenti il file di configurazione dell'host.
- Riavvia l'agente Ambari.
Il servizio slave-ha-è responsabile dell'arresto dei servizi a disponibilità elevata di HDInsight (ad eccezione del server Ambari) nel nodo head di standby.
Controller di failover master
Un controller di failover master viene eseguito su entrambi i nodi head. Entrambi i controller di failover master comunicano con il primo quorum ZooKeeper per nominare il nodo head su cui sono in esecuzione come nodo head attivo.
Ad esempio, se il controller di failover master nel nodo head 0 vince l'elezione, vengono apportate le modifiche seguenti:
- Headnode 0 diventa attivo.
- Il controller di failover master avvia il server Ambari e il master-ha-service nel nodo head 0.
- L'altro controller di failover master arresta il server Ambari e il master-ha-service nel nodo head 1.
Il master-ha-service viene eseguito solo nel nodo head attivo, arresta i servizi a disponibilità elevata di HDInsight (ad eccezione del server Ambari) nel nodo head di standby e li avvia nel nodo head attivo.
Processo di failover
Un monitoraggio dell'integrità viene eseguito in ogni nodo head insieme al controller di failover master per inviare notifiche heartbeat al quorum Zookeeper. Il nodo head è considerato un servizio a disponibilità elevata in questo scenario. Il monitoraggio dell'integrità verifica se ogni servizio a disponibilità elevata è integro e se è pronto per partecipare alle elezioni di leadership. In caso affermativo, questo nodo head compete alle elezioni. In caso contrario, chiude l'elezione fino a quando non diventa nuovamente pronto.
Se il nodo head di standby raggiunge la leadership e diventa attivo (ad esempio in caso di errore con il nodo attivo precedente), il controller di failover master avvia tutti i servizi a disponibilità elevata di HDInsight. Il controller di failover master arresta questi servizi nell'altro nodo head.
Per gli errori del servizio a disponibilità elevata di HDInsight, ad esempio un servizio inattivo o non integro, il controller di failover master deve riavviare o arrestare automaticamente i servizi in base allo stato del nodo head. Gli utenti non devono avviare manualmente i servizi a disponibilità elevata di HDInsight in entrambi i nodi head. Consentire invece il failover automatico o manuale per consentire il ripristino del servizio.
Intervento manuale accidentale
I servizi a disponibilità elevata di HDInsight devono essere eseguiti solo nel nodo head attivo e vengono riavviati automaticamente quando necessario. Poiché i singoli servizi a disponibilità elevata non hanno il proprio monitoraggio dell'integrità, il failover non può essere attivato a livello di singolo servizio. Il failover viene garantito a livello di nodo e non a livello di servizio.
Alcuni problemi noti
Quando si avvia manualmente un servizio a disponibilità elevata nel nodo head di standby, non si arresterà fino a quando non si verifica il failover successivo. Quando i servizi a disponibilità elevata sono in esecuzione in entrambi i nodi head, alcuni potenziali problemi includono: l'interfaccia utente di Ambari non è accessibile, Ambari genera errori, YARN, Spark e processi Oozie potrebbero bloccarsi.
Quando un servizio a disponibilità elevata nel nodo head attivo si arresta, non verrà riavviato fino a quando non si verifica il failover successivo o il controller di failover master/master-ha-service viene riavviato. Quando uno o più servizi a disponibilità elevata si arrestano nel nodo head attivo, in particolare quando il server Ambari si arresta, l'interfaccia utente di Ambari non è accessibile, altri potenziali problemi includono errori di processi YARN, Spark e Oozie.
Servizi di disponibilità elevata Apache
Apache offre disponibilità elevata per HDFS NameNode, YARN ResourceManager e HBase Master, disponibili anche nei cluster HDInsight. A differenza dei servizi a disponibilità elevata di HDInsight, sono supportati nei cluster ESP. I servizi Apache a disponibilità elevata comunicano con il secondo quorum ZooKeeper (descritto nella sezione precedente) per scegliere gli stati attivi/standby ed eseguire il failover automatico. Le sezioni seguenti illustrano in dettaglio il funzionamento di questi servizi.
Hadoop Distributed File System (HDFS) NameNode
I cluster HDInsight basati su Apache Hadoop 2.0 o versione successiva forniscono la disponibilità elevata di NameNode. Esistono due NomiNodi in esecuzione nei nodi head, configurati per il failover automatico. NameNodes usa ZKFailoverController per comunicare con Zookeeper per scegliere lo stato attivo/standby. ZKFailoverController viene eseguito su entrambi i nodi head e funziona allo stesso modo del controller di failover master.
Il secondo quorum zookeeper è indipendente dal primo quorum, quindi il nodo NameNode attivo potrebbe non essere eseguito nel nodo head attivo. Quando NameNode attivo è inattivo o non integro, nameNode di standby vince l'elezione e diventa attivo.
YARN ResourceManager
I cluster HDInsight basati su Apache Hadoop 2.4 o versione successiva supportano la disponibilità elevata di YARN ResourceManager. Esistono due ResourceManager, rm1 e rm2, in esecuzione rispettivamente nel nodo head 0 e nel nodo head 1. Analogamente a NameNode, YARN ResourceManager è configurato anche per il failover automatico. Un altro ResourceManager viene selezionato automaticamente per essere attivo quando ResourceManager attivo diventa inattivo o non risponde.
YARN ResourceManager usa activeStandbyElector incorporato come rilevatore di errori e elettore leader. A differenza di HDFS NameNode, YARN ResourceManager non richiede un daemon ZKFC separato. ResourceManager attivo scrive i relativi stati in Apache Zookeeper.
La disponibilità elevata di YARN ResourceManager è indipendente da NameNode e da altri servizi a disponibilità elevata di HDInsight. Il ResourceManager attivo potrebbe non essere eseguito nel nodo head attivo o nel nodo head in cui è in esecuzione nameNode attivo. Per altre informazioni sulla disponibilità elevata di YARN ResourceManager, vedere Disponibilità elevata di ResourceManager.
HBase Master
I cluster HDInsight HBase supportano la disponibilità elevata di HBase Master. A differenza di altri servizi a disponibilità elevata, che vengono eseguiti su headnodes, HBase Masters viene eseguito sui tre nodi Zookeeper, dove uno di essi è il master attivo e gli altri due sono in standby. Come NameNode, HBase Master coordina Apache Zookeeper per le elezioni leader ed esegue il failover automatico quando il master attivo corrente presenta problemi. Esiste un solo master HBase attivo in qualsiasi momento.