Introduzione
Il sistema informativo, dal punto di vista dell'utente, è ben definito nella norma GOST RV 51987 come "sistema automatizzato, il cui risultato del funzionamento è la presentazione di informazioni in uscita per un utilizzo successivo". Se consideriamo la struttura interna, sostanzialmente ogni SI è 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.
Si può 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 è determinato dal valore dei dati in ingresso e in uscita.
In base a ciò, la progettazione dovrebbe partire e prendere come base i dati, adattando l'architettura e i metodi alla struttura e all'importanza dei dati.
Dati immagazzinati
Un passo fondamentale nella preparazione alla progettazione è la raccolta delle caratteristiche di tutti i set di dati previsti per l'elaborazione e la conservazione. Queste caratteristiche includono:
— Volume dei dati;
— Informazioni sul ciclo di vita dei dati (incremento dei nuovi dati, durata della vita, elaborazione dei dati obsoleti);
— Classificazione dei dati in termini di impatto sul business principale dell'azienda (sulla triade riservatezza, integrità, disponibilità) insieme agli indicatori finanziari (ad es. costo della perdita di dati nell'ultima ora);
— Geografia dell'elaborazione dei dati (posizione fisica dei sistemi di elaborazione);
— Requisiti normativi per ciascuna classe di dati (ad es. FZ-152, PCI DSS).
Sistemi informativi
I dati non solo vengono conservati, ma anche elaborati (trasformati) dai sistemi informativi. Il passo successivo dopo aver ottenuto le caratteristiche dei dati è un'inventarizzazione il più completa possibile dei sistemi informativi, delle loro peculiarità architettoniche, interdipendenze e requisiti infrastrutturali in unità condizionali per quattro tipi di risorse:
— Potenza di calcolo del processore;
— Volume della memoria RAM;
— Requisiti per il volume e le prestazioni del sistema di storage dati;
— Requisiti per la rete di trasmissione dei dati (canali esterni, canali tra componenti del SI).
I requisiti devono essere specifici per ogni servizio/microservizio all'interno del sistema informativo.
È importante sottolineare l'obbligatorietà di avere dati sull'impatto del sistema informativo sul principale business dell'azienda, espressi come costo di inattività del sistema informativo (in rubli all'ora).
Modello di minacce
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à e disponibilità. Ad esempio:
— Guasto del server fisico;
— Guasto dello switch top-of-the-rack;
— Interruzione del canale ottico di comunicazione tra i data center;
— Guasto completo del sistema di storage operativo.
In 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.
Tutte le decisioni nel progetto di protezione contro una minaccia non descritta sono superflue.
Requisiti dei regolatori
Se i dati trattati rientrano in regole speciali stabilite dai regolatori, è obbligatorio avere informazioni sui set di dati e sulle regole di trattamento/archiviazione.
Obiettivi RPO/RTO
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.
Idealmente, RPO e RTO dovrebbero avere costi associati alla perdita di dati e all'inattività per unità di tempo.
Separazione in pool di risorse
Dopo aver raccolto tutte le informazioni preliminari, il primo passo è 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.
Esempi:
— Il perimetro che gestisce i dati personali è completamente fisicamente separato dagli altri sistemi;
— I backup sono memorizzati su un sistema di storage separato.
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.
Potenza della CPU
Le 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ò avere il proprio fattore di consolidamento).
Il 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.
Memoria RAM
La richiesta totale di memoria RAM si ottiene mediante una semplice somma. L'uso della sovrascrittura della RAM non è raccomandato.
Risorse di archiviazione
I requisiti per le risorse di archiviazione si ottengono tramite una semplice somma di tutti i pool in base al volume e alla performance.
I requisiti di prestazione sono espressi in IOPS, in combinazione con il rapporto medio di lettura/scrittura e, se necessario, con la latenza massima.
Devono essere specificati separatamente i requisiti per la Quality of Service (QoS) per specifici pool o sistemi.
Risorse di rete
I requisiti per la rete si ottengono attraverso una semplice somma di tutti i pool di banda.
Devono essere specificati separatamente i requisiti per la Quality of Service (QoS) e le latenze (RTT) per specifici pool o sistemi.
All'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.).
Scelta dell'architettura
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.
Un aspetto chiave della scelta è la chiarezza nell'uso dell'approccio classico con separazione delle funzioni di elaborazione, archiviazione e trasmissione dei dati rispetto a un approccio convergente.
Architettura classica 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).
Nell'architettura classica, la scelta tra blade e rack è effettuata principalmente secondo i seguenti principi:
— Efficienza economica (in media, i server rack sono più economici);
— Densità computazionale (le blade sono superiori);
— Consumo energetico e dissipazione del calore (le blade hanno un'unità più alta per unità);
— Scalabilità e gestione (le blade richiedono in generale meno sforzo per grandi installazioni);
— Utilizzo di schede di espansione (per le blade, la scelta è molto limitata).
Architettura convergente (conosciuta anche come iperconvergente) 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ù server blade e dischi locali.
CPU / Memoria
Per una corretta configurazione, è necessario comprendere il tipo di carico per l'ambiente o per ciascun cluster indipendente.
CPU bound – un ambiente limitato dalla potenza di elaborazione della CPU. L'aggiunta di memoria RAM non cambierà nulla in termini di prestazioni (numero di VM sul server).
Memory bound – un ambiente limitato dalla memoria RAM. Maggiore quantità di RAM sul server consente di avviare un numero maggiore di VM sul server.
GB / MHz (GB / pCPU) – il rapporto medio di consumo di memoria RAM e potenza di elaborazione per questo specifico carico. Può essere utilizzato per calcolare il volume di memoria necessario a una data prestazione e viceversa.
Calcolo della configurazione del server
Inizialmente, è necessario definire tutti i tipi di carico e prendere una decisione sulla combinazione o separazione dei vari pool di calcolo tra diversi cluster.
Successivamente, per ciascuno dei cluster definiti, si determina il rapporto GB / MHz in base al carico previsto. Se il carico non è noto in anticipo, ma si ha un'idea approssimativa del livello di utilizzo della potenza di elaborazione, è possibile utilizzare coefficienti standard vCPU:pCPU per convertire le esigenze dei pool in fisico.
Per ogni cluster, sommiamo le esigenze dei pool vCPU e dividiamo per il coefficiente:
vCPUsomma / vCPU:pCPU = pCPUsomma – numero richiesto di core fisici
pCPUsomma / 1.25 = pCPUht – numero di core corretti per l'Hyper-Threading
Supponiamo 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.
pCPU
190
CPU util
50%
Mem
3500
Mem util
75%
Socket
Core
Srv / CPU
Srv Mem
Srv / Mem
2
6
25,3
128
36,5
2
8
19,0
192
24,3
2
10
15,2
256
18,2
2
14
10,9
384
12,2
2
18
8,4
512
9,1
In questo caso, utilizziamo sempre l'arrotondamento all'intero superiore (=ROUNDUP(A1;0)).
Dalla tabella risulta chiaro che diverse configurazioni di server sono bilanciate rispetto agli obiettivi target:
— 26 server 2*6c / 192 GB
— 19 server 2*10c / 256 GB
— 10 server 2*18c / 512 GB
La scelta tra queste configurazioni deve essere effettuata considerando ulteriori fattori, come il pacchetto termico e il raffreddamento disponibile, i server già in uso o i costi.
Caratteristiche della scelta della configurazione del server
VM larghe. In caso di necessità di collocare VM ampie (comparabili a 1 nodo NUMA o più), è 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'è il rischio di frammentazione delle risorse del cluster, e in questo caso si scelgono server che consentano di collocare le VM ampie il più densamente possibile.
Dimensione del dominio di guasto singolo.
La scelta della dimensione del server è effettuata anche seguendo il principio di minimizzazione del dominio di guasto singolo. Ad esempio, nella scelta tra:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
A parità di altre condizioni, è necessario scegliere la seconda opzione, poiché 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à.
Calcolo delle prestazioni delle SAN classiche
Le 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.
Come indicatori di base delle prestazioni consideriamo le prestazioni meccaniche del disco (IOPSdisk):
— 7.2k – 75 IOPS
— 10k – 125 IOPS
— 15k – 175 IOPS
Di seguito, il numero di dischi nel pool di archiviazione viene calcolato utilizzando la seguente formula: = TotalIOPS * ( RW + (1 – RW) * RAIDPen) / IOPSdisk. Dove:
— TotalIOPS – prestazioni totali richieste in IOPS dal pool di archiviazione
— RW – percentuale di operazioni di lettura
— RAIDpen – penalità RAID per il livello RAID selezionato
Maggiori informazioni sui dispositivi RAID e sulla penalità RAID sono disponibili qui — e e
Sulla base del numero di dischi ottenuto, vengono calcolate le possibili configurazioni che soddisfano i requisiti di capacità di archiviazione, comprese quelle con archiviazione multistrato.
Il calcolo dei sistemi che utilizzano SSD come livello di archiviazione viene considerato separatamente.
Caratteristiche del calcolo dei sistemi con Flash Cache
Flash Cache – 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 è gestito dalla cache.
In questo caso è necessario comprendere il profilo del carico e il grado di localizzazione delle richieste ai blocchi dei volumi di storage. La flash cache è una tecnologia per carichi con alta localizzazione delle richieste, e praticamente non è applicabile a volumi uniformemente caricati (come ad esempio nei sistemi di analisi).
Calcolo dei sistemi ibridi low-end / mid-range
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 è 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 è una tecnologia di ottimizzazione dei costi di storage per sistemi con un carico di lavoro marcato e irregolare.
Per la multistruttura di archiviazione, si calcola prima di tutto le prestazioni del livello superiore, mentre il livello inferiore di archiviazione è considerato solo per fornire la capacità di archiviazione mancante. Per un sistema ibrido multistrato è 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.
Utilizzo di SSD nel pool di archiviazione multistrato
L'utilizzo di SSD nel pool di archiviazione multistrato presenta variazioni a seconda delle caratteristiche dell'implementazione degli algoritmi di cache flash di questo fornitore.
Pratica generale della politica di archiviazione per un pool di archiviazione con livello SSD — SSD first.
Cache Flash in sola lettura. 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.
Cache Flash Leggi / Scrivi. 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.
La valutazione delle prestazioni di SSD e cache viene effettuata ogni volta secondo le raccomandazioni del produttore, ma sempre per il peggiore dei casi.
Fonte: habr.com
