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

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

Informationssystemet definieras v\u00e4l ur anv\u00e4ndarens perspektiv i GOST RV 51987 \u2013 \"ett automatiserat system vars resultat av dess funktion \u00e4r presentationen av utdata f\u00f6r vidare anv\u00e4ndning\". Om vi betraktar den interna strukturen s\u00e5 \u00e4r i grund och botten varje IS ett system av genomf\u00f6rda algoritmer i kod. I en bredare mening av Turing-Churchs tes genomf\u00f6r algoritmen (och d\u00e4rmed IS) en transformation av m\u00e5nga ing\u00e5ngsdata till m\u00e5nga utg\u00e5ngsdata.
\nMan kan till och med s\u00e4ga att meningen med en informationssystems existens ligger i transformationen av ing\u00e5ngsdata. F\u00f6ljaktligen definieras v\u00e4rdet av IS och hela komplexet av IS genom v\u00e4rdet av ing\u00e5ende och utg\u00e5ende data.
\nBaserat p\u00e5 detta b\u00f6r designen inledas med och ta h\u00e4nsyn till data, vilket anpassar arkitektur och metoder till datans struktur och betydelse.<\/p>\n

Lagrade data<\/b>
\nEtt nyckels steg i f\u00f6rberedelserna f\u00f6r design \u00e4r att erh\u00e5lla egenskaperna f\u00f6r alla dataset som planeras att behandlas och lagras. Dessa egenskaper inkluderar:
\n \u2014 Datam\u00e4ngd;
\n \u2014 Information om livscykeln f\u00f6r data (tillv\u00e4xt av nya data, livsl\u00e4ngd, behandling av f\u00f6r\u00e5ldrad data);
\n \u2014 Klassificering av data ur perspektivet av p\u00e5verkan p\u00e5 f\u00f6retagets huvudverksamhet (de tre h\u00f6rnstenarna sekretess, integritet, tillg\u00e4nglighet) tillsammans med finansiella indikatorer (t.ex. kostnaden f\u00f6r dataf\u00f6rlust under den senaste timmen);
\n \u2014 Geografi f\u00f6r databehandling (fysisk plats f\u00f6r behandlingssystem);
\n \u2014 Regelverkskrav f\u00f6r varje dataklass (t.ex. Federal Law-152, PCI DSS).<\/p>\n

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

Informationssystem<\/b><\/p>\n

Data lagras inte bara, utan bearbetas ocks\u00e5 (transformeras) av informationssystem. N\u00e4sta steg efter att ha f\u00e5tt dataegenskaper \u00e4r att g\u00f6ra en s\u00e5 fullst\u00e4ndig inventering av informationssystemen som m\u00f6jligt, deras arkitektoniska egenskaper, \u00f6msesidiga beroenden och krav p\u00e5 infrastruktur i enhetliga m\u00e5tt f\u00f6r fyra typer av resurser:
\n \u2014 Processorkraft;
\n \u2014 M\u00e4ngd RAM;
\n \u2014 Krav p\u00e5 volym och prestanda f\u00f6r lagringssystem;
\n \u2014 Krav p\u00e5 datakommunikationsn\u00e4t (externa kanaler, kanaler mellan IS-komponenter).
\nKrav m\u00e5ste finnas f\u00f6r varje tj\u00e4nst\/mikrotj\u00e4nst inom IS.
\nDet \u00e4r s\u00e4rskilt viktigt att notera den information som \u00e4r n\u00f6dv\u00e4ndig f\u00f6r korrekt design, som angett i form av kostnaden f\u00f6r driftstopp av IS (i rubel per timme).<\/p>\n

Hotmodell<\/b><\/p>\n

Det m\u00e5ste finnas en formell hotmodell som skyddar data\/tj\u00e4nster. Denna hotmodell omfattar inte bara aspekter av konfidentialitet utan \u00e4ven integritet och tillg\u00e4nglighet. D.v.s. till exempel:
\n \u2014 Fel p\u00e5 den fysiska servern;
\n \u2014 Fel p\u00e5 top-of-the-rack-switchen;
\n \u2014 Avbrott i den optiska kommunikationskanalen mellan datacenter;
\n \u2014 Fel p\u00e5 den operationella lagringsl\u00f6sningen helt.
\nI vissa fall skrivs hotmodeller inte bara f\u00f6r infrastrukturella komponenter utan ocks\u00e5 f\u00f6r specifika IS eller deras komponenter, s\u00e5som ett fel i DBMS med logisk f\u00f6rst\u00f6ring av datakonstruktionen.
\nAlla beslut inom projektet f\u00f6r att skydda mot odefinierade hot \u00e4r \u00f6verfl\u00f6diga.<\/p>\n

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

