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

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

1.2 რატომ სჭირდებათ ბიზნესებს ყოველთვის ხელმისაწვდომი გადაწყვეტილებები

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

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

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

1.3 ძირითადი ცნებები: RTO, RPO, HA და DR

აღდგენის დროის მიზანი (RTO) განსაზღვრავს შეცდომის შემდეგ შეფერხების მაქსიმალურ მისაღებ ხანგრძლივობას — რამდენად სწრაფად უნდა დაუბრუნდეს მონაცემთა ბაზა ონლაინ რეჟიმში.

აღდგენის წერტილის მიზანი (RPO) განსაზღვრავს დროში გაზომილ მაქსიმალურ დასაშვებ მონაცემთა დანაკარგს — რამდენი ახლახანს გადაცემული მონაცემის დაკარგვა შეუძლია ბიზნესს.

მაღალი ხელმისაწვდომობა (HA) ფოკუსირებულია იმავე მონაცემთა ცენტრში რუტინული ჩავარდნებით, როგორიცაა აპარატურის გაუმართაობა ან პროგრამული უზრუნველყოფის კრახი, გამოწვეული შეფერხებების მინიმიზაციაზე.

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

SQL Server Always On რეჟიმი მხარს უჭერს როგორც HA-ს, ასევე DR-ს ერთიანი არქიტექტურის ფარგლებში. სინქრონული დადასტურების რეჟიმი უზრუნველყოფს RPO = 0-ს ავტომატური გადართვით თითქმის ნულოვანი RTO-სთვის; ასინქრონული დადასტურების რეჟიმი ითვალისწინებს მონაცემთა პოტენციურ დაკარგვას შორეულ ადგილებში შეყოვნების შემცირების სანაცვლოდ.

1.4 ყოველთვის ჩართული გადაწყვეტილებები

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

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

2. ყოველთვის ხელმისაწვდომი ჯგუფები

ყოველთვის ხელმისაწვდომი ჯგუფები (AG) არის მონაცემთა ბაზის დონის მაღალი ხელმისაწვდომობისა და კატასტროფების აღდგენის გადაწყვეტა, რომელიც ახდენს მომხმარებლის მონაცემთა ბაზების ნაკრების კოპირებას რვა მეორად რეპლიკამდე ტრანზაქციების ჟურნალის უწყვეტი მიწოდების გზით.

2.1 ძირითადი მახასიათებლები

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

2.2 განხორციელების ეტაპები

მოამზადეთ Active Directory სერვისის ანგარიშები და დააკონფიგურირეთ ნებართვები ყველა კვანძზე;
ყველა მონაწილე სერვერზე Windows Server Failover Clustering-ის ინსტალაცია და დადასტურება;
ინსტალაცია SQL Server როგორც დამოუკიდებელი ეგზემპლარი თითოეულ კვანძზე, თანმიმდევრული ბილიკებისა და პარამეტრების გამოყენებით;
ჩართეთ „ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფები“ ფუნქცია SQL Server კონფიგურაციის მენეჯერი ან PowerShell;
მონაცემთა ბაზების სრული აღდგენის მოდელზე დაყენება და სრული და ჟურნალის სარეზერვო ასლების შექმნა;
ხელმისაწვდომობის ჯგუფის შექმნა, რეპლიკების დამატება და ხელმისაწვდომობისა და გადატვირთვის რეჟიმების კონფიგურაცია;
მეორადი რეპლიკების დათესვა ავტომატური დათესვის ან ხელით სარეზერვო ასლის შექმნისა და აღდგენის გამოყენებით;
შექმენით ხელმისაწვდომობის ჯგუფის მსმენელი და გადაამოწმეთ კლიენტის კავშირი.

სრული ეტაპობრივი ინსტრუქციისთვის იხილეთ ჩვენი Always On Available Groups-ის სრული სახელმძღვანელო.

2.3 საუკეთესოა

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

