SQL Server Failover Cluster: სრული სახელმძღვანელო მონაცემთა ბაზის მონაცემთა ბაზისთვის [2026]

SQL Server გადართვის კლასტერი არის მაღალი ხელმისაწვდომობის გადაწყვეტა რომელიც ინარჩუნებს SQL Server ინსტანცია ფუნქციონირებს სერვერის გათიშვის შემთხვევაშიც კი. ეს მიიღწევა ერთი და იგივე ინსტანციის მრავალ ფიზიკურ სერვერზე — კვანძებზე — გაშვებით, ისე, რომ თუ ერთი სერვერი გაითიშება, მეორე ავტომატურად აიღებს მას, ხელით ჩარევის ან კლიენტის მხრიდან ცვლილებების გარეშე.

1.2 ძირითადი კომპონენტები და არქიტექტურა

A SQL Server Failover კლასტერის ეგზემპლარი აგებულია ხუთი ძირითადი კომპონენტისგან, რომელთაგან თითოეული ასრულებს განსხვავებულ როლს. ერთად, ისინი ქმნიან ერთ ლოგიკურ ერთეულს, რომელთანაც კლიენტები ურთიერთქმედებენ, თითქოს ეს ერთი სერვერი იყოს.

კვანძები: ფიზიკური სერვერები, რომლებიც მონაწილეობენ კლასტერში. ნებისმიერ დროს, მხოლოდ ერთი კვანძია აქტიური და მართავს SQL Server მაგალითად; დარჩენილი კვანძები მოლოდინის რეჟიმში არიან და აკვირდებიან აქტიური კვანძის მდგომარეობას.
გაზიარებული საცავი: შენახვის ტომი — SAN, iSCSI, Storage Spaces Direct ან SMB ფაილის გაზიარება — რომელზეც ერთდროულად წვდომა აქვს ყველა კვანძს. რადგან ყველა კვანძი კითხულობს და წერს ერთი და იგივე მეხსიერებაში, კვანძებს შორის მონაცემთა რეპლიკაცია საჭირო არ არის და ერთი და იგივე მონაცემთა ბაზის ფაილები დაუყოვნებლივ არის ხელმისაწვდომი, მიუხედავად იმისა, თუ რომელი კვანძი აიღებს მასზე წვდომას.
ვირტუალური ქსელის სახელი და ვირტუალური IP მისამართი: სტაბილური იდენტობა, რომელსაც კლიენტები ყოველთვის უკავშირდებიან, მიუხედავად იმისა, თუ რომელი ფიზიკური კვანძია ამჟამად აქტიური. გადართვის დროს, ვირტუალური ქსელის სახელი და IP მისამართი ხელახლა რეგისტრირდება ახალ აქტიურ კვანძზე, რაც გადასვლას აპლიკაციებისთვის გამჭვირვალეს ხდის.
Windows Server-ის გადამისამართების კლასტერიზაცია (WSFC): ძირითადი პლატფორმა, რომელიც ყველაფერს ერთად აერთიანებს. WSFC განუწყვეტლივ აკონტროლებს კვანძებისა და რესურსების მდგომარეობას გულისცემის ქსელის მეშვეობით, მართავს რესურსების ჯგუფის საკუთრებას და წარუმატებლობის აღმოჩენის შემთხვევაში ახორციელებს გადართვის პროცესს.
კვორუმი: WSFC-ის ფარგლებში ხმის მიცემის მექანიზმი, რომელიც ხელს უშლის გაყოფილი ტვინის სცენარებს. თითოეული კვანძი ხმას აძლევს კლასტერის მდგომარეობაზე; მოწმის დისკი ან ფაილის გაზიარება დამატებით ხმას იძლევა ლუწი კვანძების კლასტერებზე. კლასტერი ონლაინ რჩება მხოლოდ მაშინ, როდესაც ხმების უმრავლესობა ხელმისაწვდომია, რაც უზრუნველყოფს, რომ ორი იზოლირებული კვანძების ჯგუფი ვერასდროს შეძლებს ერთდროულად მოითხოვოს საკუთრება. SQL Server მაგალითად.

ეს კომპონენტები მკაფიო იერარქიაში მუშაობენ: WSFC მართავს კვანძებს და უზრუნველყოფს კვორუმის აღსრულებას, კვანძები იზიარებენ წვდომას ერთსა და იმავე მეხსიერებაზე, ხოლო ვირტუალური ქსელის სახელი კლიენტებს უზრუნველყოფს თანმიმდევრული კავშირის წერტილს მთელ ქსელში. როდესაც კვანძი ვერ ხერხდება, WSFC აღმოაჩენს გულისცემის გაწყვეტას, ადასტურებს, რომ კვორუმი კვლავ არსებობს, გადასცემს რესურსების ჯგუფის საკუთრებას - მათ შორის ვირტუალური ქსელის სახელს, ვირტუალურ IP მისამართს და მეხსიერებას - სარეზერვო კვანძზე და მოაქვს SQL Server ისევ ონლაინშია. მთელი თანმიმდევრობა ავტომატურად და კლიენტის მხრიდან რაიმე ცვლილების გარეშე ხდება.

1.3 FCI vs Always On Availability Groups

SQL Server გთავაზობთ WSFC-ზე აგებულ ორ Always On ტექნოლოგიას. ძირითადი განსხვავებები:

