{"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\/it\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Design del data center virtualizzato","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

Il sistema informativo, dal punto di vista dell'utente, \u00e8 ben definito nella norma GOST RV 51987 come \"sistema automatizzato, il cui risultato del funzionamento \u00e8 la presentazione di informazioni in uscita per un utilizzo successivo\". Se consideriamo la struttura interna, sostanzialmente ogni SI \u00e8 un sistema di algoritmi interconnessi realizzati nel codice. In una accezione ampia della tesi di Turing-Church, un algoritmo (e quindi un SI) realizza la trasformazione di un insieme di dati in ingresso in un insieme di dati in uscita.
\nSi pu\u00f2 persino affermare che nel trasformare i dati in ingresso risiede il senso dell'esistenza di un sistema informativo. Di conseguenza, il valore del SI e dell'intero complesso di SI \u00e8 determinato dal valore dei dati in ingresso e in uscita.
\nIn base a ci\u00f2, la progettazione dovrebbe partire e prendere come base i dati, adattando l'architettura e i metodi alla struttura e all'importanza dei dati.<\/p>\n

Dati immagazzinati<\/b>
\nUn passo fondamentale nella preparazione alla progettazione \u00e8 la raccolta delle caratteristiche di tutti i set di dati previsti per l'elaborazione e la conservazione. Queste caratteristiche includono:
\n \u2014 Volume dei dati;
\n \u2014 Informazioni sul ciclo di vita dei dati (incremento dei nuovi dati, durata della vita, elaborazione dei dati obsoleti);
\n \u2014 Classificazione dei dati in termini di impatto sul business principale dell'azienda (sulla triade riservatezza, integrit\u00e0, disponibilit\u00e0) insieme agli indicatori finanziari (ad es. costo della perdita di dati nell'ultima ora);
\n \u2014 Geografia dell'elaborazione dei dati (posizione fisica dei sistemi di elaborazione);
\n \u2014 Requisiti normativi per ciascuna classe di dati (ad es. FZ-152, PCI DSS).<\/p>\n

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

Sistemi informativi<\/b><\/p>\n

I dati non solo vengono conservati, ma anche elaborati (trasformati) dai sistemi informativi. Il passo successivo dopo aver ottenuto le caratteristiche dei dati \u00e8 un'inventarizzazione il pi\u00f9 completa possibile dei sistemi informativi, delle loro peculiarit\u00e0 architettoniche, interdipendenze e requisiti infrastrutturali in unit\u00e0 condizionali per quattro tipi di risorse:
\n \u2014 Potenza di calcolo del processore;
\n \u2014 Volume della memoria RAM;
\n \u2014 Requisiti per il volume e le prestazioni del sistema di storage dati;
\n \u2014 Requisiti per la rete di trasmissione dei dati (canali esterni, canali tra componenti del SI).
\nI requisiti devono essere specifici per ogni servizio\/microservizio all'interno del sistema informativo.
\n\u00c8 importante sottolineare l'obbligatoriet\u00e0 di avere dati sull'impatto del sistema informativo sul principale business dell'azienda, espressi come costo di inattivit\u00e0 del sistema informativo (in rubli all'ora).<\/p>\n

Modello di minacce<\/b><\/p>\n

Dev'essere necessariamente disponibile un modello formale delle minacce dalle quali si prevede di proteggere i dati\/servizi. Tale modello delle minacce deve includere non solo aspetti di riservatezza, ma anche di integrit\u00e0 e disponibilit\u00e0. Ad esempio:
\n \u2014 Guasto del server fisico;
\n \u2014 Guasto dello switch top-of-the-rack;
\n \u2014 Interruzione del canale ottico di comunicazione tra i data center;
\n \u2014 Guasto completo del sistema di storage operativo.
\nIn alcuni casi, i modelli delle minacce vengono redatti non solo per i componenti infrastrutturali, ma anche per sistemi informativi specifici o i loro componenti, come ad esempio il guasto del DBMS con la distruzione logica della struttura dei dati.
\nTutte le decisioni nel progetto di protezione contro una minaccia non descritta sono superflue.<\/p>\n

Requisiti dei regolatori<\/b><\/p>\n

Se i dati trattati rientrano in regole speciali stabilite dai regolatori, \u00e8 obbligatorio avere informazioni sui set di dati e sulle regole di trattamento\/archiviazione.<\/p>\n

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

La progettazione di qualsiasi tipo di protezione richiede la presenza di indicatori di perdita di dati e tempo di ripristino del servizio per ciascuna delle minacce descritte.
\nIdealmente, RPO e RTO dovrebbero avere costi associati alla perdita di dati e all'inattivit\u00e0 per unit\u00e0 di tempo.<\/p>\n