2.4 დადებითი

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

2.5 Cons

სრული ფუნქციების ნაკრებისთვის საჭიროა Enterprise Edition (სტანდარტული მხარს უჭერს Basic AG-ს მნიშვნელოვანი შეზღუდვებით);
სინქრონული ჩაწერის რეჟიმი ზრდის ჩაწერის შეყოვნებას, რაც პროპორციულია ქსელის ორმხრივი ჩაწერის დროისა;
შესვლები, SQL Agent-ის დავალებები და დაკავშირებული სერვერები საჭიროებენ ხელით სინქრონიზაციას SQL Server 2019 და უფრო ადრე;
ყველა რეპლიკა უნდა იყოს განთავსებული ერთი და იგივე Windows Server Failover კლასტერის კვანძებზე.

2.6 წყარო

Microsoft-ის ოფიციალური დოკუმენტი: რა არის ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფი?
Microsoft-ის ოფიციალური დოკუმენტი: ყოველთვის ხელმისაწვდომი ჯგუფების გამოყენების დაწყება

3. ყოველთვის ჩართულია Failover კლასტერის ეგზემპლარები

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

3.1 ძირითადი მახასიათებლები

ეგზემპლარის დონის გადართვა: ეგზემპლარზე არსებული ყველა მონაცემთა ბაზა ერთად, როგორც ერთი ერთეული, გადართვას განიცდის;
გაზიარებული საცავი (Storage Area Network (SAN), iSCSI, Storage Spaces Direct ან SMB), რომელზეც წვდომა აქვს ყველა კვანძს;
ვირტუალური ქსელის სახელი და ვირტუალური IP მისამართი უზრუნველყოფს სტაბილურ კავშირის საბოლოო წერტილს, მიუხედავად იმისა, თუ რომელი კვანძია აქტიური;
Windows Server-ის გადატვირთვის კლასტერიზაცია მართავს კვანძის ჯანმრთელობის მონიტორინგს, კვორუმს და გადატვირთვის ორკესტრირებას;
მხარს უჭერს Active/Standby, Active/Active, N+1 და N+M კვანძის კონფიგურაციის ტიპებს.

3.2 განხორციელების ეტაპები

ყველა კლასტერული კვანძისთვის საერთო საცავის უზრუნველყოფა და მიმაგრება;
დააინსტალირეთ Failover Clustering ფუნქცია და დაადასტურეთ კლასტერის კონფიგურაცია;
Windows Server Failover Cluster-ის შექმნა და კვორუმის კონფიგურაცია;
აწარმოებს SQL Server ინსტალაცია ხორციელდება გადამისამართების კლასტერის ოფციის არჩევით და ვირტუალური ქსელის სახელისა და საერთო შენახვის გზების მითითებით;
დაამატეთ დამატებითი კვანძები SQL Server failover კლასტერის ეგზემპლარი;
გადაამოწმეთ გადართვის ქცევა კვანძებს შორის ხელით გადართვის ტესტირებით.

სრული ეტაპობრივი ინსტრუქციისთვის იხილეთ ჩვენი SQL Server Failover Cluster-ის სრული სახელმძღვანელო.

3.3 საუკეთესოა

არსებული საერთო შენახვის ინფრასტრუქტურის მქონე გარემო (SAN ან iSCSI);
აპლიკაციები, რომლებიც საჭიროებენ ეგზემპლარის დონის გადართვას, სადაც ყველა მონაცემთა ბაზა ერთდროულად უნდა გადაერთოს;
სცენარები, სადაც კლიენტის გამჭვირვალობა კრიტიკულად მნიშვნელოვანია და აპლიკაციის მხრიდან ცვლილებები არ არის მისაღები;
ორგანიზაციები, რომლებიც უპირატესობას ანიჭებენ ერთჯერადი ჩავარდნის მოდელის სიმარტივეს.

3.4 დადებითი

