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

Tenez compte des points suivants lorsque vous créez un EMR cluster Amazon avec plusieurs nœuds principaux :

Important

Pour lancer des EMR clusters à haute disponibilité avec plusieurs nœuds principaux, nous vous recommandons vivement d'utiliser la dernière EMR version d'Amazon. 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 EMR 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. Pour les groupes d'instances, la haute disponibilité est prise en charge par les EMR versions 5.23.0 et supérieures d'Amazon. Pour en savoir plus, consultez À propos des EMR versions d'Amazon.

• Sur les clusters à haute disponibilité, Amazon prend EMR uniquement en charge le lancement de nœuds principaux avec des instances On Demand. 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 deux nœuds principaux tombent en panne simultanément, votre EMR cluster échouera.

• Tous les EMR clusters, 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 élimine EMR les types d'instance de nœuds principaux AZs qui ne prennent en charge aucun type d'instance, 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 spécifiées dansApplications prises en charge dans un EMR cluster Amazon avec plusieurs nœuds principaux.

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

• Dans les EMR versions 6.x et supérieures d'Amazon, 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 EMR cluster Amazon comportant plusieurs nœuds principaux ne peut résider que dans une seule zone de disponibilité ou sous-réseau. Amazon EMR ne peut pas remplacer un nœud principal défaillant si le sous-réseau est entièrement utilisé ou si le sous-réseau est surabonné en cas de basculement. Pour éviter ce scénario, il est recommandé de dédier un sous-réseau entier à un EMR cluster Amazon. 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 au moins 2 HDFS pour une DFS réplication suffisante. Pour plus d'informations, consultez HDFSla section configuration.

Avertissement

1. La dfs.replication valeur 1 sur les clusters de moins de quatre nœuds peut entraîner une perte de HDFS données 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 n'EMRautorisera pas les clusters à dimensionner les nœuds principaux situés en dessousdfs.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 de statistiques spécifiques à l'application concernant 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 ce cas, Amazon EMR tente de remplacer un nœud principal.

  • 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.