Failover კლასტერის ეგზემპლარი (FCI): ეგზემპლარის დონის მაღალი ხელმისაწვდომობა (HA). ყველა მონაცემთა ბაზა ერთდროულად ვერ ხერხდება. საჭიროებს საერთო მეხსიერებას. არ ხდება მონაცემთა რეპლიკაცია კვანძებს შორის. არ არსებობს ჩაშენებული კატასტროფის აღდგენის (DR) ფუნქცია.
ყოველთვის ხელმისაწვდომი ჯგუფები (AG): მონაცემთა ბაზის დონის მაღალი ხელმისაწვდომობა. ლოგზე დაფუძნებული რეპლიკაცია მეორად რეპლიკებში. საერთო მეხსიერება არ არის საჭირო. მხარს უჭერს როგორც HA-ს, ასევე DR-ს.

არსებული საერთო საცავის გამოყენებით ეგზემპლარის დონის გადართვისთვის გამოიყენეთ FCI. FCI-ის AG-სთან შერწყმა ასევე საჭიროა კატასტროფის აღდგენის ან წაკითხვადი მეორადი ფაილების შემთხვევაში.

1.4 უპირატესობები და შეზღუდვები

უპირატესობები:

ავტომატური გადართვა აპარატურის, ოპერაციული სისტემის ან სერვისის გაუმართაობის შემთხვევაში;
კლიენტის რეკონფიგურაცია არ არის საჭირო;
არაპირდაპირი საკონტროლო წერტილების მეშვეობით პროგნოზირებადი ჩავარდნის დრო;
მოქნილი საერთო შენახვის პარამეტრები.

შეზღუდვები:

გაზიარებული მეხსიერება წარუმატებლობის ერთადერთი წერტილია, თუ თავად მეხსიერება არ არის ზედმეტი;
მხოლოდ ერთი კვანძი მუშაობს SQL Server ერთდროულად, ამიტომ წაკითხვის დატვირთვის დაბალანსება არ ხდება;
ჩაშენებული DR არ არის ხელმისაწვდომი AG-სთან დაწყვილების გარეშე.

2. წინაპირობები და მოთხოვნები

2.1 აპარატურა და პროგრამული უზრუნველყოფა

მინიმუმ ორი ფიზიკური სერვერი იდენტური ან ეკვივალენტური აპარატურით, 64-ბიტიანი პროცესორებით და მეხსიერების კონტროლერებით, რომლებიც სერტიფიცირებულია Failover კლასტერიზაციისთვის.
Windows Server 2016, 2019 ან 2022 (Standard ან Datacenter). ყველა კვანძს უნდა ჰქონდეს ერთი და იგივე ოპერაციული სისტემის გამოცემა, ვერსია და კუმულაციური განახლების დონე.
SQL Server სტანდარტული ან საწარმო ვერსია. ყველა კვანძი ერთნაირად უნდა მუშაობდეს SQL Server ვერსია და პატჩის დონე.

2.2 ქსელისა და დომენის მოთხოვნები

ყველა კვანძი უნდა ეკუთვნოდეს ერთსა და იმავე Active Directory დომენს. სამუშაო ჯგუფის კლასტერები, მრავალდომენიანი კლასტერები და მხოლოდ წასაკითხი დომენის კონტროლერები არ არის მხარდაჭერილი.
ყველა ადაპტერს მიანიჭეთ სტატიკური IP მისამართები. კლასტერის ტრაფიკისთვის თითოეულ კვანძზე გამოყავით მინიმუმ ერთი ქსელური ინტერფეისის ბარათი (NIC). სახელების გადასაჭრელად დააკონფიგურირეთ დომენური სახელის სისტემა (DNS).
ინსტალაციის ანგარიში მოითხოვს ადგილობრივი ადმინისტრატორის უფლებებს ყველა კვანძზე და შექმენით კომპიუტერული ობიექტები ნებართვა Active Directory-ში.

2.3 გაზიარებული შენახვის ვარიანტები

SQL Server Failover კლასტერიზაცია მხარს უჭერს რამდენიმე გაზიარებული შენახვის ტექნოლოგიას. აირჩიეთ ის, რომელიც საუკეთესოდ შეესაბამება თქვენს ინფრასტრუქტურას და ბიუჯეტს:

SAN (ბოჭკოვანი არხი ან iSCSI): ყველაზე გავრცელებული. ყველა კვანძს უნდა ჰქონდეს წვდომა ერთსა და იმავე ლოგიკურ ერთეულ ნომრებზე (LUN). გამოიყენეთ მრავალგზიანი შეყვანა/გამოყვანა (MPIO), რათა თავიდან აიცილოთ ერთგზიანი ჩავარდნები.
Storage Spaces Direct (S2D): ლოკალურად მიერთებული NVMe ან SSD, გაერთიანებული კვანძებში. საჭიროებს Windows Server 2016 Datacenter-ს ან უფრო გვიანდელ ვერსიას.
სერვერის შეტყობინებების ბლოკის (SMB) ფაილების გაზიარება და კლასტერის გაზიარებული ტომები (CSV): მხარდაჭერილია SQL Server 2014 წლიდან მოყოლებული.

ყველა კლასტერული დისკის ფორმატირება NT ფაილურ სისტემაში (NTFS). მოერიდეთ კლასტერულ კვანძებზე დამონტაჟებული ტომების გამოყენებას.

3. კლასტერის დაგეგმვა

ინსტალაციამდე, თქვენ უნდა დაგეგმოთ კვანძის კონფიგურაციის ტიპი და კვორუმის დაყენება, რაც პირდაპირ გავლენას ახდენს კლასტერის საიმედოობაზე და აპარატურის ღირებულებაზე:

