CAP-теорема є наріжним каменем теорії розподілених систем. Звичайно, суперечки навколо неї не вщухають: і визначення в ній не канонічні, і суворого доказу немає... Проте, твердо стоячи на позиціях здорового глузду™, ми інтуїтивно розуміємо, що теорема вірна.
Єдине, що не очевидно, це значення літери «P». Коли кластер розділився, він вирішує – чи не відповідати, поки не буде набраний кворум, чи віддавати ті дані, які є. Залежно від результатів цього вибору система класифікується як CP, або як AP. Cassandra, наприклад, може вести себе і так і так, залежно навіть не від налаштувань кластера, а від кожного конкретного запиту. Але якщо система не P, і вона розділилася, тоді - що?
Відповідь на це запитання дещо несподівана: CA-кластер не може розділитися.
Що ж це за кластер, який не може поділитися?
Неодмінний атрибут такого кластера – це загальна система зберігання даних. У переважній більшості випадків це означає підключення через SAN, що обмежує застосування CA-рішень великими підприємствами, здатними містити SAN-інфраструктуру. Для того, щоб кілька серверів могли працювати з тими самими даними, необхідна кластерна файлова система. Такі файлові системи є в портфелях HPE (CFS), Veritas (VxCFS) та IBM (GPFS).
Oracle RAC
Опція Real Application Cluster вперше з'явилася 2001 року у релізі Oracle 9i. У такому кластері кілька екземплярів сервера працюють з однією і тією ж базою даних.
Oracle може працювати як із кластерною файловою системою, так і з власним рішенням – ASM, Automatic Storage Management.
Кожен екземпляр веде свій журнал. Транзакція виконується та фіксується одним екземпляром. У разі збою екземпляра один з вузлів кластера (екземплярів), що вижили, зчитує його журнал і відновлюють втрачені дані – за рахунок цього забезпечується доступність.
Всі екземпляри підтримують власний кеш, і ті самі сторінки (блоки) можуть знаходитися одночасно в кешах декількох екземплярів. Більше того, якщо якась сторінка потрібна одному екземпляру, і вона є в кеші іншого екземпляра, він може отримати його у "сусіда" за допомогою механізму cache fusion замість того, щоб читати з диска.
Але що станеться, якщо одному з екземплярів потрібно змінити дані?
Особливість Oracle в тому, що у нього немає виділеного сервісу блокувань: якщо сервер хоче заблокувати рядок, то запис про блокування ставиться прямо на тій сторінці пам'яті, де знаходиться рядок, що блокується. Завдяки такому підходу Oracle – чемпіон із продуктивності серед монолітних баз: сервіс блокувань ніколи не стає вузьким місцем. Але в кластерній конфігурації така архітектура може призводити до інтенсивного мережного обміну та взаємних блокувань.
Як тільки запис блокується, екземпляр повідомляє всі інші екземпляри про те, що сторінка, в якій зберігається цей запис, захоплена в монопольному режимі. Якщо іншому примірнику потрібно змінити запис на тій самій сторінці, він повинен чекати, поки зміни на сторінці не будуть зафіксовані, тобто інформація про зміну не буде записана в журнал на диску (при цьому транзакція може тривати). Може статися і так, що сторінка буде змінена послідовно кількома екземплярами, і тоді при записі сторінки на диск доведеться з'ясовувати, у кого зберігається актуальна версія цієї сторінки.
Випадкове оновлення тих самих сторінок через різні вузли RAC призводить до різкого зниження продуктивності бази даних – аж до того, що продуктивність кластера може бути нижчою, ніж продуктивність єдиного екземпляра.
Правильне використання Oracle RAC – фізичний поділ даних (наприклад, за допомогою механізму секційованих таблиць) та звернення до кожного набору секцій через виділений вузол. Головним призначенням RAC стало не горизонтальне масштабування, а забезпечення стійкості до відмови.
Якщо вузол перестає відповідати на heartbeat, той вузол, який виявив це першим, запускає процедуру голосування на диску. Якщо і тут зниклий вузол не відзначився, то один із вузлів бере на себе обов'язки щодо відновлення даних:
- "заморожує" всі сторінки, які знаходилися в кеші зниклого вузла;
- зчитує журнали (redo) зниклого вузла і повторно застосовує зміни, записані в цих журналах, принагідно перевіряючи, чи немає в інших вузлів свіжіших версій змінюваних сторінок;
- відкочує незавершені транзакції.
Щоб спростити перемикання між вузлами, Oracle має поняття сервісу – віртуального екземпляра. Екземпляр може обслуговувати кілька сервісів, а сервіс може переїжджати між вузлами. Примірник програми, який обслуговує певну частину бази (наприклад, групу клієнтів) працює з одним сервісом, а сервіс, який відповідає за цю частину бази, при виході вузла з ладу переїжджає на інший вузол.
IBM Pure Data Systems for Transactions
Кластерне рішення для СУБД з'явилося у портфелі Блакитного Гіганта у 2009 році. Ідеологічно воно є спадкоємцем кластера Parallel Sysplex, побудованим на «звичайному» обладнанні. У 2009 році вийшов продукт DB2 pureScale, що є комплектом програмного забезпечення, а в 2012 році IBM пропонує програмно-апаратний комплект (appliance) під назвою Pure Data Systems for Transactions. Не слід плутати його з Pure Data Systems for Analytics, яка є не що інше, як перейменована Netezza.
Архітектура pureScale на перший погляд схожа на Oracle RAC: так само кілька вузлів підключені до загальної системи зберігання даних, і на кожному вузлі працює свій екземпляр СУБД зі своїми областями пам'яті та журналами транзакцій. Але, на відміну від Oracle, DB2 має виділений сервіс блокувань, представлений набором процесів db2LLM*. У кластерної конфігурації цей сервіс виноситься на окремий вузол, який у Parallel Sysplex називається coupling facility (CF), а Pure Data – PowerHA.
PowerHA надає такі послуги:
- менеджер блокувань;
- глобальний буферний кеш;
- область міжпроцесних комунікацій.
Для передачі даних від PowerHA до вузлів БД і назад використовується віддалений доступ до пам'яті, тому кластерний інтерконект повинен підтримувати протокол RDMA. PureScale може використовувати як Infiniband, і RDMA over Ethernet.
Якщо вузлу потрібна сторінка, і цієї сторінки немає в кеші, то вузол запитує сторінку в глобальному кеші, і тільки в тому випадку, якщо там її немає, читає її з диска. На відміну від Oracle, запит іде лише в PowerHA, а не в сусідні вузли.
Якщо екземпляр збирається змінювати рядок, він блокує його в ексклюзивному режимі, а сторінку, де знаходиться рядок, – в режимі, що розділяється. Усі блокування реєструються у глобальному менеджері блокувань. Коли транзакція завершується, вузол надсилає повідомлення менеджеру блокувань, який копіює змінену сторінку до глобального кешу, знімає блокування та інвалідує змінену сторінку в кешах інших вузлів.
Якщо сторінка, в якій знаходиться рядок, що змінюється, вже заблокована, то менеджер блокувань прочитає змінену сторінку з пам'яті вузла, який зробив зміни, зніме блокування, інвалідує змінену сторінку в кешах інших вузлів і віддасть блокування сторінки вузлу, який її запросив.
"Брудні", тобто змінені, сторінки можуть бути записані на диск як зі звичайного вузла, так і PowerHA (castout).
При відмові одного з вузлів pureScale відновлення обмежене лише тими транзакціями, які в момент збою ще не були завершені: сторінки, змінені цим вузлом у транзакціях, що завершилися, є в глобальному кеші на PowerHA. Вузол перезапускається у урізаній конфігурації на одному із серверів кластера, відкочує незавершені транзакції та звільняє блокування.
PowerHA працює на двох серверах, і основний вузол синхронно реплікує свій стан. У разі відмови основного вузла PowerHA кластер продовжує роботу з резервним вузлом.
Зрозуміло, якщо звертатися до набору даних через один вузол, загальна продуктивність кластера буде вищою. PureScale навіть може помітити, що деяка область даних обробляються одним вузлом, і тоді всі блокування, що належать до цієї області, будуть оброблятися вузлом локально без комунікацій з PowerHA. Але як тільки програма спробує звернутися до цих даних через інший вузол, централізована обробка блокувань буде відновлена.
Внутрішні тести IBM на навантаженні, що складається з 90% читання та 10% запису, що дуже схоже на реальне промислове навантаження, показують майже лінійне масштабування до 128 вузлів. Умови тестування, на жаль, не розкриваються.
HPE NonStop SQL
Своя високодоступна платформа є у портфелі Hewlett-Packard Enterprise. Це платформа NonStop, випущена ринку в 1976 році компанією Tandem Computers. У 1997 році компанія була поглинена компанією Compaq, яка, у свою чергу, в 2002 році влилася до Hewlett-Packard.
NonStop використовується для побудови критичних програм - наприклад, HLR або процесингу банківських карт. Платформа поставляється у вигляді програмно-апаратного комплексу (appliance), що включає обчислювальні вузли, систему зберігання даних і комунікаційне обладнання. Мережа ServerNet (у сучасних системах – Infiniband) служить як обміну між вузлами, так доступу до системи зберігання даних.
У ранніх версіях системи використовувалися пропрієтарні процесори, які були синхронізовані один з одним: усі операції виконувались синхронно кількома процесорами, і як тільки один із процесорів помилявся, він відключався, а другий продовжував роботу. Пізніше система перейшла на звичайні процесори (спочатку MIPS, потім Itanium і, нарешті, x86), а синхронізації стали використовуватися інші механізми:
- повідомлення: у кожного системного процесу є двійник-«тінь», якому активний процес періодично надсилає повідомлення про свій стан; при збої основного процесу тіньовий процес починає роботу з моменту, визначеного останнім повідомленням;
- голосування: система зберігання даних має спеціальний апаратний компонент, який приймає кілька однакових звернень і виконує їх тільки в тому випадку, якщо звернення збігаються; замість фізичної синхронізації процесори працюють асинхронно, а результати їхньої роботи порівнюються тільки в моменти введення/виводу.
Починаючи з 1987 року на платформі NonStop працює реляційна СУБД спочатку SQL/MP, а пізніше SQL/MX.
Вся база даних ділиться на частини, і кожну частину відповідає свій процес Data Access Manager (DAM). Він забезпечує запис даних, кеширування та механізм блокувань. Обробкою даних займаються процеси-виконавці (Executor Server Process), що працюють на тих же вузлах, що й відповідні менеджери даних. Планувальник SQL/MX ділить завдання між виконавцями та об'єднує результати. При необхідності внести узгоджені зміни використовується протокол двофазної фіксації, який забезпечує бібліотека TMF (Transaction Management Facility).
NonStop SQL може пріоритезувати процеси так, щоб довгі аналітичні запити не заважали виконанню транзакцій. Проте її призначення – саме обробка коротких транзакцій, а чи не аналітика. Розробник гарантує доступність кластера NonStop на рівні п'ять "дев'яток", тобто простий складає всього 5 хвилин на рік.
САП ХАНА
Перший стабільний реліз СУБД HANA (1.0) відбувся у листопаді 2010 року, а пакет SAP ERP перейшов на HANA з травня 2013 року. Платформа базується на куплених технологіях: TREX Search Engine (пошук у колонковому сховищі), СУБД P*TIME та MAX DB.
Саме слово "HANA" - акронім, High performance ANalytical Appliance. Поставляється ця СУБД у вигляді коду, який може працювати на будь-яких серверах x86, проте промислові інсталяції допускаються лише на обладнанні сертифікації. Є рішення HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Деякі конфігурації Lenovo допускають навіть експлуатацію без SAN – роль загальної СГД грає кластер GPFS на локальних дисках.
На відміну від перерахованих вище платформ, HANA - СУБД у пам'яті, тобто первинний образ даних зберігається в оперативній пам'яті, а на диск записуються тільки журнали та періодичні знімки - для відновлення у разі аварії.
Кожен вузол кластера HANA відповідає за свою частину даних, а картка даних зберігається у спеціальному компоненті - Name Server, розташованому на вузлі-координаторі. Дані між вузлами не дублюються. Інформація про блокування зберігається на кожному вузлі, але в системі є глобальний детектор взаємних блокувань.
Клієнт HANA при з'єднанні з кластером завантажує його топологію і надалі може звертатися безпосередньо до будь-якого вузла залежно від того, які дані йому потрібні. Якщо транзакція стосується даних єдиного вузла, то вона може бути виконана цим вузлом локально, але якщо змінюються дані декількох вузлів, то вузол-ініціатор звертається до вузла-координатора, який відкриває і координує розподілену транзакцію, фіксуючи її за допомогою оптимізованого протоколу двофазної фіксації.
Вузол-координатор дубльований, тому у разі виходу координатора з експлуатації в роботу негайно вступає резервний вузол. А от якщо виходить з ладу вузол із даними, то єдиний спосіб отримати доступ до його даних – перезапустити вузол. Як правило, у кластерах HANA тримають резервний (spare) сервер, щоб якнайшвидше перезапустити на ньому втрачений вузол.
Джерело: habr.com