ავტომატური გადართვა ეგზემპლარის დონეზე კლიენტის რეკონფიგურაციის საჭიროების გარეშე;
მონაცემთა რეპლიკაციის ზედნადები ხარჯების არარსებობა — ყველა კვანძი ერთსა და იმავე მეხსიერებას იყენებს;
პროგნოზირებადი ჩავარდნის ქცევა ყველა მონაცემთა ბაზისთვის ერთდროულად;
მხარს უჭერს მოქნილ კვანძის კონფიგურაციებს (აქტიური/აქტიური, N+1, N+M) აპარატურის გამოყენების ოპტიმიზაციისთვის.

3.5 Cons

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

3.6 წყარო

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

4. ხელმისაწვდომობის ჯგუფების შეფერხების კლასტერის ეგზემპლარებთან გაერთიანება

ორგანიზაციებისთვის, რომლებიც მოითხოვენ როგორც ეგზემპლარის, ასევე მონაცემთა ბაზის დონის დაცვას, SQL Server მხარს უჭერს ხელმისაწვდომობის ჯგუფის რეპლიკების ჰოსტინგს Failover Cluster Instances-ზე (FCI). ამ კონფიგურაციაში, თითოეული FCI კვანძი მოქმედებს როგორც ერთი ხელმისაწვდომობის რეპლიკა, ამიტომ FCI failover გამჭვირვალეა ხელმისაწვდომობის ჯგუფისთვის, ხოლო AG failover უზრუნველყოფს მონაცემთა ბაზის დონის დაცვას ყველა საიტზე. ეს კომბინაცია უზრუნველყოფს ყველაზე ყოვლისმომცველ მაღალი ხელმისაწვდომობის და კატასტროფის აღდგენის დაფარვას, რომელიც ხელმისაწვდომია... SQL Server.

4.1 ძირითადი მახასიათებლები

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

4.2 განხორციელების ეტაპები

თითოეული FCI-ის დამოუკიდებლად განთავსება და დადასტურება სტანდარტული FCI-ის დაყენების პროცედურების შესაბამისად;
დარწმუნდით, რომ ყველა FCI კვანძი და დამოუკიდებელი რეპლიკა კვანძი ერთსა და იმავე Windows Server Failover კლასტერს ეკუთვნის;
FCI-ის თითოეულ ინსტანციაზე ჩართეთ „ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფების“ ფუნქცია;
გადაამოწმეთ, რომ FCI-ის შესაძლო გადართვის შემდეგ არცერთი WSFC კვანძი არ მასპინძლობს ერთი და იგივე ხელმისაწვდომობის ჯგუფის ორ რეპლიკას;
ხელმისაწვდომობის ჯგუფის შექმნა, FCI ინსტანციების რეპლიკებად დანიშვნა და FCI-ში განთავსებული ყველა რეპლიკისთვის ხელით გადართვის რეჟიმის კონფიგურაცია;
მეორადი რეპლიკების დათესვა და ხელმისაწვდომობის ჯგუფის მსმენელის კონფიგურაცია.

FCI-ის დაყენების დეტალებისთვის იხილეთ ჩვენი SQL Server Failover Cluster-ის სრული სახელმძღვანელო. AG-ის დაყენების დეტალებისთვის იხილეთ ჩვენი Always On Availability Groups-ის სრული სახელმძღვანელო.

4.3 საუკეთესოა

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

4.4 დადებითი

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

4.5 Cons

FCI-ის მიერ განთავსებული რეპლიკები მხარს უჭერენ მხოლოდ AG-ის ხელით გადართვას — ავტომატური AG გადართვა მიუწვდომელია ამ რეპლიკებისთვის;
მოითხოვს WSFC კვანძის ფრთხილად დაგეგმვას, რათა თავიდან იქნას აცილებული, რომ ერთ კვანძში ერთი და იგივე აგ-ს ორი რეპლიკა იყოს განთავსებული FCI-ის ჩავარდნის შემდეგ;
ინფრასტრუქტურის უფრო მაღალი ღირებულება და ოპერაციული სირთულე, ვიდრე მხოლოდ AG-ს ან FCI-ს;
FCI-ის თითოეული კომპონენტისთვის კვლავ საჭიროა საერთო მეხსიერება.