3.1 კონფიგურაციის ტიპები

SQL Server Failover კლასტერები მხარს უჭერენ კვანძის კონფიგურაციების ოთხ ტიპს, რომელთაგან თითოეული განსხვავებულად მოქმედებს სიმარტივეზე, აპარატურის ღირებულებასა და ლოდინის ტევადობაზე.

ტიპი 1: აქტიური/ლოდინის რეჟიმი. 1 FCI, 2 კვანძი. კვანძი 1 აქტიურია; კვანძი 2 ლოდინის რეჟიმშია. ლოდინის კვანძი განუწყვეტლივ აკონტროლებს აქტიური კვანძის გულისცემას და აქტიური კვანძის გათიშვის შემთხვევაში FCI-ს იღებს კონტროლს. ეს არის უმარტივესი კონფიგურაცია და ყველაზე გავრცელებული წარმოებაში.
ტიპი 2: აქტიური/აქტიური. 2 FCI, რომლებიც იზიარებენ 2 ფიზიკურ კვანძს. კვანძი 1 არის FCI 1-ის აქტიური კვანძი და FCI 2-ის სარეზერვო კვანძი; კვანძი 2 არის FCI 2-ის აქტიური კვანძი და FCI 1-ის სარეზერვო კვანძი. ორი კვანძი ურთიერთსაწინააღმდეგო სარეზერვო კვანძია — ორივე ნორმალური მუშაობის დროს ატარებს აქტიურ სამუშაო დატვირთვას. თუ რომელიმე კვანძი გაფუჭდება, გადარჩენილი კვანძი იღებს გაფუჭებული კვანძის FCI-ს და აგრძელებს საკუთარი კვანძის მუშაობას. ამიტომ, თითოეული კვანძის ზომა უნდა იყოს ისე, რომ გაუმკლავდეს ორივე FCI-ის კომბინირებული სამუშაო დატვირთვას.
ტიპი 3: N+1. N FCI-ები, რომლებიც იყენებენ N+1 კვანძს. თითოეულ FCI-ს აქვს ერთი აქტიური კვანძი; ყველა N FCI-ს აქვს ერთი საერთო სარეზერვო კვანძი. საერთო სარეზერვო კვანძს უნდა შეეძლოს დამოუკიდებლად ასათვისებელი ნებისმიერი ერთი გაუმართავი აქტიური კვანძის სრული სამუშაო დატვირთვა.
ტიპი 4: N+M. N FCI-ები, რომლებიც იზიარებენ N+M კვანძებს. თითოეულ FCI-ს აქვს ერთი აქტიური კვანძი; ყველა N FCI-ს აქვს M სარეზერვო კვანძი. M სარეზერვო კვანძები ერთობლივად ფარავს ყველა N აქტიური კვანძის გადართვის სერვისს, ანაწილებს პოტენციურ დატვირთვას სარეზერვო ტევადობაზე და ამცირებს თითოეული კვანძის აპარატურულ მოთხოვნებს N+1-თან შედარებით.

3.2 კვორუმის სახელმძღვანელო პრინციპები

კვორუმი განსაზღვრავს, ჰყავს თუ არა კლასტერს საკმარისი ჯანმრთელი წევრი ონლაინ რეჟიმში დასარჩენად. კვორუმის შექმნისა და შენარჩუნებისას გაითვალისწინეთ შემდეგი მითითებები:

გაყოფილი სცენარის დროს უმრავლესობის უზრუნველსაყოფად და „ტვინის გაყოფის“ თავიდან ასაცილებლად, დააკონფიგურირეთ კვორუმის ხმების კენტი საერთო რაოდენობა.
ორკვანძიანი კლასტერებისთვის გამოიყენეთ კვანძისა და დისკის უმრავლესობა მესამე ხმის სახით მოწმის დისკით. მოწმის დისკს დისკის ასო არ სჭირდება.
თუ კვორუმი მთლიანად დაკარგულია, გადარჩენილი კვანძების აღსადგენად უკიდურეს შემთხვევაში გამოიყენეთ კვორუმი, შემდეგ კი წარმოებაში დაბრუნებამდე დაუყოვნებლივ განახორციელეთ ხელახლა კონფიგურაცია.

4. Windows Server Failover Cluster-ის (WSFC) ინსტალაცია

4.1 საერთო საცავის მომზადება

კლასტერის შექმნამდე მიაერთეთ და დააკონფიგურირეთ ყველა გაზიარებული მეხსიერება.

ფიზიკურად მიაერთეთ ან მოამარაგეთ ყველა შენახვის LUN კლასტერის ყველა კვანძზე.
წლის მხოლოდ პირველი კვანძი, გახსენით დისკის მენეჯმენტი, თითოეული დისკი ონლაინ რეჟიმში გადაიყვანეთ, ინიციალიზაცია გაუკეთეთ და შექმენით NTFS დისკის ასოთი ტომი. შექმენით პატარა ტომი (1–2 GB) მოწმის დისკისთვის — დისკის ასო საჭირო არ არის.
თითოეულ დარჩენილ კვანძზე გახსენით დისკის მენეჯმენტი და მხოლოდ დისკების ონლაინ რეჟიმში გადაყვანა. არ განახორციელოთ ხელახლა ინიციალიზაცია ან ხელახლა ფორმატირება. თუ ისინი არ ემთხვევა პირველ კვანძს, ხელით მიანიჭეთ დისკის ასოები.

