{"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\/no\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Design av virtualisert datasenter","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Design
\n
\nInnledning<\/b><\/p>\n

Informasjonssystemet blir godt definert sett fra brukerens perspektiv i GOST RV 51987 \u2013 \u00abet automatisert system, hvor resultatet av driften er presentasjon av utdata for videre bruk\u00bb. Hvis vi ser p\u00e5 den interne strukturen, s\u00e5 er i prinsippet ethvert IS et system av sammenkoblede algoritmer realisert i kode. I en bredere forst\u00e5else av Turing-Church-teoremet, utf\u00f8rer algoritmen (og dermed IS) en transformasjon av mange inngangsdata til mange utgangsdata.
\nMan kan til og med si at meningen med en informasjonssystems eksistens ligger i transformasjonen av inngangsdata. Dermed defineres verdien av IS og hele komplekset av IS gjennom verdien av inngangs- og utgangsdata.
\nBasert p\u00e5 dette b\u00f8r designprosessen starte med \u00e5 ta utgangspunkt i dataene, og tilpasse arkitekturen og metodene til strukturen og betydningen av disse dataene.<\/p>\n

Lagrende data<\/b>
\nEn n\u00f8kkelkomponent i forberedelsene til design er \u00e5 skaffe egenskaper for alle datamengder planlagt for behandling og lagring. Disse egenskapene inkluderer:
\n \u2014 Datamengde;
\n \u2014 Informasjon om datalivssyklusen (vekst av nye data, levetid, behandling av foreldede data);
\n \u2014 Klassifisering av data ut fra deres p\u00e5virkning p\u00e5 selskapets kjernevirksomhet (i forhold til konfidensialitet, integritet, tilgjengelighet) sammen med finansielle indikatorer (f.eks. kostnadene ved datatap det siste timen);
\n \u2014 Geografi for behandlingen av data (fysisk plassering av behandlingssystemer);
\n \u2014 Reguleringers krav for hver dataklasse (f.eks. FZ-152, PCI DSS).<\/p>\n

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

Informasjonssystemer<\/b><\/p>\n

Data lagres ikke bare, men behandles (transformeres) ogs\u00e5 av informasjonssystemer. Neste trinn etter \u00e5 ha innhentet datakarakteristikker er en s\u00e5 fullstendig oversikt som mulig over informasjonssystemene, deres arkitektoniske s\u00e6regenheter, gjensidig avhengighet og krav til infrastruktur i vilk\u00e5rlige enheter for de fire ressurskategoriene:
\n \u2014 Prosessorberegningskraft;
\n \u2014 Mengde RAM;
\n \u2014 Krav til volum og ytelse av lagringssystemet;
\n \u2014 Krav til datanettverket (eksterne kanaler, kanaler mellom komponentene i IS).
\nKravene m\u00e5 v\u00e6re til stede for hver tjeneste\/mikrotjeneste i informasjonssystemet.
\nDet er viktig \u00e5 p\u00e5peke at det er n\u00f8dvendig med data om innvirkningen av informasjonssystemet p\u00e5 selskapets hovedvirksomhet i form av kostnaden av driftsstopper for informasjonssystemet (rubler per time).<\/p>\n

Trusselmodell<\/b><\/p>\n

Det m\u00e5 p\u00e5 plass en formell trusselmodell som beskriver hvilke trusler data\/tjenester skal beskyttes mot. Denne modellen omfatter ikke bare aspekter av konfidensialitet, men ogs\u00e5 integritet og tilgjengelighet. Det vil si for eksempel:
\n \u2014 Feil p\u00e5 fysisk server;
\n \u2014 Feil p\u00e5 top-of-the-rack switch;
\n \u2014 Brudd p\u00e5 optisk samband mellom datasentre;
\n \u2014 Feil p\u00e5 aktiv lagringsl\u00f8sning totalt.
\nI noen tilfeller skrives trusselmodeller ikke bare for infrastrukturelle komponenter, men ogs\u00e5 for spesifikke informasjonssystemer eller deres komponenter, som for eksempel svikt i databasesystemet med logisk \u00f8deleggelse av databasens struktur.
\nAlle beslutninger innen prosjektet for \u00e5 beskytte mot ubeskrevne trusler er overfl\u00f8dige.<\/p>\n

Regulatoriske krav<\/b><\/p>\n

Hvis de behandlede dataene faller under spesielle regler fastsatt av regulatorer, er det obligatorisk \u00e5 ha informasjon om datasett og regler for behandling\/lagring.<\/p>\n

M\u00e5lverdier for RPO\/RTO<\/b><\/p>\n

Prosjektering av enhver form for beskyttelse krever tilstedev\u00e6relse av m\u00e5lverdier for tap av data og m\u00e5lverdier for gjenopprettingstid av tjeneste for hver av de beskrevne truslene.
\nIdeelt sett b\u00f8r RPO og RTO ha tilknyttede kostnader for datatap og driftsstans per enhet tid.<\/p>\n

\"Design
\n
\nOppdeling i ressurspooler<\/b><\/p>\n

Etter \u00e5 ha samlet all innledende informasjonsinnhold, er det f\u00f8rste steget \u00e5 gruppere datasett og informasjonssystemer i pooler, basert p\u00e5 trusselmodeller og regulatoriske krav. Det bestemmes hvilken type inndeling av forskjellige pooler som benyttes \u2013 programmatisk p\u00e5 systemniv\u00e5 eller fysisk.
\nEksempler:
\n \u2014 Konturene som behandler personopplysninger er helt fysisk adskilt fra andre systemer;
\n \u2014 Sikkerhetskopier lagres p\u00e5 separate lagringsl\u00f8sninger.<\/p>\n

Poolene kan ogs\u00e5 ha ufullstendig uavhengighet, for eksempel kan det defineres to pooler for databehandlingsressurser (prosessorkraft + RAM), som bruker et felles lagringsomr\u00e5de og et felles datakommunikasjonsressursomr\u00e5de.<\/p>\n

Prossessorbasert kapasitet<\/b><\/p>\n

\"Design
\n
\nDe abstrakte behov for prosessorst\u00f8rrelse i en virtualisert datasenter m\u00e5les i antall virtuelle prosessorer (vCPU) og konsolideringsfaktoren deres p\u00e5 fysiske prosessorer (pCPU). I dette spesifikke tilfellet er 1 pCPU = 1 fysisk prosessorkjerne (uten hensyn til Hyper-Threading). Antallet vCPU summeres over alle definerte ressursbassenger (hver av dem kan ha sin egen konsolideringsfaktor).
\nKonsolideringsfaktoren for belastede systemer oppn\u00e5s empirisk, basert p\u00e5 den eksisterende infrastrukturen eller ved pilotinstallasjon og belastningstesting. For ubearbeidede systemer brukes \u00abbeste praksis\u00bb. Spesifikt angir VMware en gjennomsnittlig konsolideringsfaktor p\u00e5 8:1.<\/p>\n

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

Den totale behovet for arbeidsminne oppn\u00e5s ved enkel summering. Bruk av overbookede minne anbefales ikke.<\/p>\n

Lagringsressurser<\/b><\/p>\n

Kravene til lagringsressurser f\u00e5s ved enkel summering av alle bassenger etter volum og ytelse.
\nYtelseskravene uttrykkes i IOPS kombinert med det gjennomsnittlige forholdet mellom lesing\/skriving og ved behov maksimal responstid.
\nKrav til tjenestekvalitet (QoS) m\u00e5 spesifiseres separat for bestemte bassenger eller systemer.<\/p>\n

Nettverksressurser<\/b><\/p>\n

Kravene til nettverkskapasitet oppn\u00e5s ved enkel summering av alle bassenger.
\nKrav til tjenestekvalitet (QoS) og forsinkelser (RTT) m\u00e5 spesifiseres separat for bestemte bassenger eller systemer.
\nInnenfor kravene til nettverksressurser m\u00e5 ogs\u00e5 krav til isolasjon og\/eller kryptering av nettverkstrafikk og foretrukne mekanismer (802.1q, IPSec osv.) angis.<\/p>\n

Valg av arkitektur<\/b><\/p>\n

I denne veiledningen vurderes det ikke noe annet valg enn x86-arkitektur og 100% servervirtualisering. Derfor reduseres valget av databehandlingssubsystemets arkitektur til valget av servervirtualiseringsplattform, serverformfaktor og generelle krav til serverkonfigurasjon.<\/p>\n

N\u00f8kkelpunktene i valget er avklarte valg mellom den klassiske tiln\u00e6rmingen som skiller funksjonene for behandling, lagring og overf\u00f8ring av data eller konvergerende.<\/p>\n

Klassisk arkitektur<\/i> inneber \u00e5 bruke intelligente eksterne lagrings- og datatransfer systemer, mens serverne bare tilf\u00f8rer den fysiske ressursbeholdningen prosessorkraft og RAM. I ytterste fall blir serverne helt anonyme og har ikke bare egne disker, men heller ikke et systemidentifikator. I slike tilfeller brukes det \u00e5 starte OS eller hypervisor fra innebygde flash-minner eller fra et eksternt lagringssystem (boot from SAN).
\nInnen klassisk arkitektur gj\u00f8res valget mellom blad (blade) og rack-servere f\u00f8rst og fremst ut fra f\u00f8lgende prinsipper:
\n \u2014 Kostnadseffektivitet (rack-servere er i gjennomsnitt billigere);
\n \u2014 Beregningsdybde (blader har h\u00f8yere tetthet);
\n \u2014 Str\u00f8mforbruk og varmedannelse (blader har h\u00f8yere spesifikk forbruk per enhet);
\n \u2014 Skalerbarhet og h\u00e5ndterbarhet (blader krever generelt mindre innsats ved store installasjoner);
\n \u2014 Bruk av utvidelseskort (det er et sv\u00e6rt begrenset utvalg for blader).
\nKonvergent arkitektur<\/i> (ogs\u00e5 kjent som hyperkonvergent<\/i>) inneb\u00e6rer en fusjon av data behandlings- og lagringsfunksjoner, noe som f\u00f8rer til bruken av lokal disker i serverne og dermed oppgivelsen av formfaktoren til klassiske blader. For konvergerte systemer brukes enten rack-servere eller klyngesystemer som kombinerer flere bladere servere og lokale disker i et enkelt kabinett.<\/p>\n

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

For \u00e5 beregne konfigurasjonen riktig m\u00e5 man forst\u00e5 typen belastning for milj\u00f8et eller hver av de uavhengige klyngene.
\nCPU bound<\/i> \u2013 et milj\u00f8 som er begrenset av prosesseringskraften til CPU. Tillegget av mer RAM vil ikke endre noe med hensyn til ytelsen (antall VM p\u00e5 serveren).
\nMemory bound<\/i> \u2013 et milj\u00f8 som er begrenset av RAM. Mer RAM p\u00e5 serveren lar deg kj\u00f8re flere VM-er.
\nGB \/ MHz (GB \/ pCPU) \u2013 det gjennomsnittlige forholdet mellom RAM-forbruket til denne spesifikke belastningen og prosessorkraften. Kan brukes til \u00e5 beregne n\u00f8dvendig minnevolum ved angitt ytelse og omvendt. <\/p>\n

Beregning av serverkonfigurasjon<\/b><\/p>\n

\"Design
\n
\nF\u00f8rst m\u00e5 vi identifisere alle typer belastning og ta en beslutning om \u00e5 kombinere eller skille forskjellige beregningspuljer i ulike klynger.
\nDeretter bestemmes forholdet GB \/ MHz for hver av de definerte klustrene med en kjent belastning. Hvis belastningen ikke er kjent p\u00e5 forh\u00e5nd, men det er en omtrentlig forst\u00e5else av prosessorens belastningsniv\u00e5, kan man bruke standardforholdene vCPU:pCPU for \u00e5 oversette kravene fra puljene til fysisk. <\/p>\n

For hver klynge deler vi summen av vCPU-kravene p\u00e5 forholdet:
\nvCPU_summ \/ vCPU:pCPU = pCPU_summ \u2013 n\u00f8dvendig antall fysiske kjerner
\npCPU_summ \/ 1.25 = pCPU_ht \u2013 antall kjerner med justering for Hyper-Threading
\nLa oss anta at vi m\u00e5 gj\u00f8re beregninger for en klynge med 190 kjerner \/ 3.5 TB RAM. Her tar vi en m\u00e5let belastning p\u00e5 50% av prosessorkraften og 75% for RAM.<\/p>\n

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

Minne<\/b>
\n3500
\nMinne-util<\/b>
\n75%<\/p>\n

Socket<\/b>
\nKjerne<\/b>
\nSrv \/ CPU<\/b>
\nSrv Minne<\/b>
\nSrv \/ Minne<\/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

I dette tilfellet bruker vi alltid avrunding til n\u00e6rmeste hele oppover (=ROUNDUP(A1;0)).
\nFra tabellen blir det tydelig at flere konfigurasjoner av servere er balanserte etter m\u00e5lverdiene:
\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

Valget mellom disse konfigurasjonene m\u00e5 baseres p\u00e5 tilleggsskader som varmeutvikling og tilgjengelig kj\u00f8ling, allerede eksisterende servere, eller kostnad.<\/p>\n

Egenskaper ved valg av serverkonfigurasjon<\/b><\/p>\n

Bred VM. N\u00e5r det er behov for \u00e5 plassere brede VM (sammenlignbare med 1 NUMA-nod og mer), anbefales det \u00e5 velge en serverkonfigurasjon som tillater slike VM \u00e5 forbli innenfor NUMA-noden. N\u00e5r vi har mange brede VM, oppst\u00e5r det en risiko for fragmentering av klyngeressursene, og i slike tilfeller velges servere som muliggj\u00f8r en tettere plassering av brede VM.<\/p>\n

St\u00f8rrelsen p\u00e5 domenet for enkeltfeil.<\/b> <\/p>\n

Valget av serverst\u00f8rrelse styres ogs\u00e5 av prinsippet om \u00e5 minimere domenet for enkeltfeil. For eksempel ved valg mellom:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nVed ellers like betingelser m\u00e5 man velge det andre alternativet, ettersom n\u00e5r en server svikter (eller er under vedlikehold) g\u00e5r ikke 33% av klynge ressursene tapt, men 17%. P\u00e5 samme m\u00e5te reduseres antallet VM-er og IS-er som ble ber\u00f8rt av hendelsen med det halve.<\/p>\n

Beregning av klassisk lagringsytelse<\/b><\/p>\n

\"Design
\n
\nKlassisk lagringsytelse beregnes alltid ut fra worst case scenario, uten \u00e5 ta hensyn til innvirkningen av hurtigminnekontroller og optimering av operasjoner.
\nSom grunnleggende ytelsesparametre tar vi hensyn til den mekaniske ytelsen fra disken (IOPSdisk):
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

Deretter beregnes antall disker i diskpoolen etter f\u00f8lgende formel: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. Hvor:
\n \u2014 TotalIOPS<\/i> \u2013 samlet n\u00f8dvendig ytelse i IOPS fra diskpoolen
\n \u2014 RW<\/i> \u2013 prosentandel av leseoperasjoner
\n \u2014 RAIDpen<\/i> \u2013 RAID-straff for valgt RAID-niv\u00e5<\/p>\n

Mer om RAID-enhet og RAID-penalitet kan leses her \u2014 Lagringsytelse. Del \u00e9n.<\/a><\/noindex> og Lagringsytelse. Del to.<\/a><\/noindex> og Lagringsytelse. Del tre.<\/a><\/noindex><\/p>\n

Basert p\u00e5 det beregnede antallet disker, beregnes mulige alternativer som tilfredsstiller lagringskapasitetskravene, inkludert alternativer med flertrinnslagring.
\nBeregning av systemer med SSD som lagringsniv\u00e5 vurderes separat.
\nEgenskaper ved beregning av systemer med Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 det generelle navnet for alle merkespesifikke teknologier som bruker flash-minne som et sekund\u00e6rt cache. Ved bruk av flash-cache beregnes lagringsytelsen vanligvis for \u00e5 im\u00f8tekomme stabil belastning fra magnetiske disker, mens toppbelastningen dekkes av cachen.
\nDet er n\u00f8dvendig \u00e5 forst\u00e5 lastprofilen og graden av lokalisering av foresp\u00f8rslene til volumene. Flash-cache er en teknologi for belastninger med h\u00f8y lokalisering av foresp\u00f8rslene, og er praktisk talt ikke anvendbar for jevnt belastede volumer (som for eksempel for analysesystemer). <\/p>\n

Beregning av hybrid systemer low-end \/ mid-range<\/b><\/p>\n

Hybrid systemer av lav og middels klasse bruker flertrinnslagring med dataoverf\u00f8ring mellom niv\u00e5ene etter en tidsplan. I denne sammenheng har beste modeller et lagringsblokkst\u00f8rrelse p\u00e5 256 MB. Disse egenskapene lar oss ikke betrakte flertrinnslagringsteknologien som en ytelses\u00f8kningsmetode, som mange feilaktig antar. Flertrinnslagring i systemer av lav og middels klasse er en kostnadsoptimeringsteknologi for lagringssystemer med tydelig ujevn belastning.<\/p>\n

For multi-tiered storage, performance at the upper tier is primarily calculated, while the lower storage tier is considered only as a supplementary source of storage capacity. For a hybrid multi-tiered system, the use of flash cache technology in the multi-tier pool is essential to compensate for performance drops for suddenly heated data from the lower tier.<\/p>\n

Using SSD in a multi-tier disk pool<\/b><\/p>\n

\"Design
\n
\nThe use of SSD in a multi-tier disk pool varies depending on the specific implementation of flash cache algorithms by the manufacturer.
\nThe general practice for storage policy for a disk pool with SSD level is SSD first.
\nRead Only Flash Cache.<\/i> For read-only flash cache, the storage level on SSD appears with significant localization of write operations regardless of the cache.
\nRead \/ Write Flash Cache.<\/i> In the case of write flash cache, the maximum cache size is set first, and the storage level on SSD appears only when the cache size is insufficient to handle the entire localized load.
\nThe performance of SSD and cache is calculated each time based on the manufacturer's recommendations, but always for the worst-case scenario.
\n
Kilde: 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\udd47Design of virtualized data centers | ProHoster","description":"Introduction Information system from the point.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}