Introduzione
Un sistema informativo dal punto di vista dell'utente è ben definito in GOST RV 51987 - "un sistema automatizzato, il cui risultato è la presentazione di informazioni di output per un utilizzo successivo". Se consideriamo la struttura interna, in sostanza qualsiasi IS è un sistema di algoritmi interconnessi implementati nel codice. Nel senso ampio della tesi di Turing-Church, un algoritmo (o IS) trasforma un insieme di dati di input in un insieme di dati di output.
Si potrebbe addirittura dire che la trasformazione dei dati di input è il senso dell'esistenza di un sistema informativo. Di conseguenza, il valore dell'IS e dell'intero complesso IS è determinato attraverso il valore dei dati di input e di output.
Sulla base di ciò, la progettazione deve partire ed essere data-driven, adattando architettura e metodi alla struttura e al significato dei dati.
Dati memorizzati
Una fase fondamentale nella preparazione alla progettazione è ottenere le caratteristiche di tutti i set di dati pianificati per l'elaborazione e l'archiviazione. Queste caratteristiche includono:
- Volume di dati;
— informazioni sul ciclo di vita dei dati (crescita di nuovi dati, durata di vita, elaborazione di dati obsoleti);
— Classificazione dei dati dal punto di vista impatto sul core business dell'azienda (la triade riservatezza, integrità, disponibilità) insieme agli indicatori finanziari (ad esempio, il costo della perdita di dati nell'ultima ora);
— Geografia del trattamento dei dati (ubicazione fisica dei sistemi di trattamento);
— Requisiti normativi per ciascuna classe di dati (ad esempio, legge federale 152, PCI DSS).
Sistemi di informazione
I dati non vengono solo archiviati, ma anche elaborati (trasformati) dai sistemi informativi. Il passo successivo dopo aver ottenuto le caratteristiche dei dati è l'inventario più completo dei sistemi informativi, delle loro caratteristiche architettoniche, delle interdipendenze e dei requisiti infrastrutturali in unità convenzionali per quattro tipi di risorse:
— potenza di calcolo del processore;
— Quantità di RAM;
— requisiti relativi al volume e alle prestazioni del sistema di archiviazione dei dati;
— Requisiti per la rete di trasmissione dati (canali esterni, canali tra componenti IS).
In questo caso, devono essere presenti requisiti per ciascun servizio/microservizio come parte dell'IS.
Separatamente, è necessario notare che, per una corretta progettazione, è obbligatoria la disponibilità di dati sull'impatto dell'IS sul core business dell'azienda sotto forma di costo dei tempi di inattività dell'IS (rubli all'ora).
Modello di minaccia
Deve esistere un modello formale delle minacce da cui si prevede di proteggere i dati/servizi. Inoltre, il modello di minaccia comprende non solo aspetti di riservatezza, ma anche di integrità e disponibilità. Quelli. Per esempio:
— Guasto del server fisico;
— Guasto dell'interruttore superiore del rack;
— Interruzione del canale di comunicazione ottica tra data center;
— Guasto dell'intero sistema di stoccaggio operativo.
In alcuni casi i modelli di minaccia vengono scritti non solo per componenti dell'infrastruttura, ma anche per specifici sistemi informativi o loro componenti, come ad esempio un guasto del DBMS con distruzione logica della struttura dei dati.
Tutte le decisioni prese all'interno del progetto per proteggersi da una minaccia non descritta non sono necessarie.
Requisiti normativi
Se i dati trattati sono soggetti a norme speciali stabilite dalle autorità di regolamentazione, sono necessarie informazioni sui set di dati e sulle regole di elaborazione/archiviazione.
Obiettivi RPO/RTO
La progettazione di qualsiasi tipo di protezione richiede la disponibilità di indicatori della perdita di dati target e del tempo di ripristino del servizio target per ciascuna delle minacce descritte.
Idealmente, RPO e RTO dovrebbero avere costi associati di perdita di dati e tempi di inattività per unità di tempo.
Divisione in pool di risorse
Dopo aver raccolto tutte le informazioni di input iniziali, il primo passo è raggruppare i set di dati e gli IP in pool in base ai modelli di minaccia e ai requisiti normativi. Il tipo di divisione dei vari pool viene determinato: a livello di programmazione a livello di software di sistema o fisicamente.
Esempi:
— Il circuito di trattamento dei dati personali è completamente separato fisicamente dagli altri sistemi;
— I backup vengono archiviati su un sistema di archiviazione separato.
In questo caso i pool possono essere non completamente indipendenti, ad esempio vengono definiti due pool di risorse di calcolo (potenza del processore + RAM), che utilizzano un unico pool di archiviazione dati e un unico pool di risorse di trasmissione dati.
Potenza di calcolo
In sintesi, i requisiti di potenza di elaborazione di un data center virtualizzato sono misurati in termini di numero di processori virtuali (vCPU) e del loro rapporto di consolidamento su processori fisici (pCPU). In questo caso particolare, 1 pCPU = 1 core del processore fisico (escluso Hyper-Threading). Il numero di vCPU viene sommato in tutti i pool di risorse definiti (ognuno dei quali può avere il proprio fattore di consolidamento).
Il coefficiente di consolidamento per i sistemi caricati è ottenuto empiricamente, sulla base dell'infrastruttura esistente, oppure attraverso installazioni pilota e prove di carico. Per i sistemi senza carico viene utilizzata la “migliore pratica”. Nello specifico, VMware cita il rapporto medio pari a 8:1.
Memoria operativa
Il fabbisogno totale di RAM si ottiene tramite semplice somma. Non è consigliabile utilizzare l'abbonamento eccessivo alla RAM.
Risorse di archiviazione
I requisiti di archiviazione si ottengono semplicemente sommando tutti i pool in base alla capacità e alle prestazioni.
I requisiti prestazionali sono espressi in IOPS combinati con un rapporto medio di lettura/scrittura e, se necessario, una latenza massima di risposta.
I requisiti di qualità del servizio (QoS) per pool o sistemi specifici devono essere specificati separatamente.
Risorse della rete dati
I requisiti della rete dati si ottengono semplicemente sommando tutti i pool di larghezza di banda.
I requisiti di qualità del servizio (QoS) e di latenza (RTT) per pool o sistemi specifici devono essere specificati separatamente.
Nell'ambito dei requisiti per le risorse della rete dati vengono indicati anche i requisiti di isolamento e/o crittografia del traffico di rete e i meccanismi preferenziali (802.1q, IPSec, ecc.).
Selezione dell'architettura
Questa guida non discute alcuna scelta diversa dall'architettura x86 e dalla virtualizzazione del server al 100%. Pertanto, la scelta dell'architettura del sottosistema di elaborazione dipende dalla scelta della piattaforma di virtualizzazione del server, dal fattore di forma del server e dai requisiti generali di configurazione del server.
Il punto chiave della scelta è la certezza di utilizzare un approccio classico con separazione delle funzioni di elaborazione, archiviazione e trasmissione dei dati oppure uno convergente.
architettura classica prevede l'uso di sottosistemi esterni intelligenti per l'archiviazione e la trasmissione dei dati, mentre i server contribuiscono solo con potenza di elaborazione e RAM al pool comune di risorse fisiche. In casi estremi, i server diventano completamente anonimi, non avendo solo i propri dischi, ma nemmeno un identificatore di sistema. In questo caso, il sistema operativo o l'hypervisor viene caricato dal supporto flash integrato o da un sistema di archiviazione dati esterno (avvio da SAN).
Nell'ambito dell'architettura classica, la scelta tra lame e cremagliere viene effettuata principalmente in base ai seguenti principi:
— Conveniente (in media, i server montati su rack sono più economici);
— densità computazionale (maggiore per le pale);
— Consumo energetico e dissipazione del calore (le pale hanno un'unità specifica per unità più elevata);
— scalabilità e controllabilità (le pale richiedono generalmente uno sforzo minore per le installazioni di grandi dimensioni);
- Utilizzo di schede di espansione (scelta molto limitata per i blade).
Architettura convergente (conosciuto anche come iperconvergente) comporta la combinazione delle funzioni di elaborazione e archiviazione dei dati, il che porta all'utilizzo di dischi server locali e, di conseguenza, all'abbandono del classico fattore di forma blade. Per i sistemi convergenti vengono utilizzati server rack o sistemi cluster, combinando più server blade e dischi locali in un unico caso.
CPU/memoria
Per calcolare correttamente la configurazione, è necessario comprendere il tipo di carico per l'ambiente o ciascuno dei cluster indipendenti.
Vincolato alla CPU – un ambiente limitato nelle prestazioni dalla potenza del processore. L'aggiunta di RAM non cambierà nulla in termini di prestazioni (numero di VM per server).
Legato alla memoria – ambiente limitato dalla RAM. Più RAM sul server consente di eseguire più VM sul server.
GB / MHz (GB / pCPU) – il rapporto medio tra consumo di RAM e potenza del processore da parte di questo particolare carico. Può essere utilizzato per calcolare la quantità di memoria richiesta per una determinata prestazione e viceversa.
Calcolo della configurazione del server
Innanzitutto è necessario determinare tutti i tipi di carico e decidere se combinare o dividere diversi pool di elaborazione in cluster diversi.
Successivamente, per ciascuno dei cluster definiti, viene determinato il rapporto GB/MHz con un carico noto in anticipo. Se il carico non è noto in anticipo, ma si ha una conoscenza approssimativa del livello di utilizzo della potenza del processore, è possibile utilizzare i rapporti vCPU:pCPU standard per convertire i requisiti del pool in requisiti fisici.
Per ciascun cluster, dividere la somma dei requisiti del pool vCPU per il coefficiente:
vCPUsum / vCPU:pCPU = pCPUsum – numero richiesto di unità fisiche. nuclei
pCPUsum / 1.25 = pCPUht – numero di core adattato per Hyper-Threading
Supponiamo che sia necessario calcolare un cluster con 190 core / 3.5 TB di RAM. Allo stesso tempo, accettiamo un carico target del 50% della potenza del processore e del 75% della RAM.
CPU
190
Utilizzo CPU
50%
Mem
3500
Utilità Mem
75%
presa di corrente
Nucleo
serv./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 più vicino (=ROUNDUP(A1;0)).
Dalla tabella risulta evidente che diverse configurazioni di server sono bilanciate per gli indicatori target:
— 26 server 2*6c / 192 GB
— 19 server 2*10c / 256 GB
— 10 server 2*18c / 512 GB
La scelta di queste configurazioni deve poi essere fatta in base a fattori aggiuntivi, come pacchetto termico e raffreddamento disponibile, server già utilizzati o costo.
Caratteristiche della scelta di una configurazione del server
VM ampie. Se è necessario ospitare VM estese (paragonabili a 1 nodo NUMA o più), si consiglia, se possibile, di selezionare un server con una configurazione che consenta a tali VM di rimanere all'interno del nodo NUMA. Con un numero elevato di VM ampie, esiste il pericolo di frammentazione delle risorse del cluster e, in questo caso, vengono selezionati server che consentano di posizionare le VM ampie il più densamente possibile.
Dimensione del dominio con errore singolo.
Anche la scelta della dimensione del server si basa sul principio di minimizzare il singolo dominio di guasto. Ad esempio, quando si sceglie tra:
— 3x4*10c / 512 GB
— 6x2*10c / 256 GB
A parità di condizioni, è necessario scegliere la seconda opzione, poiché quando un server si guasta (o viene sottoposto a manutenzione), non viene perso il 33% delle risorse del cluster, ma il 17%. Allo stesso modo, il numero di VM e IS colpiti dall’incidente viene dimezzato.
Calcolo dei sistemi di storage classici in base alle prestazioni
I sistemi di storage classici vengono sempre calcolati utilizzando lo scenario peggiore, escludendo l'influenza della cache operativa e l'ottimizzazione delle operazioni.
Come indicatori di prestazione di base, prendiamo le prestazioni meccaniche dal disco (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Successivamente, il numero di dischi nel lotto dischi viene calcolato utilizzando la seguente formula: = TotalIOPS * (RW + (1 –RW) * RAIDPen) / IOPSdisco. Dove:
- IOPS totali – prestazioni totali richieste in IOPS dal lotto dischi
- RW – percentuale di operazioni di lettura
- Penna RAID – Penalità RAID per il livello RAID selezionato
Maggiori informazioni sul RAID del dispositivo e sulla penalità RAID qui - и и
In base al numero risultante di dischi, vengono calcolate le possibili opzioni che soddisfano i requisiti di capacità di archiviazione, comprese le opzioni con archiviazione multilivello.
Il calcolo dei sistemi che utilizzano SSD come livello di archiviazione viene considerato separatamente.
Caratteristiche dei sistemi di calcolo con Flash Cache
Cache flash – un nome comune per tutte le tecnologie proprietarie per l'utilizzo della memoria flash come cache di secondo livello. Quando si utilizza una cache flash, il sistema di archiviazione viene solitamente calcolato per fornire un carico costante dai dischi magnetici, mentre il picco è servito dalla cache.
In questo caso è necessario comprendere il profilo di carico e il grado di localizzazione dell'accesso ai blocchi di volumi di stoccaggio. La cache flash è una tecnologia per carichi di lavoro con query altamente localizzate ed è praticamente inapplicabile per volumi caricati in modo uniforme (come per i sistemi di analisi).
Calcolo dei sistemi ibridi di fascia bassa/media
I sistemi ibridi delle classi medio-basse utilizzano l'archiviazione multilivello con i dati che si spostano tra i livelli secondo una pianificazione. Allo stesso tempo, la dimensione del blocco di archiviazione multilivello per i migliori modelli è di 256 MB. Queste caratteristiche non ci consentono di considerare la tecnologia di storage a più livelli una tecnologia per aumentare la produttività, come molte persone credono erroneamente. Lo stoccaggio multilivello nei sistemi di classe bassa e media è una tecnologia per ottimizzare i costi di stoccaggio per sistemi con pronunciate irregolarità di carico.
Per l'archiviazione a più livelli, le prestazioni del livello superiore vengono calcolate per prime, mentre si ritiene che il livello di archiviazione inferiore contribuisca solo alla capacità di archiviazione mancante. Per un sistema multilivello ibrido, è obbligatorio utilizzare la tecnologia flash cache per il pool multilivello per compensare il calo delle prestazioni dovuto a dati improvvisamente riscaldati dal livello inferiore.
Utilizzo di un SSD in un pool di dischi a livelli
L'utilizzo delle unità SSD in un pool di dischi multilivello presenta variazioni, a seconda dell'implementazione specifica degli algoritmi di flash cache da parte di un determinato produttore.
La pratica generale della politica di archiviazione per un lotto di dischi con un livello SSD è innanzitutto SSD.
Cache Flash di sola lettura. Per una cache flash di sola lettura, il livello di archiviazione SSD viene visualizzato quando le scritture sono altamente localizzate, indipendentemente dalla cache.
Lettura/scrittura della cache Flash. Nel caso della cache flash, la dimensione della cache di scrittura viene prima impostata sulla dimensione massima della cache e il livello di archiviazione SSD viene visualizzato solo quando la dimensione della cache non è sufficiente per gestire l'intero carico di lavoro localizzato.
I calcoli delle prestazioni dell'SSD e della cache vengono effettuati ogni volta in base alle raccomandazioni del produttore, ma sempre per lo scenario peggiore.
Fonte: habr.com