Om de behandlade uppgifterna omfattas av s\u00e4rskilda regler som st\u00e4lls av regulatorer, beh\u00f6vs n\u00f6dv\u00e4ndigtvis information om datam\u00e4ngder och regler f\u00f6r behandling\/lagring.<\/p>\n

M\u00e5l RPO\/RTO<\/b><\/p>\n

Design av alla typer av skydd kr\u00e4ver n\u00e4rvaro av indikatorer f\u00f6r m\u00e5l f\u00f6r datarf\u00f6rlust och m\u00e5ltid f\u00f6r \u00e5terst\u00e4llande av tj\u00e4nsten f\u00f6r varje av de beskrivna hoten.
\nIdealt sett b\u00f6r RPO och RTO ha associerade kostnader f\u00f6r datarf\u00f6rlust och driftstopp per tidsenhet.<\/p>\n

\"Design
\n
\nDelning av resurspooler<\/b><\/p>\n

Efter att ha samlat in all initial information \u00e4r det f\u00f6rsta steget att gruppera upps\u00e4ttningar av data och IS i pooler, baserat p\u00e5 hotmodeller och regulatoriska krav. Typen av uppdelning av olika pooler best\u00e4ms \u2013 antingen programvarum\u00e4ssigt p\u00e5 niv\u00e5 med systemprogramvara eller fysiskt.
\nExempel:
\n \u2014 Konturen som behandlar personuppgifter \u00e4r helt fysiskt \u00e5tskild fr\u00e5n andra system;
\n \u2014 S\u00e4kerhetskopior lagras p\u00e5 en separat lagringsl\u00f6sning.<\/p>\n

Poolerna kan emellertid vara med ofullst\u00e4ndig sj\u00e4lvst\u00e4ndighet, till exempel definieras tv\u00e5 pooler av datorkraft (processorkraft + RAM) som anv\u00e4nder en gemensam datalagringspool och en gemensam data\u00f6verf\u00f6ringspool.<\/p>\n

Processorkraft<\/b><\/p>\n

\"Design
\n
\nAbstracta behov av processorstyrka i virtualiserade datacenter m\u00e4ts i antalet virtuella processorer (vCPU) och graden av deras konsolidering p\u00e5 fysiska processorer (pCPU). I detta specifika fall motsvarar 1 pCPU = 1 fysiskt processor k\u00e4rna (utan att ta h\u00e4nsyn till Hyper-Threading). Antalet vCPU sammanr\u00e4knas \u00f6ver alla definierade resurspooler (var och en av dem kan ha sin egen konsolideringsgrad).
\nKonsolideringsgraden f\u00f6r belastade system erh\u00e5lls empiriskt, baserat p\u00e5 befintlig infrastruktur, eller vid pilotinstallation och belastningstestning. F\u00f6r icke-belastade system anv\u00e4nds \"best practices\". Specifikt anges medelv\u00e4rdet av VMware som 8:1.<\/p>\n

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

Det totala behovet av RAM f\u00e5r genom enkel summering. Anv\u00e4ndning av \u00f6verskrivning av RAM rekommenderas inte.<\/p>\n

Lagringsresurser<\/b><\/p>\n

Krav p\u00e5 lagringsresurser f\u00e5s genom att enkelt summera alla pooler efter volym och prestanda.
\nPrestandakrav uttrycks i IOPS i kombination med det genomsnittliga f\u00f6rh\u00e5llandet mellan l\u00e4sning\/skrivning och vid behov h\u00f6gsta svarstid.
\nSpecifika krav p\u00e5 kvaliteten av tj\u00e4nsten (QoS) f\u00f6r specifika pooler eller system m\u00e5ste anges s\u00e4rskilt.<\/p>\n

N\u00e4tverksresurser<\/b><\/p>\n

Krav p\u00e5 n\u00e4tverksresurser f\u00e5s genom att enkelt summera alla poolers bandbredd.
\nSpecifika krav p\u00e5 kvaliteten av tj\u00e4nsten (QoS) och latens (RTT) f\u00f6r specifika pooler eller system m\u00e5ste anges s\u00e4rskilt.
\nInom kraven p\u00e5 n\u00e4tverksresurser anges \u00e4ven krav p\u00e5 isolering och\/eller kryptering av n\u00e4tverkstrafik och f\u00f6redragna mekanismer (802.1q, IPSec etc.).<\/p>\n

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

