Вопрос: Почему так сложно обновить основные версии Red Hat и CentOS?


«Можем ли мы модернизировать наши существующие серверы EL5 на EL6?»

Простой запрос от двух клиентов с полностью разные среды подсказывали мой обычный ответ лучшей практики «да», но для этого потребуется скоординированное перестройка всех ваших систем»...

Оба клиента считают, что полная перестройка их систем является неприемлемым вариантом для простоя и причин ресурсов ... На вопрос, почему необходимо полностью переустановить системы, у меня не было хорошего ответа дальше, «так оно и есть ...»

Я не пытаюсь получить ответы на вопросы об управлении конфигурацией («Купите все" не всегда применяется) или как клиенты должны были планировать лучше. Это реальный пример среды, которая выросла и процветала в производственной мощности, но не видит чистого пути перехода к следующей версии своей ОС.

Окружающая среда A:
Некоммерческая организация с 40 x Red Hat Enterprise Linux 5.4 и 5.5 веб-серверы баз данных и почтовые серверы, выполняющие стек веб-приложений Java, балансировщики программного обеспечения и базы данных Postgres. Все системы виртуализированы на двух кластерах VMWare vSphere в разных местах, каждый с HA, DRS и т. Д.

Окружающая среда B:
Высокочастотная финансовая торговая фирма с 200 x CentOS 5.x системы в нескольких местах совместного размещения, где производятся торговые операции, поддерживаются внутренние разработки и функции бэк-офиса. Торговые серверы работают на аппаратном оборудовании товарного сервера на основе чистого металла. У них много sysctl.conf, rtctl, привязка прерываний и настройки драйвера для снижения задержки обмена сообщениями. У некоторых есть пользовательские и / или ядра реального времени. На рабочих станциях разработчика также работают аналогичные версии CentOS.


В обоих случаях среда работает хорошо, как есть. Желание обновиться связано с необходимостью нового приложения или функции, доступной в EL6.

  • Для некоммерческой фирмы это связано с Apache, ядром и некоторыми вещами, которые сделают разработчиков счастливыми.
  • В торговой фирме речь идет о некоторых улучшениях в ядре, сетевом стеке и GLIBC, что сделает разработчиков счастливыми.

Обе вещи не могут быть легко упакованы или обновлены без радикальное изменение операционной системы,

Как системный инженер, я ценю, что Red Hat рекомендует полностью перестраивать при переходе между версиями основных версий. Чистый старт заставляет вас реорганизовать и уделять внимание конфигурациям на этом пути.

Будучи чувствительным к деловым потребностям клиентов, мне интересно, почему это должно быть обременительная задача, Система упаковки RPM более чем способна обрабатывать обновления на месте, но это небольшие детали, которые вы получаете: /boot требуя больше места, новые файловые системы по умолчанию, RPM, возможно, прерывая средние обновления, устаревшие и несуществующие пакеты ...

Какой ответ здесь? Другие дистрибутивы (.deb-based, Arch и Gentoo), похоже, имеют эту способность или лучший путь. Предположим, мы нашли время простоя для выполнения этой задачи. правильно путь:

  • Что должны делать эти клиенты, чтобы избежать такой же проблемы, когда EL7 выпускается и стабилизируется?
  • Или это случай, когда люди должны смириться с перестройками каждые несколько лет?
  • Это, похоже, ухудшилось по мере развития Enterprise Linux ... Или я просто воображаю это?
  • Разве это отговаривало кого-либо от использования Red Hat и производных операционных систем?

Я полагаю, что есть угол управления конфигурацией, но большинство установок Puppet, которые я вижу, плохо переходят в среды с высоко настраиваемыми серверами приложений (Среда B может иметь один сервер, чей ifconfig вывод выглядит так). Мне было бы интересно услышать предложения о том, как можно использовать управление конфигурацией, чтобы помочь организациям получить доступ к основной версии RHEL.


70
2017-11-15 15:14


Источник


Я собирался отметить это для закрытия как «неконструктивное», когда увидел имя автора и репутацию, и из уважения я этого не сделаю. Я все еще думаю, что это глупый вопрос, потому что ответ заключается в том, что «Red Hat решила, что это должно быть так». 4-битные обновления были вполне возможны благодаря загрузке DVD, и были процедуры для этого в реальном времени, используя yum, который работал для меня большую часть времени. Моя единственная надежда состоит в том, что RH взяли огромный ударил боль от своих платежных клиентов за то, что они решили не поддерживать поддерживаемый путь обновления 5-> 6, и переосмыслит это для 6-> 7. - MadHatter
Тем не менее, вы знаете, что есть рабочий неподдерживаемый путь обновления через загрузку DVD с C5-> C6, используя upgradeany параметр времени загрузки, да? Я тестировал его дважды, однажды на чистой C5-установке, где он работал нормально; один раз на (тестовая копия a) жесткая старая «раньше была C4 и была обновлена», установите там, где она резко потерпела неудачу. - MadHatter
Я хорошо осведомлен о вариантах upgradeany и определенно принуждаю установки, используя подход RPM в реальном времени (изменение репо, *-release files и все). Но вопросы клиентов на этой неделе заставили меня больше думать о том, как укоренившаяся среда может стать с конкретной версией и не иметь пути. - ewwhite


Ответы:


(Примечание автора: Этот ответ относится к 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.
  • Приложения сторонних разработчиков или ISV могут работать неправильно после обновления.

Конечно, они затем описывают, как сделать обновление на месте с помощью метода 1, на случай, если вы действительно этого захотите. Функция существует, и Red Hat помещает в нее время разработки, поэтому она поддерживается тем, что функция существует. Но если что-то пойдет не так, Red Hat скажет вам установить свежий; они не будут предоставлять поддержку поставщиков для вещей, которые ломаются в результате обновления.

Для записи у меня никогда не возникало проблемы с обновлением системы RHEL / CentOS или Fedora на месте, которую я не мог решить самостоятельно. Типичные проблемы возникают из переименованных пакетов, сторонних репозиториев и случайного несоответствия версий между архитектурами i386 и x86_64 пакета. Установщик немного лучше справляется с этим, чем yum, Я думаю.


Как мне обновить?

Я вообще предупреждаю людей, что они должны план в окне обслуживания каждые 3-4 года обновлять системы RHEL с одной основной версии на другую. Хотя обновления обычно идут гладко, неожиданное может случиться.

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

Для большого развертывания, такого как вы здесь, рассмотрите подход Limoncelli «один-несколько». Обновите одну машину, посмотрите, какие проблемы возникли, разрешите их, затем используйте уроки, извлеченные при обновлении небольшой партии машин, повторите извлеченные уроки, а затем, когда вы считаете, что все изломы выработаны, обновите их большими партиями.

В то же время я также рекомендую внимательно изучить процесс развертывания вашего приложения. Если он недостаточно автоматизирован, вы можете запустить его с помощью одной команды и быть достаточно уверенным, что приложение будет развернуто правильно, то, возможно, разработчики должны работать над этим. Наличие такого процесса развертывания упростит новую установку новой версии 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).


41
2017-11-15 17:09



Новый инструмент обновления Fedora называется надоело, Три-четыре года звучат агрессивно для меня и для крупных модернизаций. Должны быть установлены, я вижу, что они намного больше соответствуют жизненному циклу RHEL на 10+ лет, поэтому я бы рекомендовал более регулярные незначительные обновления. - Dominic Cleal
Для людей, которые нуждаются в новых функциях на постоянной основе, 3-4 года почти слишком велики. - Michael Hampton♦
Простые вещи, такие как PHP, Apache, версии ядра и GLIBC ... Люди склонны чаще менять эти изменения. - ewwhite
Процесс обновления Debian / Ubuntu не идеален, но тот факт, что это предпочтительный механизм обновления, и Red Hat не имеют официально поддерживаемого механизма обновления, говорит мне тома. - Paul Gear
Это не так много, если существуют обновления на месте, как они это делают, но предоставляют ли соответствующие поставщики поддержку для них. - Michael Hampton♦


Я возьму последний абзац:

Я полагаю, что есть угол управления конфигурацией, но большинство установок Puppet, которые я вижу, плохо переходят в среды с высоко настраиваемыми серверами приложений (среда B может иметь один сервер, чей вывод ifconfig выглядит так). Мне было бы интересно услышать предложения о том, как можно использовать управление конфигурацией, чтобы помочь организациям получить доступ к основной версии RHEL.

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

Я знаю, что это не решает вашу непосредственную проблему, но для меня это связано с тем, что организация думает о серверах, а не о сервисах. В ориентированном на обслуживание мышлении индивидуальность отдельных серверов не должна поддерживаться до тех пор, пока служба продолжает функционировать. Если CMS используется дисциплинированно, чтобы построить всю услугу, то перемещение этого сервиса в другую систему должно быть относительно простым, потому что все личность машины будет построена CMS.

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


5
2017-11-20 22:28



Вы правы в отношении услуг и серверов в общем смысле. В среде B имеется специализированное серверное оборудование (сетевые адаптеры 10GbE, библиотеки разгрузки), которые взаимодействуют с поставщиками восходящего потока. Это то, что не может быть сбалансировано по нагрузке или легко перемещаться без простоя. Нефинансовый пример будет чем-то вроде сервера, прикрепленного в качестве контроллера для некоторых задействованных механизмов производства. Особый случай, возможно, с выделенными интерфейсами PCIe. Очень одноразовая настройка, уникальная для сервера. В Puppet вы бы просто сказали: «Вот конфигурация для этого хоста / роли» и жить с ним? - ewwhite
Согласитесь, некоторые вещи нелегко вписаться в общие случаи, особенно если у вас есть среда с конкретными требованиями к оборудованию. С марионеткой, как можно больше вписывается в эту роль, имеет смысл. Но в итоге он должен работать, поэтому, если что-то не очень элегантное заставляет его работать, тогда я просто живу с ним, будучи неэлегантным. Большую часть времени мы должны жить с вещами, которые неэлегантны просто потому, что у нас нет времени, чтобы сделать их «правильными». - Paul Gear