Niezawodność w usłudze Azure Spring Apps

Artykuł
11/20/2024

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 każdym regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Aby uzyskać więcej informacji na temat stref dostępności na platformie Azure, zobacz Co to są strefy dostępności?.

Usługa Azure Spring Apps obsługuje nadmiarowość strefową. Po utworzeniu wystąpienia usługi Azure Spring Apps z włączoną nadmiarowością stref usługa Azure Spring Apps automatycznie dystrybuuje podstawowe zasoby między logiczne sekcje podstawowej infrastruktury platformy 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

Nadmiarowość 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
- Central US
- Azja Wschodnia
- East US
- Wschodnie stany USA 2
- Francja Środkowa
- Niemcy Środkowo-Zachodnie
- Europa Północna
- Japonia Wschodnia
- Korea Środkowa
- Północna Republika Południowej Afryki
- South Central US
- Southeast Asia
- Południowe Zjednoczone Królestwo
- West Europe
- Zachodnie stany USA 2
- Zachodnie stany USA 3

Tworzenie wystąpienia usługi Azure Spring Apps z włączonymi strefami dostępności

Uwaga

Nadmiarowość stref można włączyć tylko podczas tworzenia wystąpienia usługi Azure Spring Apps. Nie można zmienić właściwości nadmiarowości strefy po utworzeniu.

Nadmiarowość stref w usłudze Azure Spring Apps można włączyć przy użyciu interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal.

Interfejs wiersza polecenia platformy Azure
Witryna Azure Portal

Aby utworzyć usługę w usłudze Azure Spring Apps z włączoną nadmiarowością strefową przy użyciu interfejsu wiersza polecenia platformy Azure, dołącz --zone-redundant parametr 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.

Środowisko strefowe w dół

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 i wystąpienie usługi Azure Spring Apps, których dotyczy ten wpływ, zostanie przywrócone przez usługę.

Cennik

Nie ma dodatkowych kosztów związanych z włączaniem nadmiarowości stref. Musisz zapłacić tylko za plan w warstwie Standardowa lub Enterprise, który jest wymagany do włączenia nadmiarowości strefy.

Odzyskiwanie po awarii między regionami i ciągłość działania

Odzyskiwanie po awarii dotyczy 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. Zanim zaczniesz myśleć o tworzeniu planu odzyskiwania po awarii, zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.

Jeśli chodzi o odzyskiwanie po awarii, firma Microsoft korzysta z modelu wspólnej odpowiedzialności. W modelu wspólnej odpowiedzialności firma Microsoft zapewnia dostępność infrastruktury bazowej i usług platformy. Jednocześnie 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 regionu z włączoną obsługą. W przypadku tych usług ponosisz odpowiedzialność za skonfigurowanie planu odzyskiwania po awarii, który działa dla obciążenia. Większość usług uruchamianych na platformie Azure jako usługa (PaaS) oferuje funkcje i wskazówki dotyczące obsługi odzyskiwania po awarii. Funkcje specyficzne dla usługi umożliwiają szybkie odzyskiwanie w celu ułatwienia opracowania 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ć gorąca/gorąca, gorąca/ciepła, czy gorąca/zimna.

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 nawiązać połączenie z nazwą DNS usługi Azure Traffic Manager wskazującą wystąpienie usługi Azure Spring Apps. Obciążenie usługi Azure Traffic Manager równoważy ruch 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 wystąpienia usługi w regionach Wschodnie stany USA i Europa Zachodnia, jak pokazano w poniższej tabeli. Każde wystąpienie służy jako podstawowy i punkt końcowy trybu failover dla ruchu.

Service name	Lokalizacja	Aplikacja
service-sample-a	Wschodnie stany USA	brama/usługa uwierzytelniania/ usługa konta
service-sample-b	West Europe	brama/usługa uwierzytelniania/ usługa konta

Skonfiguruj domenę niestandardową dla wystąpień usługi. Aby uzyskać więcej informacji, zobacz Samouczek: mapowania istniejącej domeny niestandardowej na usługę 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 usługę Traffic Manager 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:

Profil	Typ	Obiekt docelowy	Priorytet	Ustawienia nagłówka niestandardowego
Profil punktu końcowego A	Zewnętrzny punkt końcowy	`service-sample-a.azuremicroservices.io`	1	`host: bcdr-test.contoso.com`
Profil punktu końcowego B	Zewnętrzny punkt końcowy	`service-sample-b.azuremicroservices.io`	2	`host: bcdr-test.contoso.com`

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.

Kierowanie ruchem za pomocą usługi Azure Front Door i usługi aplikacja systemu Azure Gateway

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 tę samą nadmiarowość z wieloma obszarami geograficznymi i routing do najbliższego regionu co 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 w wielu regionach zintegrowanego z siecią wirtualną wystąpienia usługi Azure Spring Apps. 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.

Udostępnij za pośrednictwem