4.2 Failover Clustering ფუნქციის ინსტალაცია და ვალიდაცია

დააინსტალირეთ Failover Clustering ფუნქცია ყველა კვანძზე, შემდეგ კი კლასტერის შექმნამდე დაადასტურეთ იგი.

თითოეულ კვანძზე, გახსენით Server Manager -> როლებისა და ფუნქციების დამატება -> მისი მახასიათებლებია;, აირჩიეთ Failover კლასტერული, და დააჭირეთ ინსტალაციაგადატვირთეთ, თუ მოთხოვნილია. PowerShell-ის ალტერნატივა:
```
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
```
ნებისმიერ კვანძზე, გახსენით Failover კლასტერის მენეჯერი -> კონფიგურაციის ვალიდაციადაამატეთ ყველა კვანძის ჰოსტის სახელი და გაუშვით ყველა ტესტი. PowerShell-ის ალტერნატივა:
```
Test-Cluster -Node Node1, Node2
```
გაგრძელებამდე გამოასწორეთ ვალიდაციის ანგარიშში არსებული ყველა შეცდომა. Storage Spaces Direct გაფრთხილებები შეიძლება იგნორირებული იყოს, თუ S2D არ გამოიყენება.

4.3 WSFC-ის შექმნა

ვალიდაციის წარმატებით დასრულების შემდეგ, შექმენით კლასტერი და გადაამოწმეთ მისი კონფიგურაცია.

In Failover კლასტერის მენეჯერი, დააჭირეთ შექმენით კლასტერი, დაამატეთ ყველა კვანძის ჰოსტის სახელი, შეიყვანეთ კლასტერის სახელი და სტატიკური ვირტუალური IP მისამართი, შემდეგ დააჭირეთ შემდეგიPowerShell-ის ალტერნატივა:
```
New-Cluster -Name ClusterName -Node Node1, Node2 -StaticAddress x.x.x.x
```
თუ დომენის ნებართვები შეზღუდულია, სთხოვეთ თქვენს Active Directory ადმინისტრატორს, რომ ამ ნაბიჯის შესრულებამდე წინასწარ მოამზადოს კლასტერის სახელის კომპიუტერული ობიექტი.
შექმნის შემდეგ, დაადასტურეთ კვორუმის ჩვენებები კვანძისა და დისკის უმრავლესობა მოწმის დისკით მინიჭებული.
ქვეშ შენახვის სივრცე -> დისკები, თითოეული კლასტერული დისკის სახელის შეცვლა მისი როლის ასახვის მიზნით (მაგალითად, SQL_DATA, SQL_LOG, მოწმობა). ქვეშ ქსელები, შეცვალეთ თითოეული კლასტერული ქსელის სახელი მისი ტრაფიკის ტიპის შესაბამისად.

5. ინსტალაცია SQL Server Failover კლასტერის ეგზემპლარი

5.1 ინსტალაციის მეთოდის არჩევა

SQL Server ინსტალაცია გთავაზობთ ორ მიდგომას failover კლასტერის ეგზემპლარის დასაყენებლად. აირჩიეთ ის, რომელიც შეესაბამება თქვენს გარემოს.

ინტეგრირებული ინსტალაცია (კვანძის დამატება): დააინსტალირეთ სრული, მოქმედი FCI პირველ კვანძზე, შემდეგ დაამატეთ თითოეული შემდეგი კვანძი შემდეგი ინსტრუქციის გამოყენებით: კვანძის დამატება ვარიანტი. უფრო მარტივი და რეკომენდებულია განლაგების უმეტესობისთვის.
გაფართოებული/კორპორატიული ინსტალაცია: გასაშვებად Failover კლასტერის მომზადება ჯერ ყველა კვანძზე, შემდეგ კი გაუშვით სრული გადართვის კლასტერი საერთო დისკის მფლობელ კვანძზე. გამოიყენეთ ეს მიდგომა მრავალკვანძიანი დიდი გაშვებისთვის, სადაც გსურთ ყველა კვანძის პარალელურად მომზადება დადასტურებამდე.

5.2 პირველი კვანძის ინსტალაცია

გასაშვებად SQL Server ინტეგრირებული მეთოდის გამოყენებით FCI-ის შესაქმნელად პირველ კვანძზე დაყენება.

გასაშვებად Setup.exe როგორც ადმინისტრატორი. აირჩიეთ მონტაჟი -> ახალი SQL Server გადართვის კლასტერის ინსტალაცია.
On მხატვრული შერჩევა, აირჩიოს მონაცემთა ბაზის ძრავის სერვისები მდე მართვის ინსტრუმენტები – ძირითადი.
On ინსტანციის კონფიგურაცია, შეიყვანეთ SQL Server ქსელის სახელი — ვირტუალური სახელი, რომელსაც კლიენტები იყენებენ დასაკავშირებლად.
On კლასტერული რესურსების ჯგუფი, შეიყვანეთ ჯგუფის აღწერილობითი სახელი.
On კლასტერული დისკის შერჩევა, აირჩიეთ გაზიარებული დისკები მონაცემების, ჟურნალის და სარეზერვო ფაილებისთვის.
On კლასტერის ქსელის კონფიგურაცია, თითოეულ ქვექსელზე IP მისამართის მინიჭება. დაყენება ავტომატურად აყენებს OR დამოკიდებულებას მრავალქვექსელიანი კლასტერებისთვის.
On სერვერის კონფიგურაცია, სერვისის ანგარიშების დაყენება. პაროლის ავტომატური მართვისთვის გამოიყენეთ ჯგუფის მიერ მართული სერვისის ანგარიში (gMSA); გამოიყენეთ დომენის ანგარიშები სარეზერვო ასლის სახით.
On მონაცემთა ბაზის ძრავის კონფიგურაცია, აირჩიეთ ავტორიზაციის რეჟიმი და დააყენეთ მონაცემთა დირექტორიის ბილიკები. მოათავსეთ სისტემის მონაცემთა ბაზები, მომხმარებლის მონაცემთა ბაზები, ჟურნალები, სარეზერვო ასლები და TempDB ცალკე დისკებზე.
გადახედეთ შეჯამებას და დააწკაპუნეთ ინსტალაცია.