I denna handledning behandlas inget annat val \u00e4n x86-arkitekturen och 100% virtualisering av servrar. D\u00e4rf\u00f6r \u00e4r valet av arkitektur f\u00f6r datorsystemet begr\u00e4nsat till valet av servervirtualiseringsplattform, serverformfaktor och allm\u00e4nna krav p\u00e5 serverkonfiguration.<\/p>\n

En nyckelfaktor vid valet \u00e4r tydlighet i anv\u00e4ndningen av den klassiska metoden med uppdelning av funktionerna f\u00f6r bearbetning, lagring och \u00f6verf\u00f6ring av data eller konvergerande.<\/p>\n

Klassisk arkitektur<\/i> inneb\u00e4r anv\u00e4ndning av intelligenta externa lagrings- och datatransportsystem, medan servrar endast bidrar med processorkraft och RAM till den gemensamma poolen av fysiska resurser. I extrema fall blir servrar helt anonyma, utan egna diskar eller ens ett systemidentifierare. I s\u00e5dana fall anv\u00e4nds en operativsystem- eller hypervisorstart fr\u00e5n inbyggda flashmedia eller ett externt lagringssystem (boot from SAN).
\nInom klassisk arkitektur g\u00f6rs valet mellan blad (blade) och rack (rack) fr\u00e4mst utifr\u00e5n f\u00f6ljande principer:
\n \u2014 Kostnadseffektivitet (i genomsnitt \u00e4r rackservrar billigare);
\n \u2014 Ber\u00e4kningsdensitet (blad har h\u00f6gre densitet);
\n \u2014 Energikonsumtion och v\u00e4rmeutveckling (blad har h\u00f6gre specifik v\u00e4rmeutveckling per enhet);
\n \u2014 Skalbarhet och hanterbarhet (blad kr\u00e4ver allm\u00e4nt mindre arbete vid stora installationer);
\n \u2014 Anv\u00e4ndning av expansionskort (valet f\u00f6r blad \u00e4r mycket begr\u00e4nsat).
\nKonvergent arkitektur<\/i> (\u00e4ven k\u00e4nd som hyperkonvergent<\/i>) inneb\u00e4r en kombination av databehandling och lagring, vilket leder till att servrarnas lokala diskar anv\u00e4nds och d\u00e4rmed avst\u00e5r fr\u00e5n formfaktorn av klassiska blad. F\u00f6r konvergerande system anv\u00e4nds antingen rackservrar eller klustersystem som kombinerar flera bladservrar och lokala diskar i ett enda chassi.<\/p>\n

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

F\u00f6r korrekt ber\u00e4kning av konfigureringen beh\u00f6ver man f\u00f6rst\u00e5 typen av belastning f\u00f6r milj\u00f6n eller varje oberoende kluster.
\nCPU bound<\/i> \u2013 en milj\u00f6 som \u00e4r begr\u00e4nsad av processorkraft. Att l\u00e4gga till RAM f\u00f6r\u00e4ndrar ingenting n\u00e4r det g\u00e4ller prestanda (antal VM p\u00e5 servern).
\nMemory bound<\/i> \u2013 en milj\u00f6 som \u00e4r begr\u00e4nsad av RAM-minnet. Mer RAM p\u00e5 servern till\u00e5ter att fler VM kan startas.
\nGB \/ MHz (GB \/ pCPU) \u2013 det genomsnittliga f\u00f6rh\u00e5llandet mellan den specifika belastningens minnes- och processorkraft. Kan anv\u00e4ndas f\u00f6r att ber\u00e4kna det n\u00f6dv\u00e4ndiga minnesvolymen vid angiven prestanda och vice versa. <\/p>\n

Ber\u00e4kning av serverkonfiguration<\/b><\/p>\n

\"Design
\n
\nF\u00f6rst m\u00e5ste man identifiera alla typer av belastning och besluta om man ska kombinera eller separera olika ber\u00e4kningspooler \u00f6ver olika kluster.
\nD\u00e4refter best\u00e4ms f\u00f6r varje definierat kluster f\u00f6rh\u00e5llandet GB \/ MHz vid k\u00e4nd belastning. Om belastningen inte \u00e4r k\u00e4nd i f\u00f6rv\u00e4g, men man har en ungef\u00e4rlig f\u00f6rst\u00e5else av niv\u00e5erna f\u00f6r CPU-belastning, kan man anv\u00e4nda standardkvoter f\u00f6r vCPU:pCPU f\u00f6r att \u00f6vers\u00e4tta kraven f\u00f6r pooler till fysiska. <\/p>\n

