"Чи можемо ми оновити існуючі виробничі сервери 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, Arch та Gentoo), схоже, мають цю здатність або кращий шлях. Скажімо , ми знаходимо час простою для виконання цього завдання на правильному шляху:

• Що робити цим клієнтам, щоб уникнути тієї ж проблеми, коли EL7 випускається та стабілізується?
• Або це випадок, коли людям потрібно звільнитися з повними перебудовами кожні кілька років?
• Це, здається, погіршилося, коли Enterprise Linux розвивався ... Або я просто уявляю це?
• Це відвертало когось від використання Red Hat та похідних операційних систем?

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

(Примітка автора: Ця відповідь стосується RHEL 6 та попередніх версій. RHEL 7 тепер має повністю підтримуваний шлях оновлення від RHEL 6, деталі якого є в кінці.)

Для початку зауважу, що оновлення на місці є двома способами :

1. Завантажте інсталяційний DVD (або використовуйте зображення DVD через iLO / iDRAC), завантажте з нього і виберіть Оновити, наприклад linux upgradeany.
2. Оновіть 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 (наприклад, пакет кластерів), його, можливо, потрібно буде оновити вручну після завершення оновлення 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).

Я приймаю ваш останній абзац:

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

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

Я знаю, що це не вирішує вашу безпосередню проблему, але для мене це випливає з організації, що мислить з точки зору серверів, а не послуг. У сервісно-орієнтованому мисленні особистість окремих серверів не повинна підтримуватися до тих пір, поки служба продовжує функціонувати. Якщо CMS використовується дисципліновано для побудови всієї послуги, то переміщення цієї послуги в іншу систему повинно бути досить простим, оскільки вся особистість машини буде будуватися CMS.

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