Czy replikacja między regionami jest w 100% niezawodna w przypadku awarii regionu S3?

Amazon S3 ma opcję replikacji między regionami, która powinna być dość odporna na awarie w przypadku awarii regionu / strefy.

Czy to oznacza, że ci, którzy narzekają na awarię, nie skorzystali z tego aspektu?

A może replikacja między regionami nie jest całkowicie niezawodna i nie pomogłaby?

amazon-s3

— Dawny33
źródło

powiązane: devops.stackexchange.com/questions/83/…

— Evgeny

@Evgeny Dziękuję. Czytałem ten sam post, zanim o to

— zapytałem

Wada związana z replikacją wynika z poniższej uwagi:

Amazon S3 domyślnie trasuje wszelkie wirtualne żądania w stylu hostowanym do regionu USA East (N. Virginia), jeśli używasz punktu końcowego US East (N. Virginia) (s3.amazonaws.com), zamiast punktu końcowego specyficznego dla regionu (dla na przykład s3-eu-west-1.amazonaws.com).

Podczas korzystania z replikacji zwykle AWS zajmuje się routowaniem aliasu do jednego regionu, s3.amazonaws.comkierując żądanie żądania REST z serwerów i pozwalając przekierowaniu wykonać swoje zadanie.

Za każdym razem, gdy N.Virginia nie działa, magia przestaje działać i nie masz szczęścia, aby uzyskać dostęp do swoich danych i musisz zaktualizować konfigurację, aby wybrać punkt końcowy określonego regionu.

Problem nie pochodzi z DNS (żądanie do samego segmentu będzie działać), ale od klientów S3, którzy połączą się z punktem końcowym interfejsu API S3 przed uzyskaniem dostępu do segmentu, w tym przypadku rozdzielczość dns jest wykonywana s3.amazonaws.comi jest to us- punkt końcowy wschód-1.

Kiedy używasz aliasu regionów, tracisz łatwość równoważenia obciążenia w regionach z włączoną kontrolą stanu z AWS.

Jeśli używasz nazwy DNS w celu szybkiego przełączania regionów, ponosisz odpowiedzialność za TTL DNS, ale nic nie gwarantuje, że serwery pamięci podręcznej klienta ISP uszanują twoją wartość (jedna z wielu pamięci podręcznych, które może napotkać klient).

I na koniec, jeśli spróbujesz samodzielnie wczytać równowagę, prawdopodobnie stworzysz ten sam SPOF, co już AWS, z dodatkowym obciążeniem związanym z jego utrzymaniem.

AWS nad tym pracuje, ale to wszystko, co mam w chwili pisania.

— Tensibai
źródło

Według docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html można użyć „bucketname.s3-eu-west-1.amazonaws.com” (zamień swój ulubiony region) jako alias DNS. IFF, który działa, może być sposobem na szybką zmianę (tak szybko, jak pozwala na to ustawione wcześniej TTL)

— Michael Bravo

@MichaelBravo udzielił odpowiedzi, aby rozwiązać problem :)

— Tensibai

„Nawet jeśli teoretycznie można użyć CNAME do regionu końcowych, odpowiedź autorytatywna polegać na służbie w N.Virginia o ile wiem i czytałem o to” Bierzesz cytat o routingu do regionu US East domyślnie poza kontekstem. Zanim ten example-bucketsegment będzie istniał, example-bucket.s3.amazonaws.comwskazuje już na DNS Wschodni w USA. W ciągu kilku minut od początkowego utworzenia segmentu zmienia się to na stałe, wskazując właściwy regionalny punkt końcowy. Ostrzeżeniem jest to, że ta nazwa hosta może być początkowo krótko przekierowana natychmiast po utworzeniu segmentu - nie później.

— Michael - sqlbot

... więc „Ilekroć N.Virginia nie działa, magia przestaje działać i nie masz szczęścia, aby uzyskać dostęp do swoich danych w dowolnym regionie metodą aliasu DNS”, dlatego jest niepoprawna. Wyłączenie us-east-1 nie wpłynęło na segmenty w innych regionach, w tym te, do których odwołuje się ten styl nazwy hosta.

— Michael - sqlbot

Nie, ty nie. Zmieniają wpis DNS dla twojego segmentu w s3.amazonaws.comstrefie w ciągu kilku minut od utworzenia segmentu, i ta zmiana utrzymuje się niezależnie od nas-wschód-1. Utwórz wiadro w innym regionie i obserwuj, jak your-bucket-name.s3.amazonaws.comrozwiązuje się przed, w trakcie i kilka minut po utworzeniu wiadra. Informacje są przekazywane do s3-1.amazonaws.comstrefy na Trasie 53 po utworzeniu wiadra i pozostają tam, bez dalszego polegania na us-east-1.

— Michael - sqlbot

Wiele dużych firm byłoby winnych za nieużywanie tej funkcji. To nie dodawać dodatkowych kosztów, a historycznie każdy rodzaj prawdziwego rozwiązania odzyskiwania danych jest niesprawdzone, nawet jeśli wdrożone.

Oprócz kwestii związanych z kosztami firmy, które aktywnie korzystają z replikacji między regionami, mogą przedstawić uzasadnione obawy dotyczące opóźnienia, jakie zajmuje replikacja obiektu. S3 nie pozwala (o ile wiem) na spójność odczytu po zapisie replikowanych obiektów, podczas gdy pozwala na segment w jednym regionie.

To pytanie SE rodzi obawy, że obiekty nie są replikowane poprawnie lub replikacja trwa zbyt długo. Pod warunkiem, że replikacja między regionami odbywa się w trybie ostatecznej spójności, istnieje wiele problemów do rozwiązania.

— Jewgienij
źródło

Chciałbym położyć jeszcze większy nacisk na fakt, że replikacja między regionami S3 oferuje ostateczną spójność dla niektórych operacji. To nie jest trywialne do wzięcia pod uwagę. W zależności od zastosowania może być wręcz niedopuszczalne. W każdym razie nie jest to głupie (może prowadzić do większych problemów, jeśli ktoś uzna, że to magia)

— Alexandre