Термін "поводитись із вашими серверами як з великою рогатою худобою, а не з домашніми тваринами" в останні роки поширився, особливо коли він застосовувався до контейнерів Docker та віртуальних машин
Що це насправді означає?
Відповіді:
Ренді Біас хронікує історію цього терміна, вказуючи, що він, ймовірно, зародився в 2011 або 2012 роках, коли Білл Бейкер використовував аналогію, описуючи архітектурні стратегії "масштабування" проти "масштабування". Біас прийняв це у своїх презентаціях щодо хмарних архітектурних моделей:
По-старому, ми ставимося до наших серверів як до домашніх тварин, наприклад, поштовому серверу Боба. Якщо Боб зійде, всі руки на палубі. Генеральний директор не може отримати свою електронну пошту, і це кінець світу. По-новому, сервери нумеруються, як худоба в стаді. Наприклад, від www001 до www100. Коли один сервер опускається, він виймається назад, знімається та замінюється на лінії.
Упередженість продовжує визначати домашніх тварин як
Сервери або серверні пари, які розглядаються як незамінні або унікальні системи, які ніколи не можуть бути знищені. Зазвичай вони будуються вручну, керуються ними та “подаються вручну”. Приклади включають мейнфрейми, одиночні сервери, балансири навантаження / брандмауери HA (активні / активні або активні / пасивні), системи баз даних, розроблені як головний / ведений (активний / пасивний) тощо.
а худобу як
Масиви більш ніж двох серверів, побудованих за допомогою автоматизованих інструментів, і призначені для виходу з ладу, де жоден, два чи навіть три сервери не є незамінними. Як правило, під час подій відмов не потрібно втручатися людиною, оскільки масив демонструє атрибути "маршрутизації навколо відмов" шляхом перезавантаження невдалих серверів або реплікації даних за допомогою таких стратегій, як потрійна реплікація або кодування стирання. Приклади включають масиви веб-серверів, багатомастерні сховища даних, такі як кластери Кассандри, кілька стійок передач, зібраних у кластери, і майже все, що є збалансованим навантаженням і мультимайстерним.
По суті, те, що намагаються передати Біас та Бейкер, має бути переходом від того, як ми ставимось до серверів, а не від того, щоб бути «Унікальними сніжинками» з іменами та емоційними вкладеннями, до моделі, за якої, якщо у нас є проблеми із сервером, ми створюємо заміну і знищити проблемний сервер.
Нарешті, напевно, варто згадати, що в регульованих умовах виймання сервера назад та зйомка може виявитися не оптимальним. У цих випадках часто вигідно «заморозити» сервер, наприклад, використовуючи docker pauseдля заморозки контейнера. Потім це може бути використане для проведення аналізу причин кореневих даних як частини процесу управління випадками або проблемами.
Щоб додати відповідь Річардса, зазвичай аналогія є корисною з точки зору впливу на втрату сервера.
Якщо ви відчували б якусь скруту через втрату будь-якого окремого об’єкта інфраструктури, тоді вважайте це домашнім улюбленцем (читайте антипатерн).
Якщо ви відчуваєте себе досить комфортно, знаючи, що якщо будь-який флот перестане функціонувати, не буде реально впливати на операції, тоді ви говорите про велику рогату худобу.
Часто спокусливо використовувати аналогію для простої класифікації ваших серверів, тобто "наші вузли навантаження - велика рогата худоба, але наші балансири навантаження - домашні тварини", але потрапляння в цю пастку - це саме проблема. Немає місця для домашніх тварин у сучасних обчислювальних умовах (наприклад, у хмарі, товарному обладнання тощо). Якщо всі ваші сервери вважаються великою рогатою худобою та є легкозамінними, ви можете почати дивитися на речі, як мавпа хаосу, щоб допомогти створити впевненість, що ваша інфраструктура справді пружна.