Продуктивний відмовостійкий географічно рознесений кластер, який працює за схемою Active-Active на мейнфрейме IBM zEnterprise EC 12

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

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

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

Проблеми при побудові географічно рознесеного кластера, що працює за схемою Active-Active

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

Сучасні підходи до кластеризації СУБД зазвичай базуються на архітектурі shared disk. Основною задачею при такому підході є забезпечення синхронизируемого доступу до подільних даними. Деталі реалізації сильно залежать від конкретної СУБД, але найбільш популярним є підхід, заснований на обміні повідомленнями між вузлами кластера. Таке рішення є чисто програмним, прийом і відправлення повідомлень вимагає переривання роботи додатків (звернення до мережевого стека операційної системи), так само при активному доступі до подільних даними накладні витрати можу стати істотними, що особливо проявляється у разі збільшення відстані між активними вузлами. Як правило, коефіцієнт масштабованості таких рішень не перевищує ¾ (кластер з чотирьох вузлів, кожен з яких має продуктивність N, забезпечує сумарну продуктивність ¾ N).

У разі віддаленості один від одного вузлів кластера істотний вплив на продуктивність і допустимий час відновлення (RTO) рішення надає відстань. Як відомо, швидкість світла в оптиці становить приблизно 200 000 км/с, що відповідає затримці в 10 мкс на кожен кілометр оптоволокна.

Підхід, застосовуваний в мейнфреймах IBM

В мейнфреймах IBM для кластеризації СУБД DB2 і менеджерів черг WebSphere MQ застосовується інший підхід, не заснований на програмному обмін повідомленнями між вузлами кластера. Рішення називається Parallel Sysplex і дозволяє об'єднувати в кластер до 32 логічних розділів (LPAR), що працюють на одному або декількох мейнфреймах під управлінням операційної системи z/OS. Якщо врахувати, що новий мейнфрейм z13 може мати на борту понад 140 процесорів, то максимальна досяжна продуктивність кластера не може не вражати.

Основою Parallel Sysplex є технологія Coupling Facility, що представляє собою виділені логічні розділи (LPAR), що використовують процесори, які можуть виконувати спеціальне кластерний програмне забезпечення — Coupling Facility Control Code (CFCC). Coupling Facility у своїй пам'яті зберігає структури загальних даних, спільно використовувані вузлами кластера Parallel Sysplex. Обмін даними між CF та підключеними системами організується за принципом «пам'ять-пам'ять» (схоже на DMA), при цьому процесори, на яких працюють програми, не задіюються.

Для забезпечення високої доступності структур CF використовуються механізми синхронної і асинхронної реплікації даних між ними засобами операційної системи z/OS і СУБД DB2.

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

Навантажувальне тестування кластера

Для демонстрації масштабованості системи і оцінки впливу відстані на показники продуктивності ми провели ряд випробувань, за результатами яких хочемо з вами поділитися.

Як стенду для проведення випробувань використовувався один фізичний сервер zEnterprise EC 12. На даному сервері було розгорнуто два логічних розділи (LPAR) MVC1 і MVC2, кожен з яких працював під управлінням операційної системи z/OS 2.1 і містив по 5 процесорів загального призначення (CP) і 5 спеціалізованих процесорів zIIP, призначених для виконання коду СУБД DB2 і роботи Java-додатків. Дані логічні розділи були об'єднані в кластер з використанням механізму Parallel Sysplex.

Для роботи механізму Coupling Facility використовувалися виділені логічні розділи (LPAR) CF1 і CF2, що містять по 2 процесора ICF. Відстань між CF1 і CF2 по каналах зв'язку за сценарієм тестування дискретно змінювалося, перебуваючи в межах від 0 до 70 км.

Підключення MVC1 до CF1 здійснювалося за допомогою віртуальних каналів типу ICP, в той час як для доступу до CF2 використовувалися фізичні канали типу Infiniband. Підключення MVC2 до CF1 і CF2 здійснювалося аналогічно: за допомогою ICP каналів до CF2 і з допомогою Infiniband до CF1.

Для зберігання даних використовувався дисковий масив IBM DS 8870, в якому були створені два набору дисків і налаштована синхронна реплікацію даних між ними з допомогою технології Metro Mirror. Відстань між наборами дисків по каналах зв'язку за сценарієм тестування дискретно змінювалося, перебуваючи в межах від 0 до 70 км. Необхідну відстань між компонентами стенду забезпечувалося шляхом застосування спеціалізованих пристроїв DWDM (ADVA) і оптоволоконних кабелів необхідної довжини.

Кожен з логічних розділів MVC1 і MVC2 підключався до дискових масивів за допомогою двох каналів FICON, які мають пропускну здатність 8 GB/s.

