Der Begriff "Behandeln Sie Ihre Server wie Vieh, nicht wie Haustiere" hat in den letzten Jahren zugenommen, insbesondere bei Docker-Containern und virtuellen Maschinen
Was heißt das eigentlich?
Antworten:
Randy Bias zeichnet die Geschichte des Begriffs auf und gibt an, dass er wahrscheinlich im Jahr 2011 oder 2012 entstanden ist, als Bill Baker die Analogie bei der Beschreibung der Architekturstrategien "Scale-up" vs. "Scale-out" verwendete. Bias übernahm dies in seinen Präsentationen über Cloud-Architekturmuster:
Wie früher behandeln wir unsere Server wie Haustiere, zum Beispiel den Mailserver Bob. Wenn Bob untergeht, sind alle Hände an Deck. Der CEO kann seine E-Mail nicht erhalten und es ist das Ende der Welt. Auf die neue Art und Weise werden Server wie Rinder in einer Herde nummeriert. Zum Beispiel www001 bis www100. Wenn ein Server ausfällt, wird er zurückgenommen, abgeschossen und in der Leitung ersetzt.
Bias definiert Haustiere weiterhin als
Server oder Serverpaare, die als unverzichtbare oder einzigartige Systeme behandelt werden, die niemals außer Betrieb sein können. In der Regel werden sie manuell erstellt, verwaltet und von Hand eingezogen. Beispiele hierfür sind Mainframes, einzelne Server, HA-Loadbalancer / Firewalls (aktiv / aktiv oder aktiv / passiv), als Master / Slave (aktiv / passiv) konzipierte Datenbanksysteme usw.
und Vieh als
Arrays mit mehr als zwei Servern, die mit automatisierten Tools erstellt wurden und für Ausfälle ausgelegt sind, bei denen keiner, zwei oder sogar drei Server unersetzbar sind. In der Regel ist bei Fehlerereignissen kein menschliches Eingreifen erforderlich, da das Array die Attribute "Umleiten von Fehlern" aufweist, indem ausgefallene Server neu gestartet oder Daten mithilfe von Strategien wie dreifacher Replikation oder Löschcodierung repliziert werden. Beispiele hierfür sind Webserver-Arrays, Multi-Master-Datenspeicher wie Cassandra-Cluster, mehrere in Clustern zusammengefasste Racks sowie nahezu alles, was mit Lastenausgleich und Multi-Master zu tun hat.
Grundsätzlich versuchen Bias und Baker zu vermitteln, dass es einen Übergang von der Art und Weise, wie wir Server als "einzigartige Schneeflocken" mit Namen und emotionalen Bindungen behandeln, zu einem Modell geben muss, bei dem wir bei Problemen mit dem Server einen Ersatz erstellen und zerstören Sie den problematischen Server.
Schließlich ist es wahrscheinlich erwähnenswert, dass in regulierten Umgebungen das Herausnehmen und Aufnehmen eines Servers möglicherweise nicht optimal ist. In diesen Fällen ist es oftmals vorteilhaft, den Server "einzufrieren", beispielsweise docker pauseum einen Container einzufrieren. Dies kann dann verwendet werden, um eine Ursachenanalyse als Teil des Incident- oder Problem-Management-Prozesses durchzuführen .
Um die Antwort von Richards zu ergänzen, ist die Analogie im Allgemeinen hilfreich, um die Auswirkungen des Verlusts eines Servers zu berücksichtigen.
Wenn Sie sich über den Verlust eines einzelnen Teils der Infrastruktur aufgeregt fühlen, dann betrachten Sie es als Haustier (lesen Sie Antimuster).
Wenn Sie sich ziemlich sicher fühlen würden, wenn Sie wissen, dass ein Ausfall der Flotte keine wirklichen Auswirkungen auf den Betrieb hätte, dann sprechen Sie von Rindern.
Es ist oft verlockend, die Analogie zu verwenden, um Ihre Server einfach zu klassifizieren, dh "unsere Workload-Knoten sind Vieh, aber unsere Load Balancer sind Haustiere", aber genau in diese Falle zu tappen, ist das Problem. In einer modernen Computerumgebung ist kein Platz für Haustiere vorhanden (z. B. in der Cloud, auf Standardhardware usw.). Wenn alle Ihre Server als Vieh betrachtet werden und leicht austauschbar sind, können Sie sich Dinge wie Chaos Monkey ansehen, um zu helfen Stellen Sie sicher, dass Ihre Infrastruktur wirklich stabil ist.