Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Fonctionnalités garantissant la haute disponibilité dans un cluster Amazon EMR et leur fonctionnement avec les applications open source
Cette rubrique fournit des informations sur les fonctionnalités de haute disponibilité Hadoop de HDFS NameNode et YARN dans un cluster ResourceManager Amazon EMR, 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é de HDFS
Un cluster Amazon EMR avec plusieurs nœuds principaux permet de HDFS NameNode fonctionnalité de haute disponibilité dans Hadoop. Pour plus d'informations, consultez Haute disponibilité de HDFS
Dans un cluster Amazon EMR, au moins deux nœuds distincts 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 basculement HDFS 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 en échec par un nouveau, puis le rejoint en tant que standby.
Note
Dans les versions 5.23.0 et 5.30.1 incluses d'Amazon EMR, seuls deux des trois nœuds principaux exécutent HDFS. NameNode
Si vous avez besoin de savoir lequel NameNode estactive, vous pouvez 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
FIL À HAUTE DISPONIBILITÉ ResourceManager
Un cluster Amazon EMR avec plusieurs nœuds principaux active la fonctionnalité de ResourceManager haute disponibilité YARN dans Hadoop. Pour plus d'informations, consultez la section ResourceManager Haute disponibilité
Dans un cluster Amazon EMR comportant plusieurs nœuds principaux, 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 que. standby
Vous pouvez vous connecter à « http : //:8088/cluster master-public-dns-name » pour n'importe quel nœud principal, qui vous dirige automatiquement vers le gestionnaire de ressources. active Pour déterminer quel gestionnaire de ressources est active, utilisez SSH pour vous connecter à un nœud primaire dans le 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 cluster Amazon EMR avec plusieurs nœuds primaires
Vous pouvez installer et exécuter les applications suivantes sur un cluster Amazon EMR comportant plusieurs nœuds primaires. 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 tâches Flink sur Amazon EMR s'exécutent en tant qu'applications YARN. Flink JobManagers fonctionne en tant que YARN ApplicationMasters sur 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 s' JobManager 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 cluster Amazon EMR doté de plusieurs nœuds primaires. À partir de la version 5.28.0 d'Amazon EMR, aucune configuration manuelle n'est nécessaire pour activer la haute disponibilité. JobManager |
| 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 basculent automatiquement vers le nœud de secours lorsque le nœud principal actif tombe en panne. |
| HBase |
Haute disponibilité |
HBase bascule 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 |
HCatalog est basé sur le métastore Hive, qui existe en dehors du cluster. HCatalog reste 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' MXNet a 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 |
| 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 des conteneurs YARN et peuvent réagir au basculement du nœud primaire de la même manière que les fonctionnalités de haute disponibilité de 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é |
Puisque les conteneurs Tez s'exécutent sur YARN, Tez se comporte de la même manière que YARN lors du processus de basculement du nœud primaire. |
| 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 dans HDFS par défaut pour éviter la 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 la base de la fonction de basculement automatique HDFS. 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 de plus amples informations, veuillez consulter Basculement automatique de HDFS |
Pour exécuter les applications suivantes dans un cluster Amazon EMR doté de plusieurs nœuds primaires, 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 métastore externe MySQL, car PostgreSQL n'est 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 dans 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 Utilisation d'Oozie avec une base de données distante dans 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 PrestoSQL/Trino |
Haute disponibilité pour les composants de service uniquement |
Un métastore Hive externe pour PrestoDB (PrestoSQL sur Amazon EMR 6.1.0-6.3.0 ou Trino sur Amazon EMR 6.4.0 et versions ultérieures) est requis. Vous pouvez utiliser Presto avec le AWS Glue Data Catalog ou utiliser une base de données MySQL externe pour Hive. Presto CLI est installé sur les trois nœuds primaires afin que vous puissiez l'utiliser pour accéder au coordinateur Presto depuis n'importe lequel des nœuds primaires. Presto Coordinator est installé sur un seul nœud primaire. Vous pouvez trouver le nom DNS du nœud primaire sur lequel le coordinateur Presto est installé en appelant l'API Amazon EMR |
Note
Lorsqu'un nœud primaire échoue, votre Java Database Connectivity (JDBC) ou Open Database Connectivity (ODBC) met fin à sa connexion au nœud primaire. 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 les fonctionnalités Amazon EMR fonctionnent dans un cluster avec plusieurs nœuds primaires
Connexion aux nœuds primaires à l'aide de SSH
Vous pouvez vous connecter à l'un des trois nœuds primaires dans un cluster Amazon EMR à l'aide de SSH de la même manière que vous vous connectez à un seul nœud primaire. Pour plus d'informations, consultez Se connecter au nœud primaire à l'aide de SSH.
En cas de défaillance d'un nœud primaire, votre connexion SSH à ce nœud primaire 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 primaire une fois qu'Amazon EMR remplace celui en échec 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 à l'aide de la commande describe-cluster de l' AWS
CLI.
NameNode ne fonctionne que sur deux des nœuds principaux. Cependant, vous pouvez exécuter les commandes de l'interface de ligne de commande hdfs et exploiter des tâches pour accéder à HDFS sur les trois nœuds maîtres.
Utilisation des étapes dans un cluster Amazon EMR avec plusieurs nœuds primaires
Vous pouvez soumettre des étapes à un cluster Amazon EMR avec plusieurs nœuds primaires de la même manière que vous travaillez avec des étapes dans un cluster avec un seul nœud primaire. Pour plus d'informations, consultez Soumission de travail à un cluster.
Voici les points à prendre en compte lors de l'utilisation des étapes dans un cluster Amazon EMR comportant plusieurs nœuds primaires :
-
Si un nœud primaire échoue, les étapes en cours d'exécution sur le nœud primaire sont marquées comme FAILED. Toutes les données écrites en local sont perdues. Toutefois, 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 application YARN lorsque le nœud primaire échoue, l'étape peut continuer et réussir grâce au basculement automatique du nœud primaire.
-
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
_SUCCESSfichier pour déterminer si elles se terminent correctement. -
Il est recommandé de définir le ActionOnFailure paramètre sur CONTINUE, ou CANCEL_AND_WAIT, au lieu de TERMINATE_JOB_FLOW ou TERMINATE_CLUSTER.
Protection contre la résiliation automatique
Amazon EMR active automatiquement la protection contre les résiliations pour tous les clusters comportant plusieurs nœuds primaires 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 Résiliation d'un cluster Amazon EMR avec plusieurs nœuds primaires.
Pour plus d'informations sur la protection contre les résiliations, consultez Utilisation de la protection contre la résiliation pour protéger vos clusters Amazon EMR d'un arrêt accidentel.
Fonctions non prises en charge dans un cluster Amazon EMR avec plusieurs nœuds primaires
Les fonctionnalités Amazon EMR suivantes ne sont actuellement pas disponibles dans un cluster Amazon EMR comportant plusieurs nœuds primaires :
-
Blocs-notes EMR
-
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 clusters Amazon EMR dotés de plusieurs nœuds principaux ou pour les clusters Amazon EMR intégrés à Lake Formation. AWS
Note
Pour utiliser l'authentification Kerberos dans votre cluster, vous devez configurer un KDC externe.
À partir de la version 5.27.0 d'Amazon EMR, vous pouvez configurer le chiffrement HDFS transparent sur un cluster Amazon EMR comportant plusieurs nœuds primaires. Pour plus d'informations, consultez Chiffrement transparent dans HDFS sur Amazon EMR.
