Quelle est la définition de «bétail sans animaux de compagnie»?

Le terme "traitez vos serveurs comme du bétail, pas des animaux domestiques" a proliféré ces dernières années, en particulier lorsqu'il est appliqué aux conteneurs Docker et aux machines virtuelles.

Qu'est-ce que cela signifie réellement?

Randy Bias fait la chronique de l'histoire du terme, affirmant qu'il a probablement été créé en 2011 ou 2012 lorsque Bill Baker a utilisé l'analogie pour décrire les stratégies architecturales «passage à l'échelle» ou «montée en puissance». Bias a repris cela dans ses présentations sur les schémas architecturaux du cloud:

Dans l'ancienne façon de faire, nous traitions nos serveurs comme des animaux domestiques, par exemple Bob le serveur de messagerie. Si Bob tombe, tout est sur le pont. Le PDG ne peut pas obtenir son email et c'est la fin du monde. À la nouvelle manière, les serveurs sont numérotés, comme du bétail dans un troupeau. Par exemple, www001 à www100. Lorsqu'un serveur tombe en panne, il est retiré, remplacé et remplacé sur la ligne.

Bias continue de définir les animaux de compagnie comme

Des serveurs ou des paires de serveurs traités comme des systèmes indispensables ou uniques ne pouvant jamais être en panne. Généralement, ils sont construits, gérés et alimentés manuellement. Les exemples incluent les ordinateurs centraux, les serveurs solitaires, les équilibreurs de charge / pare-feu haute disponibilité (actifs / actifs ou actifs / passifs), les systèmes de base de données conçus comme maîtres / esclaves (actifs / passifs), etc.

et le bétail comme

Matrices de plus de deux serveurs, construites à l'aide d'outils automatisés et conçues pour les pannes, dans lesquelles aucun, deux ou même trois serveurs ne sont irremplaçables. Généralement, pendant les événements de défaillance, aucune intervention humaine n'est requise car le tableau présente les attributs de «routage autour des défaillances» en redémarrant les serveurs défaillants ou en répliquant les données au moyen de stratégies telles que la réplication triple ou le codage d'effacement. Les exemples incluent les baies de serveurs Web, les banques de données multi-maîtres telles que les clusters Cassandra, les racks d’engins multiples regroupés en grappes et à peu près tout ce qui est équilibré en charge et multi-maître.

Fondamentalement, ce que Bias et Baker tentent de faire comprendre, c’est qu’il faut passer de la façon dont nous traitons les serveurs, qui ne sont plus que des "flocons de neige uniques" avec des noms et des liens affectifs, à un modèle selon lequel nous avons un remplacement en cas de problème avec le serveur. et détruire le serveur problématique.

Enfin, il est probablement utile de mentionner que, dans les environnements réglementés, retirer un serveur à l'arrière et filmer peut ne pas être optimal. Dans ces cas, il est souvent avantageux de "geler" le serveur, par exemple en utilisant docker pausepour geler un conteneur. Cela peut ensuite être utilisé pour effectuer une analyse de la cause première dans le cadre du processus de gestion des incidents ou des problèmes.

Pour ajouter à la réponse de Richards, l'analogie est généralement utile en termes de prise en compte de l'impact de la perte d'un serveur.

Si vous ressentez une sorte de détresse à la suite de la perte d’un élément d’infrastructure individuel, alors considérez-le comme un animal de compagnie (lisez l’annexe).

Si vous vous sentez assez à l'aise en sachant que si une partie de la flotte cesse de fonctionner, cela n'aura aucun impact réel sur les opérations, alors vous parlez de bétail.

Il est souvent tentant d’utiliser cette analogie pour simplement classer vos serveurs, c’est-à-dire que "nos nœuds de charge de travail sont du bétail mais que nos équilibreurs de charge sont des animaux domestiques", mais le problème est précisément de tomber dans ce piège. Il n’ya pas de place pour les animaux de compagnie dans un environnement informatique moderne (dans le cloud, sur du matériel de base, etc.) Si tous vos serveurs sont considérés comme du bétail et sont facilement remplaçables, alors vous pouvez commencer à regarder des choses comme chaos monkey pour vous aider Assurez-vous que votre infrastructure est vraiment résiliente.