\"Design
\n
\nSeparazione in pool di risorse<\/b><\/p>\n

Dopo aver raccolto tutte le informazioni preliminari, il primo passo \u00e8 raggruppare i set di dati e i sistemi informativi in pool, in base ai modelli delle minacce e ai requisiti dei regolatori. Si determina il tipo di separazione dei vari pool - software a livello di sistema operativo o fisicamente.
\nEsempi:
\n \u2014 Il perimetro che gestisce i dati personali \u00e8 completamente fisicamente separato dagli altri sistemi;
\n \u2014 I backup sono memorizzati su un sistema di storage separato.<\/p>\n

I pool possono avere una indipendenza incompleta, ad esempio, vengono definiti due pool di risorse computazionali (potenza della CPU + memoria operativa) che utilizzano un unico pool di storage dati e un unico pool di risorse di trasmissione dei dati.<\/p>\n

Potenza della CPU<\/b><\/p>\n

\"Design
\n
\nLe esigenze astratte di potenza di elaborazione di un data center virtualizzato vengono misurate in termini di numero di processori virtuali (vCPU) e nel rapporto di consolidamento di questi su processori fisici (pCPU). In questo caso specifico, 1 pCPU = 1 core fisico della CPU (senza considerare l'Hyper-Threading). Il numero di vCPU si somma su tutti i pool di risorse definiti (ognuno dei quali pu\u00f2 avere il proprio fattore di consolidamento).
\nIl fattore di consolidamento per i sistemi sotto carico si ottiene empiricamente, basandosi sull'infrastruttura esistente o durante l'installazione pilota e i test di carico. Per i sistemi non sotto carico si applicano le \"best practice\". In particolare, VMware indica un fattore medio di 8:1.<\/p>\n

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

La richiesta totale di memoria RAM si ottiene mediante una semplice somma. L'uso della sovrascrittura della RAM non \u00e8 raccomandato.<\/p>\n

Risorse di archiviazione<\/b><\/p>\n

I requisiti per le risorse di archiviazione si ottengono tramite una semplice somma di tutti i pool in base al volume e alla performance.
\nI requisiti di prestazione sono espressi in IOPS, in combinazione con il rapporto medio di lettura\/scrittura e, se necessario, con la latenza massima.
\nDevono essere specificati separatamente i requisiti per la Quality of Service (QoS) per specifici pool o sistemi.<\/p>\n

Risorse di rete<\/b><\/p>\n

I requisiti per la rete si ottengono attraverso una semplice somma di tutti i pool di banda.
\nDevono essere specificati separatamente i requisiti per la Quality of Service (QoS) e le latenze (RTT) per specifici pool o sistemi.
\nAll'interno dei requisiti per le risorse della rete devono essere indicati anche i requisiti per l'isolamento e\/o la crittografia del traffico di rete e i meccanismi preferiti (802.1q, IPSec, ecc.).<\/p>\n

Scelta dell'architettura<\/b><\/p>\n

In questa guida non viene preso in considerazione alcun altro tipo di scelta oltre all'architettura x86 e alla virtualizzazione server 100%. Pertanto, la scelta dell'architettura del sottosistema di calcolo si riduce alla scelta della piattaforma di virtualizzazione server, del fattore di forma dei server e dei requisiti generali per la configurazione dei server.<\/p>\n

Un aspetto chiave della scelta \u00e8 la chiarezza nell'uso dell'approccio classico con separazione delle funzioni di elaborazione, archiviazione e trasmissione dei dati rispetto a un approccio convergente.<\/p>\n

Architettura classica<\/i> implica l'uso di sistemi di archiviazione e trasmissione dati esterni intelligenti, mentre i server contribuiscono al pool generale di risorse fisiche solo con potenza di elaborazione e memoria RAM. In un caso estremo, i server diventano completamente anonimi, senza dischi propri e nemmeno un identificatore di sistema. In questo caso, si utilizza il caricamento del sistema operativo o dell'iperesigente da dispositivi flash integrati o da un sistema di archiviazione dati esterno (boot from SAN).
\nNell'architettura classica, la scelta tra blade e rack \u00e8 effettuata principalmente secondo i seguenti principi:
\n \u2014 Efficienza economica (in media, i server rack sono pi\u00f9 economici);
\n \u2014 Densit\u00e0 computazionale (le blade sono superiori);
\n \u2014 Consumo energetico e dissipazione del calore (le blade hanno un'unit\u00e0 pi\u00f9 alta per unit\u00e0);
\n \u2014 Scalabilit\u00e0 e gestione (le blade richiedono in generale meno sforzo per grandi installazioni);
\n \u2014 Utilizzo di schede di espansione (per le blade, la scelta \u00e8 molto limitata).
\nArchitettura convergente<\/i> (conosciuta anche come iperconvergente<\/i>) implica la combinazione di funzioni di elaborazione e archiviazione dati, il che porta all'uso di dischi locali nei server e, di conseguenza, all'abbandono del fattore di forma delle classiche blade. Per i sistemi convergenti, vengono utilizzati sia server rack che sistemi cluster che integrano in un unico chassis pi\u00f9 server blade e dischi locali.<\/p>\n

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

Per una corretta configurazione, \u00e8 necessario comprendere il tipo di carico per l'ambiente o per ciascun cluster indipendente.
\nCPU bound<\/i> \u2013 un ambiente limitato dalla potenza di elaborazione della CPU. L'aggiunta di memoria RAM non cambier\u00e0 nulla in termini di prestazioni (numero di VM sul server).
\nMemory bound<\/i> \u2013 un ambiente limitato dalla memoria RAM. Maggiore quantit\u00e0 di RAM sul server consente di avviare un numero maggiore di VM sul server.
\nGB \/ MHz (GB \/ pCPU) \u2013 il rapporto medio di consumo di memoria RAM e potenza di elaborazione per questo specifico carico. Pu\u00f2 essere utilizzato per calcolare il volume di memoria necessario a una data prestazione e viceversa. <\/p>\n

Calcolo della configurazione del server<\/b><\/p>\n

\"Design
\n
\nInizialmente, \u00e8 necessario definire tutti i tipi di carico e prendere una decisione sulla combinazione o separazione dei vari pool di calcolo tra diversi cluster.
\nSuccessivamente, per ciascuno dei cluster definiti, si determina il rapporto GB \/ MHz in base al carico previsto. Se il carico non \u00e8 noto in anticipo, ma si ha un'idea approssimativa del livello di utilizzo della potenza di elaborazione, \u00e8 possibile utilizzare coefficienti standard vCPU:pCPU per convertire le esigenze dei pool in fisico. <\/p>\n

Per ogni cluster, sommiamo le esigenze dei pool vCPU e dividiamo per il coefficiente:
\nvCPUsomma \/ vCPU:pCPU = pCPUsomma \u2013 numero richiesto di core fisici
\npCPUsomma \/ 1.25 = pCPUht \u2013 numero di core corretti per l'Hyper-Threading
\nSupponiamo di dover calcolare un cluster con 190 core \/ 3.5TB di RAM. Consideriamo un utilizzo target del 50% della potenza di elaborazione e del 75% della memoria.<\/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 questo caso, utilizziamo sempre l'arrotondamento all'intero superiore (=ROUNDUP(A1;0)).
\nDalla tabella risulta chiaro che diverse configurazioni di server sono bilanciate rispetto agli obiettivi target:
\n \u2014 26 server 2*6c \/ 192 GB
\n \u2014 19 server 2*10c \/ 256 GB
\n \u2014 10 server 2*18c \/ 512 GB <\/p>\n

La scelta tra queste configurazioni deve essere effettuata considerando ulteriori fattori, come il pacchetto termico e il raffreddamento disponibile, i server gi\u00e0 in uso o i costi.<\/p>\n

Caratteristiche della scelta della configurazione del server<\/b><\/p>\n

VM larghe. In caso di necessit\u00e0 di collocare VM ampie (comparabili a 1 nodo NUMA o pi\u00f9), \u00e8 consigliabile scegliere un server con una configurazione che consenta a tali VM di rimanere all'interno del nodo NUMA. Con un numero elevato di VM ampie, c'\u00e8 il rischio di frammentazione delle risorse del cluster, e in questo caso si scelgono server che consentano di collocare le VM ampie il pi\u00f9 densamente possibile.<\/p>\n

Dimensione del dominio di guasto singolo.<\/b> <\/p>\n

La scelta della dimensione del server \u00e8 effettuata anche seguendo il principio di minimizzazione del dominio di guasto singolo. Ad esempio, nella scelta tra:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nA parit\u00e0 di altre condizioni, \u00e8 necessario scegliere la seconda opzione, poich\u00e9 in caso di guasto di un server (o manutenzione) non si perde il 33% delle risorse del cluster, ma solo il 17%. Allo stesso modo, il numero di VM e IS colpite dall'incidente si riduce della met\u00e0.<\/p>\n

Calcolo delle prestazioni delle SAN classiche<\/b><\/p>\n

\"Design
\n
\nLe SAN classiche vengono sempre calcolate considerando il peggiore dei casi (worst case scenario), escludendo l'influenza della cache di sistema e l'ottimizzazione delle operazioni.
\nCome indicatori di base delle prestazioni consideriamo le prestazioni meccaniche del disco (IOPSdisk):
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

Di seguito, il numero di dischi nel pool di archiviazione viene calcolato utilizzando la seguente formula: = TotalIOPS * ( RW + (1 \u2013 RW) * RAIDPen) \/ IOPSdisk<\/i>. Dove:
\n \u2014 TotalIOPS<\/i> \u2013 prestazioni totali richieste in IOPS dal pool di archiviazione
\n \u2014 RW<\/i> \u2013 percentuale di operazioni di lettura
\n \u2014 RAIDpen<\/i> \u2013 penalit\u00e0 RAID per il livello RAID selezionato<\/p>\n

Maggiore informazioni sui dispositivi RAID e sul RAID Penalty sono disponibili qui — Prestazioni delle SAN. Parte prima.<\/a><\/noindex> e Prestazioni delle SAN. Parte seconda.<\/a><\/noindex> e Prestazioni delle SAN. Parte terza.<\/a><\/noindex><\/p>\n

Sulla base del numero di dischi ottenuto, vengono calcolate le possibili configurazioni che soddisfano i requisiti di capacit\u00e0 di archiviazione, comprese quelle con archiviazione multistrato.
\nIl calcolo dei sistemi che utilizzano SSD come livello di archiviazione viene considerato separatamente.
\nCaratteristiche del calcolo dei sistemi con Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 termine generico per tutte le tecnologie proprietarie che utilizzano la memoria flash come cache di secondo livello. Quando si utilizza la cache flash, le SAN vengono generalmente calcolate per garantire il carico stabilito sui dischi magnetici, mentre il picco \u00e8 gestito dalla cache.
\nIn questo caso \u00e8 necessario comprendere il profilo del carico e il grado di localizzazione delle richieste ai blocchi dei volumi di storage. La flash cache \u00e8 una tecnologia per carichi con alta localizzazione delle richieste, e praticamente non \u00e8 applicabile a volumi uniformemente caricati (come ad esempio nei sistemi di analisi). <\/p>\n

Calcolo dei sistemi ibridi low-end \/ mid-range<\/b><\/p>\n

I sistemi ibridi di classe bassa e media utilizzano lo storage multilivello con spostamento dei dati tra i livelli secondo un programma. In questo caso, la dimensione del blocco di storage multilivello dei migliori modelli \u00e8 di 256 MB. Queste caratteristiche non permettono di considerare la tecnologia di storage multilivello come una tecnologia per migliorare le prestazioni, come erroneamente ritengono molti. Lo storage multilivello nei sistemi di classe bassa e media \u00e8 una tecnologia di ottimizzazione dei costi di storage per sistemi con un carico di lavoro marcato e irregolare.<\/p>\n

Per la multistruttura di archiviazione, si calcola prima di tutto le prestazioni del livello superiore, mentre il livello inferiore di archiviazione \u00e8 considerato solo per fornire la capacit\u00e0 di archiviazione mancante. Per un sistema ibrido multistrato \u00e8 sicuramente necessario utilizzare la tecnologia della cache flash per il pool multistrato al fine di compensare il calo di prestazioni per i dati improvvisamente accesi dal livello inferiore.<\/p>\n

Utilizzo di SSD nel pool di archiviazione multistrato<\/b><\/p>\n

\"Design
\n
\nL'utilizzo di SSD nel pool di archiviazione multistrato presenta variazioni a seconda delle caratteristiche dell'implementazione degli algoritmi di cache flash di questo fornitore.
\nPratica generale della politica di archiviazione per un pool di archiviazione con livello SSD \u2014 SSD first.
\nCache Flash in sola lettura.<\/i> Per la cache flash in sola lettura, il livello di archiviazione su SSD emerge con una significativa localizzazione delle operazioni di scrittura, indipendentemente dalla cache.
\nCache Flash Leggi \/ Scrivi.<\/i> Nel caso della cache flash in scrittura, viene prima impostato il volume massimo della cache, e il livello di archiviazione su SSD emerge solo quando le dimensioni della cache non sono sufficienti a gestire l'intero carico localizzato.
\nLa valutazione delle prestazioni di SSD e cache viene effettuata ogni volta secondo le raccomandazioni del produttore, ma sempre per il peggiore dei casi.
\n
Fonte: 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\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 del Data Center virtualizzato | ProHoster","description":"Introduzione Sistema informativo con punto.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}