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

შესავალი

მომხმარებლის თვალსაზრისით საინფორმაციო სისტემა კარგად არის განსაზღვრული GOST RV 51987 - ”ავტომატური სისტემა, რომლის შედეგია გამომავალი ინფორმაციის პრეზენტაცია შემდგომი გამოყენებისთვის”. თუ გავითვალისწინებთ შიდა სტრუქტურას, მაშინ არსებითად ნებისმიერი IS არის კოდში დანერგილი ურთიერთდაკავშირებული ალგორითმების სისტემა. ტიურინგ-ეკლესიის თეზისის ფართო გაგებით, ალგორითმი (ან IS) გარდაქმნის შეყვანის მონაცემთა ერთობლიობას გამომავალი მონაცემების სიმრავლედ.
შეიძლება ითქვას, რომ შეყვანის მონაცემების ტრანსფორმაცია არის საინფორმაციო სისტემის არსებობის მნიშვნელობა. შესაბამისად, IS-ის და მთელი IS კომპლექსის ღირებულება განისაზღვრება შეყვანისა და გამომავალი მონაცემების მნიშვნელობით.
ამის საფუძველზე, დიზაინი უნდა დაიწყოს და იყოს მონაცემთა ორიენტირებული, არქიტექტურისა და მეთოდების მორგება მონაცემთა სტრუქტურასა და მნიშვნელობაზე.

შენახული მონაცემები
დიზაინისთვის მომზადების მთავარი ეტაპია დამუშავებისა და შესანახად დაგეგმილი მონაცემთა ნაკრების მახასიათებლების მიღება. ეს მახასიათებლები მოიცავს:
- მონაცემთა მოცულობა;
— ინფორმაცია მონაცემთა სასიცოცხლო ციკლის შესახებ (ახალი მონაცემების ზრდა, სიცოცხლის ხანგრძლივობა, მოძველებული მონაცემების დამუშავება);
— მონაცემების კლასიფიკაცია თვალსაზრისით გავლენა კომპანიის ძირითად საქმიანობაზე (კონფიდენციალურობის, მთლიანობის, ხელმისაწვდომობის ტრიადა) ფინანსურ ინდიკატორებთან ერთად (მაგალითად, მონაცემების დაკარგვის ღირებულება ბოლო საათში);
— მონაცემთა დამუშავების გეოგრაფია (დამუშავების სისტემების ფიზიკური მდებარეობა);
— მარეგულირებელი მოთხოვნები მონაცემთა თითოეული კლასისთვის (მაგალითად, ფედერალური კანონი-152, PCI DSS).

საინფორმაციო სისტემები

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

საფრთხის მოდელი

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

მარეგულირებელი მოთხოვნები

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

RPO/RTO მიზნები

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

რესურსების აუზებად დაყოფა

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

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

გადამამუშავებელი სიმძლავრე

რეზიუმე, ვირტუალური მონაცემთა ცენტრის დამუშავების სიმძლავრის მოთხოვნები იზომება ვირტუალური პროცესორების რაოდენობის (vCPU) და მათი კონსოლიდაციის კოეფიციენტის მიხედვით ფიზიკურ პროცესორებზე (pCPU). ამ კონკრეტულ შემთხვევაში, 1 pCPU = 1 ფიზიკური პროცესორის ბირთვი (Hyper-Threading-ის გამოკლებით). vCPU-ების რაოდენობა ჯამდება ყველა განსაზღვრულ რესურს აუზში (რომელთაგან თითოეულს შეიძლება ჰქონდეს საკუთარი კონსოლიდაციის ფაქტორი).
დატვირთული სისტემებისთვის კონსოლიდაციის კოეფიციენტი მიიღება ემპირიულად, არსებული ინფრასტრუქტურის საფუძველზე, ან საპილოტე ინსტალაციისა და დატვირთვის ტესტირების გზით. დატვირთული სისტემებისთვის გამოიყენება "საუკეთესო პრაქტიკა". კერძოდ, VMware ასახელებს საშუალო თანაფარდობას 8:1.

ოპერატიული მეხსიერება

ოპერატიული მეხსიერების მთლიანი მოთხოვნა მიიღება მარტივი შეჯამებით. არ არის რეკომენდებული ოპერატიული მეხსიერების გადაჭარბებული გამოწერის გამოყენება.

შენახვის რესურსები

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

მონაცემთა ქსელის რესურსები

მონაცემთა ქსელის მოთხოვნები მიიღება ყველა გამტარუნარიანობის აუზის უბრალოდ შეჯამებით.
სერვისის ხარისხის (QoS) და შეყოვნების (RTT) მოთხოვნები კონკრეტული აუზების ან სისტემებისთვის ცალკე უნდა იყოს მითითებული.
მონაცემთა ქსელის რესურსების მოთხოვნების ფარგლებში ასევე მითითებულია მოთხოვნები ქსელური ტრაფიკის იზოლაციისა და/ან დაშიფვრის და სასურველი მექანიზმების შესახებ (802.1q, IPSec და ა.შ.).

