Jaka jest dobra strategia utrzymywania mojej witryny w trybie online, gdy S3 przechodzi w tryb offline?

32

Jaka jest dobra strategia utrzymywania mojej witryny w trybie online, gdy S3 przechodzi w tryb offline?

Jeśli S3 US East 1 przejdzie w tryb offline, jak powinienem skonfigurować / ustrukturyzować moją aplikację, aby zapobiec przełączeniu całej witryny w tryb offline?

Jakie są najlepsze strategie dywersyfikacji w takiej sytuacji?

jcolebrand
źródło
Co próbowałeś?
030

Odpowiedzi:

26

W marcu 2015 r. Amazon AWS ogłosił, że obsługuje replikację S3 w różnych regionach. Gdy określony region w S3 przechodzi w tryb offline, możesz udostępniać pliki z serwera lustrzanego w innym regionie.

źródło: https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/

Praktyka utrzymywania infrastruktury w trybie online poprzez przejście do innego regionu jest złożona, ale S3 jest stosunkowo małym i prostym komponentem. Netflix ma świetny artykuł na temat swoich doświadczeń z Gorylem Chaosu.

Dotyczy to również degradacji usług, takich jak zwiększone opóźnienie. Nie tylko wtedy, gdy usługa, na której polegasz, jest całkowicie offline. Netflix ma również artykuł na ten temat: Ulepszona inżynieria chaosu .

Jewgienij
źródło
Strategią sprawdzania, czy coś działa, jest sprawdzenie, czy to działa. To samo dotyczy kopii zapasowych, kodu itp. Sugeruję, aby środowisko testowe (jeśli je masz) lub środowisko programistyczne (jeśli je posiadasz) działało z replikowanej witryny podczas uruchamiania testów.
Evgeny
Netflix przenosi całe regiony do trybu offline, aby sprawdzić, czy ich plany tworzenia kopii zapasowych faktycznie działają.
Evgeny
Pamiętam, kiedy Netflix
padał
10

To, o co prosisz, to w zasadzie wysoka dostępność. Aby system był wysoce dostępny, potrzebujesz trzech rzeczy:

  1. Wyeliminuj pojedyncze punkty awarii
  2. Mechanizm przełączania z punktu końcowego na inny
  3. Sposób na wykrycie awarii

Wyeliminuj pojedyncze punkty awarii

W przypadku S3, punkt # 1 jest rozwiązany, jak wskazał Evgeny, przez replikację między regionami S3 .

Replikacja nie jest jednak natychmiastowa i będziesz chciał sprawdzić, czy chcesz, aby replikacja aplikacji była świadoma, czy nie. W przypadku awarii może się zdarzyć, że coś, co zostało zapisane w źródłowym segmencie, jeszcze go nie uczyniło (nie zostało zreplikowane) w docelowym segmencie. Musisz pomyśleć, jak aplikacja poradziłaby sobie z takim scenariuszem. To naprawdę zależy od rodzaju danych, tego, co się z nimi dzieje i (potencjalnie) oczekiwań użytkowników końcowych lub kierownictwa.

Mechanizm przełączania z punktu końcowego na inny

W przypadku S3 oznacza to, że w przypadku awarii chcesz, aby aplikacja przestała czytać i zapisywać z / do segmentu A i zamiast tego używała segmentu B.

O tym, jak to osiągnąć, zależy od ciebie. Niektóre inne usługi AWS oferują całkowicie transparentne przełączenia awaryjne, ale w tej chwili nie jestem świadomy czegoś takiego dla S3.

Istnieją różne sposoby osiągnięcia tego celu. Jednym z przykładów jest użycie serwera proxy, który przekieruje ruch do odpowiedniego segmentu. Podczas awarii należy zaktualizować / zmienić serwer proxy, aby kierować ruch do segmentu, na który nie ma wpływu awaria. Innym przykładem może być dynamiczna konfiguracja aplikacji i przechowywanie jej w magazynie klucz-wartość. Jeśli aplikacja dość często odczytuje magazyn KV w celu zaktualizowania właściwości, możesz zmienić miejsce odczytu i zapisu (Spring Cloud obsługuje na przykład nasłuchiwanie „EnvironmentChange”).

Sposób na wykrycie awarii

Myślę, że ten jest łatwy. Wystarczy skonfigurować pętlę zapisu + odczytu i powiadomić, gdy tylko coś będzie nie tak :)

Notatki końcowe

  • Jeśli aplikacja pisze do wiadra, musisz pomyśleć o tym, co by się stało w przypadku przełączenia awaryjnego. Czy wszystkie zapisy dotarły do ​​segmentu docelowego (i czy możesz powiedzieć)? Czy możesz zezwolić na zapisy w segmencie docelowym (co czyni go nowym „podstawowym”)? Staranne planowanie pozwoli uniknąć scenariuszy podzielonego mózgu lub utraconych aktualizacji.
  • W zależności od umowy SLA możesz chcieć, aby punkty 2 i 3 były zautomatyzowane lub automatyczne. Wymaga to dodatkowego planowania, oprzyrządowania i testowania, ale dobrze napisane skrypty zawsze będą reagować szybciej i w bardziej przewidywalny sposób niż ludzie (awarie mają również irytujący zwyczaj zdarzania się w środku nocy, gdy interwencja człowieka jest czymś niebezpiecznym.
  • Warto wspomnieć, że nawet replikacja między regionami nie eliminuje całkowicie pojedynczych punktów awarii. Jasne, jeśli region upadnie, jesteś objęty ubezpieczeniem. Ale co się stanie, jeśli nastąpi awaria AWS w USA? Azure miał częściową, ale globalną awarię w ubiegłym roku i jedną w 2014 r.
Alexandre
źródło