Je voudrais poser une question sur une bonne pratique décrite dans ce document:

http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf

Utilisez plusieurs routeurs de requêtes. Utilisez plusieurs processus mongos répartis sur plusieurs serveurs. Un déploiement courant consiste à colocaliser le processus mongos sur les serveurs d'applications, ce qui permet une communication locale entre l'application et le processus mongos. Le nombre approprié de processus mongos dépendra de la nature de l'application et du déploiement.

Juste un peu d'histoire sur notre déploiement. Nous avons beaucoup de nœuds de serveur d'applications. Chacun d'eux exécute un processus basé sur JVM avec WS RESTful sans état. Comme le suggère cette meilleure pratique, chaque nœud de serveur d'applications exécute son propre mongosprocessus, ce qui signifie que le nombre de processus JVM est toujours égal au nombre de mongosprocessus.

Tous les mongosprocessus se connectent à 3 serveurs de configuration et à plusieurs fragments de mongo (avec des jeux de réplicas dans chaque fragment). Même si nous utilisons un déploiement fragmenté, nous ne partageons pas vraiment nos collections. En fait, nous avons un grand nombre de bases de données qui sont réparties sur tous les fragments au moment de leur création (et c'est notre principal cas d'utilisation pour le partage en ce moment).

Étant donné que les meilleures pratiques suggèrent également que "le nombre approprié de processus mongos dépendra de la nature de l'application et du déploiement", j'ai commencé à me demander si notre utilisation de mongosest réellement appropriée ou s'il serait préférable pour nous d'avoir plusieurs mongosnœuds dédiés et de laisser nos serveurs d'applications s'y connectent sans avoir à mongoss'exécuter localement.

Quelle est votre opinion sur la meilleure approche pour décider du nombre d' mongosinstances appropriées par rapport au nombre d'instances du serveur d'applications ou à la taille du cluster MongoDB?

Récemment, nous avons commencé à étudier la gestion des clusters pour nos services Web sans état, c'est-à-dire des outils comme Docker, Apache Mesos et Kubernetes. Si nous utilisons Docker, il est généralement déconseillé d'exécuter plusieurs processus dans le conteneur. Compte tenu de ce fait, il devient vraiment difficile de s'assurer que le conteneur du serveur d'applications et le mongosconteneur sont toujours colocalisés sur le même nœud physique et ont une quantité égale de processus. Cela me fait me demander si cette meilleure pratique s'applique toujours à l'architecture de cluster que je viens de décrire. Sinon, pouvez-vous suggérer quelle serait la meilleure façon de localiser et de déployer des mongosprocessus dans cette architecture?

Puisqu'il y a déjà et une réponse soumise, et une réponse utile et valide à cela, je ne veux pas me distraire de sa propre utilité, mais il y a effectivement des points à soulever qui vont bien au-delà d'un bref commentaire. Considérez donc cette "augmentation", qui, nous l'espérons, est valable mais principalement en plus de ce qui a déjà été dit.

La vérité est de vraiment considérer "comment votre application utilise les données", et d'être également conscient des facteurs dans un "environnement fragmenté" ainsi que de votre "environnement de conteneur" proposé qui affectent cela.

Le cas d'arrière-plan

L'approche générale de la recommandation de pratique pour colocaliser le mongosprocessus avec l'instance d'application est d'éviter toute surcharge réseau requise pour que l'application communique avec ce mongosprocessus. Bien sûr, il est également "recommandé" de spécifier un certain nombre d' mongosinstances dans la chaîne de connexion de l'application dans le cas où le nœud "le plus proche" ne devrait pas être disponible pour une raison quelconque, puis un autre pourrait être sélectionné, bien qu'avec le surcoût possible de contacter un nœud distant.

Le cas du "docker" dont vous parlez semble quelque peu arbitraire. S'il est vrai que l'un des principaux objectifs des conteneurs (et avant cela, quelque chose comme les prisons BSD ou même chroot) est généralement d'atteindre un certain niveau d '«isolation des processus», il n'y a rien de vraiment mal à exécuter plusieurs processus tant que vous comprendre les implications.

Dans ce cas particulier, le mongosest censé être "léger" et exécuté en tant que "fonction supplémentaire" pour le processus de demande d'une manière qui est à peu près une partie "appariée" de l'application elle-même. Ainsi, les images docker elles-mêmes n'ont pas de processus de type "initd" mais il n'y a vraiment rien de mal à exécuter un contrôleur de processus comme supervisord (par exemple) en tant que processus principal du conteneur, ce qui vous donne ensuite un point de contrôle du processus sur ce conteneur aussi. Cette situation de «processus jumelés» est un cas raisonnable et aussi une demande assez courante qu'il existe une documentation officielle pour cela.

Si vous avez choisi ce type d'opération «jumelée» pour le déploiement, cela traite en effet le point principal de la gestion d'une mongosinstance sur la même connexion réseau et en fait une «instance de serveur» que le serveur d'applications lui-même. Il peut également être considéré en quelque sorte comme un cas où le "conteneur entier" devait échouer, alors ce nœud en lui-même serait tout simplement invalide. Non pas que je le recommanderais, et en fait, vous devriez probablement configurer des connexions pour rechercher d'autres mongosinstances même si celles-ci ne sont accessibles que via une connexion réseau qui augmente la latence.

