ადმინი ხელების გარეშე = ჰიპერკონვერგენცია?

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

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

გამოდის, რომ დაყენების სიმარტივისთვის იხდით 10-15%-ით მეტს. სწორედ ამან გამოიწვია მითი სათაურში. ჩვენ დიდხანს ვეძებდით, თუ სად იქნებოდა ოპტიმალურად გამოყენებული ტექნოლოგია და ვიპოვეთ იგი. ფაქტია, რომ Cisco-ს არ ჰქონდა საკუთარი შენახვის სისტემები, მაგრამ მათ სურდათ სერვერების სრული ბაზარი. და მათ შექმნეს Cisco Hyperflex - გადაწყვეტა ლოკალური შენახვით კვანძებზე.

და ეს მოულოდნელად აღმოჩნდა ძალიან კარგი გამოსავალი სარეზერვო მონაცემთა ცენტრებისთვის (Disaster Recovery). ახლა გეტყვით რატომ და როგორ. და მე გაჩვენებთ კლასტერულ ტესტებს.

სადაც საჭიროა

ჰიპერკონვერგენცია არის:

1. დისკების გადატანა გამოთვლით კვანძებში.
2. შენახვის ქვესისტემის სრული ინტეგრაცია ვირტუალიზაციის ქვესისტემასთან.
3. ქსელის ქვესისტემასთან გადატანა/ინტეგრაცია.

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

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

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

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

ტესტები

ჩვენი მაგალითი შედგება ოთხი სერვერისგან, რომელთაგან თითოეულს აქვს 10 SSD დისკი 960 GB. არის გამოყოფილი დისკი ჩაწერის ოპერაციების ქეშირებისთვის და სერვისის ვირტუალური მანქანის შესანახად. გამოსავალი თავისთავად მეოთხე ვერსიაა. პირველი არის გულწრფელად უხეში (მიმოხილვებით ვიმსჯელებთ), მეორე ნესტიანია, მესამე უკვე საკმაოდ სტაბილურია და ამას შეიძლება ეწოდოს გამოშვება ფართო საზოგადოებისთვის ბეტა ტესტირების დასრულების შემდეგ. ტესტირების დროს მე ვერ ვნახე პრობლემა, ყველაფერი მუშაობს საათის მსგავსად.

ცვლილებები v4-შიგამოსწორდა შეცდომების მთელი რიგი.

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

ახლა ბავშვობის ყველა პრობლემა მოგვარებულია, HyperFlex-ს შეუძლია გაუმკლავდეს როგორც ESXi-ს, ასევე Hyper-V-ს, ასევე შესაძლებელია:

1. დაჭიმული მტევნის შექმნა.
2. ოფისებისთვის კლასტერის შექმნა Fabric Interconnect-ის გამოყენების გარეშე, ორიდან ოთხ კვანძამდე (ვყიდულობთ მხოლოდ სერვერებს).
3. გარე შენახვის სისტემებთან მუშაობის უნარი.
4. კონტეინერებისა და კუბერნეტების მხარდაჭერა.
5. ხელმისაწვდომობის ზონების შექმნა.
6. ინტეგრაცია VMware SRM-თან, თუ ჩაშენებული ფუნქციონირება არ არის დამაკმაყოფილებელი.

არქიტექტურა დიდად არ განსხვავდება მისი მთავარი კონკურენტების გადაწყვეტილებებისგან, მათ არ შექმნეს ველოსიპედი. ეს ყველაფერი მუშაობს VMware ან Hyper-V ვირტუალიზაციის პლატფორმაზე. აპარატურა განთავსებულია საკუთრებაში არსებულ Cisco UCS სერვერებზე. არიან ისეთებიც, რომლებსაც სძულთ პლატფორმა საწყისი დაყენების შედარებით სირთულის გამო, ბევრი ღილაკი, შაბლონებისა და დამოკიდებულებების არატრივიალური სისტემა, მაგრამ არიან ისეთებიც, ვინც ისწავლეს ზენი, შთაგონებულია იდეით და აღარ სურთ. სხვა სერვერებთან მუშაობისთვის.

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

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

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

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

