შეცდომის ტოლერანტული გადაწყვეტის შექმნა Oracle RAC და AccelStor Shared-Nothing არქიტექტურაზე დაფუძნებული

Enterprise აპლიკაციებისა და ვირტუალიზაციის სისტემების მნიშვნელოვან რაოდენობას აქვს საკუთარი მექანიზმები შეცდომის ტოლერანტული გადაწყვეტილებების შესაქმნელად. კონკრეტულად, Oracle RAC (Oracle Real Application Cluster) არის ორი ან მეტი Oracle მონაცემთა ბაზის სერვერის კლასტერი, რომლებიც ერთად მუშაობენ დატვირთვის დასაბალანსებლად და სერვერის/აპლიკაციის დონეზე შეცდომების ტოლერანტობის უზრუნველსაყოფად. ამ რეჟიმში მუშაობისთვის გჭირდებათ საერთო საცავი, რომელიც, როგორც წესი, არის შენახვის სისტემა.

როგორც უკვე განვიხილეთ ერთ-ერთ ჩვენს სტატიებითავად შენახვის სისტემას, მიუხედავად დუბლირებული კომპონენტების (მათ შორის კონტროლერების) არსებობისა, მაინც აქვს წარუმატებლობის წერტილები - ძირითადად მონაცემთა ერთი ნაკრების სახით. ამიტომ, Oracle-ის გადაწყვეტის შესაქმნელად გაზრდილი სანდოობის მოთხოვნებით, უნდა გართულდეს სქემა "N სერვერები - ერთი შენახვის სისტემა".

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

ეს კაბინეტები უნდა შეიცავდეს აღჭურვილობისა და პროგრამული უზრუნველყოფის მთელ აუცილებელ კომპლექტს, რომელიც საშუალებას მისცემს Oracle-ის მონაცემთა ბაზების მუშაობას „მეზობლის“ მდგომარეობის მიუხედავად. სხვა სიტყვებით რომ ვთქვათ, Cross-Rack კატასტროფის აღდგენის გადაწყვეტის გამოყენებით, ჩვენ აღმოვფხვრით წარუმატებლობის რისკებს:

• Oracle აპლიკაციის სერვერები
• შენახვის სისტემები
• გადართვის სისტემები
• კაბინეტში არსებული ყველა აღჭურვილობის სრული უკმარისობა:
  • დენის უკმარისობა
  • გაგრილების სისტემის გაუმართაობა
  • გარე ფაქტორები (ადამიანი, ბუნება და ა.შ.)

Oracle სერვერების დუბლირება გულისხმობს Oracle RAC-ის მუშაობის პრინციპს და ხორციელდება აპლიკაციის საშუალებით. გადართვის ობიექტების დუბლირება ასევე არ არის პრობლემა. მაგრამ შენახვის სისტემის დუბლირებასთან ერთად, ყველაფერი არც ისე მარტივია.

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

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

AccelStor NeoSapphire™ All Flash მასივის გადაწყვეტა შესანიშნავია ისეთი სცენარებისთვის, როგორიცაა Cross-Rack კატასტროფის აღდგენა H710 Shared-Nothing არქიტექტურის გამოყენებით. ეს მოდელი არის ორკვანძიანი შენახვის სისტემა, რომელიც იყენებს საკუთრების FlexiRemap® ტექნოლოგიას ფლეშ დრაივებთან მუშაობისთვის. მადლობა FlexiRemap® NeoSapphire™ H710-ს შეუძლია უზრუნველყოს 600K IOPS@4K შემთხვევითი ჩაწერა და 1M+ IOPS@4K შემთხვევითი წაკითხვა, რაც მიუწვდომელია კლასიკური RAID-ზე დაფუძნებული შენახვის სისტემების გამოყენებისას.

