nuclight: (Default)
[personal profile] nuclight
Три недели назад Андрей Шетухин, руководитель отдела почты Rambler, сообщил о начале миграции своего почтового кластера (порядка 500 серверов) с FreeBSD на Linux (Debian/Ubuntu), поскольку FreeBSD перестала его устраивать. Дискуссия в комментах, которых уже более полутысячи, разгорелась нешуточная. В комментах также стало известно, что аналогичный переход планирует Яндекс на своем поисковом кластере, который в данный момент работает целиком на FreeBSD, а это примерно 25000-30000 серверов, и порядка 60% мощностей Яндекса. Такая потеря — это для FreeBSD уже серьезно. С такими тенденциями система, к радости ликующих подонков, станет таки умирать.

Очевидно, что подобные решения не принимаются на ровном месте, и существуют определенные причины, проблемы, которые мы, FreeBSD, можем начать исправлять, пока не стало слишком уж поздно. BSD-сообщество привыкло закрывать глаза на многие проблемы, считая их несущественными. Более так поступать нельзя — легко списать всё на тараканы в голове менеджмента и ничего не делать, вот только постоянное повторение такого образа действий приведет к тому, что лет через 5 работу BSD-администратора будет уже не найти (Вы такую перспективу себе хотите? Я лично — нет). Однако, с другой стороны, тот же Шетухин 3 месяца назад писал "Вывод простой: миграция на Linux нецелесообразна, так как затраты на нее не окупятся" о том, что разницы в производительности FreeBSD и Linux для их целей не выявлено. То бишь, следует отделить зерна от плевел и решать те проблемы, которые действительно есть.

Таким образом, имеется два утверждения (которые будут более подробно рассмотрены далее), причем оба истинные и друг другу не противоречат:

I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).
II. У FreeBSD действительно есть серьезные проблемы, нам необходимо их решать, иначе нам каюк.

По второму вопросу — в следующем посте предполагается анализ, каковы еще проблемы FreeBSD и как их можно решить, с опросом мнения читателей. Но сначала — о том, почему держателям акций Рамблера стоит продавать их, пока курс еще хороший.

Часть I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).

Что выяснилось в процессе обсуждений как в комментах к посту, так и в других местах? Например, то, что проблемы и претензии Рампочты к FreeBSD были вызваны во многом их собственной спецификой. А именно, это закрытый отдел, и они не используют наработки остальной части Рамблера. В условиях больших систем нормально организовывать работу ведь следует как? Делается собственная сборка системы, часть машин выделяется под компиляцию (сборку пакетов), часть под тестирование. Этот процесс требуется всегда, какой бы там дистрибутив не стоял — даже с самым бинарным будет сделан свой локальный репозиторий, в котором собираются пакеты под задачи фирмы. И распространяются пакеты аналогично. Может быть видоизменен инсталлятор для автоматизации разливки на новые машины кластера, и т.д.

Но у них, в отделе почты, свой инсталлятор, они не пользуются, например, тем, что сделано у работающего в соседнем отделе Глеба Смирнова, коммитера FreeBSD. Из высказанных претензий складывается впечатление, что администраторам Рамблер-почты неизвестно ни про freebsd-update(8) — средство бинарного апгрейда базовой системы, имеющееся в ней уже 5 лет (обновляет в две простые команды, "скачать" и "поставить"). Ни про portmaster, написанная на чистом /bin/sh утилита обновления пакетов, альтернатива portupgrade — претензия к которому была, что он тянет за собой язык Ruby.

Аргументов было много, внятный перечень (я тут свёл воедино из нескольких разных комментов) был таким:
Ок. Давайте осилим тиндербокс. Давайте осилим бинарные обновления базовой системы и пакетов. Давайте подтянем версию FreeBSD к текущей. Давайте забьем на тупизну ipfw и убогость pf по сравнению с iptables. Давайте все собирать древним как говно мамонта компилятором. Давайте жить на ufs2. Давайте сделаем еще миллион прекрасных в своей глупости вещей, лишь бы не уходить с труъ-системы на негодный Линукс.

