Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ten artykuł zawiera szczegółowe informacje na temat odporności regionalnej ze strefami dostępności i odzyskiwaniem po awarii między regionami oraz obsługą ciągłości działania usługi Azure Spring Apps.
Obsługa strefy dostępności
Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.
Usługa Azure Spring Apps obsługuje nadmiarowość strefową. Po utworzeniu wystąpienia usługi Azure Spring Apps przy włączonej redundancji strefowej, usługa Azure Spring Apps automatycznie dystrybuuje podstawowe zasoby między logiczne sekcje podstawowej infrastruktury Azure. Podstawowy zasób obliczeniowy dystrybuuje maszyny wirtualne we wszystkich strefach dostępności, aby zapewnić możliwość obliczeń. Podstawowy zasób magazynu replikuje dane w różnych strefach dostępności, aby zachować je, nawet jeśli wystąpią awarie centrum danych. Ta dystrybucja zapewnia wyższy poziom dostępności i chroni przed awariami sprzętowymi lub zdarzeniami planowanej konserwacji.
Wymagania wstępne
Redundancja strefowa nie jest dostępna w planie podstawowym.
Usługa Azure Spring Apps obsługuje strefy dostępności w następujących regionach:
- Australia Wschodnia
- Brazylia Południowa
- Kanada Środkowa
- Środkowe stany USA
- Azja Wschodnia
- Wschodnie stany USA
- Wschodnie stany USA 2
- Francja Środkowa
- Niemcy Środkowo-Zachodnie
- Europa Północna
- Japonia Wschodnia
- Korea Środkowa
- Północna Republika Południowej Afryki
- Południowo-środkowe stany USA
- Azja Południowo-Wschodnia
- Południowe Zjednoczone Królestwo
- Europa Zachodnia
- Zachodnie stany USA 2
- Zachodnie stany USA 3
Utwórz wystąpienie usługi Azure Spring Apps z włączonymi strefami dostępności
Uwaga / Notatka
Strefową nadmiarowość można włączyć tylko podczas tworzenia instancji usługi Azure Spring Apps. Nie można zmienić właściwości nadmiarowości strefy po utworzeniu.
Redundancję strefową w usłudze Azure Spring Apps można włączyć przy użyciu Azure CLI lub Azure Portal.
Aby utworzyć usługę w Azure Spring Apps z włączoną nadmiarowością strefową przy użyciu Interfejsu Wiersza Polecenia platformy Azure, dołącz parametr --zone-redundant podczas tworzenia usługi, jak pokazano w poniższym przykładzie.
az spring create \
--resource-group <your-resource-group-name> \
--name <your-Azure-Spring-Apps-instance-name> \
--location <location> \
--zone-redundant true
Włączanie własnego zasobu z włączonymi strefami dostępności
Możesz włączyć własny zasób w usłudze Azure Spring Apps, na przykład własny magazyn trwały. Należy jednak upewnić się, że włączono nadmiarowość strefową dla zasobu. Aby uzyskać więcej informacji, zobacz Jak włączyć własny magazyn trwały w usłudze Azure Spring Apps.
Doświadczenie zmniejszania strefy
Gdy wystąpienie aplikacji zakończy się niepowodzeniem, ponieważ znajduje się w węźle maszyny wirtualnej w strefie awarii, usługa Azure Spring Apps tworzy nowe wystąpienie aplikacji dla aplikacji, która zakończyła się niepowodzeniem w innym węźle maszyny wirtualnej w innej strefie dostępności. W tym czasie użytkownicy mogą napotkać krótką przerwę. Nie jest wymagana żadna akcja użytkownika, a dotknięte wystąpienie usługi Azure Spring Apps zostanie przywrócone przez serwis.
Pricing
Nie ma dodatkowych kosztów związanych z włączaniem nadmiarowości stref. Musisz zapłacić jedynie za plan Standardowa lub Enterprise, który jest wymagany do włączenia nadmiarowości stref.
Odzyskiwanie po awarii między regionami i ciągłość działania
Odzyskiwanie po awarii (DR) odnosi się do praktyk używanych przez organizacje do odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Przed rozpoczęciem tworzenia planu odzyskiwania po awarii zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.
W przypadku DR firma Microsoft używa modelu wspólnej odpowiedzialności . W tym modelu firma Microsoft zapewnia dostępność podstawowej infrastruktury i usług platformy. Jednak wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego włączonego regionu. W przypadku tych usług odpowiadasz za skonfigurowanie planu odzyskiwania danych po awarii, który jest dostosowany do Twojego obciążenia. Większość usług oferty platformy Azure jako usługa (PaaS) udostępnia funkcje i wskazówki wspierające DR. Możesz użyć funkcji specyficznych dla usługi, aby wspierać szybkie odzyskiwanie i ułatwić opracowanie planu odzyskiwania po awarii.
Usługa Azure Spring Apps nie zapewnia odzyskiwania po awarii geograficznej, ale staranne planowanie może pomóc w ochronie przed przestojami.
Aby zapewnić wysoką dostępność i ochronę przed awariami, wdróż aplikacje hostowane w usłudze Azure Spring Apps w wielu regionach. Platforma Azure udostępnia listę sparowanych regionów , dzięki czemu można odpowiednio zaplanować wdrożenia aplikacji.
Podczas projektowania architektury należy wziąć pod uwagę następujące kluczowe czynniki:
- Dostępność w danym regionie. Aby zminimalizować opóźnienie sieci i czas transmisji, wybierz region obsługujący nadmiarowość strefową usługi Azure Spring Apps lub obszar geograficzny blisko użytkowników.
- Sparowane regiony platformy Azure. W celu zapewnienia skoordynowanych aktualizacji platformy i priorytetowych działań związanych z odzyskiwaniem w razie potrzeby wybierz sparowane regiony w wybranym obszarze geograficznym.
- Dostępność usługi. Zdecyduj, czy sparowane regiony powinny działać jako gorący/gorący, gorący/ciepły, czy gorący/zimny.
Kierowanie ruchem za pomocą usługi Azure Traffic Manager
Usługa Azure Traffic Manager zapewnia równoważenie obciążenia ruchu opartego na systemie DNS i może dystrybuować ruch sieciowy w wielu regionach. Usługa Azure Traffic Manager umożliwia kierowanie klientów do najbliższego wystąpienia usługi Azure Spring Apps. Aby uzyskać najlepszą wydajność i nadmiarowość, należy kierować cały ruch aplikacji za pośrednictwem usługi Azure Traffic Manager przed wysłaniem go do wystąpienia usługi Azure Spring Apps. Aby uzyskać więcej informacji, zobacz Co to jest usługa Traffic Manager?
Jeśli masz aplikacje w usłudze Azure Spring Apps działające w wielu regionach, usługa Azure Traffic Manager może kontrolować przepływ ruchu do aplikacji w każdym regionie. Zdefiniuj punkt końcowy usługi Azure Traffic Manager dla każdego wystąpienia usługi przy użyciu adresu IP wystąpienia. Należy połączyć się z nazwą DNS, która wskazuje na instancję usługi Azure Spring Apps w usłudze Azure Traffic Manager. Azure Traffic Manager równoważy obciążenie ruchu między zdefiniowanymi punktami końcowymi. W przypadku awarii centrum danych usługa Azure Traffic Manager kieruje ruch z tego regionu do pary, zapewniając ciągłość usługi.
Wykonaj następujące kroki, aby utworzyć wystąpienie usługi Azure Traffic Manager dla wystąpień usługi Azure Spring Apps:
Utwórz wystąpienia usługi Azure Spring Apps w dwóch różnych regionach. Na przykład utwórz instancje usług w Wschodnim USA i Zachodniej Europie, jak przedstawiono w poniższej tabeli. Każde wystąpienie służy jako podstawowy i awaryjny punkt końcowy dla ruchu.
Nazwa usługi Lokalizacja Aplikacja Service-próbka-a Wschodnie stany USA brama/usługa uwierzytelniania/ usługa konta przykład-usługi-b Europa Zachodnia brama/usługa uwierzytelniania/ usługa konta Skonfiguruj niestandardową domenę dla instancji usługi. Aby uzyskać więcej informacji, zobacz Samouczek: przypisanie istniejącej domeny niestandardowej do aplikacji Azure Spring Apps. Po pomyślnym skonfigurowaniu oba wystąpienia usługi będą powiązane z tą samą domeną niestandardową, taką jak
bcdr-test.contoso.com.Utwórz menedżera ruchu i dwa punkty końcowe. Aby uzyskać instrukcje, zobacz Szybki start: tworzenie profilu usługi Traffic Manager przy użyciu witryny Azure Portal, która tworzy następujący profil usługi Traffic Manager:
- Nazwa DNS usługi Traffic Manager:
http://asa-bcdr.trafficmanager.net - Profile punktów końcowych:
Profile Typ Target Priority Niestandardowe ustawienia nagłówka Profil punktu końcowego A Zewnętrzny punkt końcowy service-sample-a.azuremicroservices.io1 host: bcdr-test.contoso.comProfil punktu końcowego B Zewnętrzny punkt końcowy service-sample-b.azuremicroservices.io2 host: bcdr-test.contoso.com- Nazwa DNS usługi Traffic Manager:
Utwórz rekord CNAME w strefie DNS podobny do następującego przykładu:
bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net.
Środowisko jest teraz skonfigurowane. Jeśli użyto przykładowych wartości w połączonych artykułach, powinno być możliwe uzyskanie dostępu do aplikacji przy użyciu polecenia https://bcdr-test.contoso.com.
Użyj usługi Azure Front Door i usługi Azure Application Gateway do przekierowywania ruchu.
Usługa Azure Front Door to globalny, skalowalny punkt wejścia, który używa globalnej sieci brzegowej firmy Microsoft do tworzenia szybkich, bezpiecznych i szeroko skalowalnych aplikacji internetowych. Usługa Azure Front Door zapewnia taką samą nadmiarowość geograficzną i routing do najbliższego regionu, jak usługa Azure Traffic Manager. Usługa Azure Front Door udostępnia również zaawansowane funkcje, takie jak kończenie żądań protokołu TLS, przetwarzanie warstw aplikacji i zapora aplikacji internetowej (WAF). Aby uzyskać więcej informacji, zobacz Co to jest usługa Azure Front Door?
Na poniższym diagramie przedstawiono architekturę nadmiarowości umożliwiającej pracę w wielu regionach dla wystąpienia usługi Azure Spring Apps zintegrowanego z siecią wirtualną. Diagram przedstawia poprawną konfigurację zwrotnego serwera proxy dla usługi Application Gateway i usługi Front Door z domeną niestandardową. Ta architektura jest oparta na scenariuszu opisanym w temacie Uwidacznij aplikacje z kompleksowego protokołu TLS w sieci wirtualnej. To podejście łączy dwa wystąpienia iniekcji wirtualnej usługi Azure Spring Apps zintegrowane z usługą Application Gateway w wystąpienie geograficznie nadmiarowe.