{"id":35800,"date":"2019-10-31T22:06:24","date_gmt":"2019-10-31T19:06:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/dizajn-virtualizovannogo-tsod\/"},"modified":"2019-10-31T22:06:24","modified_gmt":"2019-10-31T19:06:24","slug":"dizajn-virtualizovannogo-tsod","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Dizajn virtualizovan\u00e9ho DC","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Dizajn
\n
\n\u00davod<\/b><\/p>\n

Informa\u010dn\u00fd syst\u00e9m je z poh\u013eadu pou\u017e\u00edvate\u013ea presne definovan\u00fd v normativite STN 51987 \u2013 \"automatizovan\u00fd syst\u00e9m, ktor\u00e9ho v\u00fdsledkom fungovania je prezent\u00e1cia v\u00fdstupn\u00fdch inform\u00e1ci\u00ed na \u010fal\u0161ie vyu\u017eitie\". Ak sa pozrieme na vn\u00fatorn\u00fa \u0161trukt\u00faru, v podstate ka\u017ed\u00fd IS predstavuje syst\u00e9m algoritmov realizovan\u00fdch v k\u00f3de, ktor\u00e9 s\u00fa navz\u00e1jom prepojen\u00e9. Vo v\u0161eobecnosti, pod\u013ea Turingovej\u2013Churchovej t\u00e9zy, algoritmus (a teda aj IS) uskuto\u010d\u0148uje transform\u00e1ciu mno\u017estva vstupn\u00fdch \u00fadajov na mno\u017estvo v\u00fdstupn\u00fdch \u00fadajov.
\nM\u00f4\u017eeme poveda\u0165, \u017ee v\u00fdznamom existencie informa\u010dn\u00e9ho syst\u00e9mu je transform\u00e1cia vstupn\u00fdch \u00fadajov. T\u00fdm p\u00e1dom, hodnota IS a cel\u00e9ho komplexu IS sa ur\u010duje cez hodnotu vstupn\u00fdch a v\u00fdstupn\u00fdch \u00fadajov.
\nNa z\u00e1klade toho by malo projektovanie za\u010d\u00edna\u0165 a vych\u00e1dza\u0165 z \u00fadajov, prisp\u00f4sobuj\u00fac architekt\u00faru a met\u00f3dy \u0161trukt\u00fare a v\u00fdznamu \u00fadajov.<\/p>\n

Ukladan\u00e9 \u00fadaje<\/b>
\nK\u013e\u00fa\u010dov\u00fdm krokom v pr\u00edprave na projektovanie je z\u00edska\u0165 charakteristiky v\u0161etk\u00fdch s\u00faborov \u00fadajov, ktor\u00e9 pl\u00e1nujeme spracov\u00e1va\u0165 a uchov\u00e1va\u0165. Tieto charakteristiky zah\u0155\u0148aj\u00fa:
\n \u2014 Objem \u00fadajov;
\n \u2014 Inform\u00e1cie o \u017eivotnom cykle \u00fadajov (pr\u00edrastok nov\u00fdch \u00fadajov, doba \u017eivotnosti, spracovanie zastaran\u00fdch \u00fadajov);
\n \u2014 Klasifik\u00e1cia \u00fadajov z poh\u013eadu vplyvu na hlavn\u00fd biznis spolo\u010dnosti (t.j. tri\u00e1da d\u00f4vernos\u0165, integrita, dostupnos\u0165) spolu s finan\u010dn\u00fdmi ukazovate\u013emi (napr. cena straty \u00fadajov za posledn\u00fa hodinu);
\n \u2014 Geografia spracovania \u00fadajov (fyzick\u00e1 poloha syst\u00e9mov spracovania);
\n \u2014 Po\u017eiadavky regul\u00e1torov na ka\u017ed\u00fa triedu \u00fadajov (napr. Z\u00e1kon \u010d. 152, PCI DSS).<\/p>\n

<\/a><\/noindex><\/p>\n

Informa\u010dn\u00e9 syst\u00e9my<\/b><\/p>\n