4.6 წყარო

Microsoft-ის ოფიციალური დოკუმენტი: Failover კლასტერიზაცია და ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფები (SQL Server)
Microsoft-ის ოფიციალური დოკუმენტი: რა არის ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფი?
Microsoft-ის ოფიციალური დოკუმენტი: ყოველთვის ხელმისაწვდომი ჯგუფების გამოყენების დაწყება
Microsoft-ის ოფიციალური დოკუმენტი: ყოველთვის ჩართულია Failover კლასტერის ეგზემპლარები (SQL Server)

5. Always On გადაწყვეტილებების შედარება

5.1 მახასიათებლების შედარების ცხრილი

მხატვრული	ხელმისაწვდომობის ჯგუფები	Failover კლასტერის ეგზემპლარები	AG + FCI კომბინირებული
გადამისამართების დიაპაზონი	მონაცემთა ბაზის დონე	ეგზემპლარის დონე	ორივე
საჭიროა საერთო მეხსიერება	არა	დიახ	კი (FCI კომპონენტისთვის)
მონაცემთა რეპლიკაცია	ლოგზე დაფუძნებული თითოეული რეპლიკისთვის	არცერთი (საერთო მეხსიერება)	ლოგარითმული მონაცემებით FCI-ებს შორის
ავტომატური მარცხი	კი (სინქრონული რეპლიკები)	დიახ	FCI: კი; AG: არა
წაკითხვადი მეორადი ჩანაწერები	დიახ	არა	კი (AG კომპონენტი)
კატასტროფის აღდგენა	ჩამონტაჟებული	ჩაშენებული არ არის	ჩამონტაჟებული
მაქსიმალური რეპლიკები	9 (საწარმო)	N / A	9 (საწარმო)
ინფრასტრუქტურის სირთულე	საშუალო	საშუალო	მაღალი
ღირებულება	უფრო დაბალი (SAN არ არის საჭირო)	უფრო მაღალი (საჭიროა SAN)	უმაღლესი

5.2 აირჩიეთ თქვენი ყოველთვის ჩართული გადაწყვეტა

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

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

დღესდღეობით, ახალი ვერსიების უმეტესობისთვის, რეკომენდებული საწყისი წერტილია Always On Availability Groups (ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფები): ის მოიცავს როგორც HA-ს, ასევე DR-ს, არ საჭიროებს საერთო მეხსიერებას და მხარს უჭერს წაკითხვად მეორად მონაცემებს — შესაძლებლობებს, რომლებსაც მხოლოდ FCI ვერ შეედრება.

6. საუკეთესო პრაქტიკა SQL Server ყოველთვის გადაწყვეტილებებზე ორიენტირებული

6.1 დაგეგმვა და დიზაინი

