Dizajn virtualiziranog DC-a

Uvod

Informacijski sustav korisnik definira prema GOST RV 51987 – "automatizirani sustav čiji je rezultat funkcioniranja predstavljanje izlaznih informacija za daljnju upotrebu". Ako razmotrite unutarnju strukturu, svaka IS u suštini predstavlja sustav međusobno povezanih algoritama realiziranih u kodu. U širem smislu Turing-Churchove teze, algoritam (tj. IS) provodi transformaciju skupa ulaznih podataka u skup izlaznih podataka.
Može se čak reći da je smisao postojanja informacijskog sustava upravo u transformaciji ulaznih podataka. Stoga se vrijednost IS i cijelog kompleksa IS određuje kroz vrijednost ulaznih i izlaznih podataka.
Iz toga slijedi da projektiranje treba započeti i temeljiti se na podacima, prilagođavajući arhitekturu i metode strukturi i značaju podataka.

Pohranjeni podaci
Ključna faza pripreme za projektiranje je prikupiti karakteristike svih skupa podataka koje planiramo obrađivati i pohranjivati. Ove karakteristike uključuju:
— Obujam podataka;
— Informacije o životnom ciklusu podataka (povećanje novih podataka, vijek trajanja, obrada zastarjelih podataka);
— Klasifikacija podataka s gledišta utjecaja na osnovno poslovanje tvrtke (posjedovanju povjerljivosti, cjelovitosti, dostupnosti) zajedno s financijskim pokazateljima (npr. cijena gubitka podataka u posljednjem satu);
— Geografija obrade podataka (fizička lokacija sustava obrade);
— Zahtjevi regulatora za svaku klasu podataka (npr. FZ-152, PCI DSS).

Informacijski sustavi

Podaci ne samo da se pohranjuju, već ih i obrađuju (transformiraju) informacijski sustavi. Sljedeći korak nakon prikupljanja karakteristika podataka je što potpunija inventarizacija informacijskih sustava, njihovih arhitektonskih osobina, međuzavisnosti i zahtjeva za infrastrukturom u konvencionalnim jedinicama za četiri vrste resursa:
— Procesorska računalna snaga;
— Obujam radne memorije;
— Zahtjevi za obujam i performanse sustava za pohranu podataka;
— Zahtjevi za mrežom prijenosa podataka (vanjski kanali, kanali među komponentama IS).
Za svaki servis/mikroservis unutar IS-a moraju postojati zahtjevi.
Posebno je važno napomenuti obavezan skup podataka o utjecaju IS-a na osnovno poslovanje tvrtke u smislu troška zastoja IS-a (rubalja na sat).

Model prijetnji

Obavezno treba imati formalni model prijetnji od kojih se planira zaštita podataka / usluga. Model prijetnji uključuje ne samo aspekte povjerljivosti, već i cjelovitosti i dostupnosti. To jest, na primjer:
— Kvar fizičkog servera;
— Kvar top-of-the-rack prekidača;
— Prekid optičkog komunikacijskog kanala između CENTRA;
— Kvar operativnog sustava za pohranu podataka u cjelini.
U nekim slučajevima modeli prijetnji nisu pisani samo za infrastrukturne komponente, već i za specifične IS ili njihove komponente, poput pada DBMS-a s logičkim uništenjem strukture podataka.
Sva rješenja unutar projekta za zaštitu od neobjašnjenih prijetnji su suvišna.

Zahtjevi regulatora

Ako obrađeni podaci podliježu posebnim pravilima koja utvrđuju regulatori, obavezno je osigurati informacije o skupovima podataka i pravilima obrade/pohrane.

Ciljni pokazatelji RPO / RTO

Projektiranje bilo koje vrste zaštite zahtijeva prisutnost pokazatelja ciljane gubitka podataka i ciljanog vremena oporavka usluge za svaku od opisanych prijetnji.
U idealnom slučaju, RPO i RTO trebaju imati povezane troškove gubitka podataka i zastoja po jedinici vremena.