Все это прекрасно, но моим админам не платят за название операционки. Им платят за то, чтобы все работало. Сделать так, чтобы все работало на Линуксе, объективно проще, чем на FreeBSD. Пройдет еще 3-5 лет, и фря станет системой исключительно для маргиналов.

1. Убить такое понятие как монолитная base sysem, сделать набор пакетов для base system и для ports.
Компилировать и патчить мир в 2011 году — уебанство. Кроме того, куча вещеий из base system не нужны большинству юзеров. Значит, их и ставить не надо. Тот же bind, который не запускается на 99.5% серверов. Хрена он там делает в base system?

2. Отказаться от сборки пакетов как от основного способа установки ПО.
Пакеты должны ставиться из репозитория, и только. Нужно что-то свое — делайте набор ПО чтобы подключить локальный репозиторий на машине.

3. Сделать -STABLE репозиторий с пакетами, регулярно обновляемыми патчами.
Да, это напрягает — искать патч к X.Y.Z версии одного пакета только потому, что другой пакет хочет только ее.

4. Разработать систему автообновлений, позволяющую с минимумом головной боли содержать up-to-date систему. Ключевое слово: АВТОобновлений.

5. Самое важное: все это должно быть "из коробки", без доустановки и чтения инструкций.

Я ничего против портов не имею, это наоборот, очень удобно и классно. А вот к менеджеру пакетов претензии есть.

Серьезные ли это причины? Серьезные, хотя разбираться мы с ними будем позже. Но, однако в другом месте встречаем признание: "Собственно, все пертензии к деплойменту — невозможность в автомате с учетом всех требуемых зависимостей поднять версию системы и/или переустановить те пакеты, которые требуются. Это — прямое следствие использования pkg_*."

Решаема такая проблема с FreeBSD? В принципе, решаема, но требует скриптования. Вполне понятно и желание не заниматься рутинной работой, которую уже сделали другие. Другое дело, что максимально её сложить с себя можно только, если кто-то это будет делать на оплачиваемой основе. Вполне резонно следующее мнение: "Удивительно, что Rambler, ища стабильность и уверенность + иметь возможность своих админов отпускать вечерами домой к семье выбрали опять черти что, а не коммерческий RedHAT, где они получат любую консультацию почему у них что-то не работает. А ведь для такой конторы как Рамблер стабильность должна быть на первом плане, а они ищут халявки. позор."

Тут-то уже закрадываются подозрения, что не во FreeBSD дело — ведь, как резонно отмечали, даже конкретно Debian не уменьшит работу админов до нуля как по волшебству. Подозрения закрадываются в том, что текущие админы Рампочты попросту не в состоянии адекватно управляться с FreeBSD. Так ли это? [livejournal.com profile] slonik_v_domene пишет по этому поводу:
Из админов ушел ровно один человек, было это в конце весны 2009 года. Причины, по которым мы расстались очень просты и печальны: мы не смогли работать друг с другом. Тем не менее, расставание прошло без ругани и взаимных истерик. И несмотря ни на что, к этому человеку я испытываю уважение за профессионализм и умение твердо отстаивать свои принципы, даже ценой рабочего места.

Далее находится (в IRC) сам этот ровно один человек, это был [livejournal.com profile] ospf_ripe, и комментирует заявление "FreeBSD сложно майнтейнить" так:
Wed 22:46:44 <@citrin> nuclight: не очень понятно что там маинтейнить, а миграция будет очень сложно и трудозатратной (до прихода slonik-v-domene я работал в Рампочте и представляю что там есть внутри)
Wed 22:52:18 <@citrin> обсуждать не хочется и смысла не вижу. собственно я и ушел оттуда из за того, что с Шетухиным сложно вести конструктивный диалог. Он любит все решения принимать сам, ни с кем не советуясь и не аргументируя свою точку зрения.