მაგრამ NeoSapphire™ H710-ის მთავარი მახასიათებელია ორი კვანძის შესრულება ცალკეული შემთხვევების სახით, რომელთაგან თითოეულს აქვს მონაცემთა საკუთარი ასლი. კვანძების სინქრონიზაცია ხორციელდება გარე InfiniBand ინტერფეისის საშუალებით. ამ არქიტექტურის წყალობით, შესაძლებელია კვანძების განაწილება სხვადასხვა ადგილას 100 მ-მდე მანძილზე, რითაც უზრუნველყოფს Cross-Rack კატასტროფის აღდგენის გადაწყვეტას. ორივე კვანძი მუშაობს სრულიად სინქრონულად. მასპინძლის მხრიდან, H710 ჰგავს ჩვეულებრივი ორმაგი კონტროლერის შენახვის სისტემას. ამიტომ, არ არის საჭირო რაიმე დამატებითი პროგრამული უზრუნველყოფის ან აპარატურის პარამეტრების ან განსაკუთრებით რთული პარამეტრების შესრულება.

თუ შევადარებთ ზემოთ აღწერილ Cross-Rack კატასტროფის აღდგენის გადაწყვეტილებებს, მაშინ AccelStor-ის ვარიანტი შესამჩნევად გამოირჩევა დანარჩენისგან:

AccelStor NeoSapphire™ გაზიარებული არაფერი არქიტექტურა
პროგრამული უზრუნველყოფის ან ტექნიკის "ვირტუალიზატორის" შენახვის სისტემა
რეპლიკაციაზე დაფუძნებული ხსნარი

ხელმისაწვდომობა

სერვერის უკმარისობა
დაყოვნება არ არის
დაყოვნება არ არის
დაყოვნება არ არის

გადამრთველის უკმარისობა
დაყოვნება არ არის
დაყოვნება არ არის
დაყოვნება არ არის

შენახვის სისტემის უკმარისობა
დაყოვნება არ არის
დაყოვნება არ არის
Downtime

კაბინეტის სრული მარცხი
დაყოვნება არ არის
დაყოვნება არ არის
Downtime

ღირებულება და სირთულე

გადაწყვეტის ღირებულება
დაბალი*
მაღალი
მაღალი

განლაგების სირთულე
დაბალი
მაღალი
მაღალი

*AccelStor NeoSapphire™ ჯერ კიდევ არის All Flash მასივი, რომელიც განსაზღვრულად არ ღირს "3 კაპიკი", მით უმეტეს, რომ მას აქვს ორმაგი სიმძლავრის რეზერვი. თუმცა, მასზე დაფუძნებული გადაწყვეტის საბოლოო ღირებულების შედარებისას სხვა მოვაჭრეების მსგავსებთან, ღირებულება შეიძლება ჩაითვალოს დაბალი.

აპლიკაციის სერვერებისა და ყველა Flash მასივის კვანძის დამაკავშირებელი ტოპოლოგია ასე გამოიყურება:

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

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

მოსამზადებელი სამუშაოები მასივზე

გამოყენებული აღჭურვილობა და პროგრამული უზრუნველყოფა

სერვერისა და გადამრთველის სპეციფიკაციები

კომპონენტები
აღწერა

Oracle Database 11g სერვერები
ორი

სერვერის ოპერაციული სისტემა
Oracle Linux

Oracle მონაცემთა ბაზის ვერსია
11 გ (RAC)

პროცესორები თითო სერვერზე
ორი 16 ბირთვიანი Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz

ფიზიკური მეხსიერება თითო სერვერზე
128GB

FC ქსელი
16 გბ/წმ FC ერთად multipathing

FC HBA
Emulex Lpe-16002B

გამოყოფილი საჯარო 1GbE პორტები კლასტერების მართვისთვის
Intel Ethernet ადაპტერი RJ45

16 გბ/წმ FC გადამრთველი
ბროკადი 6505

გამოყოფილი პირადი 10 GbE პორტები მონაცემთა სინქრონიზაციისთვის
Intel X520

AccelStor NeoSapphire™ ყველა ფლეშ მასივის სპეციფიკაცია

კომპონენტები
აღწერა

შენახვის სისტემა
NeoSapphire™ მაღალი ხელმისაწვდომობის მოდელი: H710