Podjela na skupine resursa

Nakon prikupljanja svih početnih informacija, prvi korak je grupiranje skupova podataka i IS-a u skupine, na temelju modela prijetnji i zahtjeva regulatora. Određuje se vrsta podjele različitih skupina - programski na razini sustavnog softvera ili fizički.
Primjeri:
— Kontura koja obrađuje osobne podatke potpuno je fizički odvojena od ostalih sustava;
— Backup se čuva na zasebnom sustavu za pohranu.

U tom slučaju, skupine mogu imati nepotpunu neovisnost, na primjer, definiraju se dva skupa računalnih resursa (procesorska snaga + radna memorija), koji koriste jedinstveni skup za pohranu podataka i jedinstveni skup resursa za prijenos podataka.

Procesorska snaga

Apsolutne potrebe za procesorskom snagom virtualiziranog DC-a mjere se brojem virtualnih procesora (vCPU) i koeficijentom njihove konsolidacije na fizičkim procesorima (pCPU). U ovom konkretnom slučaju 1 pCPU = 1 fizičko jezgro procesora (ne računajući Hyper-Threading). Broj vCPU zbraja se u svim unaprijed definiranim bazenima resursa (od kojih svaki može imati svoj koeficijent konsolidacije).
Koeficijent konsolidacije za opterećene sustave dobiva se empirijski, prema već postojećoj infrastrukturi ili tijekom probne instalacije i opterećenja. Za neopterećene sustave primjenjuju se 'best practices'. Konkretno, VMware navodi prosječni koeficijent od 8:1.

Radna memorija

Ukupna potreba za radnom memorijom dobiva se jednostavnim zbrajanjem. Korištenje pretplate za radnu memoriju nije preporučljivo.

Resursi pohrane

Zahtjevi za resursima pohrane dobivaju se jednostavnim zbrajanjem svih bazena prema volumenu i performansama.
Zahtjevi za performansama izražavaju se u IOPS-u u kombinaciji s prosječnim omjerom čitanja/pisanja i, ako je potrebno, maksimalnom latencijom.
Odvojeno treba navesti zahtjeve za osiguranje kvalitete usluge (QoS) za određene bazene ili sustave.

Resursi mreže

Zahtjevi za mrežom dobivaju se jednostavnim zbrajanjem svih bazena propusnosti.
Odvojeno treba navesti zahtjeve za osiguranje kvalitete usluge (QoS) i latencije (RTT) za određene bazene ili sustave.
U okviru zahtjeva za resursima mreže također se navode zahtjevi za izolacijom i/ili enkripcijom mrežnog prometa i preferiranim mehanizmima (802.1q, IPSec itd.).

Odabir arhitekture

U okviru ovog vodiča ne razmatra se drugi izbor osim arhitekture x86 i 100% virtualizacije poslužitelja. Stoga se odabir arhitekture računalnog podsustava svodi na izbor platforme za virtualizaciju poslužitelja, oblik poslužitelja i opće zahtjeve za konfiguraciju poslužitelja.

Ključna točka odabira je jasnost u korištenju klasičnog pristupa s razdvajanjem funkcija obrade, pohrane i prijenosa podataka ili konvergentnog.

Klasična arhitektura podrazumijeva korištenje inteligentnih vanjskih sustava za pohranu i prijenos podataka, dok serveri doprinose zajedničkom skupu fizičkih resursa samo procesorskom snagom i radnom memorijom. U ekstremnom slučaju, serveri postaju potpuno anonimni, nemajući niti vlastite diskove, čak ni sistemski identifikator. U tom slučaju koristi se podizanje OS-a ili hipervizora s ugrađenih flash uređaja ili s vanjskog sustava za pohranu podataka (boot from SAN).
U okviru klasične arhitekture, izbor između blade i rack sustava se prvenstveno donosi prema sljedećim načelima:
— Ekonomičnost (u prosjeku rack serveri su jeftiniji);
— Računalna gustoća (blade su viši);
— Potrošnja energije i ispuštanje topline (blade imaju višu specifičnu potrošnju po jedinici);
— Skalabilnost i upravljivost (blade u cjelini zahtijevaju manje napora pri velikim instalacijama);
— Korištenje proširivih kartica (za blade je vrlo ograničen izbor).
Konvergentna arhitektura (također poznata kao hiper-konvergentna) podrazumijeva kombiniranje funkcija obrade i pohrane podataka, što dovodi do korištenja lokalnih diskova servera i kao posljedicu odustajanje od form-faktora klasičnih blade sustava. Za konvergentne sustave koriste se ili rack serveri ili klasterski sustavi koji kombiniraju u jednoj kućištu nekoliko blade servera i lokalne diskove.