F\u00f6r varje kluster delar vi summan av kraven p\u00e5 vCPU med kvoten:
\nvCPU_samling \/ vCPU:pCPU = pCPU_samling \u2013 det n\u00f6dv\u00e4ndiga antalet fysiska k\u00e4rnor
\npCPU_samling \/ 1.25 = pCPU_ht \u2013 antalet k\u00e4rnor justerat f\u00f6r Hyper-Threading
\nAnta att vi beh\u00f6ver ber\u00e4kna ett kluster med 190 k\u00e4rnor \/ 3.5 TB RAM. Vi antar h\u00e4r att m\u00e5let \u00e4r 50% belastning p\u00e5 CPU och 75% p\u00e5 RAM.<\/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

I det h\u00e4r fallet anv\u00e4nder vi alltid avrundning upp\u00e5t till n\u00e4rmaste heltal (=ROUNDUP(A1;0)).
\nDet framg\u00e5r tydligt av tabellen att flera serverkonfigurationer \u00e4r balanserade med tanke p\u00e5 m\u00e5len:
\n \u2014 26 servrar 2*6c \/ 192 GB
\n \u2014 19 servrar 2*10c \/ 256 GB
\n \u2014 10 servrar 2*18c \/ 512 GB <\/p>\n

Valet av dessa konfigurationer m\u00e5ste g\u00f6ras med h\u00e4nsyn till ytterligare faktorer, s\u00e5som v\u00e4rmeutveckling och tillg\u00e4nglig kylning, redan anv\u00e4nda servrar eller kostnader.<\/p>\n

S\u00e4rskildheter vid val av serverkonfiguration<\/b><\/p>\n

Breda VM. Vid behov av att placera breda VM (j\u00e4mf\u00f6rbara med 1 NUMA-nod och mer) rekommenderas det att v\u00e4lja en serverkonfiguration som h\u00e5ller dessa VM inom en NUMA-nod s\u00e5 mycket som m\u00f6jligt. Vid ett stort antal breda VM finns det en risk f\u00f6r fragmentering av klustrets resurser, och i dessa fall v\u00e4ljs servrar som m\u00f6jligg\u00f6r att placera breda VM s\u00e5 t\u00e4tt som m\u00f6jligt.<\/p>\n

Storleken p\u00e5 ett dom\u00e4n f\u00f6r enskilt fel.<\/b> <\/p>\n

Valet av serverstorlek g\u00f6rs ocks\u00e5 med principen om att minimera dom\u00e4nen f\u00f6r enskilt fel. Till exempel vid valet mellan:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nVid lika villkor b\u00f6r det andra alternativet v\u00e4ljas, eftersom om en server g\u00e5r ner (eller underh\u00e5lls) f\u00f6rloras inte 33% av klustrets resurser, utan 17%. P\u00e5 samma s\u00e4tt minskar antalet VM och ISer som p\u00e5verkas av en incident med h\u00e4lften.<\/p>\n

Ber\u00e4kning av klassisk lagringssystem prestanda<\/b><\/p>\n

\"Design
\n
\nKlassisk lagringssystem ber\u00e4knas alltid utifr\u00e5n v\u00e4rsta scenariot (worst case scenario), utan att ta h\u00e4nsyn till den operativa cachen och optimeringen av operationerna.
\nSom grundl\u00e4ggande prestandaindikatorer tar vi den mekaniska prestandan fr\u00e5n disken (IOPSdisk):
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

D\u00e4refter ber\u00e4knas antalet diskar i diskpoolen enligt f\u00f6ljande formel: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. D\u00e4r:
\n \u2014 TotalIOPS<\/i> \u2013 den totala n\u00f6dv\u00e4ndiga prestandan i IOPS fr\u00e5n diskpoolen
\n \u2014 RW<\/i> \u2013 procentandelen av l\u00e4soperationer
\n \u2014 RAIDpen<\/i> \u2013 RAID-straff f\u00f6r den valda RAID-niv\u00e5n<\/p>\n

\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435 \u043e\u0431 \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0435 RAID \u0438 RAID Penalty \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u0437\u0434\u0435\u0441\u044c — Prestanda f\u00f6r lagringssystem. Del ett.<\/a><\/noindex> och Prestanda f\u00f6r lagringssystem. Del tv\u00e5.<\/a><\/noindex> och Prestanda f\u00f6r lagringssystem. Del tre<\/a><\/noindex><\/p>\n

