Virtuaalne andmekeskuse disain

Sissejuhatus

Kasutaja vaatenurgast määratleb teabe süsteemi hästi GOST RV 51987 – „automatiseeritud süsteem, mille funktsioneerimise tulemuseks on väljundinformatsiooni esitamine edasiseks kasutamiseks”. Kui vaadata sisemist struktuuri, siis põhimõtteliselt on iga teabe süsteem omavahel seotud algoritmide koodiväljatöötamise süsteem.
Võib isegi öelda, et sisendandmete transformatsioon on teabe süsteemi olemuse sisu. Vastavalt sellele määratakse teabe süsteemi ja kogu teabe süsteemide kompleksi väärtus sisend- ja väljundandmete väärtuse kaudu.
Seega peaks projekteerimine alustama ja võtma aluseks andmed, kohandades arhitektuuri ja meetodeid andmete struktuuri ja tähtsuse järgi.

Salvestatud andmed
Projekteerimise ettevalmistamise oluline etapp on kõikide andmekogumite omaduste saamine, mida planeeritakse töödelda ja salvestada. Need omadused hõlmavad järgmist:
— Andmehulga;
— Teave andmete elutsükli kohta (uute andmete lisandumine, eluiga, vanade andmete töötlemine);
— Andmete klassifitseerimine ettevõtte peamise äri mõju seisukohalt (kolmainsuse – konfidentsiaalsuse, terviklikkuse, kättesaadavuse) koos rahaliste näitajatega (nt andmete kaotuse hind viimase tunni jooksul);
— Andmete töötlemise geograafia (füüsiline asukoht töötlemisseadmetel);
— Regulaatorite nõuded iga andmeklassi kohta (nt Föderaalseadus 152, PCI DSS).

Teabe süsteemid

Andmeid mitte ainult ei salvestata, vaid töötlevad (transformeerivad) teabe süsteemid. Järgmine samm pärast andmete omaduste saamist on võimalikult täielik teabe süsteemide inventuur, nende arhitektuurilised omadused, omavahelised sõltuvused ja infrastruktuuri nõudmised neljas ressursside kategoorias:
— Protsessorite arvutustehniline võime;
— Operatiivmälu maht;
— Nõuded andmesalvestussüsteemi mahu ja jõudluse suhtes;
— Nõuded andmeside võrgu kohta (välistooted, kanalid teabe süsteemi komponentide vahel).
Nõuded peavad olema iga teenuse/mikroteenuse kohta, mis kuulub infosüsteemi.
Erakordne on rõhutada, et korrektseks projekteerimiseks on vajalik teave infosüsteemi mõju kohta ettevõtte põhitegevusele väljendatuna infosüsteemi seisaku maksumuses (rubla tunnis).

Ohumudel

Kohustuslik on omada formaalset ohumudelit, millest kavatsetakse andmeid/teenuseid kaitsta. Samuti hõlmab ohumudel mitte ainult konfidentsiaalsuse aspekte, vaid ka terviklikkust ja kättesaadavust. Näiteks:
— Füüsilise serveri tõrge;
— Top-of-the-rack lüliti tõrge;
— Optilise side kanali katkestamine andmekeskuste vahel;
— Operatiivse andmesalvestuse (SAN) täielik tõrge.
Mõnel juhul kirjutatakse ohumudeleid mitte ainult infrastruktuuri komponente, vaid ka konkreetseid infosüsteeme või nende komponente, näiteks andmebaasi (DB) tõrge, mis põhjustab andmestruktuuri loogilise rikkumise.
Kõik projektiraames tehtud otsused, mis on suunatud kirjeldamata ohu vastu kaitsmiseks, on liigsed.

Regulaatorite nõuded

Kui töödeldavad andmed kuuluvad regulatiivsete asutuste kehtestatud eriliste reeglite alla, on hädavajalik teave andmekogude ja töötlemise/hajutamise reeglite kohta.

Eesmärgid RPO/RTO

Iga kaitseprojekti kujundamine eeldab sihtandmete kaotuse ja teenuse taastamise sihtaegade näitajate olemasolu kõigi kirjeldatud ohtude puhul.
Ideaalis peaks RPO ja RTO omama seotud kaotuse ja seiskumise maksumuse väärtusi ajaühikus.

Ressursse jagamine gruppideks

