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