გამოსახულების ვერსია
4.0.1

დისკების საერთო რაოდენობა
48

დისკის ზომა
1.92TB

გამგზავნის ტიპი
SSD

FC სამიზნე პორტები
16 x 16 გბ პორტები (8 კვანძზე)

მართვის პორტები
1GbE ეთერნეტის კაბელი, რომელიც უკავშირდება ჰოსტებს ეთერნეტის გადამრთველის მეშვეობით

გულისცემის პორტი
1GbE ეთერნეტის კაბელი, რომელიც აკავშირებს ორ შესანახ კვანძს შორის

მონაცემთა სინქრონიზაციის პორტი
56 გბ/წმ InfiniBand კაბელი

სანამ მასივის გამოყენებას შეძლებთ, თქვენ უნდა მოაწყოთ იგი. ნაგულისხმევად, ორივე კვანძის საკონტროლო მისამართი იგივეა (192.168.1.1). თქვენ უნდა დაუკავშირდეთ მათ სათითაოდ და დააყენოთ ახალი (უკვე განსხვავებული) მართვის მისამართები და დააყენოთ დროის სინქრონიზაცია, რის შემდეგაც მენეჯმენტის პორტები შეიძლება დაუკავშირდეს ერთ ქსელს. ამის შემდეგ, კვანძები გაერთიანებულია HA წყვილში Interlink კავშირებისთვის ქვექსელების მინიჭებით.

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

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

რეკომენდირებულია Oracle ASM-ისთვის მრავალი ტომის შექმნა, რადგან ეს გაზრდის სერვერების სამიზნეების რაოდენობას, რაც საბოლოოდ გააუმჯობესებს მთლიან მუშაობას (უფრო მეტი რიგის შესახებ სხვაში მუხლი).

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

შენახვის მოცულობის სახელი
მოცულობის ზომა

მონაცემები 01
200GB

მონაცემები 02
200GB

მონაცემები 03
200GB

მონაცემები 04
200GB

მონაცემები 05
200GB

მონაცემები 06
200GB

მონაცემები 07
200GB

მონაცემები 08
200GB

მონაცემები 09
200GB

მონაცემები 10
200GB

Grid01
1GB

Grid02
1GB

Grid03
1GB

Grid04
1GB

Grid05
1GB

Grid06
1GB

Redo01
100GB

Redo02
100GB

Redo03
100GB

Redo04
100GB

Redo05
100GB

Redo06
100GB

Redo07
100GB

Redo08
100GB

Redo09
100GB

Redo10
100GB

ზოგიერთი ახსნა მასივის მუშაობის რეჟიმებისა და საგანგებო სიტუაციებში მიმდინარე პროცესების შესახებ

თითოეული კვანძის მონაცემთა ნაკრებს აქვს „ვერსიის ნომერი“ პარამეტრი. საწყისი ინიციალიზაციის შემდეგ ის იგივეა და უდრის 1-ს. თუ რაიმე მიზეზით ვერსიის ნომერი განსხვავებულია, მაშინ მონაცემები ყოველთვის სინქრონიზდება ძველი ვერსიიდან უმცროსთან, რის შემდეგაც ხდება უმცროსი ვერსიის რიცხვის გასწორება, ე.ი. ეს ნიშნავს, რომ ასლები იდენტურია. მიზეზები, რის გამოც ვერსიები შეიძლება იყოს განსხვავებული:

• ერთ-ერთი კვანძის დაგეგმილი გადატვირთვა
• ავარია ერთ-ერთ კვანძზე უეცარი გათიშვის გამო (დენის მიწოდება, გადახურება და ა.შ.).
• დაიკარგა InfiniBand კავშირი სინქრონიზაციის შეუძლებლობით
• ავარია ერთ-ერთ კვანძზე მონაცემთა კორუფციის გამო. აქ დაგჭირდებათ ახალი HA ჯგუფის შექმნა და მონაცემთა ნაკრების სრული სინქრონიზაცია.

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