Детальна схема стенда (у варіанті з відстанню між вузлами кластера 50 км.) представлена на малюнку.



В якості тестового додатку на вузлах кластера була розгорнута банківська платіжна система, що використовує для своєї роботи наступне програмне забезпечення IBM: СУБД DB2 z/OS, менеджери черг повідомлень WebSphere MQ, сервер додатків WebSphere Application Server for z/OS.

Роботи з налаштування тестового стенду і встановлення платіжної системи зайняли приблизно три тижні.

Окремо слід розповісти про принцип роботи додатки і профілі навантаження. Всі оброблювані платежі можна розділити на два типу: термінові і нетермінові. Термінові платежі проводяться відразу ж після їх зчитування з вхідної черги. У процесі ж обробки нетермінових платежів можна виділити три послідовні фази. Перша фаза — фаза прийому — платежі зчитуються з вхідної черги системи і реєструються в базі даних. Друга фаза — фаза багатостороннього взаємозаліку — запускається по таймеру кілька разів на добу і виконується строго в однопоточному режимі. На цій фазі здійснюється проводка всіх прийнятих до цього нетермінових платежів, при цьому враховуються взаємні зобов'язання учасників системи (якщо Петя переводить 500 рублів Васі і 300 рублів Світлі, а Вася — 300 рублів Світлі, то є сенс відразу збільшити значення рахунки Свєти на 600 рублів, а Васі — на 200 рублів, ніж виконувати реальні проводки). Третя фаза — фаза розсилки повідомлень — запускається автоматично після завершення другої фази. На цій фазі здійснюється формування та розсилка інформаційних повідомлень (квитанцій) для всіх що беруть участь у багатосторонній взаємозалік рахунків. Кожна фаза являє собою одну або декількох глобальних транзакцій, що представляють собою складну послідовність дій, виконуваних менеджерами черг WebSphere MQ і СУБД DB2. Кожна глобальна транзакція завершується двофазної фіксацією (commit), оскільки в ній беруть участь кілька ресурсів (чергу — база даних — черга).

Важливою особливістю платіжної системи є здатність проводити термінові платежі на тлі багатостороннього взаємозаліку.
Профіль навантаження при проведенні випробувань повторював профіль навантаження реально працюючої системи. На вхід подавалося 2 млн. нетермінових платежів, об'єднаних в пакети по 500/1000/5000 платежів, кожного пакету відповідало одне електронне повідомлення. Дані пакети подавалися на вхід системи з інтервалом 4 мс між надходженням кожного наступного повідомлення. Паралельно подавалося близько 16 тис. строкових платежів, кожному з яких відповідав свій електронне повідомлення. Дані електронні повідомлення подавалися з інтервалом 10 мс. між надходженням кожного наступного повідомлення.

Результати навантажувального тестування

При проведенні навантажувального тестування відстань по каналах зв'язку між наборами дисків, а також між логічними розділами CF дискретно змінювалося, перебуваючи в межах від 0 до 70 км. При виконанні тестів були зафіксовані наступні результати:



Цікаво порівняти два перші рядки, які показують масштабованість системи. Видно, що час виконання першої фази при використанні кластера з двох вузлів скорочується в 1.4 рази («нелінійність» масштабування першої фази пояснюється особливостями реалізації вимоги щодо дотримання порядку платежів від одного учасника), а час виконання третьої фази — практично в 2 рази. Багатосторонній взаємозалік виконується в один потік. Час його проведення в кластерному режимі збільшується через необхідність пересилання блокувань DB2 в CF при виконанні масових операцій DML.

При включенні механізму реплікації даних на дисках (Metro Mirror) час виконання кожної фази збільшується незначно, на 3 — 4%. При подальшому зростанні відстані по каналах зв'язку між дисками і між логічними розділами CF час виконання кожної фази зростає більш інтенсивно.

Цікаво порівняти часові характеристики обробки термінових платежів у крайніх випадках: без кластера і в кластері, вузли якого рознесені на відстань 70 км.



Максимальний час обробки платежу зросла на 40%, при цьому середня змінилося всього на 7.6%. При цьому утилізація процесорного ресурсу змінюється незначно за рахунок збільшення часу доступу до структур CF.

Висновки

У статті ми розглянули проблеми, що виникають при побудові географічно розподіленого кластера, що працює в режимі Active-Active, і з'ясували яким шляхом можна їх уникнути, побудувавши кластер на основі мейнфреймів IBM. Твердження про високу масштабованість рішень на основі кластеру Parallel Sysplex продемонстровані результатами навантажувального тестування. При цьому ми перевірили поведінку системи при різній відстані між вузлами кластера: 0, 20, 50 і 70 км.

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

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.