Virtualizuotas duomenų centro dizainas

Virtualizuotas duomenų centro dizainas

įvedimas

Informacinė sistema vartotojo požiūriu yra gerai apibrėžta GOST RV 51987 - „automatizuota sistema, kurios rezultatas yra išvesties informacijos pateikimas tolesniam naudojimui“. Jei atsižvelgsime į vidinę struktūrą, tai iš esmės bet kuri IS yra tarpusavyje susijusių algoritmų sistema, įgyvendinta kode. Plačiąja Turingo-Church tezės prasme algoritmas (arba IS) paverčia įvesties duomenų rinkinį į išvesties duomenų rinkinį.
Galima net sakyti, kad įvesties duomenų transformacija yra informacinės sistemos egzistavimo prasmė. Atitinkamai, IS ir viso IS komplekso vertė nustatoma per įvesties ir išvesties duomenų vertę.
Remiantis tuo, projektavimas turi prasidėti ir būti pagrįstas duomenimis, architektūrą ir metodus pritaikant prie duomenų struktūros ir reikšmės.

Saugomi duomenys
Pagrindinis pasiruošimo projektavimui etapas yra visų duomenų rinkinių, planuojamų apdoroti ir saugoti, charakteristikų gavimas. Šios savybės apima:
- Duomenų apimtis;
— Informacija apie duomenų gyvavimo ciklą (naujų duomenų augimas, gyvavimo trukmė, pasenusių duomenų apdorojimas);
— Duomenų klasifikavimas požiūriu poveikis pagrindinei įmonės veiklai (konfidencialumo, vientisumo, prieinamumo triada) kartu su finansiniais rodikliais (pavyzdžiui, duomenų praradimo kaina paskutinę valandą);
— Duomenų apdorojimo geografija (fizinė apdorojimo sistemų vieta);
— Norminiai reikalavimai kiekvienai duomenų klasei (pavyzdžiui, Federalinis įstatymas-152, PCI DSS).

Informacinės sistemos

Duomenis ne tik saugo, bet ir apdoroja (transformuoja) informacinės sistemos. Kitas žingsnis, gavus duomenų charakteristikas, yra išsamiausias informacinių sistemų, jų architektūrinių ypatybių, tarpusavio priklausomybių ir infrastruktūros reikalavimų inventorius įprastiniuose vienetuose keturiems išteklių tipams:
— Procesoriaus skaičiavimo galia;
- RAM kiekis;
— Duomenų saugojimo sistemos apimties ir našumo reikalavimai;
— Reikalavimai duomenų perdavimo tinklui (išoriniai kanalai, kanalai tarp IS komponentų).
Tokiu atveju turi būti reikalavimai kiekvienai paslaugai/mikropaslaugai kaip IS daliai.
Atskirai reikia pažymėti, kad norint teisingai suprojektuoti duomenis apie IS poveikį pagrindinei įmonės veiklai IS prastovų sąnaudų (rubliais per valandą) forma yra privaloma.

Grėsmės modelis

Turi būti formalus grėsmių modelis, nuo kurio planuojama apsaugoti duomenis/paslaugas. Be to, grėsmės modelis apima ne tik konfidencialumo, bet ir vientisumo bei prieinamumo aspektus. Tie. Pavyzdžiui:
— fizinio serverio gedimas;
— viršutinio stovo jungiklio gedimas;
— optinio ryšio kanalo tarp duomenų centrų sutrikimas;
— visos veikiančios saugojimo sistemos gedimas.
Kai kuriais atvejais grėsmių modeliai rašomi ne tik infrastruktūros komponentams, bet ir konkrečioms informacinėms sistemoms ar jų komponentams, pavyzdžiui, DBVS gedimas su loginiu duomenų struktūros sunaikinimu.
Visi projekto sprendimai, skirti apsisaugoti nuo neaprašytos grėsmės, yra nereikalingi.

Norminiai reikalavimai

Jei tvarkomiems duomenims taikomos specialios reguliavimo institucijų nustatytos taisyklės, reikalinga informacija apie duomenų rinkinius ir tvarkymo/saugojimo taisykles.

RPO/RTO tikslai

Norint sukurti bet kokio tipo apsaugą, reikia turėti tikslinius duomenų praradimo rodiklius ir tikslinį paslaugos atkūrimo laiką kiekvienai iš aprašytų grėsmių.
Idealiu atveju RPO ir RTO turėtų turėti susijusias duomenų praradimo ir prastovos išlaidas per laiko vienetą.

