Нещодавно з’явилася завдання створити і протестувати відмовостійкий кластер на Windows 2008 Server. Після створення подивитися, як буде все це працювати в реальних умовах виконуючи роль Принт-Сервера.

Завдання на перший погляд не складна, за винятком кількох моментів:

  • кластер було необхідно побудувати без використання SAN-сховища;
  • вузли даного кластера повинні розташовуватися в різних мережах (тобто територіально розподілені) і не мати між собою прямого з’єднання;
  • кількість вузлів в кластері дорівнює двом.

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

До цього я жодного разу не стикався з таким завданням – робилося все в перший раз. Варто відзначити, що робилося на віртуальних машинах Hyper-V – зараз це модно, повсюдне впровадження;) Тому хотів би поділитися деякими моментами (питаннями), які можуть у кого-небудь виникнути в процесі розгортання гео-розподіленого кластера.

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

Для створення відмовостійкого кластера необхідний, як мінімум, один загальний ресурс, доступний всім вузлів кластера. До даного ресурсу в певний момент часу може мати доступ і керувати ним, тільки один з вузлів кластера. Цей Ресурс, як не важко здогадатися, якесь сховище інформації. Організувати його можна двома способами – використовуючи або iSCSI SAN сховище. Варто відзначити, що SAN-сховище дуже не дешеве задоволення. Тим не менш воно є 😉 Але використовувати його для тестів і підняття Сервера Друку не доцільно. У iSCSI, за твердженнями багатьох, немає майбутнього – та воно і не потрібно (мається на увазі організовувати iSCSI-сховище). Тому було вирішено скористатися програмною реалізацією iSCSI-цілі – утилітою StarWind. Тим більше що iSCSI-ініціатор вже вбудований в операційну систему Windows 2008 Server. Плюс утиліта StarWind дозволяє абсолютно безкоштовно підключати сховища обсягом не більше 2 Гб – цього цілком достатньо як для проведення тестів, так і промислового використання сервера друку.

Як все має виглядати в кінцевому підсумку. Скажімо в місті А знаходитися один вузол кластера. У місті Б перебувати другий вузол кластера. Обидва вузла підключені до загального сховища. Кластер виконує роль SQL-сервера. Якщо виходить з ладу один з вузлів кластера, який є в даний момент його власником (і фактично надає доступ до бази даних SQL), його функції тут же підхоплює другий вузол. В результаті сервіс залишається доступним – всі клієнти просто перенаправляються до другого вузла кластера. При цьому не забуваємо, що вузли кластера знаходяться в різних містах. Це і є геораспределенный кластер.

Налаштування iSCSI-цілі, її підключення та налаштування ролей серверів описувати не буду – в інтернеті досить документації на цю тему. Скажу лише, що в якості моделі Кворуму була обрана модель Node and File Share Majority.

Перша проблема, яка виникла, як змусити кластер працювати з вузлами в різних мережах. Виявилося, що проблеми тут немає – кластер без проблем підключає вузли в різних мережах і підмереж. При необхідності, можна додатково прописати адреси (див. малюнок).

Геораспределенный кластер на Windows 2008 ServerГеораспределенный кластер на Windows 2008 Server
Геораспределенный кластер на Windows 2008 ServerГеораспределенный кластер на Windows 2008 Server

Досвідченим шляхом було встановлено механізм роботи кластера, який полягає в наступному – при створенні нової служби кластер створює в DNS запис типу A з IP-адресою чи іменем даного кластера. При виході з ладу одного з вузлів кластера, DNS запис перезаписується. Таким чином, ім’я кластера залишається колишнім, але IP-адреса змінюється. Якщо вузол, який стає головним, знаходитися в іншій підмережі – то і адресу кластера також буде з тієї ж підмережі (адреса попередньо задається при створенні кластера). Відповідно всі запити клієнтів будуть перенаправлятися в потрібну підмережа.

Друга проблема, яка виникла – час життя записи кластера в DNS. За замовчуванням воно становить 20 хвилин, тобто якщо один з вузлів кластера виходить з ладу – клієнти не дізнаються про це протягом 20 хвилин (у гіршому варіанті). Час підхоплення функцій вийшов з ладу вузла становить близько 15-20 секунд. Тобто працездатність сервісу відновлюється протягом 20 секунд, але клієнти дізнаються про це тільки через 20 хвилин. Це не прийнятно. Вручну задати час життя DNS-записи не виходить – при виході з ладу одного з вузлів запис в DNS перезаписується повністю, разом зі значенням поля TTL. Міняти ж TTL для всієї DNS-зони значить багаторазово збільшувати навантаження на DNS-сервера. Зменшити значення поля TTL виявилося можливо з допомогою команди cluster:

cluster /cluster: res /priv HostRecordTTL=

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

Дана стаття була запропонована для публікації відмінним системним адміністратором і блогером буржуйського ресурсу http://x-freedom.eu – go0dwin’ом.
Оригінал статті англійською – Geo-distributed Cluster / Multi-Site Cluster

Якщо Ви шукайте нову ідею підприємництва, то варто почитати оригінальні форми заробітку

LEAVE A REPLY

Please enter your comment!
Please enter your name here