{"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\/hr\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Dizajn virtualiziranog DC-a","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

Informacijski sustav korisnik definira prema GOST RV 51987 \u2013 \"automatizirani sustav \u010diji je rezultat funkcioniranja predstavljanje izlaznih informacija za daljnju upotrebu\". Ako razmotrite unutarnju strukturu, svaka IS u su\u0161tini predstavlja sustav me\u0111usobno povezanih algoritama realiziranih u kodu. U \u0161irem smislu Turing-Churchove teze, algoritam (tj. IS) provodi transformaciju skupa ulaznih podataka u skup izlaznih podataka.
\nMo\u017ee se \u010dak re\u0107i da je smisao postojanja informacijskog sustava upravo u transformaciji ulaznih podataka. Stoga se vrijednost IS i cijelog kompleksa IS odre\u0111uje kroz vrijednost ulaznih i izlaznih podataka.
\nIz toga slijedi da projektiranje treba zapo\u010deti i temeljiti se na podacima, prilago\u0111avaju\u0107i arhitekturu i metode strukturi i zna\u010daju podataka.<\/p>\n

Pohranjeni podaci<\/b>
\nKlju\u010dna faza pripreme za projektiranje je prikupiti karakteristike svih skupa podataka koje planiramo obra\u0111ivati i pohranjivati. Ove karakteristike uklju\u010duju:
\n \u2014 Obujam podataka;
\n \u2014 Informacije o \u017eivotnom ciklusu podataka (pove\u0107anje novih podataka, vijek trajanja, obrada zastarjelih podataka);
\n \u2014 Klasifikacija podataka s gledi\u0161ta utjecaja na osnovno poslovanje tvrtke (posjedovanju povjerljivosti, cjelovitosti, dostupnosti) zajedno s financijskim pokazateljima (npr. cijena gubitka podataka u posljednjem satu);
\n \u2014 Geografija obrade podataka (fizi\u010dka lokacija sustava obrade);
\n \u2014 Zahtjevi regulatora za svaku klasu podataka (npr. FZ-152, PCI DSS).<\/p>\n

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

Informacijski sustavi<\/b><\/p>\n

Podaci ne samo da se pohranjuju, ve\u0107 ih i obra\u0111uju (transformiraju) informacijski sustavi. Sljede\u0107i korak nakon prikupljanja karakteristika podataka je \u0161to potpunija inventarizacija informacijskih sustava, njihovih arhitektonskih osobina, me\u0111uzavisnosti i zahtjeva za infrastrukturom u konvencionalnim jedinicama za \u010detiri vrste resursa:
\n \u2014 Procesorska ra\u010dunalna snaga;
\n \u2014 Obujam radne memorije;
\n \u2014 Zahtjevi za obujam i performanse sustava za pohranu podataka;
\n \u2014 Zahtjevi za mre\u017eom prijenosa podataka (vanjski kanali, kanali me\u0111u komponentama IS).
\nZa svaki servis\/mikroservis unutar IS-a moraju postojati zahtjevi.
\nPosebno je va\u017eno napomenuti obavezan skup podataka o utjecaju IS-a na osnovno poslovanje tvrtke u smislu tro\u0161ka zastoja IS-a (rubalja na sat).<\/p>\n

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

Obavezno treba imati formalni model prijetnji od kojih se planira za\u0161tita podataka \/ usluga. Model prijetnji uklju\u010duje ne samo aspekte povjerljivosti, ve\u0107 i cjelovitosti i dostupnosti. To jest, na primjer:
\n \u2014 Kvar fizi\u010dkog servera;
\n \u2014 Kvar top-of-the-rack prekida\u010da;
\n \u2014 Prekid opti\u010dkog komunikacijskog kanala izme\u0111u CENTRA;
\n \u2014 Kvar operativnog sustava za pohranu podataka u cjelini.
\nU nekim slu\u010dajevima modeli prijetnji nisu pisani samo za infrastrukturne komponente, ve\u0107 i za specifi\u010dne IS ili njihove komponente, poput pada DBMS-a s logi\u010dkim uni\u0161tenjem strukture podataka.
\nSva rje\u0161enja unutar projekta za za\u0161titu od neobja\u0161njenih prijetnji su suvi\u0161na.<\/p>\n

Zahtjevi regulatora<\/b><\/p>\n

Ako obra\u0111eni podaci podlije\u017eu posebnim pravilima koja utvr\u0111uju regulatori, obavezno je osigurati informacije o skupovima podataka i pravilima obrade\/pohrane.<\/p>\n

Ciljni pokazatelji RPO \/ RTO<\/b><\/p>\n

Projektiranje bilo koje vrste za\u0161tite zahtijeva prisutnost pokazatelja ciljane gubitka podataka i ciljanog vremena oporavka usluge za svaku od opisanych prijetnji.
\nU idealnom slu\u010daju, RPO i RTO trebaju imati povezane tro\u0161kove gubitka podataka i zastoja po jedinici vremena.<\/p>\n

\"Dizajn
\n
\nPodjela na skupine resursa<\/b><\/p>\n

Nakon prikupljanja svih po\u010detnih informacija, prvi korak je grupiranje skupova podataka i IS-a u skupine, na temelju modela prijetnji i zahtjeva regulatora. Odre\u0111uje se vrsta podjele razli\u010ditih skupina - programski na razini sustavnog softvera ili fizi\u010dki.
\nPrimjeri:
\n \u2014 Kontura koja obra\u0111uje osobne podatke potpuno je fizi\u010dki odvojena od ostalih sustava;
\n \u2014 Backup se \u010duva na zasebnom sustavu za pohranu.<\/p>\n

U tom slu\u010daju, skupine mogu imati nepotpunu neovisnost, na primjer, definiraju se dva skupa ra\u010dunalnih resursa (procesorska snaga + radna memorija), koji koriste jedinstveni skup za pohranu podataka i jedinstveni skup resursa za prijenos podataka.<\/p>\n

Procesorska snaga<\/b><\/p>\n

\"Dizajn
\n
\nApsolutne potrebe za procesorskom snagom virtualiziranog DC-a mjere se brojem virtualnih procesora (vCPU) i koeficijentom njihove konsolidacije na fizi\u010dkim procesorima (pCPU). U ovom konkretnom slu\u010daju 1 pCPU = 1 fizi\u010dko jezgro procesora (ne ra\u010dunaju\u0107i Hyper-Threading). Broj vCPU zbraja se u svim unaprijed definiranim bazenima resursa (od kojih svaki mo\u017ee imati svoj koeficijent konsolidacije).
\nKoeficijent konsolidacije za optere\u0107ene sustave dobiva se empirijski, prema ve\u0107 postoje\u0107oj infrastrukturi ili tijekom probne instalacije i optere\u0107enja. Za neoptere\u0107ene sustave primjenjuju se 'best practices'. Konkretno, VMware navodi prosje\u010dni koeficijent od 8:1.<\/p>\n

Radna memorija<\/b><\/p>\n

Ukupna potreba za radnom memorijom dobiva se jednostavnim zbrajanjem. Kori\u0161tenje pretplate za radnu memoriju nije preporu\u010dljivo.<\/p>\n

Resursi pohrane<\/b><\/p>\n

Zahtjevi za resursima pohrane dobivaju se jednostavnim zbrajanjem svih bazena prema volumenu i performansama.
\nZahtjevi za performansama izra\u017eavaju se u IOPS-u u kombinaciji s prosje\u010dnim omjerom \u010ditanja\/pisanja i, ako je potrebno, maksimalnom latencijom.
\nOdvojeno treba navesti zahtjeve za osiguranje kvalitete usluge (QoS) za odre\u0111ene bazene ili sustave.<\/p>\n

Resursi mre\u017ee<\/b><\/p>\n

Zahtjevi za mre\u017eom dobivaju se jednostavnim zbrajanjem svih bazena propusnosti.
\nOdvojeno treba navesti zahtjeve za osiguranje kvalitete usluge (QoS) i latencije (RTT) za odre\u0111ene bazene ili sustave.
\nU okviru zahtjeva za resursima mre\u017ee tako\u0111er se navode zahtjevi za izolacijom i\/ili enkripcijom mre\u017enog prometa i preferiranim mehanizmima (802.1q, IPSec itd.).<\/p>\n

Odabir arhitekture<\/b><\/p>\n

U okviru ovog vodi\u010da ne razmatra se drugi izbor osim arhitekture x86 i 100% virtualizacije poslu\u017eitelja. Stoga se odabir arhitekture ra\u010dunalnog podsustava svodi na izbor platforme za virtualizaciju poslu\u017eitelja, oblik poslu\u017eitelja i op\u0107e zahtjeve za konfiguraciju poslu\u017eitelja.<\/p>\n

Klju\u010dna to\u010dka odabira je jasnost u kori\u0161tenju klasi\u010dnog pristupa s razdvajanjem funkcija obrade, pohrane i prijenosa podataka ili konvergentnog.<\/p>\n

Klasi\u010dna arhitektura<\/i> podrazumijeva kori\u0161tenje inteligentnih vanjskih sustava za pohranu i prijenos podataka, dok serveri doprinose zajedni\u010dkom skupu fizi\u010dkih resursa samo procesorskom snagom i radnom memorijom. U ekstremnom slu\u010daju, serveri postaju potpuno anonimni, nemaju\u0107i niti vlastite diskove, \u010dak ni sistemski identifikator. U tom slu\u010daju koristi se podizanje OS-a ili hipervizora s ugra\u0111enih flash ure\u0111aja ili s vanjskog sustava za pohranu podataka (boot from SAN).
\nU okviru klasi\u010dne arhitekture, izbor izme\u0111u blade i rack sustava se prvenstveno donosi prema sljede\u0107im na\u010delima:
\n \u2014 Ekonomi\u010dnost (u prosjeku rack serveri su jeftiniji);
\n \u2014 Ra\u010dunalna gusto\u0107a (blade su vi\u0161i);
\n \u2014 Potro\u0161nja energije i ispu\u0161tanje topline (blade imaju vi\u0161u specifi\u010dnu potro\u0161nju po jedinici);
\n \u2014 Skalabilnost i upravljivost (blade u cjelini zahtijevaju manje napora pri velikim instalacijama);
\n \u2014 Kori\u0161tenje pro\u0161irivih kartica (za blade je vrlo ograni\u010den izbor).
\nKonvergentna arhitektura<\/i> (tako\u0111er poznata kao hiper-konvergentna<\/i>) podrazumijeva kombiniranje funkcija obrade i pohrane podataka, \u0161to dovodi do kori\u0161tenja lokalnih diskova servera i kao posljedicu odustajanje od form-faktora klasi\u010dnih blade sustava. Za konvergentne sustave koriste se ili rack serveri ili klasterski sustavi koji kombiniraju u jednoj ku\u0107i\u0161tu nekoliko blade servera i lokalne diskove.<\/p>\n

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

Za to\u010dan izra\u010dun konfiguracije treba razumjeti tip optere\u0107enja za okolinu ili svaki od neovisnih klastera.
\nCPU bound<\/i> \u2013 okru\u017eenje ograni\u010deno na procesorsku snagu. Dodavanje radne memorije ne\u0107e promijeniti performanse (broj VM-ova na serveru).
\nMemory bound<\/i> \u2013 okru\u017eenje ograni\u010deno radnom memorijom. Ve\u0107a koli\u010dina radne memorije na serveru omogu\u0107uje pokretanje ve\u0107eg broja VM-ova na serveru.
\nGB \/ MHz (GB \/ pCPU) \u2013 prosje\u010dni odnos potro\u0161nje te specifi\u010dne optere\u0107enja radne memorije i procesorske snage. Mo\u017ee se koristiti za izra\u010dun potrebnog volumena memorije pri zadanoj performansi i obrnuto. <\/p>\n

Izra\u010dun konfiguracije servera<\/b><\/p>\n

\"Dizajn
\n
\nPrvo je potrebno odrediti sve vrste optere\u0107enja i donijeti odluku o kombinaciji ili razdvajanju razli\u010ditih ra\u010dunalnih pool-ova po raznim klastra.
\nNakon toga, za svaki od definiranih klastera odre\u0111uje se omjer GB \/ MHz uz poznato optere\u0107enje. Ako optere\u0107enje nije poznato unaprijed, ali postoji pribli\u017eno razumijevanje razine optere\u0107enja procesorske snage, mo\u017ee se koristiti standardni omjer vCPU:pCPU za prevo\u0111enje zahtjeva pool-ova u fizi\u010dke. <\/p>\n

Za svaki klaster zbroj zahtjeva pool-ova vCPU dijelimo s koeficijentom:
\nvCPUzbroj \/ vCPU:pCPU = pCPUzbroj \u2013 tra\u017eeni broj fizi\u010dkih jezgri
\npCPUzbroj \/ 1.25 = pCPUht \u2013 broj jezgri uz korekciju na Hyper-Threading
\nPretpostavimo da je potrebno izra\u010dunati klaster sa 190 jezgri \/ 3.5 TB RAM-a. Pri tome prihva\u0107amo ciljano optere\u0107enje procesorske snage od 50% i 75% za radnu memoriju.<\/p>\n

pCPU<\/b>
\n190
\nCPU util<\/b>
\n50%<\/p>\n

Mem<\/b>
\n3500
\nMem util<\/b>
\n75%<\/p>\n

Socket<\/b>
\nCore<\/b>
\nSrv \/ CPU<\/b>
\nSrv Mem<\/b>
\nSrv \/ Mem<\/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

U ovom slu\u010daju uvijek koristimo zaokru\u017eivanje na najbli\u017ei cijeli broj navi\u0161e (=ROUNDUP(A1;0)).
\nIz tablice postaje o\u010dito da su uravnote\u017eene prema ciljnim pokazateljima nekoliko konfiguracija poslu\u017eitelja:
\n \u2014 26 poslu\u017eitelja 2*6c \/ 192 GB
\n \u2014 19 poslu\u017eitelja 2*10c \/ 256 GB
\n \u2014 10 poslu\u017eitelja 2*18c \/ 512 GB <\/p>\n

Odabir izme\u0111u ovih konfiguracija dalje se mora vr\u0161iti uzimaju\u0107i u obzir dodatne faktore, kao \u0161to su toplinski paket i dostupno hla\u0111enje, ve\u0107 kori\u0161teni poslu\u017eitelji ili tro\u0161ak.<\/p>\n

Osobitosti odabira konfiguracije poslu\u017eitelja<\/b><\/p>\n

\u0160iroke VM. U slu\u010daju potrebe za smje\u0161tanjem \u0161irokih VM (usporedivih s 1 NUMA \u010dvorom i vi\u0161e) preporu\u010duje se, koliko god je to mogu\u0107e, odabrati poslu\u017eitelj s konfiguracijom koja omogu\u0107uje tim VM-ovima ostati unutar NUMA \u010dvora. Kod velikog broja \u0161irokih VM postoji opasnost od fragmentacije resursa klastera, te se u tom slu\u010daju odabiru poslu\u017eitelji koji omogu\u0107uju gusto smje\u0161tanje \u0161irokih VM.<\/p>\n

Veli\u010dina domene pojedina\u010dnog kvara.<\/b> <\/p>\n

Odabir veli\u010dine poslu\u017eitelja tako\u0111er se vr\u0161i prema na\u010delu minimizacije domene jedinstvenog kvara. Na primjer, prilikom odabira izme\u0111u:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nUz jednake uvjete, potrebno je odabrati drugu opciju, jer u slu\u010daju kvara jednog poslu\u017eitelja (ili servisiranja) ne gubi se 33% resursa klastera, ve\u0107 17%. Na isti na\u010din se prepolovljuje broj VM-ova i IS-a na koje je utjecala nesre\u0107a.<\/p>\n

Izra\u010dun klasi\u010dne SANS po performansama<\/b><\/p>\n

\"Dizajn
\n
\nKlasi\u010dna SANS uvijek se izra\u010dunava prema najgorem scenariju, isklju\u010duju\u0107i utjecaj operativnog ke\u0161a i optimizacije operacija.
\nKao osnovne pokazatelje performansi uzimamo mehani\u010dku performansu diska (IOPSdisk):
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

Dalje, broj diskova u disku poolu izra\u010dunava se prema sljede\u0107oj formuli: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. Gdje:
\n \u2014 TotalIOPS<\/i> \u2013 ukupna potrebna performansa u IOPS s diska poola
\n \u2014 RW<\/i> \u2013 postotak operacija \u010ditanja
\n \u2014 RAIDpen<\/i> \u2013 RAID kazna za odabrani nivo RAID-a<\/p>\n

Vi\u0161e o RAID ure\u0111aju i RAID kazni mo\u017eete pro\u010ditati ovdje \u2014 Performanse SANS-a. Prvi deo.<\/a><\/noindex> i Performanse SANS-a. Drugi deo.<\/a><\/noindex> i Performanse SANS-a. Tre\u0107i deo.<\/a><\/noindex><\/p>\n

Na osnovu dobivenog broja diskova izra\u010dunavaju se mogu\u0107i varijante koje zadovoljavaju zahtjeve za kapacitetom pohrane, uklju\u010duju\u0107i varijante s vi\u0161eslojnom pohranom.
\nIzra\u010dun sustava koji koriste SSD kao nivo pohrane razmatra se posebno.
\nOsobine izra\u010duna sustava s Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 op\u0107i naziv za sve brendirane tehnologije kori\u0161tenja flash memorije kao drugog nivoa ke\u0161a. Pri kori\u0161tenju flash ke\u0161a, SANS se obi\u010dno izra\u010dunava za osiguravanje optere\u0107enja s magnetskih diskova, dok vrhunsku opremu opslu\u017euje ke\u0161.
\nPri tome je va\u017eno razumjeti profil optere\u0107enja i stepen lokalizacije zahtjeva prema blokovima pohrane. Flash ke\u0161 je tehnologija za optere\u0107enja s visokom lokalizacijom zahtjeva i prakti\u010dki nije primjenjiva za ravnomjerno optere\u0107ene volumene (kao \u0161to su, na primjer, analiti\u010dki sustavi). <\/p>\n

Izra\u010dun hibridnih sustava low-end \/ mid-range<\/b><\/p>\n

Hibridni sustavi donjih i srednjih klasa koriste vi\u0161eslojnu pohranu s premje\u0161tanjem podataka izme\u0111u nivoa prema rasporedu. Pri tome veli\u010dina bloka vi\u0161eslojne pohrane kod najboljih modela iznosi 256 MB. Ove osobine ne omogu\u0107uju smatraju\u0107i tehnologiju vi\u0161eslojne pohrane tehnologijom pobolj\u0161anja performansi, kako mnogi pogre\u0161no misle. Vi\u0161eslojna pohrana u sustavima donjih i srednjih klasa je tehnologija optimizacije tro\u0161kova pohrane za sustave s izra\u017eenom neravnomjerno\u0161\u0107u optere\u0107enja.<\/p>\n

Za vi\u0161eslojno pohranjivanje prvo se izra\u010dunava performansa gornjeg sloja, dok se donji sloj pohrane smatra jedino dopunskom kapacitetu pohrane. Za hibridni vi\u0161eslojni sustav obavezna je upotreba tehnologije flash cache za vi\u0161eslojni bazen s ciljem kompenzacije pada performansi za iznenada pove\u0107ane podatke iz donjeg sloja.<\/p>\n

Kori\u0161tenje SSD-a u vi\u0161eslojnim diskovnim bazenima<\/b><\/p>\n

\"Dizajn
\n
\nKori\u0161tenje SSD-a u vi\u0161eslojnim diskovnim bazenima ima varijacije, ovisno o karakteristikama provedbe algoritama flash cachea od strane odre\u0111enog proizvo\u0111a\u010da.
\nOp\u0107a praksa politike pohrane za diskovni bazen s razinom SSD-a \u2013 SSD first.
\nFlash Cache samo za \u010ditanje.<\/i> Za flash cache samo za \u010ditanje, razina pohrane na SSD-u pojavljuje se kada je zna\u010dajno lokalizirana operacija pisanja neovisna o cacheu.
\nFlash Cache za \u010ditanje \/ pisanje.<\/i> U slu\u010daju flash cachea za pisanje, najprije se postavlja maksimalni volumen cachea, a razina pohrane na SSD-u pojavljuje se samo kada veli\u010dina cachea nije dovoljna za upravljanje svim lokaliziranim optere\u0107enjem.
\nIzra\u010dun performansi SSD-a i cachea vr\u0161i se svaki put prema preporukama proizvo\u0111a\u010da, ali uvijek za najgori mogu\u0107i scenarij.
\n
Izvor: 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 virtualiziranog DC-a | ProHoster","description":"Uvod Informacijski sustav s to\u010dke.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}