Для виконання набору спеціальних перевірочних тестів можна використовувати майстер перевірки конфігурації, який інтегрований в диспетчер відмовостійкості кластерів, або командлет Test-Cluster Windows PowerShell. Цей процес можна виконати на наборі серверів, які будуть служити вузлами в кластері. При цьому базове устаткування і програмне забезпечення безпосередньо тестуються окремо, щоб отримати точну оцінку можливості підтримки відмовостійкої кластеризації в заданій конфігурації.
У цьому розділі описуються дії з перевірки обладнання для відмов кластеру.
Майстер перевірки конфігурації і командлет Test-Cluster Windows PowerShell дозволяють виконувати набір спеціальних тестів для набору серверів, мереж та пов'язаних систем зберігання, планованого для використання в якості відмов кластеру. У процесі перевірки кластера перевіряється базове устаткування і програмне забезпечення, щоб отримати точну оцінку можливостей підтримки відмовостійкої кластеризації в заданій конфігурації.
Перед створенням відмов кластеру настійно рекомендується виконати всі перевірочні тести кластера.
Перевірка кластера призначена для вирішення наступних завдань:
виявлення проблем з обладнанням або конфігурацією до перекладу відмов кластеру в робочий режим;
забезпечення надійної роботи, що розгортається рішення по кластеризації;
перевірка змін в обладнанні існуючого кластера;
виконання діагностичних тестів в існуючому кластері.
Система в повній конфігурації (сервери, мережі та підсистема зберігання) повинна пройти всі обов'язкові тести в майстра перевірки конфігурації, який можна запустити з диспетчера відмовостійкості кластерів. Перевірочні тести також можна виконувати за допомогою командлета Test-Cluster Windows PowerShell.
У наступних списках описані сценарії, в яких обов'язково або корисно виконати перевірку обладнання. Як правило, необхідно виконувати всі перевірочні тести (виключення відповідно позначені).
Перевірка перед налаштуванням кластера
Набір серверів, готових до включення в відмовостійкий кластер
Це найпростіший сценарій перевірки. Компоненти обладнання (системи, мережі та пристрої зберігання) підключені, але системи не працюють в якості кластера. Виконання тестів в такій ситуації не впливає на доступність.
Клоновані і відновлені з образу системи
Для клонованих систем і систем, відновлених з образу на іншому обладнанні, необхідно запускати майстер перевірки конфігурації так само, як і для будь-якого нового кластера. Рекомендується запускати майстер відразу після підключення компонентів обладнання і установки компонента "Відмовостійка кластеризація", поки кластер ще не використовується клієнтами.
Якщо в кластер входять віртуалізовані сервери, запустіть майстер перевірки конфігурації так само, як для нового кластера. Вимога використовувати майстер залишається колишнім і для кластера вузлів (коли резервне переключення виконується між двома фізичними комп'ютерами), і для гостьового кластера (коли резервне переключення виконується між операційними системами на віртуальних машинах на одному фізичному комп'ютері), і для інших конфігурацій, в які входить один або кілька віртуалізованих серверів.
Перевірка для кластера з одним вузлом
Для одного сервера, який планується до використання в кластері, можна виконати обмежене число перевірочних тестів. Деякі тести неможливо виконати в такій ситуації, наприклад тести, які перевіряють відповідність програм і оновлень на серверах, і тести систем зберігання, які імітують резервне переключення між вузлами. Для завершення процесу перевірки кластера в ньому має бути не менше двох вузлів. Тому після додавання серверів в конфігурацію необхідно знову запустити майстер перевірки конфігурації, щоб виконати всі тести.
Перевірка використовуваного кластера (після настройки)
Перед додаванням вузла
Коли сервер додається в кластер, настійно рекомендується спочатку підключити сервер до мереж кластера і систем зберігання даних, а потім запустити майстер перевірки конфігурації, задавши існуючі вузли кластера і новий вузол.
При додаванні системи зберігання
Коли в кластер додається нова система зберігання (це відрізняється від надання нового логічного номера пристрою (LUN) в існуючій системі зберігання), необхідно запустити майстер перевірки конфігурації, щоб підтвердити правильність роботи нової системи зберігання. Щоб мінімізувати можливі перешкоди на доступність, рекомендується запускати майстер після підключення системи зберігання, але до початку використання нових LUN в кластерних службах або додатках.
При внесенні змін, які зачіпають драйвери або вбудоване ПО
Якщо потрібно оновити кластер або внести в нього інші зміни, для яких потрібна заміна драйверів або вбудованого ПО, необхідно запустити майстер перевірки конфігурації, щоб підтвердити працездатність відмов кластеру в новому поєднанні обладнання, вбудованого програмного забезпечення, драйверів і програмного забезпечення. Якщо зміна поширюється на вбудоване ПО або драйвери для системи зберігання даних, рекомендується залишити невеликий пристрій LUN доступним (не використовуваним в кластерних ролях), щоб можна було виконувати перевірочні тести зберігання даних, які не переводячи кластерні ролі в автономний режим.
Після відновлення системи з резервної копії
Після відновлення системи з резервної копії запустіть майстер перевірки конфігурації, щоб підтвердити, що система правильно працює в складі кластера. До завершення перевірочних тестів система не вважається підтримуваної.
Під час перевірки змін в обладнанні існуючого кластера (в розширеному сценарії) деякі тести системи зберігання можна пропустити. За докладнішою інформацією та рекомендації см. В статті Розширені сценарії перевірки.
Командлет Test-Cluster Windows PowerShell за замовчуванням виконує всі тести сховища. Можна вказати параметр -Include. щоб виконати тільки тести сховища або тільки вказаний тест сховища. Параметри -Disk і -Pool дозволяють перевірити заданий ресурс зберігання (диск або пул). Параметри -Disk і -Pool задають відповідно один або декілька дисків і один або кілька пулів носіїв для включення в перевірочне тестування сховища. Якщо в параметрі -Disk або -Pool заданий диск або пул носіїв, який в даний момент підключений до мережі і призначений деякої кластерної ролі або загальному того кластера, то також необхідно вказати параметр -Force. щоб перевірити відповідний диск або пул носіїв. В іншому випадку необхідно перевести цей кластерний диск або пул носіїв в автономний режим перед виконанням тестів. Якщо параметри -Disk і -Pool не вказані, то командлет Test-Cluster виконує тести сховища на всіх дисках і пулах носіїв, які доступні для використання в кластері, працюють в автономному режимі або знаходяться в стані помилки. Рекомендується відключити кластерну роль або інший процес, який може використовувати диск або пул носіїв, перед включенням диска або пулу в перевірочне тестування.
Сховище, не підключені безпосередньо до всіх вузлів в кластері
Можливі ситуації, в яких в структуру кластера входить сховище, яке підключено не до всіх вузлів кластера. Поширеним прикладом служать Многосайтовий кластери, коли вузли кластера на сайті SiteA підключені до одного набору ресурсів зберігання, вузли на сайті SiteB підключені до іншого набору ресурсів зберігання, а для синхронізації даних на двох наборах ресурсів зберігання застосовується рішення по реплікації стороннього розробника. Відмов кластер виявляє таку асиметричну конфігурацію сховища, і диски на сайті SiteA перевіряються тільки з вузлами SiteA. а диски на сайті SiteB перевіряються тільки з вузлами SiteB.
Якщо відмовостійкий кластер пройшов повний набір перевірочних тестів і для нього не буде проводитися зміна устаткування і програмного забезпечення, то він буде вважатися підтримуваної конфігурацією. Однак після виконання регулярних оновлень програмних компонентів (драйвери, вбудоване ПО і т. П.) Може знадобитися знову запустити майстер перевірки конфігурації, щоб переконатися, що поточна конфігурація відмов кластеру як і раніше підтримується. Наступні рекомендації допоможуть визначити, коли це необхідно.
Тести конфігурації системи, тести обліку і тести мережі витрачають незначна кількість ресурсів і можуть виконуватися, практично не зачіпаючи роботу серверів в кластері.