Always On გადაწყვეტის არჩევამდე განსაზღვრეთ RTO და RPO მოთხოვნები — ეს სამიზნეები პირდაპირ განსაზღვრავენ, შესაფერისია თუ არა სინქრონული თუ ასინქრონული ჩაწერის რეჟიმი და შესაძლებელია თუ არა ავტომატური გადართვა.
მეორადი რეპლიკების ზომა ისე განსაზღვრეთ, რომ გაუმკლავდეთ ძირითად სამუშაო დატვირთვას გადართვის მოვლენის დროს, პიკური დატვირთვის სცენარების ჩათვლით.
AG განლაგებისთვის, ჩაწერის შეფერხებაზე ზემოქმედების მინიმიზაციის მიზნით, სინქრონული რეპლიკები მოათავსეთ იმავე მონაცემთა ცენტრში ან დაბალი შეყოვნების მქონე ქსელში. გეოგრაფიულად დაშორებული DR რეპლიკებისთვის დაჯავშნეთ ასინქრონული რეჟიმი.
შექმენით კვორუმი კენტი რაოდენობის ხმებით. ორკვანძიანი კლასტერებისთვის, დაამატეთ ფაილის გაზიარება ან ღრუბლოვანი მოწმე მესამე ხმის სახით, რათა თავიდან აიცილოთ გაყოფილი ტვინის სცენარები.
ყურადღებით დაგეგმეთ თქვენი ქსელის ტოპოლოგია მრავალ ქვექსელზე განლაგებისთვის. თითოეულ ქვექსელს სჭირდება საკუთარი მსმენელის IP მისამართი, ხოლო კლიენტებს დაკავშირების სტრიქონებში დასჭირდებათ MultiSubnetFailover=True.

6.2 განხორციელების სახელმძღვანელო პრინციპები

გამოიყენეთ თანმიმდევრული SQL Server ვერსია, გამოცემა და კუმულაციური განახლების დონეები ყველა რეპლიკაში. შერეულმა პატჩ დონეებმა შეიძლება გამოიწვიოს მოულოდნელი ქცევა გადატვირთვის დროს.
კლასტერის გულისცემის ტრაფიკისთვის სპეციალური ქსელური ინტერფეისების კონფიგურაცია, აპლიკაციის ტრაფიკისგან განცალკევებით.
ავტომატური დათესვის ჩართვა მონაცემთა ბაზის საწყისი სინქრონიზაციისთვის SQL Server 2016 და შემდგომი ვერსიები — უმეტეს შემთხვევაში, ის გამორიცხავს სარეზერვო ასლების მეორად რეპლიკებზე ხელით კოპირების საჭიროებას.
AG + FCI ტოპოლოგიებისთვის, FCI კვანძის კონფიგურაციის ყოველი ცვლილების შემდეგ გადაამოწმეთ, რომ არცერთ WSFC კვანძს არ შეუძლია ერთი და იგივე ხელმისაწვდომობის ჯგუფის ორი რეპლიკის განთავსება.
ყოველთვის გამოიყენეთ SQL Server ხელმისაწვდომობის ჯგუფის ჩავარდნის სამართავად Management Studio ან Transact-SQL — არასდროს გამოიყენოთ პირდაპირ ჩავარდნის კლასტერის მენეჯერი, რადგან ის არ იცნობს AG სინქრონიზაციის მდგომარეობას და შეიძლება გამოიწვიოს გახანგრძლივებული შეფერხება ან მონაცემთა დაკარგვა.

6.3 მონიტორინგი და ტექნიკური მომსახურება

სინქრონიზაციის მდგომარეობის მონიტორინგი, რიგის გაგზავნა და რიგის ხელახლა შექმნა რეგულარულად, ხელმისაწვდომობის ჯგუფის დაფის გამოყენებით SQL Server Management Studio ან Dynamic Management Views (DMV). მეორად მოდელზე მზარდი გამეორების რიგი მიუთითებს შეყვანის/გამოყვანის შეფერხებაზე, რაც შეაფერხებს failover-ის აღდგენას.
გაუშვით DBCC CHECKDB მეორად რეპლიკებზე, რათა პირველადიდან მთლიანობის შემოწმებები განტვირთოთ. იხილეთ ჩვენი DBCC CHECKDB სახელმძღვანელო დამატებითი ინფორმაციისათვის.
მიმართვა SQL Server მოძრავი განახლებებით განახლებების გამოყენებით პატჩების გაკეთება: ჯერ მეორადი სისტემის რეპლიკების პატჩირება, შემდეგ დაგეგმილი ხელით პატჩირებული მეორადი სისტემის პატჩირება, შემდეგ კი წინა პირველადი სისტემის პატჩირება. ეს შეზღუდავს შეფერხების დროს ერთი პატჩირების ხანგრძლივობით.
არაპროდუქტიულ გარემოში რეგულარულად შეამოწმეთ ჩავარდნის რეჟიმი. ავტომატური ჩავარდნის რეჟიმი, რომელიც არასდროს არ არის გამოცდილი, არ წარმოადგენს აღდგენის საიმედო სტრატეგიას.
ხელმისაწვდომობის ჯგუფის ჯანმრთელობის მდგომარეობის ცვლილებების, რეპლიკაციის როლის გადასვლების და სინქრონიზაციის შეცდომების შესახებ შეტყობინებების კონფიგურაცია SQL Server აგენტი ან სპეციალური მონიტორინგის ინსტრუმენტი, როგორიცაა SQL Server შესრულების მონიტორი.

