Термин «относиться к вашим серверам как к домашним животным, а не домашним животным» получил широкое распространение в последние годы, особенно когда он применяется к контейнерам Docker и виртуальным машинам
Что это на самом деле означает?
Ответы:
Рэнди Биас ведет хронику истории термина, утверждая, что он, вероятно, возник в 2011 или 2012 годах, когда Билл Бейкер использовал аналогию при описании архитектурных стратегий «масштабирование» или «масштабирование». Биас применил это в своих презентациях об облачных архитектурных моделях:
По старинке мы относимся к нашим серверам как к домашним животным, например к почтовому серверу Бобу. Если Боб упадет, все руки на палубе. Генеральный директор не может получить свою электронную почту, и это конец света. По-новому, серверы нумеруются, как скот в стаде. Например, с www001 по www100. Когда один сервер выходит из строя, он вынимается, снимается и заменяется на линии.
Смещение продолжает определять домашних животных как
Серверы или пары серверов, которые рассматриваются как незаменимые или уникальные системы, которые никогда не могут быть недоступны. Как правило, они создаются вручную, управляются и «подаются вручную». Примеры включают мэйнфреймы, отдельные серверы, распределители нагрузки HA / межсетевые экраны (активные / активные или активные / пассивные), системы баз данных, разработанные как ведущие / ведомые (активные / пассивные) и так далее.
и скот как
Массивы из более чем двух серверов, которые построены с использованием автоматизированных инструментов и предназначены для отказа, когда ни один, два или даже три сервера не являются незаменимыми. Как правило, во время событий отказа не требуется вмешательство человека, поскольку массив демонстрирует атрибуты «маршрутизации вокруг сбоев» путем перезапуска отказавших серверов или репликации данных с помощью таких стратегий, как тройная репликация или кодирование стирания. Примеры включают в себя массивы веб-серверов, хранилища данных с несколькими главными устройствами, такие как кластеры Cassandra, несколько стоек устройств, собранных в кластеры, и почти все, что сбалансировано по нагрузке и имеет несколько главных устройств.
По сути, Bias и Baker пытаются донести, что должен быть переход от того, как мы относимся к серверам, с того, чтобы быть «уникальными снежинками» с именами и эмоциональными привязанностями, к модели, в которой, если у нас есть проблема с сервером, мы создаем замену. и уничтожить проблемный сервер.
Наконец, вероятно, стоит упомянуть, что в регулируемых средах вынимание сервера сзади и стрельба могут быть неоптимальными. В этих случаях часто выгодно «замораживать» сервер, например, используя docker pauseдля замораживания контейнера. Затем его можно использовать для выполнения анализа первопричин в рамках процесса управления инцидентами или проблемами.
Чтобы добавить к ответу Ричардса, обычно аналогия полезна с точки зрения влияния потери сервера.
Если вы испытываете какое-то беспокойство из-за потери какого-либо отдельного объекта инфраструктуры, то считайте его домашним животным (читай антипаттерн).
Если вы чувствуете себя довольно комфортно, зная, что если какой-либо из флотов перестанет функционировать, это не окажет реального влияния на операции, тогда вы говорите о скоте.
Часто соблазнительно использовать аналогию, чтобы просто классифицировать ваши серверы, то есть «наши узлы рабочей нагрузки - крупный рогатый скот, но наши балансировщики нагрузки - домашние животные», но попадание в эту ловушку является именно проблемой. В современной компьютерной среде нет места для домашних животных (т. Е. В облаке, на обычном оборудовании и т. Д.). Если все ваши серверы считаются скотом и их легко заменить, то вы можете начать смотреть на такие вещи, как обезьяна хаоса, чтобы помочь обеспечить уверенность в том, что ваша инфраструктура действительно устойчива.