\u00dadaje nes\u00fa len ulo\u017een\u00e9, ale aj spracovan\u00e9 (transformovan\u00e9) informa\u010dn\u00fdmi syst\u00e9mami. Nasleduj\u00faci krok po z\u00edskan\u00ed charakterist\u00edk \u00fadajov je maxim\u00e1lne \u00fapln\u00e1 inventariz\u00e1cia informa\u010dn\u00fdch syst\u00e9mov, ich architektonick\u00fdch zvl\u00e1\u0161tnost\u00ed, vz\u00e1jomn\u00fdch z\u00e1vislost\u00ed a po\u017eiadaviek na infra\u0161trukt\u00faru v podmienen\u00fdch jednotk\u00e1ch pre \u0161tyri druhy zdrojov:
\n \u2014 Procesorov\u00fd v\u00fdkon;
\n \u2014 Objem opera\u010dnej pam\u00e4te;
\n \u2014 Po\u017eiadavky na objem a v\u00fdkon syst\u00e9mu ukladania \u00fadajov;
\n \u2014 Po\u017eiadavky na sie\u0165 prenosu \u00fadajov (extern\u00e9 kan\u00e1ly, kan\u00e1ly medzi komponentmi IS).
\nPo\u017eiadavky by mali by\u0165 na ka\u017ed\u00fd servis\/mikroslu\u017ebu v r\u00e1mci IS.
\nOsobitne treba zd\u00f4razni\u0165, \u017ee pre spr\u00e1vne navrhnutie je nevyhnutn\u00e1 existencia \u00fadajov o vplyve IS na hlavn\u00fd biznis spolo\u010dnosti vo forme n\u00e1kladov na prestoj IS (rubly za hodinu).<\/p>\n

Model hrozieb<\/b><\/p>\n

V nez\u00e1v\u00e4zn\u00fdch pr\u00edpadoch mus\u00ed by\u0165 k dispoz\u00edcii form\u00e1lny model hrozieb, vo\u010di ktor\u00fdm sa pl\u00e1nuje chr\u00e1ni\u0165 \u00fadaje\/slu\u017eby. Tento model hrozieb zah\u0155\u0148a nielen aspekty d\u00f4vernosti, ale aj integritu a dostupnos\u0165. T.j. napr\u00edklad:
\n \u2014 Zlyhanie fyzick\u00e9ho servera;
\n \u2014 Zlyhanie prep\u00edna\u010da top-of-the-rack;
\n \u2014 Pretrhnutie optick\u00e9ho komunika\u010dn\u00e9ho kan\u00e1la medzi DC;
\n \u2014 Zlyhanie opera\u010dnej S\u00da\u0421D celkom.
\nV niektor\u00fdch pr\u00edpadoch sa modely hrozieb p\u00ed\u0161u nielen pre infra\u0161trukt\u00farne komponenty, ale aj pre konkr\u00e9tne IS alebo ich komponenty, ako napr\u00edklad zlyhanie DBMS s logick\u00fdm zni\u010den\u00edm \u0161trukt\u00fary \u00fadajov.
\nV\u0161etky rozhodnutia v r\u00e1mci projektu ochrany pred nepop\u00edsanou hrozbou s\u00fa zbyto\u010dn\u00e9.<\/p>\n

Po\u017eiadavky regul\u00e1torov<\/b><\/p>\n

Ak spracov\u00e1van\u00e9 \u00fadaje podliehaj\u00fa osobitn\u00fdm pravidl\u00e1m stanoven\u00fdm regul\u00e1tormi, je nevyhnutn\u00e1 inform\u00e1cia o s\u00faboroch \u00fadajov a pravidl\u00e1ch spracovania\/ukladania.<\/p>\n

Cie\u013eov\u00e9 ukazovatele RPO\/RTO<\/b><\/p>\n

Navrhovanie ak\u00e9hoko\u013evek druhu ochrany si vy\u017eaduje existenciu ukazovate\u013eov cie\u013eovej straty \u00fadajov a cie\u013eov\u00e9ho \u010dasu na obnovenie slu\u017eby pre ka\u017ed\u00fa z pop\u00edsan\u00fdch hrozieb.
\nIde\u00e1lne by mali ma\u0165 RPO a RTO priraden\u00e9 n\u00e1klady na stratu \u00fadajov a prestoj v jednotke \u010dasu.<\/p>\n

\"Dizajn
\n
\nRozdelenie na pooly zdrojov<\/b><\/p>\n