Spécifique à la version / spécifique à l'utilisation

Maintenant que ce point est fait, l'autre considération ici revient à cette considération initiale de co-localiser le mongosprocessus avec l'application à des fins de latence du réseau. Dans les versions de MongoDB antérieures à 2.6 et en particulier en ce qui concerne les opérations telles que le cadre d'agrégation, le cas était qu'il y aurait beaucoup plus de trafic réseau et après le travail de traitement effectué par le mongosprocessus pour traiter les données de différents fragments . Ce n'est pas tellement le cas maintenant, car une grande partie de la charge de travail de traitement peut maintenant être effectuée sur ces fragments eux-mêmes avant de «distiller» le «routeur».

L'autre cas est les modèles d'utilisation de votre application en ce qui concerne le partage. Cela signifie que la charge de travail principale consiste à «distribuer les écritures» sur plusieurs fragments, ou bien à être une approche de «diffusion-collecte» dans la consolidation des demandes de lecture. Dans ces scénarios

Testez, testez puis testez à nouveau

Donc, le dernier point ici est vraiment explicite et se résume au consensus de base de toute réponse sensée à votre question. Ce n'est pas une nouveauté pour MongoDB ou toute autre solution de stockage, mais votre environnement de déploiement réel doit être testé sur ses «modèles d'utilisation» aussi proches de la réalité réelle que tout «test unitaire» des fonctionnalités attendues des composants principaux ou les résultats globaux doivent être testés.

Il n'y a vraiment pas de déclaration «définitive» pour dire «configurer de cette façon» ou «utiliser de cette façon» qui a du sens en dehors de tester ce qui «fonctionne le mieux» pour les performances et la fiabilité de votre application comme prévu.

Bien sûr, le «meilleur cas» sera toujours de ne pas «surcharger» les mongosinstances avec des demandes provenant de «nombreuses» sources de serveur d'applications. Mais ensuite, pour leur permettre une certaine "parité" naturelle qui peut être distribuée par les charges de travail des ressources disponibles pour avoir au moins "un" pool de ressources "qui peut être sélectionné, et idéalement dans de nombreux cas, mais en évitant la nécessité d'induire un supplément "frais généraux de transport réseau".

C'est le but, mais idéalement, vous pouvez "tester en laboratoire" les différentes configurations perçues afin d'arriver à une solution "la mieux adaptée" pour votre éventuelle solution de déploiement.

Je recommanderais également fortement les cours "gratuits" (comme dans la bière) disponibles comme déjà mentionné, et quel que soit votre niveau de connaissance. Je trouve que diverses sources de matériel de cours offrent souvent des «trésors cachés» pour donner plus de détails sur des choses que vous n'avez peut-être pas envisagées ou autrement négligées. La classe M102 mentionnée est construite et dirigée par Adam Commerford pour qui je peux attester qu'il possède un niveau élevé de connaissances sur les déploiements à grande échelle de MongoDB et d'autres architectures de données. Vaut le temps d'envisager au moins une nouvelle perspective sur ce que vous pensez peut-être déjà savoir.

Étant donné que les meilleures pratiques suggèrent également que "le nombre approprié de processus de mongos dépendra de la nature de l'application et du déploiement", j'ai commencé à me demander si notre utilisation des mongos était réellement appropriée.

Je pense que c'est une question à laquelle vous seul pouvez répondre, comme le mentionne la documentation.

L'une des stratégies recommandées est d'avoir un mongosservice sur chacun des nœuds d'application et peut-être même un nœud dédié supplémentaire pour une disponibilité supplémentaire. Comme vous l'avez actuellement, je ne vois rien de mal à votre déploiement actuel. Si rien ne change dans votre architecture, vous respectez actuellement les meilleures pratiques. Pourtant...

Si nous utilisons Docker, il est généralement déconseillé d'exécuter plusieurs processus dans le conteneur.

Étant donné que le mongosprocessus ne consomme pas beaucoup de ressources, vous pouvez également en placer une instance sur chacun de vos fragments et laisser chaque mongodnœud agir également en tant que mongosnœud. Cela peut avoir plus de sens si vous complexifiez légèrement l'architecture de votre serveur d'applications.

Personnellement, je ne connais pas trop ces produits, mais je vérifierais également auprès du fournisseur leurs recommandations, car ils mongospeuvent être moins intensifs que la plupart des autres processus que vous pourriez exécuter côte à côte.

Enfin, vous pouvez toujours engager des nœuds dédiés pour le mongosprocessus en fonction de votre échelle, de vos ressources, etc., ce qui correspondrait également aux meilleures pratiques. Le vrai point à retenir ici est que tant que vous avez un tas de mongosprocessus quelque part, vous vous portez bien.

Le nombre dépend vraiment de la taille de votre déploiement et des exigences de SLA. Si vous utilisez les fragments, vous en aurez plus qu'assez, mais si vous allez utiliser des nœuds dédiés, j'essaierais de faire correspondre le plus possible le nombre de nœuds d'application.

Vous pouvez regarder cette vidéo du cours en ligne MongoDB M102 qui aborde ces sujets et voudrez peut-être essayer de vous inscrire au cours M102 pour DBA la prochaine fois qu'il sera en session (gratuit, en ligne).