В ряде статей на Хабре упоминалось разделение серверов на «pets» и «cattle». Эта терминология пошла с одной небезинтересной статьи за авторством Noah Slater — open source активиста и соавтора CouchDB. Я не смог скрафтить хороший перевод английского «cattle», «животные, выращиваемые в промышленном животноводстве», поэтому под катом вас ждет перевод с Крупным Рогатым Скотом. Очень крупным.



Я был одним из разработчиков, создавших Orchestra: PHP PaaS, которую Engine Yard приобрел в 2011 году. Многие наши клиенты использовали PaaS в первый раз, до этого они работали с традиционным хостингом. У них была привычка заливать файлы через FTP и править удаленные конфиги. Эти практики до сих пор распространены, несмотря на популярность git и таких сайтов как The Twelve-Factor App. Распространенность таких подходов поддерживалась еще и тем, что множество коммерческих PHP проектов довольно старые и подразумевают именно такой сценарий развертывания.

Как бы смешно это не было, традиционное системное администрирование сосредоточено на работе с физическими серверами. При добавлении новой машины в кластер она вначале покупается, затем настраивается в офисе и только потом отвозится в дата-центр для установки. Подобная операция при неблагоприятном положении звезд может занять несколько недель. А если в будущем с этой машиной что-то случится — то придется приложить все усилия, чтобы починить ее по SSH. Если с расположением звезд снова не повезет — то придется ехать в дата-центр лично и разбираться с железкой на месте.

Именно так я работал со своими серверами. Я все еще помню эти времена, когда только пробовал на зуб системное администрирование и у всех моих серверов были прикольные имена, как у домашних животных. Я называл их по персонажам книги Дугласа Хофштадтера «Гёдель, Эшер, Бах: эта бесконечная гирлянда». «Черепаха» была моим основным Apache сервером с httpd, «Ахиллес» крутил Squid в режиме reverse proxy, «Краб» держал MySQL, а «Джинн» был моим SMTP гейтом. Каждая машина содержала модифицированный motd с разноцветным ASCII-артом и цитатой из книги.

Я очень гордился тем, как разделил деплой своего проекта на части. Я с любовью лелеял каждую машину. Я устанавливал на них обновления, проводил настройку, тестирование и множество других нужных в админском деле вещей. В случае проблем я выхаживал их, возвращая в рабочее состояние, и тщательно записывал все шаги, которые при этом выполнял. В случае фатальной поломки я мог восстановить их с нуля, пользуясь этими записями. Когда установка нового сервера занимает недели, ты относишься к ним с очень, ОЧЕНЬ большим вниманием.

В облачных системах все совсем не так.

Поиск аналогии

С приходом виртуализации больше не нужно работать с «железом» и куда-то ездить. На самом деле, часто самое простое решение — это просто прибить сбойнувший сервер из административной консоли. Чтобы затем перезапустить его из каталога серверных образов. Теперь это занимает не недели, а минуты.
Чтобы такое было возможно, большинство решений облачных провайдеров основаны на концепциях «share-nothing» архитектуры, stateless файловых систем, автоматического повторяемого деплоя и так далее и тому подобное. Но если вы раньше использовали традиционный подход к хостингу, то все эти концепции могут показаться вам слишком ограничивающими. Долгое время я мучился, пытаясь сообразить как же лучше объяснить моим клиентам разницу в подходах. С практической точки зрения труднее всего было обосновать почему новый способ лучше.

Но в один прекрасный момент Massimo познакомил меня вот с этим:


Слайд вырезан из презентации Gavin McCance на конференции CERN в 2012 году. Хотя, The Register указывает, что изначально автором аналогии является Bill Baker из Microsoft.

Разница между деплоем до и после наступления эры виртуализации можно сравнить с разницей между домашними животными и крупным рогатым скотом. Домашним животным дают с любовью выбранные имена, такие как «котвсапогах» (в моем случае «Черепаха», «Ахиллес» итд). Их выращивают и о них заботятся. Они вертиально масштабируются, становясь больше. И когда они болеют, вы лечите их. С крупным рогатым скотом все не так. Вместо имен они имеют функциональные идентификаторы типа «vm0042». Они практчиески идентичны друг другу. Они горизонтально масштабируются путем увеличения их количества. И когда какой-то из них заболевает, вы просто заменяете его другим таким же.

Как показывает Massimo, опираясь на эту аналогию очень легко определить — имеете вы дело с серверами типа «домашние животны» или же типа «крупный рогатый скот». Достаточно спросить себя: что случится, если несколько ваших серверов станут недоступны прямо сейчас? Если это никак не отразится на ваших пользователях, то поздравляю — в вашем распоряжении стадо крупного рогатого скота. Если же это приведет к сбою в работе сервиса — то вы работает с домашними животными.

Этот же принцип лежит в основе шаблона для оценки вашей архитектуры. Вы смотрите на сервер и спрашиваете себя: что я буду делать, если этот сервер «заболеет»? Правильный ответ: немедленно его уничтожить и заменить на точно такой же. Если вы беспокоитесь о бекапах, дампах данных, запланированных даунтаймах или об утомительном ручном конфигурировании, то это является «звоночком» по поводу архитектуры.

Тем не менее, пост-виртуализационная модель развертывания еще относительно молода, и многие легаси приложения еще долго будут нам нужны. При сложной архитектуе у вас даже могут одновременно жить домашние животные и крупный рогатый скот на одной серверной ферме (извините, не удержался). Хорошо, что Engine Yard поддерживает и тех, и тех.

Об авторе

Noah Slater — англичанин, живущий в Берлине, который занимается open source с 1999 года. На его счету участие в Debian, GNU и Free Software Foundation. На момент написания статьи он является участником Apache Software Foundation. Основной проект, над которым он работает — Apache CouchDB, документ-ориентированнся база данных, которая положила начало движению NoSQL. Также он помогает Apache Incubator, обучая участников новых проектов как правильно работать с open source.

Картинка с коровой взята отсюда