La replica tra regioni è al 100% a prova di errore per le interruzioni nella regione S3?

Amazon S3 ha un'opzione di replica inter-regione che dovrebbe essere abbastanza tollerante ai guasti contro le interruzioni di regione / zona.

Ciò significa che coloro che si arrabbiano per l'interruzione non si sono avvalsi di questo aspetto?

Oppure la replica tra regioni non è completamente a prova di errore e non avrebbe aiutato?

amazon-s3

— Dawny33
fonte

collegati: devops.stackexchange.com/questions/83/…

— Evgeny

@Evgeny Grazie. Stavo leggendo lo stesso post, prima di chiedere questo :)

— Dawny33

Lo svantaggio in caso di replica proviene dalla nota seguente:

Amazon S3 indirizza tutte le richieste in stile host virtuale verso la regione Stati Uniti orientali (Virginia settentrionale) per impostazione predefinita se si utilizza l'endpoint Stati Uniti orientali (Virginia settentrionale) (s3.amazonaws.com), anziché l'endpoint specifico della regione (per esempio, s3-eu-west-1.amazonaws.com).

Quando usi la replica, di solito lasci che AWS si occupi del routing dell'alias verso una regione indirizzandoti s3.amazonaws.comnella tua richiesta REST dai tuoi server e lascia che il reindirizzamento faccia il suo lavoro.

Ogni volta che N.Virginia è inattivo, la magia smette di funzionare e sei sfortunato ad accedere ai tuoi dati e devi aggiornare la configurazione per scegliere un endpoint specifico della regione.

Il problema non proviene dal DNS (una richiesta al bucket stesso funzionerà) ma dai client S3, che si collegheranno all'endpoint dell'API S3 prima di accedere al bucket, in questo caso la risoluzione DNS viene eseguita s3.amazonaws.come questo è noi- endpoint est-1.

Quando usi l'alias delle regioni, perdi la facilità di bilanciamento del carico sulle regioni con il controllo dello stato di AWS incluso.

Se si utilizza il nome DNS DNS destinato alle regioni per passare rapidamente, si è responsabili del TTL DNS ma nulla garantisce che i server cache dell'ISP client rispettino il proprio valore (una delle tante cache che il client potrebbe incontrare).

Infine, se provi a bilanciare il carico da solo, probabilmente creerai lo stesso SPOF di AWS con l'onere aggiuntivo di mantenerlo.

AWS ci sta lavorando, ma sono tutte le informazioni che ho al momento della stesura.

— Tensibai
fonte

Secondo docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html è possibile utilizzare 'bucketname.s3-eu-west-1.amazonaws.com' (sostituire la propria regione preferita) come alias DNS. IFF che funziona, può essere un modo per passare rapidamente (alla velocità consentita dal TTL preimpostato)

— Michael Bravo

@MichaelBravo ha esteso la risposta per rispondere alle tue preoccupazioni :)

— Tensibai

"Anche se in teoria potresti usare CNAME per gli endpoint regionali, la risposta autorevole si basa sul servizio in Virginia, per quanto ne so e ne ho letto" Stai prendendo la citazione sul routing verso la regione orientale degli Stati Uniti di default fuori contesto. Prima che example-bucketesca il bucket, example-bucket.s3.amazonaws.compunta già a US East in DNS. Entro pochi minuti dalla creazione iniziale del bucket, questo cambia in modo permanente per puntare all'endpoint regionale corretto. L'avvertimento qui è che questo nome host può inizialmente essere brevemente deviato immediatamente dopo la creazione del bucket, non più tardi.

— Michael - sqlbot

... quindi "Ogni volta che N.Virginia è inattivo, la magia smette di funzionare e sei sfortunato ad accedere ai tuoi dati in qualsiasi regione con il metodo alias DNS" è quindi errato. L'interruzione us-east-1 non ha influito sui bucket in altre regioni, inclusi quelli a cui si fa riferimento utilizzando questo stile di nome host.

— Michael - sqlbot

No, non lo fai. Cambiano la voce DNS per il tuo bucket nella s3.amazonaws.comzona entro pochi minuti dalla creazione del bucket e questa modifica persiste indipendentemente da noi-est-1. Crea un bucket in un'altra area e osserva come si your-bucket-name.s3.amazonaws.comrisolve prima, durante e pochi minuti dopo la creazione del bucket. Le informazioni vengono inviate alla s3-1.amazonaws.comzona nella Route 53 dopo la creazione del bucket e persistono lì, senza ulteriore affidamento su us-east-1.

— Michael - sqlbot

Molte grandi aziende sarebbero in errore per non aver utilizzato questa funzione. Aggiunge costi aggiuntivi e storicamente qualsiasi tipo di soluzione di ripristino di emergenza reale non viene testato anche se implementato.

Oltre al problema dei costi, le aziende che stanno attivamente utilizzando la replica tra regioni possono offrire una valida preoccupazione per quanto riguarda la latenza necessaria per la replica di un oggetto. S3 non consente (per quanto ne so) coerenza lettura-scrittura-scrittura su oggetti replicati, mentre lo consente per un bucket in una singola regione.

Questa domanda di SE solleva il problema per cui gli oggetti non vengono replicati correttamente o impiegano troppo tempo per replicarsi. A condizione che la replica tra regioni venga eseguita in una modalità di eventuale coerenza, ci sono molte preoccupazioni da affrontare.

— Evgeny
fonte

Vorrei porre ulteriormente l'accento sul fatto che la replica tra regioni S3 offre un'eventuale coerenza per alcune operazioni. Cioè non banale di prendere in considerazione. A seconda dell'applicazione, potrebbe essere assolutamente inaccettabile. In ogni caso, non è a prova di folle (può portare a problemi più grandi se qualcuno assume che sia magico)

— Alexandre