Ćwiczenie — rozszerzanie projektu na wiele regionów
Firma Contoso Shoes potrzebuje sposobu, aby wytrzymać awarie regionalne. Chcesz wdrożyć bieżącą sygnaturę w topologii aktywne-aktywne, współużytkowane i wieloregionowej. Architektura musi być zaprojektowana tak, aby przekierowywać ruch do innego regionu w przypadku awarii regionu.
Bieżący stan i problem
Jeden region był wystarczający dla aplikacji. Jednak niedawna awaria regionalna, która ma wpływ na sieć, spowodowała przejście systemu do trybu offline z perspektywy użytkownika końcowego. Skalowanie w poziomie w regionie — a nawet wdrożenie nowej sygnatury w tym regionie — nie spowodowałoby odzyskania aplikacji ze stanu niepowodzenia.
Usługa DNS jest przechowywana przez istniejącego rejestratora dla programu api.contososhoes.com. Rekord DNS jest rozpoznawany jako punkt końcowy usługi App Services zaplecza (apicontososhoes.azurewebsites.net) z czasem wygaśnięcia (TTL) w ciągu dwóch dni. Po wdrożeniu rozwiązania w wielu regionach należy przeprowadzić migrację systemu DNS.
Specyfikacja
- Rozszerz architekturę tak, aby działała w topologii aktywne-aktywne i wieloregionowej.
- Zmodyfikuj model sygnatury wdrożenia, który umożliwia dynamiczne dodawanie i usuwanie regionów zgodnie z potrzebami zamiast listy zakodowanych na stałe zasobów w dwóch regionach.
- Jeśli wystąpi awaria regionalna, ruch musi być kierowany do regionu, który nie jest uszkodzony, bez żadnego istotnego wpływu na klientów w regionie, który nie jest uszkodzony.
- Klienci nie powinni być przypięci do regionu.
- Klienci nie powinni zmieniać adresów URL na potrzeby kontaktowania się z interfejsem API. System DNS powinien zostać zmigrowany do routera globalnego.
Zalecane podejście
Aby rozpocząć projektowanie, zalecamy wykonanie następujących kroków:
Topologia 1–Wieloregionowa
Architektura musi być dystrybuowana do co najmniej dwóch regionów świadczenia usługi Azure w celu ochrony przed awariami regionalnymi. Podczas wybierania regionu należy wziąć pod uwagę następujące czynniki:
- Region musi być w stanie wytrzymać awarie centrum danych w tym regionie.
- Usługi platformy Azure i możliwości używane w architekturze muszą być obsługiwane w regionie.
- Region i zasoby wdrożone w regionie muszą być blisko użytkowników końcowych i systemów zależnych, aby zminimalizować opóźnienie sieci.
Pomyśl o scenariuszu awarii. Załóżmy, że region 1 pobiera 75% ruchu, a nowo dodany region 2 pobiera pozostały ruch. Obie te elementy są odpowiednio skalowane w celu obsługi tego obciążenia. W regionie 1 występuje awaria regionalna, a cały ruch jest teraz kierowany do regionu 2. Czy możesz sprawić, że przejście będzie sprawne? Czy region 2 może obsługiwać zwiększone obciążenie ruchem?
Sprawdzanie postępu: Dystrybucja globalna
Routing globalny 2
Aby klienci otrzymywali przezroczyste trasy do jednego z regionów roboczych, dodaj globalny moduł równoważenia obciążenia. Moduł równoważenia obciążenia powinien używać kontroli kondycji dodanych w poprzednim ćwiczeniu, aby określić, czy sygnatura jest w dobrej kondycji. Czy można myśleć o sposobach obsługi częstych i podobnych żądań, które można spełnić bez dotarcia do zaplecza?
- Wybierz natywną usługę platformy Azure, która integruje się z istniejącą architekturą i umożliwia szybkie przełączanie w tryb failover.
- Upewnij się, że ścieżka ruchu przychodzącego sieci ma kontrolki w celu odmowy nieautoryzowanego ruchu.
- Zminimalizuj opóźnienie sieci, obsługując użytkowników końcowych z pamięci podręcznej brzegowej.
- Migrowanie istniejącego systemu DNS bez wpływu na istniejących klientów.
- Mieć zautomatyzowany sposób wskazywania awarii regionalnej, aby upewnić się, że ruch nie jest kierowany do uszkodzonego regionu. Ponadto otrzymuj powiadomienia, gdy region jest ponownie dostępny, aby moduł równoważenia obciążenia mógł wznowić routing do tego regionu.
Sprawdzanie postępu: Globalny routing ruchu
3 — Zmiany sygnatury wdrożenia
Idealnym stanem jest konfiguracja aktywna-aktywna, która nie wymaga ręcznego przejścia w tryb failover, a żądania klientów mogą być obsługiwane z dowolnego regionu. Zastanów się nad tym, co oznacza dla twojej architektury. Czy na przykład masz jakikolwiek stan przechowywany w sygnaturze regionalnej?
Niektóre usługi w bieżącej architekturze mają możliwości replikacji geograficznej. Rozważ rozdzielenie usług na różne sygnatury: jedną sygnaturę zawierającą zasoby globalne i inną sygnaturę regionalną, która udostępnia zasoby sygnaturą globalną. Jednym z czynników decydujących powinno być cykl życia tych zasobów. Jaki jest oczekiwany okres istnienia zasobu względem innych zasobów w architekturze? Czy zasób powinien przetrwać lub udostępnić okres istnienia całej systemowi lub regionowi, czy też powinien być tymczasowy?
Zapoznaj się z funkcjami niezawodności usług platformy Azure używanymi w architekturze. Możesz zacząć od tych funkcji i dokładniej zbadać, aby zmaksymalizować niezawodność.
| Usługa platformy Azure | Funkcja |
|---|---|
| Azure Cosmos DB | Zapis w wielu regionach |
| Azure Container Registry | Geo-replication (Replikacja geograficzna) |
| Plan usługi Azure App Service | Obsługa strefy dostępności |
Sprawdzanie postępu: platforma danych platformy | aplikacji
Sprawdź swoją pracę
Poniżej przedstawiono opcje projektowania aplikacji i danych dla podobnej architektury. Czy wszystkie aspekty zostały omówione w projekcie?
- Który inny region platformy Azure został wybrany dla topologii obejmującej wiele regionów i dlaczego?
- Czy włączono co najmniej dwie Strefy dostępności platformy Azure w każdym regionie świadczenia usługi Azure w celu ochrony przed awariami centrum danych?
- Czy włączono zaporę aplikacji internetowej do kontrolowania ruchu przychodzącego? Jakie reguły routingu zostały wprowadzone i dlaczego?
- Jak moduł równoważenia obciążenia obsługuje istniejący rekord DNS?
- Jak używasz interfejsu API sprawdzania kondycji z poprzedniego ćwiczenia?
- Czy aplikacja jest chroniona przed atakami DDoS, szczególnie uniemożliwiając złośliwym klientom pomijanie modułu równoważenia obciążenia i docieranie do wystąpień regionalnych?
- Jak podejść do migracji DNS?
- Czy wprowadzono zmiany jednostki SKU w istniejącym składniku w celu obsługi topologii w wielu regionach?
- Które usługi platformy Azure pozostawiliśmy jako singletons? W jaki sposób uzasadniłeś wybór dla każdej usługi? Czy wprowadzono jakieś zmiany konfiguracji?
- Czy rejestrujesz zasoby? Czy uważasz, że będzie to miało wpływ na możliwość inspekcji dzienników dla całego systemu?