Аналогичной точки зрения придерживаются и другие сотрудники Рамблера. В частности, известно, что оттуда в свое время уволился и Максим Дунин ([livejournal.com profile] mdounin). Сам [livejournal.com profile] slonik_v_domene от комментариев насчет него отказался, а Глеб Смирнов высказался по этому поводу так:
Tue 16:17:37 <@glebius> ну, если бы Максим был здесь, то я думаю слоник бы не начал этого манёвра
Tue 16:17:56 <@glebius> потому как начальству будет видно, что это просто перестановка мебели
Tue 16:18:11 <@glebius> а сейчас понимающего начальства нет, так что можно попереставлять

[UPDATE:glebius@ поправляет, что это был не [livejournal.com profile] mdounin, а maxim@freebsd.org]

По непроверенным слухам, [livejournal.com profile] slonik_v_domene работал ранее в компании СУП (которой принадлежит ЖЖ) и был оттуда уволен за примерно такие же действия — взять и устроить революцию работающей системы без оснований.

Прямых подтверждений тому у нас нет, зато косвенных — валом. Например, мной был задан вопрос, чего не хватает FreeBSD, как нам можно её улучшить. Ответом был приведенный выше перечень, что именно стоило бы сделать. Однако последовавшее за этим обсуждение показало странные вещи. Глава Рампочты никак не хочет признаваться, в какие же именно затраты рабочего времени администраторов (то есть в конечном счете финансовые затраты) выливается та или иная проблема FreeBSD. Например, еще более-менее понятно, чем плох BIND в базовой системе, хотя даже по этому вопросу конкретику с цифрами я почему-то получил от другого человека. А вот чем администратору мешает наличие в базовой системе какой-нибудь мелкой утилиты, скажем, make — уму непостижимо. Если она не используется — она вообще не требует внимания админа, лежит себе да лежит. Если её требует кто-то по зависимостям — она всё равно будет поставлена по зависимостям, что во фре, что в дебиане. Если всё ставить вручную — наоборот, требуется время админа на расстановку галок в инсталляторе (или его эквиваленте), никакого выигрыша...

Такой отказ в назывании конкретики говорит о том, что причины не технические. А тут еще выясняется что? Что из Рамблера по-тихому, 3 месяца назад, ушел Игорь Сысоев, автор известного web-сервера nginx. Итого, из Рамблера ушло уже трое. Между тем, внимания заслуживает еще такая цитата:
> что подходы рампочты к администрированию конкретно fbsd, мягко говоря, плохие.

Ну, плохие и плохие. Будет Линукс вместо FreeBSD, будут хорошие подходы. Что-то возразить по существу описанных с портами проблем есть?

Изменятся ли подходы от смены систем? Ни разу, "внезапная революция в мосгах, бывает ли такое". Подходы зависят от людей. Заблуждение о том, что есть "серебряная пуля", инструмент, с которым все проблемы сразу решатся, к сожалению, популярно... В другом треде в обсуждении [livejournal.com profile] slonik_v_domene также заявлял о том, что предпочтительны системы, с которыми справится и новичок. Он считает, что "первопричина — это не люди, а системы. А люди — следствие". В действительности же — именно люди, ключевым является именно персонал, а не инструменты. Нет смысла останавливаться на этом подробно и переубеждать того, кто до понимания положения "кадры решают всё" еще не дорос. Я просто процитирую по этому вопросу классика:
Выдающиеся проектировщики. Главная проблема совершенствования искусства программирования заключена, как всегда, в людях. [...] Выбор правильного метода проектирования определяет различия между плохим и хорошим концептуальным проектом, но не между хорошим и выдающимся. Выдающиеся проекты создаются выдающимися проектировщиками. Создание программ является творческим процессом. Крепкая методология может придать силу и освободить творческий ум, но она не может воспламенить или вдохновить того, кто занят нудной работой.
И разница немалая — это как Сальери и Моцарт. Одно исследование за другим показывают, что лучшие проектировщики создают структуры, которые быстрее, меньше по размеру, проще, понятнее и разработаны меньшими усилиями. Различия между выдающимся и средним достигают порядка величины.
[...]
Как растить выдающихся проектировщиков? Место не позволяет обсуждать это пространно, но вот некоторые очевидные шаги:
  • Систематически и как можно раньше выявлять первоклассных проектировщиков. Лучшие — не всегда самые опытные.

  • Назначить наставника, ответственного за рост перспективного проектировщика и тщательно следить за его карьерой.

  • Разработать и осуществлять план служебного роста для каждого перспективного проектировщика, включающий тщательно продуманное обучение у передовых проектировщиков, периоды дополнительного формального обучения, краткосрочные курсы, перемежающиеся с самостоятельным проектированием и назначением на руководящие технические должности.

  • Обеспечить возможности для взаимодействия и взаимного стимулирования растущих проектировщиков.

