Ist die regionsübergreifende Replikation für S3-Regionsausfälle 100% narrensicher?

Amazon S3 bietet eine Option für die regionübergreifende Replikation, die bei Regions- / Zonenausfällen ziemlich fehlertolerant sein sollte.

Bedeutet das, dass diejenigen, die sich über den Ausfall beschweren, diesen Aspekt nicht genutzt haben?

Oder ist diese regionübergreifende Replikation nicht absolut narrensicher und hätte nicht geholfen?

amazon-s3

— Dawny33
quelle

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

— Evgeny

@Evgeny Danke. Ich habe den gleichen Beitrag gelesen, bevor ich gefragt habe :)

— Dawny33

Der Nachteil bei Replikation ergibt sich aus dem folgenden Hinweis:

Amazon S3 leitet standardmäßig alle virtuellen gehosteten Anforderungen an die Region US-Ost (N. Virginia) weiter, wenn Sie den Endpunkt US-Ost (N. Virginia) (s3.amazonaws.com) anstelle des regionenspezifischen Endpunkts (z Beispiel s3-eu-west-1.amazonaws.com).

Wenn Sie die Replikation verwenden, lässt AWS den Alias normalerweise an eine Region weiterleiten, indem s3.amazonaws.comIhre REST-Anforderung von Ihren Servern als Ziel festgelegt wird und die Umleitung ihren Job erledigt .

Immer wenn N.Virginia inaktiv ist, funktioniert die Magie nicht mehr und Sie haben Pech, auf Ihre Daten zuzugreifen und Ihre Konfiguration zu aktualisieren, um einen bestimmten Regionsendpunkt auszuwählen.

Das Problem kommt nicht vom DNS (eine Anforderung an den Bucket selbst wird funktionieren), sondern von S3-Clients, die vor dem Zugriff auf den Bucket eine Verbindung zum S3-API-Endpunkt herstellen. In diesem Fall wird die DNS-Auflösung s3.amazonaws.comausgeführt. Ost-1-Endpunkt.

Wenn Sie Regions-Alias verwenden, verlieren Sie die Leichtigkeit des Lastenausgleichs über Regionen mit der Integritätsprüfung von AWS.

Wenn Sie DNS cname verwenden, um schnell auf die Regionen umzuschalten, sind Sie für Ihre DNS-TTL verantwortlich, es wird jedoch nicht garantiert, dass Cache-Server des Client-ISP Ihren Wert berücksichtigen (einer von vielen Caches, auf die Ihr Client möglicherweise stößt).

Und schließlich, wenn Sie versuchen, den Lastenausgleich selbst vorzunehmen, werden Sie wahrscheinlich denselben SPOF erstellen, den AWS bereits hat, mit der zusätzlichen Belastung, ihn beizubehalten.

AWS arbeitet daran, aber das sind alle Informationen, die ich zum Zeitpunkt des Schreibens habe.

— Tensibai
quelle

Laut docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html ist es möglich, "bucketname.s3-eu-west-1.amazonaws.com" (anstelle Ihrer bevorzugten Region) als DNS-Alias zu verwenden. Wenn das funktioniert, kann es eine Möglichkeit sein, schnell zu wechseln (so schnell es Ihre voreingestellte TTL zulässt)

— Michael Bravo

@MichaelBravo erweiterte die Antwort, um Ihr Anliegen anzusprechen :)

— Tensibai

„Selbst wenn in der Theorie Sie CNAME Region Endpoints nutzen könnten, verlassen die verbindliche Antwort auf den Dienst in N.Virginia soweit ich weiß , und ich gelesen habe darüber“ Sie nehmen das Zitat über das Routing an den US - Osten Standardmäßig außerhalb des Kontexts. Bevor der example-bucketBucket existiert, example-bucket.s3.amazonaws.comverweist er bereits im DNS auf US East. Innerhalb weniger Minuten nach der ersten Bucket-Erstellung ändert sich dies permanent und zeigt auf den richtigen regionalen Endpunkt. Die Warnung hier ist, dass dieser Hostname unmittelbar nach der Bucket-Erstellung zunächst kurzzeitig fehlgeleitet werden kann - nicht später.

— Michael - sqlbot

... "Immer wenn N.Virginia inaktiv ist, funktioniert die Magie nicht mehr und Sie haben Pech, in einer beliebigen Region mit der DNS-Alias-Methode auf Ihre Daten zuzugreifen" ist daher falsch. Eimer in anderen Regionen waren von dem Ausfall in den USA-Osten-1 nicht betroffen, einschließlich derjenigen, auf die mit diesem Hostnamen-Stil verwiesen wurde.

— Michael - sqlbot

Nein, tust du nicht. Sie ändern den DNS-Eintrag für Ihren Bucket in der s3.amazonaws.comZone innerhalb weniger Minuten nach der Bucket-Erstellung. Diese Änderung bleibt unabhängig von us-east-1 bestehen. Erstellen Sie einen Bucket in einer anderen Region, und beobachten Sie, wie die your-bucket-name.s3.amazonaws.comAuflösung vor, während und einige Minuten nach der Bucket-Erstellung erfolgt. Die Informationen werden nach dem s3-1.amazonaws.comErstellen des Buckets an die Zone in Route 53 weitergeleitet und bleiben dort bestehen, ohne sich weiter auf us-east-1 zu verlassen.

— Michael - sqlbot

Viele große Unternehmen würden schuld daran sein, diese Funktion nicht zu nutzen. Dies führt zu zusätzlichen Kosten, und in der Vergangenheit ist jede echte Disaster Recovery-Lösung ungetestet, selbst wenn sie implementiert ist.

Abgesehen vom Kostenproblem können Unternehmen, die die regionenübergreifende Replikation aktiv einsetzen, berechtigte Bedenken hinsichtlich der Latenz für die Replikation eines Objekts geltend machen. S3 erlaubt (soweit ich weiß) keine Read-After-Write-Konsistenz für replizierte Objekte, während dies für einen Bucket in einer einzelnen Region möglich ist.

Diese SE-Frage gibt Anlass zur Sorge, wenn Objekte nicht ordnungsgemäß repliziert werden oder die Replikation zu lange dauert. Vorausgesetzt, die regionübergreifende Replikation erfolgt in einer Art und Weise, in der die Konsistenz erreicht wird, gibt es viele Bedenken, die berücksichtigt werden müssen.

— Evgeny
quelle

Ich möchte die Tatsache weiter betonen, dass die bereichsübergreifende S3-Replikation für einige Vorgänge eine mögliche Konsistenz bietet . Das ist nicht trivial zu berücksichtigen. Abhängig von der Anwendung kann dies völlig inakzeptabel sein. In jedem Fall ist es nicht narrensicher (kann zu größeren Problemen führen, wenn jemand annimmt, dass es magisch ist)

— Alexandre