Po zhroma\u017eden\u00ed v\u0161etk\u00fdch z\u00e1kladn\u00fdch vstupn\u00fdch inform\u00e1ci\u00ed je prv\u00fdm krokom skupinovanie s\u00faborov \u00fadajov a IS do poolov, vych\u00e1dzaj\u00fac z modelov hrozieb a po\u017eiadaviek regul\u00e1torov. Ur\u010duje sa, ak\u00fd typ rozdelenia r\u00f4znych poolov \u2013 softv\u00e9rovo na \u00farovni syst\u00e9mov\u00e9ho SW alebo fyzicky.
\nPr\u00edklady:
\n \u2014 Kont\u00fara spracov\u00e1vaj\u00faca osobn\u00e9 \u00fadaje je \u00faplne fyzicky oddelen\u00e1 od ostatn\u00fdch syst\u00e9mov;
\n \u2014 Z\u00e1lohy sa ukladaj\u00fa na samostatnej S\u00da\u0421D.<\/p>\n

Pri\u010dom pooly m\u00f4\u017eu ma\u0165 ne\u00fapln\u00fa nez\u00e1vislos\u0165, napr\u00edklad sa ur\u010duje dva pooly v\u00fdpo\u010dtov\u00fdch zdrojov (procesorov\u00fd v\u00fdkon + opera\u010dn\u00e1 pam\u00e4\u0165), ktor\u00e9 vyu\u017e\u00edvaj\u00fa jeden pool \u00falo\u017en\u00fdch \u00fadajov a jeden pool zdrojov prenosu \u00fadajov.<\/p>\n

Procesorov\u00fd v\u00fdkon<\/b><\/p>\n

\"Dizajn
\n
\nAbstraktn\u00e9 po\u017eiadavky na procesorov\u00fd v\u00fdkon virtualizovan\u00e9ho d\u00e1tov\u00e9ho centra sa meraj\u00fa po\u010dtom virtu\u00e1lnych procesorov (vCPU) a koeficientom ich konsolid\u00e1cie na fyzick\u00fdch procesoroch (pCPU). V tomto konkr\u00e9tnom pr\u00edpade 1 pCPU = 1 fyzick\u00e9 jadro procesora (bez oh\u013eadu na Hyper-Threading). Po\u010det vCPU sa s\u010d\u00edta vo v\u0161etk\u00fdch definovan\u00fdch baz\u00e9noch zdrojov (z ka\u017ed\u00e9ho z nich m\u00f4\u017ee ma\u0165 svoj koeficient konsolid\u00e1cie).
\nKoeficient konsolid\u00e1cie pre za\u0165a\u017een\u00e9 syst\u00e9my sa z\u00edskava empiricky, vych\u00e1dzaj\u00fac z u\u017e existuj\u00facej infra\u0161trukt\u00fary, alebo pri pilotnej in\u0161tal\u00e1cii a z\u00e1\u0165a\u017eovom testovan\u00ed. Pre neza\u0165a\u017een\u00e9 syst\u00e9my platia \u201ebest practice\u201c. Konkr\u00e9tne, VMware ozna\u010duje priemern\u00fd koeficient 8:1.<\/p>\n

Opera\u010dn\u00e1 pam\u00e4\u0165<\/b><\/p>\n

Celkov\u00e1 po\u017eiadavka na opera\u010dn\u00fa pam\u00e4\u0165 sa z\u00edskava jednoduch\u00fdm s\u010d\u00edtan\u00edm. Pou\u017e\u00edvanie prepredaja opera\u010dnej pam\u00e4te sa neodpor\u00fa\u010da.<\/p>\n

Skladovacie zdroje<\/b><\/p>\n

Po\u017eiadavky na skladovacie zdroje sa z\u00edskavaj\u00fa jednoduch\u00fdm s\u010d\u00edtan\u00edm v\u0161etk\u00fdch baz\u00e9nov pod\u013ea objemu a v\u00fdkonu.
\nPo\u017eiadavky na v\u00fdkon sa vyjadruj\u00fa v IOPS v kombin\u00e1cii so stredn\u00fdm pomerom \u010d\u00edtanie\/z\u00e1pis a v pr\u00edpade potreby maxim\u00e1lnou latenciou odpovede.
\nSamostatne by mali by\u0165 uveden\u00e9 po\u017eiadavky na zabezpe\u010denie kvality slu\u017eby (QoS) pre konkr\u00e9tne baz\u00e9ny alebo syst\u00e9my.<\/p>\n

Zdroje siete pren\u00e1\u0161ania d\u00e1t<\/b><\/p>\n

