Jaka jest definicja „bydła, a nie zwierząt domowych”?

Termin „traktuj swoje serwery jak bydło, a nie zwierzęta domowe” rozpowszechnił się w ostatnich latach, szczególnie w odniesieniu do kontenerów Docker i maszyn wirtualnych

Co to właściwie znaczy?

Randy Bias kronika historii tego terminu, stwierdzając, że prawdopodobnie powstał on w 2011 lub 2012 roku, kiedy Bill Baker zastosował analogię, opisując strategie architektoniczne „skalowalne” i „skalowalne”. Bias zastosował to w swoich prezentacjach na temat wzorów architektonicznych w chmurze:

W starym stylu działania traktujemy nasze serwery jak zwierzęta domowe, na przykład Bob - serwer pocztowy. Jeśli Bob upada, wszystko zależy od pokładu. Prezes nie może dostać swojego e-maila, a to koniec świata. W nowy sposób serwery są ponumerowane, jak bydło w stadzie. Na przykład od www001 do www100. Kiedy jeden serwer przestaje działać, jest usuwany, strzelany i zastępowany na linii.

Odchylenie nadal definiuje Zwierzęta jako

Serwery lub pary serwerów, które są traktowane jako niezbędne lub unikalne systemy, które nigdy nie mogą ulec awarii. Zazwyczaj są one ręcznie budowane, zarządzane i „ręcznie karmione”. Przykłady obejmują komputery mainframe, samotne serwery, moduły równoważenia obciążenia / zapory HA (aktywne / aktywne lub aktywne / pasywne), systemy baz danych zaprojektowane jako master / slave (aktywne / pasywne) i tak dalej.

i bydło jako

Tablice więcej niż dwóch serwerów zbudowane przy użyciu zautomatyzowanych narzędzi i zaprojektowane pod kątem awarii, w których żaden, dwa, a nawet trzy serwery nie są niezastąpione. Zazwyczaj podczas zdarzeń awarii nie jest wymagana interwencja człowieka, ponieważ tablica wykazuje atrybuty „routingu wokół awarii” poprzez ponowne uruchomienie uszkodzonych serwerów lub replikację danych za pomocą strategii takich jak potrójna replikacja lub kodowanie kasowania. Przykłady obejmują tablice serwerów WWW, wielostanowiskowe magazyny danych, takie jak klastry Cassandra, wiele stojaków na sprzęt zebranych w klastry i prawie wszystko, co jest zrównoważone pod względem obciążenia i wielopanelowe.

Zasadniczo to, co Bias i Baker starają się przekazać, to musi nastąpić przejście od tego, jak traktujemy serwery z bycia „Unikalnymi płatkami śniegu” z nazwami i emocjonalnymi przywiązaniami, do modelu, w którym jeśli mamy problem z serwerem, tworzymy zamiennik i zniszcz problematyczny serwer.

Na koniec warto chyba wspomnieć, że w regulowanych środowiskach wyjmowanie serwera z tyłu i strzelanie może nie być optymalne. W takich przypadkach często korzystne jest „zamrożenie” serwera, na przykład za pomocą docker pausezamrożenia kontenera. Można to następnie wykorzystać do przeprowadzenia analizy przyczyny pierwotnej jako części procesu zarządzania incydentami lub problemami.

Aby dodać do odpowiedzi Richardsa, ogólnie analogia jest pomocna w rozważaniu wpływu utraty serwera.

Jeśli odczuwasz niepokój związany z utratą jakiejkolwiek części infrastruktury, zastanów się nad tym jako zwierzę domowe (czytaj antypattern).

Jeśli czujesz się komfortowo wiedząc, że jeśli któraś z flot przestanie funkcjonować, nie będzie to miało rzeczywistego wpływu na operacje, wtedy mówisz o bydle.

Często kuszące jest użycie analogii do zwykłej klasyfikacji serwerów, tzn. „Nasze węzły obciążenia są bydłem, ale nasze równoważniki obciążenia są zwierzętami domowymi”, ale wpadnięcie w tę pułapkę stanowi właśnie problem. W nowoczesnym środowisku komputerowym (np. W chmurze, na sprzęcie towarowym itp.) Nie ma miejsca dla zwierząt domowych. Jeśli wszystkie Twoje serwery są uważane za bydło i można je łatwo wymienić, możesz zacząć szukać pomocy małpy chaosu zapewnij, że twoja infrastruktura jest naprawdę odporna.