თუ კავშირი Ethernet ბმულზე დაიკარგება, Heartbeat დროებით გადადის InfiniBand-ზე და დაბრუნდება 10 წამში, როდესაც ის აღდგება.

მასპინძლების დაყენება

შეცდომების ტოლერანტობის უზრუნველსაყოფად და მუშაობის გასაუმჯობესებლად, თქვენ უნდა ჩართოთ MPIO მხარდაჭერა მასივისთვის. ამისათვის თქვენ უნდა დაამატოთ ხაზები /etc/multipath.conf ფაილში და შემდეგ გადატვირთოთ მრავალმხრივი სერვისი.

დამალული ტექსტიმოწყობილობები {
მოწყობილობა {
გამყიდველი "AStor"
path_grouping_policy "group_by_prio"
path_selector "რიგ-სიგრძე 0"
path_checker "tur"
მახასიათებლები "0"
hardware_handler "0"
პრიო "კონსტ"
მარცხი დაუყოვნებლივ
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names დიახ
detect_prio დიახ
rr_min_io_rq 1
no_path_retry 0
}
}

შემდეგი, იმისათვის, რომ ASM-მ იმუშაოს MPIO-სთან ASMLib-ის საშუალებით, თქვენ უნდა შეცვალოთ /etc/sysconfig/oracleasm ფაილი და შემდეგ გაუშვათ /etc/init.d/oracleasm scandisks.

დამალული ტექსტი

# ORACLEASM_SCANORDER: შაბლონების შესატყვისი დისკის სკანირების შეკვეთისთვის
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: შესაბამისი შაბლონები დისკების სკანირებიდან გამოსარიცხად
ORACLEASM_SCANEXCLUDE="sd"

შენიშვნა

თუ არ გსურთ გამოიყენოთ ASMLib, შეგიძლიათ გამოიყენოთ UDEV წესები, რომლებიც ASMLib-ის საფუძველია.

Oracle Database-ის 12.1.0.2 ვერსიიდან დაწყებული, ვარიანტი ხელმისაწვდომია ინსტალაციისთვის, როგორც ASMFD პროგრამული უზრუნველყოფის ნაწილი.

აუცილებელია იმის უზრუნველყოფა, რომ Oracle ASM-ისთვის შექმნილი დისკები შეესაბამება ბლოკის ზომას, რომლითაც მასივი ფიზიკურად მუშაობს (4K). წინააღმდეგ შემთხვევაში, შეიძლება წარმოიშვას მუშაობის პრობლემები. აქედან გამომდინარე, აუცილებელია ტომების შექმნა შესაბამისი პარამეტრებით:

გაყოფილი /dev/mapper/device-name mklabel gpt mkpart პირველადი 2048s 100% გასწორება-შემოწმება ოპტიმალური 1

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

შენახვის მოცულობის სახელი
მოცულობის ზომა
მოცულობის LUN-ების რუქა
ASM მოცულობის მოწყობილობის დეტალი
განაწილების ერთეულის ზომა

მონაცემები 01
200GB
საცავის ყველა მოცულობის რუკა მონაცემთა შენახვის სისტემის ყველა პორტში
ჭარბი რაოდენობა: ნორმალური
სახელი: DGDATA
დანიშნულება: მონაცემთა ფაილები

4MB

მონაცემები 02
200GB

მონაცემები 03
200GB

მონაცემები 04
200GB

მონაცემები 05
200GB

მონაცემები 06
200GB

მონაცემები 07
200GB

მონაცემები 08
200GB

მონაცემები 09
200GB

მონაცემები 10
200GB

Grid01
1GB
ჭარბი რაოდენობა: ნორმალური
დასახელება: DGGRID1
მიზანი: ბადე: CRS და ხმის მიცემა

4MB

Grid02
1GB

Grid03
1GB

Grid04
1GB
ჭარბი რაოდენობა: ნორმალური
დასახელება: DGGRID2
მიზანი: ბადე: CRS და ხმის მიცემა

4MB

Grid05
1GB

Grid06
1GB

