Salamlar  Microsoft Failover Clustering məqaləmin bu hissəsində SQL Clustering-dən danışmağa çalışacam. İki növ SQL clustering mövcuddur: bunlardan birincisi FCI (Failover Cluster Instances) -bu növ SQL cluster-larda traditional cluster quruluşunda olduğu kimi shared storage istifadə olunur.  Hər bir yüklü SQL Server əslində SQL Instance adlanır. Hər bir SQL node-üçün ümumi olacaq verilənlər bazası shared storage üzərində yerləşir. Node-larda baş verəcək hər hansı bir fail zamanı  verilənlər bazası digər node-un ixtiyarına keçir, gələn transaction -ları isə Cluster Role kimi əlavə edib tənzimləyəcəyimiz Distributed Transaction Coordinator role-u  idarə edir.  Transaction–  verilənlər bazası üzərində aparılan hər hansı bir dəyişiklik, məlumat daxil etmə, məlumat silmə və s. kimi başa düşülə bilər . Bir transaction içərisində bir neçə əməliyyat ola bilər. Bütün bu əməliyyatlar  uğurla başa çatdıqda transaction tamamlanmış olur. Əgər əməliyyatlardan biri gerçəkləşdirilə bilməsə o zaman verilənlər bazası üzərində həmin transaction daxilindəki bütün əməliyyatlar aparılmamış sayılır. Bu növ clustering seçimində High Availability and Disaster Recovery həlli üçün mirroring, log shipping və replication kimi texnologiyalardan istifadə etməliyik.

Database Mirroring-  bir serverin verilənlər bazasında olan dəyişikliklərin eyni zamanda digər server və  ya disaster site-dakı server üzərindəki server-in verlənlər bazasına senxron ya da asenxron olaraq yazılmasıdır.

Log Shipping-   High Availability və həm də Disaster Recovery  həllərinin ən qədimi sayılır, ana verilənlər bazasının transaction log-larından bəslənən digər bir verilənlər bazasının olası bir fəlakət zamanı ana verilənlər bazasını əvəz etməsi.

Replication-  Publisher( mərkəzi verilənlər bazası) və subscriber-lar  (mərkəzi verilənlər bazasında melumatları replica edən read-only kopyası) arasında  məlumatların replica olunması.

2-ci növ High Availability və həm də Disaster Recovery həlli  SQL AlwaysOn High Availability Groups-dur. AlwaysOn Groups yuxarıda sadalanan həllərin hər birini özündə birləşdirən və daha geniş imkanları ilə High Availability və Disaster Recovery həllidir.  FCI -dən fərqli olaraq burada shared storage şərt deyil,  ola da bilər, ya da olduğu kimi local diskdə də yerləşə bilər.

yuxarıdakı rəsimdən də aydın olduğu kimi Primary və Disaster Site  ya da  sadəcə Primary Site içərisində mövcud SQL Server daxilində AlwaysOn Groups tənzimləməsi edərək mövcud digər verilənlər bazalarını bu qrupa daxil edirik. Primary Replica bizim Primary Site-ımızda duran hər hansı bir SQL instance üzərindəki verilənlər bazası,  üzərindəki dəyişiklərin sinxron ya da asinxron yolla daşınacağı verilənlər bazaralı isə Secondary Replica adlanır.

Mənim test üçün istifadə edəcəyim  mühit aşağıdakı kimidir:

İlk öncə Active Directory üzərində bir OU yaratmalıyıq və OU-nu daxili aşağıdakı kimi olmalıdır.

Biz Users OU-su daxilində SQL server-lərimizizn servisləri üçün bir user yaradırıq, və bu istifadəçisi MSSQL Cluster OU-su üəzində  müəyyən hüquqlara malik olmalıdır:

Eyni zamanda bu istifadəçi SQL node-larımız üzərində local admin hüququna malik olmalıdır, bunu eyni zamanda Group Policy ilə və ya da node üzərindən də edə bilərik. GPO ilə bunu eləmək üçün ilk olaraq Group Policy Management üzərində OU-muzun altında olan obyektlərin yuxarıdakı hər hansı bir GPO-dan təsirlənməməsi üçün Block Inheritance seçimindən istifadə etməliyik:

OU-muz altında yeni bir GPO yaradaraq aşağıdakı kimi tənzimləyirik:

Node-lar üzərində gpupdate /force əmrini icra edib restart edirik, daha sonra Failover Cluster tənzimləmələrinə keçirik, yəni yeni bir cluster yaradaraq node-ları bu cluster-ə daxil edəcəyik, lakin shared storage-in iştirakı olmadan, role-ların qurulumu haqqında əvvəlki məqalələrimdə ətraflı danışdığım üçün bu məqaləmdə bu mövzulara çox toxunmayacağam:

mövcud node-larımızı əlavə edib davam edirik:

shared storage olmadığı  üçün onunla bağlı testləri etmirik:

və yeni bir cluster yaradırıq:

