Налаштування VMware vSphere: де ламається кластер
Кластер найчастіше ламається не на етапі встановлення, а на налаштуванні відмовостійкості: хост є, сховище під’єднано, віртуальні машини працюють — до першого збою гіпервізора.
У цей момент з’ясовується, що пріоритети перезапуску не задані, а резервний хост або відсутній, або на ньому не вистачає ресурсів. Простій інфраструктури тоді вимірюється не хвилинами, а часом до того, як черговий інженер помітить проблему.
Єдина точка відмови майже завжди ховається в одному з чотирьох місць. Окремий хост, який тримає навантаження, але не має пари в кластері. Спільне сховище, під’єднане одним шляхом: відмова комутатора або порту робить томи недоступними одразу для всіх вузлів.
Керуючий вузол або служба каталогу в єдиному екземплярі. І мережа, де трафік керування, міграції та віртуальних машин іде одними фізичними каналами.
Ручний перезапуск віртуальних машин виглядає безпечним, поки відмов не було. На практиці відновлення залежить від людини: ніч, вихідні, відпустка — і сервіс лежить до ранку.
Додайте порядок запуску: база даних має піднятися раніше за застосунок, інакше застосунок піде в цикл перезапусків і додасть до простою ще півгодини.
І відсутність перевірок відмови. Правила розміщення, пріоритети перезапуску, резервування шляхів і ізоляція мережі налаштовуються один раз і не тестуються — а реальна відмова гіпервізора розкриває розбіжність між очікуваною та фактичною поведінкою.
Розбираємо, як це закривається налаштуванням VMware vSphere: від схеми розміщення до навчань із примусовим вимкненням вузла.
Що змінюється після впровадження: простій, відновлення, відмови
Кластер на VMware vSphere оцінюють не за кількістю налаштованих вузлів, а за тим, як поводяться сервіси в момент відмови. Нижче — чотири метрики, які ми знімаємо до та після впровадження і за ними приймаємо роботу.
Час відновлення сервісів: хвилини замість годин
При відмові фізичного вузла віртуальні машини автоматично піднімаються на тих, що залишилися — сервіс повертається в роботу за одиниці хвилин, а не за час, поки черговий доїде до майданчика і вручну переналаштує запуск.
Для критичних систем задається пріоритет перезапуску: спочатку піднімається те, від чого залежать інші.
Усунений клас відмов обладнання
Зникає цілий клас аварій, пов’язаних з одним вузлом: вихід з ладу блока живлення, диска, мережевого порту або каналу до сховища більше не зупиняє сервіс.
Арбітражний вузол зберігає кворум при втраті основного майданчика — кластер не розпадається на дві половини і не починає конкурувати за ресурси.
Автоматичне перемикання без ручних операцій
Частка ручних дій чергового при відмові падає майже до нуля: перезапуск, вибір вузла та повернення ресурсів виконуються правилами кластера. Людина залишається в процесі лише там, де потрібне рішення — наприклад, відкотити реліз після невдалого оновлення.
Доступність сервісів і навантаження на чергового
Доступність рахується за фактом: частка часу, коли сервіс відповідає, зростає за рахунок того, що короткі відмови перестають перетворюватися на простій. Нічні підйоми за тривогою скорочуються — більшість інцидентів закривається автоматикою до того, як черговий відкриє телефон.
Режими відмовостійкості vSphere: що вибрати
Режим кластера визначають два обмеження: де лежать дані віртуальних машин і наскільки далеко один від одного вузли. Звідси розвилки — локальний диск або спільне сховище, один майданчик або два, один керуючий вузол або кворум.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Окремі вузли на локальних дисках | пілот, тестовий контур, ізольований сервіс | міграція вручну, простій до відновлення з резервної копії |
| Кластер високої доступності на спільному сховищі | основний контур від трьох вузлів | обов’язкові спільний том і резервування шляхів доступу, чутливість до затримки до масиву |
| Кластер високої доступності та планування розміщення | різнорідне навантаження, різні класи сервісів | сумісні набори інструкцій на всіх вузлах, правила розміщення задаються вручну |
| Розтягнутий кластер на два майданчики | безперервність при відмові майданчика | третій майданчик-свідок, низька затримка між майданчиками, синхронна реплікація |
Кількість вузлів підкоряється кворуму: у кластер високої доступності беремо не менше трьох, щоб втрата хоста не залишала керуючий контур у невизначеному стані.
Мережу розділяємо на трафік керування та трафік сховища — при спільному томі це прибирає конкуренцію за смугу та хибні спрацювання моніторингу.
Сумісність обмежують чотири перевірки до розгортання: підтримка багатошляхового доступу масивом, режим завантаження вузлів, драйвери під вибрану гілку платформи та коректний кворум між майданчиками.
Якщо хоча б одна не проходить, режим знижується — це краще з’ясувати на проєктуванні, ніж при відмові.
Порядок впровадження: від аудиту до передачі в експлуатацію
Кластер не збирається за типовим шаблоном: конфігурація залежить від кількості хостів, класу сховища та профілю навантаження. Тому порядок робіт фіксуємо до старту, і кожен етап закінчується перевірюваним артефактом, а не звітом про факт виконаних робіт.
- Аудит інфраструктури. Інвентаризуємо хости, мережеві сегменти, масиви та поточні віртуальні машини, знімаємо карту залежностей між сервісами. На виході — перелік вузьких місць: перевантажені сховища, одиночні шляхи до СХД, відсутність резервування на комутаторах.
- Схема розміщення вузлів. Розподіляємо хости за стійками, зонами живлення та мережевими парами так, щоб відмова будь-якого одного елемента не валила кластер. Рахуємо резерв ресурсів під правило N+1 і правила балансування.
- Підготовка платформи. Розмічаємо мережі: службовий трафік, міграції, доступ до сховищ через iSCSI або NFS, окремі VLAN, узгоджений розмір кадру. Налаштовуємо профілі сховищ і політики відмовостійкості.
- Конфігурування кластера. Вмикаємо високу доступність з контролем резерву, задаємо heartbeat-сховища, пріоритети та порядок перезапуску віртуальних машин, ізоляцію вузла при втраті зв’язку.
- Перевірка на стенді. Проганяємо тестові навантаження, планові міграції та деградацію сховища, заміряємо час відгуку під піком. Правки вносимо до виведення в продуктивне середовище.
- Навчання з відмови. По черзі вимикаємо хост, живлення стійки, обриваємо аплінк і імітуємо недоступність масиву. Фіксуємо фактичний час перезапуску сервісів і втрати даних.
- Передача в експлуатацію. Віддаємо регламенти обслуговування, карти відновлення, налаштований моніторинг і пороги оповіщень, проводимо навчання чергової зміни та узгоджуємо вікна робіт.
Документація, схеми та політики доступу
Кластер передається не як «чорна скринька»: разом з працюючими вузлами ви отримуєте комплект матеріалів, за якими його можна обслуговувати, розширювати та відновлювати без нас. Нижче — мінімум, який ми фіксуємо в кінці робіт.
- Схема розміщення. Групи відмовостійкості, де лежать дані кластера, який запас ємності залишається при відмові одного вузла і як розподілені машини за хостами.
- Схеми мереж. Розділення трафіку керування, міграції, доступу до сховища та гостьового сегмента, резервні шляхи й агрегація каналів.
- Конфігурації. Вивантаження налаштувань вузлів і спільного шару керування з позначкою, що змінено відносно заводських значень і навіщо.
- Ролі та права адміністраторів. Розмежування за зонами відповідальності: мережа, запуск машин, читання журналів. Сервісні задачі йдуть під окремими обліковими записами.
- Політики доступу. Точки входу в інтерфейси керування, обов’язкова багатофакторна перевірка, журналювання дій, вимкнення простоюючих записів.
- Регламент обслуговування. Періодичність оновлень, перевірка дисків і датчиків, ревізія знімків і вільного місця, порядок узгодження вікна робіт.
- Регламент відновлення. Черговість підйому, місця зберігання резервних копій налаштувань, перевірка відновлення на тестовому контурі.
- Контроль стану. Критичні події та пороги, кому надходять оповіщення, типові дії чергової зміни при відмові вузла або шляху.
Кейс: кластер витримав відмову вузла в робочий день
Замовник — виробнича компанія, де кластер віртуалізації на VMware vSphere із шести вузлів обслуговував близько 120 віртуальних машин: облікові системи, файловий обмін, аналітику по цехах.
Відмова одного хоста до робіт означала ручний розбір — черговий інженер піднімав віртуальні машини на вцілілих вузлах, простій у робочий час сягав 40 хвилин, а порядок запуску залежав від того, хто першим помітив проблему.
Кластер перезібрали під автоматичне перемикання: увімкнули високу доступність із пріоритетами перезапуску, зарезервували частку ресурсів під рестарт, щоб уцілілі вузли гарантовано прийняли навантаження, і винесли сигнали доступності в окремий сегмент мережі.
Віртуальні машини розклали за групами пріоритету — спочатку бази даних і контролери, потім другорядні сервіси.
Відмова в середині робочого дня
Через кілька тижнів після здачі вузол втратив живлення в розпал зміни. Кластер перемкнув машини автоматично: критичний контур був доступний через 2 хвилини, інші сервіси — за 4, порядок запуску витримався без участі людей.
Метрики до та після: простій критичних сервісів — 40 хвилин проти 2, повне відновлення — півтори години проти 4 хвилин, частка відмов, відпрацьованих кластером без інженера, — 100%.
Планові роботи тепер ідуть без вікна обслуговування: вузол виводять з кластера, оновлюють і повертають, а навантаження їде на інших.
Чим відрізняється відмовостійкий кластер від резервного копіювання?
Це два різних механізми з різними задачами, і один не замінює інший. Відмовостійкий кластер відповідає за безперервність роботи: при відмові фізичного сервера його віртуальні машини автоматично піднімаються на живих вузлах, і сервіс продовжує відповідати.
Резервне копіювання відповідає за захист даних — можливість повернути систему до стану на минулий момент часу.
Кластер працює з поточним станом: спільний пул ресурсів у VMware vSphere, розподіл навантаження, автоматичний перезапуск при відмові. Простій скорочується до часу підйому віртуальної машини — хвилини замість годин, поки інженери лагодять залізо.
Але від логічних помилок кластер не захищає: якщо база видалена помилково, прийшло шифрувальне зараження або оновлення зіпсувало дані, репліка чесно повторить це на всіх вузлах — відкочувати буде нічого. Апаратна відмова та втрата даних — різні класи збоїв, і захист від першого не закриває другий.
Резервна копія зберігається окремо і фіксує стан на момент зняття: її можна розгорнути на тому самому або іншому кластері, підняти окрему копію для перевірки, відновити один файл або систему цілком.
Тому обидва шари плануємо одразу — кластер, снапшоти для коротких операцій і копії на незалежному сховищі за розкладом.
Сценарії відновлення прописуємо і перевіряємо на навчаннях: відмова вузла, відмова майданчика, помилкове видалення, псування даних. Для кожного — своє джерело відновлення і свій час, за який сервіс повертається в роботу.
Технічні питання, які задають до початку робіт
Перед оцінкою ми проходимо по чотирьох питаннях, які найчастіше змінюють схему кластера. Відповіді короткі, але саме вони визначають, чи потрібно докуповувати обладнання і скільки вікон обслуговування закласти в план підготовки до впровадження.
Чи підійде обладнання, яке вже стоїть у стійці?
На етапі підготовки знімаємо інвентаризацію: підтримка віртуалізації в прошивці, обсяг пам’яті під потрібну щільність машин, окремі мережеві порти під трафік сховища та живу міграцію. За результатом говоримо прямо, які вузли підуть у кластер, а які залишаться під тестовий контур.
Чи можна зібрати відмовостійкість без зовнішньої системи зберігання?
Так. Локальні диски кожного вузла об’єднуються у відмовостійкий пул, а дані реплікуються між серверами. При відмові одного вузла машини піднімаються на інших, але вільне місце резервується інакше — це враховуємо при плануванні ємності.
Як проходить планове обслуговування без простою?
По одному вузлу: переводимо віртуальні машини на вільні, виводимо вузол з кластера, оновлюємо гіпервізор і прошивки, повертаємо назад. Порядок вузлів і вікна обслуговування фіксуємо заздалегідь, щоб не потрапляти в пікові навантаження.
Як переконатися, що перемикання справді працює?
Перевіряємо не за індикаторами, а імітацією відмови: знеструмлюємо вузол або розриваємо мережу і дивимося, за який час піднялися критичні сервіси і чи не втратилися дані. Підсумок — звіт із заміряним часом відновлення та списком зауважень.
Обговоримо задачу: що потрібно для оцінки
Щоб повернутися не із загальними словами, а зі схемою рішення та планом робіт, нам потрібен зріз поточної інфраструктури. Нижче — мінімальний набір; якщо чогось немає, скажіть одразу, підкажемо, як це зібрати.
- Склад кластера та навантаження: число фізичних хостів, їх покоління, розміщення за стійками та зонами, кількість і профіль віртуальних машин, пікові значення за процесором, пам’яттю та диском.
- Сховища: локальні диски, спільна система зберігання або програмно-визначувана, які рівні захисту даних налаштовані і як організовані резервні копії.
- Мережа: схема комутації, розділення трафіку керування, машин, міграції та зберігання, наявність надлишкових каналів і резервних шляхів.
- Вимоги до простоїв: допустимий час недоступності сервісів, точки відновлення, що критично, а що можна перезапустити вручну.
- Доступи для обстеження: облікові записи з правами лише на читання за хостами та системою керування (VMware vSphere), доступ до інтерфейсів зберігання та комутаторів, вікно на зняття метрик.
- Цільова задача та обмеження: нове розгортання, переїзд, розділення контурів або оновлення платформи; вікна робіт і правила безпеки, які не можна порушувати.
З цих даних складається склад кластера, схема розміщення та політики відмовостійкості. Опишіть задачу і надішліть те, що вже є, — повернемося зі схемою рішення, планом робіт та оцінкою.