(с) Фредерик П. Брукс. "Мифический человеко-месяц или как создатся программные системы".


В Рамблере же всё происходит с точностью до наоборот. Кроме того, Андрей Богородский прокомментировал, что штатная сетка рампочты привела его в тихий ступор — с точки зрения риск менеджемента два человека администраторов недостаточно даже для текущего саппорта, что уж говорить о развитии (чтобы от болезней/свадеб/отпусков не зависеть, по КЗОТу для обеспечения круглосуточной работы должно быть минимум 5 человек на клетку).

[UPDATE: Эта ситуация относилась к 2008 году. Как сообщает А. Шетухин, сейчас сисадминов хватает для покрытия всех суток.]

В довершение ко всему, глава Рампочты еще и относится наплевательски к сообществу и исповедует паразитизм, считая, что его должны носить на руках уже за сам факт использования системы. Этика между тем проста: ему дали систему забесплатно, он ничем разработчикам не обязан, но и не имеет права требовать от них ничего, а уж тем более вставать в позу и оскорблять кого-то. Вот если бы помог хоть чем-то (тот же Яндекс, скажем, помогал)... но он хамски требует. И, не получив, уходя, он предпочитает обосрать всех и вся. Может быть, и специалисты из Рамблера сбегают из-за такого отношения руководства?..

Как бы там ни было, потеря уже невелика. "С таким подходом через 3-5 лет Рамблером не будет пользоваться никто, кроме маргиналов". Прощай, Рамблер! А мы пойдем дальше разбираться со своими проблемами сами.

Часть II. У FreeBSD действительно есть серьезные проблемы, или мы их решаем, или нам каюк.

опубликована отдельным следующим постом

Date: 2011-08-03 08:33 am (UTC)
From: [identity profile] slonik-v-domene.livejournal.com
>за одним исключением

Бида-бида. 2011 год на дворе.

Date: 2011-08-03 08:35 am (UTC)
From: [identity profile] http://users.livejournal.com/_slw/
что, правда надо-надо?
а в линухе уже есть честный posix aio?

Date: 2011-08-03 08:39 am (UTC)
From: [identity profile] slonik-v-domene.livejournal.com
Я понятия не имею, что там с aio. Сервера почти всегда упираются в диски и CPU, а не в network i/o. Так что есть оно там, нет его, мне глубоко пофиг.

Date: 2011-08-03 08:43 am (UTC)
From: [identity profile] http://users.livejournal.com/_slw/
aio -- это CPU/диски.

Date: 2011-08-03 09:50 am (UTC)
From: [identity profile] b00ter.livejournal.com
aio - CPU? Можно ссылочку на этот счет?

Date: 2011-08-03 10:02 am (UTC)
From: [identity profile] http://users.livejournal.com/_slw/
при линуховой эмуляции posix aio через треды ты тратишь CPU.
логика ясна?

Date: 2011-08-03 10:11 am (UTC)
From: [identity profile] b00ter.livejournal.com
Нет. При работе aio в FreeBSD CPU не расходуется?

Date: 2011-08-03 10:22 am (UTC)
From: [identity profile] http://users.livejournal.com/_slw/
пишут, что меньше. именно это я имел ввиду, упоминаю тут CPU

Date: 2011-08-03 10:28 am (UTC)
From: [identity profile] b00ter.livejournal.com
А где пишут? Просто мне кажется, что разница не столь стремная, чтобы придавать ей большое значение.

Date: 2011-08-03 10:34 am (UTC)
From: [identity profile] http://users.livejournal.com/_slw/
http://rblaze.livejournal.com/963786.html

