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.
Всяко копие води свой собствен дневник. Транзакцията се изпълнява и извършва от една инстанция. Ако даден екземпляр се провали, един от оцелелите клъстерни възли (екземпляри) чете своя журнал и възстановява изгубените данни - като по този начин гарантира наличност.
Всички екземпляри поддържат свой собствен кеш и едни и същи страници (блокове) могат да бъдат в кешовете на множество екземпляри едновременно. Освен това, ако един екземпляр се нуждае от страница и тя е в кеша на друг екземпляр, той може да я получи от своя съсед, използвайки механизма за сливане на кеша, вместо да чете от диск.
Но какво се случва, ако един от екземплярите трябва да промени данните?
Особеността на Oracle е, че той няма специална услуга за заключване: ако сървърът иска да заключи ред, тогава записът за заключване се поставя директно на страницата с памет, където се намира заключеният ред. Благодарение на този подход Oracle е шампионът по производителност сред монолитните бази данни: услугата за заключване никога не се превръща в пречка. Но в клъстерна конфигурация такава архитектура може да доведе до интензивен мрежов трафик и блокирания.
След като даден запис бъде заключен, екземплярът уведомява всички други екземпляри, че страницата, която съхранява този запис, има изключително задържане. Ако друг екземпляр трябва да промени запис на същата страница, той трябва да изчака, докато промените в страницата бъдат приети, т.е. информацията за промяната се записва в дневник на диск (и транзакцията може да продължи). Възможно е също така една страница да бъде променена последователно от няколко копия и след това, когато записвате страницата на диск, ще трябва да разберете кой съхранява текущата версия на тази страница.
Случайното актуализиране на едни и същи страници в различни RAC възли води до драстичен спад на производителността на базата данни до точката, в която производителността на клъстера може да бъде по-ниска от тази на един екземпляр.
Правилното използване на Oracle RAC е физическо разделяне на данните (например чрез използване на механизъм на разделена таблица) и достъп до всеки набор от дялове чрез специален възел. Основната цел на RAC не беше хоризонтално мащабиране, а осигуряване на устойчивост на грешки.
Ако възел спре да отговаря на сърдечен ритъм, тогава възелът, който го е открил, първо започва процедура за гласуване на диска. Ако липсващият възел не е отбелязан тук, тогава един от възлите поема отговорността за възстановяване на данни:
- „замразява“ всички страници, които са били в кеша на липсващия възел;
- чете регистрационните файлове (повторно) на липсващия възел и прилага отново промените, записани в тези регистрационни файлове, като едновременно с това проверява дали други възли имат по-нови версии на страниците, които се променят;
- връща чакащи транзакции.
За да опрости превключването между възлите, Oracle има концепцията за услуга - виртуален екземпляр. Екземплярът може да обслужва множество услуги и услугата може да се движи между възли. Екземпляр на приложение, обслужващ определена част от базата данни (например група клиенти), работи с една услуга, а услугата, отговорна за тази част от базата данни, се премества в друг възел, когато възел се повреди.
IBM Pure Data Systems за транзакции
Клъстерно решение за СУБД се появи в портфолиото на Blue Giant през 2009 г. Идеологически той е наследник на клъстера Parallel Sysplex, изграден на „обикновено“ оборудване. През 2009 г. DB2 pureScale беше пуснат като софтуерен пакет, а през 2012 г. IBM предложи устройство, наречено Pure Data Systems for Transactions. Не трябва да се бърка с Pure Data Systems for Analytics, което не е нищо повече от преименувана Netezza.
На пръв поглед архитектурата на pureScale е подобна на Oracle RAC: по същия начин няколко възела са свързани към обща система за съхранение на данни и всеки възел изпълнява свой собствен екземпляр на СУБД със собствени области на паметта и журнали на транзакции. Но за разлика от Oracle, DB2 има специална услуга за заключване, представена от набор от db2LLM* процеси. В клъстерна конфигурация тази услуга се поставя на отделен възел, който се нарича средство за свързване (CF) в Parallel Sysplex и PowerHA в Pure Data.
PowerHA предоставя следните услуги:
- мениджър на заключване;
- глобален буферен кеш;
- област на междупроцесните комуникации.
За прехвърляне на данни от PowerHA към възлите на базата данни и обратно се използва отдалечен достъп до паметта, така че свързването на клъстера трябва да поддържа протокола RDMA. PureScale може да използва както Infiniband, така и RDMA през 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, която от своя страна се слива с Hewlett-Packard през 2002 г.
NonStop се използва за изграждане на критични приложения - например HLR или обработка на банкови карти. Платформата се доставя под формата на софтуерно-хардуерен комплекс (устройство), който включва изчислителни възли, система за съхранение на данни и комуникационно оборудване. Мрежата ServerNet (в съвременните системи - Infiniband) служи както за обмен между възли, така и за достъп до системата за съхранение на данни.
Ранните версии на системата използват собствени процесори, които са синхронизирани помежду си: всички операции се извършват синхронно от няколко процесора и веднага щом един от процесорите направи грешка, той се изключва, а вторият продължава да работи. По-късно системата премина към конвенционални процесори (първо MIPS, след това Itanium и накрая x86) и започнаха да се използват други механизми за синхронизация:
- съобщения: всеки системен процес има „сенчест“ близнак, на който активният процес периодично изпраща съобщения за състоянието си; ако основният процес се провали, процесът в сянка започва да работи от момента, определен от последното съобщение;
- гласуване: системата за съхранение има специален хардуерен компонент, който приема множество идентични достъпи и ги изпълнява само ако достъпите съвпадат; Вместо физическа синхронизация, процесорите работят асинхронно и резултатите от тяхната работа се сравняват само в I/O моменти.
От 1987 г. на платформата NonStop работи релационна СУБД - първо SQL/MP, а по-късно SQL/MX.
Цялата база данни е разделена на части и всяка част е отговорна за своя собствен процес на Data Access Manager (DAM). Той осигурява запис на данни, кеширане и механизми за заключване. Обработката на данни се извършва от процеси на изпълнителен сървър, работещи на същите възли като съответните мениджъри на данни. SQL/MX планировчикът разделя задачите между изпълнителите и обобщава резултатите. Когато е необходимо да се направят съгласувани промени, се използва двуфазовият протокол за ангажиране, предоставен от библиотеката TMF (Transaction Management Facility).
NonStop SQL може да приоритизира процесите, така че дългите аналитични заявки да не пречат на изпълнението на транзакция. Неговата цел обаче е именно обработка на къси транзакции, а не анализи. Разработчикът гарантира наличността на клъстера NonStop на ниво пет „деветки“, тоест престоят е само 5 минути годишно.
САП-ХАНА
Първата стабилна версия на HANA DBMS (1.0) се състоя през ноември 2010 г., а SAP ERP пакетът премина към HANA през май 2013 г. Платформата е базирана на закупени технологии: TREX Search Engine (търсене в колонно съхранение), P*TIME DBMS и MAX DB.
Самата дума „HANA“ е акроним, High performance ANlytical Appliance. Тази СУБД се доставя под формата на код, който може да работи на всеки x86 сървър, но индустриалните инсталации са разрешени само на сертифицирано оборудване. Предлагани решения от HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Някои конфигурации на Lenovo дори позволяват работа без SAN - ролята на обща система за съхранение се играе от GPFS клъстер на локални дискове.
За разлика от изброените по-горе платформи, HANA е СУБД в паметта, т.е. изображението на първичните данни се съхранява в RAM и само регистрационни файлове и периодични моментни снимки се записват на диска за възстановяване в случай на бедствие.
Всеки HANA клъстерен възел отговаря за собствената си част от данните, а картата на данните се съхранява в специален компонент – Name Server, разположен на координиращия възел. Данните не се дублират между възлите. Информацията за заключване също се съхранява на всеки възел, но системата има глобален детектор за блокиране.
Когато HANA клиент се свърже към клъстер, той изтегля неговата топология и след това може да има директен достъп до всеки възел, в зависимост от това какви данни са му необходими. Ако дадена транзакция засяга данните на единичен възел, тогава тя може да бъде изпълнена локално от този възел, но ако данните на няколко възела се променят, иницииращият възел се свързва с координиращия възел, който отваря и координира разпределената транзакция, като я ангажира с помощта на оптимизиран двуфазов протокол за ангажиране.
Координаторният възел е дублиран, така че ако координаторът се провали, резервният възел веднага поема. Но ако възел с данни се провали, тогава единственият начин за достъп до неговите данни е да рестартирате възела. Като правило, HANA клъстерите поддържат резервен сървър, за да рестартират загубен възел на него възможно най-бързо.
Източник: www.habr.com