Considérations et bonnes pratiques

Limites d'un cluster Amazon EMR comportant plusieurs nœuds primaires :

• Vous ne pouvez pas utiliser un cluster Amazon EMR avec plusieurs nœuds primaires avec des parcs d'instances. Pour plus d'informations sur les fonctionnalités Amazon EMR qui fonctionnent avec plusieurs nœuds primaires, consultez Applications et fonctionnalités prises en charge.

• Si les deux nœuds primaires échouent simultanément, Amazon EMR ne peut pas récupérer le cluster.

• Les clusters Amazon EMR comportant plusieurs nœuds primaires 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 EMR.

• Amazon EMR ne garantit pas les fonctionnalités de haute disponibilité pour les 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.30.1 d'Amazon EMR, seuls deux des trois nœuds primaires 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 :

• Pour vous assurer que le groupe d'instances du nœud principal dispose également d'une haute disponibilité, nous vous recommandons de lancer au moins quatre nœuds principaux. 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 en utilisant les métriques Amazon CloudWatch suivantes : MultiMasterInstanceGroupNodesRunning, MultiMasterInstanceGroupNodesRunningPercentage ou MultiMasterInstanceGroupNodesRequested. CloudWatch vous informera en cas de défaillance et de remplacement du nœud primaire.

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