7. კითხვა

_ რა არის SQL Server ყოველთვის ჩართულია?

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

კითხვა: რა განსხვავებაა Always On Availability Groups-სა და Failover Cluster-ის ეგზემპლარებს შორის?

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

კითხვა: მჭირდება თუ არა საერთო საცავი ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფებისთვის?

A: არა. თითოეული AG რეპლიკა ინახავს მონაცემთა ბაზების საკუთარ დამოუკიდებელ ასლს ადგილობრივ მეხსიერებაში. გაზიარებული მეხსიერება საჭიროა მხოლოდ იმ შემთხვევაში, თუ AG რეპლიკების განსათავსებლად იყენებთ Failover Cluster-ის ეგზემპლარებს.

კითხვა: შემიძლია გამოვიყენო Always On ფუნქცია „ყოველთვის ჩართული“-თან ერთად SQL Server სტანდარტული გამოცემა?

A: SQL Server სტანდარტული გამოცემა მხარს უჭერს ძირითადი ხელმისაწვდომობის ჯგუფებს, დაწყებული SQL Server 2016, თუმცა მნიშვნელოვანი შეზღუდვებით: ერთი მონაცემთა ბაზა თითოეული AG-სთვის, მაქსიმუმ ორი რეპლიკა და წასაკითხი მეორადი მხარდაჭერის არარსებობა. FCI ხელმისაწვდომია სტანდარტულ გამოცემაში ამ შეზღუდვების გარეშე. სრული Always On ფუნქციონალურობისთვის საჭიროა Enterprise Edition.

კითხვა: რა არის რეპლიკების მაქსიმალური რაოდენობა ხელმისაწვდომობის ჯგუფში?

A: SQL Server Enterprise Edition მხარს უჭერს ცხრა რეპლიკას: ერთ ძირითადს და რვა მეორადს. განაწილებული ხელმისაწვდომობის ჯგუფების გამოყენებით შესაძლებელია ამ რაოდენობის 18 რეპლიკამდე გაფართოება ორ ცალკეულ ხელმისაწვდომობის ჯგუფში.

კითხვა: შეუძლიათ თუ არა FCI-ის მიერ ჰოსტირებულ რეპლიკებს ავტომატური AG გადამისამართების გამოყენება?

A: არა. როდესაც ხელმისაწვდომობის რეპლიკა განთავსებულია Failover Cluster-ის ეგზემპლარზე, ხელმისაწვდომობის ჯგუფის ავტომატური failover ამ რეპლიკისთვის მხარდაჭერილი არ არის. FCI-ის მიერ ჰოსტირებულ რეპლიკებთან დაკავშირებული ყველა AG failover მოითხოვს ხელით ჩარევას.

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