CPU / Memory

Za točan izračun konfiguracije treba razumjeti tip opterećenja za okolinu ili svaki od neovisnih klastera.
CPU bound – okruženje ograničeno na procesorsku snagu. Dodavanje radne memorije neće promijeniti performanse (broj VM-ova na serveru).
Memory bound – okruženje ograničeno radnom memorijom. Veća količina radne memorije na serveru omogućuje pokretanje većeg broja VM-ova na serveru.
GB / MHz (GB / pCPU) – prosječni odnos potrošnje te specifične opterećenja radne memorije i procesorske snage. Može se koristiti za izračun potrebnog volumena memorije pri zadanoj performansi i obrnuto.

Izračun konfiguracije servera

Prvo je potrebno odrediti sve vrste opterećenja i donijeti odluku o kombinaciji ili razdvajanju različitih računalnih pool-ova po raznim klastra.
Nakon toga, za svaki od definiranih klastera određuje se omjer GB / MHz uz poznato opterećenje. Ako opterećenje nije poznato unaprijed, ali postoji približno razumijevanje razine opterećenja procesorske snage, može se koristiti standardni omjer vCPU:pCPU za prevođenje zahtjeva pool-ova u fizičke.

Za svaki klaster zbroj zahtjeva pool-ova vCPU dijelimo s koeficijentom:
vCPUzbroj / vCPU:pCPU = pCPUzbroj – traženi broj fizičkih jezgri
pCPUzbroj / 1.25 = pCPUht – broj jezgri uz korekciju na Hyper-Threading
Pretpostavimo da je potrebno izračunati klaster sa 190 jezgri / 3.5 TB RAM-a. Pri tome prihvaćamo ciljano opterećenje procesorske snage od 50% i 75% za radnu memoriju.

pCPU
190
CPU util
50%

Mem
3500
Mem util
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

U ovom slučaju uvijek koristimo zaokruživanje na najbliži cijeli broj naviše (=ROUNDUP(A1;0)).
Iz tablice postaje očito da su uravnotežene prema ciljnim pokazateljima nekoliko konfiguracija poslužitelja:
— 26 poslužitelja 2*6c / 192 GB
— 19 poslužitelja 2*10c / 256 GB
— 10 poslužitelja 2*18c / 512 GB

Odabir između ovih konfiguracija dalje se mora vršiti uzimajući u obzir dodatne faktore, kao što su toplinski paket i dostupno hlađenje, već korišteni poslužitelji ili trošak.

Osobitosti odabira konfiguracije poslužitelja

Široke VM. U slučaju potrebe za smještanjem širokih VM (usporedivih s 1 NUMA čvorom i više) preporučuje se, koliko god je to moguće, odabrati poslužitelj s konfiguracijom koja omogućuje tim VM-ovima ostati unutar NUMA čvora. Kod velikog broja širokih VM postoji opasnost od fragmentacije resursa klastera, te se u tom slučaju odabiru poslužitelji koji omogućuju gusto smještanje širokih VM.

Veličina domene pojedinačnog kvara.