Baserat p\u00e5 det ber\u00e4knade antalet diskar ber\u00e4knas m\u00f6jliga alternativ som uppfyller kraven p\u00e5 lagringskapacitet, inklusive alternativ med fler-niv\u00e5 lagring.
\nBer\u00e4kning av system med SSD som lagringsniv\u00e5 behandlas separat.
\nEgenskaper f\u00f6r ber\u00e4kning av system med Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 en allm\u00e4n ben\u00e4mning p\u00e5 alla propriet\u00e4ra teknologier som anv\u00e4nder flashminne som andra niv\u00e5ns cache. Vid anv\u00e4ndning av flash-cache ber\u00e4knas lagringssystem vanligtvis f\u00f6r att hantera den etablerade belastningen fr\u00e5n magnetdiskar, medan den maximala belastningen hanteras av cachen.
\nVid detta tillf\u00e4lle \u00e4r det n\u00f6dv\u00e4ndigt att f\u00f6rst\u00e5 belastningsprofilen och graden av lokalisering av \u00e5tkomst till lagringens volymblock. Flash-cache \u00e4r en teknologi f\u00f6r belastningar med h\u00f6g lokaliseringsgrad av f\u00f6rfr\u00e5gningar, och \u00e4r praktiskt taget oanv\u00e4ndbar f\u00f6r j\u00e4mnt belastade volymer (som till exempel f\u00f6r analytiska system). <\/p>\n

Ber\u00e4kning av hybrida system low-end \/ mid-range<\/b><\/p>\n

Hybrida system i l\u00e5g och medelklass anv\u00e4nder fler-niv\u00e5 lagring med databehandling mellan niv\u00e5erna enligt schema. I detta fall \u00e4r blockstorleken f\u00f6r fler-niv\u00e5 lagring hos de b\u00e4sta modellerna 256 MB. Dessa egenskaper g\u00f6r det om\u00f6jligt att betrakta teknologin f\u00f6r fler-niv\u00e5 lagring som en teknologi f\u00f6r att \u00f6ka prestanda, som m\u00e5nga felaktigt tror. Fler-niv\u00e5 lagring i l\u00e5g- och medelklassystem \u00e4r en teknik f\u00f6r att optimera lagringskostnader f\u00f6r system med uttalad oj\u00e4mn belastning.<\/p>\n

F\u00f6r flerniv\u00e5lagring ber\u00e4knas f\u00f6rst och fr\u00e4mst prestandan f\u00f6r den \u00f6vre niv\u00e5n, medan den nedre lagringsniv\u00e5n endast anses bidra med den saknade lagringskapaciteten. F\u00f6r ett hybrid flerniv\u00e5system \u00e4r det n\u00f6dv\u00e4ndigt att anv\u00e4nda flash cache-teknik f\u00f6r den flerniv\u00e5poolen f\u00f6r att kompensera f\u00f6r prestandafallet f\u00f6r data som pl\u00f6tsligt blivit varma fr\u00e5n den nedre niv\u00e5n.<\/p>\n

Anv\u00e4ndning av SSD i flerniv\u00e5diskpoolen<\/b><\/p>\n

\"Design
\n
\nAnv\u00e4ndningen av SSD i flerniv\u00e5diskpoolen har variationer beroende p\u00e5 egenskaperna hos algoritmerna f\u00f6r flash cache fr\u00e5n denna tillverkare.
\nAllm\u00e4n praxis f\u00f6r lagringspolicy f\u00f6r diskpool med SSD-niv\u00e5 \u00e4r SSD f\u00f6rst.
\nRead Only Flash Cache.<\/i> F\u00f6r flashcache endast f\u00f6r l\u00e4sning uppst\u00e5r lagringsniv\u00e5n p\u00e5 SSD vid betydande lokalisering av skrivoperationer oavsett cachen.
\nRead \/ Write Flash Cache.<\/i> Vid skrivcache fastst\u00e4lls f\u00f6rst den maximala cachekapaciteten, och lagringsniv\u00e5n p\u00e5 SSD uppst\u00e5r endast vid otillr\u00e4cklig cachestorlek f\u00f6r att hantera hela den lokalisering belastningen.
\nPrestandaber\u00e4kningen f\u00f6r SSD och cachar g\u00f6rs varje g\u00e5ng baserat p\u00e5 tillverkarens rekommendationer, men alltid f\u00f6r det s\u00e4msta fallet.
\n
K\u00e4lla: 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 av virtualiserad datacenter | ProHoster","description":"Introduktion Informationssystem med punkt.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}