CAP teoremi paylanmış sistemlər nəzəriyyəsinin təməl daşıdır. Təbii ki, onun ətrafında mübahisələr səngimir: ondakı təriflər kanonik deyil və ciddi sübut yoxdur... Buna baxmayaraq, gündəlik sağlam düşüncənin mövqelərində möhkəm dayanaraq, biz intuitiv olaraq teoremin doğru olduğunu başa düşürük.
Aydın olmayan yeganə şey "P" hərfinin mənasıdır. Klaster bölündükdə, kvoruma çatana qədər cavab verməməyə və ya mövcud məlumatları geri verməyə qərar verir. Bu seçimin nəticələrindən asılı olaraq sistem ya CP, ya da AP kimi təsnif edilir. Məsələn, Cassandra, hətta klaster parametrlərindən deyil, hər bir xüsusi sorğunun parametrlərindən asılı olaraq hər iki şəkildə davrana bilər. Bəs sistem “P” deyilsə və parçalanırsa, onda nə olacaq?
Bu sualın cavabı bir qədər gözlənilməzdir: CA klasteri bölünə bilməz.
Bu necə çoxluqdur ki, parçalana bilmir?
Belə bir klasterin əvəzsiz atributu ortaq məlumat saxlama sistemidir. Əksər hallarda bu, SAN üzərindən qoşulma deməkdir ki, bu da SAN infrastrukturunu saxlamağa qadir olan böyük müəssisələrə CA həllərinin istifadəsini məhdudlaşdırır. Birdən çox serverin eyni verilənlərlə işləməsi üçün klasterləşdirilmiş fayl sistemi tələb olunur. Belə fayl sistemləri HPE (CFS), Veritas (VxCFS) və IBM (GPFS) portfellərində mövcuddur.
Oracle RAC
Real Application Cluster seçimi ilk dəfə 2001-ci ildə Oracle 9i-nin buraxılışı ilə ortaya çıxdı. Belə bir klasterdə bir neçə server nümunəsi eyni verilənlər bazası ilə işləyir.
Oracle həm klaster fayl sistemi, həm də öz həlli ilə işləyə bilər - ASM, Avtomatik Saxlama İdarəetmə.
Hər nüsxə öz jurnalını saxlayır. Əməliyyat bir instansiya tərəfindən icra edilir və həyata keçirilir. Nümunə uğursuz olarsa, sağ qalan klaster qovşaqlarından (nümunələrdən) biri onun jurnalını oxuyur və itirilmiş məlumatları bərpa edir - bununla da mövcudluğu təmin edir.
Bütün instansiyalar öz keşini saxlayır və eyni səhifələr (bloklar) eyni anda bir neçə instansiyanın keşində ola bilər. Üstəlik, əgər bir instansiya səhifəyə ehtiyac duyursa və o, başqa bir instansiyanın yaddaşındadırsa, diskdən oxumaq əvəzinə onu öz qonşusundan keş birləşmə mexanizmindən istifadə edə bilər.
Bəs nümunələrdən birinin məlumatı dəyişməsi lazımdırsa nə baş verir?
Oracle-ın özəlliyi ondadır ki, onun xüsusi kilidləmə xidməti yoxdur: əgər server cərgəni bağlamaq istəyirsə, o zaman kilid qeydi birbaşa kilidlənmiş cərgənin yerləşdiyi yaddaş səhifəsində yerləşdirilir. Bu yanaşma sayəsində Oracle monolit verilənlər bazaları arasında performans çempionudur: kilidləmə xidməti heç vaxt darboğaza çevrilmir. Lakin klaster konfiqurasiyasında belə bir arxitektura intensiv şəbəkə trafikinə və çıxılmaz vəziyyətə gətirib çıxara bilər.
Qeyd kilidləndikdən sonra instansiya bütün digər instansiyalara həmin qeydi saxlayan səhifənin eksklüziv saxlama hüququna malik olduğunu bildirir. Əgər başqa bir instansiya eyni səhifədəki qeydi dəyişdirməlidirsə, o, səhifəyə edilən dəyişikliklərin həyata keçirilməsini, yəni dəyişiklik haqqında məlumatın diskdəki jurnala yazılmasını gözləməlidir (və əməliyyat davam edə bilər). Bir səhifənin ardıcıl olaraq bir neçə nüsxə ilə dəyişdirilməsi də baş verə bilər və sonra səhifəni diskə yazarkən bu səhifənin cari versiyasını kimin saxladığını öyrənməli olacaqsınız.
Fərqli RAC qovşaqlarında eyni səhifələrin təsadüfi yenilənməsi verilənlər bazası performansının kəskin şəkildə aşağı düşməsinə səbəb olur ki, klaster performansı bir nümunədən daha aşağı ola bilər.
Oracle RAC-ın düzgün istifadəsi verilənləri fiziki olaraq bölməkdir (məsələn, hissələrə bölünmüş cədvəl mexanizmindən istifadə etməklə) və hər bir bölmə dəstinə ayrılmış node vasitəsilə daxil olmaqdır. RAC-ın əsas məqsədi üfüqi miqyaslama deyil, nasazlığa dözümlülüyün təmin edilməsi idi.
Bir düyün ürək döyüntüsünə cavab verməyi dayandırarsa, onu aşkar edən qovşaq əvvəlcə diskdə səsvermə proseduruna başlayır. Çatışmayan node burada qeyd edilmirsə, qovşaqlardan biri məlumatların bərpası üçün məsuliyyət daşıyır:
- itkin node keşində olan bütün səhifələri "dondurur";
- çatışmayan qovşağın qeydlərini oxuyur (yenidən yerinə yetirmək) və bu jurnallarda qeydə alınan dəyişiklikləri təkrar tətbiq etməklə eyni zamanda digər qovşaqlarda dəyişdirilən səhifələrin daha yeni versiyalarının olub-olmadığını yoxlayır;
- gözləyən əməliyyatları geri qaytarır.
Qovşaqlar arasında keçidi sadələşdirmək üçün Oracle xidmət konsepsiyasına malikdir - virtual instansiya. Nümunə birdən çox xidmətə xidmət edə bilər və xidmət qovşaqlar arasında hərəkət edə bilər. Verilənlər bazasının müəyyən hissəsinə xidmət edən proqram nümunəsi (məsələn, bir müştəri qrupu) bir xidmətlə işləyir və verilənlər bazasının bu hissəsinə cavabdeh olan xidmət qovşaq uğursuz olduqda başqa qovşağa keçir.
Əməliyyatlar üçün IBM Pure Data Systems
DBMS üçün klaster həlli 2009-cu ildə Blue Giant portfelində peyda oldu. İdeoloji cəhətdən o, “adi” avadanlıq üzərində qurulmuş Paralel Sysplex klasterinin davamçısıdır. 2009-cu ildə DB2 pureScale proqram dəsti kimi buraxıldı və 2012-ci ildə IBM Transaksiyalar üçün Saf Məlumat Sistemləri adlı cihazı təklif etdi. Onu yenidən adlandırılmış Netezzadan başqa bir şey olmayan Analitika üçün Saf Məlumat Sistemləri ilə qarışdırmaq olmaz.
İlk baxışdan pureScale arxitekturası Oracle RAC-a bənzəyir: eyni şəkildə bir neçə qovşaq ümumi məlumat saxlama sisteminə qoşulur və hər bir qovşaq öz yaddaş sahələri və əməliyyat jurnalları ilə öz DBMS nümunəsini idarə edir. Lakin, Oracle-dan fərqli olaraq, DB2 bir sıra db2LLM* prosesləri ilə təmsil olunan xüsusi kilidləmə xidmətinə malikdir. Klaster konfiqurasiyasında bu xidmət Parallel Sysplex-də birləşmə qurğusu (CF) və Pure Data-da PowerHA adlanan ayrıca qovşaqda yerləşdirilir.
PowerHA aşağıdakı xidmətləri təqdim edir:
- kilid meneceri;
- qlobal bufer önbelleği;
- proseslərarası rabitə sahəsi.
PowerHA-dan verilənlər bazası qovşaqlarına və arxaya məlumat ötürmək üçün uzaqdan yaddaşa giriş istifadə olunur, ona görə də klasterin qarşılıqlı əlaqəsi RDMA protokolunu dəstəkləməlidir. PureScale Ethernet üzərindən həm Infiniband, həm də RDMA-dan istifadə edə bilər.
Əgər node bir səhifəyə ehtiyac duyursa və bu səhifə keşdə deyilsə, o zaman qovşaq qlobal keşdəki səhifəni tələb edir və yalnız orada olmadıqda onu diskdən oxuyur. Oracle-dan fərqli olaraq, sorğu qonşu qovşaqlara deyil, yalnız PowerHA-ya gedir.
Nümunə cərgəni dəyişdirmək niyyətindədirsə, o, onu eksklüziv rejimdə, sətirin yerləşdiyi səhifəni isə paylaşılan rejimdə kilidləyir. Bütün kilidlər qlobal kilid menecerində qeydə alınıb. Tranzaksiya başa çatdıqda, qovşaq dəyişdirilmiş səhifəni qlobal ön yaddaşa köçürən, kilidləri buraxan və digər qovşaqların keşlərində dəyişdirilmiş səhifəni etibarsız edən kilid menecerinə mesaj göndərir.
Dəyişdirilmiş sıranın yerləşdiyi səhifə artıq kilidlənibsə, kilid meneceri dəyişdirilmiş səhifəni dəyişikliyi edən qovşağın yaddaşından oxuyacaq, kilidi buraxacaq, dəyişdirilmiş səhifəni digər qovşaqların keşlərində etibarsız hesab edəcək və səhifə kilidini tələb edən node verin.
"Çirkli", yəni dəyişdirilmiş səhifələr həm adi qovşaqdan, həm də PowerHA-dan (castout) diskə yazıla bilər.
Əgər pureScale qovşaqlarından biri uğursuz olarsa, bərpa yalnız uğursuzluq zamanı tamamlanmamış əməliyyatlarla məhdudlaşır: tamamlanmış əməliyyatlarda həmin node tərəfindən dəyişdirilmiş səhifələr PowerHA-da qlobal keşdədir. Düyün klasterdəki serverlərdən birində azaldılmış konfiqurasiyada yenidən işə salınır, gözlənilən əməliyyatları geri qaytarır və kilidləri buraxır.
PowerHA iki serverdə işləyir və master node öz vəziyyətini sinxron şəkildə təkrarlayır. Əsas PowerHA qovşağı uğursuz olarsa, klaster ehtiyat qovşağı ilə işləməyə davam edir.
Təbii ki, verilənlər toplusuna bir qovşaq vasitəsilə daxil olsanız, klasterin ümumi performansı daha yüksək olacaq. PureScale hətta müəyyən bir məlumat sahəsinin bir qovşaq tərəfindən işləndiyini görə bilər və sonra bu sahə ilə əlaqəli bütün kilidlər PowerHA ilə əlaqə yaratmadan node tərəfindən yerli olaraq işlənəcəkdir. Lakin proqram bu məlumatı başqa bir node vasitəsilə əldə etməyə cəhd edən kimi, mərkəzləşdirilmiş kilidin işlənməsi bərpa olunacaq.
IBM-in 90% oxu və 10% yazma iş yükü ilə bağlı daxili testləri real dünya istehsal iş yüklərinə çox bənzəyir, 128 node-a qədər demək olar ki, xətti miqyaslama göstərir. Təəssüf ki, sınaq şərtləri açıqlanmır.
HPE NonStop SQL
Hewlett-Packard Enterprise portfelinin də yüksək əlçatan platforması var. Bu, 1976-cı ildə Tandem Computers tərəfindən bazara çıxarılan NonStop platformasıdır. 1997-ci ildə şirkət Compaq tərəfindən alınıb, o da öz növbəsində 2002-ci ildə Hewlett-Packard ilə birləşib.
NonStop kritik proqramların yaradılması üçün istifadə olunur - məsələn, HLR və ya bank kartının işlənməsi. Platforma hesablama qovşaqlarını, məlumatların saxlanması sistemini və rabitə avadanlığını özündə birləşdirən proqram-texniki kompleks (cihaz) şəklində təqdim olunur. ServerNet şəbəkəsi (müasir sistemlərdə - Infiniband) həm qovşaqlar arasında mübadilə, həm də məlumat saxlama sisteminə daxil olmaq üçün xidmət edir.
Sistemin ilkin versiyalarında bir-biri ilə sinxronlaşdırılan mülkiyyət prosessorlarından istifadə olunurdu: bütün əməliyyatlar bir neçə prosessor tərəfindən sinxron şəkildə yerinə yetirilirdi və prosessorlardan biri xəta törədən kimi o, söndürülür, ikincisi isə işləməyə davam edirdi. Daha sonra sistem adi prosessorlara (əvvəlcə MIPS, sonra Itanium və nəhayət x86) keçdi və sinxronizasiya üçün digər mexanizmlərdən istifadə olunmağa başladı:
- mesajlar: hər bir sistem prosesində aktiv proses vaxtaşırı öz statusu haqqında mesajlar göndərən “kölgə” əkizinə malikdir; əsas proses uğursuz olarsa, kölgə prosesi sonuncu mesajın müəyyən etdiyi andan işə başlayır;
- səsvermə: saxlama sistemində çoxsaylı eyni girişləri qəbul edən və yalnız girişlər uyğun olduqda onları yerinə yetirən xüsusi aparat komponenti var; Fiziki sinxronizasiya əvəzinə prosessorlar asinxron işləyir və onların işinin nəticələri yalnız giriş/çıxış anlarında müqayisə edilir.
1987-ci ildən NonStop platformasında əlaqəli DBMS işləyir - əvvəlcə SQL/MP, sonra isə SQL/MX.
Bütün verilənlər bazası hissələrə bölünür və hər bir hissə öz Data Access Manager (DAM) prosesinə cavabdehdir. O, məlumatların qeydə alınması, keşləşdirilməsi və kilidləmə mexanizmlərini təmin edir. Məlumatların emalı müvafiq məlumat menecerləri ilə eyni qovşaqlarda işləyən İcraçı Server Prosesləri tərəfindən həyata keçirilir. SQL/MX planlayıcısı tapşırıqları icraçılar arasında bölür və nəticələri ümumiləşdirir. Razılaşdırılmış dəyişikliklər etmək zərurəti yarandıqda, TMF (Transaction Management Facility) kitabxanası tərəfindən təqdim edilən iki fazalı öhdəlik protokolundan istifadə edilir.
NonStop SQL prosesləri prioritetləşdirə bilər ki, uzun analitik sorğular əməliyyatın icrasına mane olmasın. Bununla belə, onun məqsədi analitika deyil, dəqiq qısa əməliyyatların işlənməsidir. Tərtibatçı, NonStop klasterinin beş "doqquz" səviyyəsində mövcudluğuna zəmanət verir, yəni dayanma müddəti ildə cəmi 5 dəqiqədir.
SAP-HANA
HANA DBMS-nin (1.0) ilk stabil buraxılışı 2010-cu ilin noyabrında baş verdi və SAP ERP paketi 2013-cü ilin mayında HANA-ya keçdi. Platforma alınmış texnologiyalara əsaslanır: TREX Axtarış Mühərriki (sütunlu yaddaşda axtarış), P*TIME DBMS və MAX DB.
“HANA” sözünün özü qısaldılmışdır, Yüksək Performanslı Analitik Cihazdır. Bu DBMS istənilən x86 serverlərində işləyə bilən kod şəklində verilir, lakin sənaye qurğularına yalnız sertifikatlaşdırılmış avadanlıqlarda icazə verilir. HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC-dən əldə edilə bilən həllər. Bəzi Lenovo konfiqurasiyaları hətta SAN olmadan işləməyə imkan verir - ümumi saxlama sisteminin rolunu yerli disklərdəki GPFS klasteri oynayır.
Yuxarıda sadalanan platformalardan fərqli olaraq, HANA yaddaşdaxili DBMS-dir, yəni ilkin məlumat görüntüsü RAM-da saxlanılır və fəlakət zamanı bərpa üçün diskə yalnız qeydlər və dövri snapshotlar yazılır.
Hər bir HANA klaster qovşağı məlumatların öz hissəsinə cavabdehdir və məlumat xəritəsi koordinator qovşağında yerləşən xüsusi komponentdə - Ad Serverində saxlanılır. Məlumat qovşaqlar arasında təkrarlanmır. Kilidləmə məlumatları da hər bir qovşaqda saxlanılır, lakin sistemdə qlobal kilid detektoru var.
HANA müştərisi klasterə qoşulduqda, o, topologiyasını yükləyir və daha sonra ehtiyac duyduğu məlumatdan asılı olaraq istənilən node-a birbaşa daxil ola bilər. Əgər tranzaksiya bir qovşağın məlumatlarına təsir edirsə, o zaman həmin qovşaq tərəfindən lokal olaraq icra oluna bilər, lakin bir neçə qovşaqın məlumatları dəyişirsə, başlanğıc qovşağı paylanmış əməliyyatı açıb koordinasiya edən koordinator qovşağı ilə əlaqə saxlayır, onu bir qovşaqdan istifadə etməklə həyata keçirir. optimallaşdırılmış iki fazalı icra protokolu.
Koordinator qovşağı təkrarlanır, ona görə də koordinator uğursuz olarsa, ehtiyat qovşağı dərhal öz üzərinə götürür. Lakin məlumatı olan node uğursuz olarsa, onun məlumatlarına daxil olmağın yeganə yolu qovşağı yenidən başlatmaqdır. Bir qayda olaraq, HANA klasterləri itirilmiş qovşağı mümkün qədər tez yenidən işə salmaq üçün ehtiyat server saxlayır.
Mənbə: www.habr.com