სპეციალური სერვისის VM Cisco HyperFlex მონაცემთა პლატფორმის კონტროლერი, რომელიც იქმნება თითოეულ საცავის კვანძზე, პასუხისმგებელია დისკის ქვესისტემის მთელი ოპერაციის ლოგიკაზე. ჩვენი სერვისის VM კონფიგურაციაში გამოიყო რვა vCPU და 72 GB ოპერატიული მეხსიერება, რაც არც ისე ცოტაა. შეგახსენებთ, რომ თავად ჰოსტს აქვს 28 ფიზიკური ბირთვი და 512 GB ოპერატიული მეხსიერება.

სერვის VM-ს აქვს წვდომა ფიზიკურ დისკებზე პირდაპირ SAS კონტროლერის VM-ზე გადამისამართებით. ჰიპერვიზორთან კომუნიკაცია ხდება სპეციალური მოდულის IOVisor-ის საშუალებით, რომელიც წყვეტს I/O ოპერაციებს და აგენტის გამოყენებით, რომელიც საშუალებას გაძლევთ გაგზავნოთ ბრძანებები ჰიპერვიზორის API-ზე. აგენტი პასუხისმგებელია HyperFlex სნეპშოტებთან და კლონებთან მუშაობაზე.

დისკის რესურსები დამონტაჟებულია ჰიპერვიზორში NFS ან SMB აქციების სახით (ჰიპერვიზორის ტიპის მიხედვით, გამოიცანით რომელი სად არის). და ქუდის ქვეშ, ეს არის განაწილებული ფაილური სისტემა, რომელიც საშუალებას გაძლევთ დაამატოთ ზრდასრული სრულფასოვანი შენახვის სისტემების ფუნქციები: თხელი მოცულობის განაწილება, შეკუმშვა და დუბლირება, სნეპშოტები Redirect-on-Write ტექნოლოგიის გამოყენებით, სინქრონული/ასინქრონული რეპლიკაცია.

სერვისი VM უზრუნველყოფს წვდომას HyperFlex ქვესისტემის WEB მართვის ინტერფეისზე. არის vCenter-თან ინტეგრაცია და მისგან შესაძლებელია ყოველდღიური დავალებების უმეტესობის შესრულება, მაგრამ მონაცემთა მაღაზიები, მაგალითად, უფრო მოსახერხებელია ცალკე ვებკამერიდან ამოღება, თუ უკვე გადაერთეთ სწრაფ HTML5 ინტერფეისზე, ან იყენებთ სრულფასოვან Flash კლიენტს. სრული ინტეგრაციით. სერვისის ვებკამერაში შეგიძლიათ ნახოთ სისტემის მუშაობა და დეტალური სტატუსი.

კლასტერში არის სხვა ტიპის კვანძი - გამოთვლითი კვანძები. ეს შეიძლება იყოს rack ან blade სერვერები ჩაშენებული დისკების გარეშე. ამ სერვერებს შეუძლიათ იმუშაონ VM-ები, რომელთა მონაცემები ინახება სერვერებზე დისკებით. მონაცემთა წვდომის თვალსაზრისით, კვანძების ტიპებს შორის განსხვავება არ არის, რადგან არქიტექტურა გულისხმობს მონაცემთა ფიზიკური მდებარეობიდან აბსტრაქციას. გამოთვლითი კვანძების მაქსიმალური თანაფარდობა შენახვის კვანძებთან არის 2:1.

გამოთვლითი კვანძების გამოყენება ზრდის მოქნილობას კლასტერული რესურსების სკალირებისას: ჩვენ არ გვჭირდება დამატებითი კვანძების ყიდვა დისკებით, თუ გვჭირდება მხოლოდ CPU/RAM. გარდა ამისა, ჩვენ შეგვიძლია დავამატოთ blade cage და დაზოგოთ სერვერების თაროების განთავსება.

შედეგად, ჩვენ გვაქვს ჰიპერკონვერგირებული პლატფორმა შემდეგი მახასიათებლებით:

