Налаштовуємо відмовостійкий кластер Hyper-V на базі Windows Server 2012

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

Все це здатне серйозно охолодити ентузіазм з приводу переваг віртуалізації, але вихід є і полягає він у створенні кластера високої доступності. Ми вже згадували про те, що термін "відмовостійкий" не зовсім коректний і тому сьогодні все частіше використовується інша характеристика, більш точно відображає стан справ - "високодоступних".

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

У цьому матеріалі ми будемо розглядати найбільш просту конфігурацію відмов кластеру, що складається з двох вузлів (нод) SRV12R2-NODE1 і SRV12R2-NODE2, кожен з яких працює під управлінням Windows Server 2012 R2. Обов'язковою умовою для цих серверів є застосування процесорів одного виробника, тільки Intel або тільки AMD, в іншому випадку міграція віртуальних машин між вузлами буде неможлива. Кожен вузол повинен бути підключений до двох мереж: мережі підприємства LAN і мережі зберігання даних SAN.

Другим обов'язковою умовою для створення кластеру є наявність розгорнутої Active Directory, в нашій схемі вона представлена ​​контролером домену SRV12R2-DC1.

Сховище виконано за технологією iSCSI і може бути реалізовано на будь-якої зручної платформі, в даному випадку це ще один сервер на Windows Server 2012 R2 - SRV12R2-STOR. Сервер сховища може бути підключений до мережі підприємства і бути членом домену, але це не обов'язкова умова. Пропускна здатність мережі зберігання даних повинна бути не нижче 1 Гбіт / с.

Будемо вважати, що на обидва вузла вже встановлена ​​операційна система, вони введені в домен і мережеві підключення налаштовані. Відкриємо Майстер додавання ролей і компонентів і додамо роль Hyper-V.

Наступним кроком додамо компоненту Відмовостійка кластеризація.

На сторінці налаштування віртуальних комутаторів вибираємо той мережевий адаптер, який підключений до мережі підприємства.

Міграцію віртуальних машин залишаємо виключеною.

Інші параметри залишаємо без зміни. Установка ролі Hyper-V зажадає перезавантаження, після чого аналогічним чином налаштовуємо другий вузол.

Потім перейдемо до сервера сховища, як налаштувати iSCSI-сховище на базі Windows Server 2012 ми розповідали в даній статті , Але це не принципово, ви можете використовувати будь-який сервер мети iSCSI. Для нормальної роботи кластера нам буде потрібно створити мінімум два віртуальних диска: диск свідка кворуму і диск для зберігання віртуальних машин. Диск-свідок - це службовий ресурс кластера, в рамках даної статті ми не будемо торкатися його ролі і механізму роботи, для нього досить виділити мінімальний розмір, в нашому випадку 1ГБ.

Створіть нову мету iSCSI і дозвольте доступ до неї двом ініціаторам, в якості яких будуть виступати вузли кластера.

І зіставте даної мети створені віртуальні диски.

Налаштувавши сховище, повернемося на один з вузлів і підключимо диски зі сховища. Пам'ятайте, що якщо сервер сховища підключений також до локальної мережі, то при підключенні до мети iSCSI вкажіть для доступу мережу зберігання даних.

Підключення диски инициализируем і форматіруем.

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

Після чого відкриємо Диспетчер Hyper-V і перейдемо до налаштування віртуальних комутаторів. Їх назва на обох вузлах повинно повністю збігатися.

Тепер у нас все готово до створення кластера. Запустимо оснащення Диспетчер відмов кластерів і виберемо дію Перевірити конфігурацію.

В налаштуваннях майстра додамо налаштовані нами вузли і виберемо виконання всіх тестів.

Перевірки займають відчутне час, при виникненні будь-яких помилок їх необхідно виправити і повторити перевірку.

Якщо істотних помилок не виявлено робота майстра завершиться і він запропонує вам створити на обраних вузлах кластер.

Однак, якщо перевірка видала попередження, ми радимо вивчити звіт і з'ясувати на що впливає дане попередження і що потрібно зробити для його усунення. У нашому випадку майстер попереджав нас про відсутність надмірності в мережевих підключеннях кластера, за замовчуванням кластер не використовує мережі iSCSI, що неважко виправити пізніше.

При створенні кластера для нього створюється віртуальний об'єкт, що володіє мережевим ім'ям і адресою. Зазначимо їх в розпочатому Майстрі створення кластерів.

На наступному кроці радимо зняти прапорець Додавання всіх допустимих сховищ в кластер, так як майстер не завжди правильно призначає ролі дискам і все одно доведеться перевіряти і, при необхідності виправляти, вручну.

Більше питань не буде і майстер повідомить нам, що кластер створено, видавши при цьому попередження про відсутність диска-свідка.

Закриємо майстер і розгорнемо дерево зліва до рівня Сховище - Диски, в доступних діях справа виберемо Додати диск і вкажемо підключаються диски в вікні, в нашому випадку їх два.

Потім клацнемо правою кнопкою миші на об'єкті кластера в дереві зліва і виберемо Додаткові дії - Налаштувати параметри кворуму в кластері.

Далі послідовно вибираємо: Вибрати свідок кворуму - Налаштувати диск-свідок і вказуємо створений для цих цілей диск.