Po\u017eiadavky na sie\u0165 pren\u00e1\u0161ania d\u00e1t sa z\u00edskavaj\u00fa jednoduch\u00fdm s\u010d\u00edtan\u00edm v\u0161etk\u00fdch baz\u00e9nov priepustnosti.
\nSamostatne by mali by\u0165 uveden\u00e9 po\u017eiadavky na zabezpe\u010denie kvality slu\u017eby (QoS) a latenci\u00ed (RTT) pre konkr\u00e9tne baz\u00e9ny alebo syst\u00e9my.
\nV r\u00e1mci po\u017eiadaviek na zdroje siete pren\u00e1\u0161ania d\u00e1t sa tie\u017e uv\u00e1dzaj\u00fa po\u017eiadavky na izol\u00e1ciu a\/alebo \u0161ifrovanie sie\u0165ov\u00e9ho prenosu a preferovan\u00e9 mechanizmy (802.1q, IPSec at\u010f.)<\/p>\n

V\u00fdber architekt\u00fary<\/b><\/p>\n

V r\u00e1mci tohto sprievodcu sa neberie do \u00favahy in\u00fd v\u00fdber ako architekt\u00fara x86 a 100% virtualiz\u00e1cia serverov. Preto sa v\u00fdber architekt\u00fary v\u00fdpo\u010dtovej subsyst\u00e9my zu\u017euje na vo\u013ebu platformy serverovej virtualiz\u00e1cie, form factor serverov a celkov\u00e9 po\u017eiadavky na konfigur\u00e1ciu serverov.<\/p>\n

K\u013e\u00fa\u010dov\u00fdm bodom vo v\u00fdbere je jednozna\u010dnos\u0165 v pou\u017e\u00edvan\u00ed klasick\u00e9ho pr\u00edstupu s rozdelen\u00edm funkci\u00ed spracovania, ukladania a prenosu d\u00e1t alebo konvergovan\u00e9ho pr\u00edstupu.<\/p>\n

Klasick\u00e1 architekt\u00fara<\/i> predpoklad\u00e1 pou\u017e\u00edvanie inteligentn\u00fdch extern\u00fdch \u00falo\u017en\u00fdch a prenosov\u00fdch syst\u00e9mov, zatia\u013e \u010do servery do spolo\u010dn\u00e9ho s\u00faboru fyzick\u00fdch zdrojov prid\u00e1vaj\u00fa iba procesorov\u00fd v\u00fdkon a opera\u010dn\u00fa pam\u00e4\u0165. V extr\u00e9mnom pr\u00edpade sa servery st\u00e1vaj\u00fa \u00faplne anonymn\u00fdmi, nemaj\u00fa nielen vlastn\u00e9 disky, ale ani syst\u00e9mov\u00fd identifik\u00e1tor. V takomto pr\u00edpade sa pou\u017e\u00edva zavedenie opera\u010dn\u00e9ho syst\u00e9mu alebo hyperv\u00edzora z integrovan\u00fdch flash pam\u00e4t\u00ed alebo z extern\u00e9ho \u00falo\u017en\u00e9ho syst\u00e9mu (boot from SAN).
\nV r\u00e1mci klasickej architekt\u00fary sa v\u00fdber medzi blade a rack vykon\u00e1va predov\u0161etk\u00fdm na z\u00e1klade nasleduj\u00facich princ\u00edpov:
\n \u2014 Ekonomick\u00e1 efekt\u00edvnos\u0165 (v priemere s\u00fa rackov\u00e9 servery lacnej\u0161ie);
\n \u2014 V\u00fdpo\u010dtov\u00e1 hustota (u blade je vy\u0161\u0161ia);
\n \u2014 Spotreba energie a tepeln\u00e9 vy\u017earovanie (u blade je vy\u0161\u0161ie na jednotku);
\n \u2014 \u0160k\u00e1lovate\u013enos\u0165 a spravovate\u013enos\u0165 (blade vo v\u0161eobecnosti vy\u017eaduje menej \u00fasilia pri ve\u013ek\u00fdch in\u0161tal\u00e1ci\u00e1ch);
\n \u2014 Pou\u017e\u00edvanie roz\u0161iruj\u00facich kariet (pre blade je ve\u013emi obmedzen\u00fd v\u00fdber).
\nKonvergentn\u00e1 architekt\u00fara<\/i> (tie\u017e zn\u00e1ma ako hyperkonvergentn\u00e1<\/i>) predpoklad\u00e1 kombin\u00e1ciu funkci\u00ed spracovania a ukladania d\u00e1t, \u010do vedie k pou\u017e\u00edvaniu lok\u00e1lnych diskov serverov a ako d\u00f4sledok odmietaniu form\u00e1tov klasick\u00fdch blade. Pre konvergentn\u00e9 syst\u00e9my sa pou\u017e\u00edvaj\u00fa bu\u010f rackov\u00e9 servery, alebo klastrov\u00e9 syst\u00e9my, ktor\u00e9 kombinuj\u00fa v jednom \u0161asi nieko\u013eko blade serverov a lok\u00e1lne disky.<\/p>\n

