Fonctionnalités garantissant la haute disponibilité et leur fonctionnement avec les applications open source

Cette rubrique fournit des informations sur les fonctionnalités Hadoop de HDFS NameNode et dans YARN ResourceManager un EMR cluster Amazon, ainsi que sur la manière dont les fonctionnalités de haute disponibilité fonctionnent avec les applications open source et les autres fonctionnalités d'Amazon. EMR

Haute disponibilité HDFS

Un EMR cluster Amazon avec plusieurs nœuds principaux permet HDFS NameNode fonctionnalité de haute disponibilité dans Hadoop. Pour plus d'informations, consultez la section HDFSHaute disponibilité.

Dans un EMR cluster Amazon, deux nœuds distincts ou plus sont configurés en tant que NameNodes. L'un NameNode est dans un active État et les autres dans un standby État. En cas de active NameNode défaillance du nœud, Amazon EMR lance un processus de HDFS basculement automatique. Un nœud standby NameNode devient active et prend en charge toutes les opérations du client dans le cluster. Amazon EMR remplace le nœud défaillant par un nouveau, qui le rejoint ensuite en tant standby que.

Note

Dans EMR les versions 5.23.0 à 5.30.1 incluses d'Amazon, seuls deux des trois nœuds principaux s'exécutent. HDFS NameNode

Si vous avez besoin de savoir lequel NameNode estactive, vous pouvez l'utiliser SSH pour vous connecter à n'importe quel nœud principal du cluster et exécuter la commande suivante :

hdfs haadmin -getAllServiceState

La sortie répertorie les nœuds sur lesquels NameNode il est installé et leur état. Par exemple,

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

Haute disponibilité YARN ResourceManager

Un EMR cluster Amazon avec plusieurs nœuds principaux active la fonctionnalité de YARN ResourceManager haute disponibilité de Hadoop. Pour plus d'informations, consultez la section ResourceManager Haute disponibilité.

Dans un EMR cluster Amazon comportant plusieurs nœuds principaux, il YARN ResourceManager s'exécute sur les trois nœuds principaux. L'un ResourceManager est en active état et les deux autres sont en standby état. En cas de active ResourceManager défaillance du nœud principal, Amazon EMR lance un processus de basculement automatique. Un nœud principal doté d'un standby ResourceManager prend en charge toutes les opérations. Amazon EMR remplace le nœud principal défaillant par un nouveau, qui rejoint ensuite le ResourceManager quorum en tant standby que.

Vous pouvez vous connecter à « http ://master-public-dns-name:8088/cluster » pour n'importe quel nœud principal, qui vous dirige automatiquement vers le gestionnaire de ressources. active Pour savoir quel est le gestionnaire de ressourcesactive, utilisez SSH pour vous connecter à n'importe quel nœud principal du cluster. Ensuite, exécutez la commande suivante pour obtenir la liste des trois nœuds primaires et leur statut :

yarn rmadmin -getAllServiceState

Applications prises en charge dans un EMR cluster Amazon avec plusieurs nœuds principaux

Vous pouvez installer et exécuter les applications suivantes sur un EMR cluster Amazon comportant plusieurs nœuds principaux. Pour chaque application, le processus de basculement du nœud primaire (ou nœud primaire) varie.

