Funzionalità che supportano l'elevata disponibilità in un EMR cluster Amazon e il loro funzionamento con applicazioni open source

Questo argomento fornisce informazioni sulle funzionalità di alta disponibilità di Hadoop di HDFS NameNode e in YARN ResourceManager un EMR cluster Amazon e su come le funzionalità ad alta disponibilità funzionano con le applicazioni open source e altre funzionalità di Amazon. EMR

Alta disponibilità HDFS

Un EMR cluster Amazon con più nodi primari consente di HDFS NameNode funzionalità di alta disponibilità in Hadoop. Per ulteriori informazioni, vedere HDFSAlta disponibilità.

In un EMR cluster Amazon, due o più nodi separati sono configurati come NameNodes. Uno NameNode è in uno active stato e gli altri sono in uno standby stato. Se il nodo si active NameNode guasta, Amazon EMR avvia un processo di HDFS failover automatico. Un nodo standby NameNode diventa active e assume il controllo di tutte le operazioni dei client nel cluster. Amazon EMR sostituisce il nodo guasto con uno nuovo, che poi si ricongiunge come un. standby

Nota

Nelle EMR versioni Amazon 5.23.0 fino alla 5.30.1 inclusa, vengono eseguiti solo due dei tre nodi primari. HDFS NameNode

Se hai bisogno di scoprire qual NameNode èactive, puoi utilizzarlo SSH per connetterti a qualsiasi nodo primario del cluster ed eseguire il seguente comando:

hdfs haadmin -getAllServiceState

L'output elenca i nodi in cui NameNode è installato e il loro stato. Ad esempio,

ip-##-#-#-##1.ec2.internal:8020 active
ip-##-#-#-##2.ec2.internal:8020 standby
ip-##-#-#-##3.ec2.internal:8020 standby

Elevata disponibilità YARN ResourceManager

Un EMR cluster Amazon con più nodi primari abilita la funzionalità di YARN ResourceManager alta disponibilità in Hadoop. Per ulteriori informazioni, consulta la sezione ResourceManager Alta disponibilità.

In un EMR cluster Amazon con più nodi primari, YARN ResourceManager viene eseguito su tutti e tre i nodi primari. Uno ResourceManager è in active stato e gli altri due sono in standby stato. Se il nodo primario si active ResourceManager guasta, Amazon EMR avvia un processo di failover automatico. Un nodo primario con un standby ResourceManager si occupa di tutte le operazioni. Amazon EMR sostituisce il nodo primario guasto con uno nuovo, che quindi si ricongiunge al ResourceManager quorum come. standby

Puoi connetterti a «http://master-public-dns-name:8088/cluster» per qualsiasi nodo primario, che indirizza automaticamente l'utente al gestore delle risorse. active Per scoprire cos'è il gestore delle risorseactive, usa SSH per connetterti a qualsiasi nodo primario del cluster. Quindi esegui il comando seguente per ottenere un elenco dei tre nodi primari e il relativo stato:

yarn rmadmin -getAllServiceState

Applicazioni supportate in un EMR cluster Amazon con più nodi primari

Puoi installare ed eseguire le seguenti applicazioni su un EMR cluster Amazon con più nodi primari. Per ogni applicazione, il processo di failover del nodo primario varia.

