В Windows Server 2012 з'явилася технологія SMB Scale-Out, що дозволяє створювати масштабовані файлові кластера - Scale-Out File Server (SOFS). SOFS вдає із себе новий тип файлового кластера, що працює в режимі Active-Active. У цьому режимі всі вузли кластера можуть одночасно обробляти запити SMB-клієнтів на підключення до файловим кулях.

Принцип роботи Scale-Out File Server

Для підключення до стандартного кластеру клієнт використовує спеціальну точку підключення Client Access Point (CAP). CAP є кластерним ресурсом і складається з мережевого імені (Network Name, NN) і одного (або кількох) унікальних IP-адрес. Також файловий кластер може включати в себе ресурси типу Storage і File Server.

При відповідній настройці CAP реєструється в DNS \ WINS. Ось так в DNS виглядає звичайна точка доступу клієнта (CAP) двовузлового файлового кластера.

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

SOFS використовує інший підхід для роботи з клієнтами.Для цього використовується ресурси розподіленого мережного імені (Distributed Network Name, DNN) і Scale-Out File Server. Ресурси IP-адреси і сховища не використовуються.

Група ресурсів Scale-Out File Server запускається на одному з вузлів кластера, який називається лідером (Leader). Всі інші вузли містять копії (клони) групи ресурсів.Клони управляються лідером, який стежить за порядком їх запуску і зупинки, а також відстежує їх стан. Група ресурсів SOFS не вимикається, поки доступний хоч один клон. Лідер може бути перенесений на будь-який з вузлів кластера, його рух не позначиться на доступність файлових куля.

Хоча SOFS і не використовує IP-адреса в якості кластерного ресурсу, DNN залежить від адрес кожного вузла кластера. DNN реєструється в DNS, використовуючи IP-адреси мережевих інтерфейсів всіх вузлів кластера, на яких обробляються клієнтські підключення. Ось так в DNS виглядає запис DNN для двовузлового кластера SOFS.

DNN відповідає за відстеження стану вузлів кластера і оновлення інформації в DNS:

• Кожні 24 години, або при запуску DNN;
• У разі додавання або видалення вузлів кластера;
• при зміні IP-адреси;
• при додаванні або видалення IP-адреси з мережі кластера.

Для розподілу підключень до вузлів кластера в DNS використовується round-robin. SMB-клієнт отримує повний список адрес, пов'язаних з DNN, і потім намагається підключитися, використовуючи по черзі перші вісім адрес зі списку. Спроби відбуваються з інтервалом в 1 секунду до тих пір, поки не відбудеться підключення.

Таким чином, на відміну від звичайного кластера, в якому всі клієнти підключаються до одного вузла (режим Active-Passive), при використанні кластера SOFS клієнтські підключення рівномірно розподіляються між усіма вузлами кластера (режим Active-Active).

Робота Scale-Out File Server базується на кількох нових технологіях, про які варто згадати.

Cluster Shared Volume (CSVv2)

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

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

Технологія CSV з'явилася ще в Windows Server 2008 R2, однак тоді загальні томи CSV можна було задіяти виключно для ролі Hyper-V.Починаючи з другої версії (CSVv2) в Windows Server 2012 ці обмеження зняті і можна використовувати CSV-томи для ролі отказоустойчивого файлового сервера. Тобто ми можемо конфігурувати кластер з одним або декількома томами CSV, підняти на ньому роль Scale-Out File Server і в рамках цієї ролі створити на CSV необхідну кількість файлових куля, одночасний доступ до яких буде можливий з будь-якого з вузлів кластера.

SMB Transparent Failover

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

При відпрацюванні відмови в звичайному файловому кластері в тому ж Windows Server 2008 R2 існувало 2 основних проблеми.По-перше, при перемиканні на інший вузол клієнту необхідно було визначити факт недоступності поточного вузла і здійснити підключення до працюючого вузла. Ця процедура займає деякий час (близько 40 секунд), протягом якого припинялися всі операції з файлами.І по-друге, при перемиканні скидалися всі файлові дескриптори і блокування. Як правило, це не завдавало особливих проблем при роботі з звичайними для користувача файлами (документами, зображеннями і т.п.), але для серверних додатків типу SQL Server подібний підхід неприпустимий.

SMB Transparent Failover вирішує обидві проблеми і забезпечує безперервну доступність загальних файлових ресурсів для клієнтів SMB 3.0. Для цього в SMB 3.0 використовуються компоненти SMB Witness і Resume Key Filter.