CPU \/ Memory <\/b><\/p>\n

Na spr\u00e1vny v\u00fdpo\u010det konfigur\u00e1cie je potrebn\u00e9 pochopi\u0165 typ za\u0165a\u017eenia pre prostredie alebo ka\u017ed\u00e9ho z nez\u00e1visl\u00fdch klastrov.
\nCPU bound<\/i> \u2013 prostredie obmedzen\u00e9 v\u00fdkonnos\u0165ou procesora. Pridanie opera\u010dnej pam\u00e4te ni\u010d nezmen\u00ed z h\u013eadiska v\u00fdkonu (po\u010det VM na server).
\nMemory bound<\/i> \u2013 prostredie obmedzen\u00e9 opera\u010dnou pam\u00e4\u0165ou. Viac opera\u010dnej pam\u00e4te na serveri umo\u017e\u0148uje spusti\u0165 viac VM na server.
\nGB \/ MHz (GB \/ pCPU) \u2013 priemern\u00fd pomer spotreby tejto konkr\u00e9tnej za\u0165a\u017een\u00edm opera\u010dnej pam\u00e4te a procesorov\u00e9ho v\u00fdkonu. M\u00f4\u017ee sa pou\u017e\u00edva\u0165 na v\u00fdpo\u010dty potrebn\u00e9ho objemu pam\u00e4te pri ur\u010denej v\u00fdkonnosti a naopak. <\/p>\n

V\u00fdpo\u010det konfigur\u00e1cie servera<\/b><\/p>\n

\"Dizajn
\n
\nNa za\u010diatok je potrebn\u00e9 ur\u010di\u0165 v\u0161etky druhy za\u0165a\u017eenia a rozhodn\u00fa\u0165 o kombinovan\u00ed alebo rozdelen\u00ed r\u00f4znych v\u00fdpo\u010dtov\u00fdch poolov do r\u00f4znych klastrov.
\n\u010ealej sa pre ka\u017ed\u00fd z ur\u010den\u00fdch klastrov ur\u010duje pomer GB \/ MHz pri vopred zn\u00e1mych za\u0165a\u017eeniach. Ak za\u0165a\u017eenie nie je zn\u00e1me vopred, ale existuje pribli\u017en\u00e1 predstava o \u00farovni vy\u0165a\u017eenia procesorovej kapacity, je mo\u017en\u00e9 pou\u017ei\u0165 \u0161tandardn\u00e9 koeficienty vCPU:pCPU na prevedenie po\u017eiadaviek poolov na fyzick\u00e9. <\/p>\n

Pre ka\u017ed\u00fd klaster sa s\u00fa\u010det po\u017eiadaviek poolov vCPU del\u00ed koeficientom:
\nvCPUsum \/ vCPU:pCPU = pCPUsum \u2013 po\u017eadovan\u00fd po\u010det fyzick\u00fdch jadier
\npCPUsum \/ 1.25 = pCPUht \u2013 po\u010det jadier s oh\u013eadom na Hyper-Threading
\nPredpokladajme, \u017ee je potrebn\u00e9 vykona\u0165 v\u00fdpo\u010det klastra na 190 jadier \/ 3.5TB RAM. Pri tom zoh\u013ead\u0148ujeme cie\u013eov\u00fa 50% vy\u0165a\u017eenos\u0165 procesorovej kapacity a 75% vy\u0165a\u017eenie opera\u010dnej pam\u00e4te.<\/p>\n

pCPU<\/b>
\n190
\nCPU vy\u0165a\u017e.<\/b>
\n50%<\/p>\n

Pam\u00e4\u0165<\/b>
\n3500
\nVy\u0165a\u017e. pam\u00e4\u0165<\/b>
\n75%<\/p>\n