• 64-მდე კვანძი კლასტერში (32-მდე შესანახი კვანძი).
• კვანძების მინიმალური რაოდენობა კლასტერში არის სამი (ორი Edge კლასტერისთვის).
• მონაცემთა გადაჭარბების მექანიზმი: ასახვა რეპლიკაციის ფაქტორებით 2 და 3.
• მეტროს კლასტერი.
• ასინქრონული VM რეპლიკაცია სხვა HyperFlex კლასტერზე.
• VM-ების გადართვის ორკესტრირება დისტანციურ მონაცემთა ცენტრში.
• მშობლიური სნეპშოტები გადამისამართების ჩაწერის ტექნოლოგიის გამოყენებით.
• 1 PB-მდე გამოსაყენებელი სივრცე რეპლიკაციის ფაქტორზე 3 და დედუპლიკაციის გარეშე. ჩვენ არ გავითვალისწინებთ რეპლიკაციის ფაქტორ 2-ს, რადგან ეს არ არის სერიოზული გაყიდვების ვარიანტი.

კიდევ ერთი დიდი პლიუსი არის მართვისა და განლაგების სიმარტივე. UCS სერვერების დაყენების ყველა სირთულეზე ზრუნავს სპეციალიზებული VM, რომელიც მომზადებულია Cisco-ს ინჟინრების მიერ.

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

• 2 x Cisco UCS Fabric Interconnect 6248UP, როგორც მართვის კლასტერი და ქსელის კომპონენტები (48 პორტი მუშაობს Ethernet 10G/FC 16G რეჟიმში).
• ოთხი Cisco UCS HXAF240 M4 სერვერი.

სერვერის მახასიათებლები:

CPU

2 x Intel® Xeon® E5-2690 v4

RAM

16 x 32 გბ DDR4-2400-MHz RDIMM/PC4-19200/ორმაგი რანგი/x4/1.2v

ქსელი

UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet პორტი

შენახვის HBA

Cisco 12G Modular SAS-ის კონტროლერი გადის

შესანახი დისკები

1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB

მეტი კონფიგურაციის პარამეტრებიშერჩეული აპარატურის გარდა, ამჟამად ხელმისაწვდომია შემდეგი პარამეტრები:

• HXAF240c M5.
• ერთი ან ორი CPU დაწყებული Intel Silver 4110-დან Intel Platinum I8260Y-მდე. ხელმისაწვდომია მეორე თაობა.
• მეხსიერების 24 სლოტი, ზოლები 16 GB RDIMM 2600-დან 128 GB LRDIMM 2933-მდე.
• 6-დან 23 მონაცემთა დისკამდე, ერთი ქეშირების დისკი, ერთი სისტემის დისკი და ერთი ჩატვირთვის დისკი.

ტევადობის დისკები

• HX-SD960G61X-EV 960GB 2.5 Inch Enterprise Value 6G SATA SSD (1X გამძლეობა) SAS 960 GB.
• HX-SD38T61X-EV 3.8TB 2.5 inch Enterprise Value 6G SATA SSD (1X გამძლეობა) SAS 3.8 TB.
• დისკების ქეშირება
• HX-NVMEXPB-I375 375GB 2.5 დიუმიანი Intel Optane Drive, Extreme Perf & Endurance.
• HX-NVMEHW-H1600* 1.6TB 2.5 inch Ent. პერფ. NVMe SSD (3X გამძლეობა) NVMe 1.6 ტბ.
• HX-SD400G12TX-EP 400GB 2.5 დიუმიანი ენტ. პერფ. 12G SAS SSD (10X გამძლეობა) SAS 400 GB.
• HX-SD800GBENK9** 800GB 2.5 დიუმიანი ენტ. პერფ. 12G SAS SED SSD (10X გამძლეობა) SAS 800 GB.
• HX-SD16T123X-EP 1.6TB 2.5 inch Enterprise performance 12G SAS SSD (3X გამძლეობა).

სისტემის/ლოგის დისკები

• HX-SD240GM1X-EV 240GB 2.5 დიუმიანი საწარმოს ღირებულება 6G SATA SSD (მოითხოვს განახლებას).

ჩატვირთვის დისკები

• HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.

დაუკავშირდით ქსელს 40G, 25G ან 10G Ethernet პორტების მეშვეობით.

FI შეიძლება იყოს HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).