При підключенні до загальної кулі SMB-клієнт перевіряє, чи встановлений для неї ознака безперервної доступності (Continuous availability), і якщо так - то відкриває файл від імені додатки, запитує у SMB-сервера дескриптор файлу і надає унікальний ключ (resume key).SMB-сервер витягує і надає клієнту необхідні дані, а інформацію про дескрипторі файлу і клієнтський ключ зберігає на диску, використовуючи фільтр Resume Key.

При перемиканні (плановому або позаплановому) на інший вузол кластера SMB-клієнт намагається завершити операцію, розпочату на попередньому вузлі, використовуючи свій resume key.Сервер, отримавши resume key, звертається до фільтру Resume Key і відновлює стан дескриптора файлу на момент, що передує збою. При цьому додаток на клієнті ніяк не бере участі в цьому процесі і відчуває лише невелику затримку в операціях введення-виведення.

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

Як тільки на вузлі кластера, до якого підключений SMB-клієнт, відбувається збій, служба кластера оповіщає про нього Witness-сервіс альтернативного вузла, який відразу-ж передає повідомлення Witness-клієнту. Відповідно клієнт SMB, отримавши повідомлення від Witness-клієнта, негайно починає процедуру підключення до іншого вузла кластера.Подібний підхід дозволяє значно зменшити час простою (приблизно з 40 до 7-10 секунд).

Треба сказати, що оскільки SOFS використовує можливості протоколу SMB 3.0, то для використання всіх переваг SOFS необхідний клієнт з підтримкою цього протоколу. На даний момент це операційні системи Windows 8 \ Server 2012 і більш нові.Хоча підключитися до куль на файловому сервері SOFS зможуть і інші клієнти, але прозора відпрацювання відмови (Transparent failover) для них не буде доступна.

На цьому закінчимо теоретичну частину і приступимо до практики.

Для створення двовузлового файлового сервера з роллю Scale-Out File Server я використовую два сервера SRV3 і SRV4 під керуванням Windows Server 2012 R2.Обидва сервера підключені до загального сховища iSCSI, на якому під потреби кластера виділено 2 LUNа - один під те CSV, другий під кворумний диск. Обидва сервера є членами домену Active Directory.

Начебто всі необхідні вимоги дотримані, можна приступати.

Установка служби Failover Clustering

Відкриваємо Server Manager, запускаємо майстер додавання ролей і в розділі «Features» відзначаємо пункт Failover Clustering.Цю процедуру необхідно виконати на всіх серверах, які планується додавати в кластер.

Те ж саме можна проробити і з допомогою PowerShell. Наступна команда встановить фичу Failover Clustering разом із засобами управління:

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Створення відмов кластеру

Для створення кластера нам буде потрібно оснащення Failover Cluster Manager.Відкрити її можна з Server Manager, вибравши відповідний пункт в меню Tools.

Перед тим, як створювати кластер, проведемо валідацію його вузлів, тобто перевірку всіх компонентів кластера (серверів, мережі та сховища) на відповідність необхідним вимогам. Для запуску валідації в оснащенні Failover Cluster Manager перейдемо на пункт «Validate Configuration».

Запускається майстер перевірки конфігурації. На першому екрані читаємо корисну інформацію і тиснемо Next.

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

На наступній сторінці Testing Options можна вибрати конкретні набори тестів, або вказати запуск всіх тестів.Вибір певних тестів може знадобиться при пошуку проблем на вже готовому кластері, а при створенні нового кластера варто запустити всі тести.

Дивимося список тестів і тиснемо Next, запускаючи перевірку.

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

За результатами перевірки буде виведений звіт. Якщо при перевірці були виявлені некритичні помилки, то в звіті буде попередження (жовтий трикутник), серйозні помилки будуть відзначені червоним хрестом.З попередженнями варто ознайомитися, але можна їх проігнорувати, помилки ж необхідно виправити перед створенням кластеру.

Оскільки наш кластер успішно пройшов валідацію, то відзначаємо чекбокс Create the cluster now using the validated nodes (Створити кластер негайно використовуючи перевірені вузли ) і тиснемо Finish.

Запускається майстер створення кластера. Тиснемо Next

Вводимо ім'я кластера і IP-адресу, за якою кластер буде доступний в мережі.

Примітка. Починаючи з Windows Server 2012 IP-адрес кластера можна призначати через DHCP, але я віддаю перевагу призначати кластерам статичний адресу.

Далі переходимо на сторінку підтвердження, дивимося настройки і якщо все вірно, то запускаємо створення кластера кнопкою Next. Зверніть увагу на чекбокс Add all eligible storage to the cluster (Додати всі підходящі сховища в кластер). Якщо він відзначений (а за замовчуванням це так), то майстер автоматично додасть в кластер і сконфигурирует всі знайдені загальні диски.