Virtualizuotas duomenų centro dizainas

Padalijimas į išteklių telkinius

Surinkus visą pradinę įvesties informaciją, pirmiausia reikia sugrupuoti duomenų rinkinius ir IP į telkinius pagal grėsmės modelius ir reguliavimo reikalavimus. Nustatomas įvairių telkinių padalijimo tipas – programiškai sistemos programinės įrangos lygiu arba fiziškai.
Pavyzdžiai:
— Asmens duomenų apdorojimo grandinė yra fiziškai visiškai atskirta nuo kitų sistemų;
— Atsarginės kopijos saugomos atskiroje saugojimo sistemoje.

Tokiu atveju telkiniai gali būti nevisiškai nepriklausomi, pavyzdžiui, apibrėžiami du skaičiavimo resursų telkiniai (procesoriaus galia + RAM), kurie naudoja vieną duomenų saugojimo telkinį ir vieną duomenų perdavimo resursų telkinį.

Apdorojimo galia

Virtualizuotas duomenų centro dizainas

Anotacija, virtualizuoto duomenų centro apdorojimo galios poreikis matuojamas virtualių procesorių (vCPU) skaičiumi ir jų konsolidacijos koeficientu fiziniuose procesoriuose (pCPU). Šiuo konkrečiu atveju 1 pCPU = 1 fizinis procesoriaus branduolys (išskyrus „Hyper-Threading“). VCPU skaičius sumuojamas visuose apibrėžtuose išteklių telkiniuose (kiekvienas iš jų gali turėti savo konsolidavimo koeficientą).
Apkrautų sistemų konsolidacijos koeficientas gaunamas empiriškai, remiantis esama infrastruktūra arba bandomuoju įrengimu ir apkrovos testavimu. Neapkrautoms sistemoms taikoma „geriausia praktika“. Tiksliau, VMware nurodo vidutinį santykį kaip 8:1.

Operatyvi atmintis

Bendras RAM poreikis gaunamas paprastai susumavus. Nerekomenduojama naudoti perteklinės RAM.

Sandėliavimo ištekliai

Sandėliavimo reikalavimai gaunami tiesiog susumavus visus baseinus pagal talpą ir našumą.
Našumo reikalavimai išreiškiami IOPS kartu su vidutiniu skaitymo/rašymo santykiu ir, jei reikia, didžiausiu atsako delsa.
Paslaugos kokybės (QoS) reikalavimai konkretiems telkiniams ar sistemoms turi būti nurodyti atskirai.

Duomenų tinklo ištekliai

Duomenų tinklo reikalavimai gaunami tiesiog susumavus visus pralaidumo fondus.
Paslaugos kokybės (QoS) ir delsos (RTT) reikalavimai konkretiems telkiniams ar sistemoms turėtų būti nurodyti atskirai.
Kaip duomenų tinklo išteklių reikalavimų dalis, taip pat nurodomi tinklo srauto izoliavimo ir (arba) šifravimo reikalavimai bei pageidaujami mechanizmai (802.1q, IPSec ir kt.).

Architektūros pasirinkimas

Šiame vadove neaptariamas joks kitas pasirinkimas, išskyrus x86 architektūrą ir 100 % serverio virtualizaciją. Todėl skaičiavimo posistemės architektūros pasirinkimas priklauso nuo serverio virtualizacijos platformos, serverio formos faktoriaus ir bendrųjų serverio konfigūracijos reikalavimų.

Esminis pasirinkimo taškas yra tikrumas, kad bus naudojamas klasikinis metodas, atskiriant duomenų apdorojimo, saugojimo ir perdavimo funkcijas arba konvergencinę.

klasikinė architektūra apima intelektualių išorinių posistemių naudojimą duomenims saugoti ir perduoti, o serveriai į bendrą fizinių išteklių fondą įneša tik apdorojimo galią ir RAM. Kraštutiniais atvejais serveriai tampa visiškai anonimiški, turi ne tik savo diskus, bet net neturi sistemos identifikatoriaus. Tokiu atveju OS arba hipervizorius įkeliamas iš įmontuotos „flash“ laikmenos arba iš išorinės duomenų saugojimo sistemos (įkrovos iš SAN).
Klasikinės architektūros rėmuose pasirinkimas tarp peilių ir stelažų pirmiausia atliekamas remiantis šiais principais:
— Ekonomiškas (vidutiniškai ant stovo montuojami serveriai yra pigesni);
— Skaičiavimo tankis (didesnis menčių);
— Energijos suvartojimas ir šilumos išsklaidymas (menčių vienetas turi didesnį specifinį vienetą);
— Mastelio keitimas ir valdymas (didelėse instaliacijose paprastai reikia mažiau pastangų);
- Išplėtimo kortelių naudojimas (labai ribotas ašmenų pasirinkimas).
Konvergentinė architektūra (taip pat žinomas kaip hiperkonverguotas). Sujungtoms sistemoms naudojami stovo serveriai arba klasterių sistemos, sujungiančios kelis blade serverius ir vietinius diskus vienu atveju.

