C'è qualcosa di interessante in questa domanda, in particolare per quanto riguarda l'idea dei tempi di fermo. Parte dell'idea è che se un'applicazione è sensibile ai tempi di inattività, anche i tempi di recupero devono essere presi in considerazione. ).
Un po 'su EBS
I volumi e le istantanee EBS funzionano a livello di blocco, una conseguenza della quale consente di acquisire istantanee mentre un'istanza è in esecuzione, anche se il volume EBS è in uso. Tuttavia, solo i dati che si trovano effettivamente sul disco (cioè non in una cache di file) verranno inclusi nell'istantanea. È quest'ultima ragione che dà origine all'idea di istantanee coerenti.
- Il modo consigliato è quello di staccare il volume, istantaneamente e ricollegarlo, di solito non pratico.
- L'opzione migliore successiva prevede lo svuotamento delle cache di scrittura sul disco, il blocco del file system e l'esecuzione dell'istantanea
Un punto interessante qui è che in entrambi i casi sopra, non è necessario attendere il completamento dell'istantanea per ricollegarsi / sbloccare e riprendere la scrittura sul disco: una volta avviata l'istantanea, i dati saranno coerenti con quel momento. In genere ciò richiede solo pochi secondi durante i quali il disco è bloccato in scrittura. Inoltre, poiché la maggior parte dei database struttura i propri file su disco in modo ragionevole - esiste una buona probabilità che gli inserti abbiano un effetto minimo sui blocchi esistenti - il che riduce al minimo i dati aggiunti all'istantanea.
Considera il punto del backup
I volumi EBS sono già replicati all'interno di una zona di disponibilità, quindi è presente un certo grado di ridondanza. Se l'istanza viene chiusa, è possibile semplicemente collegare il volume EBS a una nuova istanza e (dopo aver superato la mancanza di coerenza) riprendere da dove lasciato fuori. Per molti aspetti ciò rende il volume EBS molto simile a uno snapshot incoerente, a condizione che sia possibile accedervi. Detto questo, la maggior parte degli utenti EC2 probabilmente ricorda i fallimenti a cascata dei volumi EBS dall'inizio del 2011 - i volumi sono stati inaccessibili per più giorni e alcuni utenti hanno perso anche i dati.
RAID1
Se si sta tentando di proteggersi dall'errore di un disco EBS (ciò accade), è possibile prendere in considerazione un'installazione RAID1. Poiché i volumi EBS sono dispositivi a blocchi, è possibile utilizzare facilmente mdadm per configurarli nella configurazione desiderata. Se uno dei tuoi volumi EBS non funziona secondo le specifiche, è abbastanza facile fallirlo manualmente (e successivamente sostituirlo con un altro volume EBS). Naturalmente, questo ha degli aspetti negativi: maggiore tempo per ogni scrittura, maggiore suscettibilità alle prestazioni variabili, doppio del costo I / O (monetariliy, non dal punto di vista delle prestazioni), nessuna protezione reale contro un fallimento AWS più diffuso (un problema comune dell'anno scorso era l'impossibilità di staccare i volumi EBS che erano in uno stato bloccato) e, naturalmente, lo stato incoerente del disco in caso di errore.
S3FS
Un'opzione per alcune applicazioni (sicuramente NON per i database) è montare S3 come file system locale (ad es. Tramite s3fs). Questo è lento, manca di alcune delle funzionalità che ci si aspetterebbe da un file system e potrebbe non comportarsi come previsto (eventuale coerenza). Detto questo, per un semplice scopo come rendere disponibili i file caricati su più istanze, potrebbe avere dei meriti. Ovviamente non è per tutto ciò che richiede buone prestazioni di lettura / scrittura.
Bin-log di MySQL
Un'altra opzione specifica per MySQL potrebbe essere l'uso del bin-log. È possibile impostare un secondo volume EBS che memorizzerà il proprio registro bin (per ridurre al minimo l'effetto delle scritture aggiunte sul database) e utilizzarlo insieme a qualsiasi dump del database. Potresti anche essere in grado di farlo con s3fs, che potrebbe effettivamente avere merito se le prestazioni sono tollerabili (probabilmente un rsync sarebbe meglio che provare a usare direttamente s3fs e vorrai sicuramente comprimere ciò che puoi).
Ancora una volta, però, torniamo all'idea di scopo. Considera cosa accadrebbe con i suggerimenti di cui sopra:
- Volumi EBS inaccessibili:
- RAID1: inutile, poiché non è possibile accedere ai dati
- bin-log - inutile, a meno che non sia stato esportato in S3 - probabilmente un ritardo se lo facessi
- L'istanza termina inaspettatamente:
- RAID1: i dischi sono disponibili, ma non coerenti, il database potrebbe ripristinarsi da solo incoerenza
- bin-log: i dati dovrebbero essere accessibili, anche se potrebbe essere necessario rivedere gli ultimi eventi
- Qualcuno esegue DROP DATABASE come root:
- RAID1: hai due copie perfette di un database inesistente
- bin-log: dovresti essere in grado di riprodurre gli eventi fino a poco prima del comando, quindi dovresti essere a posto
Quindi, in realtà, RAID1 è per lo più inutile e il bin-log impiega troppo tempo - entrambi possono avere dei meriti in determinate circostanze, ma sono lontani dall'idea del backup.
istantanee
È importante notare che le istantanee sono differenziali e memorizzano solo i blocchi effettivi che contengono dati (e sono compressi). A differenza di un volume EBS, in cui se si dispone di un volume da 20 GB, ma si utilizza solo 1 GB, viene comunque addebitato lo spazio di archiviazione "provisioning" (20 GB). Con un'istantanea, ti viene addebitato solo ciò che utilizzi. Se nessun dato cambia tra le istantanee, non c'è (teoricamente) alcun addebito. (Le istantanee vengono addebitate per PUTS / GETS e spazio di archiviazione utilizzato).
Inoltre, consiglio vivamente che i dati della tua applicazione (compresi i database) non vengano archiviati sul tuo volume di root (che potresti avere già configurato). Uno dei vantaggi è che, si spera, il tuo volume di root vede un minimo di cambiamento - il che significa che le sue istantanee possono essere meno frequenti (o avranno un minimo di cambiamento) riducendo i costi e la facilità d'uso.
È anche importante ricordare che è possibile eliminare le vecchie istantanee in qualsiasi momento, anche se sono differenziali e non influiranno sulle altre istantanee. Detto questo, ogni blocco assegnato a un'istantanea non verrà abbandonato fino a quando non ci sarà un'istantanea che fa ancora riferimento a quel blocco.
Il problema con i dump periodici è innanzitutto il tempo che intercorre tra i dump (eventualmente risolti utilizzando il bin-log di MySQL) e anche la difficoltà di recupero. Ci vuole tempo per importare un dump di grandi dimensioni e riprodurre tutti gli eventi da un registro bin. Inoltre, la creazione di un dump non è priva di conseguenze per le prestazioni. Probabilmente, tali discariche richiedono probabilmente molta più memoria di un'istantanea. La creazione di un volume EBS esclusivamente per i database e lo snapshot sarebbe preferibile per la maggior parte dei casi (detto ciò, anche lo scatto di un'istantanea ha un certo impatto sulle prestazioni).
Il bello delle istantanee e dei volumi EBS è che possono essere utilizzati in altri casi. Se la tua istanza non si avvia, puoi collegare il volume di root a un'altra istanza per diagnosticare e risolvere il problema - o semplicemente per copiare i tuoi dati da esso - e puoi cambiare i volumi di root con solo un paio di minuti di downtime (fermare l'istanza, staccare il volume di root, collegare un nuovo volume di root, avviare l'istanza). La stessa idea vale per avere i tuoi dati su un secondo volume EBS. In sostanza, è sufficiente estrarre una nuova istanza dall'AMI personalizzata e collegare il volume EBS corrente ad esso - aiuta a ridurre al minimo i tempi di inattività.
(Si potrebbe argomentare (e probabilmente non lo consiglierei) che è possibile impostare due copie di MySQL sullo stesso server (Master-slave), utilizzando due volumi EBS, quindi arrestare lo slave per scattare un'istantanea del suo Volume EBS - sarà coerente, senza tempi di inattività - ma i costi di prestazione probabilmente non ne valgono la pena).
AWS ha il ridimensionamento automatico, che sarà in grado di mantenere un numero costante di istanze (anche se quel numero è 1), tuttavia si distribuirà da un'istantanea, quindi se l'istantanea non è utile, la premessa non è di grande utilità .
Un'altra coppia di punti: è possibile distribuire tutte le istanze desiderate da una singola istantanea (a differenza di un volume EBS, che può essere collegato a una singola istanza in qualsiasi momento). Inoltre, i volumi EBS possono essere utilizzati all'interno di un'area di disponibilità, mentre le istantanee possono essere utilizzate all'interno di un'area.
Idealmente, con uno snapshot, se il tuo server si arresta, puoi semplicemente avviarne uno nuovo usando l'ultimo snapshot - specialmente se separi il tuo volume di root dai tuoi dati, un cattivo aggiornamento dovrebbe comportare un minimo di downtime (dal momento che trasferisci il volume EBS contenente i tuoi dati - e scatta un'istantanea per preservare tutto ciò che potrebbe essere danneggiato a causa di un'incoerenza).
Come nota a margine, Amazon afferma che il tasso di fallimento dei volumi EBS aumenta con la quantità di dati modificati su di loro dall'ultima istantanea.
Raccomandazioni finali
- Usa le istantanee - sono fantastiche - riducono i tempi di fermo molto più di quanto non lo causino
- Separare i dati e il volume di root, magari anche mettendo i database sul proprio volume e, se necessario, eseguire uno snapshot prima degli aggiornamenti
- Usa il bin-log per rimanere il più 'caldo' possibile - carica questo (compresso) su S3
- Assicurati di ottenere effettivamente i dati dall'istanza (anche se i dati sono intatti su un volume EBS, il volume stesso potrebbe essere temporaneamente inaccessibile).
Lettura consigliata:
(Credo di aver scritto troppo, ma non ho detto abbastanza - ma spero che trovi qualcosa che valga la pena leggere).