CAP теорем нь тархсан системийн онолын тулгын чулуу юм. Мэдээжийн хэрэг, түүнийг тойрсон маргаан тасрахгүй: үүн доторх тодорхойлолтууд нь каноник биш, хатуу нотолгоо байхгүй ... Гэсэн хэдий ч бид өдөр тутмын нийтлэг ойлголтын байр суурь дээр тууштай зогсож, энэ теорем үнэн гэдгийг зөн совингоор ойлгож байна.
Зөвхөн тодорхойгүй байгаа зүйл бол "P" үсгийн утга юм. Кластер хуваагдах үед чуулгад хүрэх хүртэл хариу өгөхгүй байх, эсвэл байгаа өгөгдлийг буцааж өгөх эсэхийг шийддэг. Энэ сонголтын үр дүнгээс хамааран системийг CP эсвэл AP гэж ангилдаг. Жишээлбэл, Кассандра нь кластерийн тохиргооноос биш, харин тодорхой хүсэлт бүрийн параметрүүдээс хамааран аль ч аргаар ажиллах боломжтой. Гэхдээ систем нь "P" биш бөгөөд энэ нь хуваагддаг бол яах вэ?
Энэ асуултын хариулт нь зарим талаараа гэнэтийн байна: CA кластер хуваагдаж чадахгүй.
Энэ ямар бөөгнөрөл болж хуваагдаж чадахгүй вэ?
Ийм кластерын зайлшгүй шинж чанар бол хуваалцсан өгөгдөл хадгалах систем юм. Ихэнх тохиолдолд энэ нь SAN-аар холбогдоно гэсэн үг бөгөөд энэ нь SAN-ийн дэд бүтцийг хадгалах чадвартай томоохон аж ахуйн нэгжүүдэд CA шийдлүүдийн хэрэглээг хязгаарладаг. Олон серверүүд ижил өгөгдөлтэй ажиллахын тулд кластер файлын систем шаардлагатай. Ийм файлын системүүд нь HPE (CFS), Veritas (VxCFS) болон IBM (GPFS) багцуудад байдаг.
Oracle RAC
Real Application Cluster сонголт нь анх 2001 онд Oracle 9i-г гаргаснаар гарч ирсэн. Ийм кластерт хэд хэдэн серверийн жишээнүүд ижил мэдээллийн сантай ажилладаг.
Oracle нь кластер файлын систем болон өөрийн шийдэл болох ASM, Автомат Хадгалалтын Удирдлагатай ажиллах боломжтой.
Хуулбар бүр өөрийн өдрийн тэмдэглэл хөтөлдөг. Гүйлгээг нэг инстанц хийж гүйцэтгэнэ. Хэрэв инстанц амжилтгүй болвол амьд үлдсэн кластерийн зангилаа (инстанс) нь бүртгэлээ уншиж, алдагдсан өгөгдлийг сэргээж, ингэснээр бэлэн байдлыг баталгаажуулна.
Бүх тохиолдлууд өөрсдийн кэшийг хадгалдаг бөгөөд ижил хуудаснууд (блокууд) олон тохиолдлын кэшэд нэгэн зэрэг байж болно. Түүнээс гадна, хэрэв нэг инстанцад хуудас хэрэгтэй бөгөөд энэ нь өөр инстанцийн кэшэд байгаа бол дискнээс уншихын оронд кэш нэгтгэх механизмыг ашиглан хөршөөсөө авах боломжтой.
Гэхдээ тохиолдлын аль нэг нь өгөгдлийг өөрчлөх шаардлагатай бол яах вэ?
Oracle-ийн онцлог нь түүнд зориулалтын түгжих үйлчилгээ байхгүй: хэрвээ сервер мөрийг түгжихийг хүсвэл түгжээний бичлэгийг түгжигдсэн мөр байрлах санах ойн хуудсан дээр шууд байрлуулна. Энэхүү аргын ачаар Oracle нь цул мэдээллийн сангуудын дунд гүйцэтгэлийн аварга болж байна: түгжих үйлчилгээ нь хэзээ ч гацаа болдоггүй. Гэхдээ кластерийн тохиргоонд ийм архитектур нь сүлжээний ачаалал ихтэй, түгжрэлд хүргэдэг.
Бичлэг түгжигдсэний дараа тухайн бичлэгийг хадгалж буй хуудас онцгой хамгаалалттай болохыг бусад бүх тохиолдлуудад мэдээлнэ. Хэрэв өөр нэг тохиолдол нэг хуудсан дээрх бичлэгийг өөрчлөх шаардлагатай бол энэ нь хуудасны өөрчлөлтийг хийх хүртэл хүлээх ёстой, өөрөөр хэлбэл өөрчлөлтийн мэдээллийг диск дээрх журналд бичих (мөн гүйлгээ үргэлжлэх боломжтой). Хуудсыг хэд хэдэн хуулбараар дараалан өөрчлөх тохиолдол гарч магадгүй бөгөөд дараа нь хуудсыг диск рүү бичихдээ энэ хуудасны одоогийн хувилбарыг хэн хадгалж байгааг олж мэдэх шаардлагатай болно.
Өөр өөр RAC зангилаанууд дээр ижил хуудсыг санамсаргүйгээр шинэчлэх нь өгөгдлийн сангийн гүйцэтгэлийг огцом бууруулж, кластерын гүйцэтгэлийг нэг жишээнийхээс доогуур түвшинд хүргэдэг.
Oracle RAC-ийн зөв хэрэглээ нь өгөгдлийг физик байдлаар хуваах (жишээ нь хуваасан хүснэгтийн механизмыг ашиглах) ба хуваалтын багц бүрийг тусгай зангилаагаар дамжуулан хандах явдал юм. RAC-ийн гол зорилго нь хэвтээ масштаб биш, харин алдааг тэсвэрлэх чадварыг хангах явдал байв.
Хэрэв зангилаа зүрхний цохилтонд хариу өгөхөө больсон бол түүнийг илрүүлсэн зангилаа эхлээд дискэн дээр санал өгөх процедурыг эхлүүлнэ. Хэрэв дутуу зангилаа энд тэмдэглэгдээгүй бол зангилааны аль нэг нь өгөгдлийг сэргээх үүрэгтэй.
- Алга болсон зангилааны кэш дэх бүх хуудсыг "царцаах";
- алга болсон зангилааны бүртгэлийг (дахин хийх) уншиж, эдгээр бүртгэлд бүртгэгдсэн өөрчлөлтийг дахин хэрэглэх ба бусад зангилаанууд өөрчлөгдөж буй хуудасны сүүлийн үеийн хувилбарууд байгаа эсэхийг нэгэн зэрэг шалгах;
- хүлээгдэж буй гүйлгээг буцаана.
Зангилаа хооронд шилжих ажлыг хялбарчлахын тулд Oracle нь үйлчилгээний тухай ойлголттой байдаг - виртуал жишээ. Нэг жишээ нь олон үйлчилгээнд үйлчлэх боломжтой бөгөөд үйлчилгээ нь зангилаа хооронд шилжих боломжтой. Өгөгдлийн сангийн тодорхой хэсэгт үйлчилдэг програмын жишээ (жишээ нь, үйлчлүүлэгчдийн бүлэг) нэг үйлчилгээтэй ажилладаг бөгөөд мэдээллийн сангийн энэ хэсгийг хариуцдаг үйлчилгээ нь зангилаа бүтэлгүйтсэн үед өөр зангилаа руу шилждэг.
Гүйлгээнд зориулсан IBM Pure Data Systems
DBMS-д зориулсан кластер шийдэл нь 2009 онд Blue Giant багцад гарч ирэв. Үзэл суртлын хувьд энэ нь "ердийн" төхөөрөмж дээр баригдсан Parallel Sysplex кластерийн залгамжлагч юм. 2009 онд DB2 pureScale программ хангамжийн иж бүрдэл хэлбэрээр гарсан бөгөөд 2012 онд IBM нь гүйлгээний цэвэр мэдээллийн систем гэж нэрлэгддэг төхөөрөмжийг санал болгосон. Үүнийг Analytics-д зориулсан цэвэр мэдээллийн системтэй андуурч болохгүй бөгөөд энэ нь өөрчилсөн Netezza-аас өөр зүйл биш юм.
Эхлээд харахад pureScale архитектур нь Oracle RAC-тай төстэй: ижил аргаар хэд хэдэн зангилаа нь нийтлэг өгөгдөл хадгалах системд холбогдсон бөгөөд зангилаа бүр өөрийн санах ойн талбарууд болон гүйлгээний бүртгэлүүдтэй өөрийн DBMS instance-ийг ажиллуулдаг. Гэхдээ Oracle-аас ялгаатай нь DB2 нь db2LLM* процессуудын багцаар илэрхийлэгдсэн тусгай түгжих үйлчилгээтэй. Кластерийн тохиргоонд энэ үйлчилгээг Parallel Sysplex-д coupling facility (CF), Pure Data-д 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 багц нь өөрийн гэсэн өндөр боломжтой платформтой. Энэ бол 1976 онд Tandem Computers компаниас зах зээлд гаргасан 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 оны 2013-р сард гарсан бөгөөд SAP ERP багц нь XNUMX оны XNUMX-р сард HANA руу шилжсэн. Энэхүү платформ нь худалдан авсан технологи дээр суурилдаг: TREX хайлтын систем (багануур сангаас хайх), P*TIME DBMS болон MAX DB.
"HANA" гэдэг үг нь өөрөө өндөр гүйцэтгэлтэй аналитик хэрэгсэл гэсэн товчлол юм. Энэхүү DBMS нь ямар ч x86 сервер дээр ажиллах боломжтой код хэлбэрээр нийлүүлэгдсэн боловч үйлдвэрлэлийн суурилуулалтыг зөвхөн баталгаажсан төхөөрөмж дээр зөвшөөрдөг. Шийдэлүүдийг HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC-ээс авах боломжтой. Зарим Lenovo тохиргоонууд нь SAN-гүйгээр ажиллахыг зөвшөөрдөг - нийтлэг санах ойн системийн үүргийг локал диск дээрх GPFS кластер гүйцэтгэдэг.
Дээр дурдсан платформуудаас ялгаатай нь HANA нь санах ойн DBMS юм, өөрөөр хэлбэл, үндсэн өгөгдлийн дүрс нь RAM-д хадгалагддаг бөгөөд гамшгийн үед сэргээх зорилгоор зөвхөн бүртгэлүүд болон үечилсэн хормын хувилбаруудыг дискэнд бичдэг.
HANA кластерийн зангилаа бүр нь өгөгдлийн өөрийн гэсэн хэсгийг хариуцдаг бөгөөд өгөгдлийн зураг нь зохицуулагчийн зангилаа дээр байрлах тусгай бүрэлдэхүүн хэсэг болох Нэрийн серверт хадгалагддаг. Зангилааны хооронд өгөгдөл давхарддаггүй. Түгжих мэдээлэл нь зангилаа бүр дээр хадгалагддаг боловч систем нь дэлхийн түгжрэл илрүүлэгчтэй байдаг.
HANA клиент нь кластерт холбогдох үед өөрийн топологийг татаж аваад ямар өгөгдөл хэрэгтэй байгаагаас хамааран дурын зангилаа руу шууд хандах боломжтой. Хэрэв гүйлгээ нь нэг зангилааны өгөгдөлд нөлөөлж байвал түүнийг тухайн зангилаагаар локал байдлаар гүйцэтгэж болох боловч хэд хэдэн зангилааны өгөгдөл өөрчлөгдвөл эхлүүлэгч зангилаа зохицуулагч зангилаатай холбогдож, тараасан гүйлгээг нээж, зохицуулдаг. оновчтой хоёр үе шаттай гүйцэтгэх протокол.
Зохицуулагчийн зангилаа давхардсан тул зохицуулагч бүтэлгүйтвэл нөөц зангилаа шууд хүлээн авна. Гэхдээ өгөгдөл бүхий зангилаа бүтэлгүйтвэл түүний өгөгдөлд хандах цорын ганц арга бол зангилааг дахин эхлүүлэх явдал юм. Дүрмээр бол HANA кластерууд алдагдсан зангилааг аль болох хурдан дахин эхлүүлэхийн тулд нөөц серверийг ажиллуулдаг.
Эх сурвалж: www.habr.com