8 minuti di lettura (1475 parole)
Este post también está disponible en Español
Tutti i business moderni si basano sulla tecnologia. Se c’è un problema con la tecnologia, c’è un impatto negativo sul business. Oggi le aspettative sono che la tecnologia non debba fallire. Come sappiamo, ciò non è possibile e per questo tendiamo a valutare un sistema in termini di availability che possiamo misurare in “numero di nove”. Ad esempio, 5 9’s significa letteralmente che un sistema è disponibile per 99.999 del tempo, il che equivale a 5 minuti di inattività (sia pianificati che non pianificati) all’anno. È chiaro che le dichiarazioni di alcuni fornitori di infrastruttura di avere una disponibilità del 100% non sono realistiche, se ciò fosse vero, non sarebbe necessario implementare architetture di Business Continuity o DR per le nostre applicazioni mission-critical.
Sia la Business Continuity che il DR sono meccanismi di copia di dati da un data center primario a un data center secondario. Essendo una copia, e mentre i dati vengono copiati, questi non possono essere utilizzati nel sito secondario fino al completamento di una serie di operazioni in modo che le applicazioni possano riavviare il servizio. Un’implementazione di questo tipo non è utile se il nostro obiettivo è ottenere una disponibilità continua dei dati, senza alcuna interruzione del servizio.
Per una disponibilità continua di dati e servizi, è necessaria un’architettura di tipo attiva/attiva o Metro in cui i carichi di lavoro possano operare in due data center contemporaneamente.
Esistono diverse soluzioni Metro con marcate differenze tra di loro. L’obiettivo di questo post è differenziare queste soluzioni e, in particolare, evidenziare le caratteristiche uniche della proposta di Dell Technologies PowerStore Metro Node.
Metro 101
Il motivo principale per il quale sempre più data center implementano soluzioni di tipo Metro è per aumentare la disponibilità dei dati e la resilienza dell’ambiente.
Le tecnologie Metro o Active-Active forniscono una disponibilità continua posizionando gli stessi dati in due siti diversi con l’obiettivo di consentire l’accesso simultaneo ai dati su entrambi i siti.
Le soluzioni Metro introducono uno strato attivo-attivo tra i server e lo storage garantendo che i dati rimangano coerenti senza necessità di riconfigurare i server o lo storage. In altre parole, i server sono collegati a un sistema di archiviazione che semplicemente si estende a distanza. Il Metro fa a livello di archiviazione ciò che un cluster fa a livello di server; crea un cluster di storage aumentando così la resilienza dell’ambiente.
Tripla protezione (RPO, RTO e DTO)
Mantenere le applicazioni sempre disponibili è un concetto importante e per la sua realizzazione è necessario considerare tre elementi; RPO, RTO e DTO.
Come sappiamo, per misurare il livello di resilienza agli errori utilizziamo due metriche chiave:
RTO: La prima metrica chiave, Recovery Time Objective, definisce il tempo entro il quale l’accesso ai dati deve essere ripristinato dopo un errore per ridurre al minimo qualsiasi impatto aziendale
RPO: la seconda metrica chiave, Recovery Point Objective, definisce la quantità massima di dati che è tollerabile perdere in caso di fault
Quando si parla di soluzioni per la continuità del servizio, il significato di failover è importante. Definiamo il failover come la serie di operazioni che devono essere eseguite per attivare nuovamente il servizio. Il failover può essere manuale (nella maggior parte dei casi) o utilizzare una serie di script che consentono un certo grado di automazione. In ognuno di questi casi, il suo effetto è una momentanea interruzione del servizio. Oltre a ciò, le procedure di failover richiedono una serie di test prima di poter essere eseguite, test che devono essere effettuati frequentemente nell’ambiente di produzione con tutti i rischi associati al caso. Quanto appena descritto ci porta a definire un terzo elemento che dobbiamo considerare per ottenere una vera continuità di servizio, il DTO.
Il DTO è il Decision Time Objective, in caso di errore, qual è il tempo necessario per prendere la decisione di eseguire il failover. Il DTO e la necessità o meno di eseguire un failover sono le differenze fondamentali tra una soluzione Metro e una soluzione di DR (Disaster Recovery) o BC (Business Continuity). In questi ultimi 2 casi, a seguito di un guasto sul sito primario (produzione), sarà necessario prendere la decisione di ripristinare i servizi sul sito secondario (BC o DR). Questa decisione implica un certo tempo, il tempo necessario per ottenere le autorizzazioni per eseguire il failover, il tempo materiale per eseguirlo (eseguire script, procedure, ecc.). Un DTO = 0 implica che il ripristino è completamente automatico.
In breve, una vera soluzione Metro richiede 3 elementi (tripla protezione); RPO = 0, RTO = 0 e DTO = 0
Dell Technologies PowerStore Metro Node
La soluzione Metro PowerStore Node di Dell Technologies è basata sulla tecnologia VPLEX installata in più di 10.000 cluster, con 260 milioni di ore di funzionamento, con una disponibilità superiore a 6 9 e adottata dal 50% dei clienti Fortune 500 aiutando a mantenere le applicazioni mission-critical sempre disponibili.
True Metro e Pseudo-Metro, differeze architetturali
Se in una soluzione Metro i dati si trovano in entrambe le posizioni ed è possibile accedervi contemporaneamente, è logico chiedersi se in un’implementazione di questo tipo, a seguito di un disastro (perdita di uno dei siti, perdita di connettività tra i siti, malfunzionamento server/storage, ecc.) sarà comunque necessario considerare un certo DTO ed effettuare un failover con effetti negativi sulla continuità del servizio. La risposta è che questo dipenderà dal tipo di Metro. Possiamo distinguere 2 tipi di soluzioni Metro: a) Vero Metro (True Metro) e b) Pseudo Metro.
In un vero Metro (Dell Technologies Metro Node), concetti come sito primario (sito di produzione) e sito secondario (sito di DR o BC) perdono significato. Il Metro Node di Dell Technologies è un’implementazione attiva/attiva in cui i dati vengono distribuiti a livello logico e sono disponibili in modalità di lettura / scrittura simultanea su entrambi i siti senza distinzione tra sito primario o sito secondario. Pertanto, in un vero Metro, se si verifica un guasto in uno dei 2 siti, le operazioni proseguono senza alcuna interruzione del servizio e senza necessità di intervento dell’operatore (No failover, DTO = 0)
Il comportamento è completamente diverso in quello che possiamo chiamare uno pseudo-metro. In questo tipo di implementazione, esiste un meccanismo di copia sincrono tra 2 siti, sito A e sito B, ma la copia di dati sul sito B non può essere acceduta dai i server locali perché è in modalità stand-by. Ci sono tutta una serie di svantaggi nello pseudo-metro che vedremo nel prossimo punto.
Pseudo-Metro o Active/Passive, considerazioni competitive
Nelle implementazioni Pseudo-Metro i volumi di dati sono presenti su entrambi i siti, ma in realtà esiste un sito preferred o primario dove i volumi sono disponibili in modalità di lettura/scrittura, mentre sull’altro sito i volumi sono in stand-by. Questo significa che le scritture che avvengono sul sito secondario non possono essere scritte direttamente dai server locali e devono essere prima trasferite al sito primario via WAN e solo successivamente copiate dallo storage ai volumi non preferred. Risulta chiaro che queste soluzioni di tipo pseudo-metro soffrono di impatti sulle prestazioni dovuti all’aumento del carico sul componente di rete (WAN).
Inoltre, le implementazioni pseudo-metro richiedono una pianificazione adeguata per decidere quale sito sarà il primario (preferred) e quale sarà il secondario.
powerstore metro node – pseudo metro differences (click to enlarge)
È importante ricordare che queste architetture pseudo-metro non possono garantire un RTO = 0 semplicemente perché richiedono un tempo di failover per attivare i volumi del sito secondario. In alcuni casi di implementazioni pseudo-metro il failover può durare fino a 120 secondi, che è il tempo necessario affinché i volumi (LUN) in stand-by transitino alla modalità di scrittura/lettura più il tempo necessario per far intervenire i meccanismi di ALUA per indirizzare le rotte di accesso ed inviare le notifiche iSCSI ai server.
Per concludere
In un ambiente Metro i dati sono disponibili in due data center, il Metro crea un cluster di storage a distanza geografica
Esistono 2 tipi di soluzioni Metro: Vero Metro (True Metro) e Pseudo Metro. In un vero Metro (attivo-attivo) i volumi di dati sono accessibili (in lettura/scrittura) ai server di entrambi i siti. In uno Pseudo Metro (attivo-passivo) solo i volumi del sito primario o preferred possono essere scritti dai server
La necessità di effettuare un failover compromette la continuità del servizio poiché richiede un certo tempo per essere eseguito
In un’implementazione Metro la disponibilità continua dei dati può essere ottenuta solo se vengono rispettati 3 requisiti (tripla protezione): RPO = 0, RTO = 0 e DTO = 0
La disponibilità continua dei dati, implementata con Dell EMC PowerStore Metro Node, va oltre la semplice copia, replica o ridondanza dei dati. Dell EMC PowerStore Metro Node garantisce disponibilità e operatività continua dei dati
Per maggiori informazioni
Dell EMC PowerStore Metro Node Enables Automated Business Continuity (Dell Technologies blog)
PowerStore Metro Node (Solution Brief)
#IWork4Dell