Socket<\/b>
\nJadro<\/b>
\nSrv \/ CPU<\/b>
\nSrv Pam\u00e4\u0165<\/b>
\nSrv \/ Pam\u00e4\u0165<\/b><\/p>\n

2
\n6
\n25,3
\n128
\n36,5<\/p>\n

2
\n8
\n19,0
\n192
\n24,3<\/p>\n

2
\n10
\n15,2
\n256
\n18,2<\/p>\n

2
\n14
\n10,9
\n384
\n12,2<\/p>\n

2
\n18
\n8,4
\n512
\n9,1<\/p>\n

V tomto pr\u00edpade v\u017edy pou\u017e\u00edvame zaokr\u00fah\u013eovanie na najbli\u017e\u0161ie cel\u00e9 nahor (=ROUNDUP(A1;0)).
\nZ tabu\u013eky je zrejm\u00e9, \u017ee vyv\u00e1\u017een\u00fdmi pre cie\u013eov\u00e9 parametre s\u00fa nieko\u013eko konfigur\u00e1ci\u00ed serverov:
\n \u2014 26 serverov 2*6c \/ 192 GB
\n \u2014 19 serverov 2*10c \/ 256 GB
\n \u2014 10 serverov 2*18c \/ 512 GB <\/p>\n

V\u00fdber z t\u00fdchto konfigur\u00e1ci\u00ed je potrebn\u00e9 urobi\u0165 na z\u00e1klade \u010fal\u0161\u00edch faktorov, ako s\u00fa napr\u00edklad tepeln\u00fd v\u00fdkon a dostupn\u00e9 chladenie, u\u017e pou\u017e\u00edvan\u00e9 servery alebo n\u00e1klady.<\/p>\n

\u0160pecifik\u00e1 v\u00fdberu konfigur\u00e1cie servera<\/b><\/p>\n

\u0160irok\u00e9 VM. V pr\u00edpade potreby umiestnenia \u0161irok\u00fdch VM (porovnate\u013en\u00fdch s 1 uzlom NUMA a viac) sa odpor\u00fa\u010da, ak je to mo\u017en\u00e9, vybra\u0165 server s konfigur\u00e1ciou, ktor\u00e1 umo\u017en\u00ed, aby tak\u00e9 VM zostali v r\u00e1mci uzla NUMA. Pri ve\u013ekom po\u010dte \u0161irok\u00fdch VM hroz\u00ed riziko fragment\u00e1cie zdrojov klastrov, a v takom pr\u00edpade sa vyberaj\u00fa servery, ktor\u00e9 umo\u017e\u0148uj\u00fa umiestni\u0165 \u0161irok\u00e9 VM maxim\u00e1lne tesne.<\/p>\n

Ve\u013ekos\u0165 dom\u00e9ny jedine\u010dn\u00e9ho zlyhania.<\/b> <\/p>\n

V\u00fdber ve\u013ekosti servera sa uskuto\u010d\u0148uje aj na z\u00e1klade z\u00e1sady minimaliz\u00e1cie dom\u00e9ny jedine\u010dn\u00e9ho zlyhania. Napr\u00edklad pri v\u00fdbere medzi:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nPri rovnak\u00fdch podmienkach je potrebn\u00e9 vybra\u0165 druh\u00fa mo\u017enos\u0165, preto\u017ee pri v\u00fdpadku jedn\u00e9ho servera (alebo \u00fadr\u017ebe) sa nestr\u00e1ca 33% zdrojov klastrov, ale 17%. Rovnako sa tie\u017e zn\u00ed\u017ei po\u010det VM a IS, na ktor\u00fdch sa odrazila hav\u00e1ria.<\/p>\n

V\u00fdpo\u010det klasickej \u00falo\u017enej s\u00fastavy pod\u013ea v\u00fdkonu<\/b><\/p>\n

\"Dizajn
\n
\nKlasick\u00e1 \u00falo\u017en\u00e1 s\u00fastava sa v\u017edy vypo\u010d\u00edta na z\u00e1klade najhor\u0161ieho scen\u00e1ra (worst case scenario), pri\u010dom sa vylu\u010duje vplyv opera\u010dnej cache a optimaliz\u00e1cie oper\u00e1ci\u00ed.
\nAko z\u00e1kladn\u00e9 ukazovatele v\u00fdkonu vezmeme mechanick\u00fd v\u00fdkon z disku (IOPSdisk):
\n \u2014 7,2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

