Відмовостійкий кластер

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

• Повинен бути відносно простий спосіб запуску, зупинки, примусової зупинки, і перевірки стану додатка. На практиці це означає, що додаток має мати інтерфейс командної стрічки або скрипту для управління ним, в тому числі для роботи з декількома запущеними екземплярами додатка.
• Додаток повинен вміти використовувати загальне сховище даних (NAS / SAN).
• Важливо, що додаток має зберігати в загальному сховищі максимально можливу кількість даних про свій поточний стан.
• Додаток не повинен пошкоджувати дані при виході з ладу або відновленні з збереженого стану.

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

• Active / active — Частина трафіку, що обробляє відмову вузла, перенаправляється до працюючого вузла або розподіляється між кількома працюючими вузлами. Така схема використовується в тому випадку, коли вузли мають однорідну конфігурацію програмного забезпечення і виконують однакову задачу[2].
• Active / passive — Має повне резервування (дійсну копію) кожного вузла. Резерв використовується тільки тоді, коли відмовляє відповідний основний вузол. Ця конфігурація вимагає значних надлишкових апаратних засобів.
• N + 1 — Має один повноцінний резервний вузол, до якого в момент відмови переходить роль вузла, що не доступний в даний момент часу. У разі гетерогенної програмної конфігурації основних вузлів додатковий вузол, повинен бути здатний взяти на себе роль кожного з основних вузлів, за резервування котрих, він відповідає. Така схема застосовується в кластерах, які обслуговують кілька різнорідних сервісів, що працюють одночасно.
• N + M — Якщо один кластер обслуговує кілька сервісів, включення в кластер єдиного резервного вузла може виявитися недостатнім для належного рівня резервування. У таких випадках в кластер включається кілька резервних серверів, кількість яких є компромісом між ціною рішення і необхідної надійністю.
• N-к-1 — Дозволяє резервному вузлу вмикатися в роботу тимчасово, поки вузол, що відмовив, не буде відновлений, після цього вихідне навантаження повертається на основний вузол для збереження вихідного рівня доступності системи.
• N-к-N — це поєднання active / active і N + M кластерів. У N-к-N кластері сервіси, екземпляри систем або об'єднання вузлів, що відмовили, перерозподіляються між іншими активними вузлами. Тим самим усувається (як в схемі active / active) необхідність окремого резервного вузла, але при цьому всі вузли кластера повинні володіти деякою надлишковою потужністю понад мінімально необхідною[3]. Терміни логічний хост або кластерний логічний хост використовуються для позначення мережевої адреси, яка використовується для доступу до сервісів, що надаються кластером. Ідентифікатор логічного хоста не прив'язаний до одного вузла кластера. Це насправді мережева адреса котра пов'язана з сервісом, що надана кластером. Якщо вузол кластера, наприклад, працює з базою даних виходить з ладу, базу даних буде перезапущено на іншому вузлі кластера, а мережева адреса, за якою користувачі отримують доступ до бази даних, збережеться для будь-якого нового вузла, причому користувачі матимуть доступ до бази даних.

HA-кластери, крім описаних схем міжвузлового резервування, використовують всі методи, які використовуються в окремих (некластерних) системах і в мережевій інфраструктурі для максимального підвищення надійності. До них належать:

• Резервування і реплікацію дисків: відмова частини внутрішніх дисків не призводить до збоїв системи. DRBD є одним із прикладів.
• Резервування зовнішніх мережевих з'єднань: пошкодження кабелю, відмова комутатора або мережевого інтерфейсу не призводять до повного відключення від мережі.
• Резервування внутрішніх з'єднань мережі зберігання даних (SAN): пошкодження кабелю, збій комутатора або мережевого інтерфейсу не приведуть до втрати з'єднання серверів зі сховищем.
• Надлишкові схеми електроживлення різного устаткування, як правило, захищені джерелами безперебійного живлення, і резервуються блоки живлення: відмова одиничного введення, UPS або БЖ не призводить до критичної відмови живлення системи.

Заходи щодо забезпечення безперебійної роботи окремого вузла, допомагають звести до мінімуму ймовірність звернення до механізмів або, власне, відмовостійкої кластеризації. У разі виконання останніх, доступ до сервісу може перериватися, хоча б і ненадовго, проте, доцільніше попереджати критичні відмови обладнання[2].

Системи, які обробляють помилки в розподілених комп'ютерних системах, використовують різні стратегії усунення наслідків при збоях. Наприклад, Apache Cassandra API Hector (API) передбачає три варіанти обробки помилок:

• Fail Fast, скрипт — «FAIL FAST», повідомляє клієнта про помилку, що виникла в недоступному вузлі.
• On Fail, Try One — Next Available, скрипт — «ON_FAIL_TRY_ONE_NEXT_AVAILABLE», означає, що система при збої вузла пробує перевести запит на інший вільний вузол і після першої невдалої спроби повідомляє про помилку.
• On Fail, Try All, скрипт — «ON_FAIL_TRY_ALL_AVAILABLE», означає, що система після першої невдалої спроби намагається всі наявні всі вузли і тільки потім повідомляє про помилку[1].

Для контролю працездатності вузлів в кластері зазвичай використовується передача безперервного періодичного сигналу («пульсу», англ. Heartbeat) у внутрішній мережі кластера від кожного з вузлів, за наявністю якого, керуюче ПЗ робить висновок про нормальну роботу сусідніх вузлів. З цим пов'язана неочевидна, але серйозна проблема «розділеного мозку» (англ. Split-brain_ (computing)) — в разі одночасного розриву безлічі з'єднань у внутрішній мережі кластера через збій живлення, несправності мережного обладнання і т. д., вузол, що не здатний коректно обробити інформацію, починає поводитися так, як ніби всі інші вузли кластера вийшли з ладу, запускаючи дублюючі вузли, у вже працюючому кластері, що може привести до пошкодження даних в загальному сховищі.

• Паралельні обчислення
• Grid-система
• Кластеризація

• Погорілий С. Технологія віртуалізації[1]. Динамічна реконфігурація ресурсів кластера[2] / С. Погорілий, І. Білоконь, Ю. Бойко // Математичні машини і системи. — 2012. — № 3. — С. 3 — 18. 5.
• Погорілий С. Д. До задачі оптимізації завантаженості ресурсів кластера з вузлами у вигляді віртуальних машин[3] / С. Д. Погорілий, І. В. Білоконь // Матеріали 8 міжнар. наук.- практ. конф. з програмування «УкрПРОГ–2012». Проблеми програмування, (Київ, 22–24 травня 2012 р.). — Київ, 2012. — № 2–3. — С. 93 — 101.
• Bilokon I. Research of Genetic Algorithm for searching optimal configurations of computing cluster with virtual machine nodes / I. Bilokon, S. Pogorilyy[4] // Theoretical and Applied Aspects of cybernetics. Proc. of the 2nd International Scientific Conference of students and Young Scientists[5]. — Kyiv: Bukrek, 2012. — Р. 13 — 18. 8.