თავად ტესტი

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

ჩვენი კლასტერი შედგება ოთხი კვანძისგან, რეპლიკაციის ფაქტორი 3, ყველა დისკი არის Flash.

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

ტესტის შედეგები ასეთია:

100% წაკითხული 100% შემთხვევითი

0% წაკითხული 100% შემთხვევითი

ბლოკის / რიგის სიღრმე

128

256

512

1024

2048

128

256

512

1024

2048

4K

0,59 ms 213804 IOPS

0,84 ms 303540 IOPS

1,36ms 374348 IOPS

2.47 ms 414116 IOPS

4,86ms 420180 IOPS

2,22 ms 57408 IOPS

3,09 ms 82744 IOPS

5,02 ms 101824 IPOS

8,75 ms 116912 IOPS

17,2 ms 118592 IOPS

8K

0,67 ms 188416 IOPS

0,93 ms 273280 IOPS

1,7 ms 299932 IOPS

2,72 ms 376,484 IOPS

5,47 ms 373,176 IOPS

3,1 ms 41148 IOPS

4,7 ms 54396 IOPS

7,09 ms 72192 IOPS

12,77 ms 80132 IOPS

16K

0,77 ms 164116 IOPS

1,12 ms 228328 IOPS

1,9 ms 268140 IOPS

3,96 ms 258480 IOPS

3,8 ms 33640 IOPS

6,97 ms 36696 IOPS

11,35 ms 45060 IOPS

32K

1,07 ms 119292 IOPS

1,79 ms 142888 IOPS

3,56 ms 143760 IOPS

7,17 ms 17810 IOPS

11,96 ms 21396 IOPS

64K

1,84 ms 69440 IOPS

3,6 ms 71008 IOPS

7,26 ms 70404 IOPS

11,37 ms 11248 IOPS

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

• თანმიმდევრული წაკითხვა 4432 მბ/წმ.
• თანმიმდევრული ჩაწერა 804 მბ/წმ.
• თუ ერთი კონტროლერი ვერ ხერხდება (ვირტუალური აპარატის ან ჰოსტის გაუმართაობა), შესრულების ვარდნა ორმაგდება.
• თუ შესანახი დისკი ვერ ხერხდება, შემცირება არის 1/3. დისკის აღდგენას თითოეული კონტროლერის რესურსის 5% სჭირდება.

პატარა ბლოკზე ჩვენ შემოიფარგლება კონტროლერის (ვირტუალური აპარატის) მუშაობით, მისი CPU იტვირთება 100%-ით, ხოლო როდესაც ბლოკი იზრდება, შემოიფარგლება პორტის გამტარუნარიანობით. 10 გბიტი/წმ არ არის საკმარისი AllFlash სისტემის პოტენციალის განსაბლოკად. სამწუხაროდ, მოწოდებული დემო სტენდის პარამეტრები არ გვაძლევს 40 გბიტ/წმ-ზე მუშაობის ტესტირების საშუალებას.

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

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

რეალური გამოყენება

სარეზერვო მონაცემთა ცენტრის ორგანიზებისთვის შეგიძლიათ გამოიყენოთ ორი მიდგომა (ჩვენ არ განვიხილავთ სარეზერვო ასლის განთავსებას დისტანციურ საიტზე):

1. Აქტიური პასიური. ყველა აპლიკაცია განთავსებულია მონაცემთა მთავარ ცენტრში. რეპლიკაცია არის სინქრონული ან ასინქრონული. თუ ძირითადი მონაცემთა ცენტრი ვერ ხერხდება, ჩვენ უნდა გავააქტიუროთ სარეზერვო. ეს შეიძლება გაკეთდეს ხელით/სკრიპტები/ორკესტრირების აპლიკაციებით. აქ ჩვენ მივიღებთ რეპლიკაციის სიხშირის შესაბამის RPO-ს და RTO დამოკიდებულია ადმინისტრატორის რეაქციაზე და უნარებზე და გადართვის გეგმის შემუშავების/გამართვის ხარისხზე.
2. აქტიური-აქტიური. ამ შემთხვევაში, არსებობს მხოლოდ სინქრონული რეპლიკაცია; მონაცემთა ცენტრების ხელმისაწვდომობას განსაზღვრავს კვორუმი/არბიტრი, რომელიც მდებარეობს მკაცრად მესამე საიტზე. RPO = 0, და RTO შეიძლება მიაღწიოს 0-ს (თუ აპლიკაცია საშუალებას იძლევა) ან უდრის ვირტუალიზაციის კლასტერში კვანძის ჩავარდნის დროს. ვირტუალიზაციის დონეზე იქმნება დაჭიმული (მეტრო) კლასტერი, რომელიც საჭიროებს Active-Active საცავს.

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