Pärast kogu esmase teabe kogumist on esimene samm andmekogude ja infosüsteemide grupeerimine rühmadesse, lähtudes ohumudelitest ja regulatiivsete nõuete sätetest. Määratakse erinevate rühmade jagamise vorm – programmiliselt süsteemide tasandil või füüsiliselt.
Näited:
— Isikuandmeid töötlev kontuur on täielikult füüsiliselt eraldatud muudest süsteemidest;
— Varukoopiad hoitakse eraldi andmesalvestuses.

Sel juhul võivad rühmad olla mittetäieliku iseseisvusega, näiteks määratakse kaks arvutusressursside gruppi (protsessoripotentsiaal + mälumaa), mis kasutavad ühte andmesalvestuse gruppi ja ühte andmesideressursside gruppi.

Protsessoripotentsiaal

Abstraktsed vajadused virtualiseeritud andmekeskuse protsessorivõimsuse jaoks mõõdetakse virtuaalprotsessorite (vCPU) arvu ja nende konsolideerimise koefitsienti füüsilistel protsessoritel (pCPU). Antud konkreetses olukorras 1 pCPU = 1 füüsiline protsessori tuum (ilma Hyper-Threading'ita). vCPU kogus summeeritakse kõigi määratletud ressursside basseinide kohta (igal neist võib olla oma konsolideerimise koefitsient).
Konsolideerimise koefitsiendi määramine koormatud süsteemide jaoks toimub empiiriliselt, lähtudes juba olemasolevast infrastruktuurist või pilootinstalleerimise ja koormustestimise käigus. Koormamata süsteemide puhul rakendatakse 'parimaid tavasid'. Eelkõige nimetab VMware keskmiseks koefitsiendiks 8:1.

Operatiivmälu

Üldine vajadus mäluressursside järele saadakse lihtsa summeerimise kaudu. Mälu üleallokatsiooni kasutamine ei ole soovitatav.

Salvestusressursid

Salvestusressursside nõuded saadakse kõigi basseinide mahu ja jõudluse lihtsa summeerimise kaudu.
Jõudluse nõuded väljendatakse IOPS-ina koos keskmise lugemise/kirjutamise suhtega ning vajadusel maksimaalse vaste viivitusega.
Eraldi tuleks määrata teenuse kvaliteedi (QoS) nõuded konkreetsete basseinide või süsteemide jaoks.

Andmeside ressursid

Andmeside nõuded saadakse kõigi ribalaiuse basseinide lihtsa summeerimise kaudu.
Eraldi tuleks määrata teenuse kvaliteedi (QoS) ja viivituse (RTT) nõuded konkreetsete basseinide või süsteemide jaoks.
Andmeside ressursside nõuete raames määratakse samuti võrgu liikluse isoleerimise ja/või krüpteerimise nõuded ning eelistatud mehhanismid (802.1q, IPSec jne).

Arhitektuuri valik

Käesolevas juhendis ei käsitleta muud valikut, välja arvatud x86 arhitektuur ja 100% serverite virtualiseerimine. Seetõttu piirdub arvutusala arvutussüsteemi arhitektuuri valik serveri virtualiseerimise platvormi, serverite vormifaktori ja serverite konfiguratsiooni üldiste nõuetega.

Valiku peamine punkt on kindel otsus, kas kasutada klassikalist lähenemist, mis eraldab andmete töötlemise, salvestamise ja edastamise funktsioonid, või konvergente.

Klassikaline arhitektuur eeldab andmete salvestamise ja edastamise intelligentsete välist süsteemide kasutamist, samas kui serverid toovad füüsilise ressursi ühisesse puuli vaid protsessorivõimsuse ja muutmälu. Äärmuslikus olukorras muutuvad serverid täiesti anonüümseks, millel ei ole mitte ainult oma kettasid, vaid isegi süsteemi tuvastajat. Sel juhul kasutatakse opsüsteemi või hüperviisori laadimist sisseehitatud flash-mägedelt või välistelt andmesalvestussüsteemidelt (boot from SAN).
Klassikalise arhitektuuri raames tehakse valik terade (blade) ja riiulite (rack) vahel peamiselt järgmiste põhimõtete alusel:
— Majanduslik efektiivsus (keskmiselt on riiuliserverid odavamad);
— Arvutuslik tihedus (teradel on see kõrgem);
— Energiatarve ja soojuse tootmine (terade puhul on see suurem suhteliselt ühesus);
— Skaalautuvus ja haldamine (terad vajavad suuremate installatsioonide puhul üldiselt vähem pingutust);
— Laienduskaartide kasutamine (terade puhul on valik väga piiratud).
Konvergeeriv arhitektuur (ka tuntud kui hüperkonvergeeriv) tähendab töötlemise ja andmete salvestamise funktsioonide ühendamist, mis viib serverite kohalike kettade kasutamiseni ning tagab seega klassikaliste terade vormitegurist loobumise. Konvergeerivate süsteemide jaoks kasutatakse kas riiuliservereid või klastrisüsteeme, mis ühendavad ühte korpusesse mitu serveri-terast ja kohalikke kettaid.

CPU / Mälu

Õige konfiguratsiooni arvutamiseks tuleb mõista koormuse tüüpi iga keskkonna või iga sõltumatu klastri jaoks.
CPU bound – keskkond, mis on piiratud protsessorivõimsuse tootlikkuse poolest. Muutmälu lisamine ei muuda mitte midagi jõudluse (virtuaalmasinate arvu serveris) osas.
Memory bound – keskkond, mis on piiratud muutmälu poolest. Suurema muutmälu olemasolu serveris võimaldab käivitada rohkem virtuaalmasinaid.
GB / MHz (GB / pCPU) – keskmine suhe selle konkreetse koormuse poolt tarbitud muutmälu ja protsessorivõimsuse vahel. Seda saab kasutada vajaliku mälu mahtude arvutamiseks antud jõudluse korral ja vastupidi.

Serveri konfiguratsiooni arvutamine

Esiteks tuleb määrata kõik koormuse tüübid ja otsustada, kas erinevad arvutuspoolid tuleks ühendada või eraldada erinevatesse klastritesse.
Seejärel määratakse iga määratud klastri jaoks suhtarv GB / MHz, teades eelnevalt koormust. Kui koormust ei ole võimalik eelnevalt määrata, kuid on olemas ligikaudne arusaam protsessorite võimsuse koormuse tasemest, saab kasutada standardseid vCPU:pCPU koefitsiente, et tõlkida nõuded poolidest füüsilisteks.

Iga klastri vCPU nõuete summa jagatakse koefitsiendiga:
vCPU_sum / vCPU:pCPU = pCPU_sum – nõutav füüsiliste tuumade arv
pCPU_sum / 1.25 = pCPU_ht – tuumade arv, arvestades Hyper-Threading'ut
Oletame, et on vajalik arvutada klaster 190 tuumale / 3.5TB RAM-ile. Sel juhul võtame sihiks 50% protsessorivõimsuse koormuse ja 75% mälu koormuse.

pCPU
190
CPU util
50%

Mem
3500
Mem util
75%

Socket
Tuumik
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

Sellisel juhul kasutame alati ümardamist kõige lähemale täisarvule ülespoole (=ROUNDUP(A1;0)).
Tabelist on selge, et sihttasemele vastavad mitmed serverikonfiguratsioonid:
— 26 serverit 2*6c / 192 GB
— 19 serverit 2*10c / 256 GB
— 10 serverit 2*18c / 512 GB

Nende konfiguratsioonide valimisel tuleb arvesse võtta ka täiendavaid tegureid, näiteks soojuspakett ja saadaval olev jahutus, juba kasutusel olevad serverid või hind.

Serveri konfiguratsiooni valimise eripärad

Laialdased VM-d. Kui on vajalik laiaaldate VM-de paigutamine (mis on võrreldavad 1 NUMA sõlmega ja suuremad), on soovitatav võimalusel valida server, mille konfiguratsioon võimaldab nendel VM-del jääda NUMA sõlme piiridesse. Suure arvu laialdaste VM-de korral võib tekkida klastrite ressursside killustamine ning sel juhul valitakse serverid, mis võimaldavad laialdasi VM-e maksimaalselt tihedalt paigutada.

Ühe punktilükkest domaani suurus.

Serveri suuruse valimine toimub samuti ühe punktilükkest domaani minimeerimise printsiibil. Näiteks valiku tegemisel:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Kui kõik muu on võrdsed, tuleks valida teine variant, kuna ühe serveri rikke (või hoolduse) korral kaotatakse mitte 33% klastrite ressursse, vaid 17%. Samuti väheneb kahe võrra VM-de ja IS-de arv, millele rike mõjutas.

Klassikalise andmesalvestuse süsteemi jõudluse arvutamine

Klassikalise andmesalvestuse süsteem arvutatakse alati kõige halvemate tingimuste (worst case scenario) põhjal, jättes välja operatiivse vahemälu ja toimingute optimeerimise mõju.
Põhijõudlusnäitajatena võtame diskilt saadud mehaanilise jõudluse (IOPSdisk):
— 7.2k – 75 IOPS
— 10k – 125 IOPS
— 15k – 175 IOPS

Seejärel arvutatakse ketaste arv andmepuulis järgmise valemi järgi: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Kus:
— TotalIOPS – nõutav kogujõudlus IOPS alates andmepuust
— RW – lugemistehingute protsentuaalne osa
— RAIDpen – RAID karistus valitud RAID tasemele

ROG: RAID-i seadmete ja RAID karistuse kohta on rohkem infot siin — Andmesalvestus süsteem. Esimene osa. ja Andmesalvestus süsteem. Teine osa. ja Andmesalvestus süsteem. Kolmas osa.

Saadud ketaste arvu põhjal arvutatakse võimalikud valikud, mis vastavad salvestusmahu nõuetele, sealhulgas mitmetasandilise salvestuse variandid.
SSD-de kasutamisega süsteemide arvutamine mitmetasandilise salvestusena käsitletakse eraldi.
Flash Cache süsteemide arvutamise eripära

Flash Cache – üldmõisted, mis tähistavad kõiki patenteeritud tehnoloogiaid, mis kasutavad flash-mälu teise taseme vahemäluna. Flash-vahemälu kasutamisel arvutatakse andmesalvestuse system tavaliselt selliste magnetketaste koormuse põhjal, samas kui tipukoormust teenindab vahemälu.
Oluline on mõista koormuse profiili ja sekkumise aste salvestustükkide plokkidesse. Flash Cache on tehnoloogia, mis on mõeldud suure lokaaliseerimisega päringute koormustele ja on praktiliselt kasutamiskõlbmatu ühtlaselt koormatud mahtude jaoks (nagu näiteks analüüsi süsteemide jaoks).

Hübriidsüsteemide arvutamine low-end / mid-range

Alumise ja keskmise klassi hübriidsüsteemid kasutavad mitmetasandilist salvestust andmete liigutamisega tasandite vahel vastavalt graafikule. Samuti on mitmetasandilise salvestuse ploki suurus parimates mudelites 256 MB. Need omadused ei võimalda mitmetasandilist salvestust pidada jõudluse suurendamise tehnoloogiaks, nagu paljud ekslikult arvavad. Mitmetasandiline salvestus alumise ja keskmise klassi süsteemides on salvestuskulude optimeerimise tehnoloogia, mida iseloomustab väljendunud ebaühtlane koormus.

Mitme tasandi salvestuse puhul kalkuleeritakse peamiselt tippvõimekus, samal ajal kui madalama tasandi salvestust loetakse lihtsalt puuduvaks salvestusmahtuks. Hübriidsete mitme tasandi süsteemide puhul on kohustuslik kasutada vilkuritehnoloogiat mitme tasandi paagis, et kompenseerida jõudluse langust järsku soojenenud andmete puhul madalamal tasandil.

SSD kasutamine mitme tasandi ketta paagis

SSD kasutamine mitme tasandi ketta paagis varieerub sõltuvalt antud tootja vilkuritehnoloogia rakendamise spetsifikast.
Üldine salvestuspoliitika SSD tasemega ketta paagi jaoks – SSD first.
Ainult lugemise jaoks mõeldud vilkurite jagu. Ainult lugemise jaoks mõeldud vilkurite taseme puhul ilmneb salvestusmaht SSD-l alles siis, kui kirjutamise tegevused on oluliselt lokaliseeritud sõltumata vahemälust.
Luge/ Kirjuta vilkurite jagu. Kirjutamise nimel vilkurite jagu puhul määratakse esmalt vahemälu maksimumsuurus ja SSD salvestusmaht ilmub alles siis, kui vahemälu suurus ei ole piisav kogu lokaalse koormuse teenindamiseks.
SSD ja vahemälu jõudluse kalkuleerimine toimub iga kord vastavalt tootja soovitustele, kuid alati juhul, kui see on halvim stsenaarium.

Allikas: habr.com