{"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\/da\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Design af den virtualiserede datacenter.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

Informationssystemet set fra brugerens perspektiv er godt defineret i GOST RV 51987 \u2014 \"et automatiseret system, hvis funktion resulterer i pr\u00e6sentationen af udg\u00e5ende information til efterf\u00f8lgende brug\". Betragtet ud fra den indre struktur er ethvert IS i bund og grund et system af sammenkoblede algoritmer implementeret i kode. I en bredere forst\u00e5else gennemf\u00f8rer Turing-Church-teoremet, at et algoritme (og dermed IS) transformationen af et s\u00e6t inputdata til et s\u00e6t outputdata.
\nMan kan endda sige, at meningen med eksistensen af informationssystemet ligger i transformationen af inputdata. Derfor bestemmes v\u00e6rdien af IS og hele komplekset af IS gennem v\u00e6rdien af input- og outputdata.
\nI lyset af dette skal designet starte med og tage data som udgangspunkt og tilpasse arkitektur og metoder til strukturen og betydningen af dataene.<\/p>\n

Opbevarede data<\/b>
\nEn afg\u00f8rende fase i forberedelsen til design er at f\u00e5 egenskaberne for alle datam\u00e6ngder, der planl\u00e6gges behandlet og opbevaret. Disse egenskaber omfatter:
\n \u2014 Dataomfang;
\n \u2014 Oplysninger om dataenes livscyklus (v\u00e6kst af nye data, levetid, behandling af for\u00e6ldede data);
\n \u2014 Klassificering af data set i forhold til indflydelse p\u00e5 virksomhedens kerneforretning (den s\u00e5kaldte tredighed af fortrolighed, integritet, tilg\u00e6ngelighed) sammen med \u00f8konomiske indikatorer (f.eks. omkostninger ved datatab over den sidste time);
\n \u2014 Geografi for databehandling (fysisk placering af behandlingssystemer);
\n \u2014 Regulatoriske krav for hver dataklasse (f.eks. FZ-152, PCI DSS).<\/p>\n

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

Informationssystemer<\/b><\/p>\n

Data lagres ikke kun, men behandles (transformeres) ogs\u00e5 af informationssystemer. N\u00e6ste skridt efter at have indsamlet dataegenskaberne er at lave en s\u00e5 fuldst\u00e6ndig opg\u00f8relse som muligt over informationssystemerne, deres arkitektoniske egenskaber, afh\u00e6ngigheder og krav til infrastrukturer i form af de fire ressourcekategorier:
\n \u2014 Processorberegningskapacitet;
\n \u2014 M\u00e6ngden af RAM;
\n \u2014 Krav til m\u00e6ngde og ydeevne af datalageringssystemer;
\n \u2014 Krav til datanetv\u00e6rk (eksterne kanaler, kanaler mellem komponenter i IS).
\nKravene skal v\u00e6re til stede for hver service\/mikroservice i systemet.
\nDet er vigtigt at bem\u00e6rke, at der skal v\u00e6re data om, hvordan systemet p\u00e5virker virksomhedens kerneforretning i form af omkostninger ved systemnedbrud (rubler per time).<\/p>\n

Trusselsmodel<\/b><\/p>\n

Der skal v\u00e6re en formel trusselsmodel, som angiver, hvilke trusler der planl\u00e6gges at beskytte data\/services imod. Denne model omfatter ikke kun aspekter af fortrolighed, men ogs\u00e5 integritet og tilg\u00e6ngelighed. For eksempel:
\n \u2014 Nedbrud af en fysisk server;
\n \u2014 Nedbrud af top-of-the-rack switch;
\n \u2014 Brud p\u00e5 den optiske kommunikationskanal mellem datacentre;
\n \u2014 Nedbrud af det operative SAN i sin helhed.
\nI nogle tilf\u00e6lde skrives trusselsmodellerne ikke kun for infrastrukturelle komponenter, men ogs\u00e5 for specifikke systemer eller deres komponenter, som for eksempel nedbrud af DBMS med logisk \u00f8del\u00e6ggelse af datastrukturen.
\nAlle beslutninger under projektet vedr\u00f8rende beskyttelse mod ikke-beskrivelige trusler er overfl\u00f8dige.<\/p>\n

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

Hvis de behandlede data er omfattet af s\u00e6rlige regler fastsat af regulatorer, er det n\u00f8dvendigt at have information om datam\u00e6ngder og regler for behandling\/opbevaring.<\/p>\n

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

Design af enhver form for beskyttelse kr\u00e6ver tilstedev\u00e6relse af m\u00e5lte tab af data og m\u00e5lte restitutionstid for servicen for hver af de beskrevne trusler.
\nIdeelt set skal RPO og RTO have tilknyttede omkostninger ved tab af data og nedbrud pr. tidsenhed.<\/p>\n

\"Design
\n
\nOpdeling i ressourcepuljer<\/b><\/p>\n

Efter indsamling af al den prim\u00e6re inputinformation er det f\u00f8rste skridt at gruppere datam\u00e6ngder og systemer i puljer, baseret p\u00e5 trusselsmodeller og regulatoriske krav. Type opdeling af de forskellige puljer bestemmes \u2013 softwarem\u00e6ssigt p\u00e5 systemsoftware niveau eller fysisk.
\nEksempler:
\n \u2014 Omr\u00e5det, der behandler persondata, er helt fysisk adskilt fra de \u00f8vrige systemer;
\n \u2014 Sikkerhedskopier opbevares p\u00e5 en separat SAN.<\/p>\n

Puljer kan dog have delvis uafh\u00e6ngighed; for eksempel defineres to puljer af computerressourcer (processor kapacitet + RAM), der bruger en f\u00e6lles dataopbevaringspulje og en f\u00e6lles dataoverf\u00f8rselsressourcepulje.<\/p>\n

Processor kapacitet<\/b><\/p>\n

\"Design
\n
\nDe abstrakte behov for processorkraft i et virtualiseret datacenter m\u00e5les i antal virtuelle processorer (vCPU) og deres konsolideringsforhold til fysiske processorer (pCPU). I dette specifikke tilf\u00e6lde svarer 1 pCPU til 1 fysisk processor-kerne (uden hensyntagen til Hyper-Threading). Antallet af vCPU opsummeres p\u00e5 tv\u00e6rs af alle definerede ressourcepuljer (hver af dem kan have sit eget konsolideringsforhold).
\nKonsolideringsforholdet for belastede systemer opn\u00e5s empirisk, baseret p\u00e5 eksisterende infrastruktur, eller ved pilotinstallation og belastningstestning. For ubearbejdede systemer anvendes 'best practice'. Is\u00e6r angiver VMware et gennemsnitligt forhold p\u00e5 8:1.<\/p>\n

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

Det samlede behov for hukommelse opn\u00e5s ved simpel opsummering. Anvendelse af overtegning p\u00e5 hukommelse anbefales ikke.<\/p>\n

Lagringsressourcer<\/b><\/p>\n

Kraven til lagringsressourcer opn\u00e5s ved simpel opsummering af alle puljer baseret p\u00e5 kapacitet og ydelse.
\nKravene til ydelse udtrykkes i IOPS i kombination med det gennemsnitlige forhold mellem l\u00e6se\/skriv og, hvis n\u00f8dvendigt, den maksimale svartid.
\nKravene til kvaliteten af service (QoS) for specifikke puljer eller systemer skal angives s\u00e6rskilt.<\/p>\n

Dataoverf\u00f8rselsressourcer<\/b><\/p>\n

Kravene til dataoverf\u00f8rselsnetv\u00e6rket opn\u00e5s ved simpel opsummering af alle puljer af b\u00e5ndbredde.
\nKravene til kvaliteten af service (QoS) og forsinkelse (RTT) for specifikke puljer eller systemer skal angives s\u00e6rskilt.
\nInden for kravene til dataoverf\u00f8rselsressourcer angives ogs\u00e5 krav til isolation og\/eller kryptering af netv\u00e6rkstrafik samt pr\u00e6fererede mekanismer (802.1q, IPSec osv.).<\/p>\n

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

I denne vejledning overvejes der ikke andet valg end x86-arkitekturen og 100% virtualisering af servere. S\u00e5ledes reduceres valget af arkitektur for beregningssystemet til valg af server-virtualiseringsplatform, formfaktor for servere og generelle konfigurationskrav for servere.<\/p>\n

Et centralt punkt i valget er klarhed i brugen af den klassiske tilgang, der adskiller databehandling, lagring og transmission, eller den konvergerende.<\/p>\n

Klassisk arkitektur<\/i> betyder brugen af intelligente eksterne lagrings- og dataoverf\u00f8rselssystemer, mens serverne kun bidrager til det samlede pool af fysiske ressourcer med CPU-kraft og RAM. I ekstremt tilf\u00e6lde bliver serverne helt anonyme, uden hverken egne drev eller systemidentifikator. I dette tilf\u00e6lde bruges boot af OS eller hypervisor fra indbyggede flash-drev eller fra et eksternt lagringssystem (boot from SAN).
\nInden for den klassiske arkitektur v\u00e6lges mellem blade og rack prim\u00e6rt ud fra f\u00f8lgende principper:
\n \u2014 \u00d8konomisk effektivitet (i gennemsnit er rack-servere billigere);
\n \u2014 Beregningsdensitet (blade har en h\u00f8jere);
\n \u2014 Energiforbrug og varmeudvikling (blade har h\u00f8jere specifik forbrug pr. enhed);
\n \u2014 Skalerbarhed og h\u00e5ndterbarhed (blade kr\u00e6ver generelt mindre indsats ved store installationer);
\n \u2014 Brug af udvidelseskort (valget for blade er meget begr\u00e6nset).
\nKonvergerende arkitektur<\/i> (ogs\u00e5 kendt som hyperkonvergerende<\/i>) indeb\u00e6rer en kombination af funktioner til behandling og lagring af data, hvilket f\u00f8rer til brugen af lokale drev i serverne og dermed opgivelse af formfaktoren for klassiske blade. Til konvergerende systemer bruges enten rack-servere eller klyngesystemer, der kombinerer flere blade-servere og lokale drev i et enkelt chassis.<\/p>\n

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

For korrekt beregning af konfigurationen skal man forst\u00e5 typen af belastning for milj\u00f8et eller hver af de uafh\u00e6ngige klynger.
\nCPU bound<\/i> \u2013 et milj\u00f8, der er begr\u00e6nset af CPU-kraft. Tils\u00e6tning af RAM \u00e6ndrer ikke noget med hensyn til ydeevne (m\u00e6ngden af VM p\u00e5 serveren).
\nMemory bound<\/i> \u2013 et milj\u00f8, der er begr\u00e6nset af RAM. En st\u00f8rre m\u00e6ngde RAM p\u00e5 serveren muligg\u00f8r k\u00f8rsel af et st\u00f8rre antal VM p\u00e5 serveren.
\nGB \/ MHz (GB \/ pCPU) \u2013 det gennemsnitlige forhold mellem hukommelses- og CPU-forbruget for den specifikke belastning. Kan bruges til beregning af det n\u00f8dvendige hukommelsesvolumen ved en given ydeevne og omvendt. <\/p>\n

Beregning af serverkonfiguration<\/b><\/p>\n

\"Design
\n
\nFor starters, it is necessary to determine all types of loads and decide on whether to combine or separate different computing pools across various clusters.
\nNext, for each of the defined clusters, the ratio of GB \/ MHz is determined based on known loads. If the load is not known in advance, but there is a rough understanding of the CPU power load level, standard coefficients vCPU:pCPU can be used to convert the requirements of pools into physical ones. <\/p>\n

For each cluster, the total requirements of the vCPU pools are divided by the coefficient:
\nvCPUsum \/ vCPU:pCPU = pCPUsum \u2013 required number of physical cores
\npCPUsum \/ 1.25 = pCPUht \u2013 the number of cores adjusted for Hyper-Threading
\nSuppose we need to calculate a cluster for 190 cores \/ 3.5TB of RAM. In this case, we assume a target CPU load of 50% and 75% for 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

In this case, we always use rounding up to the nearest whole number (=ROUNDUP(A1;0)).
\nFrom the table, it becomes clear that several server configurations are balanced for the target indicators:
\n \u2014 26 servers 2*6c \/ 192 GB
\n \u2014 19 servers 2*10c \/ 256 GB
\n \u2014 10 servers 2*18c \/ 512 GB <\/p>\n

The choice among these configurations must be made based on additional factors, such as thermal package and available cooling, already used servers, or cost.<\/p>\n

Features of server configuration selection<\/b><\/p>\n

Wide VMs. If there is a need to host wide VMs (comparable to 1 NUMA node and more), it is advisable to choose a server configuration that allows such VMs to stay within a NUMA node. With a large number of wide VMs, there is a risk of fragmenting the cluster resources, and in this case, servers should be selected that allow wide VMs to be accommodated as closely as possible.<\/p>\n

Size of the single point of failure domain.<\/b> <\/p>\n

The choice of server size is also made from the principle of minimizing the single point of failure domain. For example, when choosing between:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nAll other things being equal, the second option should be chosen since if one server fails (or is under maintenance), not 33% of the cluster's resources are lost, but 17%. Similarly, the number of VMs and IS affected by the failure is halved.<\/p>\n

Beregning af klassisk SAN baseret p\u00e5 ydeevne<\/b><\/p>\n

\"Design
\n
\nKlassisk SAN beregnes altid ud fra det v\u00e6rste scenarie (worst case scenario), som udelukker indflydelsen fra RAM-cache og optimering af operationer.
\nSom grundl\u00e6ggende ydeevneparametre tager vi den mekaniske ydeevne fra disken (IOPSdisk):
\n \u2014 7,2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

Antallet af diske i diskpuljen beregnes derefter med f\u00f8lgende formel: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. Hvor:
\n \u2014 TotalIOPS<\/i> \u2013 den samlede kr\u00e6vede ydeevne i IOPS fra diskpuljen
\n \u2014 RW<\/i> \u2013 procentdelen af l\u00e6seoperationer
\n \u2014 RAIDpen<\/i> \u2013 RAID-straf for det valgte RAID-niveau<\/p>\n

L\u00e6s mere om RAID-enheder og RAID-b\u00f8de her \u2014 Ydeevne for SAN. Del et.<\/a><\/noindex> og Ydeevne for SAN. Del to.<\/a><\/noindex> og Ydeevne for SAN. Del tre.<\/a><\/noindex><\/p>\n

Baseret p\u00e5 det opn\u00e5ede antal diske beregnes de mulige varianter, der opfylder kravene til lagerkapacitet, herunder muligheder med lagring p\u00e5 flere niveauer.
\nBeregning af systemer med SSD som lagerniveau betragtes separat.
\nEgenskaber ved beregning af systemer med Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 en generel betegnelse for alle m\u00e6rkespecifikke teknologier, der bruger flash-hukommelse som sekund\u00e6rt cache. Ved brug af flash-cache beregnes SAN typisk for at sikre, at belastningen fra magnetiske diske er stabil, mens den maksimale belastning h\u00e5ndteres af cachen.
\nDet er vigtigt at forst\u00e5 belastningsprofilen og graden af lokaliserede henvendelser til lagervolumenerne. Flash-cache er en teknologi til belastninger med h\u00f8j lokaliseringsintensitet og er praktisk talt uanvendelig for j\u00e6vnt belastede volumener (som for eksempel til analyse systemer). <\/p>\n

Beregning af hybride low-end\/mid-range systemer<\/b><\/p>\n

Hybrid systems of lower and mid-range use multi-level storage with scheduled data movement between levels. In this case, the block size of multi-level storage in the best models is 256 MB. These characteristics do not allow us to consider multi-level storage technology as a performance enhancement technology, as many mistakenly believe. Multi-level storage in lower and mid-range systems is a cost optimization technology for storage systems with pronounced uneven load.<\/p>\n

For lagring p\u00e5 flere niveauer beregnes ydeevnen f\u00f8rst og fremmest for det \u00f8verste niveau, mens det nederste lag kun betragtes som en medvirkende kapacitet. For et hybridlagringssystem er det afg\u00f8rende at bruge flash-cache-teknologi for at kompensere for ydeevnedrop for pludseligt varme data fra det nederste niveau.<\/p>\n

Brug af SSD i en multi-level diskpool<\/b><\/p>\n

\"Design
\n
\nBrug af SSD i en multi-level diskpool har variationer afh\u00e6ngigt af producentens implementering af flash-cache-algoritmer.
\nGenerel praksis for lagringspolitikken for en diskpool med SSD-niveau er \u2013 SSD first.
\nRead Only Flash Cache.<\/i> For read-only flash cache, the SSD storage level appears when writing operations are significantly localized, regardless of the cache.
\nRead \/ Write Flash Cache.<\/i> In the case of write flash cache, the maximum cache capacity is first set, and the SSD storage level only appears when the cache size is insufficient to handle the entire localized load.
\nThe performance calculation for SSD and cache is performed 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 with a point.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}