არქიტექტურის შერჩევა

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

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

კლასიკური არქიტექტურა მოიცავს ინტელექტუალური გარე ქვესისტემების გამოყენებას მონაცემთა შესანახად და გადასაცემად, ხოლო სერვერები ხელს უწყობენ მხოლოდ დამუშავების სიმძლავრეს და ოპერატიული მეხსიერებას ფიზიკური რესურსების საერთო აუზში. უკიდურეს შემთხვევაში, სერვერები ხდება სრულიად ანონიმური, აქვთ არა მხოლოდ საკუთარი დისკები, არამედ სისტემის იდენტიფიკატორიც კი. ამ შემთხვევაში, OS ან ჰიპერვიზორი იტვირთება ჩაშენებული ფლეშ მედიიდან ან გარე მონაცემთა შენახვის სისტემიდან (ჩატვირთვა SAN-დან).
კლასიკური არქიტექტურის ფარგლებში არჩევანი პირებსა და თაროებს შორის ძირითადად ხდება შემდეგი პრინციპების საფუძველზე:
— ხარჯთეფექტური (საშუალოდ, rack-mount სერვერები უფრო იაფია);
- გამოთვლითი სიმკვრივე (უფრო მაღალია პირებისთვის);
— ენერგიის მოხმარება და სითბოს გაფრქვევა (პირებს აქვთ უფრო მაღალი სპეციფიკური ერთეული ერთეულზე);
— მასშტაბურობა და კონტროლირებადი (პირები ზოგადად ნაკლებ ძალისხმევას მოითხოვს დიდი დანადგარებისთვის);
- გაფართოების ბარათების გამოყენება (ძალიან შეზღუდული არჩევანი პირებისთვის).
კონვერგენტული არქიტექტურა (აგრეთვე ცნობილი, როგორც ჰიპერკონვერგირებული) გულისხმობს მონაცემთა დამუშავებისა და შენახვის ფუნქციების გაერთიანებას, რაც იწვევს ლოკალური სერვერის დისკების გამოყენებას და, შედეგად, კლასიკური blade ფორმის ფაქტორის მიტოვებას. კონვერგირებული სისტემებისთვის გამოიყენება rack სერვერები ან კლასტერული სისტემები, რომლებიც აერთიანებს რამდენიმე blade სერვერს და ადგილობრივ დისკს ერთ შემთხვევაში.

CPU/მეხსიერება

კონფიგურაციის სწორად გამოსათვლელად, თქვენ უნდა გესმოდეთ დატვირთვის ტიპი გარემოსთვის ან თითოეული დამოუკიდებელი კლასტერისთვის.
CPU შეკრული – პროცესორის სიმძლავრით შეზღუდულ გარემოში. ოპერატიული მეხსიერების დამატება არაფერს შეცვლის მუშაობის კუთხით (VM-ების რაოდენობა თითო სერვერზე).
მეხსიერება შეკრულია - RAM-ით შეზღუდული გარემო. სერვერზე მეტი ოპერატიული მეხსიერება გაძლევთ საშუალებას გაუშვათ მეტი VM სერვერზე.
GB / MHz (GB / pCPU) - RAM-ისა და პროცესორის ენერგიის მოხმარების საშუალო თანაფარდობა ამ კონკრეტული დატვირთვით. შეიძლება გამოყენებულ იქნას მეხსიერების საჭირო რაოდენობის გამოსათვლელად მოცემული შესრულებისთვის და პირიქით.

სერვერის კონფიგურაციის გაანგარიშება

პირველ რიგში, თქვენ უნდა განსაზღვროთ ყველა სახის დატვირთვა და გადაწყვიტოთ სხვადასხვა გამოთვლითი აუზის გაერთიანება ან დაყოფა სხვადასხვა კლასტერებად.
შემდეგი, თითოეული განსაზღვრული კლასტერისთვის, GB / MHz თანაფარდობა განისაზღვრება წინასწარ ცნობილი დატვირთვით. თუ დატვირთვა წინასწარ არ არის ცნობილი, მაგრამ არსებობს პროცესორის ენერგიის გამოყენების დონის უხეშად გაგება, შეგიძლიათ გამოიყენოთ სტანდარტული vCPU:pCPU კოეფიციენტები აუზის მოთხოვნების ფიზიკურად გადაქცევისთვის.

