Combien de nœuds puis-je gérer avec une seule instance du serveur chef ?

Question

Je suis en train de configurer un serveur chef et je m'attends à gérer plus de 500 nœuds par le biais de ce serveur - peut-être près de 1000. Est-ce que je peux m'attendre à ce que cela fonctionne efficacement sur une instance extra-large sur EC2 ? Devrais-je envisager d'exécuter rabbitmq, solr, etc. sur des serveurs distincts ? Est-il possible d'exécuter le serveur chef lui-même dans une configuration distribuée ?

Answer 1

Mise à jour

Chef 11 est sorti au début de l'année. Avec la sortie de cette version, il y a eu quelques communiqués de presse / études de cas pour des entreprises avec lesquelles Opscode a travaillé pour des tests de scalabilité. Il convient de noter que Facebook et Cycle Computing ont géré des clusters de plus de 10 000 nœuds avec un seul serveur Chef. Les spécifications du serveur Chef sont modestes, mais non divulguées. De plus amples informations sont disponibles ici :

• Annonce du Chef 11
• Annonce sur Facebook
• Phil Dibowitz, Facebook, spotlight
• L'intervention de Phil à ChefConf
• Etude de cas Cycle Computing

Il est important de noter que ceci s'applique à la fois à Open Source Chef Server et à Enterprise Chef. Le service Hosted Enterprise Chef d'Opscode est essentiellement une énorme instance d'Enterprise Chef, puisqu'il utilise fondamentalement la "même" base de code.

(pas précisément la même chose, car Opscode a des personnalisations et des services supplémentaires qui sont nécessaires pour gérer une plateforme SaaS accessible au public qui permet à plusieurs clients de payer et d'utiliser).

Cette page sur le wiki Chef contient de nombreux liens et informations utiles :

• http://wiki.opscode.com/display/chef/Scalability+et+haute+disponibilité

Quelques points à considérer :

1. La métrique qui compte n'est pas le nombre de nœuds, c'est le nombre de nœuds convergeant dans le temps que vous attendez. Par exemple, 500 nœuds qui exécutent Chef une fois par jour représentent une charge moindre pour le serveur que 50 nœuds qui exécutent Chef toutes les 10 minutes. Bien sûr, 500 nœuds exécutant Chef toutes les 10 minutes (ou même 30 minutes, un intervalle de temps courant) représentent une charge importante pour le système.

2. Chef Server a été conçu comme un système distribué afin que les composants puissent fonctionner sur des nœuds séparés. C'est exactement comme cela que Opscode Hosted Chef y Opscode Private Chef travail - divers services sont exécutés sur des systèmes distincts pour répartir la charge. Si vous prévoyez que de nombreux nœuds exécuteront souvent Chef, vous devez absolument exécuter les services sur des systèmes distincts. Le site Paramètres de configuration du chef La page sur le wiki décrit les options de configuration des services.

3. Haute disponibilité et évolutivité ne sont pas la même chose et nécessitent des approches différentes. Les différences entre ces deux notions sortent entièrement du cadre de Chef. Le " Évolutivité et haute disponibilité La page " " devrait aider, cependant.

4. La version Chef 10.x ou 0.10.x utilise un service API basé sur Ruby, et CouchDB comme magasin de données back-end. A l'échelle de Hosted Chef, Opscode a trouvé des problèmes d'extensibilité, qui sont décrits dans le document suivant Intervention de Seth Falcon à la ChefConf 2012 . Bien que cette présentation porte principalement sur une migration en direct des données des clients, il y a plusieurs points concernant l'évolutivité par rapport à CouchDB. Egalement, Chef 11 sera migré vers un service API basé sur Erlang. et SQL (MySQL) ou PostgreSQL) comme magasin de données dorsal.

5. Mise à jour La version Chef 11 du serveur Chef Open Source implique une réécriture complète du service API du serveur en Erlang comme décrit précédemment. Les informations figurant en haut de cette réponse permettent de mieux comprendre ce que tout cela signifie, avec des études de cas et des exposés.

Answer 2

@jtimberman résume assez bien la situation et vous pouvez effectivement faire évoluer les choses jusqu'à un certain point en répartissant le service Chef sur un certain nombre de nœuds distincts et en y affectant davantage de ressources.

À titre d'exemple, j'ai vu ~700 clients gérés par un seul serveur Chef 10.x (open source) avec solr et couchdb sur des nœuds séparés.