Considérations et bonnes pratiques lors de la création d'un cluster Amazon EMR avec plusieurs nœuds principaux - Amazon EMR

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.

Considérations et bonnes pratiques lors de la création d'un cluster Amazon EMR avec plusieurs nœuds principaux

Tenez compte des éléments suivants lorsque vous créez un cluster Amazon EMR doté de plusieurs nœuds primaires :

Important

Pour lancer des clusters EMR à haute disponibilité dotés de plusieurs nœuds primaires, nous vous recommandons vivement d’utiliser la dernière version d’Amazon EMR. Vous vous assurez ainsi de bénéficier du plus haut niveau de résilience et de stabilité pour vos clusters à haute disponibilité.

  • La haute disponibilité des flottes d'instances est prise en charge par les versions 5.36.1, 5.36.2, 6.8.1, 6.9.1, 6.10.1, 6.11.1, 6.12.0 et supérieures d'Amazon EMR. Pour les groupes d’instances, la haute disponibilité est prise en charge avec les versions 5.23.0 et les versions ultérieures d’Amazon EMR. Pour plus d’informations, voir À propos des versions d’Amazon EMR.

  • Sur les clusters à haute disponibilité, Amazon EMR prend uniquement en charge le lancement de nœuds primaires avec des instances à la demande. Cela garantit une disponibilité maximale pour votre cluster.

  • Vous pouvez toujours spécifier plusieurs types d’instances pour la flotte principale, mais tous les nœuds primaires des clusters à haute disponibilité sont lancés avec le même type d’instance, y compris les remplacements des nœuds primaires défectueux.

  • Pour qu’un cluster à haute disponibilité doté de plusieurs nœuds primaires continue à fonctionner, deux nœuds primaires sur trois doivent être sains. Par conséquent, si les deux nœuds primaires présentent une défaillance simultanément, votre cluster EMR présentera lui aussi une défaillance.

  • Tous les clusters EMR, y compris les clusters à haute disponibilité, sont lancés dans une seule zone de disponibilité. Par conséquent, ils ne peuvent pas tolérer les défaillances des zones de disponibilité. Dans le cas d’une panne d’une zone de disponibilité, vous perdez l’accès au cluster.

  • Si vous utilisez un rôle ou une politique de service personnalisé lorsque vous lancez un cluster au sein d'un parc d'instances, vous pouvez ajouter l'ec2:DescribeInstanceTypeOfferingsautorisation afin qu'Amazon EMR puisse filtrer les zones de disponibilité (AZ) non prises en charge. Lorsqu'Amazon EMR filtre ceux AZs qui ne prennent en charge aucun type d'instance de nœuds principaux, Amazon EMR empêche les lancements de clusters d'échouer en raison de types d'instances principales non pris en charge. Pour plus d'informations, consultez la section Type d'instance non pris en charge.

  • Amazon EMR ne garantit pas la haute disponibilité des applications open source autres que celles qui sont spécifiées dans Applications prises en charge dans un cluster Amazon EMR avec plusieurs nœuds primaires.

  • Dans les versions 5.23.0 à 5.36.2 d'Amazon EMR, seuls deux des trois nœuds principaux d'un cluster de groupes d'instances étaient exécutés HDFS NameNode.

  • Dans les versions 6.x et supérieures d'Amazon EMR, les trois nœuds principaux d'un groupe d'instances s'exécutent HDFS NameNode.

Considérations relatives à la configuration d’un sous-réseau :

  • Un cluster Amazon EMR comportant plusieurs nœuds primaires ne peut résider que dans une seule zone de disponibilité ou sous-réseau. Amazon EMR ne peut pas remplacer un nœud primaire en échec si le sous-réseau est entièrement utilisé ou congestionné dans le cas d'un basculement. Pour éviter ce scénario, il est recommandé de dédier l'ensemble d'un sous-réseau à un cluster Amazon EMR. En outre, assurez-vous qu'il y ait suffisamment d'adresses IP privées disponibles dans le sous-réseau.

Considérations relatives à la configuration de nœuds principaux :

  • Nous vous recommandons de lancer au moins quatre nœuds principaux pour vous assurer que les nœuds principaux sont également hautement disponibles. Si vous décidez de lancer un cluster plus petit avec trois nœuds principaux ou moins, définissez dfs.replication parameter sur au moins 2 pour que HDFS ait une réplication DFS suffisante. Pour de plus amples informations, veuillez consulter Configuration de HDFS.

Avertissement

  1. Paramétrer dfs.replication sur la valeur 1 avec les clusters de moins de quatre nœuds peut entraîner une perte de données HDFS en cas de panne d'un seul nœud. Nous vous recommandons d'utiliser un cluster comportant au moins quatre nœuds principaux pour les charges de travail de production.

  2. Amazon EMR n'autorisera pas les clusters à mettre à l'échelle les nœuds principaux situés en dessous de dfs.replication. Par exemple, si dfs.replication = 2, le nombre minimum de nœuds principaux est 2.

  3. Lorsque vous utilisez la mise à l'échelle gérée, autoscaling, ou que vous choisissez de redimensionner manuellement votre cluster, nous vous recommandons de définir dfs.replication sur une valeur supérieure ou égale à 2.

Considérations relatives à la configuration d'alarmes sur les métriques :

  • Amazon EMR ne fournit pas les métriques spécifiques à une application donnée sur HDFS ou YARN. Nous vous reccomandons de configurer des alarmes pour surveiller le nombre d'instances du nœud primaire. Configurez les alarmes à l'aide CloudWatch des métriques Amazon suivantes : MultiMasterInstanceGroupNodesRunningMultiMasterInstanceGroupNodesRunningPercentage, ouMultiMasterInstanceGroupNodesRequested. CloudWatch vous informera en cas de défaillance ou de remplacement du nœud principal.

    • Si le MultiMasterInstanceGroupNodesRunningPercentage est inférieur à 1,0 et supérieur à 0,5, le cluster peut avoir perdu un nœud primaire. Dans cette situation, Amazon EMR tente de remplacer un nœud primaire.

    • Si le MultiMasterInstanceGroupNodesRunningPercentage passe en dessous de 0,5, deux nœuds primaires peuvent avoir échoué. Dans ce cas, le quorum est perdu et le cluster ne peut pas être récupéré. Vous devez migrer manuellement les données hors de ce cluster.

    Pour de plus amples informations, veuillez consulter Configuration d'alarmes sur les métriques.