CAP теоремасы бөлүштүрүлгөн системалар теориясынын негизи болуп саналат. Албетте, анын тегерегиндеги талаш-тартыштар басаңдабайт: андагы аныктамалар канондук эмес, катуу далилдер да жок... Ошого карабастан, күнүмдүк акыл-эстин позицияларында бекем туруп, теореманын туура экенин интуитивдик түрдө түшүнөбүз.
Бир гана нерсе "П" тамгасынын мааниси ачык эмес. Кластер бөлүнгөндө кворумга жеткенге чейин жооп бербөөнү же колдо болгон маалыматтарды кайтарып берүүнү чечет. Бул тандоонун натыйжаларына жараша система CP же AP болуп бөлүнөт. Кассандра, мисалы, кластердин жөндөөлөрүнө эмес, ар бир конкреттүү суроо-талаптын параметрлерине жараша өзүн эки жол менен аткара алат. Бирок система "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
DBMS үчүн кластердик чечим 2009-жылы Blue Giant портфелинде пайда болгон. Идеологиялык жактан ал “кадимки” жабдууларга курулган Parallel Sysplex кластеринин мураскери. 2009-жылы DB2 pureScale программалык камсыздоо топтому катары чыгарылган, ал эми 2012-жылы IBM транзакциялар үчүн Pure Data Systems деп аталган приборду сунуштаган. Аны Analytics үчүн таза маалымат тутумдары менен чаташтырбоо керек, бул Netezza аталышынан башка эч нерсе эмес.
Бир караганда, pureScale архитектурасы Oracle RACга окшош: ушундай эле жол менен бир нече түйүндөр жалпы маалымат сактоо тутумуна туташтырылып, ар бир түйүн өзүнүн эстутум аймактары жана транзакция журналдары менен өзүнүн DBMS инстанциясын иштетет. Бирок, Oracleдан айырмаланып, DB2 db2LLM* процесстеринин жыйындысы менен берилген атайын кулпулоо кызматына ээ. Кластер конфигурациясында бул кызмат өзүнчө түйүнгө жайгаштырылат, ал Параллель Sysplexте бириктирүү объекти (CF) жана таза маалыматтарда PowerHA деп аталат.
PowerHA төмөнкү кызматтарды көрсөтөт:
- кулпу менеджери;
- глобалдык буфер кэш;
- процесстер аралык байланыш чөйрөсү.
PowerHAдан берилиштерди база түйүндөрүнө жана кайра өткөрүү үчүн эстутумга алыскы кирүү колдонулат, андыктан кластер аралык байланыш RDMA протоколун колдоого алышы керек. PureScale Ethernet аркылуу Infiniband жана RDMA экөөнү тең колдоно алат.
Эгерде түйүнгө баракча керек болсо жана бул барак кэште болбосо, анда түйүн глобалдык кэштеги баракты сурайт жана ал жок болсо гана аны дисктен окуйт. Oracleдан айырмаланып, өтүнүч кошуна түйүндөргө эмес, PowerHAга гана барат.
Эгерде инстанция сапты өзгөртө турган болсо, аны эксклюзивдүү режимде, ал эми катар жайгашкан баракты жалпы режимде бекитет. Бардык кулпулар глобалдык кулпу менеджеринде катталган. Транзакция аяктагандан кийин түйүн кулпу менеджерине билдирүү жөнөтөт, ал өзгөртүлгөн баракты глобалдык кэшке көчүрөт, кулпуларды бошотот жана башка түйүндөрдүн кэштеринде өзгөртүлгөн баракты жараксыз кылат.
Эгерде өзгөртүлгөн сап жайгашкан барак мурунтан эле кулпуланган болсо, анда кулпу менеджери өзгөртүү киргизген түйүндүн эс тутумунан өзгөртүлгөн баракты окуйт, кулпуну бошотот, башка түйүндөрдүн кэштеринде өзгөртүлгөн баракты жараксыз деп эсептейт жана аны сураган түйүнгө беттин кулпусун бериңиз.
"Кир", башкача айтканда, өзгөртүлгөн барактар дискке кадимки түйүндөн да, PowerHAдан да (castout) жазылса болот.
Эгерде pureScale түйүндөрүнүн бири иштебей калса, калыбына келтирүү ката учурунда бүтө элек транзакциялар менен гана чектелет: аяктаган транзакциялардагы түйүн тарабынан өзгөртүлгөн барактар PowerHAдагы глобалдык кэште. Түйүн кластердеги серверлердин биринде кыскартылган конфигурацияда кайра ишке кирет, күтүлүп жаткан транзакцияларды артка жылдырат жана кулпуларды чыгарат.
PowerHA эки серверде иштейт жана башкы түйүн өзүнүн абалын синхрондуу түрдө кайталайт. Эгерде негизги PowerHA түйүнү иштебей калса, кластер камдык түйүн менен иштөөнү улантат.
Албетте, бир түйүн аркылуу берилиштер топтомун жетүү болсо, кластердин жалпы өндүрүмдүүлүгү жогору болот. PureScale ал тургай, белгилүү бир маалымат аймагы бир түйүн тарабынан иштетилип жатканын байкай алат, андан кийин ал аймакка тиешелүү бардык кулпулар PowerHA менен байланышпастан түйүн тарабынан жергиликтүү иштетилет. Бирок тиркеме башка түйүн аркылуу бул маалыматка кирүүгө аракет кылса, борборлоштурулган кулпу иштетүү кайра башталат.
IBMдин 90% окуу жана 10% жазуу жүгү боюнча ички тесттери, бул реалдуу өндүрүштүк жүктөмгө абдан окшош, 128 түйүнгө чейин дээрлик сызыктуу масштабды көрсөтөт. Сынактын шарттары, тилекке каршы, ачыкталган эмес.
HPE NonStop SQL
Hewlett-Packard Enterprise портфолиосу да өзүнүн жогорку жеткиликтүү платформасына ээ. Бул Tandem Computers тарабынан 1976-жылы рынокко чыгарылган NonStop платформасы. 1997-жылы компанияны Compaq сатып алган, ал өз кезегинде 2002-жылы Hewlett-Packard менен бириккен.
NonStop маанилүү тиркемелерди түзүү үчүн колдонулат - мисалы, HLR же банк картасын иштетүү. Платформа эсептөө түйүндөрүн, маалыматтарды сактоо тутумун жана байланыш жабдууларын камтыган программалык-аппараттык комплекс (прибор) түрүндө жеткирилет. ServerNet тармагы (заманбап системаларда - Infiniband) түйүндөрдүн ортосундагы алмашуу үчүн да, маалыматтарды сактоо тутумуна кирүү үчүн да кызмат кылат.
Системанын алгачкы версияларында бири-бири менен синхрондоштурулган проприетардык процессорлор колдонулган: бардык операциялар синхрондуу түрдө бир нече процессорлор тарабынан аткарылып, процессорлордун бири ката кетирээри менен ал өчүрүлүп, экинчиси иштей берген. Кийинчерээк система кадимки процессорлорго (биринчи MIPS, андан кийин Itanium жана акырында x86) өткөн жана башка механизмдер синхрондоштуруу үчүн колдонула баштаган:
- билдирүүлөр: ар бир система процессинин “көмүскө” эгизи бар, ага активдүү процесс мезгил-мезгили менен анын абалы жөнүндө билдирүүлөрдү жөнөтөт; негизги процесс ишке ашпай калса, көмүскө процесс акыркы билдирүү менен аныкталган учурдан тартып иштей баштайт;
- добуш берүү: сактоо тутумунда бир нече окшош кирүүлөрдү кабыл алган жана мүмкүнчүлүктөр дал келген учурда гана аларды ишке ашырган атайын аппараттык компоненти бар; Физикалык синхрондоштуруунун ордуна процессорлор асинхрондуу иштешет жана алардын ишинин натыйжалары киргизүү/чыгаруу моментинде гана салыштырылат.
1987-жылдан бери реляциялык DBMS NonStop платформасында иштеп келет - биринчи SQL/MP, кийинчерээк SQL/MX.
Бүткүл маалымат базасы бөлүктөргө бөлүнгөн жана ар бир бөлүк өзүнүн Data Access Manager (DAM) процесси үчүн жооптуу. Ал маалыматтарды жаздыруу, кэштөө жана бөгөттөө механизмдерин камсыз кылат. Маалыматтарды иштетүү тиешелүү маалымат менеджерлери менен бир эле түйүндөрдө иштеген Аткаруучу сервер процесстери тарабынан ишке ашырылат. SQL/MX пландоочу тапшырмаларды аткаруучулар арасында бөлүштүрөт жана натыйжаларды бириктирет. Макулдашылган өзгөртүүлөрдү киргизүү зарыл болгондо, TMF (Транзакцияларды башкаруу механизми) китепканасы тарабынан берилген эки фазалуу милдеттенмелердин протоколу колдонулат.
NonStop SQL узак аналитикалык сурамдар транзакциянын аткарылышына тоскоол болбошу үчүн процесстерге артыкчылык бере алат. Бирок, анын максаты так кыска бүтүмдөрдү кайра иштетүү эмес, аналитика болуп саналат. Иштеп чыгуучу беш “тогуздук” деңгээлинде NonStop кластеринин болушуна кепилдик берет, башкача айтканда, токтоп калуу жылына болгону 5 мүнөт.
SAP-HANA
HANA DBMS (1.0) биринчи туруктуу релиз 2010-жылдын ноябрында болуп өттү, ал эми SAP ERP пакети HANA 2013-жылдын май айында которулган. Платформа сатып алынган технологияларга негизделген: TREX Search Engine (мамычалуу сактагычтан издөө), P*TIME DBMS жана MAX DB.
"HANA" деген сөздүн өзү аббревиатура, Жогорку натыйжалуу ANAlytic Appliance. Бул DBMS ар кандай x86 серверлеринде иштей турган код түрүндө берилет, бирок өнөр жайлык орнотууларга сертификатталган жабдууларда гана уруксат берилет. Чечимдер HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Кээ бир Lenovo конфигурациялары SAN жок иштөөгө мүмкүндүк берет - жалпы сактоо тутумунун ролун жергиликтүү дисктердеги GPFS кластери ойнойт.
Жогоруда саналып өткөн платформалардан айырмаланып, HANA - эс тутумдагы DBMS, башкача айтканда, негизги маалымат сүрөтү RAMда сакталат жана кырсык болгон учурда калыбына келтирүү үчүн дискке журналдар жана мезгилдүү сүрөттөр гана жазылат.
Ар бир HANA кластер түйүнү маалыматтардын өзүнүн бөлүгү үчүн жооптуу жана маалымат картасы атайын компонентте сакталат - координатор түйүндө жайгашкан Name Server. Маалыматтар түйүндөрдүн ортосунда кайталанбайт. Бөгөттөө маалыматы да ар бир түйүндө сакталат, бирок системада глобалдык туюк детектор бар.
HANA кардары кластерге туташканда, ал өзүнүн топологиясын жүктөп алып, андан соң каалаган түйүнгө түздөн-түз кире алат. Эгерде транзакция бир түйүндүн маалыматтарына таасир этсе, анда ал ошол түйүн тарабынан локалдык түрдө аткарылышы мүмкүн, бирок бир нече түйүндөрдүн маалыматтары өзгөрсө, демилгечи түйүн координатор түйүнү менен байланышат, ал бөлүштүрүлгөн транзакцияны ачат жана координациялайт, аны оптималдаштырылган эки фазалуу тапшырма протоколу.
Координатор түйүнү кайталанат, андыктан координатор иштебей калса, резервдик түйүн дароо ээлейт. Бирок маалыматтары бар түйүн иштебей калса, анда анын маалыматтарына жетүүнүн бирден-бир жолу бул түйүндү кайра иштетүү. Эреже катары, HANA кластерлери жоголгон түйүндү мүмкүн болушунча тезирээк кайра иштетүү үчүн запастык серверди колдошот.
Source: www.habr.com