სცენარი 1: ჩვენ გვაქვს პირველადი და სარეზერვო მონაცემთა ცენტრები, ვირტუალიზაციის პლატფორმა VMware vSphere-ზე. ყველა პროდუქტიული სისტემა განლაგებულია მონაცემთა მთავარ ცენტრში და ვირტუალური მანქანების რეპლიკაცია ხორციელდება ჰიპერვიზორის დონეზე, ეს თავიდან აიცილებს სარეზერვო მონაცემთა ცენტრში ჩართული VM-ების შენარჩუნებას. ჩვენ ვიმეორებთ მონაცემთა ბაზებსა და სპეციალურ აპლიკაციებს ჩაშენებული ხელსაწყოების გამოყენებით და ვინარჩუნებთ VM-ებს ჩართულ. თუ ძირითადი მონაცემთა ცენტრი ვერ ხერხდება, ჩვენ გავუშვით სისტემები სარეზერვო მონაცემთა ცენტრში. ჩვენ გვჯერა, რომ გვაქვს 100-მდე ვირტუალური მანქანა. სანამ პირველადი მონაცემთა ცენტრი ფუნქციონირებს, მოლოდინის მონაცემთა ცენტრს შეუძლია აწარმოოს სატესტო გარემო და სხვა სისტემები, რომლებიც შეიძლება დაიხუროს პირველადი მონაცემთა ცენტრის გადართვის შემთხვევაში. ასევე შესაძლებელია გამოვიყენოთ ორმხრივი რეპლიკაცია. ტექნიკის თვალსაზრისით, არაფერი შეიცვლება.

კლასიკური არქიტექტურის შემთხვევაში, ჩვენ დავაყენებთ თითოეულ მონაცემთა ცენტრში ჰიბრიდულ საცავის სისტემას FibreChannel-ის საშუალებით წვდომით, tiering, deduplication და compression (მაგრამ არა ონლაინ), 8 სერვერი თითოეული საიტისთვის, 2 FibreChannel გადამრთველი და 10G Ethernet. რეპლიკაციისა და გადართვის მენეჯმენტისთვის კლასიკურ არქიტექტურაში შეგვიძლია გამოვიყენოთ VMware ინსტრუმენტები (Replication + SRM) ან მესამე მხარის ინსტრუმენტები, რომლებიც ცოტა იაფი და ზოგჯერ მოსახერხებელი იქნება.

ფიგურაში ნაჩვენებია დიაგრამა.

Cisco HyperFlex-ის გამოყენებისას მიიღება შემდეგი არქიტექტურა:

HyperFlex-ისთვის გამოვიყენე სერვერები დიდი CPU/RAM რესურსებით, რადგან... რესურსების ნაწილი გადავა HyperFlex კონტროლერ VM-ზე; CPU-ს და მეხსიერების თვალსაზრისით, HyperFlex-ის კონფიგურაციაც კი ხელახლა დავაკონფიგურირე, რომ არ ვითამაშო Cisco-სთან ერთად და გარანტირებული იყოს რესურსები დარჩენილი VM-ებისთვის. მაგრამ ჩვენ შეგვიძლია მივატოვოთ FibreChannel-ის გადამრთველები და არ დაგვჭირდება Ethernet პორტები თითოეული სერვერისთვის; ადგილობრივი ტრაფიკი გადართულია FI-ში.

შედეგი იყო შემდეგი კონფიგურაცია თითოეული მონაცემთა ცენტრისთვის:

სერვერები

8 x 1U სერვერი (384 GB ოპერატიული მეხსიერება, 2 x Intel Gold 6132, FC HBA)