\u010ealej sa po\u010det diskov v diskovom poole vypo\u010d\u00edta pod\u013ea nasleduj\u00facej formul\u00e1cie: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. Kde:
\n \u2014 TotalIOPS<\/i> \u2013 s\u00fahrnn\u00fd po\u017eadovan\u00fd v\u00fdkon v IOPS z diskov\u00e9ho poolu
\n \u2014 RW<\/i> \u2013 percentu\u00e1lny podiel oper\u00e1ci\u00ed \u010d\u00edtania
\n \u2014 RAIDpen<\/i> \u2013 RAID penaliz\u00e1cia pre zvolen\u00fa \u00farove\u0148 RAID<\/p>\n

Viac o zariaden\u00ed RAID a RAID Penalty sa dozviete tu \u2014 V\u00fdkon \u00falo\u017enej s\u00fastavy. \u010cas\u0165 prv\u00e1.<\/a><\/noindex> a V\u00fdkon \u00falo\u017enej s\u00fastavy. \u010cas\u0165 druh\u00e1.<\/a><\/noindex> a V\u00fdkon \u00falo\u017enej s\u00fastavy. \u010cas\u0165 tretia<\/a><\/noindex><\/p>\n

Na z\u00e1klade z\u00edskan\u00e9ho po\u010dtu diskov sa vypo\u010d\u00edtaj\u00fa mo\u017en\u00e9 varianty, ktor\u00e9 sp\u013a\u0148aj\u00fa po\u017eiadavky na kapacitu \u00falo\u017eiska, vr\u00e1tane variantov s viacer\u00fdmi \u00farov\u0148ami uchov\u00e1vania.
\nV\u00fdpo\u010det syst\u00e9mov s pou\u017eit\u00edm SSD ako \u00falo\u017enej \u00farovne sa posudzuje samostatne.
\n\u0160pecifik\u00e1 v\u00fdpo\u010dtu syst\u00e9mov s Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 v\u0161eobecn\u00fd n\u00e1zov pre v\u0161etky firemn\u00e9 technol\u00f3gie pou\u017e\u00edvania flash pam\u00e4te ako cache druhej \u00farovne. Pri pou\u017eit\u00ed flash cache sa \u00falo\u017en\u00e1 s\u00fastava zv\u00e4\u010d\u0161a vypo\u010d\u00edta pre zaistenie za\u0165a\u017eenej prev\u00e1dzky z magnetick\u00fdch diskov, pri\u010dom vrcholov\u00fa prev\u00e1dzku zabezpe\u010duje cache.
\nPri tom je potrebn\u00e9 pochopi\u0165 profil za\u0165a\u017eenia a stup\u0148u lokaliz\u00e1cie pr\u00edstupov k blokom \u00falo\u017en\u00fdch objemov. Flash cache je technol\u00f3gia pre za\u0165a\u017eenia s vysokou lokaliz\u00e1ciou po\u017eiadaviek a prakticky nie je aplikovate\u013en\u00e1 pre rovnomerne za\u0165a\u017een\u00e9 objemy (ako napr\u00edklad pre analytick\u00e9 syst\u00e9my). <\/p>\n

V\u00fdpo\u010det hybridn\u00fdch syst\u00e9mov low-end \/ mid-range<\/b><\/p>\n

Hybridn\u00e9 syst\u00e9my ni\u017e\u0161ej a strednej triedy pou\u017e\u00edvaj\u00fa viacer\u00e9 \u00farovne ukladan\u00ed s presunom \u00fadajov medzi \u00farov\u0148ami pod\u013ea \u010dasov\u00e9ho pl\u00e1nu. Ve\u013ekos\u0165 bloku viacer\u00fdch \u00farovn\u00ed uchov\u00e1vania u najlep\u0161\u00edch modelov dosahuje 256 MB. Tieto \u0161pecifik\u00e1 neumo\u017e\u0148uj\u00fa pova\u017eova\u0165 technol\u00f3giu viacer\u00fdch \u00farovn\u00ed uchov\u00e1vania za technol\u00f3giu zvy\u0161ovania v\u00fdkonu, ako sa mylne domnieva mnoho \u013eud\u00ed. Viac\u00farov\u0148ov\u00e9 uchov\u00e1vanie v syst\u00e9moch ni\u017e\u0161ej a strednej triedy je technol\u00f3gia optimaliz\u00e1cie n\u00e1kladov na uchov\u00e1vanie pre syst\u00e9my s v\u00fdraznou nerovnomernos\u0165ou z\u00e1\u0165a\u017ee.<\/p>\n

