Теоремата CAP е камен-темелник на теоријата на дистрибуирани системи. Се разбира, контроверзноста околу него не стивнува: дефинициите во него не се канонски и нема строг доказ... Сепак, цврсто стоиме на позициите на секојдневниот здрав разум™, интуитивно разбираме дека теоремата е вистинита.
Единственото нешто што не е очигледно е значењето на буквата „П“. Кога кластерот е поделен, тој одлучува дали да не одговори додека не се постигне кворум или да ги врати податоците што се достапни. Во зависност од резултатите од овој избор, системот е класифициран како CP или како AP. Касандра, на пример, може да се однесува на кој било начин, во зависност дури и од поставките на кластерот, туку од параметрите на секое конкретно барање. Но, ако системот не е „П“ и тој се подели, тогаш што?
Одговорот на ова прашање е малку неочекуван: кластерот 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 for Transactions
Кластерско решение за DBMS се појави во портфолиото Blue Giant во 2009 година. Идеолошки, тој е наследник на кластерот Parallel Sysplex, изграден на „обична“ опрема. Во 2009 година беше објавен DB2 pureScale, софтверски пакет, а во 2012 година, IBM понуди уред наречен Pure Data Systems for Transactions. Не треба да се меша со Pure Data Systems for Analytics, што не е ништо повеќе од преименувана Netezza.
На прв поглед, архитектурата pureScale е слична на Oracle RAC: на ист начин, неколку јазли се поврзани со заеднички систем за складирање податоци, и секој јазол води своја сопствена DBMS пример со свои мемориски области и дневници на трансакции. Но, за разлика од Oracle, DB2 има посветена услуга за заклучување претставена со множество db2LLM* процеси. Во кластерската конфигурација, оваа услуга е поставена на посебен јазол, кој се нарекува спојување (CF) во Parallel Sysplex и PowerHA во Pure Data.
PowerHA ги обезбедува следниве услуги:
- менаџер за заклучување;
- глобален бафер кеш;
- област на меѓупроцесни комуникации.
За пренос на податоци од PowerHA до јазлите на базата на податоци и назад, се користи далечински пристап до меморијата, така што интерконекцијата на кластерот мора да го поддржува протоколот RDMA. PureScale може да користи и Infiniband и RDMA преку етернет.
Ако на јазолот му е потребна страница, а оваа страница не е во кешот, тогаш јазолот ја бара страницата во глобалниот кеш, и само ако не е таму, ја чита од дискот. За разлика од 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), а други механизми почнаа да се користат за синхронизација:
- пораки: секој системски процес има близнак „сенка“, на кој активниот процес периодично испраќа пораки за неговиот статус; ако главниот процес не успее, процесот во сенка започнува да работи од моментот определен со последната порака;
- гласање: системот за складирање има специјална хардверска компонента која прифаќа повеќе идентични пристапи и ги извршува само ако пристапите се совпаѓаат; Наместо физичка синхронизација, процесорите работат асинхроно, а резултатите од нивната работа се споредуваат само во моментите на влез/излез.
Од 1987 година, на платформата NonStop работи релациона DBMS - прво SQL/MP, а подоцна и SQL/MX.
Целата база на податоци е поделена на делови и секој дел е одговорен за сопствениот процес на Менаџер за пристап до податоци (DAM). Обезбедува механизми за снимање, кеширање и заклучување податоци. Обработката на податоците се врши од страна на Executor Server Processes кои работат на истите јазли како и соодветните менаџери на податоци. Распоредувачот SQL/MX ги дели задачите меѓу извршители и ги собира резултатите. Кога е неопходно да се направат договорени промени, се користи двофазниот протокол за извршување обезбеден од библиотеката TMF (Transaction Management Facility).
NonStop SQL може да даде приоритет на процесите, така што долгите аналитички барања не се мешаат во извршувањето на трансакцијата. Сепак, неговата цел е токму обработка на кратки трансакции, а не аналитика. Инвеститорот гарантира достапност на кластерот NonStop на ниво од пет „деветки“, односно времето на застој е само 5 минути годишно.
САП ХАНА
Првото стабилно издание на HANA DBMS (1.0) се случи во ноември 2010 година, а пакетот SAP ERP се префрли на HANA во мај 2013 година. Платформата се базира на купените технологии: TREX пребарувач (пребарување во продавница за колони), P*TIME DBMS и MAX DB.
Самиот збор „ХАНА“ е акроним, аналитички апарат со високи перформанси. Овој DBMS е испорачан во форма на код што може да работи на кој било x86 сервер, меѓутоа, индустриските инсталации се дозволени само на сертифицирана опрема. Решенија достапни од HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Некои конфигурации на Lenovo дури дозволуваат работа без SAN - улогата на заеднички систем за складирање ја игра кластерот GPFS на локалните дискови.
За разлика од платформите наведени погоре, HANA е DBMS во меморијата, т.е. сликата на примарните податоци е зачувана во RAM меморијата, а само дневниците и периодичните снимки се запишуваат на дискот за обновување во случај на катастрофа.
Секој јазол на кластерот HANA е одговорен за сопствениот дел од податоците, а мапата на податоци се чува во посебна компонента - Сервер за имиња, која се наоѓа на координаторскиот јазол. Податоците не се дуплираат помеѓу јазлите. Информациите за заклучување исто така се складирани на секој јазол, но системот има глобален детектор за ќор-сокак.
Кога клиентот HANA се поврзува со кластер, тој ја презема неговата топологија и потоа може директно да пристапи до кој било јазол, во зависност од тоа какви податоци му се потребни. Ако трансакцијата влијае на податоците на еден јазол, тогаш таа може да се изврши локално од тој јазол, но ако податоците на неколку јазли се променат, иницирачкиот јазол контактира со координаторскиот јазол, кој ја отвора и ја координира дистрибуираната трансакција, извршувајќи ја со помош на оптимизиран двофазен протокол за извршување.
Координаторскиот јазол е дупликат, па ако координаторот не успее, резервниот јазол веднаш го презема. Но, ако некој јазол со податоци не успее, тогаш единствениот начин за пристап до неговите податоци е да го рестартирате јазолот. Како по правило, кластерите HANA одржуваат резервен сервер со цел да се рестартира изгубениот јазол на него што е можно побрзо.
Извор: www.habr.com