CPU/atmintis

Norėdami teisingai apskaičiuoti konfigūraciją, turite suprasti aplinkos ar kiekvienos nepriklausomos grupės apkrovos tipą.
Sujungtas su CPU – aplinka, kurią našumą riboja procesoriaus galia. Pridėjus RAM, našumas (VM skaičius viename serveryje) nieko nepasikeis.
Atmintis surišta – RAM ribojama aplinka. Daugiau RAM serveryje leidžia paleisti daugiau VM serveryje.
GB / MHz (GB / pCPU) - vidutinis RAM ir procesoriaus galios sunaudojimo pagal šią apkrovą santykis. Galima naudoti norint apskaičiuoti reikiamą atminties kiekį tam tikram našumui ir atvirkščiai.

Serverio konfigūracijos skaičiavimas

Virtualizuotas duomenų centro dizainas

Pirmiausia turite nustatyti visų tipų apkrovą ir nuspręsti, ar sujungti arba padalinti skirtingus skaičiavimo telkinius į skirtingas grupes.
Toliau kiekvienam iš apibrėžtų grupių GB / MHz santykis nustatomas esant iš anksto žinomai apkrovai. Jei apkrova iš anksto nežinoma, bet yra apytikslis supratimas apie procesoriaus galios panaudojimo lygį, galite naudoti standartinius vCPU:pCPU santykius, norėdami konvertuoti telkinio reikalavimus į fizinius.

Kiekvieno klasterio vCPU baseino poreikių sumą padalinkite iš koeficiento:
vCPUsum / vCPU:pCPU = pCPUsum – reikalingas fizinių vienetų skaičius. šerdys
pCPUsum / 1.25 = pCPUht – branduolių skaičius, pritaikytas Hyper-Threading
Tarkime, kad reikia apskaičiuoti klasterį su 190 branduolių / 3.5 TB RAM. Tuo pačiu metu mes priimame tikslinę 50% procesoriaus galios ir 75% RAM apkrovą.

pCPU
190
CPU util
50%

Mem
3500
Mem naudingumas
75%

Lizdas
Esmė
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

Šiuo atveju visada naudojame apvalinimą iki artimiausio sveikojo skaičiaus (=ROUNDUP(A1;0)).
Iš lentelės tampa akivaizdu, kad tiksliniams rodikliams subalansuotos kelios serverio konfigūracijos:
— 26 serveriai 2*6c / 192 GB
— 19 serveriai 2*10c / 256 GB
— 10 serveriai 2*18c / 512 GB

Šių konfigūracijų pasirinkimas turi būti atliktas atsižvelgiant į papildomus veiksnius, tokius kaip šiluminis paketas ir galimas aušinimas, jau naudojami serveriai arba kaina.

Serverio konfigūracijos pasirinkimo ypatybės

Plačios VM. Jei reikia talpinti plačias VM (palyginama su 1 NUMA mazgu ar daugiau), rekomenduojama, jei įmanoma, pasirinkti serverį su konfigūracija, leidžiančia tokioms VM likti NUMA mazge. Esant dideliam plačių VM skaičiui, kyla klasterio resursų fragmentacijos pavojus, tokiu atveju parenkami serveriai, leidžiantys kuo tankiau išdėstyti plačias VM.

Vieno gedimo domeno dydis.

Serverio dydžio pasirinkimas taip pat grindžiamas vieno gedimo srities sumažinimo principu. Pavyzdžiui, renkantis iš:
- 3 x 4*10c / 512 GB
- 6 x 2*10c / 256 GB
Jei visi kiti dalykai nesikeičia, turite pasirinkti antrąjį variantą, nes vienam serveriui sugedus (arba prižiūrint), prarandami ne 33% klasterio resursų, o 17%. Lygiai taip pat perpus sumažėja avarijos paveiktų VM ir IS skaičius.