5.3 დარჩენილი კვანძების დამატება

პირველი კვანძის დასრულების შემდეგ, დაამატეთ თითოეული დამატებითი კვანძი FCI-ს.

დამატებით კვანძზე, გაუშვით Setup.exe და აირჩიეთ მონტაჟი -> კვანძის დამატება a-ზე SQL Server გადართვის კლასტერი.
On კლასტერის კვანძების კონფიგურაცია, აირჩიეთ არსებული FCI ეგზემპლარი.
On კლასტერის ქსელის კონფიგურაცია, მიანიჭეთ IP მისამართი ამ კვანძის ქვექსელისთვის.
On სერვისის ანგარიშები, დაადასტურეთ, რომ სერვისის ანგარიშის პაროლები ემთხვევა პირველ კვანძზე დაყენებულ პაროლებს, შემდეგ დააჭირეთ ღილაკს ინსტალაცია.
გაიმეორეთ ყოველი დამატებითი კვანძისთვის.

6. ინსტალაციის შემდგომი პერიოდი: კონფიგურაცია და ტესტირება

6.1 არსებითი SQL Server პარამეტრები

გამოიყენეთ ეს პარამეტრები FCI-ის ამოქმედებისთანავე.

უცნობია სერვერის მაქსიმალური მეხსიერება დასაფარად SQL Server-ის მეხსიერება და დატოვეთ თავისუფალი ადგილი ოპერაციული სისტემისა და კლასტერის სერვისებისთვის:
```
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'max server memory', <value_in_MB>; RECONFIGURE;
```
უცნობია პარალელიზმის მაქსიმალური ხარისხი (MAXDOP) თქვენი არაერთგვაროვანი მეხსიერების წვდომის (NUMA) ტოპოლოგიის საფუძველზე.
გადაიტანეთ TempDB ცალკე ტომში მისი შემავალი/გამომავალი ველების იზოლირებისთვის:
```
USE master;
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'D:\TempDB\tempdb.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'D:\TempDB\templog.ldf');
```
გადატვირთეთ SQL Server სერვისი ფაილის გადატანის ძალაში შესასვლელად.

6.2 ტესტის წარუმატებლობა

კლასტერის წარმოებაში გადატანამდე შეამოწმეთ გადართვის ქცევის დადასტურება.

In Failover კლასტერის მენეჯერი, დააწკაპუნეთ მაუსის მარჯვენა ღილაკით SQL Server FCI-ის როლი და შერჩევა გადატანა -> კვანძის არჩევააირჩიეთ მეორადი კვანძი და დააწკაპუნეთ OK.
დაელოდეთ როლის სტატუსის გამოჩენას სირბილი ახალ კვანძზე.
კლიენტის მოწყობილობიდან, დაუკავშირდით SQL Server ვირტუალური ქსელის სახელის გამოყენებით და დაადასტურეთ, რომ კავშირი წარმატებულია კავშირის სტრიქონის შეცვლის გარეშე.
გადახედე SQL Server შეცდომების ჟურნალი და Windows-ის კლასტერის მოვლენების ჟურნალი, რათა დაადასტუროთ სუფთა გადართვა თქვენი აღდგენის დროის მიზნის (RTO) ფარგლებში.

7. მენეჯმენტი, საუკეთესო პრაქტიკა და პრობლემების მოგვარება

7.1 გადართვის პოლიტიკა და მონიტორინგი

In Failover კლასტერის მენეჯერი, დააწკაპუნეთ მაუსის მარჯვენა ღილაკით SQL Server FCI-ის როლი -> განცხადებები -> Failover შეცდომის მდგომარეობის დონისა და შემოწმების ვადის დასაყენებლად. გაზარდეთ ვადის ამოწურვა ძლიერ დატვირთულ სერვერებზე, რათა თავიდან აიცილოთ ცრუ ჩავარდნები.
კლასტერის მდგომარეობის მონიტორინგი Failover კლასტერის მენეჯერი, Windows Event Viewerსაქართველოს SQL Server შეცდომების ჟურნალი და SQL Server საქმიანობის მონიტორი რეალურ დროში რესურსებისა და სესიის ხილვადობისთვის.
ნებისმიერი ავტომატური გადართვის შემდეგ, გადახედეთ SQL Server დიაგნოსტიკური ჟურნალები (შენახულია შეცდომის ჟურნალთან ერთად) კომპონენტის მდგომარეობისთვის, რომელიც მოვლენამდე მივიდა. გამოიყენეთ SQL Server გაფართოებული ღონისძიებები რესურსების მდგომარეობისა და გადართვის ფანჯრის გარშემო შეცდომების პირობების დეტალური კვალის აღსაწერად.

7.2 საუკეთესო პრაქტიკა

