{"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\/ro\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Designul centrului de date virtualizat","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Designul
\n
\nIntroducere<\/b><\/p>\n

Sistemul informa\u021bional, din perspectiva utilizatorului, este bine definit \u00een GOST RV 51987 \u2014 \u201esistem automatizat, a c\u0103rui func\u021bionare rezult\u0103 \u00een prezentarea informa\u021biei de ie\u0219ire pentru utilizare ulterioar\u0103\u201d. Dac\u0103 examin\u0103m structura intern\u0103, orice SI este, \u00een esen\u021b\u0103, un sistem de algoritmi interconecta\u021bi realizat \u00een cod. \u00cen sens larg, teza lui Turing-Church afirm\u0103 c\u0103 algoritmul (\u0219i, prin urmare, SI) realizeaz\u0103 transformarea unui set de date de intrare \u00eentr-un set de date de ie\u0219ire.
\nSe poate spune chiar c\u0103 sensul existen\u021bei unui sistem informa\u021bional const\u0103 \u00een transformarea datelor de intrare. Prin urmare, valoarea SI \u0219i a \u00eentregului complex de SI este determinat\u0103 prin valoarea datelor de intrare \u0219i de ie\u0219ire.
\nPe baza aceasta, proiectarea ar trebui s\u0103 \u00eenceap\u0103 \u0219i s\u0103 se bazeze pe date, adapt\u00e2nd arhitectura \u0219i metodele la structura \u0219i importan\u021ba datelor.<\/p>\n

Datele stocate<\/b>
\nUn pas-cheie \u00een preg\u0103tirea proiect\u0103rii este ob\u021binerea caracteristicilor tuturor seturilor de date planificate pentru a fi procesate \u0219i stocate. Aceste caracteristici includ:
\n \u2014 Volumul de date;
\n \u2014 Informa\u021bii despre ciclul de via\u021b\u0103 al datelor (cre\u0219terea datelor noi, durata de via\u021b\u0103, procesarea datelor \u00eenvechite);
\n \u2014 Clasificarea datelor din perspectiva influen\u021bei asupra afacerii principale a companiei (acestea fiind cele trei aspecte: confiden\u021bialitate, integritate, disponibilitate) \u00eempreun\u0103 cu indicatorii financiari (de exemplu, costul pierderii de date pe ultima or\u0103);
\n \u2014 Geografia proces\u0103rii datelor (amplasarea fizic\u0103 a sistemelor de procesare);
\n \u2014 Cerin\u021bele reglementatorului pentru fiecare clas\u0103 de date (de exemplu, Legea Fed. 152, PCI DSS).<\/p>\n

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

Sistemele informa\u021bionale<\/b><\/p>\n

Datele nu doar c\u0103 sunt stocate, dar sunt \u0219i procesate (transformate) de sistemele informa\u021bionale. Urm\u0103torul pas dup\u0103 ob\u021binerea caracteristicilor datelor este realizarea unei inventariz\u0103ri complete a sistemelor informa\u021bionale, a caracteristicilor arhitecturale, interdependen\u021belor \u0219i cerin\u021belor infrastructurii \u00een unit\u0103\u021bi condi\u021bionate pentru cele patru tipuri de resurse:
\n \u2014 Capacitatea de calcul a procesorului;
\n \u2014 Volumul memoriei RAM;
\n \u2014 Cerin\u021bele pentru volumul \u0219i performan\u021ba sistemului de stocare a datelor;
\n \u2014 Cerin\u021bele pentru re\u021beaua de transfer de date (canale externe, canale \u00eentre componentele SI).
\nCerin\u021bele trebuie s\u0103 fie pentru fiecare serviciu\/microserviciu din cadrul IS.
\nEste important s\u0103 men\u021bion\u0103m c\u0103, pentru o proiectare corect\u0103, este necesar s\u0103 existe date despre impactul IS asupra afacerii principale a companiei, sub form\u0103 de costuri de nefunc\u021bionare a IS (lei pe or\u0103).<\/p>\n

Modelul amenin\u021b\u0103rilor<\/b><\/p>\n

Trebuie s\u0103 existe obligatoriu un model formal al amenin\u021b\u0103rilor, \u00eempotriva c\u0103rora se intendenteaz\u0103 s\u0103 se protejeze datele\/serviciile. Acest model al amenin\u021b\u0103rilor include nu doar aspectele confiden\u021bialit\u0103\u021bii, ci \u0219i integrit\u0103\u021bii \u0219i disponibilit\u0103\u021bii. Adic\u0103, de exemplu:
\n \u2014 Defec\u021biunea unui server fizic;
\n \u2014 Defec\u021biunea unui switch top-of-the-rack;
\n \u2014 Interuperea canalului optic de comunicare \u00eentre data center-e;
\n \u2014 Defec\u021biunea complet\u0103 a unui sistem de stocare a datelor opera\u021bionale.
\n\u00cen unele cazuri, modelele amenin\u021b\u0103rilor sunt redactate nu doar pentru componentele infrastructurii, ci \u0219i pentru anumite IS sau componentele acestora, cum ar fi e\u0219ecul SGBD-ului cu distrugerea logic\u0103 a structurii datelor.
\nToate solu\u021biile din cadrul proiectului pentru protec\u021bia \u00eempotriva amenin\u021b\u0103rilor neidentificate sunt inutile.<\/p>\n

Cerin\u021bele reglementatorului<\/b><\/p>\n

Dac\u0103 datele procesate sunt supuse unor reguli speciale stabilite de reglementatori, este obligatorie informa\u021bia despre seturile de date \u0219i regulile de procesare\/stocare.<\/p>\n

Indicatorii \u021binti\u021bi RPO\/RTO<\/b><\/p>\n

Proiectarea oric\u0103rui tip de protec\u021bie necesit\u0103 existen\u021ba indicatorilor pentru pierderile acceptabile de date \u0219i timpul dorit de recuperare a serviciului pentru fiecare dintre amenin\u021b\u0103rile descrise.
\n\u00cen ideal, RPO \u0219i RTO ar trebui s\u0103 aib\u0103 costuri asociate pentru pierderea datelor \u0219i nefunc\u021bionare pe unitatea de timp.<\/p>\n

\"Designul
\n
\n\u00cemp\u0103r\u021birea \u00een grupuri de resurse<\/b><\/p>\n

Dup\u0103 colectarea tuturor informa\u021biilor ini\u021biale, primul pas este gruparea seturilor de date \u0219i IS \u00een grupuri, pe baza modelului amenin\u021b\u0103rilor \u0219i cerin\u021belor reglementatorilor. Se determin\u0103 tipul de separare a diferitelor grupuri \u2013 software la nivel de software de sistem sau fizic.
\nExemple:
\n \u2014 Conturul care prelucreaz\u0103 date personale este complet separat fizic de celelalte sisteme;
\n \u2014 Copiile de rezerv\u0103 sunt p\u0103strate pe un sistem de stocare a datelor separat.<\/p>\n

\u00cen acest context, grupurile pot avea independen\u021b\u0103 incomplet\u0103; de exemplu, sunt definite dou\u0103 grupuri de resurse de calcul (capacitate de procesare + memorie RAM), care utilizeaz\u0103 un singur grup de stocare a datelor \u0219i un singur grup de resurse de transmitere a datelor.<\/p>\n

Capacitate de procesare<\/b><\/p>\n

\"Designul
\n
\nNecesitatea abstract\u0103 de putere de procesare a unui centru de date virtualizat este m\u0103surat\u0103 \u00een num\u0103rul de procesoare virtuale (vCPU) \u0219i \u00een coeficientul de consolidare a acestora pe procesoarele fizice (pCPU). \u00cen acest caz specific, 1 pCPU = 1 nucleu fizic de procesor (f\u0103r\u0103 a lua \u00een considerare Hyper-Threading). Num\u0103rul de vCPU se acumuleaz\u0103 pe toate pool-urile definite de resurse (fiecare dintre acestea put\u00e2nd avea propriul coeficient de consolidare).
\nCoeficientul de consolidare pentru sistemele \u00eenc\u0103rcate se ob\u021bine empiric, pe baza infrastructurii deja existente sau prin instalarea pilot \u0219i testarea de \u00eenc\u0103rcare. Pentru sistemele ne\u00eenc\u0103rcate se aplic\u0103 \u201ebest practice\u201d. \u00cen special, VMware consider\u0103 un coeficient mediu de 8:1.<\/p>\n

Memorie RAM<\/b><\/p>\n

Necesitatea total\u0103 de memorie opera\u021bional\u0103 se ob\u021bine prin simpla sumare. Utilizarea re-subscrierii memoriei opera\u021bionale nu este recomandat\u0103.<\/p>\n

Resurse de stocare<\/b><\/p>\n

Cerin\u021bele pentru resursele de stocare se ob\u021bin prin simpla sumare a tuturor pool-urilor \u00een func\u021bie de volum \u0219i performan\u021b\u0103.
\nCerin\u021bele de performan\u021b\u0103 se exprim\u0103 \u00een IOPS, \u00een combina\u021bie cu raportul mediu de citire\/scriere \u0219i, dac\u0103 este necesar, cu \u00eent\u00e2rzierea maxim\u0103 a r\u0103spunsului.
\nTrebuie specificate separat cerin\u021bele pentru asigurarea calit\u0103\u021bii serviciilor (QoS) pentru pool-uri sau sisteme specifice.<\/p>\n

Resurse de re\u021bea de date<\/b><\/p>\n

Cerin\u021bele pentru re\u021beaua de date se ob\u021bin prin simpla sumare a tuturor pool-urilor de l\u0103\u021bime de band\u0103.
\nTrebuie specificate separat cerin\u021bele pentru asigurarea calit\u0103\u021bii serviciilor (QoS) \u0219i \u00eent\u00e2rzierilor (RTT) pentru pool-uri sau sisteme specifice.
\n\u00cen cadrul cerin\u021belor pentru resursele re\u021belei de date, se specific\u0103 de asemenea cerin\u021bele pentru izolare \u0219i\/sau criptarea traficului de re\u021bea \u0219i mecanismele preferate (802.1q, IPSec etc.).<\/p>\n

Alegerea arhitecturii<\/b><\/p>\n

\u00cen cadrul acestui ghid, nu se ia \u00een considerare alt\u0103 alegere dec\u00e2t arhitectura x86 \u0219i virtualizarea 100% a serverelor. Prin urmare, alegerea arhitecturii subsistemului de calcul se reduce la selec\u021bia platformei de virtualizare a serverului, a factorului de form\u0103 al serverelor \u0219i a cerin\u021belor generale privind configura\u021bia serverelor.<\/p>\n

Un aspect esen\u021bial al alegerii este claritatea \u00een utilizarea abord\u0103rii clasice cu separarea func\u021biilor de procesare, stocare \u0219i transmitere a datelor sau a celei convergente.<\/p>\n

Arhitectura clasic\u0103<\/i> implic\u0103 utilizarea sistemelor externe de stocare \u0219i transfer de date inteligente, \u00een timp ce serverele contribuie la pool-ul general de resurse fizice doar cu puterea de procesare \u0219i memoria RAM. \u00cen cazul extrem, serverele devin complet anonime, f\u0103r\u0103 nu doar propriile diskuri, ci chiar \u0219i un identificator de sistem. \u00cen acest caz, se utilizeaz\u0103 boot-ul OS-ului sau al hypervisor-ului de pe unit\u0103\u021bi flash \u00eencorporate sau de pe un sistem de stocare extern (boot from SAN).
\n\u00cen cadrul arhitecturii clasice, alegerea \u00eentre blade-uri \u0219i rack-uri se face \u00een principal pe baza urm\u0103toarelor principii:
\n \u2014 Eficien\u021ba economic\u0103 (\u00een medie, serverele rack sunt mai ieftine);
\n \u2014 Densitatea de calcul (blade-urile au o densitate mai mare);
\n \u2014 Consumul de energie \u0219i disiparea c\u0103ldurii (blade-urile au un consum specific mai mare pe unitate);
\n \u2014 Scalabilitatea \u0219i gestionabilitatea (blade-urile necesit\u0103 \u00een general mai pu\u021bin efort la instal\u0103ri mari);
\n \u2014 Utilizarea pl\u0103cilor de expansiune (pentru blade-uri, op\u021biunile sunt foarte limitate).
\nArhitectura convergent\u0103<\/i> (cunoscut\u0103 \u0219i sub denumirea de hyperconvergent\u0103<\/i>) presupune combinarea func\u021biilor de procesare \u0219i stocare a datelor, ceea ce duce la utilizarea diskurilor locale ale serverelor \u0219i, ca urmare, la renun\u021barea la factorul de form\u0103 al blade-urilor clasice. Pentru sistemele convergente sunt utilizate fie servere rack, fie sisteme cluster care combin\u0103 \u00eentr-o carcas\u0103 unic\u0103 mai multe servere blade \u0219i diskuri locale.<\/p>\n

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

Pentru un calcul corect al configura\u021biei, trebuie s\u0103 \u00een\u021belegem tipul de sarcin\u0103 pentru mediu sau fiecare dintre clusterele independente.
\nCPU bound<\/i> \u2013 un mediu limitat de performan\u021b\u0103 de procesare. Ad\u0103ugarea de memorie RAM nu va schimba nimic din perspectiva performan\u021bei (num\u0103rul de VM-uri pe server).
\nMemory bound<\/i> \u2013 un mediu limitat de memorie RAM. O cantitate mai mare de memorie RAM pe server permite rularea unui num\u0103r mai mare de VM-uri pe server.
\nGB \/ MHz (GB \/ pCPU) \u2013 raportul mediu de consum al memoriei RAM \u0219i puterii de procesare pentru aceast\u0103 sarcin\u0103 specific\u0103. Poate fi utilizat pentru a calcula volumul necesar de memorie pentru o anumit\u0103 performan\u021b\u0103 \u0219i invers. <\/p>\n

Calculul configura\u021biei serverului<\/b><\/p>\n

\"Designul
\n
\n\u00cen primul r\u00e2nd, trebuie s\u0103 determin\u0103m toate tipurile de sarcini \u0219i s\u0103 decidem asupra combin\u0103rii sau separ\u0103rii diferitelor pool-uri de calcul \u00eentre diverse clustere.
\nApoi, pentru fiecare dintre clusterele definite, se determin\u0103 raportul GB \/ MHz \u00een func\u021bie de sarcina cunoscut\u0103 anterior. Dac\u0103 sarcina nu este cunoscut\u0103, dar avem o idee aproximativ\u0103 despre nivelul de utilizare a puterii CPU, se pot utiliza coeficientele standard vCPU:pCPU pentru a traduce cerin\u021bele pool-urilor \u00een fizic. <\/p>\n

Pentru fiecare cluster, suma cerin\u021belor pool-urilor vCPU se \u00eemparte la coeficient:
\nvCPUsum\u0103 \/ vCPU:pCPU = pCPUsum\u0103 \u2013 num\u0103rul necesar de nuclee fizice
\npCPUsum\u0103 \/ 1.25 = pCPUht \u2013 num\u0103rul de nuclee cu ajustare pentru Hyper-Threading
\nS\u0103 presupunem c\u0103 trebuie s\u0103 calcul\u0103m un cluster cu 190 de nuclee \/ 3.5TB RAM. \u00cen acest caz, accept\u0103m o \u00eenc\u0103rcare \u021bint\u0103 de 50% din puterea CPU \u0219i 75% din memoria RAM.<\/p>\n

pCPU<\/b>
\n190
\nUtilizare CPU<\/b>
\n50%<\/p>\n

Memorie<\/b>
\n3500
\nUtilizare memorie<\/b>
\n75%<\/p>\n

Socket<\/b>
\nNucleu<\/b>
\nSrv \/ CPU<\/b>
\nSrv Memorie<\/b>
\nSrv \/ Memorie<\/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

\u00cen acest caz, folosim \u00eentotdeauna rotunjirea la cel mai apropiat \u00eentreg \u00een sus (=ROUNDUP(A1;0)).
\nDin tabel devine evident c\u0103 mai multe configura\u021bii de servere sunt echilibrate \u00een func\u021bie de indicatorii \u021binti\u021bi:
\n \u2014 26 servere 2*6c \/ 192 GB
\n \u2014 19 servere 2*10c \/ 256 GB
\n \u2014 10 servere 2*18c \/ 512 GB <\/p>\n

Alegerea dintre aceste configura\u021bii trebuie s\u0103 se fac\u0103 \u00een continuare pe baza unor factori suplimentari, cum ar fi pachetul termic \u0219i r\u0103cirea disponibil\u0103, serverele deja utilizate sau costul.<\/p>\n

Particularit\u0103\u021bile alegerii configura\u021biei serverului<\/b><\/p>\n

VM-uri largi. Dac\u0103 este necesar\u0103 plasarea de VM-uri largi (comparabile cu 1 nod NUMA \u0219i mai mult), se recomand\u0103, pe c\u00e2t posibil, alegerea unui server cu o configura\u021bie care s\u0103 permit\u0103 acestor VM-uri s\u0103 r\u0103m\u00e2n\u0103 \u00een limitele unui nod NUMA. Atunci c\u00e2nd exist\u0103 un num\u0103r mare de VM-uri largi, exist\u0103 riscul fragment\u0103rii resurselor clusterului, iar \u00een acest caz se aleg servere care permit plasarea VM-urilor largi c\u00e2t mai compact.<\/p>\n

Dimensiunea domeniului de e\u0219ec unic.<\/b> <\/p>\n

Alegerea dimensiunii serverului se face de asemenea pe principiul minimaliz\u0103rii domeniului de e\u0219ec unic. De exemplu, la alegerea \u00eentre:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nC\u00e2nd toate celelalte sunt egale, este necesar s\u0103 se aleag\u0103 a doua op\u021biune, deoarece la defectarea unui server (sau \u00een timpul \u00eentre\u021binerii) nu se pierd 33% din resursele clusterului, ci 17%. La fel, num\u0103rul de VM-uri \u0219i de IS afectate de accident se reduce la jum\u0103tate.<\/p>\n

Calculul unui sistem clasic de stocare pe baza performan\u021bei<\/b><\/p>\n

\"Designul
\n
\nSistemul clasic de stocare este \u00eentotdeauna calculat pe baza celui mai r\u0103u caz, excluz\u00e2nd influen\u021ba cache-ului opera\u021bional \u0219i optimiz\u0103rii opera\u021biunilor.
\nCa indicatori de baz\u0103 ai performan\u021bei, consider\u0103m performan\u021ba mecanic\u0103 de pe disc (IOPSdisk):
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

Mai departe, num\u0103rul de discuri din pool-ul de discuri se calculeaz\u0103 folosind urm\u0103toarea formul\u0103: = TotalIOPS * ( RW + (1 \u2013 RW) * RAIDPen) \/ IOPSdisk<\/i>. Unde:
\n \u2014 TotalIOPS<\/i> \u2013 performan\u021ba total\u0103 necesar\u0103 \u00een IOPS din pool-ul de discuri
\n \u2014 RW<\/i> \u2013 procentul de opera\u021biuni de citire
\n \u2014 RAIDpen<\/i> \u2013 penalizarea RAID pentru nivelul RAID ales<\/p>\n

Aici se explic\u0103 mai multe despre dispozitivul RAID \u0219i penalizarea RAID — Performan\u021ba SCSI. Partea \u00eent\u00e2i.<\/a><\/noindex> \u0219i Performan\u021ba SCSI. Partea a doua.<\/a><\/noindex> \u0219i Performan\u021ba SCSI. Partea a treia.<\/a><\/noindex><\/p>\n

Pe baza num\u0103rului de discuri ob\u021binut, se calculeaz\u0103 op\u021biunile posibile care satisfac cerin\u021bele de capacitate de stocare, inclusiv op\u021biuni cu stocare multi-nivel.
\nCalculul sistemelor care utilizeaz\u0103 SSD ca nivel de stocare este tratat separat.
\nParticularit\u0103\u021bile calculului sistemelor cu Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 denumire general\u0103 pentru toate tehnologiile de marc\u0103 care utilizeaz\u0103 memorie flash ca cache de nivel secundar. Atunci c\u00e2nd se utilizeaz\u0103 cache-ul flash, SCSI-ul este, de obicei, calculat pentru a asigura \u00eenc\u0103rcarea stabilit\u0103 de pe discurile magnetice, \u00een timp ce v\u00e2rful este gestionat de cache.
\n\u00cen acest context, este important s\u0103 \u00een\u021belegem profilul sarcinii \u0219i gradul de localizare a acces\u0103rilor la blocurile volumelor de stocare. Cache flash este o tehnologie pentru sarcini cu o localizare ridicat\u0103 a cererilor \u0219i este practic inaplicabil\u0103 pentru volumele cu o \u00eenc\u0103rcare uniform\u0103 (cum ar fi \u00een sistemele de analiz\u0103). <\/p>\n

Calculul sistemelor hibride low-end \/ mid-range<\/b><\/p>\n

Sistemele hibride din clasele inferioar\u0103 \u0219i medie utilizeaz\u0103 stocare stratificat\u0103 cu mutarea datelor \u00eentre straturi conform unui program. \u00cen acest context, dimensiunea blocului de stocare stratificat\u0103 la cele mai bune modele este de 256 MB. Aceste caracteristici nu permit considerarea tehnologiei de stocare stratificat\u0103 ca o tehnologie de cre\u0219tere a performan\u021bei, a\u0219a cum gre\u0219it cred mul\u021bi. Stocarea stratificat\u0103 \u00een sistemele din clasele inferioar\u0103 \u0219i medie reprezint\u0103 o tehnologie de optimizare a costurilor de stocare pentru sisteme cu o \u00eenc\u0103rcare inegal distribuit\u0103.<\/p>\n

Pentru stocarea multi-nivel, se calculeaz\u0103 \u00een primul r\u00e2nd performan\u021ba nivelului superior, \u00een timp ce nivelul inferior de stocare este considerat c\u0103 aduce doar capacitatea de stocare necesar\u0103. Pentru un sistem hibrid multi-nivel, utilizarea tehnologiei flash cache este esen\u021bial\u0103 \u00een pool-ul multi-nivel pentru a compensa sc\u0103derea performan\u021bei pentru datele care se \u00eenc\u0103lzesc brusc de la nivelul inferior.<\/p>\n

Utilizarea SSD-urilor \u00een pool-ul multi-nivel de discuri<\/b><\/p>\n

\"Designul
\n
\nUtilizarea SSD-urilor \u00een pool-ul multi-nivel de discuri are varia\u021bii, \u00een func\u021bie de particularit\u0103\u021bile implement\u0103rii algoritmilor de flash cache ale acestui produc\u0103tor.
\nPracticile generale ale politicii de stocare pentru un pool de discuri cu nivel SSD sunt \u2014 SSD first.
\nFlash Cache doar \u00een citire.<\/i> Pentru cache-ul flash de tip read-only, nivelul de stocare pe SSD apare atunci c\u00e2nd opera\u021biunile de scriere sunt semnificativ localizate, indiferent de cache.
\nFlash Cache Citire \/ Scriere.<\/i> \u00cen cazul cache-ului flash pentru scriere, mai \u00eent\u00e2i se stabile\u0219te volumul maxim al cache-ului, iar nivelul de stocare pe SSD apare doar \u00een condi\u021biile \u00een care dimensiunea cache-ului nu este suficient\u0103 pentru a gestiona \u00eentreaga sarcin\u0103 localizat\u0103.
\nCalculul performan\u021bei SSD-ului \u0219i a cache-ului se realizeaz\u0103 de fiecare dat\u0103 pe baza recomand\u0103rilor produc\u0103torului, dar \u00eentotdeauna pentru cel mai prost scenariu.
\n
Sursa: 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\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\udd47Designul unui Data Center virtualizat | ProHoster","description":"Introducere Sistem informa\u021bional cu punct.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}