La disponibilité des bases de données est l'un des aspects les plus importants de l'architecture des applications. Bien que la prévention des temps d'arrêt des centres de données soit une évidence, cela finira par arriver à tout le monde. Même les centres de données les mieux gérés vont s'effondrer complètement de temps en temps. Par exemple, les pannes d'Amazon AWS du 26/08/13 et du 13/09/13. La question importante à se poser est de savoir si cela est acceptable pour votre application ? La plupart des applications peuvent tolérer des temps d'arrêt de temps en temps, cependant, certaines applications nécessitent une disponibilité proche de 100 % et l'architecture de base de données de ces applications nécessite une approche de conception plus délibérée. Les latences entre les centres de données ont tendance à être assez importantes, il faut donc bien réfléchir à la conception de votre déploiement d'hébergement MongoDB.
Objectifs de disponibilité de MongoDB
- Votre base de données doit être opérationnelle et accessible en écriture, même si un centre de données complet tombe en panne.
- Le basculement de votre base de données doit être automatique en cas de panne du serveur/centre de données.
- Une panne de serveur unique ne doit pas entraîner le basculement du serveur principal vers un autre centre de données.
Conception de centre de données
Afin de satisfaire nos objectifs, nous avons proposé trois conceptions de centre de données utilisant un jeu de réplicas 4+1 :
- Centre de données 1 : Primaire (Priorité 10), Secondaire 0 (Primaire 9)
- Centre de données 2 : Secondaire 1 (Priorité 8), Secondaire 2 (Priorité 7)
- Centre de données 3 : Arbitre
Nous plaçons deux membres à part entière dans chacun des deux premiers centres de données et un arbitre dans le troisième centre de données. Nous avons également configuré la priorité de chaque serveur afin de pouvoir contrôler quel membre devient principal en cas de panne du serveur.
Il y a quelques inconvénients à ce géo- architecture distribuée :
- Si vous avez une application gourmande en écriture, les secondaires d'un centre de données différent seront toujours à la traîne en raison de la plus grande latence. Si certaines données sont cruciales, vous pouvez utiliser une préoccupation d'écriture MongoDB de "Majorité" pour vous assurer que tous les nœuds valident les données.
- Les builds de la communauté MongoDB n'ont pas SSL activé. Vous souhaiterez peut-être créer une version avec SSL activé ou utiliser le DBaaS MongoDB sur ScaleGrid afin que les données circulant entre les régions soient chiffrées.
Disponibilité Amazon AWS/EC2
Si vous déployez MongoDB sur AWS, chaque centre de données de cette image correspond à une région Amazon et non à une zone de disponibilité. Amazon ne fournit pas de garanties de disponibilité dans une seule zone de disponibilité, les SLA s'appliquent à l'ensemble de la région. Si vous déployez dans des zones de disponibilité, votre SLA est de 99,95 %, ce qui reste un excellent SLA. Cependant, si une région entière tombe en panne, votre base de données tombera en panne. De plus, certaines régions AWS n'ont que deux zones de disponibilité, une attention particulière doit donc être accordée au placement du troisième nœud dans une région différente afin qu'un temps d'arrêt d'une seule région n'entraîne pas l'arrêt de toute la base de données.
Disponibilité à moindre coût dans toutes les zones géographiques
Une version plus simple de la même architecture n'utilise que trois serveurs et place une seule réplique dans chaque centre de données. L'inconvénient de cette approche est qu'une défaillance d'un seul serveur entraînera le déplacement du principal entre les centres de données. Cependant, cette architecture coûte moins cher que la première architecture. Selon votre scénario, cela pourrait fonctionner pour vous.
Il existe de nombreuses façons d'obtenir une disponibilité élevée avec MongoDB, et c'est exactement la manière qui répond à nos besoins. Si vous avez d'autres architectures intéressantes, veuillez nous envoyer un e-mail à [email protected]. Nous serions ravis de connaître votre avis !
