9 errori che fanno fallire la tua replica con AWS RDS

9 errori che fanno fallire la tua replica con AWS RDS

Ci sono degli errori che possono far fallire miseramente una replica sul cloud, scopriamo insieme a Ohad Flinker, blogger di CloudEndure, quali sono e come superarli.

Chi usufruisce di un servizio di database relazionale come Amazon RDS, è molto soddisfatto delle sue alte performance e delle funzionalità di replica, in particolare per la varietà di applicazioni cloud che è in grado di gestire in situazioni di ​​ripristino di emergenza (DR) o durante la migrazione.
Spesso, però, anche i più esperti possono trovare difficoltà ecco perché è importante individuare quali potrebbero essere gli errori per poter aggirarli al meglio. Come dice Sun Tzu nell’Arte delle Guerra: “Se conosci il nemico e te stesso, la tua vittoria è sicura”.

E allora, ecco, i 9 errori da cui guardarsi:

1. Lasciare i backup giornalieri disabilitati
Se il tuo RPO (Recovery Point Objective) non è aggressivo, l’abilitazione del backup può essere sicuramente una buona idea, innanzitutto perché è il meccanismo di replica più semplice da implementare.
Importante sottolineare che non si deve iniziare a lavorare senza prima aver consentito il backup con le repliche di lettura (che consentono RPO drasticamente inferiori)
2. Ignorare l’architettura multi-AZ (zona di disponibilità)
Di certo uno dei modi più sicuri per boicottare il proprio progetto è trascurare l’architettura multi-AZ su AWS. Abilitare multi-AZ su RDS è il modo più agevole per replicare un’istanza all’interno della stessa regione.
Se si replica in tutte le regioni, l’isolamento di RDS in un’unica AZ potrà comportare tempi di inattività come risultato diretto del meccanismo di replica (ad esempio backup, lettura-replica, CloudEndure o una combinazione).

3. Tentare di replicare da zero anziché creare una replica di lettura nella regione di destinazione
Amazon ha creato “cross region” per le repliche di lettura su RDS proprio per affrontare casi complessi. Quindi perchè non utilizzarle?

4. Replicare solo RDS (escludendo dal processo il resto dell’applicazione)
Perchè una replica abbia successo l’applicazione deve poter essere in grado di funzionare in modo ridondante in entrambi i percorsi, sia in quello di origine sia in quello di destinazione. Questo significa che si deve replicare l’intera applicazione nella stessa posizione di destinazione in modo che ogni componente possa funzionare con l’istanza RDS.

5. Configurare l’istanza RDS “Read-replica” in modo diverso rispetto alla sorgente
Le proprietà della Read-replica RDS devono corrispondere esattamente all’istanza di origine. Anche una leggera modifica alle proprietà dell’istanza potrebbe costituire un blocco per la replica.

6. Dimenticare di impostare avvisi di replica
Se non si configurano gli avvisi attraverso un servizio come quello Amazon SNS, non si avrà modo di sapere se effettivamente la replica di lettura nella regione di destinazione è stata aggiornata influendo così sulla capacità di RPO.

7. Fare riferimento alle istanze nel sito di ripristino / migrazione all’istanza di origine RDS
Durante il failover o la migrazione bisogna promuovere la replica di lettura in modo che funzioni come parte dell’intero stack di applicazioni. Se le istanze non vengono aggiornate nella regione di ripristino, quando si vorrà accedere alla replica-lettura, anziché all’istanza originale RDS, l’applicazione di replica continuerà a funzionare con l’istanza originale danneggiando l’ambiente di produzione.

8. Non programmare mai un drill
Se non si effettua un test dell’applicazione non si potrà mai sapere in caso di un reale disastro cosa accadrà e come comportarsi per salvaguardarsi. Per questo è importante effettuare un monitoraggio del susseguirsi degli eventi. Il drill promuove la read-replica, accoppia le repliche degli altri componenti della applicazione e le collega tra loro nella regione di destinazione.

9. Non riuscire a pianificare il failback dopo il failover
Dopo aver superato con successo un failover, si può ritornare al sito originale. Questo significa ripetere l’intero processo di failover in senso inverso in modo da poter tornare effettivamente al proprio lavoro.

Comments are closed.