Redo01
100GB
ჭარბი რაოდენობა: ნორმალური
დასახელება: DGREDO1
მიზანი: ძაფის ჟურნალის გამეორება 1

4MB

Redo02
100GB

Redo03
100GB

Redo04
100GB

Redo05
100GB

Redo06
100GB
ჭარბი რაოდენობა: ნორმალური
დასახელება: DGREDO2
მიზანი: ძაფის ჟურნალის გამეორება 2

4MB

Redo07
100GB

Redo08
100GB

Redo09
100GB

Redo10
100GB

მონაცემთა ბაზის პარამეტრები

• ბლოკის ზომა = 8K
• სივრცის შეცვლა = 16 GB
• გამორთეთ AMM (მეხსიერების ავტომატური მართვა)
• გამორთეთ გამჭვირვალე უზარმაზარი გვერდები

სხვა პარამეტრები

# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ kernel.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # არ დააყენოთ ეს, თუ იყენებთ Linux x86-ს
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000

# vi /etc/security/limits.conf
✓ ბადე რბილი nproc 2047
✓ მძიმე ბადე nproc 16384
✓ ბადე რბილი nofile 1024
✓ grid hard nofile 65536
✓ ბადე რბილი დასტა 10240
✓ ბადე მყარი დასტა 32768
✓ Oracle soft nproc 2047
✓ Oracle hard nproc 16384
✓ Oracle soft nofile 1024
✓ Oracle hard nofile 65536
✓ Oracle soft stack 10240
✓ Oracle hard stack 32768
✓ რბილი მემლოკი 120795954
✓ მყარი მემლოკი 120795954

sqlplus "/as sysdba"
შეცვალოს სისტემის ნაკრები პროცესები=2000 scope=spfile;
სისტემის ნაკრების შეცვლა open_cursors=2000 scope=spfile;
სისტემის ნაკრების შეცვლა session_cached_cursors=300 scope=spfile;
სისტემური ნაკრების შეცვლა db_files=8192 scope=spfile;

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

სადემონსტრაციო მიზნებისთვის, HammerDB გამოიყენებოდა OLTP დატვირთვის ემულაციისთვის. HammerDB კონფიგურაცია:

საწყობების რაოდენობა
256

სულ ტრანზაქციები თითო მომხმარებლისთვის
1000000000000

ვირტუალური მომხმარებლები
256

შედეგი იყო 2.1M TPM, რაც შორს არის მასივის შესრულების ლიმიტისაგან H710, მაგრამ არის "ჭერი" სერვერების ამჟამინდელი ტექნიკის კონფიგურაციისთვის (პირველ რიგში, პროცესორების გამო) და მათი ნომრისთვის. ამ ტესტის მიზანი მაინც არის მთლიანად გამოსავლის ხარვეზების ტოლერანტობის დემონსტრირება და არა მაქსიმალური შესრულების მიღწევა. ამიტომ, ჩვენ უბრალოდ ავაშენებთ ამ ფიგურას.

ტესტი ერთ-ერთი კვანძის წარუმატებლობისთვის

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

კაბინეტის უკმარისობის ტესტი ყველა აღჭურვილობით

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

თუ საჭიროა Oracle-ისთვის შეცდომის შემწყნარებელი Cross-Rack კატასტროფის აღდგენის გადაწყვეტის დანერგვა გონივრულ ფასად და მცირე განლაგების/ადმინისტრაციის ძალისხმევით, მაშინ Oracle RAC და არქიტექტურა ერთად მუშაობენ. AccelStor გაზიარებული-არაფერი იქნება ერთ-ერთი საუკეთესო ვარიანტი. Oracle RAC-ის ნაცვლად, შეიძლება იყოს ნებისმიერი სხვა პროგრამული უზრუნველყოფა, რომელიც უზრუნველყოფს კლასტერირებას, იგივე DBMS ან ვირტუალიზაციის სისტემები, მაგალითად. ხსნარის აგების პრინციპი იგივე დარჩება. და ქვედა ხაზი არის ნულოვანი RTO და RPO.

წყარო: www.habr.com