Si vous hébergez votre cluster MongoDB dans la région Amazon AWS US-East, le mois dernier a été assez intéressant :deux pannes en quatre semaines ont testé la disponibilité opérationnelle de votre cloud déploiements. Au moment où je tape cet article de blog, la région de Sao Paulo connaît également des problèmes de connectivité. Un nombre surprenant de bases de données de production n'ont pas survécu à la panne d'AWS. Nous avons eu l'occasion de parler à un certain nombre de clients MongoDB sur AWS pour comprendre comment la panne a affecté leurs déploiements. J'ai mené une enquête rapide auprès des personnes concernées, et voici les quatre principales raisons pour lesquelles les équipes ont subi des temps d'arrêt :
-
Exécution d'une instance autonome par rapport à un ensemble de répliques
Si vous utilisez un serveur de production MongoDB, il n'y a vraiment aucune excuse pour exécuter une instance autonome plutôt qu'un ensemble de réplicas. Créez un jeu de réplicas afin que vous puissiez avoir un secondaire vers le basculement en cas de défaillance du primaire.
-
Ne pas distribuer les répliques dans les zones de disponibilité
Assurez-vous de distribuer vos répliques dans différentes zones de disponibilité d'une région. De cette façon, si un seul AZ tombe en panne, comme cela s'est produit deux fois ce mois-ci, vos serveurs restants prendront le relais et vous aurez un cluster fonctionnel. Si votre région n'a que deux AZ, placez votre arbitre dans une autre région. Cela ne vous aidera cependant pas si toute la région tombe en panne. Si vous voulez survivre à l'échec de toute la région AWS, vous devrez répartir votre jeu d'instances dupliquées sur différentes régions.
-
Ne pas distribuer vos serveurs frontaux ou d'applications dans les zones de disponibilité
Assurez-vous de répartir vos frontaux sur différentes zones de disponibilité. Il ne sert à rien d'avoir votre base de données opérationnelle si votre front-end est en panne. Si vous avez des problèmes de coût, vous pouvez garder un front-end « arrêté » à jour dans chaque AZ que vous pouvez activer en cas de besoin. Une autre option consiste à avoir des frontaux de plus petite taille.
-
Connectez-vous au jeu de réplicas plutôt qu'à un seul serveur dans votre chaîne de connexion
Assurez-vous de vous connecter au jeu de réplicas au lieu d'un seul serveur. La syntaxe est différente pour différents pilotes, mais vérifiez la documentation de votre pilote pour vous assurer que vous utilisez la bonne syntaxe pour vous connecter au jeu de répliques au lieu d'un seul serveur. De cette façon, s'il y a un basculement, le pilote MongoDB fera ce qu'il faut et se connectera au nouveau primaire.
Chez ScaleGrid, nous automatisons tous les aspects opérationnels de votre déploiement afin que vous puissiez vous concentrer sur votre application et ne pas vous soucier des opérations. Lorsque vous créez un jeu de réplicas MongoDB avec ScaleGrid, nous distribuons automatiquement les réplicas dans les zones de disponibilité. Grâce à cette distribution, tous nos clients ont pu résoudre en toute sécurité le problème d'indisponibilité d'AWS. Si vous êtes intéressé par une lecture plus détaillée sur les aspects opérationnels de MongoDB, vous pouvez lire mon article de blog détaillé précédent - 10 questions à poser et à répondre lors de l'hébergement de MongoDB sur AWS