Klasikinių saugojimo sistemų skaičiavimas pagal našumą

Virtualizuotas duomenų centro dizainas

Klasikinės saugojimo sistemos visada skaičiuojamos pagal blogiausią scenarijų, neįskaitant operacinės talpyklos ir operacijų optimizavimo įtakos.
Kaip pagrindinius našumo rodiklius mes paimame mechaninį našumą iš disko (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS

Tada diskų skaičius diskų telkinyje apskaičiuojamas pagal šią formulę: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPS diskas. Kur:
- TotalIOPS – visas reikalingas IOPS našumas iš diskų telkinio
- RW – skaitymo operacijų procentas
- RAIDpen – RAID bauda už pasirinktą RAID lygį

Daugiau apie įrenginio RAID ir RAID baudą skaitykite čia - Sandėliavimo našumas. Pirma dalis. и Sandėliavimo našumas. Antra dalis. и Sandėliavimo našumas. Trečioji dalis

Remiantis gautu diskų skaičiumi, apskaičiuojamos galimos parinktys, atitinkančios saugojimo talpos reikalavimus, įskaitant variantus su kelių lygių saugykla.
Sistemų, naudojančių SSD kaip saugojimo sluoksnį, skaičiavimas nagrinėjamas atskirai.
Skaičiavimo sistemų su „Flash Cache“ ypatybės

„Flash“ talpykla – bendras visų patentuotų technologijų, skirtų naudoti „flash“ atmintį kaip antrojo lygio talpyklą, pavadinimas. Naudojant „flash“ talpyklą, saugojimo sistema paprastai apskaičiuojama taip, kad užtikrintų pastovią magnetinių diskų apkrovą, o didžiausią talpyklą aptarnauja talpykla.
Tokiu atveju būtina suprasti apkrovos profilį ir prieigos prie saugojimo tūrių blokų lokalizacijos laipsnį. „Flash“ talpykla yra technologija, skirta darbo krūviams su labai lokalizuotomis užklausomis ir praktiškai netaikoma vienodai įkeliamiems kiekiams (pvz., analizės sistemoms).

Žemos/vidutinės klasės hibridinių sistemų skaičiavimas

Žemesnės ir vidurinės klasės hibridinėse sistemose naudojama kelių lygių saugykla, o duomenys perkeliami iš vieno lygio pagal tvarkaraštį. Tuo pačiu metu geriausių modelių kelių lygių saugojimo bloko dydis yra 256 MB. Šios savybės neleidžia mums laikyti pakopinės saugojimo technologijos produktyvumo didinimo technologija, kaip daugelis klaidingai mano. Daugiapakopis saugojimas žemos ir vidutinės klasės sistemose yra technologija, skirta optimizuoti saugojimo išlaidas sistemoms, kuriose yra ryškus apkrovos netolygumas.

Pakopinio saugojimo atveju pirmiausia apskaičiuojamas aukščiausios pakopos našumas, o apatinė saugyklos pakopa tik prisideda prie trūkstamos saugyklos talpos. Hibridinėje kelių pakopų sistemoje privaloma naudoti „flash“ talpyklos technologiją kelių pakopų telkiniui, siekiant kompensuoti staigaus žemesnio lygio duomenų našumo sumažėjimą.

SSD naudojimas pakopiniame diskų telkinyje

Virtualizuotas duomenų centro dizainas

SSD naudojimas kelių lygių diskų telkinyje gali skirtis, atsižvelgiant į konkretų konkretaus gamintojo „flash“ talpyklos algoritmų įgyvendinimą.
Bendra diskų telkinio su SSD lygiu saugojimo politika pirmiausia yra SSD.
Tik skaitymo „Flash“ talpykla. Tik skaitomai „flash“ talpyklai SSD saugojimo sluoksnis pateikiamas su reikšminga įrašymo lokalizacija, neatsižvelgiant į talpyklą.
Skaityti / rašyti „Flash“ talpyklą. „Flash“ talpyklos atveju rašymo talpyklos dydis pirmiausia nustatomas į maksimalų talpyklos dydį, o SSD saugyklos pakopa rodoma tik tada, kai talpyklos dydžio nepakanka visam lokalizuotam darbo krūviui aptarnauti.
SSD ir talpyklos našumo skaičiavimai atliekami kiekvieną kartą pagal gamintojo rekomendacijas, tačiau visada pagal blogiausią scenarijų.

Šaltinis: www.habr.com

Добавить комментарий