გამოიყენეთ სტატიკური IP მისამართები ყველა კვანძზე. დინამიური მასპინძლის კონფიგურაციის პროტოკოლის (DHCP) იჯარის ვადის გასვლა გადართვის დროს ახანგრძლივებს შეფერხების დროს და ართულებს DNS რეგისტრაციას.
კვორუმის ხმების რაოდენობა ყოველთვის კენტი უნდა იყოს. თუ კვანძის დამატებით ხმების რაოდენობა კენტ რაოდენობას მიაღწევს, დაამატეთ მოწმე.
კლასტერის ვალიდაცია გაუშვით აპარატურის ნებისმიერი ცვლილების, დრაივერის განახლების ან ოპერაციული სისტემის კონფიგურაციის მნიშვნელოვანი ცვლილების შემდეგ.
ყველა კვანძზე იდენტური დისკის ასოების მინიჭებამდე SQL Server ინსტალაცია. შეუსაბამობები აფერხებს ინსტალაციას და შემდგომში მათი გამოსწორება რთულია.
ინსტალაციის დღემდე დაუკავშირდით თქვენს Active Directory ადმინისტრატორს. კომპიუტერული ობიექტების შექმნის ნებართვები ინსტალაციამდე ყველაზე გავრცელებული ბლოკატორია.
შეინარჩუნეთ ტესტირებული SQL Server სარეზერვო სტრატეგია FCI-ის არსებობის შემთხვევაშიც კი. FCI იცავს კვანძის გაუმართაობისგან და არა მონაცემთა დაზიანებისგან, შემთხვევითი წაშლისგან ან შენახვის დონის დაკარგვისგან — რეგულარული სარეზერვო ასლის შექმნისა და აღდგენის გრაფიკი ამ სცენარებიდან ერთადერთი დაცვაა.

7.3 გავრცელებული პრობლემები და მათი გამოსწორება

Active Directory-ის ნებართვების შეცდომები: სთხოვეთ თქვენს Active Directory (AD) ადმინისტრატორს, წინასწარ მოამზადოს კლასტერის კომპიუტერული ობიექტი, ან მიანიჭეთ მას უფლებამოსილება. შექმენით კომპიუტერული ობიექტები მდე ყველა თვისების წაკითხვა ინსტალაციის ანგარიშზე.
გაზიარებული მეხსიერება კვანძებზე არ ჩანს: გადატვირთეთ iSCSI სამიზნე სერვერი სერვისი შენახვის ჰოსტზე, შემდეგ ხელახლა დაუკავშირდით iSCSI ინიციატორიდან თითოეულ კვანძზე. გადაამოწმეთ LUN ნიღაბი და ზონირება.
დრაივერების ან განახლების დონეების დამადასტურებელი გაფრთხილებები: გამოიყენეთ უახლესი კუმულაციური განახლება Windows Update ყველა კვანძზე ხელახლა ვალიდაციის დაწყებამდე.
WSFC კვანძის უკმარისობის შემდეგ ოფლაინში გადის: გამოიყენეთ ფორსირებული კვორუმი გადარჩენილი კვანძების ონლაინ რეჟიმში გადასაყვანად, ნებისმიერი მონაცემთა ბაზის აღდგენა შეცდომით დაზარალებული, აღადგინეთ კვორუმი, შემდეგ ხელახლა დააკონფიგურირეთ წარმოებაში დაბრუნებამდე. გაუშვით DBCC CHECKDB თითოეულ აღდგენილ მონაცემთა ბაზაზე, რათა დადასტურდეს მთლიანობა ნორმალური სამუშაო დატვირთვის განახლებამდე.
ცრუ ავტომატური ჩავარდნები: გაზარდეთ FCI როლის თვისებებში ჯანმრთელობის შემოწმების ვადის ამოწურვა. გადახედეთ დიაგნოსტიკურ ჟურნალებს, რათა განასხვავოთ ნამდვილი შეცდომა რესურსების დროებითი პიკისგან.

8. ხშირად დასმული კითხვები

კითხვა: რა არის კვანძების მინიმალური რაოდენობა, რომელიც საჭიროა... SQL Server გადართვის კლასტერი?

A: მინიმუმ ორი კვანძია. ერთი მოქმედებს როგორც აქტიური კვანძი, რომელიც მართავს SQL Server მაგალითად; მეორე არის სარეზერვო რეჟიმი. საწარმოო განლაგების უმეტესობა იწყება ორკვანძიანი აქტიური/პასიური კონფიგურაციით.

Q: აკეთებს SQL Server FCI-ს საერთო საცავი სჭირდება?

A: დიახ. Always On Availability Groups-ისგან განსხვავებით, FCI მოითხოვს, რომ ყველა კვანძმა ერთსა და იმავე მეხსიერებაზე წვდომა ჰქონდეს — SAN (Fibre Channel ან iSCSI), Storage Spaces Direct-ზე ან SMB ფაილის გაზიარებაზე. გაზიარებული მეხსიერება არის ის, რაც იმავე მონაცემთა ბაზის ფაილებს ხელმისაწვდომს ხდის ნებისმიერი კვანძიდან გადართვის შემდეგ.

_ რა SQL Server გამოცემები მხარს უჭერენ failover კლასტერიზაციას?

A: SQL Server სტანდარტული და საწარმო ვერსიები მხარს უჭერენ FCI-ს. Express და Developer ვერსიები - არა. საწარმო ვერსია მხარს უჭერს მეტ კვანძს და დამატებით მაღალი ხელმისაწვდომობის ფუნქციებს, როგორიცაა ონლაინ ინდექსის ოპერაციები ტექნიკური მომსახურების დროს.

