(Примечание автора: этот ответ относится к RHEL 6 и предыдущим версиям. RHEL 7 теперь имеет полностью поддерживаемый путь обновления с RHEL 6, подробности которого приведены в конце.)

Для начала отмечу, что есть два пути для обновления на месте:

1. Вставьте установочный DVD (или используйте образ DVD через iLO / iDRAC), загрузитесь с него и выберите «Обновить», например linux upgradeany.
2. Обновите redhat-release RPM вручную, запустить 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.
• Приложения сторонних разработчиков или независимых поставщиков программного обеспечения могут работать некорректно после обновления.

Конечно, затем они описывают, как выполнить обновление на месте с помощью метода 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.

P.S. Я не совсем уверен, что важно в выводе ifconfig в этом контексте - он создается файлом конфигурации и некоторыми скриптами (иначе его не было бы при загрузке), и при необходимости ими можно управлять с помощью CMS.