ARUBA INSTANT WI-FI: ПРОСТІ, ПОТУЖНІ, ДОСТУПНІ
покращення кворуму
Результат «1» означає, що у ресурсу-свідка є голос. Значення «0» означає, що голоси немає.
Якщо вам до вподоби думка про те, що голос втрачає випадково обраний вузол, ви можете зробити одну з майданчиків основний (тобто майданчиком, на якій хочете збирати кворум). Надалі ви зможете вручну вибрати вузол, який повинен втратити голос в сценарії, який передбачає втручання порушника рівноваги. Наприклад, якщо ви хочете, щоб вузол на другорядній майданчику втратив голос, використовуйте команду:
У цій команді необхідно замінити вираз на ім'я вузла, який повинен втратити голос в разі виникнення рівноваги.
Як показано на екрані 1, ви можете перевірити наявність голосу у кожного вузла в кластері в вікні Nodes диспетчера Failover Cluster Manager. Завдяки цьому тепер набагато простіше дізнатися статус голосу всередині кластера, що дуже корисно, враховуючи всі можливості динамічного кворуму.
Зміни технології CSV
- При використанні технології CSV з кластерізованний дисковими просторами володіння томом CSV тепер динамічно перерозподіляється між вузлами кластера. Перерозподіл володіння допомагає краще збалансувати операції читання / запису на диску між вузлами. Якщо вузол видаляється з кластера або повторно приєднується до нього, баланс володіння томом CSV динамічно змінюється таким чином, щоб забезпечити оптимальний розподіл.
- Відмовостійкість механізму CSV була підвищена, завдяки використанню кількох екземплярів служби Server для кожного вузла. Таким чином, поділяються різні типи трафіку і мінімізується масштаб впливу в разі відмови служби.
- Були вдосконалені засоби діагностики проблем механізму CSV. Тепер для кожного екземпляра CSV диспетчер Failover Cluster Manager показує, чи включений на даному екземплярі режим введення-виведення (I / O) і з якої причини, якщо так.
По-друге, потрібно включити кеш CSV для кожного диска. Щоб на диску включити кеш CSV, ви можете задіяти команду:
Зміни в віртуалізації
Створення гостьових кластерів було можливим в системі Hyper-V протягом декількох років. Однак якщо гостьовим кластерам потрібно загальне сховище, необхідно було задіяти такі технології як протокол iSCSI і віртуальні підключення Fibre Channel. Хоча цей підхід ефективний, він відкриває для віртуальних машин інформацію про фізичних сховищах, а таке рішення не є ідеальним для багатьох оточень.
Для спільного використання файлу VHDX необхідно вибрати параметр Enable virtual hard disk sharing в настройках диска. Даний параметр ви можете знайти у вікні Advanced Features диспетчера Hyper-V Manager, показаному на екрані 2.
Екран 2. Включення загального доступу до файлу VHDX
Для настройки спільного використання віртуального жорсткого диска ви також можете задіяти оболонку PowerShell. Необхідно просто виконати команду Add-VMHardDiskDrive з параметром -ShareVirtualDisk:
Майте на увазі, що деякі механізми не працюють із загальним файлом VHDX, так як його задіють кілька операційних систем. Наприклад, спільно використовуваний файл VHDX:
- не може бути частиною реплицируемой даних Hyper-V Replica;
- не може бути переміщений за допомогою механізму динамічного сховища, необхідно відключити віртуальні машини, перш ніж переміщати спільно використовуваний файл VHDX;
- не дозволяє виробляти динамічна зміна розміру;
- не може бути частиною резервних копій рівня хост-сервера; ви не можете робити резервну копію загального файлу VHDX з хост-сервера Hyper-V.
Я сподіваюся, що ці обмеження будуть усунені в майбутніх версіях системи Windows Server, але поки про них важливо пам'ятати.
Остання зміна, пов'язане з виртуализацией, також направлено на те, щоб забезпечити максимально тривалу доступність віртуальних оточень. Поширена проблема з логічним механізмом Failover Clustering - виявлення відмов. Якщо вузол працює, і віртуальна машина теж, здається, що з віртуальним оточенням все в порядку. Однак мережевий адаптер може бути несправний або відключений, в результаті чого віртуальні машини не зможуть встановлювати зовнішні з'єднання з хост-сервером, що робить їх марними.
Екран 3. Налаштування захищеної мережі
Якщо захищена мережа недоступна, механізм Failover Clustering автоматично здійснює динамічну міграцію віртуальної машини на інший хост-сервер, що має підключення до потрібної мережі.
Кластер, що не приєднаний до каталогу AD
- Даний механізм мало підходить для кластерів, що використовують аутентифікацію Kerberos, так як аутентифікація Kerberos необхідна для виконання динамічної міграції в кластерах Hyper-V, а кластер Hyper-V, в якому неможлива динамічна міграція, марний.
- Даний механізм мало підходить для кластерів, що складаються з файлових серверів, так як протокол SMB найчастіше використовує аутентифікацію Kerberos.
- Не варто застосовувати цей механізм, якщо ви хочете використовувати технологію BitLocker для шифрування томів CSV, так як технології BitLocker потрібно об'єкт Cluster Name Object.
- Даний механізм не підходить, якщо ви використовуєте служби Microsoft Message Queue Services (MSMQ), так як служби MSMQ виконують запис в каталог AD.
Цей список дійсно переконує, що кластери, які не приєднані до каталогу Active-Directory, призначені виключно для оточень SQL Server, що використовують аутентифікацію SQL Server Authentication, і не рекомендуються до застосування в інших середовищах. Однак даний механізм виключно корисний для тих оточень SQL Server, які використовують аутентифікацію SQL Server Authentication і не мають прав на створення об'єктів в каталозі AD.
Технологія Failover Clustering і гипервизор Hyper-V зазнали помітної зміни. Але ще більшу увагу заслуговує той факт, що з кожною новою версією системи Windows Server механізми Hyper-V і Failover Clustering все тісніше переплітаються один з одним. При спільному використанні вони утворюють дуже потужну платформу віртуалізації. Крім того, механізм Failover Clustering продовжує бути основою, що забезпечує безперебійну роботу, для багатьох інших служб.
Поділіться матеріалом з колегами і друзями