Как сисадмин, я советую взять самый дорогой выделеный сервер без поддержки, RAID, большой storage для особых файлов, template для сайта поярче, и закупить AdWords по крайней мере на два дня.
В предыдущей части я описал общую архитектуру приложения, и некоторые особенности инфраструктуры. Сегодня я бы хотел остановиться на некоторых пунктах подробнее, и рассказать, какие проблемы были созданы буквально на ровном месте. Параллельно расскажу, почему были приняты некоторые, прямо скажем, сомнительные решения (из разговоров с предшественником).
Отсутствие мониторинга
Платформа не мониторилась от слова совсем. При этом пользователи постоянно жаловались на тормоза некоторых частей сайта. Предшественник решал проблему горизонтальным масштабированием?—?раз в 2–3 месяца просто докупался ещё один сервер и добавлялся в конфиг Nginx на балансировщике. Забегая вперёд, скажу что после того, как я начал снимать статистику использования мощностей?—?оказалось что 90% инфраструктуры тупо простаивает. Деньги на аренду серверов тратились впустую. Причина такого подхода?—?“Ну, если чото работать не будет?—?клиенты скажут, зачем ещё один демон крутит”.
Gentoo в продакшене
За годы работы в индустрии для меня лично все дистрибутивы слились в один. Если раньше при планировании инфраструктуры я завязывался на какой-то один дистрибутив просто потому что у меня с ним больше опыта (или потому что захотелось попробовать новенькое), то теперь я чаще руководствуюсь соображениями стоимости поддержки того или иного решения в конкретной ситуации.
В проекте, который я описываю сейчас мой предшественник где-то прочитал, что Gentoo отлично масштабируется на десятки серверов, и один раз собрав пакет-его можно просто rsync’ом разливать на остальные машины. Теория красивая (и я даже видел такое работающее решение-для админских рабочих станций), на практике же- синхронизировать дерево портежей хотя бы раз в неделю никто не догадался, что с течением времени сделало практически нереальным установку пакетов. Про обновления безопасности речи вообще не было. За пару недель я привёл всё в божеский вид, и задумался о переезде на бинарный дистрибутив. Тратить каждый месяц по несколько дней на обновления и пересборку обратных зависимостей я не хотел (привет, брокер ZeroMQ реализованый на Ruby через libffi). Причина использования Gentoo- “Ну смотри как быстро можно при помощи моих скриптов раскатать новый сервер и добавить его в инфраструктуру”.
Брокер
Раз уж заговорил про брокер — расскажу, какие с ним были проблемы. Мониторинг состояния. Его не было (точнее, в коде брокера были заглушки для функций ping_service(), get_service_state(), get_stats() и подобным). Единственная реализованая функция?—?ping_broker()?—?работала только из одного сервиса, и её можно было вызвать из Rails консоли: ServiceName.ping_broker(). Всё. Сервисы не знали, когда брокер лежит. Сервисы не умели перерегистрироваться в случае перезапуска брокера. Брокер был stateless, соответственно “забывал” про все сервисы после рестарта, нужно было руками ходить по серверам, подключаться к screen’ам и рестартовать все сервисы и их обработчики событий. Ну и как вишенка на торте?—?брокер отвечал за назначение портов для сервиса. То есть, в настройках брокера задавался пул min_port:max_port, сервис при запуске спрашивал у брокера, на какой порт ему биндиться, и пытался начать слушать на этом порту. Если брокер работает на одном сервере, а сервис запускается на другом?—?порт, который выдал брокер уже может быть занять и сервис попросту не стартанёт с ошибкой “Address already in use”. Мониторить сервисы с такой схемой работы не представлялось возможным. Цель использования этого брокера?—?распределить нагрузку на сервер и иметь возможность крутить каждый сервис на своём сервере?—?достигнута так и не была.
Synctool
Кому интересно?—?ссылка на проект: http://walterdejong.github.io/synctool/. В принципе?—?оно имело право на жизнь. Но во-первых?—?гора bash-скриптов + rsync?—?это не управление конфигурациями, во-вторых я тогда как раз познакомился с Ansible, который оказался сильно гибче. Тут особо даже сказать нечего, просто за пару дней перенёс всю логику из synctool в Ansible и забыл как страшный сон. Причины использования synctool?—?“Ну я посмотрел на Puppet, мне показалось сложно, а в synctool можно всё скриптами решить”. Про Absible/Chef человек просто не знал.
Falcon
В первой части я упомянул falcon, но забыл дать ссылку на него, исправляюсь: http://www.falconpl.org/. Помесь процедурного и функционального скриптового ЯП с поддержкой многопоточности и собственной виртуальной машиной. В принципе?—?мощная и интересная штука с низким порогом входа, но зачем было это использовать только для того, чтоб выполнять ssh dba@db01 “echo ‘SELECT stuff FROM table’ | psql -U postgres app_db”?—?осталось за гранью моего понимания. Вопрос “Нахера это тут?” в отношении falcon так и не был мной задан.
Разделение production/development окружений в коде
Последний пункт на сегодня. В Rails есть чудный механизм, который покрывает 99% случаев, когда нужно по-разному настроить приложение для продакшена и для разработки. Этот механизм использован не был, и в коде гвоздями были прибиты имена хостов для сервисов, адрес Redis, адрес и порт базы данных, и доменное имя приложения. Как-то мне пришлось мигрировать Redis и базу данных на другие сервера?—?платформа лежала больше суток, пока я выгрепывал все такие места. Причины?—?модель разработки, и не очень высокая квалификация программиста. Проект писался практически “на коленке” сначала, новые фичи добавлялись и добавлялись, рефакторинг никто не делал, и в какой-то момент это превратилось в то, что на картинке:
В последней части я расскажу о том, как платформа выглядит сейчас, какие технологии используются и почему, как использование подходящих под задачу инструментов помогает экономить деньги, и почему сисадмин не должен кодить, а программист?—?админить.
f1inx
Gentoo в продакшене, тем не менее звучит гораздо убедительнее чем любой бинарный дистрибутив. Особенно, если это касается серверных инсталляций. В этом случае количество зависимостей сводится к минимуму. И риск напороться на серьезную проблему при update системы сильно уменьшается. К тому же любой ленивый админ легко организует кэш бинарных сборок на NFS и автоматизирует ежедневное-еженедельное обновление gentoo (разумеется после тестирования на карантином сервере, и да возможно раз в пол года автоматическая сборка не сработает) или воспользуется готовым решением.
В случае бинарных дистрибутивов велик риск привести систему в убитое состояние. Временной период существования известных, не закрытых проблем безопасности, существенно выше.
br0ziliy
> количество зависимостей сводится к минимуму
Не все умеют правильно настроить USE-флаги.
> напороться на серьезную проблему при update системы сильно уменьшается
Что есть «серьёзная проблема»?
> организует кэш бинарных сборок на NFS и автоматизирует ежедневное-еженедельное обновление gentoo
Ага, а кто потом этот кэш обслуживать будет? Ну и потом — чем сценарий с кешем отличается от бинарного дистрибутива тогда? Тем, что «минимум зависимостей»? Сомнительное преимущество.
> В случае бинарных дистрибутивов велик риск привести систему в убитое состояние
Это с чего вдруг?
> Временной период существования известных, не закрытых проблем безопасности, существенно выше.
В теории — да. На практике — Дебиан/РедХат на второй-третий день выпускают обновление, yum upgrade/apt-get dist-upgrade — и всё в шоколаде. В случае более-менее большого деплоя Генту (5+ машин) у одного человека те же два-три дня займёт обновить этот зоопарк.
Ну и стоимость для бизнеса не забываем. Клиентам обычно неважно, на чём крутится их интернет-магазин, главное чтобы было стабильно. Плюс лично мне как админу приятней ковыряться с чем-то новым, или улучшать существующее, а не проводить часы с емержем в зубах. Гента — не для бизнеса, бессысленно это.
rodial
Не скажу про редхат, но в той же убунте вроде намного быстрее происходит ввод новых версий пакетов.
progit
Ubuntu != Debian, который приведет в примере
rodial
Неправильно выразился.
Я не в курсе про редхат, но в убунте новые версии пакетов обычно появляются раньше чем в дебиан.
progit
Да, все верно. В Debian'е быстро появляются только security-патчи.
Только тогда я не совсем понимаю этот коммент.
Быстро появляются — хорошо? или плохо?))
f1inx
Плохо.
Убунту использовать на сервере это большая глупость.
Во первых постоянно что-то отваливается изза плохого тестирования.
Во вторых оно давно стало BLOATWARE, как и большинство бинарных дистрибутивов.
В третьих systemd невозможно выпилить а это тянет за собой кучу проблем.
v_sadist
В RedHat/CentOS 7 тоже systemd. Полет нормальный, проблем не испытываем. Что с ним не так?
br0ziliy
> В третьих systemd невозможно выпилить а это тянет за собой кучу проблем.
Зачем его выпиливать? Его просто готовить нужно научиться, всего делов. Мне SysV init в CentOS 3 после фряшных rc-скриптов тоже непонятен был — ничо, разобрался.
f1inx
br0ziliy
> Полностью убитые зависимости из-за ошибок в пакетах.
За 12 лет сталкивался с таким ровно один раз на Ubuntu 6.06. Возможно в Debian sid, или Fedora rawhide такое до сих пор есть — не в курсе, не пользуюсь bleeding edge версиями.
> Невозможность обновления из-за отсутствия поддержки слотов для библиотек.
Слоты в Генту конечно сила, этого не отнять. Но реальные юзкейсы слотов в других дистрах уже пару лет как покрыты — version pinning в Дебиан, Software Collections в Федоре/ЦентОС, плюс механизм alternatives что там, что там. Это если говорить про Python 2/3 например, или подобное. Зачем мне слотировать glibc (или любую другую библиотеку, от которой всё равно пол-системы зависит) — ума не приложу.
> Крах сервисов при обновлении glibc
Инфа из начала двухтысячных? Ни разу на моей практике yum update glibc не приводил к «краху сервисов».
Sovigod
Вы уж извините, но вы просто не осилили работу с генту на проде. Как и предидущий админ. f1inx все верно сказал.
Тот треш который вы описали можно вычистить и выровнять на генте. А на убунте/дебиане/центос пришлось бы переставлять на всех железках ОС.
Как я понимаю вы уговорили начальство на полный переезд на новую ОС? и куда?
PS. Помните пословицу про «два перезда» = «один пожар». На серверах такая же фигня.
br0ziliy
> Вы уж извините, но вы просто не осилили работу с генту на проде
Опыт с Gentoo — около пяти лет, так что скорее не захотел. Есть более интересные и полезные задачи. Для прода никогда не буду никому советовать source-based дистр, и сам не буду использовать — в 99% случаев это принесёт скорее вред, чем пользу, и сузит количество людей, способных поддерживать это окружение после меня.
Sovigod
5 лет с генту? И для вас стало сложностью перейти от сорцов к общим для всех серверов бинарникам? Это же азы генту в проде.
Эти бинарники нужно будет самому поддерживать и компилировать, но только один раз. И уже потом разливать по тестовым серверам.
Нужно ли это если есть готовые бинарные дистры? Каждый конечно решает сам. Но любой проект через какое-то время хочет использовать то, чего в них нет. Будь то pagespeed — гугловый модуль для nginx. Или устаревшая версия glasterfs т.к. обновить ее сразу и везде нет возможности. Ну или вы параноик и не доверяете сторонним репозиториям.
Вам придется создать свой и поддерживать его дальше. Вот только поддерживать свой репозиторий на debian/centos то еще удовольствие. Например если у сброка nginx в репе использует не ту версию openssl чем та что прилетела вам с офф апдейтом.
В генгу же вы все эти проблемы даже не увидите т.к. она знает что у вас зависит от openssl и сама все пересоберет с актуальной версией зависимостей.
br0ziliy
> И для вас стало сложностью перейти от сорцов к общим для всех серверов бинарникам?
Да. Ибо ленив я, неохота мне даже один раз пересобирать систему с целью обновления, ненужная трата времени это.
> Нужно ли это если есть готовые бинарные дистры? Каждый конечно решает сам.
Ну вот я и решил для себя — в тех проектах, в которых я учавствую/учавствовал это не нужно.
> Вот только поддерживать свой репозиторий на debian/centos то еще удовольствие.
Про Дебиан не знаю, для CentOS — не вижу проблем вообще. Пример с Nginx + openssl к слову показательный (хотя и надуманый ИМХО, ни разу не приходилось так извращаться). Решается выкладыванием своей сборки openssl рядом с Nginx, с кастомными путями (привет, слоты Генту), и пишем правильный spec для Nginx (чтоб линковался не с системным openssl, а с тем, что нужно).
MgmZog
Зато как приятно смотреть, как пересобирается мир :)
chupasaurus
Пфф, apt install apt-build && apt-build world
NikiN
отсыпь чутка…
Singaporian
Вы можете только одним способом свести количество зависимостей к минимуму: не использовать их в своем коде или писать свои велосипеды, чтобы они были частью основного кода. Дистрибутив на это никак не влияет уж точно.
Ленивый админ избежит ненужных действий своими руками, когда есть специальные механизмы, отточенные огромным сообществом умных людей на миллионах случаев разных практик. В бинарном дистрибутиве вообще ничего делать не надо для этого.
Singaporian
И вообще, чем больше
хаосаad-hoc решений в вашем проекте вместо отточенных стандартов и инструментов — тем выше энтропия и, соответственно, ниже качество. А именно оно жизненно важно в production'е. И да, энтропию еще никто не смог автоматизировать нормально.