{"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\/nl\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Ontwerp van een gevirtualiseerd datacenter","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ontwerp
\n
\nInleiding<\/b><\/p>\n

Een informatiesysteem wordt vanuit het perspectief van de gebruiker goed gedefinieerd in GOST RV 51987 als 'een geautomatiseerd systeem waarvan de functie bestaat uit het presenteren van outputinformatie voor toekomstig gebruik'. Als we naar de interne structuur kijken, is in feite elk IS een systeem van in code ge\u00efmplementeerde onderling verbonden algoritmen. In brede zin voert de stelling van Turing-Church het algoritme (en dus IS) een transformatie uit van een set invoergegevens naar een set uitvoergegevens.
\nMen kan zelfs zeggen dat de transformatie van invoergegevens de essentie van het bestaan van een informatiesysteem vormt. De waarde van een IS en het gehele complex van IS wordt derhalve bepaald door de waarde van de invoer- en uitvoergegevens.
\nOp basis hiervan moet het ontwerp beginnen en zijn fundament vinden in de gegevens, waarbij de architectuur en methoden worden afgestemd op de structuur en betekenis van de gegevens.<\/p>\n

Opgeslagen gegevens<\/b>
\nEen cruciale stap in de voorbereiding van het ontwerp is het verkrijgen van kenmerken van alle datasets die bewerkt en opgeslagen zullen worden. Deze kenmerken omvatten:
\n \u2014 De hoeveelheid gegevens;
\n \u2014 Informatie over de levenscyclus van de gegevens (toename van nieuwe gegevens, levensduur, verwerking van verouderde gegevens);
\n \u2014 Classificatie van gegevens vanuit het perspectief van invloed op de kernactiviteiten van het bedrijf (de triade van vertrouwelijkheid, integriteit, beschikbaarheid), samen met financi\u00eble indicatoren (bijv. de kostprijs van gegevensverlies in het afgelopen uur);
\n \u2014 Geografie van gegevensverwerking (fysieke locatie van verwerkende systemen);
\n \u2014 Vereisten van toezichthouders voor elke klasse gegevens (bijv. FZ-152, PCI DSS).<\/p>\n

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

Informatiesystemen<\/b><\/p>\n

Gegevens worden niet alleen opgeslagen, maar ook verwerkt (getransformeerd) door informatiesystemen. De volgende stap, na het verkrijgen van de gegevenskenmerken, is een zo volledig mogelijke inventarisatie van de informatiesystemen, hun architectonische kenmerken, onderlinge afhankelijkheden en infrastructuurvereisten in termen van vier soorten middelen:
\n \u2014 Verwerkingskracht van de processor;
\n \u2014 Hoeveelheid RAM;
\n \u2014 Vereisten voor de hoeveelheid en prestaties van de opslagsystemen;
\n \u2014 Netwerkvereisten voor gegevensoverdracht (externe kanalen, kanalen tussen IS-componenten).
\nDe vereisten moeten per service\/microservice in het informatiesysteem aanwezig zijn.
\nHet is belangrijk om de gegevens over de impact van het informatiesysteem op de kernbusiness van het bedrijf op te nemen in termen van de kosten van stilstand van het informatiesysteem (rubels per uur).<\/p>\n

Bedreigingsmodel<\/b><\/p>\n

Er moet een formeel bedreigingsmodel beschikbaar zijn om de gegevens\/services te beschermen. Dit model omvat niet alleen aspecten van vertrouwelijkheid, maar ook van integriteit en beschikbaarheid. Bijvoorbeeld:
\n \u2014 Uitval van een fysieke server;
\n \u2014 Uitval van een top-of-the-rack switch;
\n \u2014 Onderbreking van de optische communicatielijn tussen datacenters;
\n \u2014 Volledige uitval van de operationele opslag.
\nIn sommige gevallen worden bedreigingsmodellen niet alleen voor infrastructuurcomponenten geschreven, maar ook voor specifieke informatiesystemen of hun componenten, zoals bijvoorbeeld de uitval van een databasesysteem met logische vernietiging van de datastructuur.
\nAlle oplossingen binnen het project ter bescherming tegen niet-omschreven bedreigingen zijn overbodig.<\/p>\n

Regulatoire vereisten<\/b><\/p>\n

Als de verwerkte gegevens onder speciale regels vallen die door de regelgevers worden vastgesteld, is informatie over datasets en regels voor verwerking\/opslag absoluut noodzakelijk.<\/p>\n

Doelstellingen RPO\/RTO<\/b><\/p>\n

Het ontwerpen van elke vorm van bescherming vereist gegevens over de doelverliezen en de doelhersteltijd van de service voor elke van de beschreven bedreigingen.
\nIdealiter moeten RPO en RTO gekoppelde kosten voor dataverlies en stilstand per tijdseenheid hebben.<\/p>\n

\"Ontwerp
\n
\nVerdeling in resources pools<\/b><\/p>\n

Na het verzamelen van alle initi\u00eble invoergegevens is de eerste stap het groeperen van datasets en informatiesystemen in pools, rekening houdend met de bedreigingsmodellen en de vereisten van de regelgevers. Het type scheiding van verschillende pools wordt bepaald - programmatisch op het niveau van de systeemsoftware of fysiek.
\nVoorbeelden:
\n \u2014 De contour die persoonlijke gegevens verwerkt, is volledig fysiek gescheiden van andere systemen;
\n \u2014 Back-ups worden opgeslagen op een aparte opslag.<\/p>\n

Pools kunnen echter met onvolledige onafhankelijkheid zijn, bijvoorbeeld er worden twee pools van rekenkracht (processorvermogen + RAM) gedefinieerd die gebruikmaken van een enkele pool voor gegevensopslag en een enkele pool voor gegevensoverdracht.<\/p>\n

Processorvermogen<\/b><\/p>\n

\"Ontwerp
\n
\nAbstracte behoeften aan de verwerkingskracht van een gevirtualiseerd datacenter worden gemeten in het aantal virtuele processoren (vCPU) en de consolidatiefactor ervan op fysieke processoren (pCPU). In dit specifieke geval is 1 pCPU = 1 fysiek processor core (zonder rekening te houden met Hyper-Threading). Het aantal vCPU wordt opgeteld over alle gedefinieerde resource pools (elke pool kan zijn eigen consolidatiefactor hebben).
\nDe consolidatiefactor voor drukke systemen wordt empirisch bepaald, gebaseerd op de bestaande infrastructuur, of tijdens een pilotinstallatie en belastingstest. Voor niet-belaste systemen worden 'best practices' toegepast. VMware noemt bijvoorbeeld een gemiddelde factor van 8:1.<\/p>\n

Geheugen<\/b><\/p>\n

De totale behoefte aan RAM wordt verkregen door eenvoudige optelling. Het gebruik van overboeking van RAM wordt niet aanbevolen.<\/p>\n

Opslagresources<\/b><\/p>\n

De eisen voor opslagresources worden verkregen door de totale hoeveelheid en prestaties van alle pools op te tellen.
\nDe prestatie-eisen worden uitgedrukt in IOPS, in combinatie met de gemiddelde verhouding van lezen\/schrijven en indien nodig de maximale responstijd.
\nDe eisen voor kwaliteitsborging (QoS) moeten afzonderlijk worden vermeld voor specifieke pools of systemen.<\/p>\n

Netwerkresources<\/b><\/p>\n

De eisen voor netwerkresources worden verkregen door de totale bandbreedte van alle pools op te tellen.
\nDe eisen voor kwaliteitsborging (QoS) en latentie (RTT) moeten afzonderlijk worden vermeld voor specifieke pools of systemen.
\nBinnen de eisen voor netwerkresources worden ook eisen voor isolatie en\/of encryptie van netwerkverkeer en de voorkeurmechanismen (802.1q, IPSec, enz.) opgegeven.<\/p>\n

Architectuuroptie<\/b><\/p>\n

In deze handleiding wordt geen andere optie behandeld dan de x86-architectuur en 100% servervirtualisatie. Daarom beperkt de keuze van de architectuur van het rekensysteem zich tot de keuze van het virtualisatieplatform, de serverformfactor en de algemene configuratie-eisen voor servers.<\/p>\n

Een belangrijk punt bij de keuze is de duidelijkheid over het gebruik van de klassieke benadering met scheiding van gegevensverwerking, opslag en overdracht, of convergente architectuur.<\/p>\n

Klassieke architectuur<\/i> betekent het gebruik van intelligente externe opslagsystemen en gegevensoverdracht, terwijl servers alleen rekenkracht en RAM aan de gezamenlijke pool van fysieke middelen bijdragen. In extreme gevallen worden servers volledig anoniem, zonder niet alleen eigen schijven maar zelfs zonder een systeemidentificator. In dat geval wordt het besturingssysteem of hypervisor op ingebouwde flashdragers of vanuit een extern opslagsysteem opgestart (boot from SAN).
\nBinnen de klassieke architectuur wordt de keuze tussen blades en rackservers vooral gemaakt op basis van de volgende principes:
\n \u2014 Kosten-effectiviteit (gemiddeld zijn rackservers goedkoper);
\n \u2014 Rekendichtheid (blades hebben een hogere dichtheid);
\n \u2014 Energieverbruik en warmteontwikkeling (blades hebben een hoger verbruik per eenheid);
\n \u2014 Schaalbaarheid en beheersbaarheid (blades vereisen over het algemeen minder inspanning bij grote installaties);
\n \u2014 Gebruik van uitbreidingskaarten (voor blades is de keuze zeer beperkt).
\nConvergente architectuur<\/i> (ook bekend als hyperconvergent<\/i>) houdt in dat de functies voor gegevensverwerking en -opslag worden gecombineerd, wat leidt tot het gebruik van lokale schijven van servers en daardoor het afzien van het klassieke blade-formaat. Voor convergente systemen worden zowel rackservers als cluster systemen gebruikt, die in \u00e9\u00e9n behuizing meerdere blade-servers en lokale schijven combineren.<\/p>\n

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

Voor een correcte configuratieberekening is het belangrijk om het type belasting voor de omgeving of elk van de onafhankelijke clusters te begrijpen.
\nCPU bound<\/i> \u2013 een omgeving die beperkt is in prestaties door de CPU-kracht. Het toevoegen van RAM verandert niets aan de prestaties (aantal VM's op de server).
\nGeheugen bound<\/i> \u2013 een omgeving die beperkt is door RAM. Meer RAM op de server maakt het mogelijk om meer VM's op de server te draaien.
\nGB \/ MHz (GB \/ pCPU) \u2013 de gemiddelde verhouding van het geheugenverbruik door deze specifieke belasting in verhouding tot de CPU-kracht. Dit kan worden gebruikt om de benodigde hoeveelheid geheugen te berekenen bij een gegeven prestatiedoel en vice versa. <\/p>\n

Configuratieberekening van de server<\/b><\/p>\n

\"Ontwerp
\n
\nOm te beginnen moet je alle soorten belasting bepalen en beslissen of je verschillende rekenpools over verschillende clusters wilt combineren of scheiden.
\nVervolgens wordt voor elk van de gedefinieerde clusters de verhouding GB \/ MHz vastgesteld bij een vooraf bekende belasting. Als de belasting niet van tevoren bekend is, maar er wel een globaal begrip is van het niveau van de CPU-belasting, kunnen standaardverhoudingen vCPU:pCPU worden gebruikt om de vereisten van de pools om te zetten naar fysiek. <\/p>\n

Voor elk cluster delen we de totale vCPU-vereisten van de pools door de verhouding:
\nvCPUtotaal \/ vCPU:pCPU = pCUtotaal \u2013 benodigd aantal fysieke kernen
\npCUtotaal \/ 1.25 = pCUht \u2013 aantal kernen gecorrigeerd voor Hyper-Threading
\nLaten we aannemen dat we een cluster moeten berekenen met 190 kernen \/ 3,5 TB RAM. We nemen daarbij een doelstelling van 50% CPU-belasting en 75% voor het RAM.<\/p>\n

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

Geheugen<\/b>
\n3500
\nGeheugen-util<\/b>
\n75%<\/p>\n

Socket<\/b>
\nCore<\/b>
\nSrv \/ CPU<\/b>
\nSrv Geheugen<\/b>
\nSrv \/ Geheugen<\/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 dit geval gebruiken we altijd afronding naar het dichtstbijzijnde gehele getal naar boven (=ROUNDUP(A1;0)).
\nUit de tabel blijkt duidelijk dat er verschillende serverconfiguraties zijn die in balans zijn met de doelstellingen:
\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

De keuze uit deze configuraties moet verder worden gemaakt op basis van aanvullende factoren, zoals thermisch pakket en beschikbare koeling, al gebruikte servers, of kosten.<\/p>\n

Kenmerken van de keuze van serverconfiguratie<\/b><\/p>\n

Breed VM. Bij de noodzaak om brede VM's te plaatsen (vergelijkbaar met 1 NUMA-knooppunt en meer) wordt aanbevolen om indien mogelijk een server te kiezen met een configuratie die dergelijke VM's binnen het NUMA-knooppunt kan houden. Bij een groot aantal brede VM's bestaat het gevaar van fragmentatie van de clusterresources, en in dat geval worden servers gekozen die het mogelijk maken om brede VM's zo dicht mogelijk te plaatsen.<\/p>\n

Grootte van de enkele falldomein.<\/b> <\/p>\n

De keuze van de servergrootte wordt ook gemaakt vanuit het principe van het minimaliseren van de enkele falldomein. Bijvoorbeeld bij de keuze tussen:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nBij gelijkblijvende omstandigheden moet de tweede optie worden gekozen, omdat bij uitval van \u00e9\u00e9n server (of onderhoud) niet 33% van de clusterresources verloren gaat, maar 17%. Evenzo wordt het aantal VM's en IS waarop de storing impact heeft, gehalveerd.<\/p>\n

Berekening van traditionele opslag op basis van prestaties<\/b><\/p>\n

\"Ontwerp
\n
\nTraditionele opslag wordt altijd berekend op basis van het slechtste scenario, waarbij de invloed van interne cache en optimalisatie van bewerkingen worden uitgesloten.
\nAls basisindicatoren voor prestaties nemen we de mechanische IOPS-prestaties van de schijf:
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

Daarna wordt het aantal schijven in de schijfpool berekend volgens de volgende formule: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. Waarbij:
\n \u2014 TotalIOPS<\/i> \u2013 de totale vereiste prestatie in IOPS van de schijfpool
\n \u2014 RW<\/i> \u2013 het percentage van leesopdrachten
\n \u2014 RAIDpen<\/i> \u2013 RAID-straf voor het gekozen RAID-niveau<\/p>\n

Hier wordt meer informatie over RAID-apparatuur en RAID-penalties gegeven \u2014 Prestaties van opslag. Deel \u00e9\u00e9n.<\/a><\/noindex> en Prestaties van opslag. Deel twee.<\/a><\/noindex> en Prestaties van opslag. Deel drie<\/a><\/noindex><\/p>\n

Op basis van het aantal berekende schijven worden mogelijke opties berekend die voldoen aan de capaciteitsvereisten, inclusief opties met meerdere niveaus van opslag.
\nDe berekening van systemen met SSD als niveau van opslag wordt apart behandeld.
\nKenmerken van de berekening van systemen met Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 een algemene term voor alle merkgebonden technologie\u00ebn die flash-geheugen als tweede niveau-cache gebruiken. Bij het gebruik van flash-cache wordt de opslag gewoonlijk berekend om te voldoen aan de constante belasting van magnetische schijven, terwijl de pieken door de cache worden verwerkt.
\nHet is belangrijk om het profiel van de belasting en de mate van localisatie van de aanvragen naar de opslagvolumes te begrijpen. Flash-cache is een technologie voor zwaar gelokaliseerde aanvragen, en is praktisch niet toepasbaar voor gelijkmatig belaste volumes (zoals bij analysesystemen). <\/p>\n

Berekening van hybride systemen low-end \/ mid-range<\/b><\/p>\n

Hybride systemen van lage en middelgrote klasse gebruiken meerlagige opslag met gegevensverschuiving tussen niveaus volgens een schema. Daarbij heeft de blokgrootte van de meervoudige opslag bij de beste modellen een grootte van 256 MB. Deze kenmerken maken het onmogelijk om de technologie voor meervoudige opslag als prestatieverhoging te beschouwen, zoals door velen ten onrechte wordt aangenomen. Meerlagige opslag in systemen van lage en middelgrote klasse is een technologie voor het optimaliseren van opslagkosten voor systemen met een uitdrukkelijke ongelijkheid in belasting.<\/p>\n

Voor gelaagde opslag wordt in de eerste plaats de prestatie op het bovenste niveau berekend, terwijl het onderste niveau van opslag slechts wordt beschouwd als een aanvulling voor het ontbrekende opslagcapaciteit. Voor een hybride gelaagd systeem is het gebruik van flash-cache technologie voor de gelaagde pool essentieel om de prestatieverlies van plotseling opwarmende gegevens op het onderste niveau te compenseren.<\/p>\n

Gebruik van SSD in een gelaagde schijfpool<\/b><\/p>\n

\"Ontwerp
\n
\nHet gebruik van SSD in een gelaagde schijfpool varieert, afhankelijk van de implementatie van de flash-cache-algoritmen door de betreffende fabrikant.
\nDe algemene praktijk van het opslagsbeleid voor een schijfpool met SSD-niveau is SSD first.
\nAlleen-lezen Flash-cache.<\/i> Voor een alleen-lezen flash-cache verschijnt het opslagniveau op SSD bij aanzienlijke lokalisatie van schrijfoperaties, ongeacht de cache.
\nLees\/Schrijf Flash-cache.<\/i> In het geval van een schrijfflash-cache wordt eerst het maximale cachevolume ingesteld, en het opslagniveau op SSD verschijnt pas wanneer de cachecapaciteit onvoldoende is voor het verwerken van de gehele gelokaliseerde belasting.
\nDe prestatie van SSD en cache wordt telkens berekend op basis van de aanbevelingen van de fabrikant, maar altijd voor het slechtste scenario.
\n
Bron: 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\udd47Ontwerp van een gevirtualiseerd datacenter | ProHoster","description":"Inleiding Informatie systeem met betrekking tot.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}