{"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 \u00absistema automatizzato il cui risultato \u00e8 la presentazione di informazioni in uscita per un uso successivo\u00bb. Se consideriamo la struttura interna, in sostanza qualsiasi SI \u00e8 un sistema di algoritmi interconnessi implementati nel codice. In un senso ampio, secondo il teorema di Turing-Church, un algoritmo (e di conseguenza un SI) esegue la trasformazione di un insieme di dati in ingresso in un insieme di dati in uscita.
\nSi pu\u00f2 dire che il significato dell'esistenza di un sistema informativo risieda proprio nella trasformazione dei dati in ingresso. Di conseguenza, il valore del SI e dell'intero complesso di SI \u00e8 determinato attraverso il valore dei dati in ingresso e in uscita.
\nDa ci\u00f2, la progettazione deve iniziare prendendo come base i dati, adattando l'architettura e i metodi alla struttura e all'importanza dei dati.<\/p>\n

Dati memorizzati<\/b>
\nUna fase chiave nella preparazione alla progettazione \u00e8 l'ottenimento delle caratteristiche di tutti i set di dati previsti per l'elaborazione e la memorizzazione. Queste caratteristiche includono:
\n \u2014 Volume dei dati;
\n \u2014 Informazioni sul ciclo di vita dei dati (incremento dei nuovi dati, durata, gestione dei dati obsoleti);
\n \u2014 Classificazione dei dati dal punto di vista dell'impatto sul business principale dell'azienda (trifoglio riservatezza, integrit\u00e0, disponibilit\u00e0) insieme agli indicatori finanziari (es. costo della perdita di dati nell'ultima ora);
\n \u2014 Geografia del trattamento dei dati (posizione fisica dei sistemi di trattamento);
\n \u2014 Requisiti normativi per ciascuna classe di dati (es. legge federale 152, PCI DSS).<\/p>\n

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

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

I dati non solo vengono memorizzati, ma anche elaborati (trasformati) dai sistemi informativi. Il passaggio successivo dopo aver ottenuto le caratteristiche dei dati \u00e8 un'inventarizzazione quanto pi\u00f9 completa possibile dei sistemi informativi, delle loro caratteristiche architettoniche, delle dipendenze reciproche e dei requisiti infrastrutturali in unit\u00e0 nominali per quattro tipi di risorse:
\n \u2014 Potenza di calcolo del processore;
\n \u2014 Dimensione della memoria RAM;
\n \u2014 Requisiti relativi alla dimensione e alle prestazioni del sistema di archiviazione dati;
\n \u2014 Requisiti per la rete di trasmissione dati (canali esterni, canali tra i componenti dei sistemi informativi).
\nI requisiti devono essere specificati per ogni servizio\/microservizio all'interno del sistema informativo.
\n\u00c8 fondamentale sottolineare che per una progettazione corretta \u00e8 necessario disporre di dati sull'impatto del sistema informativo sul core business dell'azienda, in termini di costo di inattivit\u00e0 del sistema informativo (rubli all'ora).<\/p>\n

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

Deve necessariamente essere presente un modello formale di minacce da cui si intende proteggere dati\/servizi. Questo modello di minacce include non solo aspetti di riservatezza, ma anche di integrit\u00e0 e disponibilit\u00e0. Ad esempio:
\n \u2014 Guasto di un server fisico;
\n \u2014 Guasto di uno switch top-of-the-rack;
\n \u2014 Interruzione del canale ottico di comunicazione tra i data center;
\n \u2014 Guasto completo di uno storage di rete.
\nIn alcuni casi, i modelli di minacce vengono redatti non solo per componenti infrastrutturali, ma anche per sistemi informativi specifici o per i loro componenti, come ad esempio il guasto di un SGBD con distruzione logica della struttura dei dati.
\nTutte le decisioni all'interno del progetto per proteggersi da minacce non descritte sono superflue.<\/p>\n

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

Se i dati trattati rientrano sotto regole speciali stabilite dai regolatori, \u00e8 obbligatoria l'informazione sui set di dati e le regole di elaborazione \/ conservazione.<\/p>\n

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

La progettazione di qualsiasi tipo di protezione richiede la presenza di indicatori di perdita dati target e tempo di ripristino del servizio per ciascuna delle minacce descritte.
\nIdeale sarebbe che RPO e RTO avessero costi associati alla perdita di dati e ai fermi nell'unit\u00e0 di tempo.<\/p>\n

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

Dopo aver raccolto tutte le informazioni iniziali, il primo passo consiste nella raggruppamento dei set di dati e dei sistemi informativi in pool, in base ai modelli di minaccia e ai requisiti dei regolatori. Viene definito il tipo di separazione dei vari pool: a livello software, nel sistema operativo, oppure fisicamente.
\nEsempi:
\n \u2014 Il contorno che gestisce i dati personali \u00e8 completamente isolato fisicamente dagli altri sistemi;
\n \u2014 Le copie di riserva sono conservate su uno storage dedicato separato.<\/p>\n

In questo caso, i pool possono avere una parziale indipendenza, ad esempio, si definiscono due pool di risorse computazionali (potenza della CPU + memoria RAM) che utilizzano un unico pool di storage e un unico pool di risorse di rete.<\/p>\n

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

\"Design
\n
\nLe esigenze astratte di potenza della CPU di un datacenter virtualizzato vengono misurate in termini di numero di processori virtuali (vCPU) e del loro coefficiente di consolidamento sui processori fisici (pCPU). In questo caso specifico, 1 pCPU = 1 core fisico della CPU (senza considerare l'Hyper-Threading). Il numero di vCPU viene sommato su tutti i pool di risorse definiti (ognuno dei quali pu\u00f2 avere il proprio coefficiente di consolidamento).
\nIl coefficiente di consolidamento per sistemi ad alto carico viene ottenuto empiricamente, basandosi sull'infrastruttura esistente, oppure durante l'installazione pilota e i test di carico. Per i sistemi a basso carico si applicano le \u00abbest practice\u00bb. In particolare, VMware indica un coefficiente medio di 8:1.<\/p>\n

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

Il fabbisogno totale di memoria RAM viene calcolato tramite semplice somma. L'uso della sovrascrittura della memoria non \u00e8 raccomandato.<\/p>\n

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

I requisiti delle risorse di archiviazione sono ottenuti sommando semplicemente tutti i pool per volume e prestazioni.
\nI requisiti prestazionali sono espressi in IOPS insieme al rapporto medio di lettura\/scrittura e, se necessario, alla latenza massima.
\nI requisiti per la qualit\u00e0 del servizio (QoS) devono essere specificati separatamente per specifici pool o sistemi.<\/p>\n

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

I requisiti della rete sono ottenuti sommando semplicemente tutti i pool di larghezza di banda.
\nI requisiti di QoS e latenza (RTT) devono essere specificati separatamente per specifici pool o sistemi.
\nNell'ambito dei requisiti per le risorse di rete devono essere indicate anche le necessit\u00e0 di isolamento e\/o crittografia del traffico e i meccanismi preferiti (802.1q, IPSec, ecc.)<\/p>\n

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

In questo documento non viene considerata alcuna scelta diversa dall'architettura x86 e dalla virtualizzazione server al 100%. Pertanto, la scelta dell'architettura del sistema di calcolo si riduce alla scelta della piattaforma di virtualizzazione del 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 certezza nell'applicazione dell'approccio classico con separazione delle funzioni di elaborazione, archiviazione e trasmissione dei dati o convergente.<\/p>\n

Architettura classica<\/i> implica l'uso di sistemi di archiviazione e trasmissione dei dati esterni intelligenti, mentre i server contribuiscono al pool generale delle risorse fisiche solo con potenza di elaborazione e memoria RAM. In alcuni casi, i server diventano completamente anonimi, privi non solo di dischi propri, ma anche di un identificatore di sistema. In questo caso viene utilizzato il boot del sistema operativo o dell'ipervisore 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 basata principalmente sui seguenti principi:
\n \u2014 Efficienza economica (in media, i server rack sono pi\u00f9 economici);
\n \u2014 Densit\u00e0 computazionale (le blade hanno una densit\u00e0 maggiore);
\n \u2014 Consumo energetico e dissipazione di calore (le blade hanno un'efficienza maggiore per unit\u00e0);
\n \u2014 Scalabilit\u00e0 e gestibilit\u00e0 (le blade richiedono in generale meno sforzi per grandi installazioni);
\n \u2014 Uso di schede di espansione (per le blade c'\u00e8 una scelta molto limitata).
\nArchitettura convergente<\/i> (nota anche come iperconvergente<\/i>) prevede la combinazione di funzioni di elaborazione e archiviazione dei dati, portando all'uso di dischi locali nei server e conseguentemente all'abbandono del fattore di forma delle tradizionali blade. Per i sistemi convergenti vengono utilizzati server rack o sistemi cluster che combinano in un'unica scocca pi\u00f9 server blade e dischi locali.<\/p>\n

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

Per un corretto calcolo della configurazione \u00e8 necessario comprendere il tipo di carico per l'ambiente o per ciascuno dei cluster indipendenti.
\nLimitato dalla CPU<\/i> \u2013 ambiente limitato dalla potenza di elaborazione della CPU. Aggiungere memoria RAM non cambia nulla in termini di prestazioni (numero di VM sul server).
\nLimitato dalla memoria<\/i> \u2013 ambiente con RAM limitata. 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 questa specifica carico di lavoro rispetto alla potenza del processore. Pu\u00f2 essere usato per calcolare la quantit\u00e0 necessaria di memoria a una data prestazione e viceversa. <\/p>\n

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

\"Design
\n
\nPer iniziare, \u00e8 necessario determinare tutti i tipi di carico e decidere se unire o separare diversi pool computazionali in vari cluster.
\nSuccessivamente, per ciascuno dei cluster definiti, si determina il rapporto GB \/ MHz in base a un carico noto in anticipo. Se il carico non \u00e8 noto in anticipo, ma si ha un'idea approssimativa del livello di utilizzo della potenza del processore, si possono usare coefficienti standard vCPU:pCPU per convertire i requisiti dei pool in fisici. <\/p>\n

Per ciascun cluster, si divide la somma delle richieste dell'pool vCPU per il coefficiente:
\nvCPUsomma \/ vCPU:pCPU = pCUsomma \u2013 numero richiesto di core fisici
\npCUsomma \/ 1.25 = pCUht \u2013 numero di core corretto per l'Hyper-Threading
\nSupponiamo di dover calcolare un cluster con 190 core \/ 3,5 TB di RAM. Consideriamo un utilizzo target del 50% della potenza di elaborazione e del 75% della memoria operativa.<\/p>\n

pCPU<\/b>
\n190
\nUtilizzo CPU<\/b>
\n50%<\/p>\n

Mem<\/b>
\n3500
\nUtilizzo Mem<\/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 si utilizza sempre l'arrotondamento all'intero superiore pi\u00f9 vicino (=ROUNDUP(A1;0)).
\nDalla tabella \u00e8 evidente che esistono diverse configurazioni di server bilanciate rispetto agli obiettivi di performance:
\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 fatta tenendo conto di ulteriori fattori, come ad esempio il pacchetto termico e il raffreddamento disponibile, i server gi\u00e0 in uso o il costo.<\/p>\n

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

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

Dimensione del dominio di un singolo punto di errore.<\/b> <\/p>\n

La scelta della dimensione del server si basa anche sul principio di minimizzazione del dominio di un singolo punto di errore. Ad esempio, nella scelta tra:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nCon altre condizioni uguali, \u00e8 necessario scegliere la seconda opzione, poich\u00e9, in caso di guasto di un server (o di 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 viene dimezzato.<\/p>\n

Calcolo delle prestazioni della SAN classica<\/b><\/p>\n

\"Design
\n
\nLa SAN classica viene sempre calcolata secondo lo scenario peggiore (worst case scenario), escludendo l'influenza della cache di sistema e l'ottimizzazione delle operazioni.
\nCome indicatori di base delle prestazioni prendiamo la prestazione meccanica dei dischi (IOPSdisk):
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

Successivamente, il numero di dischi nel pool di dischi viene calcolato secondo la seguente formula: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. Dove:
\n \u2014 TotalIOPS<\/i> \u2013 prestazione totale richiesta in IOPS dal pool di dischi
\n \u2014 RW<\/i> \u2013 percentuale di operazioni di lettura
\n \u2014 RAIDpen<\/i> \u2013 penalit\u00e0 RAID per il livello RAID scelto<\/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 — Prestazioni dello storage. Parte prima.<\/a><\/noindex> e Prestazioni dello storage. Parte seconda.<\/a><\/noindex> e Prestazioni dello storage. Parte terza.<\/a><\/noindex><\/p>\n

Sulla base del numero di dischi ottenuti, vengono calcolate le opzioni disponibili che soddisfano i requisiti di capacit\u00e0 di archiviazione, comprese le opzioni con archiviazione multilivello.
\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> \u00e8 il termine generico per tutte le tecnologie proprietarie che utilizzano la memoria flash come cache di secondo livello. Quando si utilizza la flash cache, lo storage viene generalmente calcolato per sostenere il carico stabilito sui dischi magnetici, mentre il picco \u00e8 gestito dalla cache.
\n\u00c8 importante comprendere il profilo del carico e il grado di localizzazione delle richieste ai blocchi dei volumi di archiviazione. La flash cache \u00e8 una tecnologia per carichi con alta localizzazione delle richieste, e praticamente non \u00e8 applicabile per 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 fascia bassa e media utilizzano lo storage multistrato con il movimento dei dati tra i livelli programmato. In questo contesto, la dimensione del blocco di storage multistrato nei migliori modelli \u00e8 di 256 MB. Queste caratteristiche non permettono di considerare la tecnologia dello storage multistrato come una tecnologia per migliorare le prestazioni, come erroneamente pensano in molti. Lo storage multistrato nei sistemi di fascia bassa e media \u00e8 una tecnologia di ottimizzazione dei costi di storage per sistemi con carico di lavoro chiaramente irregolare.<\/p>\n

Per lo storage multistrato, si calcola principalmente la prestazione del livello superiore, mentre il livello inferiore \u00e8 considerato solo come contributo alla capacit\u00e0 di storage mancante. Per un sistema ibrido a multistrato \u00e8 necessario l'uso della tecnologia di cache flash per il pool multistrato al fine di compensare il calo di prestazioni per i dati che si scaldano improvvisamente dal livello inferiore.<\/p>\n

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

\"Design
\n
\nL'uso degli SSD in un pool di dischi a pi\u00f9 livelli varia a seconda delle specificit\u00e0 di implementazione degli algoritmi di cache flash di questo produttore.
\nLa pratica comune della politica di archiviazione per un pool di dischi con SSD \u00e8 SSD first.
\nFlash Cache in sola lettura.<\/i> Per la cache flash in sola lettura, il livello di archiviazione su SSD si attiva quando vi \u00e8 una significativa localizzazione delle operazioni di scrittura al di fuori della cache.
\nFlash Cache in lettura\/scrittura.<\/i> Nel caso della cache flash in scrittura, prima viene impostato il massimo volume di cache, e il livello di archiviazione su SSD si attiva solo quando la dimensione della cache non \u00e8 sufficiente a gestire l'intero carico localizzato.
\nIl calcolo delle prestazioni degli SSD e della cache viene effettuato ogni volta in base alle raccomandazioni del produttore, ma sempre per il worst case.
\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 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 di output per utilizzi successivi\". Se consideriamo la struttura interna, ogni sistema informativo \u00e8, in sostanza, un insieme di algoritmi interconnessi realizzati nel codice. In un'accezione pi\u00f9 ampia, secondo il teorema di Turing-Church, un algoritmo (e quindi un sistema informativo) effettua la trasformazione di un insieme di input.","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 \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","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"},"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}]}}