კითხვა: შეიძლება SQL Server FCI და Always On Availability ჯგუფები ერთად უნდა იქნას გამოყენებული?

A: დიახ. FCI კვანძს შეუძლია ხელმისაწვდომობის ჯგუფის რეპლიკის ჰოსტინგი, რაც მოგცემთ როგორც FCI-დან ეგზემპლარის დონის HA-ს, ასევე ხელმისაწვდომობის ჯგუფიდან მონაცემთა ბაზის დონის DR-ს. თუმცა, ხელმისაწვდომობის ჯგუფის ავტომატური გადართვა FCI-ზე ჰოსტირებულ რეპლიკაზე ან მისგან არ არის მხარდაჭერილი — ამ კონფიგურაციაში მხოლოდ ხელით გადართვაა ხელმისაწვდომი.

კითხვა: რამდენ ხანს გრძელდება SQL Server როგორც წესი, Failover-ს სჭირდება?

A: გადართვის დრო დამოკიდებულია ბუფერულ ქეშში არსებული იმ „ბინძური“ გვერდების რაოდენობაზე, რომლებიც უნდა ჩაიწეროს დისკზე, სანამ ეგზემპლარი გადაიტვირთება ახალ კვანძზე. არაპირდაპირი საკონტროლო წერტილების ჩართვის შემთხვევაში (ნაგულისხმევი მნიშვნელობა SQL Server 2012 წლიდან), „დაბინძურებული“ გვერდები შეზღუდულია და ჩავარდნის უმეტესი ნაწილი 30 წამზე ნაკლებ დროში სრულდება. თქვენი ფაქტობრივი RTO დამოკიდებულია დატვირთვაზე, შენახვის სიჩქარეზე და მონაცემთა ბაზის აღდგენის დროზე.

კითხვა: რა არის კვორუმი და რატომ არის ის მნიშვნელოვანი?

A: კვორუმი არის მექანიზმი, რომელსაც WSFC იყენებს იმის დასადგენად, ჰყავს თუ არა კლასტერს საკმარისი ჯანსაღი წევრები ონლაინ რეჟიმში დარჩენისა და მოთხოვნების შესასრულებლად. ეს ხელს უშლის გაყოფილი ტვინის სცენარს, სადაც ორი იზოლირებული კვანძოვანი ჯგუფი თვლის, რომ ისინი არიან კვანძების ავტორიტეტული მფლობელი. SQL Server მაგალითად. თუ კვორუმი დაიკარგება, WSFC მონაცემთა მთლიანობის დასაცავად კლასტერს ოფლაინში გადაიტანს.

კითხვა: შეიძლება SQL Server FCI დაინსტალირდება სამუშაო ჯგუფის კლასტერზე (Active Directory-ის გარეშე)?

არა: SQL Server FCI მოითხოვს, რომ ყველა კვანძი ერთი და იგივე Active Directory დომენის წევრი იყოს. სამუშაო ჯგუფის კლასტერები, მრავალდომენიანი კლასტერები და კლასტერები, რომლებიც მოიცავს მხოლოდ წასაკითხ დომენის კონტროლერებს, არ წარმოადგენს მხარდაჭერილ კონფიგურაციებს.

კითხვა: რა ხდება კლიენტის კავშირებთან, როდესაც ხდება გადართვის შეცდომა?

A: აქტიური კავშირები SQL Server ინსტანცია გამორთულია გადართვის დროს. მას შემდეგ, რაც ინსტანცია ახალ კვანძზე ონლაინ რეჟიმში გავა, ვირტუალური ქსელის სახელი და ვირტუალური IP მისამართი ხელახლა დარეგისტრირდება იქ და კლიენტები, რომლებიც იყენებენ ხელახლა ცდის ლოგიკას თავიანთ კავშირის სტრიქონებში, ავტომატურად დაუკავშირდებიან ხელახლა კონფიგურაციის ცვლილების გარეშე.

კითხვა: შემიძლია არსებულიდან კვანძების დამატება ან წაშლა? SQL Server გადართვის კლასტერი?

ა: კი. სირბილი SQL Server დააყენეთ ნებისმიერ კვანძზე და აირჩიეთ კვანძის დამატება a-ზე SQL Server გადართვის კლასტერი კვანძის დასამატებლად, ან კვანძის ამოღება a-დან SQL Server გადართვის კლასტერი ერთის წასაშლელად. კვანძის დამატება ან წაშლა არ საჭიროებს კლასტერში სხვა კვანძების მუშაობის შეფერხებას.

კითხვა: რა განსხვავებაა დაგეგმილ და ავტომატურ ჩავარდნას შორის?

A: დაგეგმილი ჩავარდნა იწყება ადმინისტრატორის მიერ ხელით — როგორც წესი, ტექნიკური მომსახურებისთვის, როგორიცაა პატჩების განახლება ან აპარატურის შეცვლა. ეს საშუალებას იძლევა SQL Server საკუთრების გადაცემამდე დაბინძურებული გვერდების გასასუფთავებლად და სისტემის გამართულად გამოსართავად, რაც მინიმუმამდე დაიყვანება შეფერხების დრო. WSFC ავტომატურად ააქტიურებს გადართვის რეჟიმს, როდესაც მდგომარეობის მონიტორინგი აღმოაჩენს, რომ აქტიური კვანძი გაფუჭებულია და აღდგენის დრო დამოკიდებულია ავარიის შემდეგ აღდგენის საჭირო დროზე.