Application	Disponibilité lors du basculement du nœud primaire	Remarques
Flink	Disponibilité non affectée par le basculement du nœud primaire	Les jobs Flink sur Amazon EMR s'exécutent sous forme d'YARNapplications. Flink JobManagers fonctionne tel quel ApplicationMasters sur YARN les nœuds principaux. Le n'JobManager est pas affecté par le processus de basculement du nœud principal. Si vous utilisez Amazon EMR version 5.27.0 ou antérieure, il JobManager s'agit d'un point de défaillance unique. En cas d' JobManager échec, il perd tous les états des tâches et ne reprend pas les tâches en cours d'exécution. Vous pouvez activer la JobManager haute disponibilité en configurant le nombre de tentatives d'application, le point de contrôle et en activant ZooKeeper le stockage d'état pour Flink. Pour plus d'informations, consultez Configuration de Flink sur un EMR cluster Amazon avec plusieurs nœuds principaux. À partir de EMR la version 5.28.0 d'Amazon, aucune configuration manuelle n'est nécessaire pour activer la JobManager haute disponibilité.
Ganglia	Disponibilité non affectée par le basculement du nœud primaire	Ganglia est disponible sur tous les nœuds primaires. Ainsi, Ganglia peut continuer à s'exécuter pendant le processus de basculement du nœud primaire.
Hadoop	Haute disponibilité	HDFS NameNode et YARN ResourceManager basculez automatiquement vers le nœud de secours en cas de défaillance du nœud principal actif.
HBase	Haute disponibilité	HBasebascule automatiquement vers le nœud de secours lorsque le nœud principal actif tombe en panne. Si vous vous connectez HBase via un serveur REST ou Thrift, vous devez passer à un autre nœud principal en cas de défaillance du nœud principal actif.
HCatalog	Disponibilité non affectée par le basculement du nœud primaire	HCatalogest basé sur le métastore Hive, qui existe en dehors du cluster. HCatalogreste disponible pendant le processus de basculement du nœud principal.
JupyterHub	Haute disponibilité	JupyterHub est installé sur les trois instances principales. Il est fortement recommandé de configurer la persistance du bloc-notes pour éviter la perte du bloc-notes en cas de défaillance du nœud primaire. Pour plus d'informations, consultez Configuration de persistance pour les blocs-notes dans Amazon S3.
Livy	Haute disponibilité	Livy est installé sur les trois nœuds primaires. Lorsque le nœud primaire actif échoue, vous perdez l'accès à la session Livy actuelle et vous devez créer une nouvelle session Livy sur un autre nœud primaire ou sur le nouveau nœud de remplacement.
Mahout	Disponibilité non affectée par le basculement du nœud primaire	Étant donné que Mahout n'a pas de démon, il n'est pas affecté par le processus de basculement du nœud primaire.
MXNet	Disponibilité non affectée par le basculement du nœud primaire	Comme il n'MXNeta pas de daemon, il n'est pas affecté par le processus de basculement du nœud principal.
Phoenix	Haute disponibilité	Phoenix' ne QueryServer fonctionne que sur l'un des trois nœuds principaux. Sur les trois maîtres, Phoenix est configuré pour connecter le Phoenix QueryServer. Vous pouvez trouver l'adresse IP privée du serveur de requête de Phoenix en utilisant le fichier /etc/phoenix/conf/phoenix-env.sh
Pig	Disponibilité non affectée par le basculement du nœud primaire	Étant donné que Pig n'a pas de démon, il n'est pas affecté par le processus de basculement du nœud primaire.
Spark	Haute disponibilité	Toutes les applications Spark s'exécutent dans YARN des conteneurs et peuvent réagir au basculement du nœud principal de la même manière que les fonctionnalités de haute disponibilitéYARN.
Sqoop	Haute disponibilité	Par défaut, sqoop-job et sqoop-metastore stockent les données (descriptions de tâche) sur le disque local du maître qui exécute la commande. Si vous souhaitez enregistrer des données de metastore dans une base de données externe, consultez la documentation Apache Sqoop
Tez	Haute disponibilité	Comme les conteneurs Tez s'exécutentYARN, Tez se comporte de la même manière que YARN lors du processus de basculement du nœud principal.
TensorFlow	Disponibilité non affectée par le basculement du nœud primaire	Comme il n' TensorFlow a pas de daemon, il n'est pas affecté par le processus de basculement du nœud principal.
Zeppelin	Haute disponibilité	Zeppelin est installé sur les trois nœuds primaires. Zeppelin stocke les notes et les configurations d'interpréteur HDFS par défaut pour éviter toute perte de données. Les sessions d'interpréteur sont complètement isolées sur les trois instances principales. Les données de session seront perdues en cas d'échec du maître. Il est recommandé de ne pas modifier simultanément la même note sur différentes instances principales.
ZooKeeper	Haute disponibilité	ZooKeeper est le fondement de la fonction de basculement HDFS automatique. ZooKeeper fournit un service hautement disponible pour gérer les données de coordination, informer les clients des modifications apportées à ces données et surveiller les clients en cas de défaillance. Pour plus d'informations, consultez la section HDFSBasculement automatique.