Applicazione	Disponibilità durante il failover del nodo primario	Note
Flink	Disponibilità non interessata dal failover del nodo primario	I lavori Flink su Amazon EMR vengono eseguiti come YARN applicazioni. Flink viene JobManagers eseguito così com'YARNè ApplicationMasters sui nodi principali. Non JobManager è influenzato dal processo di failover del nodo primario. Se utilizzi Amazon EMR versione 5.27.0 o precedente, JobManager si tratta di un singolo punto di errore. In caso di JobManager errore, perde tutti gli stati del processo e non riprende i processi in esecuzione. È possibile abilitare l' JobManager alta disponibilità configurando il conteggio dei tentativi dell'applicazione, il checkpoint e l'abilitazione ZooKeeper come storage di stato per Flink. Per ulteriori informazioni, consulta Configurazione di Flink su un EMR cluster Amazon con più nodi primari. A partire dalla EMR versione Amazon 5.28.0, non è necessaria alcuna configurazione manuale per abilitare l' JobManager alta disponibilità.
Ganglia	Disponibilità non interessata dal failover del nodo primario	Ganglia è disponibile su tutti i nodi primari, quindi può continuare a funzionare durante il processo di failover del nodo primario.
Hadoop	Elevata disponibilità	HDFS NameNode ed esegui YARN ResourceManager automaticamente il failover sul nodo di standby in caso di guasto del nodo primario attivo.
HBase	Elevata disponibilità	HBaseesegue automaticamente il failover sul nodo di standby in caso di guasto del nodo primario attivo. Se ci si connette HBase tramite un server REST o Thrift, è necessario passare a un nodo primario diverso in caso di guasto del nodo primario attivo.
HCatalog	Disponibilità non interessata dal failover del nodo primario	HCatalogè basato sul metastore Hive, che esiste all'esterno del cluster. HCatalogrimane disponibile durante il processo di failover del nodo primario.
JupyterHub	Elevata disponibilità	JupyterHub è installato su tutte e tre le istanze principali. Si consiglia vivamente di configurare la persistenza del notebook per evitare la perdita del notebook in caso di errore del nodo primario. Per ulteriori informazioni, consulta la sezione Configurazione della persistenza per i notebook in Amazon S3.
Livy	Elevata disponibilità	Livy è installato su tutti e tre i nodi primari. Quando il nodo primario attivo riscontra un errore, perdi l'accesso alla sessione Livy corrente e devi creare una nuova sessione Livy su un altro nodo primario o sul nuovo nodo sostitutivo.
Mahout	Disponibilità non interessata dal failover del nodo primario	Poiché Mahout non prevede il daemon, non viene interessato dal processo di failover del nodo primario.
MXNet	Disponibilità non interessata dal failover del nodo primario	Poiché non MXNet dispone di un demone, non è influenzato dal processo di failover del nodo primario.
Phoenix	Elevata disponibilità	Phoenix' QueryServer viene eseguito solo su uno dei tre nodi primari. Phoenix su tutti e tre i master è configurato per connettere Phoenix. QueryServer È possibile trovare l'IP privato del server Query di Phoenix utilizzando il file /etc/phoenix/conf/phoenix-env.sh
Pig	Disponibilità non interessata dal failover del nodo primario	Poiché Pig non prevede il daemon, non viene interessato dal processo di failover del nodo primario.
Spark	Elevata disponibilità	Tutte le applicazioni Spark vengono eseguite in YARN contenitori e possono reagire al failover del nodo primario allo stesso modo delle funzionalità ad alta YARN disponibilità.
Sqoop	Elevata disponibilità	Per impostazione predefinita, sqoop-job e sqoop-metastore memorizzano i dati (descrizioni del lavoro) sul disco locale del master che esegue il comando; se si desidera salvare i dati del metastore su database esterno, fare riferimento alla documentazione di apache Sqoop
Tez	Elevata disponibilità	Poiché i contenitori Tez sono attiviYARN, Tez si comporta allo stesso modo del processo di failover del nodo primarioYARN.
TensorFlow	Disponibilità non interessata dal failover del nodo primario	Poiché non TensorFlow dispone di un demone, non è influenzato dal processo di failover del nodo primario.
Zeppelin	Elevata disponibilità	Zeppelin è installato su tutti e tre i nodi primari. Per impostazione predefinita, Zeppelin memorizza le note e le configurazioni degli interpreti per prevenire la perdita di dati. HDFS Le sessioni di interprete sono completamente isolate in tutte e tre le istanze primarie. I dati della sessione andranno persi in caso di errore principale. Si consiglia di non modificare la stessa nota contemporaneamente su istanze primarie diverse.
ZooKeeper	Elevata disponibilità	ZooKeeper è la base della funzionalità di failover automatico. HDFS ZooKeeper fornisce un servizio ad alta disponibilità per la gestione dei dati di coordinamento, la notifica ai clienti delle modifiche di tali dati e il monitoraggio dei client in caso di guasti. Per ulteriori informazioni, vedere failover HDFSautomatico.

Per eseguire le seguenti applicazioni in un EMR cluster Amazon con più nodi primari, devi configurare un database esterno. Il database esterno esiste al di fuori del cluster e rende i dati persistenti durante il processo di failover del nodo primario. Per le applicazioni seguenti, i componenti del servizio verranno ripristinati automaticamente durante il processo di failover del nodo primario, ma i processi attivi potrebbero non riuscire e dovranno essere riattivati.

Applicazione	Disponibilità durante il failover del nodo primario	Note
Hive	Disponibilità elevata solo per i componenti di servizio	È necessario un metastore esterno per Hive. Questo deve essere un metastore SQL esterno My, poiché Postgre non SQL è supportato per i cluster multimaster. Per ulteriori informazioni, consulta Configurazione di un metastore esterno per Hive.
Hue	Disponibilità elevata solo per i componenti di servizio	È necessario un database esterno per Hue. Per ulteriori informazioni, consulta Usare Hue con un database remoto in Amazon RDS.
Oozie	Disponibilità elevata solo per i componenti di servizio	È necessario un database esterno per Oozie. Per ulteriori informazioni, consulta Usare Oozie con un database remoto in Amazon RDS. Oozie-server e oozie-client sono installati su tutti e tre i nodi primari. I client oozie-sono configurati per connettersi al server oozie-corretto per impostazione predefinita.
PrestoDB o Presto /Trino SQL	Disponibilità elevata solo per i componenti di servizio	È richiesto un metastore Hive esterno per PrestoDB (Presto SQL su Amazon EMR 6.1.0-6.3.0 o Trino su Amazon 6.4.0 e versioni successive). EMR Puoi usare Presto con il AWS Glue Data Catalog o usare un SQL database My esterno per Hive. Presto CLI è installato su tutti e tre i nodi primari, quindi è possibile utilizzarlo per accedere a Presto Coordinator da qualsiasi nodo primario. Presto Coordinator è installato su un solo nodo primario. Puoi trovare il DNS nome del nodo primario su cui è installato Presto Coordinator chiamando Amazon EMR describe-cluster API e leggendo il valore restituito dal MasterPublicDnsName campo nella risposta.

