Почему так сложно выполнить обновление между основными версиями Red Hat и CentOS?
"Можем ли мы обновить наши существующие производственные серверы EL5 до EL6?"
Простой звучащий запрос от двух клиентов с совершенно разными средами вызвал мой обычный ответ "да, но это потребует скоординированной перестройки всех ваших систем "...
Оба клиента считают, что полная перестройка их систем является неприемлемым вариантом из-за простоя и из-за недостатка ресурсов... Когда меня спросили, зачем нужно было полностью переустанавливать системы, у меня не было хорошего ответа, кроме того, что "так оно и есть"...."
Я не пытаюсь получить ответы об управлении конфигурацией ("Puppetize all" не всегда применимо) или о том, как клиенты должны были планировать лучше. Это реальный пример сред, которые выросли и преуспели в производственных мощностях, но не видят четкого пути перехода к следующей версии своей ОС.
Окружающая среда А:
Некоммерческая организация с 40 веб-серверами Red Hat Enterprise Linux 5.4 и 5.5, серверами баз данных и почтовыми серверами, работающей со стеком веб-приложений Java, балансировщиками нагрузки программного обеспечения и базами данных Postgres. Все системы виртуализированы в двух кластерах VMWare vSphere в разных местах, каждый с HA, DRS и т. Д.
Окружающая среда Б:
Высокочастотная финансово-торговая фирма с системами 200 x CentOS 5.x в нескольких средствах совместного размещения, осуществляющих производственные торговые операции, поддерживающих собственные разработки и вспомогательные функции. Торговые серверы работают на обычном аппаратном серверном оборудовании. У них есть многочисленные sysctl.conf, rtctl, прерывание привязки и драйверы на месте для снижения задержки обмена сообщениями. Некоторые имеют собственные ядра и / или ядра реального времени. Рабочие станции разработчиков также используют аналогичные версии CentOS.
В обоих случаях среда работает хорошо, как есть. Желание обновиться связано с необходимостью более нового приложения или функции, доступной в EL6.
- Для некоммерческой фирмы это связано с Apache, ядром и некоторыми вещами, которые сделают разработчиков счастливыми.
- В торговой фирме речь идет о некоторых улучшениях в ядре, сетевом стеке и GLIBC, которые порадуют разработчиков.
Это вещи, которые нельзя легко упаковать или обновить без кардинального изменения операционной системы.
Как системный инженер, я ценю, что Red Hat рекомендует полностью перестраивать при переходе между основными версиями. Чистый старт заставляет вас проводить рефакторинг и обращать внимание на конфиги по пути.
Будучи чувствительным к бизнес-потребностям клиентов, я удивляюсь, почему это должно быть такой обременительной задачей. Система упаковки RPM более чем способна обрабатывать обновления на месте, но вы получаете следующие мелкие детали: /boot требующий больше места, новые файловые системы по умолчанию, RPM, возможно, ломающиеся в середине обновления, устаревшие и несуществующие пакеты...
Какой ответ здесь? Другие дистрибутивы (на основе.deb, Arch и Gentoo), похоже, имеют эту возможность или лучший путь. Допустим, мы находим время простоя для правильного выполнения этой задачи:
- Что эти клиенты должны сделать, чтобы избежать той же проблемы, когда EL7 выпущен и стабилизируется?
- Или это тот случай, когда люди должны смириться с полной перестройкой каждые несколько лет?
- Кажется, с развитием Enterprise Linux все стало еще хуже... Или я просто представляю это?
- Отговорил ли это кого-нибудь от использования Red Hat и производных операционных систем?
Я полагаю, что есть угол управления конфигурацией, но большинство установок Puppet, которые я вижу, плохо переносятся в среды с сильно настроенными серверами приложений (в среде B может быть один сервер, ifconfig выход выглядит так). Мне было бы интересно услышать предложения о том, как можно использовать управление конфигурацией, чтобы помочь организациям справиться с проблемой основной версии RHEL.
2 ответа
(Примечание автора. Этот ответ относится к RHEL 6 и более ранним версиям. RHEL 7 теперь имеет полностью поддерживаемый путь обновления с RHEL 6, подробности которого приведены в конце.)
Для начала следует отметить, что есть два способа выполнить обновление на месте:
- Вставьте установочный DVD (или используйте образ DVD через iLO/iDRAC), загрузитесь с него и выберите Upgrade, например
linux upgradeany, - Обновите
redhat-releaseRPM вручную, запуститьyum distro-sync(это немного упрощено) и перезагрузите компьютер.
Способ 1 просто не поддерживается. Метод 2 для настоящих ковбоев. В дополнение к рекомендуемым свежим установкам, я сделал оба этих...
Нужна ли мне поддержка?
Поддержка имеет два дополнительных значения в нашем мире. Во-первых, продукт имеет заданную функцию (например, "Postfix поддерживает SMTP"). Во-вторых, продавец поговорит с вами об этом. Какое определение подразумевается, не всегда ясно из контекста.
Чтобы выполнить задачу, вам, очевидно, нужна поддержка в первом смысле. Поддержка поставщиков заключается в том, чтобы помочь вам в решении проблем и предоставить поставщику обратную связь относительно того, какие функции должны существовать или быть улучшены. Многие сайты платят целое состояние за поддержку поставщиков, если у них есть собственный опыт решения любых проблем, которые могут возникнуть, быстрее и даже дешевле, чем поставщик может. Независимо от того, стоит ли покупать поддержку поставщика, вы должны принять бизнес-решение (или проконсультировать руководство).
Почему бы не сделать обновление на месте?
Вот что говорит по этому поводу Red Hat:
Red Hat не поддерживает обновления на месте между основными версиями Red Hat Enterprise Linux. Основная версия обозначается изменением версии целым числом. Например, Red Hat Enterprise Linux 5 и Red Hat Enterprise Linux 6 являются основными версиями Red Hat Enterprise Linux.
Обновления на месте для основных выпусков не сохраняют все системные настройки, службы или пользовательские конфигурации. Следовательно, Red Hat настоятельно рекомендует новые установки при обновлении с одной основной версии на другую.
Они также предупреждают:
Однако обратите внимание на следующие ограничения, прежде чем вы решите обновить свою систему:
- Отдельные файлы конфигурации пакета могут работать или не работать после выполнения обновления из-за изменений в различных форматах или форматах файлов конфигурации.
- Если у вас установлен один из многоуровневых продуктов Red Hat (например, Cluster Suite), его может потребоваться обновить вручную после завершения обновления Red Hat Enterprise Linux.
- Сторонние приложения или приложения ISV могут работать некорректно после обновления.
Конечно, они затем описывают, как выполнить обновление на месте с помощью метода 1, на тот случай, если вы действительно хотите это сделать. Функция существует, и Red Hat вкладывает в нее время разработки, поэтому она поддерживается в том случае, если она существует. Но если что-то пойдет не так, Red Hat скажет вам установить все заново; они не будут предоставлять поддержку поставщика для вещей, которые ломаются в результате обновления.
Для справки, у меня никогда не было проблем с обновлением на месте системы RHEL/CentOS или Fedora, которые я не мог решить самостоятельно. Типичные проблемы возникают из-за переименованных пакетов, сторонних репозиториев и случайного несоответствия версий между архитектурами пакетов i386 и x86_64. Инсталлятор немного лучше справляется с этим, чем yum, Я думаю.
Как мне обновить?
Я обычно предупреждаю людей, что им следует планировать период обслуживания каждые 3-4 года для обновления систем RHEL с одной основной версии на другую. В то время как обновления, как правило, проходят гладко, неожиданные события могут происходить всегда.
Я ожидаю, что для обеих ваших сред будет работать обновление на месте, хотя я настоятельно рекомендую сначала тщательно его протестировать. P2V - типичный образец серверов и проведите обновление на месте в виртуальных системах, чтобы увидеть, с какими проблемами вы столкнетесь. Затем вы можете спланировать фактическое обновление производства, основываясь на лучшем знании того, что произойдет.
Для большого развертывания, такого как у вас здесь, рассмотрите возможность использования подхода Лимончелли "один-несколько-много". Обновите одну машину, посмотрите, какие проблемы возникают, решите их, затем используйте извлеченные уроки при обновлении небольшой партии машин, повторите процедуру извлеченных уроков, а затем, когда вы считаете, что у вас все петли проработаны, обновите их большими партиями.
В такое время я также рекомендую внимательно изучить процесс развертывания вашего приложения. Если он недостаточно автоматизирован, чтобы вы могли запустить его с помощью одной команды и быть достаточно уверенным, что приложение будет развернуто правильно, возможно, разработчики должны приступить к работе над этим. Наличие такого процесса развертывания значительно упростит процесс новой установки новой версии EL и последующего развертывания на нем.
Поможет ли переключение дистрибутивов?
Дистрибутивы на основе Debian имеют поддерживаемый метод обновления на месте, и он в основном работает, но он не застрахован от проблем. Например, многое изменилось для людей, которые обновили Ubuntu 10.04 LTS до 12.04 LTS с помощью поддерживаемого метода. Не ясно, что Debian или Canonical затрачивают достаточно времени на "поддержку" этой функции, то есть, чтобы убедиться, что она работает. И вам все равно придется купить поддержку поставщика для этого дистрибутива, если вы хотите, чтобы кто-то держал вас за руку. Поэтому я сомневаюсь, что вы многое выиграете от перехода на такой дистрибутив.
Вы можете выиграть, переключившись на скользящий выпуск, такой как Gentoo или Arch. Однако это также не делает вас невосприимчивым к проблемам; это просто означает, что вам приходится постоянно решать проблемы с обновлением в течение всего срока службы сервера (например, всякий раз, когда вы или разработчики решаете обновить что-либо в системе), а не все сразу в хорошо спланированное время обновления дистрибутива. У вас также нет поставщика для оказания поддержки.
Что в будущем?
Проект Fedora работает над инструментом для улучшения обновлений на месте. У них был инструмент под названием preupgrade который был заброшен и заменен новым инструментом под названием fedup, начиная с Fedora 18. Это было добавлено к RHEL7, и теперь обновления на месте имеют полную поддержку, по крайней мере, с RHEL 6 до RHEL 7. По своему опыту могу сказать, что пока fedup все еще есть некоторые изломы, это формируется, чтобы быть очень полезным инструментом.
CentOS также экспериментирует с хранилищем с непрерывным выпуском, но это применимо только к второстепенным версиям (например, 6.3-6.4).
Мой взгляд на ваш последний абзац:
Я полагаю, что есть угол управления конфигурацией, но большинство установок Puppet, которые я вижу, плохо транслируются в среды с сильно настроенными серверами приложений (в среде B может быть один сервер, у которого вывод ifconfig выглядит следующим образом). Мне было бы интересно услышать предложения о том, как можно использовать управление конфигурацией, чтобы помочь организациям справиться с проблемой основной версии RHEL.
Я думаю, что реальная ценность систем управления конфигурациями, особенно в контексте среды B, заключается в том, что они предоставляют инструменты для создания службы независимо от серверов, на которых она выполняется. Если CMS не использовалась для создания существующих сервисов, то, вероятно, это не очень поможет в воссоздании сервисов.
Я знаю, что это не решает вашу непосредственную проблему, но для меня это связано с тем, что организация думает о серверах, а не об услугах. В мышлении, ориентированном на обслуживание, индивидуальность отдельных серверов не требуется поддерживать, пока служба продолжает функционировать. Если CMS используется дисциплинированным образом для создания всего сервиса, то перемещение этого сервиса в другую систему должно быть относительно простым, потому что CMS создаст всю индивидуальность машины.
PS Я не совсем уверен, что важно в выводе ifconfig в этом контексте - он создается с помощью файла конфигурации и некоторых сценариев (в противном случае он не будет там при загрузке), и ими можно управлять с помощью CMS, если это необходимо.