CentOS 5.4 как замена RHEL: RHEL-совместимость без подписки

CentOS 5.4 вышел в конце октября, мы его пощупали на тестовом стенде - и к декабрю уже перевели несколько серверов у двух клиентов. Не потому что Debian плохой, а потому что у этих клиентов есть конкретное требование: сертифицированное ПО, которое вендор поддерживает только на RHEL.

Зачем вообще CentOS, если есть Debian

У большинства клиентов мы работаем на Debian - стабильный, понятный, минимальный. Но периодически всплывает ситуация: клиент хочет поставить что-то корпоративное - СУБД, ERP-модуль, систему мониторинга от иностранного вендора - а в списке поддерживаемых платформ значится «RHEL 5.x, SLES 10, Solaris 10». Debian в этом списке нет. Технически оно работает, но вендор это не поддерживает, и когда что-то ломается, первый же вопрос техподдержки - «а на какой ОС?» - превращается в глухую стену.

CentOS 5.4 - это бинарно совместимый клон RHEL 5.4. Одни и те же пакеты, одни и те же библиотеки, один и тот же rpm-мир. Отличие от оригинала - нет подписки Red Hat и нет гарантий вендора. Но с точки зрения сертификации ПО и галочки в чек-листе клиента, CentOS и RHEL неотличимы: ПО видит нужную ОС и не возражает.

Это честный компромисс, не трюк. Кто понимает разницу - принимает осознанно. Кто не понимает - объясняем.

KVM из коробки - это оказалось важно

В 5.4 Red Hat добавил KVM в ядро в рамках процесса синхронизации с upstream. CentOS это унаследовал без изменений. Практически это значит: после установки системы /dev/kvm уже есть, kvm пакет в базовом репозитории, virsh и virt-manager ставятся без плясок с source или сторонними репами.

Для нас это важно вот почему. У одного из клиентов была задача: несколько гостевых VM на сервере под управлением Linux. Хостовая ОС должна быть RHEL-совместимой (требование того же вендора). Раньше в такой ситуации пришлось бы либо ставить настоящий RHEL с подпиской, либо собирать KVM из исходников на том, что есть, либо тащить VirtualBox. Сейчас - CentOS 5.4, yum install kvm, и можно разворачивать гостей.

Производительность KVM на реальном железе с VT-x нас не разочаровала. Это не сравнение с ESXi в рамках серьёзного бенчмарка, просто наблюдение: гостевые VM под нагрузкой ведут себя предсказуемо, overhead виден, но не критичен для тех задач, под которые это ставилось.

Что пришлось перестроить в голове

Переход с Debian на RHEL-мир требует пересмотра нескольких вещей, которые уже работают на автопилоте.

Пакетный менеджер. apt vs yum - это не просто разные команды. Репозитории устроены иначе, логика зависимостей другая, конфиг-файлы в других местах. Первые пару дней уходит на то, чтобы перестать набирать apt-get по привычке.

SELinux. В Debian его нет по умолчанию. В CentOS он есть и включён в enforcing-режиме. Первый рефлекс - выключить. Мы его подавили: SELinux правильно настроить сложнее, чем отключить, но тогда он реально что-то даёт. Несколько часов ушло на разбор audit.log и расстановку правил - зато потом система ведёт себя ожидаемо.

init vs upstart. В 5.4 ещё классический sysvinit с /etc/init.d/. Для нас это привычно, проблем не было.

Обновления. У CentOS обновления безопасности выходят с некоторым лагом после RHEL. Иногда это день-два, иногда неделя. Для продакшн-серверов это нужно иметь в виду и смотреть не только на centosannounce, но и на rhsa.redhat.com чтобы понимать что уже закрыто, а что ещё в очереди.

Что в итоге

Для двух клиентов вопрос RHEL-совместимости закрыт без подписки Red Hat. Сертифицированное ПО встало без проблем, вендорская техподдержка претензий к платформе не имеет. KVM работает на тех задачах, для которых его поставили.

Debian мы не бросаем - он остаётся основой там, где нет специфических требований к платформе. CentOS появился как инструмент для конкретного случая, и пока справляется.

Сопровождение серверов включает выбор дистрибутива под задачу клиента - это не вкусовщина, а конкретное техническое решение с последствиями.