Odabir veličine poslužitelja također se vrši prema načelu minimizacije domene jedinstvenog kvara. Na primjer, prilikom odabira između:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Uz jednake uvjete, potrebno je odabrati drugu opciju, jer u slučaju kvara jednog poslužitelja (ili servisiranja) ne gubi se 33% resursa klastera, već 17%. Na isti način se prepolovljuje broj VM-ova i IS-a na koje je utjecala nesreća.

Izračun klasične SANS po performansama

Klasična SANS uvijek se izračunava prema najgorem scenariju, isključujući utjecaj operativnog keša i optimizacije operacija.
Kao osnovne pokazatelje performansi uzimamo mehaničku performansu diska (IOPSdisk):
— 7.2k – 75 IOPS
— 10k – 125 IOPS
— 15k – 175 IOPS

Dalje, broj diskova u disku poolu izračunava se prema sljedećoj formuli: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Gdje:
— TotalIOPS – ukupna potrebna performansa u IOPS s diska poola
— RW – postotak operacija čitanja
— RAIDpen – RAID kazna za odabrani nivo RAID-a

Više o RAID uređaju i RAID kazni razgovara se ovdje — Performanse SANS-a. Prvi deo. i Performanse SANS-a. Drugi deo. i Performanse SANS-a. Treći deo.

Na osnovu dobivenog broja diskova izračunavaju se mogući varijante koje zadovoljavaju zahtjeve za kapacitetom pohrane, uključujući varijante s višeslojnom pohranom.
Izračun sustava koji koriste SSD kao nivo pohrane razmatra se posebno.
Osobine izračuna sustava s Flash Cache

Flash Cache – opći naziv za sve brendirane tehnologije korištenja flash memorije kao drugog nivoa keša. Pri korištenju flash keša, SANS se obično izračunava za osiguravanje opterećenja s magnetskih diskova, dok vrhunsku opremu opslužuje keš.
Pri tome je važno razumjeti profil opterećenja i stepen lokalizacije zahtjeva prema blokovima pohrane. Flash keš je tehnologija za opterećenja s visokom lokalizacijom zahtjeva i praktički nije primjenjiva za ravnomjerno opterećene volumene (kao što su, na primjer, analitički sustavi).

Izračun hibridnih sustava low-end / mid-range

Hibridni sustavi donjih i srednjih klasa koriste višeslojnu pohranu s premještanjem podataka između nivoa prema rasporedu. Pri tome veličina bloka višeslojne pohrane kod najboljih modela iznosi 256 MB. Ove osobine ne omogućuju smatrajući tehnologiju višeslojne pohrane tehnologijom poboljšanja performansi, kako mnogi pogrešno misle. Višeslojna pohrana u sustavima donjih i srednjih klasa je tehnologija optimizacije troškova pohrane za sustave s izraženom neravnomjernošću opterećenja.

Za višeslojno pohranjivanje prvo se izračunava performansa gornjeg sloja, dok se donji sloj pohrane smatra jedino dopunskom kapacitetu pohrane. Za hibridni višeslojni sustav obavezna je upotreba tehnologije flash cache za višeslojni bazen s ciljem kompenzacije pada performansi za iznenada povećane podatke iz donjeg sloja.

Korištenje SSD-a u višeslojnim diskovnim bazenima

Korištenje SSD-a u višeslojnim diskovnim bazenima ima varijacije, ovisno o karakteristikama provedbe algoritama flash cachea od strane određenog proizvođača.
Opća praksa politike pohrane za diskovni bazen s razinom SSD-a – SSD first.
Flash Cache samo za čitanje. Za flash cache samo za čitanje, razina pohrane na SSD-u pojavljuje se kada je značajno lokalizirana operacija pisanja neovisna o cacheu.
Flash Cache za čitanje / pisanje. U slučaju flash cachea za pisanje, najprije se postavlja maksimalni volumen cachea, a razina pohrane na SSD-u pojavljuje se samo kada veličina cachea nije dovoljna za upravljanje svim lokaliziranim opterećenjem.
Izračun performansi SSD-a i cachea vrši se svaki put prema preporukama proizvođača, ali uvijek za najgori mogući scenarij.

Izvor: habr.com