CentOS 6, Scientific Linux 6 или RHEL 6: выбираем дистрибутив для 15 серверов

На прошлой неделе клиент - средний производственный холдинг - попросил нас помочь выбрать базовый дистрибутив Linux для 15 новых физических серверов. Бюджет ограничен, RHEL-лицензии в него не влезают, но нужна стабильность и предсказуемые обновления безопасности. Классический вопрос для бюджетных серверных проектов.

Мы провели короткое внутреннее сравнение и зафиксировали выводы - они могут пригодиться, потому что такой вопрос задают регулярно.

Три кандидата

Ситуация на рынке бесплатных RHEL-клонов сейчас выглядит так:

• CentOS 6.2 - самый популярный клон. Огромное сообщество, тонны документации, пакеты в репозиториях на любой вкус. Задержка патчей после апстрима (RHEL) бывает разная: от нескольких дней до нескольких недель, в зависимости от сложности релиза. Критичные security-патчи обычно выходят быстро, но не всегда.
• Scientific Linux 6.2 - клон от Fermilab и CERN. Ориентирован на научные вычисления, но вполне пригоден для корпоративной инфраструктуры. Команда небольшая, но патчи нередко выходят быстрее CentOS - у них проще процесс сборки и меньше бюрократии.
• RHEL 6 - оригинал, с платной подпиской от Red Hat. Быстрые патчи, официальная поддержка, гарантии. Стоит денег, и для 15 серверов это заметная строка бюджета.

Что нас беспокоит в CentOS

Главная претензия к CentOS - скорость патчей. Это не миф: сборочный процесс CentOS достаточно тяжёлый, и когда RHEL выпускает security-апдейт, CentOS догоняет через несколько дней, а иногда через две-три недели. Для десктопа это незначительно. Для серверов с выходом в интернет, где держится что-то чувствительное, - это вопрос, который надо задавать заранее.

При этом инфраструктура CentOS хорошо отлажена. Зеркала работают. Пакетная база огромная. Документация - лучшая в классе. Если у вашей команды нет опыта с Scientific Linux, кривая входа в CentOS ниже.

Что даёт Scientific Linux

Scientific Linux патчи прогоняет быстрее - это объективно, об этом пишут в нескольких местах, и мы сами это наблюдали. Команда маленькая, но сфокусированная. Из минусов: сообщество меньше, русскоязычной документации практически нет, и если у вас что-то сломалось нестандартное - ищешь ответы дольше.

Для клиентов из научной или исследовательской среды SL выглядит естественным выбором. Для производственного холдинга это не принципиальный плюс, но скорость патчей реально важна.

Почему RHEL не вариант в данном случае

Клиент строит инфраструктуру на бюджете. 15 серверов умножить на стоимость RHEL-подписки - это сумма, которую проще потратить на железо или на дополнительные мощности сопровождения. Поддержка от Red Hat ценна, когда у вас нет экспертизы внутри или нет толкового подрядчика. Когда подрядчик есть - платить Red Hat за право звонить на горячую линию не всегда рационально.

Единственный аргумент за RHEL, который здесь имел бы смысл: если в будущем планируется сертификация какого-то промышленного ПО, которое официально поддерживается только на RHEL. Уточнили у клиента - такого в ближайших планах нет.

Наш выбор и почему

Мы рекомендовали CentOS 6.2 с оговоркой.

Аргументы за CentOS: команда клиента уже работала с ним на нескольких узлах, документации больше, и при возникновении проблем - поиск ответа быстрее. Для 15 серверов под смешанную нагрузку (веб, файловые сервисы, небольшие базы) это разумный выбор.

Оговорка про патчи: мы договорились выстроить мониторинг CVE-уведомлений по RHEL напрямую и не ждать, пока CentOS соберёт апдейт. Как только RHEL публикует security-бюллетень - смотрим на серьёзность, и если критичное, прорабатываем митигацию до выхода пакета. Это дополнительная работа, но это правильная работа.

Scientific Linux остался запасным вариантом. Если бы клиент работал с более чувствительными данными или командой с опытом именно в SL - мы бы склонились туда. Разница между дистрибутивами не колоссальная, и выбор в итоге определяется не техническими характеристиками, а оперативностью команды и процессами вокруг патчинга.

Что дальше

Развернули первые три сервера на CentOS 6.2, подключили к нашей системе мониторинга и настроили автоматические уведомления об обновлениях безопасности. Остальные 12 машин уйдут в работу в течение апреля. Посмотрим, как поведёт себя дистрибутив под реальной нагрузкой и насколько оперативно будут закрываться дыры в сравнении с тем, что публикует Red Hat.

Если выводы изменятся - напишем.