თითოეული კლასტერისთვის გაყავით vCPU აუზის მოთხოვნების ჯამი კოეფიციენტზე:
vCPUsum / vCPU:pCPU = pCPUsum – ფიზიკური ერთეულების საჭირო რაოდენობა. ბირთვები
pCPUsum / 1.25 = pCPUht - ბირთვების რაოდენობა მორგებული Hyper-Threading-ისთვის
დავუშვათ, რომ აუცილებელია კლასტერის გამოთვლა 190 ბირთვით / 3.5 ტბ ოპერატიული მეხსიერება. ამავდროულად, ჩვენ ვიღებთ სამიზნე დატვირთვას პროცესორის სიმძლავრის 50% და ოპერატიული მეხსიერების 75%.

pCPU
190
CPU უტილ
50%

მემ
3500
Mem უტილიტა
75%

Socket
Core
Srv/CPU
Srv Mem
Srv/Mem

2
6
25,3
128
36,5

2
8
19,0
192
24,3

2
10
15,2
256
18,2

2
14
10,9
384
12,2

2
18
8,4
512
9,1

ამ შემთხვევაში, ჩვენ ყოველთვის ვიყენებთ დამრგვალებას უახლოეს მთელ რიცხვამდე (=ROUNDUP(A1;0)).
ცხრილიდან აშკარა ხდება, რომ რამდენიმე სერვერის კონფიგურაცია დაბალანსებულია სამიზნე ინდიკატორებისთვის:
— 26 სერვერი 2*6c / 192 GB
— 19 სერვერი 2*10c / 256 GB
— 10 სერვერი 2*18c / 512 GB

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

სერვერის კონფიგურაციის არჩევის მახასიათებლები

ფართო VM-ები. თუ საჭიროა ფართო VM-ების ჰოსტინგი (შედარებით 1 NUMA კვანძთან ან მეტთან), რეკომენდებულია, თუ ეს შესაძლებელია, შეარჩიოთ სერვერი კონფიგურაციით, რომელიც საშუალებას აძლევს ასეთ VM-ებს დარჩეს NUMA კვანძში. ფართო VM-ების დიდი რაოდენობით არსებობს კლასტერული რესურსების ფრაგმენტაციის საშიშროება და ამ შემთხვევაში შეირჩევა სერვერები, რომლებიც საშუალებას აძლევს ფართო ვირტუალური მანქანების რაც შეიძლება მჭიდროდ განთავსებას.

ერთი მარცხის დომენის ზომა.

სერვერის ზომის არჩევანი ასევე ეფუძნება ერთი მარცხის დომენის მინიმიზაციის პრინციპს. მაგალითად, არჩევისას:
- 3 x 4 * 10c / 512 GB
- 6 x 2 * 10c / 256 GB
ყველა სხვა თანაბარი იყოს, თქვენ უნდა აირჩიოთ მეორე ვარიანტი, რადგან ერთი სერვერის ჩავარდნისას (ან შენარჩუნებულია), კლასტერის რესურსების არა 33% იკარგება, არამედ 17%. ანალოგიურად, ავარიის შედეგად დაზარალებული VM-ების და IS-ების რაოდენობა განახევრებულია.

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

კლასიკური შენახვის სისტემები ყოველთვის გამოითვლება უარესი სცენარის გამოყენებით, ოპერაციული ქეშის გავლენისა და ოპერაციების ოპტიმიზაციის გამოკლებით.
როგორც ძირითადი შესრულების მაჩვენებლები, ჩვენ ვიღებთ მექანიკურ შესრულებას დისკიდან (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS

შემდეგი, დისკის აუზში დისკების რაოდენობა გამოითვლება შემდეგი ფორმულის გამოყენებით: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. სად:
- TotalIOPS - საერთო საჭირო შესრულება IOPS-ში დისკის აუზიდან
- RW - წაკითხვის ოპერაციების პროცენტი
- RAID კალამი - RAID ჯარიმა არჩეული RAID დონისთვის

წაიკითხეთ მეტი მოწყობილობის RAID და RAID ჯარიმის შესახებ აქ - შენახვის შესრულება. ნაწილი პირველი. и შენახვის შესრულება. Მეორე ნაწილი. и შენახვის შესრულება. ნაწილი მესამე

დისკების შედეგად მიღებული რაოდენობის მიხედვით, გამოითვლება შესაძლო ვარიანტები, რომლებიც აკმაყოფილებენ შენახვის მოთხოვნებს, მათ შორის მრავალდონიანი შენახვის ვარიანტები.
სისტემების გაანგარიშება SSD-ის გამოყენებით, როგორც შენახვის ფენა, განიხილება ცალკე.
Flash Cache-ით სისტემების გამოთვლის თავისებურებები

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

დაბალი/საშუალო დონის ჰიბრიდული სისტემების გაანგარიშება

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

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

SSD-ის გამოყენება დონის დისკის აუზში

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

წყარო: www.habr.com