Pour exécuter les applications suivantes dans un EMR cluster Amazon comportant plusieurs nœuds principaux, vous devez configurer une base de données externe. La base de données externe existe en dehors du cluster et rend les données persistantes pendant le processus de basculement du nœud primaire. Pour les applications suivantes, les composants de service se rétabliront automatiquement pendant le processus de basculement du nœud primaire, mais les tâches actives peuvent échouer et doivent être relancées.

Application	Disponibilité lors du basculement du nœud primaire	Remarques
Hive	Haute disponibilité pour les composants de service uniquement	Un metastore externe pour Hive est requis. Il doit s'agir d'un metastore My SQL externe, car Postgre n'SQLest pas pris en charge pour les clusters multi-maîtres. Pour de plus amples informations, veuillez consulter Configuration d'un métastore externe pour Hive.
Hue	Haute disponibilité pour les composants de service uniquement	Une base de données externe pour Hue est requise. Pour plus d'informations, consultez Utilisation de Hue avec une base de données distante sur Amazon RDS.
Oozie	Haute disponibilité pour les composants de service uniquement	Une base de données externe pour Oozie est requise. Pour plus d'informations, consultez Utiliser Oozie avec une base de données distante sur Amazon. RDS Oozie-server et oozie-client sont installés sur les trois nœuds primaires. Les clients oozie-sont configurés pour se connecter au serveur oozie-server correct par défaut.
PrestoDB ou Presto /Trino SQL	Haute disponibilité pour les composants de service uniquement	Un métastore Hive externe pour PrestoDB (Presto sur Amazon EMR 6.1.0-6.3.0 ou Trino sur SQL Amazon 6.4.0 et versions ultérieures) est requis. EMR Vous pouvez utiliser Presto avec AWS Glue Data Catalog ou utilisez une base de SQL données My Database externe pour Hive. Le Presto CLI est installé sur les trois nœuds principaux afin que vous puissiez l'utiliser pour accéder au Presto Coordinator depuis n'importe lequel des nœuds principaux. Presto Coordinator est installé sur un seul nœud primaire. Vous pouvez trouver le DNS nom du nœud principal sur lequel le Presto Coordinator est installé en appelant Amazon EMR describe-cluster API et en lisant la valeur renvoyée du MasterPublicDnsName champ dans la réponse.

Note

Lorsqu'un nœud principal tombe en panne, votre Java Database Connectivity (JDBC) ou Open Database Connectivity (ODBC) met fin à sa connexion au nœud principal. Vous pouvez vous connecter à l'un des autres nœuds maîtres pour continuer votre travail puisque le démon métastore Hive s'exécute sur tous les nœuds maîtres. Ou vous pouvez attendre le remplacement du nœud primaire en échec.

Comment fonctionnent les EMR fonctionnalités d'Amazon dans un cluster comportant plusieurs nœuds principaux

Connexion aux nœuds principaux à l'aide de SSH

Vous pouvez vous connecter à l'un des trois nœuds principaux d'un EMR cluster Amazon de la même manière que vous vous connectez à un seul nœud principal. SSH Pour plus d'informations, voir Se connecter au nœud principal à l'aide deSSH.

En cas de défaillance d'un nœud principal, votre SSH connexion à ce nœud principal prend fin. Pour continuer votre travail, vous pouvez vous connecter à l'un des deux autres nœuds primaires. Vous pouvez également accéder au nouveau nœud principal une fois qu'Amazon EMR aura remplacé le nœud défaillant par un nouveau.