A: სინქრონული დადასტურების რეჟიმი მოითხოვს, რომ პირველადმა მოდულმა დაელოდოს მეორადი მოდულიდან ლოგის ჩანაწერების გამყარებას დადასტურებამდე, რაც უზრუნველყოფს მონაცემთა ნულოვან დაკარგვას (RPO = 0) დამატებითი ჩაწერის შეყოვნების ხარჯზე. ასინქრონული დადასტურების რეჟიმი საშუალებას აძლევს პირველად მოდულს დაადასტურებინოს ლოდინის გარეშე, რაც ამცირებს შეყოვნებას, მაგრამ ქმნის მონაცემთა დაკარგვის რისკს, თუ პირველადი მოდული ვერ შეძლებს ყველა ლოგის ჩანაწერის მიღებამდე. გამოიყენეთ სინქრონული რეჟიმი ლოკალური HA რეპლიკებისთვის და ასინქრონული რეჟიმი შორეული DR რეპლიკებისთვის.

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

A: სინქრონული AG რეპლიკისთვის ავტომატური გადართვა ჩვეულებრივ 30 წამზე ნაკლებ დროში სრულდება ნორმალურ პირობებში. FCI გადართვას, როგორც წესი, 20–60 წამი სჭირდება, მონაცემთა ბაზის აღდგენის დროის მიხედვით. ფაქტობრივი ხანგრძლივობა დამოკიდებულია სამუშაო დატვირთვაზე, მონაცემთა ბაზის ზომაზე და WSFC-ში კონფიგურირებულ ჯანმრთელობის შემოწმების დროის ამოწურვის პარამეტრებზე.

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

A: არსებული კავშირები წყდება, როდესაც ხდება failover. აპლიკაციები, რომლებიც იყენებენ ხელმისაწვდომობის ჯგუფის მსმენელს და მოიცავს კავშირის ხელახალი ცდის ლოგიკას, ავტომატურად უერთდებიან ახალ პირველად კავშირს failover-ის დასრულების შემდეგ. MultiSubnetFailover=True-ს დამატება კავშირის სტრიქონებში აუმჯობესებს ხელახალი დაკავშირების სიჩქარეს მრავალ ქვექსელურ განლაგებაში.

კითხვა: როგორ უნდა გავაკეთო განაცხადი? SQL Server მინიმალური შეფერხების მქონე პატჩები Always On გარემოში?

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

კითხვა: შემიძლია გავაერთიანო Always On Availability ჯგუფები Failover Cluster-ის ეგზემპლარებთან?

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

კითხვა: რა უნდა გავაკეთო, თუ ჩემი მონაცემთა ბაზა დაზიანდება Always On გარემოში?

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

კითხვა: როგორ შეედრება „ყოველთვის ხელმისაწვდომი ჯგუფები“ ძველ ჯგუფებს? SQL Server HA გადაწყვეტილებები?

A: AG ცვლის ძველ ტექნოლოგიებს, როგორიცაა მორების გადაზიდვა მდე რეპლიკაციაჟურნალის გაგზავნა მოითხოვს ხელით გადართვას და არ აქვს როლების ავტომატური გადასვლა; რეპლიკაცია შექმნილია მონაცემთა განაწილებისთვის და არა HA-სთვის. AG უზრუნველყოფს ავტომატურ გადართვას, ნულოვან მონაცემთა დაკარგვას სინქრონული დადასტურებით და წაკითხვად მეორად სისტემებს — შესაძლებლობებს, რომელთა შედარებაც ტექნოლოგიებს არ შეუძლიათ.

8. დასკვნა

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

რომელ გადაწყვეტასაც არ უნდა აირჩევდეთ, ძირითადი პრინციპები იგივეა: ჯერ განსაზღვრეთ თქვენი RTO და RPO მოთხოვნები, შეიმუშავეთ თქვენი ტოპოლოგია ამ მიზნების გარშემო და რეგულარულად შეამოწმეთ ჩავარდნის რეჟიმი. კარგად დანერგილი Always On გადაწყვეტა, რომელიც საფუძვლიანად არის გამოცდილი, პროგნოზირებად აღდგება წარმოების ხარვეზების შემთხვევაში.

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

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

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

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

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