Pri mnohovrstvovom \u00falo\u017een\u00ed sa prim\u00e1rne posudzuje v\u00fdkon na hornej \u00farovni, zatia\u013e \u010do doln\u00e1 \u00farove\u0148 ukladania sa pova\u017euje iba za doplnkov\u00fa kapacitu \u00falo\u017eiska. Pre hybridn\u00fd mnohovrstvov\u00fd syst\u00e9m je nevyhnutn\u00e9 pou\u017ei\u0165 technol\u00f3giu flash cache pre mnohovrstvov\u00fd pool s cie\u013eom kompenzova\u0165 pokles v\u00fdkonu pre n\u00e1hle sa zahriate \u00fadaje z dolnej \u00farovne.<\/p>\n

Pou\u017eitie SSD v mnohovrstvovom diskovom poole<\/b><\/p>\n

\"Dizajn
\n
\nPou\u017eitie SSD v mnohovrstvovom diskovom poole m\u00e1 vari\u00e1cie v z\u00e1vislosti od \u0161pecif\u00edk implement\u00e1cie algoritmov flash cache od tohto v\u00fdrobcu.
\nObecn\u00e1 prax politiky ukladania pre diskov\u00fd pool s \u00farov\u0148ou SSD je - SSD najprv.
\nRead Only Flash Cache.<\/i> Pre flash cache iba na \u010d\u00edtanie \u00farove\u0148 ukladania na SSD sa objavuje pri v\u00fdznamnej lokaliz\u00e1cii oper\u00e1ci\u00ed z\u00e1pisu nez\u00e1visle od cache.
\nRead \/ Write Flash Cache.<\/i> V pr\u00edpade flash cache na z\u00e1pis sa najprv nastav\u00ed maxim\u00e1lny objem cache a \u00farove\u0148 ukladania na SSD sa objavuje len pri nedostato\u010dnosti ve\u013ekosti cache na obsluhu celej lokalizovanej z\u00e1\u0165a\u017ee.
\nV\u00fdkon SSD a cache sa vypo\u010d\u00edtava ka\u017ed\u00fdkr\u00e1t na z\u00e1klade odpor\u00fa\u010dan\u00ed v\u00fdrobcu, ale v\u017edy pre najhor\u0161\u00ed variant.
\n
Zdroj: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0441 \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f \u0445\u043e\u0440\u043e\u0448\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u0435\u0442\u0441\u044f \u0432 \u0413\u041e\u0421\u0422 \u0420\u0412 51987 \u2014 \u00ab\u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u043e\u043c \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0432\u044b\u0445\u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0434\u043b\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f\u00bb. \u0415\u0441\u043b\u0438 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0442\u044c \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u044e\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443, \u0442\u043e \u043f\u043e \u0441\u0443\u0442\u0438 \u043b\u044e\u0431\u0430\u044f \u0418\u0421 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439 \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u0432 \u043a\u043e\u0434\u0435 \u0432\u0437\u0430\u0438\u043c\u043e\u0441\u0432\u044f\u0437\u0430\u043d\u043d\u044b\u0445 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c\u043e\u0432. \u0412 \u0448\u0438\u0440\u043e\u043a\u043e\u043c \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0438 \u0442\u0435\u0437\u0438\u0441\u0430 \u0422\u044c\u044e\u0440\u0438\u043d\u0433\u0430-\u0427\u0435\u0440\u0447\u0430 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c (\u0430 \u0441\u043b-\u043d\u043e \u0418\u0421) \u043e\u0441\u0443\u0449\u0435\u0441\u0442\u0432\u043b\u044f\u0435\u0442 \u0442\u0440\u0430\u043d\u0441\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044e \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0430 \u0432\u0445\u043e\u0434\u043d\u044b\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26806,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35800","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Dizajn virtualizovan\u00e9ho d\u00e1tov\u00e9ho centra | ProHoster","description":"\u00davod Informa\u010dn\u00fd syst\u00e9m s bodom.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0438\u0437\u0430\u0439\u043d \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u043e\u0433\u043e \u0426\u041e\u0414 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0441 \u0442\u043e\u0447\u043a\u0438.","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:06:24+00:00","article:modified_time":"2019-10-31T19:06:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35800","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 00:48:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:06:24","updated":"2026-01-22 00:48:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}