Note

L'adresse IP privée pour le nœud primaire de remplacement reste la même que la précédente. L'adresse IP publique pour le nœud primaire de remplacement peut changer. Vous pouvez récupérer les nouvelles adresses IP dans la console ou en utilisant la describe-cluster commande du AWS CLI.

NameNode ne fonctionne que sur deux des nœuds principaux. Cependant, vous pouvez exécuter hdfs CLI des commandes et exécuter des tâches pour accéder HDFS aux trois nœuds principaux.

Utilisation des étapes dans un EMR cluster Amazon comportant plusieurs nœuds principaux

Vous pouvez envoyer des étapes à un EMR cluster Amazon avec plusieurs nœuds principaux de la même manière que vous travaillez avec les étapes d'un cluster avec un seul nœud principal. Pour plus d'informations, consultez Soumission de travail à un cluster.

Voici les points à prendre en compte lors de l'utilisation des étapes dans un EMR cluster Amazon comportant plusieurs nœuds principaux :

• En cas de défaillance d'un nœud principal, les étapes exécutées sur le nœud principal sont marquées commeFAILED. Toutes les données écrites en local sont perdues. Cependant, le statut FAILED peut ne pas refléter l'état réel des étapes.

• Si une étape en cours d'exécution a démarré une YARN application lorsque le nœud principal tombe en panne, l'étape peut se poursuivre et réussir grâce au basculement automatique du nœud principal.

• Il est recommandé de vérifier le statut des étapes en faisant référence à la sortie des tâches. Par exemple, les MapReduce tâches utilisent un _SUCCESS fichier pour déterminer si elles se terminent correctement.

• Il est recommandé de définir le ActionOnFailure paramètre surCONTINUE, ou CANCEL _ AND _WAIT, au lieu de TERMINATE JOB _ _ FLOW ou TERMINATE _CLUSTER.

Protection contre la résiliation automatique

Amazon active EMR automatiquement la protection contre la résiliation pour tous les clusters comportant plusieurs nœuds principaux et remplace tous les paramètres d'exécution des étapes que vous fournissez lors de la création du cluster. Vous pouvez désactiver la protection contre la résiliation après le lancement du cluster. Consultez Configuration de la protection contre la résiliation pour les clusters en cours d'exécution. Pour résilier un cluster comportant plusieurs nœuds primaires, vous devez d'abord modifier les attributs du cluster afin de désactiver la protection contre la résiliation. Pour obtenir des instructions, consultez Mettre fin à un EMR cluster Amazon comportant plusieurs nœuds principaux.

Pour plus d'informations sur la protection contre les résiliations, consultez Utilisation de la protection contre les interruptions pour protéger vos clusters contre les arrêts accidentels.

Fonctionnalités non prises en charge dans un EMR cluster Amazon comportant plusieurs nœuds principaux

Les EMR fonctionnalités Amazon suivantes ne sont actuellement pas disponibles dans un EMR cluster Amazon comportant plusieurs nœuds principaux :

• EMRCarnets

• Accès en un clic au serveur d'historique Spark permanent

• Interfaces utilisateur d'application persistante

• L'accès en un clic aux interfaces utilisateur persistantes des applications n'est actuellement pas disponible pour les EMR clusters Amazon dotés de plusieurs nœuds principaux ou pour les EMR clusters Amazon intégrés à AWS Lake Formation.

Note

Pour utiliser l'authentification Kerberos dans votre cluster, vous devez configurer une authentification externe. KDC

À partir de EMR la version 5.27.0 d'Amazon, vous pouvez configurer le chiffrement HDFS transparent sur un EMR cluster Amazon comportant plusieurs nœuds principaux. Pour plus d'informations, consultez la section Chiffrement transparent HDFS sur Amazon EMR.