კითხვა: როგორ აღვადგინო? SQL Server გადართვის კლასტერი, თუ მთელი WSFC გაითიშება?

A: თუ კვორუმი დაიკარგა და კლასტერი ნორმალურად ვერ ჩაირთვება, გამოიყენეთ კვორუმის იძულებითი რეჟიმი, რათა დარჩენილი კვანძები ონლაინ რეჟიმში გადაიყვანოთ ხარვეზებისადმი ტოლერანტულ მდგომარეობაში. შეასრულეთ შემდეგი PowerShell ბრძანება დარჩენილ კვანძზე: Start-ClusterNode -ForcQuorumკლასტერის ონლაინ რეჟიმში გაშვების შემდეგ, აღადგინეთ მონაცემთა ბაზები, გადაამოწმეთ მონაცემთა მთლიანობა და შემდეგ ხელახლა დააკონფიგურირეთ კვორუმი დარჩენილ კვანძებთან, სანამ წარმოებაში დაბრუნდებით.

კითხვა: უნდა გავუშვა თუ არა კლასტერის დადასტურების ოსტატი ყოველი SQL Server ინსტალაცია?

A: დიახ, და ასევე ნებისმიერი მნიშვნელოვანი აპარატურის ან კონფიგურაციის ცვლილების შემდეგ. Microsoft მხარს უჭერს მხოლოდ იმ კლასტერულ კონფიგურაციებს, რომლებიც შეცდომების გარეშე გადის ყველა ვალიდაციის ტესტს. ვალიდაციის გამოტოვება რისკავს მხარდაუჭერელი კონფიგურაციის გაშვებას, რომელმაც შეიძლება არაპროგნოზირებად იმოქმედოს გაუმართაობის პირობებში.

9. დასკვნა

SQL Server Failover კლასტერიზაცია უზრუნველყოფს გამჭვირვალე ეგზემპლარის დონის მაღალ ხელმისაწვდომობას WSFC-ის მეშვეობით, ავტომატური Failover-ით და კლიენტის რეკონფიგურაციის საჭიროების გარეშე. ეს სწორი არჩევანია, როდესაც საერთო მეხსიერება ხელმისაწვდომია და გჭირდებათ ეგზემპლარზე არსებული ყველა მონაცემთა ბაზა ერთად, როგორც ერთეული. იმ გარემოებისთვის, რომლებიც ასევე საჭიროებენ კატასტროფის აღდგენას ან მეორადი წაკითხვის სამუშაო დატვირთვას, დააკავშირეთ FCI Always On Availability Groups-თან ორივე სცენარის დასაფარად.

ლიტერატურა

Microsoft-ის ოფიციალური დოკუმენტი: Windows Server-ის გადატვირთვის კლასტერი SQL Server
Microsoft-ის ოფიციალური დოკუმენტი: ყოველთვის ჩართულია Failover კლასტერის ეგზემპლარები
Microsoft-ის ოფიციალური დოკუმენტი: Failover კლასტერის ეგზემპლარის ინსტალაცია
Microsoft-ის ოფიციალური დოკუმენტი: WSFC-ის კვორუმის რეჟიმები და ხმის მიცემის კონფიგურაცია

ავტორის შესახებ

იუან შენგი არის მონაცემთა ბაზის უფროსი ადმინისტრატორი (DBA) 10 წელზე მეტი გამოცდილებით SQL Server გარემოსა და საწარმოს მონაცემთა ბაზის მართვაში. მან წარმატებით გადაჭრა მონაცემთა ბაზის აღდგენის ასობით სცენარი ფინანსურ სერვისებში, ჯანდაცვისა და წარმოების ორგანიზაციებში.

იუანი სპეციალიზირებულია SQL Server მონაცემთა ბაზის აღდგენა, მაღალი ხელმისაწვდომობის გადაწყვეტილებები და მუშაობის ოპტიმიზაცია. მისი ფართო პრაქტიკული გამოცდილება მოიცავს მრავალტერაბაიტიანი მონაცემთა ბაზების მართვას, Always On Availability Groups-ის დანერგვას და კრიტიკულად მნიშვნელოვანი ბიზნეს სისტემებისთვის ავტომატური სარეზერვო ასლისა და აღდგენის სტრატეგიების შემუშავებას.

თავისი ტექნიკური ექსპერტიზისა და პრაქტიკული მიდგომის წყალობით, იუანი ფოკუსირებულია ყოვლისმომცველი სახელმძღვანელოების შექმნაზე, რომლებიც მონაცემთა ბაზის ადმინისტრატორებსა და IT სპეციალისტებს დაეხმარება რთული საკითხების გადაჭრაში. SQL Server ეფექტურად უწევს გამოწვევებს. ის მუდმივად ადევნებს თვალყურს უახლეს ამბებს SQL Server რელიზები და Microsoft-ის განვითარებადი მონაცემთა ბაზის ტექნოლოგიები, რეგულარულად ამოწმებს აღდგენის სცენარებს იმის უზრუნველსაყოფად, რომ მისი რეკომენდაციები ასახავდეს რეალურ სამყაროს საუკეთესო პრაქტიკას.

გაქვთ შეკითხვები SQL Server აღდგენა ან გჭირდებათ დამატებითი რჩევები მონაცემთა ბაზის პრობლემების მოგვარებაში? იუანი სიამოვნებით მოგმართავთ. გამოხმაურება და წინადადებები ამ ტექნიკური რესურსების გასაუმჯობესებლად.