По завершенні майстер видасть сторінку з інформацією про параметри нового кластера.

Також провести валідацію і створити кластер можна за допомогою PowerShell, наступними командами:

Test-Cluster -Node SRV3, SRV4
New-Cluster -Name Cluster1 -Node SRV3, SRV4 -StaticAddress 192.168.0.100

Налаштування диска-свідка

При створенні кластера за замовчуванням використовується модель кворуму з диском-свідком (Disk Witness), при цьому диск-свідок вибирається автоматично, і іноді не той, який потрібен.Для того, щоб перевірити настройки дисків, відкриваємо розділ Storage -> Disks. Диск-свідок позначений як Disk Witness in Quorum. Як бачите, в нашому випадку в якості свідка вибраний не той диск, який я спочатку планував.

Щоб змінити установки кворуму натискаємо правою кнопкою миші на імені кластера та переходимо на пункт меню More Actions -> Configure Cluster Quorum Settings.

В майстра настройки вибираємо пункт Select the quorum witness.

Потім вибираємо Configure a disk witness.

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

Перевіряємо отримані настройки і тиснемо Next, підтверджуючи зміни.

Також переналаштувати диски можна з PowerShell. Спочатку з'ясовуємо, хто є кворумним диском-свідком:

Get-ClusterQuorum -Cluster Cluster1

і міняємо його на інший:

Set-ClusterQuorum -Cluster Cluster1 - DiskWitness "Cluster Disk 2"

Створення CSV

на відміну від Server 2008 R2 в Server 2012 загальні кластерні томи (CSV) включені за замовчуванням, потрібно тільки вибрати сховище.Щоб активувати CSV на вибраному диску, клікаєм по ньому правою кнопкою і вибираємо Add to Cluster Shared Volumes. Після цього поле Assigned to цього диска зміниться з Available Storage на Cluster Shared Volume.

Загальні кластерні томи монтуються до системного диску як папки, так що на кожному з вузлів кластера з'явиться папка C: \ ClusterStorage \ Volume1.

І знову PowerShell. Для створення CSV-томи виконаємо команду:

Add-ClusterSharedVolume -Cluster Cluster1 -Name "Cluster Disk 1"

Ну а для видалення, відповідно:

Remove -ClusterSharedVolume -Cluster Cluster1 -Name "Cluster Disk 1"

В результаті отримуємо ось таку картину - перший диск використовується як CSV-те, а другий як диск-свідок.

Установка ролі Scale-Out File Server

Перед створенням Scale-Out File Server переконайтеся, що на всіх вузлах кластера встановлена ​​роль File Server.

Потім в Failover Cluster Manager переходимо в розділ Configure і тиснемо Configure Role.

Вибираємо зі списку доступних ролей File Server.

Потім вибираємо тип файлового сервера Scale-Out File Server for application data.

Вводимо ім'я, по якому сервер буде доступний для клієнтів.

Підтверджуємо настройки

і дивимося результат. А в результаті у нас вийшов відмовостійкий файловий сервер з ім'ям FileSRV1.

Підняти роль SOFS-сервера з PowerShell можна командою:

Add -ClusterScaleOutFileServerRole -Cluster Cluster1 -Name FileSRV1

створення файлової кулі

Ну і останній пункт - це створення файлової кулі з властивістю безперервної доступності (Continuous availability). Для цього переходимо в розділ «Roles», натискаємо правою клавішею на потрібної ролі і в контекстному меню вибираємо пункт «Add File Share».

Вибираємо зі списку тип SMB Share - Applications

вказуємо розташування файлової кулі на обраному сервері

і ставимо ім'я і опис, а також локальний і віддалений шляху до кулі.

Потім дивимося, відзначений чи у властивостях кулі пункт «Enable continuous avalability».

Роздаємо необхідні дозволи.

Перевіряємо отримані параметри і тиснемо «Create». Зверніть увагу, що у властивостях кулі вказано Scale-Out file share.

Висновок

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

По-перше, SOFS не підтримує протокол NFS, а також ролі Distributed File System Replication (DFS-R) і File Server Resource Manager (FSRM). Тобто для файлових куля не можна задіяти файлові квоти, класифікацію файлів та інші корисності.

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

І навпаки, ідеальною для SOFS є ситуація, коли файли постійно відкриті і в них проводиться велика кількість операцій введення-виведення, як у випадку з файлами баз даних SQL Server або віртуальними дисками Hyper-V.

Виходячи з цього, кластер SOFS не рекомендується використовувати для звичайного зберігання призначених для користувача файлів, а варто використовувати для серверних додатків, таких як SQL Server і Hyper-V..