ADG Оставить заявку
Блог Инфраструктура 4 мин чтения

Ubuntu 8.04 LTS «Hardy Heron»: пятилетняя поддержка server-edition и наш план апгрейда

Canonical анонсировала Ubuntu 8.04 LTS с пятилетней поддержкой Server Edition - подходящий момент проверить совместимость и спланировать переезд с Ubuntu 6.06 LTS.

Контекст момента

Анонс Ubuntu 8.04 LTS «Hardy Heron» с пятилетней поддержкой Server Edition, релиз запланирован на апрель 2008

Canonical подтвердила дату релиза Ubuntu 8.04 LTS «Hardy Heron» - апрель 2008 года. Для нас это не просто очередной релиз, а повод взяться за задачу, которую мы откладывали последние несколько месяцев: спланировать апгрейд Linux-серверов с Ubuntu 6.06 LTS «Dapper Drake».

У «Дрэппера» поддержка заканчивается в июне 2009 года. Это не завтра, но год пролетит быстро - особенно если учесть, что у нас несколько десятков серверов на этой базе у разных клиентов, и апгрейд никогда не бывает быстрым там, где ждёшь.

Что даёт 8.04 LTS именно в Server Edition

Для десктопной версии LTS означает три года поддержки. Для Server Edition Canonical обещает пять лет - до 2013 года. Это ключевое отличие, которое делает Hardy реально интересным для production: не надо будет планировать очередную миграцию через два года.

Из конкретных изменений, которые нас касаются:

Linux-ядро 2.6.24 - здесь появился нормальный cgroups и заметно улучшился планировщик. На серверах с высокой нагрузкой это должно проявиться, хотя без тестов на реальном железе - только предположения.

OpenSSH 4.7 - security-патчи относительно того, что стоит на «Дрэппере», плюс несколько изменений в поведении. Это надо будет проверить против наших конфигов.

MySQL 5.0 остаётся в основе, но с обновлёнными патчами. Для тех клиентов, где мы ведём MySQL в рамках сопровождения инфраструктуры, это плюс - меньше ручных security-обновлений.

PHP 5.2.4 - принципиально важно для нескольких клиентских стендов, где сейчас живут приложения под 5.1.x с Dapper. Совместимость надо будет проверять.

Postfix 2.5 и Samba 3.0.28 - более новые версии относительно Dapper, но совместимость наших конфигов вопросов не вызывает.

Что нас реально беспокоит: скрипты и пакеты

Накопленный за два года набор инструментов - это всегда головная боль при миграции. У нас есть несколько категорий вещей, которые надо проверить до того, как трогать production.

Самописные backup-скрипты. Большинство написаны на bash с расчётом на конкретные версии rsync и tar. В теории - должно работать. На практике - неожиданности бывают в самых скучных местах. Запустим на тестовой машине и посмотрим.

Пакеты из PPA и сторонних репозиториев. Для некоторых клиентов мы ставили пакеты, которых нет в стандартном репозитории Ubuntu. На Hardy у них могут быть новые версии, могут быть конфликты, могут вообще не существовать сборки под новый дистрибутив. Это придётся проверять по каждому хосту.

Мониторинговые агенты. После того как мы на прошлой неделе переехали на Nagios 3.0, конфигурации NRPE надо будет перепроверить на новом дистрибутиве. Скорее всего пересобирать из исходников не потребуется - но проверить обязательно.

Cron-задачи с путями. Классика: скрипт в cron завязан на конкретный путь к интерпретатору или утилите, а на новом дистрибутиве путь изменился. Ловится только при запуске, а не при установке.

Как планируем делать

Апгрейдить большой парк серверов на новый дистрибутив методом do-release-upgrade прямо в production - не наш вариант. Да, это работает, и Canonical явно тестировала этот путь. Но «работает у соседей» и «работает у нас» - разные вещи.

Наш план выглядит так:

Первое - тестовый стенд. Поднять виртуальную машину с Ubuntu 8.04 LTS server и прогнать на ней весь типовой стек: Apache, MySQL, PHP, Postfix, NRPE, наши скрипты. Зафиксировать что сломалось и что потребовало правок.

Второе - инвентаризация. У нас есть список серверов на 6.06 LTS, но он неполный - часть сведений разбросана по задачам в тикет-системе. Прежде чем планировать апгрейды, нужно собрать честный список с версиями установленных пакетов и зависимостей.

Третье - приоритизация. Не все серверы одинаково критичны. Начнём с тех, где нагрузка ниже и где можно позволить себе окно обслуживания без сложной координации с клиентом.

Четвёртое - свежая установка вместо апгрейда там, где это возможно. Если сервер можно пересоздать - лучше поставить 8.04 чисто и перенести данные и конфигурацию, чем тянуть историю Dapper в Hardy. Это дольше, но результат предсказуемее.

Сейчас

Hardy официально ещё не вышел. Пока смотрим на бета-релизы и читаем release notes. Тестовый стенд поднимем как только выйдет RC - нет смысла начинать с бетой, если релиз в апреле уже на горизонте.

Главная цель сейчас - не торопиться, но и не ждать до последнего. Лучше потратить три месяца на спокойный поэтапный переезд, чем за полгода до конца поддержки Dapper обнаружить, что треть серверов требует нетривиальных правок.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.