Тепер налаштуємо диск сховища, з ним все набагато простіше, просто клацаємо на диску правою кнопкою і вказуємо: Додати в загальні сховища кластера.

Для того, щоб диск міг використовуватися відразу декількома учасниками кластера на ньому створюється CSVFS - реалізована поверх NTFS кластерна файлова система, що вперше з'явилася в Windows Server 2008 R2 і дозволяє використовувати такі функції як Динамічна (Жива) міграція, тобто передачу віртуальної машини між вузлами кластера без зупинки її роботи.

Загальні сховища стають доступні на всіх вузлах кластера в розташуванні C: \ ClusterStorage \ VolumeN. Зверніть увагу, що це не просто папки на системному диску, а точки монтування загальних томів кластера.

Закінчивши з дисками, перейдемо до налаштувань мережі, для цього перейдемо в розділ Мережі. Для мережі, яка підключена до мережі підприємства вказуємо Дозволити кластеру використовувати цю мережу і Дозволити клієнтам підключатися через цю мережу. Для мережі зберігання даних просто залишимо Дозволити кластеру використовувати цю мережу, таким чином забезпечивши необхідну надмірність мережевих з'єднань.

На цьому настройка кластера закінчена. Для роботи з кластерізованний віртуальними машинами слід використовувати Диспетчер відмовостійкості кластерів, а не Диспетчер Hyper-V, який призначений для управління віртуалкою розташованими локально.

Щоб створити віртуальну машину перейдіть в розділ Ролі в меню правої кнопки миші виберіть Віртуальні машини - Створити віртуальну машину, це ж можна зробити і через панель Дії справа.

Перш за все виберіть вузол, на якому буде створена віртуальна машина. Кожна виртуалка працює на певному вузлі кластера, мігруючи на інші вузли при зупинці або відмову своєї Ноди.

Після вибору вузла відкриється стандартний Майстер створення віртуальної машини, робота з ним не представляє складності, тому зупинимося тільки на значущих моментах. Як розташування віртуальної машини обов'язково вкажіть один із загальних томів кластера C: \ ClusterStorage \ VolumeN.

Тут же повинен розташовуватися і віртуальний жорсткий диск, ви також можете використовувати вже існуючі віртуальні жорсткі диски, попередньо скопіювавши їх в загальне сховище.

Після створення віртуальної машини перейдіть в її Параметри і в пункті Процесори - Сумісність встановіть прапорець перенесення на фізичний комп'ютер з іншою версією процесора, це дозволить виконувати міграцію між вузлами з різними моделями процесорів одного виробника. Міграція з Intel на AMD або навпаки неможлива.

Потім перейдіть в Мережевий адаптер - Апаратне прискорення і переконайтеся, що обрані опції підтримуються мережевими картами всіх вузлів кластера або вимкніть їх.

Не забудьте налаштувати автоматичні дії при запуску і завершенні роботи вузла, при великій кількості віртуальних машин не забувайте встановлювати затримку запуску, щоб уникнути надмірного навантаження на систему.

Закінчивши з Параметрами перейдіть в Властивості віртуальної машини і вкажіть бажані вузли власників даної ролі в порядку убування і пріоритет, машини мають більш високий пріоритет мігрують першими.

На закладці Обробка відмови задайте кількість допустимих відмов для віртуальної машини за одиницю часу, пам'ятайте, що відмовою вважається не тільки відмова вузла, але і втрата пульсу віртуальної машини, наприклад, її зависання. На час налаштування і тестів є сенс вказати значення побільше.

Також налаштуйте Відновлення розміщення, ця опція дозволяє передавати віртуальні машини назад найбільш кращого власнику при відновленні його нормальної роботи. Щоб уникнути надмірних навантажень скористайтеся опцією затримки відновлення.

На цьому настройка віртуальної машини закінчена, можемо запускати і працювати з нею.

Тепер саме час перевірити міграцію, для цього клацніть на машині правою кнопкою миші і виберіть Перемістити - Динамічна міграція - Вибрати вузол. Виртуалка повинна переміститися на обрану ноду завершувати роботи.

Яким чином відбувається міграція в робочій обстановці? Припустимо нам треба вимкнути або перезавантажити перший вузол, на якому в даний момент виконується віртуальна машина. Отримавши команду на завершення роботи вузол ініціює передачу віртуальних машин:

Завершення роботи припиняється до тих пір, поки не будуть передані всі віртуальні машини.

Коли робота вузла буде відновлена, кластер, якщо включено відновлення розміщення, ініціює зворотний процес, передаючи віртуальну машину назад кращого власнику.

Що станеться якщо вузол, на якому розміщені віртуальні машини аварійно вимкнеться або перезавантажиться? Все виртуалки також аварійно завершать свою роботу, але тут-таки будуть перезапущени на справних вузлах згідно списку бажаних власників.

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

Кластер Hyper-V не забезпечує відмовостійкості віртуальним машинам, відмова вузла призводить до відмови всіх розміщених на ньому машин, але він дозволяє забезпечити вашим службам високу доступність, автоматично відновлюючи їх роботу і забезпечуючи мінімально можливий час простою. Також він дозволяє значно полегшити адміністрування віртуальної інфраструктури дозволяючи переміщувати віртуальні машини між вузлами без переривання їхньої роботи.