8 x HX240C-M5L (512 GB ოპერატიული მეხსიერება, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)

შდ

ჰიბრიდული შენახვის სისტემა FC Front-End-ით (20TB SSD, 130 TB NL-SAS)

-

LAN

2 x Ethernet switch 10G 12 პორტი

-

SAN

2 x FC switch 32/16Gb 24 პორტი

2 x Cisco UCS FI 6332

ლიცენზიები

VMware Ent Plus

VM გადართვის რეპლიკაცია და/ან ორკესტრირება

VMware Ent Plus

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

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

Cisco HyperFlex-ის ხსნარი 13%-ით იაფი აღმოჩნდა.

სცენარი 2: ორი აქტიური მონაცემთა ცენტრის შექმნა. ამ სცენარში, ჩვენ ვქმნით დაჭიმულ კლასტერს VMware-ზე.

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

HyperFlex-ში ჩვენ უბრალოდ ვქმნით Stretch Cluster-ს კვანძების იგივე რაოდენობით ორივე საიტზე. ამ შემთხვევაში გამოიყენება რეპლიკაციის ფაქტორი 2+2.

შედეგი არის შემდეგი კონფიგურაცია:

კლასიკური არქიტექტურა

HyperFlex

სერვერები

16 x 1U სერვერი (384 GB ოპერატიული მეხსიერება, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)

16 x HX240C-M5L (512 GB ოპერატიული მეხსიერება, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)

შდ

2 x AllFlash შენახვის სისტემა (150 TB SSD)

-

LAN

4 x Ethernet switch 10G 24 პორტი

-

SAN

4 x FC switch 32/16Gb 24 პორტი

4 x Cisco UCS FI 6332

ლიცენზიები

VMware Ent Plus

VMware Ent Plus

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

ღირებულების მხრივ HyperFlex 5%-ით ძვირი აღმოჩნდა. აქვე უნდა აღინიშნოს, რომ CPU/RAM რესურსების კუთხით, მე მქონდა გადახრა Cisco-სთვის, რადგან კონფიგურაციაში მეხსიერების კონტროლერის არხები თანაბრად შევავსე. ღირებულება ოდნავ მაღალია, მაგრამ არა სიდიდის ბრძანებით, რაც ნათლად მიუთითებს იმაზე, რომ ჰიპერკონვერგენცია სულაც არ არის „სათამაშო მდიდრებისთვის“, მაგრამ შეუძლია კონკურენცია გაუწიოს მონაცემთა ცენტრის მშენებლობის სტანდარტულ მიდგომას. ეს ასევე შეიძლება იყოს დაინტერესებული მათთვის, ვისაც უკვე აქვს Cisco UCS სერვერები და მათთვის შესაბამისი ინფრასტრუქტურა.

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

რაც შეეხება მხარდაჭერას, აქ თქვენ იღებთ მას ერთი გამყიდველისგან - Cisco-სგან. ვიმსჯელებთ Cisco UCS სერვერებთან ჩემი გამოცდილებით, მე მომწონს; არ მომიწია მისი გახსნა HyperFlex-ზე, ყველაფერი ერთნაირად მუშაობდა. ინჟინრები მყისიერად რეაგირებენ და შეუძლიათ არა მხოლოდ ტიპიური პრობლემების გადაჭრა, არამედ რთული სიტუაციების გადაჭრა. ხანდახან მივმართავ მათ კითხვებით: „შესაძლებელია თუ არა ამის გაკეთება, ჩოჩქოთ?“ ან „აქ დავაყენე რაღაც და არ სურს მუშაობა. დახმარება!" - მოთმინებით იპოვიან იქ საჭირო მეგზურს და მიუთითებენ სწორ ქმედებებზე, არ უპასუხებენ: „ჩვენ მხოლოდ ტექნიკის პრობლემებს ვაგვარებთ“.

ლიტერატურა

• სპეციფიკაციები
• ვირტუალური მონაცემთა ცენტრი
• მონაცემთა ცენტრი მაგიდის უჯრაში
• ჩემი ფოსტა - [ელ.ფოსტით დაცულია]

წყარო: www.habr.com