gördüyümüz kimi quorum olaraq hər hansı bir disk ya da bir file share yoxdur:

bunun üçün mən DC01 üzərində bir qovluq paylaşmışam və bu qovluğu yeni cluster-imiz üçün witness olaraq müəyyən edəcəyik, əvvəlki məqələlərdə bu haqda daha ətraflı məlumat ala bilərsiz:

Confiqure a  file share witness deyərək davam edirik:

DC01 üzərindəki paylaşılmış qovluğu seçərək davam edirik:

gördüyümüz kimi witness-imizi müvəffəqiyyətlə tənzimlədik:

İndi isə keçirik SQL Server-in node-lar üzərinə qurulması və tənzimləmələrinə, qeyd edim ki hər iki node üzərində  update-lər tam olaraq yüklü vəziyyətdə olması daha məqsədəuyğun və vacibdir:

mövcud update-ləri yükləməliyik, lakin test mühiti olduğu üçün mən seçmədən davam edirəm:

olduğu kimi saxlayıb davam edirik:

aşağıdakı özəllikləri seçərək davam edirik:

olduğu kimi saxlayaraq davam edirik:

bu hissədə yaratdığımız və hüquqlandırdığımız istifadəçimizi seçirik:

bu hissənin aşağıdakı kimi olduğundan əmin olmaqda fayda var:

Authentication Mode üçün Mixed Mode seçərək uyğun istifadəçini Add buttonu ilə əlavə edirik və onunla bağlı şifrəni daxil edirik:

Install deyərək qurulumu başladırıq:

Eyni prosesi digər node üzərində də təkrarlayırıq.  Biz qurulumları stand-alone olaraq həyata keçirmişik AlwaysOn özəlliyinin istifadə oluna biləsi üçün cluster-in üzvü olması lazımdır, bunun üçün hər iki node-üzərində SQL Configuration Manager-i açırıq, aşağıdakı kimi SQL Server servisini seçib özəlliklərinə daxil oluruq:

Aşağıdakı dəyişikliyi etdikdən sonra həmin yolla servisi yenidən başladırıq:

İndi isə keçirik AllwaysOn Groups tənzimləmərinə. Primary Replica olaraq müəyyən edəcəyimiz verilənlər bazası üçün müəyyən tələblər mövcuddur.

Verilənlər bazasının minimum 1 ədəd Full Backup-ı alınmış olmalıdır:

Vrilənlər bazası -full recovery mode-da olmalıdır:

Verilənlər bazasının minimum 1 ədəd T-log  backup-ı olmalıdır.

SQLAOHNODE01 üzərində SQL Management Studio-nu açırıq AlwaysOn High Availability Groups>New Availability Groups Wizard deyirik:

Uyğun ad verərək davam edirik:

DB adlı verilənlər bazasının  yuxarıda deyilən tələblərə cavab verdiyi üçün görünür ,seçərək davam edirik:

Add Replica buttonu ilə ikinci node-umuzu əlavə edirik, avtomatik olaraq secondary replica olaraq müəyyən olunur. İki cür  idarəçi tərəfindən olunan manual və Primary Replica-nın offline olması nəticəsində yaranan automatic failover mümkündür. Transaction-lar  secondary replica-lara göndərilərkən yenisi göndərilməzdən əvvəl əvvəlkinin  müvəffəqiyyətlə başa çatdığı barədə məlumat gözlənilir, bu sinxon üsul adlanır. Asinxron da isə belə deyil sadəcə transaction-lar göndərilir müvəffəqiyyətlə başa çatıb-çatmamağı önəmli deyil. Primary Replica-nı yazma, Secondary Replica-nı oxuma və backup üçün istifadə etmək istəyirsinizsə Redable Secondary bölməsindən yararlana bilərsiniz:

burada fikir verəcəyimiz məqam firewall-varsa uyğun portların açıq olmasıdır:

Bu hissədə əgər Prefer Secondary seçilərsə,  Secondary Replica əlçatan olduğu halda backup-lar bu replica üzərindən alınacaq, əgər offline olarsa o zaman primary replica-dan alınacaqdır:

Əgər istifadəçilərin Cluster servisinin hostname-indən başqa bir hostname ilə bağlanmağını istəyiriksə bu zaman listener yaratmalıyıq:

Full -burda müəyyən etdiyimiz hər bir replica-lardan əlçatan olan bir path üzərində həmin verilənlər bazasının backup-ı alınaraq secondary replica üzərinə restore olunur. Join only -seçimində isə backup və restore prosesi bizim tərfimizdən həyata keçirilir sadəcə AlwaysOn Group yaratdıqdan sonra həmin server-i qrupa join eləməli oluruq:

Gördüyümüz kimi SQLAOH adlı bir AlwaysOn High Availability Group yaratdıq və serverlərimizdən biri Primary digəri isə Secondary Replica olaraq tənzimləndi:

Məqaləmin bu hissəsi də burada bitir, yararlı olması diləyi ilə…