Nota

Quando un nodo primario si guasta, Java Database Connectivity (JDBC) o Open Database Connectivity (ODBC) interrompe la connessione al nodo primario. Puoi connetterti a uno dei nodi primari rimanenti per continuare il lavoro dal momento che il daemon metastore Hive viene eseguito su tutti i nodi primari. In alternativa, puoi attendere che il nodo primario con errori venga sostituito.

Come funzionano EMR le funzionalità di Amazon in un cluster con più nodi primari

Connessione ai nodi primari tramite SSH

Puoi connetterti a uno qualsiasi dei tre nodi primari di un EMR cluster Amazon utilizzando lo stesso modo SSH in cui ti connetti a un singolo nodo primario. Per ulteriori informazioni, consulta Connect to the primary node using SSH.

Se un nodo primario si guasta, la SSH connessione a quel nodo primario termina. Per continuare il lavoro, puoi connetterti a uno degli altri due nodi primari. In alternativa, puoi accedere al nuovo nodo primario dopo che Amazon EMR ha sostituito quello guasto con uno nuovo.

Nota

L'indirizzo IP privato per il nodo primario sostitutivo rimane uguale a quello precedente. L'indirizzo IP pubblico per il nodo primario sostitutivo potrebbe cambiare. Puoi recuperare i nuovi indirizzi IP nella console o utilizzando il describe-cluster comando in. AWS CLI

NameNode viene eseguito solo su due dei nodi primari. Tuttavia, è possibile eseguire hdfs CLI comandi e gestire processi per accedere HDFS a tutti e tre i nodi primari.

Utilizzo dei passaggi in un EMR cluster Amazon con più nodi primari

Puoi inviare passaggi a un EMR cluster Amazon con più nodi primari nello stesso modo in cui lavori con i passaggi in un cluster con un singolo nodo primario. Per ulteriori informazioni, consulta Invio di lavoro a un cluster.

Di seguito sono riportate alcune considerazioni sull'utilizzo dei passaggi in un EMR cluster Amazon con più nodi primari:

• Se un nodo primario si guasta, i passaggi in esecuzione sul nodo primario sono contrassegnati comeFAILED. I dati scritti in locale andranno perduti. Tuttavia, lo stato FAILED potrebbe non riflettere lo stato reale dei passaggi.

• Se una fase in esecuzione ha avviato un'YARNapplicazione quando si verifica un errore nel nodo primario, l'operazione può continuare e avere esito positivo grazie al failover automatico del nodo primario.

• È consigliabile controllare lo stato delle fasi consultando l'output dei processi. Ad esempio, i MapReduce job utilizzano un _SUCCESS file per determinare se il processo viene completato correttamente.

• Si consiglia di impostare il ActionOnFailure parametro suCONTINUE, o CANCEL _ AND _WAIT, anziché su TERMINATE _ JOB _ FLOW o TERMINATE _CLUSTER.

Protezione da cessazione automatica

Amazon abilita EMR automaticamente la protezione dalla terminazione per tutti i cluster con più nodi primari e sostituisce tutte le impostazioni di esecuzione delle fasi fornite al momento della creazione del cluster. È possibile disattivare la protezione da cessazione dopo l'avvio del cluster. Per informazioni, consulta Configurazione della protezione da cessazione per i cluster in esecuzione. Per chiudere un cluster con più nodi primari, è necessario modificare gli attributi del cluster per disabilitare la protezione da terminazione. Per istruzioni, consulta Termina un EMR cluster Amazon con più nodi primari.

Per ulteriori informazioni sulla protezione da cessazione, consulta Utilizzo della protezione dalla terminazione per proteggere i EMR cluster Amazon da arresti accidentali.

Funzionalità non supportate in un EMR cluster Amazon con più nodi primari

Le seguenti EMR funzionalità di Amazon non sono attualmente disponibili in un EMR cluster Amazon con più nodi primari:

• EMRNotebook

• Accesso con un clic al server della cronologia Spark persistente

• Interfacce utente delle applicazioni persistenti

• L'accesso con un clic alle interfacce utente persistenti delle applicazioni non è attualmente disponibile per EMR i cluster Amazon con più nodi primari o per i EMR cluster Amazon integrati con Lake Formation. AWS

Nota

Per utilizzare l'autenticazione Kerberos nel tuo cluster, devi configurarne uno esterno. KDC

A partire dalla EMR versione 5.27.0 di Amazon, puoi configurare la crittografia HDFS Transparent su un EMR cluster Amazon con più nodi primari. Per ulteriori informazioni, consulta la sezione Crittografia trasparente HDFS in Amazon EMR.