Відмовостійка кластеризація - загальні відомості

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

Почнемо з того, що термін відмовостійкий не зовсім застосуємо до кластерним рішенням, він виник в результаті невірного перекладу терміна failover cluster. Правильний переклад - з обробкою відмови. хоча сьогодні все частіше вживається інший термін - високої доступності (high availability). який, на наш погляд, найбільш точно відображає суть справ.

Щоб зрозуміти, чому кластер не є ВІДМОВОСТІЙКО, розберемо більш детально його пристрій і схему роботи. Відразу уточнимо, що кластери застосовуються не тільки для забезпечення відмовостійкості, також кластерні схеми застосовують для балансування навантаження або нарощування обчислювальної потужності. Однак в рамках даного матеріалу ми будемо говорити саме про високодоступних кластерах.

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

По-перше це службова мережу кластера для передачі сигналу "пульсу" (heartbeat). за яким кластер стежить за станом своїх вузлів (на схемі показана червоним), мережа зберігання даних (SAN, синя), в недорогих рішеннях це найчастіше iSCSI через окрему Ethernet-мережа, але це може бути також і FibreChanell чи інші технології. Для обслуговування клієнтів кластер включається в існуючу локальну мережу.

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

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

Уважний Новомосковсктель повинен звернути увагу на існування в поступовим зниженням дози точки відмови - сховища. Дійсно, для забезпечення високої доступності сховище також має бути ВІДМОВОСТІЙКО або високодоступних. Це може бути реалізовано як покупкою спеціальних апаратних моделей, так і програмно, в тому числі і на базі відкритого ПЗ.

Якщо в якості сховища використовується iSCSI, то службову мережу кластера і мережу зберігання даних можна об'єднати. Але при цьому у нас залишається точка відмови - мережа, тому в відповідальних системах слід використовувати для доступу до SAN не менше двох мереж. Крім підвищення надійності даний підхід дозволяє підвищити пропускну здатність, що теж актуально.

Не можна не згадати і про програмні рішення, що дозволяють створити відмовостійкий кластер тільки на двох нодах, використовуючи в якості SAN віртуальне сховище. Наприклад, StarWind Virtual SAN, який створює віртуальне iSCSI сховище на базі локальних дисків кожного з вузлів. Це дозволяє знизити витрати на створення і розміщення отказоустойчивого сховища, але в той же час підвищує вимогу до продуктивності мережі між вузлами кластера, так як при запису на диск всі зміни тут-же синхронізуються між вузлами.

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

При відмові вузла все виконувалися на ньому віртуальні машини будуть перезапущени на інших вузлах, згідно виставленого пріоритету.

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

У наших наступних матеріалах ми розглянемо практичну реалізацію відмов кластеру на базі Hyper-V.