Replicate il gruppo, non il disco: la coerenza nella replica tra array

La replica tra array sembra la forma più semplice di disaster recovery: l'array copia i vostri dischi su un altro array in un altro datacenter, e dentro i vostri server non cambia nulla. È davvero così semplice, a patto di replicare insieme le cose giuste. Replicate ogni volume per conto suo e potete ritrovarvi con una copia perfetta di ogni disco e un database che si rifiuta di partire.

Una copia di ogni disco non è una copia dell'applicazione

La maggior parte delle applicazioni serie scrive su più di un volume. Un database tiene i file dati su un disco e il log delle transazioni su un altro. Un server di posta separa l'archivio dei messaggi dai suoi log. Una macchina virtuale può avere un disco di sistema e un disco dati che hanno senso solo insieme.

Queste applicazioni dipendono dall'ordine delle scritture. Il database scrive prima il record di log e poi la pagina dati, e in recovery rilegge il log per portare i file dati a un punto coerente. Se la copia del volume di log sul sito remoto è di qualche secondo più vecchia della copia del volume dati, il sito remoto contiene pagine dati che fanno riferimento a record di log che lì non esistono. Il database vede uno stato impossibile. Nel migliore dei casi si riprende con fatica; nel peggiore non si apre.

Quando ogni volume replica in modo indipendente, ogni copia avanza al proprio ritmo, quindi i dischi remoti non sono quasi mai allo stesso istante nel tempo. La risposta è un consistency group: un insieme di volumi che l'array replica come un'unica unità, preservando l'ordine delle scritture su tutti. Su HPE 3PAR è un Remote Copy group. Altri array hanno il proprio nome per la stessa idea. Comunque si chiami, la regola è la stessa: tutto ciò che serve a un'applicazione per partire va in un unico gruppo.

Scegliere cosa entra in un gruppo

Partite dall'applicazione, non dall'elenco dei volumi:

• Elencate ogni volume su cui l'applicazione scrive, compresi quelli facili da dimenticare: il volume che contiene il binary log o l'archivio del write-ahead log, un tablespace temporaneo separato, un disco di configurazione.
• Metteteli tutti in un unico gruppo.
• Tenete le applicazioni non correlate in gruppi separati, così una può essere fatta fallire, testata o messa in pausa senza toccare l'altra.

Poi decidete quanto da vicino la copia debba seguire l'originale.

Quanto vicina deve essere la copia?

Esistono due grandi famiglie di modalità di replica, e la scelta riguarda la fisica tanto quanto le preferenze.

La replica sincrona mantiene la copia aggiornata al costo di un round trip su ogni scrittura, piccolo a distanza metropolitana e misurabile tra paesi. L'asincrona corre alla velocità locale e il ritardo è il vostro recovery point.

Nessuna delle due è giusta in generale. Un sistema transazionale il cui ultimo minuto di ordini ha valore può giustificare la latenza in scrittura; una piattaforma di contenuti che può perdere qualche minuto di modifiche di solito no. La risposta corretta viene dal chiedersi quanto costerebbe all'azienda perdere quell'intervallo, e poi dal misurare se l'applicazione tollera la latenza della modalità più rigorosa.

Tenete la replica fuori dal percorso di produzione

Il traffico di replica compete con l'I/O degli host, se glielo permettete. Dategli porte dedicate sull'array, tenete quelle porte separate da quelle usate dagli host, e assegnate a ogni link di replica un solo partner. Osservate il ritardo di replica, non solo lo stato del link. Un link attivo mentre la copia resta sempre più indietro ogni ora è la modalità di guasto che trasforma un piano di disaster recovery in una sorpresa.

Testate la replica senza romperla

Una replica che non è mai stata avviata è una speranza. La buona notizia è che potete testarla senza interrompere la replica:

1. Fate uno snapshot point-in-time dei volumi secondari del gruppo sull'array remoto. Fate lo snapshot dell'intero gruppo in una volta, così la copia di test è coerente quanto la replica.
2. Presentate gli snapshot a un host di test isolato nel sito remoto. Tenete quell'host fuori dalla rete di produzione, così la copia non può rispondere a traffico reale, inviare e-mail reali o eseguire job pianificati contro sistemi reali.
3. Avviate l'applicazione esattamente come fareste in un disastro, usando il vostro runbook scritto e nient'altro.
4. Verificatela a livello applicativo: il database si apre e supera il proprio controllo di coerenza, i conteggi delle righe e i record più recenti sono dove il recovery point dice che dovrebbero essere, e un login applicativo funziona.
5. Cronometrate, dalla decisione di fare failover alla prima transazione riuscita. Quel numero è il vostro vero recovery time, qualunque cosa dica il piano.
6. Rimuovete gli snapshot e registrate il risultato, compreso tutto ciò che vi ha sorpreso.

Eseguite il test dopo ogni modifica al gruppo, e a cadenza regolare anche quando non è cambiato nulla, perché le applicazioni aggiungono volumi in silenzio.

La replica non è un backup

La replica copia fedelmente le modifiche, e questo include una tabella cancellata, una cifratura da ransomware e un deploy sbagliato. In pochi secondi o minuti l'errore è in entrambi i posti. Una replica vi protegge dalla perdita di un sito; i backup con storico vi proteggono dai vostri stessi dati. Vi servono entrambi, e i backup dovrebbero essere prelevati da un sistema che il lato produzione non può raggiungere.

Come lo facciamo noi

Tra i nostri datacenter di Atene e Amsterdam, i volumi dei clienti possono replicare da array ad array su HPE 3PAR, con i volumi correlati collocati nello stesso Remote Copy group perché restino coerenti tra loro. La modalità di replica è concordata per servizio, la replica corre su porte dedicate, un partner per coppia di porte, sulla nostra interconnessione privata tra i siti, e le repliche dei dati ospitati nell'UE restano dentro la nostra infrastruttura UE. All'interno di ogni sito gli array sono in federation, quindi i volumi si spostano anche tra array a caldo. I backup stanno accanto, separati e pull-only.

Se non siete sicuri che la vostra copia remota partirebbe il giorno in cui vi serve, vale la pena scoprirlo in una giornata tranquilla. Siamo lieti di aiutarvi a progettare i gruppi e il test.

cta: Parla con un ingegnere

Related

• /what-we-do/storage-compute/storage-replication-federation/
• /what-we-do/storage-compute/disaster-recovery/
• /what-we-do/storage-compute/enterprise-san-storage/