Date: 2011-08-04 09:41 pm (UTC)
From: [identity profile] permea-kra.livejournal.com
Где там эмуляция? libaio работает на ядреных вызовах. Асинхронных.

Date: 2011-08-03 10:45 am (UTC)
From: [identity profile] slonik-v-domene.livejournal.com
Хватит ля-ля. Рандом сик по дискам убивает все преимущества aio.

Date: 2011-08-03 10:57 am (UTC)
From: [identity profile] http://users.livejournal.com/_slw/
рандом сик убивает вообще все, кроме ssd и этих, которые на памяти с батарейкой.

Date: 2011-08-03 11:05 am (UTC)
From: [identity profile] filonov.livejournal.com
Что однако не мешает минимизировать оный cик. просто выравнивание по размеру блока дает весьма существенные результаты. Товарищ просто не в курсе.

Date: 2011-08-03 11:25 am (UTC)
From: [identity profile] slonik-v-domene.livejournal.com
Для рандомного доступа все это не имеет смысла, особенно с большим размером кэша на контроллере.
Есть возражения - ну так покажите бенчмарки.

Date: 2011-08-03 11:43 am (UTC)
From: [identity profile] filonov.livejournal.com
Вы делаете мне смешно. Бенчмарков вы, очевидно, не делали, что однако не мешает делать голословные утверждения.

Date: 2011-08-03 12:00 pm (UTC)
From: [identity profile] slonik-v-domene.livejournal.com
Не делали - так сделайте. И не сферические в вакууме, а на реальной нагрузке. Что вы там за порнуху рандомно отдаете? Ну вот на ней и измерьте.

(no subject)

From: [identity profile] filonov.livejournal.com - Date: 2011-08-03 12:16 pm (UTC) - Expand

Date: 2011-08-05 03:19 am (UTC)
From: [identity profile] faerion.livejournal.com
А при чем тут рандом сик? aio помогает при локах на дисках при большой нагрузке, тот же nginx при его маленьком количестве воркеров лочится без aio на ура.

Date: 2011-08-03 05:58 pm (UTC)
From: [identity profile] ra-ga.livejournal.com
а вот не флейма ради: какой профит от posix aio?

Date: 2011-08-03 06:12 pm (UTC)
From: [identity profile] http://users.livejournal.com/_slw/
я тут давал ссылку на пост человека, который производил конкретные замеры.
я думаю спрашивать лучше прямо у него.

Date: 2011-08-03 08:57 pm (UTC)
From: [identity profile] frotmnenogi.livejournal.com
какими бы легковесными не были бы POSIX threads, а AIO все таки легче. В цифрах это приращение к ожиданию ответа от винта. Так что чем быстрей диск, тем эффект более заметен.

Date: 2011-08-03 10:57 pm (UTC)
From: [identity profile] ra-ga.livejournal.com
а причём тут pthreads?

Date: 2011-08-04 09:02 am (UTC)
From: [identity profile] frotmnenogi.livejournal.com
единственная альтернатива AIO для дисковых операций - блокируемый ввод-вывод: на примере pread(2) и pwrite(2) вы можете заметить некоторую неоднозначность при попытке перевода обработки в диспетчер событий. Но у режима блокирования недостаток - жесткая привязка к потокам. С другой стороны один поток для AIO может задать сразу несколько задач по съему и наполнению данных во ФС (с сокетами сокетов тоже) - lio_listio(2).

Date: 2011-08-08 03:39 pm (UTC)
From: [identity profile] q53.spb.ru (from livejournal.com)

Спросите у oracle, почему их база по умолчанию работает с aio, и почему они до сих не портировали ее под bsd, если там так хорошо с aio. :)

Date: 2011-08-08 04:25 pm (UTC)
From: [identity profile] http://users.livejournal.com/_slw/
ответ может быть совершенно случайным.

February 2017

S M T W T F S
   1 234
567891011
12131415161718
19202122232425
262728    

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 21st, 2025 05:32 pm
Powered by Dreamwidth Studios