Niezawodność w usłudze aplikacja systemu Azure

  • Artykuł

W tym artykule opisano obsługę niezawodności w usłudze aplikacja systemu Azure oraz omówiono odporność wewnątrz regionalną ze strefamidostępności oraz odzyskiwaniem po awarii między regionami i ciągłością działalności biznesowej. Aby uzyskać bardziej szczegółowe omówienie zasad niezawodności na platformie Azure, zobacz Niezawodność platformy Azure.

aplikacja systemu Azure Service to usługa oparta na protokole HTTP do hostowania aplikacji internetowych, interfejsów API REST i zapleczy dla urządzeń przenośnych oraz dodaje możliwości platformy Microsoft Azure do aplikacji, takie jak:

  • Zabezpieczenia
  • Równoważenie obciążenia
  • Skalowanie automatyczne
  • Zautomatyzowane zarządzanie

Aby dowiedzieć się, jak usługa aplikacja systemu Azure może zwiększyć niezawodność i odporność obciążenia aplikacji, zobacz Dlaczego warto używać usługi App Service?

Zalecenia dotyczące niezawodności

Ta sekcja zawiera zalecenia dotyczące uzyskiwania odporności i dostępności. Każde zalecenie należy do jednej z dwóch kategorii:

  • Elementy kondycji obejmują obszary, takie jak elementy konfiguracji i właściwa funkcja głównych składników tworzących obciążenie platformy Azure, takie jak ustawienia konfiguracji zasobów platformy Azure, zależności od innych usług itd.

  • Elementy ryzyka obejmują obszary, takie jak wymagania dotyczące dostępności i odzyskiwania, testowanie, monitorowanie, wdrażanie i inne elementy, które, jeśli nie zostały rozwiązane, zwiększają szanse na problemy w środowisku.

Macierz priorytetów zaleceń dotyczących niezawodności

Każde zalecenie jest oznaczone zgodnie z następującą macierzą priorytetów:

Obraz Priorytet opis
Wys. Wymagana jest natychmiastowa poprawka.
Śred. Poprawka w ciągu 3–6 miesięcy.
Niski Należy przejrzeć.

Podsumowanie zaleceń dotyczących niezawodności

Kategoria Priorytet Zalecenie
Wysoka dostępność ASP-1 — wdrażanie strefowo nadmiarowych planów usługi App Service
Odporność ASP-2 — Używanie planu usługi App Service obsługującego strefy dostępności
ASP-4 — tworzenie oddzielnych planów usługi App Service dla środowiska produkcyjnego i testowania
Skalowalność ASP-3 — unikaj częstego skalowania w górę lub w dół
ASP-5 — włączanie automatycznego skalowania/automatycznego skalowania w celu zapewnienia, że odpowiednie zasoby są dostępne dla żądań obsługi

Wysoka dostępność

ASP-1 — wdrażanie strefowo nadmiarowych planów usługi App Service

Aby zwiększyć odporność i niezawodność obciążeń krytycznych dla działania firmy, zaleca się wdrożenie nowych planów usługi App Service z nadmiarowością strefową. Wykonaj kroki, aby ponownie wdrożyć obsługę stref dostępności, skonfigurować potoki do ponownego wdrożenia aplikacji internetowej w nowym planie usług App Services, a następnie użyć podejścia wdrażania Blue-Green w celu przejścia w tryb failover do nowej lokacji.

Dystrybuując aplikacje w wielu strefach dostępności, można zapewnić ciągłą operację nawet w przypadku awarii na poziomie centrum danych. Aby uzyskać więcej informacji na temat obsługi stref dostępności w usłudze aplikacja systemu Azure, zobacz Obsługa stref dostępności.

// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
// Its important to check regions that support availability zones for Azure App Services running on multi-tenant and App Service Environments https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service?tabs=graph%2Ccli#:~:text=The%20following%20regions%20support%20Azure%20App%20Services%20running%20on%20multi%2Dtenant%20environments%3A

resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where (tolower(sku_tier) contains "isolated" or tolower(sku_tier) contains "premium") and zoneRedundant == false
| project recommendationid="asp-1", name, id, tags, param1=sku_tier, param2="Not Zone Redundant"

Odporność

ASP-2 — Używanie planu usługi App Service obsługującego strefy dostępności

Obsługa stref dostępności jest dostępna tylko w niektórych planach usługi App Service. Aby sprawdzić, który plan jest potrzebny do korzystania ze stref dostępności, zobacz Wymagania wstępne dotyczące strefy dostępności.

// Azure Resource Graph Query
// Provides a list of Azure App Service Plans that are not in the "Standard", "Premium", or "IsolatedV2" SKU tiers.

resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where tolower(sku_tier) !contains "standard" and
        tolower(sku_tier) !contains "premium" and
        tolower(sku_tier) !contains "isolatedv2"
| project recommendationid="asp-2", name, id, tags, param1= strcat("SKU=",sku_tier)

ASP-4 — tworzenie oddzielnych planów usługi App Service dla środowiska produkcyjnego i testowania

Aby zwiększyć odporność i niezawodność obciążeń krytycznych dla działania firmy, należy przeprowadzić migrację istniejących planów usługi App Service i środowisk App Service Environment do obsługi stref dostępności. Dystrybuując aplikacje w wielu strefach dostępności, można zapewnić ciągłą operację nawet w przypadku awarii na poziomie centrum danych. Aby uzyskać więcej informacji na temat obsługi stref dostępności w usłudze aplikacja systemu Azure, zobacz Obsługa stref dostępności.

Skalowalność

ASP-3 — unikaj częstego skalowania w górę lub w dół

Zaleca się unikanie częstego skalowania w górę lub w dół wystąpień usługi aplikacja systemu Azure Service. Zamiast tego wybierz odpowiednią warstwę i rozmiar wystąpienia, który może obsługiwać typowe obciążenie, i skaluj wystąpienia w poziomie, aby uwzględnić zmiany w woluminie ruchu. Skalowanie w górę lub w dół może potencjalnie wyzwolić ponowne uruchomienie aplikacji, co może spowodować zakłócenia usługi.

ASP-5 — włączanie automatycznego skalowania/automatycznego skalowania w celu zapewnienia, że odpowiednie zasoby są dostępne dla żądań obsługi

Zaleca się włączenie automatycznego skalowania/automatycznego skalowania dla usługi aplikacja systemu Azure, aby upewnić się, że wystarczające zasoby są dostępne do obsługi żądań przychodzących. Skalowanie automatyczne jest skalowaniem opartym na regułach, a automatyczne skalowanie wykonuje automatyczne skalowanie w i na podstawie ruchu HTTP. Aby uzyskać więcej informacji, zobacz automatyczne skalowanie w usłudze aplikacja systemu Azure lub rozpoczynanie pracy z autoskalowaniem na platformie Azure.

// under-development

Obsługa strefy dostępności

Strefy dostępności platformy Azure to co najmniej trzy fizycznie oddzielne grupy centrów danych w każdym regionie świadczenia usługi Azure. Centra danych w każdej strefie są wyposażone w niezależną infrastrukturę zasilania, chłodzenia i sieci. W przypadku awarii strefy lokalnej strefy strefy dostępności są zaprojektowane tak, aby w przypadku wystąpienia problemu z jedną strefą usługi regionalne, pojemność i wysoka dostępność są obsługiwane przez pozostałe dwie strefy.

Awarie mogą wahać się od awarii oprogramowania i sprzętu po zdarzenia, takie jak trzęsienia ziemi, powodzie i pożary. Tolerancja awarii jest osiągana z nadmiarowością i logiczną izolacją usług platformy Azure. Aby uzyskać bardziej szczegółowe informacje na temat stref dostępności na platformie Azure, zobacz Regiony i strefy dostępności.

Usługi z obsługą stref dostępności platformy Azure zostały zaprojektowane w celu zapewnienia odpowiedniego poziomu niezawodności i elastyczności. Można je skonfigurować na dwa sposoby. Mogą być strefowo nadmiarowe, z automatyczną replikacją między strefami lub strefami, z wystąpieniami przypiętymi do określonej strefy. Możesz również połączyć te podejścia. Aby uzyskać więcej informacji na temat architektury strefowej i strefowo nadmiarowej, zobacz Rekomendacje na potrzeby korzystania ze stref dostępności i regionów.

aplikacja systemu Azure Usługę można wdrożyć w strefach dostępności (AZ), aby ułatwić osiągnięcie odporności i niezawodności obciążeń o znaczeniu krytycznym dla działania firmy. Ta architektura jest również nazywana nadmiarowością stref.

Podczas konfigurowania usługi App Service jako strefowo nadmiarowej platforma automatycznie rozkłada wystąpienia planu usługi aplikacja systemu Azure w trzech strefach w wybranym regionie.

Wystąpienie rozłożone przy użyciu wdrożenia strefowo nadmiarowego jest określane wewnątrz następujących reguł, nawet gdy aplikacja jest skalowana w poziomie i w poziomie:

  • Minimalna liczba wystąpień planu usługi App Service to trzy.
  • Jeśli określisz pojemność większą niż trzy, a liczba wystąpień jest podzielna przez trzy, wystąpienia są rozłożone równomiernie.
  • Wszystkie liczby wystąpień przekraczające 3*N są rozłożone w pozostałych strefach.

Obsługa strefy dostępności jest właściwością planu usługi App Service. Plany usługi App Service można tworzyć w zarządzanym środowisku wielodostępnym lub w dedykowanym środowisku przy użyciu środowiska App Service Environment w wersji 3. Aby dowiedzieć się więcej na temat środowiska App Service Environment w wersji 3, zobacz Omówienie środowiska App Service Environment w wersji 3.

W przypadku usług App Services, które nie są skonfigurowane jako strefowo nadmiarowe, wystąpienia maszyn wirtualnych nie są odporne na strefy i mogą wystąpić przestoje podczas przestoju w dowolnej strefie w tym regionie.

Aby uzyskać informacje na temat architektury wdrażania w przedsiębiorstwie, zobacz Wdrażanie w przedsiębiorstwie o wysokiej dostępności przy użyciu środowiska App Service Environment.

Wymagania wstępne

Bieżące wymagania/ograniczenia dotyczące włączania stref dostępności to:

  • Obsługiwane są systemy Windows i Linux.

  • Strefy dostępności są obsługiwane tylko w nowszych miejscach usługi App Service. Nawet jeśli używasz jednego z obsługiwanych regionów, zostanie wyświetlony błąd, jeśli strefy dostępności nie są obsługiwane dla grupy zasobów. Aby upewnić się, że obciążenia wylądowały na sygnaturze obsługującej strefy dostępności, może być konieczne utworzenie nowej grupy zasobów, planu usługi App Service i usługi App Service.

  • Plan usług App Services musi być jednym z następujących planów, które obsługują strefy dostępności:

    • W środowisku wielodostępnym korzystającym z planów Usługi App Service Premium w wersji 2 lub Premium w wersji 3.
    • W dedykowanym środowisku korzystającym ze środowiska App Service Environment w wersji 3, który jest używany z planami izolowanej usługi App Service w wersji 2.

  • W przypadku środowisk dedykowanych środowisko App Service Environment musi być w wersji 3.

    Ważne

    Środowisko App Service Environment w wersji 2 i v1 zostanie wycofane 31 sierpnia 2024 r. Środowisko App Service Environment w wersji 3 jest łatwiejsze do użycia i działa w bardziej wydajnej infrastrukturze. Aby dowiedzieć się więcej na temat środowiska App Service Environment w wersji 3, zobacz Omówienie środowiska App Service Environment. Jeśli obecnie używasz środowiska App Service Environment w wersji 2 lub 1 i chcesz przeprowadzić uaktualnienie do wersji 3, wykonaj kroki opisane w tym artykule , aby przeprowadzić migrację do nowej wersji.

  • Minimalna liczba wystąpień trzech stref jest wymuszana. Platforma będzie wymuszać tę minimalną liczbę w tle, jeśli określisz liczbę wystąpień mniej niż trzy.

  • Strefy dostępności można określić tylko podczas tworzenia nowego planu usługi App Service. Nie można przekonwertować istniejącego planu usługi App Service na strefy dostępności.

  • Następujące regiony obsługują usługi aplikacja systemu Azure działające w środowiskach wielodostępnych:

    • Australia Wschodnia
    • Brazylia Południowa
    • Kanada Środkowa
    • Indie Środkowe
    • Central US
    • Azja Wschodnia
    • East US
    • Wschodnie stany USA 2
    • Francja Środkowa
    • Niemcy Środkowo-Zachodnie
    • Japonia Wschodnia
    • Korea Środkowa
    • Europa Północna
    • Norwegia Wschodnia
    • Polska Środkowa
    • Katar Środkowy
    • Północna Republika Południowej Afryki
    • South Central US
    • Southeast Asia
    • Szwecja Środkowa
    • Szwajcaria Północna
    • Północne Zjednoczone Emiraty Arabskie
    • Południowe Zjednoczone Królestwo
    • West Europe
    • Zachodnie stany USA 2
    • Zachodnie stany USA 3
    • Platforma Microsoft Azure obsługiwana przez firmę 21Vianet — Chiny Północne 3
    • Azure Government — US Gov Virginia

  • Aby zobaczyć, które regiony obsługują strefy dostępności dla środowiska App Service Environment w wersji 3, zobacz Regiony.

Tworzenie zasobu z włączoną strefą dostępności

Aby wdrożyć usługę App Service strefowo nadmiarową z wieloma dzierżawami

Aby włączyć strefy dostępności przy użyciu interfejsu wiersza polecenia platformy Azure, dołącz --zone-redundant parametr podczas tworzenia planu usługi App Service. Można również uwzględnić parametr w --number-of-workers celu określenia pojemności. Jeśli nie określisz pojemności, platforma zostanie domyślnie ustawiona na trzy. Pojemność powinna być ustawiana na podstawie wymagania dotyczącego obciążenia, ale nie mniej niż trzy. Dobrą regułą wyboru pojemności jest zapewnienie wystarczającej liczby wystąpień dla aplikacji, tak aby utrata jednej strefy wystąpień pozostawiała wystarczającą pojemność do obsługi oczekiwanego obciążenia.

az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6

Napiwek

Aby zdecydować o pojemności wystąpienia, można użyć następującego obliczenia:

Ponieważ platforma rozprzestrzenia maszyny wirtualne w trzech strefach i musisz uwzględnić co najmniej awarię jednej strefy, pomnożyć liczbę wystąpień szczytowych obciążeń przez współczynnik stref/(strefy-1) lub 3/2. Jeśli na przykład typowe szczytowe obciążenie wymaga czterech wystąpień, należy aprowizować sześć wystąpień: (2/3 * 6 wystąpień) = 4 wystąpienia.

Wdrażanie strefowo nadmiarowej usługi App Service przy użyciu dedykowanego środowiska

Aby dowiedzieć się, jak utworzyć środowisko App Service Environment w wersji 3 w planie izolowanym w wersji 2, zobacz Tworzenie środowiska App Service Environment.

Rozwiązywanie problemów

Komunikat o błędzie opis Zalecenie
Nadmiarowość strefy nie jest dostępna dla grupy zasobów "RG-NAME". Wdróż plan usługi App Service "ASP-NAME" w nowej grupie zasobów. Strefy dostępności są obsługiwane tylko w nowszych miejscach usługi App Service. Nawet jeśli używasz jednego z obsługiwanych regionów, zostanie wyświetlony błąd, jeśli strefy dostępności nie są obsługiwane dla grupy zasobów. Aby upewnić się, że obciążenia wylądowały na sygnaturze obsługującej strefy dostępności, utwórz nową grupę zasobów, plan usługi App Service i usługę App Service.

Odporność na uszkodzenia

Aby przygotować się do awarii strefy dostępności, należy nadmiernie aprowizować pojemność usługi, aby upewnić się, że rozwiązanie może tolerować utratę pojemności 1/3 i nadal działać bez obniżonej wydajności podczas awarii całego obszaru strefy. Ponieważ platforma rozprzestrzenia maszyny wirtualne w trzech strefach i musisz uwzględnić co najmniej awarię jednej strefy, pomnożyć liczbę wystąpień szczytowych obciążeń przez współczynnik stref/(strefy-1) lub 3/2. Jeśli na przykład typowe szczytowe obciążenie wymaga czterech wystąpień, należy aprowizować sześć wystąpień: (2/3 * 6 wystąpień) = 4 wystąpienia.

Środowisko strefowe w dół

Ruch jest kierowany do wszystkich dostępnych wystąpień usługi App Service. W przypadku awarii strefy platforma App Service wykryje utracone wystąpienia i automatycznie podejmie próbę znalezienia nowych wystąpień zastępczych i rozłożenia ruchu zgodnie z potrzebami. Jeśli skonfigurowano automatyczne skalowanie , a jeśli zdecydujesz, że potrzebne jest więcej wystąpień, skalowanie automatyczne będzie również wysyłać żądanie do usługi App Service w celu dodania większej liczby wystąpień. Należy pamiętać, że zachowanie autoskalowania jest niezależne od zachowania platformy usługi App Service i że specyfikacja liczby wystąpień autoskalowania nie musi być wielokrotna z trzech.

Uwaga

Nie ma gwarancji, że żądania dotyczące dodatkowych wystąpień w scenariuszu strefowo w dół zostaną wykonane pomyślnie. Wypełnienie wsteczne utraconych wystąpień odbywa się na zasadzie najlepszego nakładu pracy. Zalecanym rozwiązaniem jest utworzenie i skonfigurowanie planów usługi App Service w celu utraty strefy zgodnie z opisem w następnej sekcji.

Aplikacje wdrożone w planie usługi App Service z włączonymi strefami dostępności będą nadal działać i obsługiwać ruch, nawet jeśli w tym samym regionie wystąpi awaria innych stref. Jednak istnieje możliwość, że zachowania inne niż środowisko uruchomieniowe, w tym skalowanie planu usługi App Service, tworzenie aplikacji, konfiguracja aplikacji i publikowanie aplikacji mogą nadal mieć wpływ na awarię w innych Strefy dostępności. Nadmiarowość strefowa dla planów usługi App Service zapewnia tylko stały czas pracy wdrożonych aplikacji.

Gdy platforma App Service przydziela wystąpienia do strefowo nadmiarowego planu usługi App Service, używa najlepszego równoważenia nakładu pracy oferowanego przez bazowe zestawy skalowania maszyn wirtualnych platformy Azure. Plan usługi App Service będzie "zrównoważony", jeśli każda strefa ma taką samą liczbę maszyn wirtualnych lub +/- jedną maszynę wirtualną we wszystkich pozostałych strefach używanych przez plan usługi App Service.

Migracja strefy dostępności

Nie można migrować istniejących wystąpień usługi App Service ani zasobów środowiska z obsługi stref niedostępnych do obsługi stref dostępności. Aby uzyskać obsługę stref dostępności, należy utworzyć zasoby z włączonymi strefami dostępności.

Cennik

Nie ma dodatkowych kosztów związanych z włączaniem stref dostępności. Ceny strefowo nadmiarowej usługi App Service są takie same jak usługa App Service w pojedynczej strefie. Opłaty będą naliczane na podstawie jednostki SKU planu usługi App Service, określonej pojemności i wszelkich wystąpień skalowanych na podstawie kryteriów autoskalowania. Jeśli włączysz strefy dostępności, ale określisz pojemność mniejszą niż trzy, platforma będzie wymuszać minimalną liczbę wystąpień wynoszącą trzy i pobierać opłaty za te trzy wystąpienia. Aby uzyskać informacje o cenach środowiska App Service Environment w wersji 3, zobacz Cennik.

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 Rekomendacje na potrzeby 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.

W tej sekcji opisano niektóre typowe strategie dotyczące aplikacji internetowych wdrożonych w usłudze App Service.

Podczas tworzenia aplikacji internetowej w usłudze App Service i wybierania regionu świadczenia usługi Azure podczas tworzenia zasobów jest to aplikacja z jednym regionem. Gdy region stanie się niedostępny podczas awarii, aplikacja stanie się również niedostępna. Jeśli utworzysz identyczne wdrożenie w regionie pomocniczym platformy Azure przy użyciu architektury geograficznej z wieloma regionami, aplikacja stanie się mniej podatna na awarię w jednym regionie, co gwarantuje ciągłość działania. Każda replikacja danych w regionach umożliwia odzyskanie ostatniego stanu aplikacji.

W przypadku it plany ciągłości działania są w dużej mierze oparte na celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO). Aby uzyskać więcej informacji na temat celu odzyskiwania i celu punktu odzyskiwania, zobacz Cele odzyskiwania.

Zwykle utrzymanie umowy SLA wokół celu punktu odzyskiwania jest niepraktyczne w przypadku regionalnych awarii i zazwyczaj należy zaprojektować strategię odzyskiwania po awarii wokół samego celu punktu odzyskiwania (tj. skupić się na odzyskiwaniu danych, a nie na zminimalizowaniu przerw). Jednak dzięki platformie Azure nie tylko jest to praktyczne, ale nawet proste wdrożenie usługi App Service na potrzeby automatycznych trybów failover geograficznych. Dzięki temu aplikacje mogą być jeszcze bardziej odporne na awarie, dbając zarówno o cel czasu odzyskiwania, jak i cel punktu odzyskiwania.

W zależności od żądanych metryk celu punktu odzyskiwania i celu punktu odzyskiwania po awarii trzy architektury odzyskiwania po awarii są często używane zarówno w środowiskach wielodostępnych usługi App Service, jak i środowiskach App Service Environment. Każda architektura jest opisana w poniższej tabeli:

Metric Aktywne-aktywne Aktywny-pasywny Pasywne/zimne
RTO Czas rzeczywisty lub sekundy Minuty godzin(y)
RPO Czas rzeczywisty lub sekundy Minuty godzin(y)
Koszt $$$ $$ $
Scenariusze Aplikacje o znaczeniu krytycznym Aplikacje o wysokim priorytcie Aplikacje o niskim priorytcie
Możliwość obsługi ruchu użytkowników w wielu regionach Tak Tak/być może Nie.
Wdrażanie kodu Preferowane potoki ciągłej integracji/ciągłego wdrażania Preferowane potoki ciągłej integracji/ciągłego wdrażania Tworzenie kopii zapasowej i przywracanie
Tworzenie nowych zasobów usługi App Service podczas przestojów Niewymagane Niewymagane Wymagania

Uwaga

Aplikacja najprawdopodobniej zależy od innych usług danych na platformie Azure, takich jak konta usługi Azure SQL Database i Azure Storage. Zaleca się również opracowanie strategii odzyskiwania po awarii dla każdej z tych zależnych usług platformy Azure. W przypadku usługi SQL Database zobacz Temat Aktywna replikacja geograficzna dla usługi Azure SQL Database. W przypadku usługi Azure Storage zobacz Nadmiarowość usługi Azure Storage.

Odzyskiwanie po awarii w lokalizacji geograficznej obejmującej wiele regionów

Istnieje wiele sposobów replikowania zawartości i konfiguracji aplikacji internetowych w regionach platformy Azure w architekturze aktywne-aktywne lub aktywne-pasywne, na przykład przy użyciu kopii zapasowej i przywracania usługi App Service. Jednak tworzenie i przywracanie kopii zapasowych tworzy migawki do punktu w czasie i ostatecznie prowadzi do wyzwań związanych z przechowywaniem wersji aplikacji internetowej w różnych regionach. Poniższa tabela zawiera porównanie wskazówek dotyczących przywracania i przywracania w porównaniu ze wskazówkami dotyczącymi odzyskiwania diaster:

Tworzenie kopii zapasowej i przywracanie w porównaniu z odzyskiwaniem po awarii

Platforma Wskazówki dotyczące tworzenia kopii zapasowych i przywracania Wskazówki dotyczące odzyskiwania po awarii
App Service Web Apps
(Bezpłatna i współdzielona warstwa cenowa)		 Jeśli masz aplikacje internetowe wdrożone w warstwie Bezpłatna lub Współdzielona i wymagają dostępu do możliwości tworzenia kopii zapasowych i przywracania dla tych aplikacji internetowych, przeprowadź skalowanie w górę do warstwy Podstawowa lub nowsza. Przełącz zasoby usługi App Service z powrotem do trybu online w innym regionie świadczenia usługi Azure podczas regionalnej awarii.

Od 31 marca 2025 r. aplikacje usługi App Service nie będą umieszczane w trybie odzyskiwania po awarii w regionie świadczenia usługi Azure, jak wyjaśniono w artykule odzyskiwanie po awarii w całym regionie. Zaleca się zaimplementowanie powszechnie używanych technik odzyskiwania po awarii, aby zapobiec przestojom i utracie danych podczas regionalnej awarii.
App Service Web Apps
(Warstwa cenowa Podstawowa\Standardowa\Premium)		 W usłudze aplikacja systemu Azure możesz tworzyć niestandardowe kopie zapasowe na żądanie lub korzystać z automatycznych kopii zapasowych. Możesz przywrócić kopię zapasową, zastępując istniejącą aplikację, przywracając do nowej aplikacji lub miejsca.

Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowej i przywracanie aplikacji w usłudze aplikacja systemu Azure Service.		 Bieżące wskazówki dotyczące przenoszenia zasobów usługi App Service z powrotem do trybu online w innym regionie świadczenia usługi Azure podczas regionalnej awarii są dostępne w artykule Odzyskiwanie po awarii całego regionu — aplikacja systemu Azure Service.

Od 31 marca 2025 r. aplikacje internetowe usługi aplikacja systemu Azure Nie będą już umieszczane w trybie odzyskiwania po awarii w regionie świadczenia usługi Azure, jak wyjaśniono w artykule odzyskiwania po awarii całego regionu. Zachęcamy do zaimplementowania powszechnie używanych technik odzyskiwania po awarii, aby zapobiec utracie funkcji lub danych dla aplikacji internetowych, jeśli wystąpi awaria regionalna.
App Service Environment (wersja 2 i wersja 3) W środowisku usługi aplikacja systemu Azure możesz tworzyć niestandardowe kopie zapasowe na żądanie lub korzystać z automatycznych kopii zapasowych. Automatyczne kopie zapasowe można przywrócić do aplikacji docelowej w ramach tego samego środowiska ASE, a nie w innym środowisku ASE. Niestandardowe kopie zapasowe można przywrócić do aplikacji docelowej w innym środowisku ASE (na przykład z środowiska ASE w wersji 2 do środowiska ASE w wersji 3). Kopie zapasowe można przywrócić do aplikacji docelowej tej samej platformy systemu operacyjnego co aplikacja źródłowa.

Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowej i przywracanie aplikacji w usłudze aplikacja systemu Azure Service.		 Zachęcamy do zaimplementowania wskazówek dotyczących odzyskiwania po awarii dla aplikacji internetowych wdrożonych w środowisku App Service Environment przy użyciu powszechnie używanych technik odzyskiwania po awarii.
Azure Functions (dedykowane) W usłudze Azure Functions można tworzyć niestandardowe kopie zapasowe na żądanie lub korzystać z automatycznych kopii zapasowych. Możesz przywrócić kopię zapasową, zastępując istniejącą aplikację, przywracając do nowej aplikacji lub miejsca.

Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowej i przywracanie aplikacji w usłudze aplikacja systemu Azure Service.		 Bieżące wskazówki dotyczące przenoszenia zasobów aplikacji usługi Azure Functions (dedykowanych) z powrotem do trybu online w innym regionie świadczenia usługi Azure podczas awarii regionalnej są dostępne w artykule Odzyskiwanie po awarii całego regionu — aplikacja systemu Azure Service.

Od 31 marca 2025 r. aplikacje usługi App Service nie będą umieszczane w trybie odzyskiwania po awarii w regionie świadczenia usługi Azure, jak wyjaśniono w artykule odzyskiwanie po awarii w całym regionie. Zamiast tego zaimplementuj odzyskiwanie po awarii geograficznej usługi Azure Functions.

Ponadto można również zapoznać się z często używanymi technikami odzyskiwania po awarii dla usługi Azure Functions w wersji dedykowanej.
Użycie usługi Azure Functions i wersja Premium Funkcje platformy Azure wdrożone w planach użycia i warstwy Premium nie zapewniają dostępu do niestandardowych i automatycznych kopii zapasowych. Zawartość aplikacji funkcji znajduje się na koncie usługi Azure Storage. Użyj opcji nadmiarowości usługi Azure Storage, aby upewnić się, że konto magazynu spełnia cele dotyczące dostępności i trwałości podczas awarii.

Jeśli funkcje zostały utworzone przy użyciu edytora w witrynie Azure Portal, możesz również pobrać istniejący projekt aplikacji funkcji jako plik .zip.		 Zdecydowanie zachęcamy do zaimplementowania odzyskiwania po awarii geograficznej i niezawodności usługi Azure Functions.

Aby uniknąć ograniczeń metod tworzenia kopii zapasowych i przywracania, skonfiguruj potoki ciągłej integracji/ciągłego wdrażania, aby wdrożyć kod w obu regionach świadczenia usługi Azure. Rozważ użycie usługi Azure Pipelines lub GitHub Actions. Aby uzyskać więcej informacji, zobacz Ciągłe wdrażanie w usłudze aplikacja systemu Azure Service.

Wykrywanie, powiadamianie i zarządzanie awariami

  • Zaleca się skonfigurowanie monitorowania i alertów dla aplikacji internetowych w celu zapewnienia terminowych powiadomień podczas awarii. Aby uzyskać więcej informacji, zobacz Application Szczegółowe informacje availability tests (Testy dostępności Szczegółowe informacje aplikacji).

  • Aby zarządzać zasobami aplikacji na platformie Azure, użyj mechanizmu infrastruktury jako kodu (IaC). W złożonym wdrożeniu w wielu regionach zarządzanie regionami niezależnie i zachowanie synchronizacji konfiguracji między regionami w niezawodny sposób wymaga przewidywalnego, testowalnego i powtarzalnego procesu. Rozważ użycie narzędzia IaC, takiego jak szablony usługi Azure Resource Manager lub narzędzie Terraform.

Konfigurowanie odzyskiwania po awarii i wykrywania awarii

Aby przygotować się do odzyskiwania po awarii w lokalizacji geograficznej obejmującej wiele regionów, możesz użyć architektury aktywne-aktywne lub aktywne-pasywne.

Architektura Active-Active

W architekturze odzyskiwania po awarii aktywne-aktywne identyczne aplikacje internetowe są wdrażane w dwóch oddzielnych regionach, a usługa Azure Front door służy do kierowania ruchu do obu aktywnych regionów.

Diagram przedstawiający aktywne-aktywne wdrożenie usługi App Service.

W przypadku tej przykładowej architektury:

  • Identyczne aplikacje usługi App Service są wdrażane w dwóch oddzielnych regionach, w tym w warstwie cenowej i liczbie wystąpień.
  • Ruch publiczny bezpośrednio do aplikacji usługi App Service jest blokowany.
  • Usługa Azure Front Door służy do kierowania ruchu do obu aktywnych regionów.
  • Podczas awarii jeden z regionów staje się w trybie offline, a usługa Azure Front Door kieruje ruch wyłącznie do regionu, który pozostaje w trybie online. Cel czasu odzyskiwania podczas takiego geograficznego przejścia w tryb failover jest zbliżony do zera.
  • Pliki aplikacji powinny być wdrażane w obu aplikacjach internetowych z rozwiązaniem ciągłej integracji/ciągłego wdrażania. Gwarantuje to, że cel punktu odzyskiwania jest praktycznie zerowy.
  • Jeśli aplikacja aktywnie modyfikuje system plików, najlepszym sposobem zminimalizowania celu punktu odzyskiwania jest zapisywanie tylko w zainstalowanym udziale usługi Azure Storage zamiast zapisywania bezpośrednio w udziale zawartości /home aplikacji internetowej. Następnie użyj funkcji nadmiarowości usługi Azure Storage (GZRS lub GRS) dla zainstalowanego udziału, który ma cel punktu odzyskiwania około 15 minut.

Kroki tworzenia architektury aktywne-aktywne dla aplikacji internetowej w usłudze App Service zostały podsumowane w następujący sposób:

  1. Utwórz dwa plany usługi App Service w dwóch różnych regionach świadczenia usługi Azure. Skonfiguruj dwa plany usługi App Service identycznie.

  2. Utwórz dwa wystąpienia aplikacji internetowej z jednym w każdym planie usługi App Service.

  3. Utwórz profil usługi Azure Front Door przy użyciu:

    • Punkt końcowy.
    • Dwie grupy pochodzenia, z których każdy ma priorytet 1. Równy priorytet nakazuje usłudze Azure Front Door kierowanie ruchu do obu regionów w równym stopniu (w ten sposób aktywny-aktywny).
    • Trasa.

  4. Ogranicz ruch sieciowy do aplikacji internetowych tylko z wystąpienia usługi Azure Front Door.

  5. Skonfiguruj i skonfiguruj wszystkie inne usługi platformy Azure zaplecza, takie jak bazy danych, konta magazynu i dostawcy uwierzytelniania.

  6. Wdrażanie kodu w obu aplikacjach internetowych przy użyciu ciągłego wdrażania.

Samouczek: tworzenie aplikacji z wieloma regionami o wysokiej dostępności w usłudze aplikacja systemu Azure pokazuje, jak skonfigurować architekturę aktywne-pasywne. Te same kroki z minimalnymi zmianami (ustawienie priorytetu "1" dla obu źródeł w grupie pochodzenia w usłudze Azure Front Door) daje architekturę aktywne-aktywne.

Architektura aktywne-pasywne

W tym podejściu do odzyskiwania po awarii identyczne aplikacje internetowe są wdrażane w dwóch oddzielnych regionach, a usługa Azure Front door służy do kierowania ruchu tylko do jednego regionu ( aktywny region).

Diagram przedstawiający architekturę aktywne-pasywne usługi aplikacja systemu Azure Service.

W przypadku tej przykładowej architektury:

  • Identyczne aplikacje usługi App Service są wdrażane w dwóch oddzielnych regionach.

  • Ruch publiczny bezpośrednio do aplikacji usługi App Service jest blokowany.

  • Usługa Azure Front Door służy do kierowania ruchu do regionu podstawowego.

  • Aby zaoszczędzić koszt, pomocniczy plan usługi App Service jest skonfigurowany tak, aby miał mniej wystąpień i/lub znajduje się w niższej warstwie cenowej. Istnieją trzy możliwe podejścia:

    • Preferowany pomocniczy plan usługi App Service ma tę samą warstwę cenową co podstawowa, z taką samą liczbą wystąpień lub mniej. Takie podejście zapewnia parzystość zarówno w przypadku rozmiaru funkcji, jak i maszyny wirtualnej dla dwóch planów usługi App Service. Cel czasu odzyskiwania podczas przechodzenia w tryb failover geograficznie zależy tylko od czasu skalowania wystąpień w poziomie.

    • Mniej preferowane Pomocniczy plan usługi App Service ma ten sam typ warstwy cenowej (np. PremiumV3), ale mniejszy rozmiar maszyny wirtualnej z mniejszymi wystąpieniami. Na przykład region podstawowy może znajdować się w warstwie P3V3, a region pomocniczy znajduje się w warstwie P1V3. Takie podejście nadal zapewnia równoważność funkcji dla dwóch planów usługi App Service, ale brak parzystości rozmiaru może wymagać ręcznego skalowania w górę, gdy region pomocniczy stanie się aktywnym regionem. Cel czasu odzyskiwania podczas przechodzenia w tryb failover geograficznie zależy od czasu skalowania w górę i skalowania wystąpień w poziomie.

    • Najmniej preferowane Pomocniczy plan usługi App Service ma inną warstwę cenową niż wystąpienia podstawowe i mniejsze. Na przykład region podstawowy może znajdować się w warstwie P3V3, a region pomocniczy znajduje się w warstwie S1. Upewnij się, że pomocniczy plan usługi App Service ma wszystkie funkcje wymagane przez aplikację do uruchomienia. Różnice w dostępności funkcji między nimi mogą powodować opóźnienia odzyskiwania aplikacji internetowej. Cel czasu odzyskiwania podczas przechodzenia w tryb failover geograficznie zależy od czasu skalowania w górę i skalowania wystąpień w poziomie.

  • Automatyczne skalowanie jest konfigurowane w regionie pomocniczym w przypadku, gdy aktywny region stanie się nieaktywny. Zaleca się stosowanie podobnych reguł autoskalowania zarówno w regionach aktywnych, jak i pasywnych.

  • Podczas awarii region podstawowy staje się nieaktywny, a region pomocniczy zaczyna odbierać ruch i staje się aktywnym regionem.

  • Gdy region pomocniczy stanie się aktywny, obciążenie sieciowe wyzwala wstępnie skonfigurowane reguły automatycznego skalowania w celu skalowania pomocniczej aplikacji internetowej w poziomie.

  • Może być konieczne ręczne skalowanie w górę warstwy cenowej dla regionu pomocniczego, jeśli nie ma jeszcze wymaganych funkcji do uruchomienia jako aktywny region. Na przykład skalowanie automatyczne wymaga warstwy Standardowa lub nowszej.

  • Gdy region podstawowy jest ponownie aktywny, usługa Azure Front Door automatycznie kieruje ruch z powrotem do niego, a architektura wraca do trybu aktywny-pasywny, tak jak wcześniej.

  • Pliki aplikacji powinny być wdrażane w obu aplikacjach internetowych z rozwiązaniem ciągłej integracji/ciągłego wdrażania. Gwarantuje to, że cel punktu odzyskiwania jest praktycznie zerowy.

  • Jeśli aplikacja aktywnie modyfikuje system plików, najlepszym sposobem zminimalizowania celu punktu odzyskiwania jest zapisywanie tylko w zainstalowanym udziale usługi Azure Storage zamiast zapisywania bezpośrednio w udziale zawartości /home aplikacji internetowej. Następnie użyj funkcji nadmiarowości usługi Azure Storage (GZRS lub GRS) dla zainstalowanego udziału, który ma cel punktu odzyskiwania około 15 minut.

Kroki tworzenia architektury aktywne-pasywnej dla aplikacji internetowej w usłudze App Service są podsumowane w następujący sposób:

  1. Utwórz dwa plany usługi App Service w dwóch różnych regionach świadczenia usługi Azure. Pomocniczy plan usługi App Service może być aprowizowany przy użyciu jednego z wymienionych wcześniej podejść.
  2. Skonfiguruj reguły skalowania automatycznego dla pomocniczego planu usługi App Service, aby skalować je do tej samej liczby wystąpień co podstawowy, gdy region podstawowy stanie się nieaktywny.
  3. Utwórz dwa wystąpienia aplikacji internetowej z jednym w każdym planie usługi App Service.
  4. Utwórz profil usługi Azure Front Door przy użyciu:
    • Punkt końcowy.
    • Grupa pochodzenia z priorytetem 1 dla regionu podstawowego.
    • Druga grupa pochodzenia z priorytetem 2 dla regionu pomocniczego. Różnica w priorytetyzuje usługę Azure Front Door, aby preferować region podstawowy, gdy jest on w trybie online (w związku z czym jest aktywny-pasywny).
    • Trasa.
  5. Ogranicz ruch sieciowy do aplikacji internetowych tylko z wystąpienia usługi Azure Front Door.
  6. Skonfiguruj i skonfiguruj wszystkie inne usługi platformy Azure zaplecza, takie jak bazy danych, konta magazynu i dostawcy uwierzytelniania.
  7. Wdrażanie kodu w obu aplikacjach internetowych przy użyciu ciągłego wdrażania.

Samouczek: tworzenie aplikacji z wieloma regionami o wysokiej dostępności w usłudze aplikacja systemu Azure pokazuje, jak skonfigurować architekturę aktywne-pasywne.

Architektura pasywna chłodna

Architektura pasywna/zimna umożliwia tworzenie i utrzymywanie regularnych kopii zapasowych aplikacji internetowych na koncie usługi Azure Storage znajdującym się w innym regionie.

W przypadku tej przykładowej architektury:

  • Pojedyncza aplikacja internetowa jest wdrażana w jednym regionie.

  • Kopia zapasowa aplikacji internetowej jest regularnie tworzona na koncie usługi Azure Storage w tym samym regionie.

  • Replikacja między regionami kopii zapasowych zależy od konfiguracji nadmiarowości danych na koncie usługi Azure Storage. W miarę możliwości należy ustawić konto usługi Azure Storage jako magazyn GZRS . Magazyn GZRS oferuje zarówno synchroniczną nadmiarowość strefy w regionie, jak i asynchroniczną w regionie pomocniczym. Jeśli magazyn GZRS jest niedostępny, skonfiguruj konto jako GRS. Zarówno GZRS, jak i GRS mają cel punktu odzyskiwania około 15 minut.

  • Aby mieć pewność, że można pobrać kopie zapasowe, gdy region podstawowy konta magazynu stanie się niedostępny, włącz dostęp tylko do odczytu do regionu pomocniczego (odpowiednio co spowoduje, że konto magazynu RA-GZRS lub RA-GRS). Aby uzyskać więcej informacji na temat projektowania aplikacji w celu korzystania z nadmiarowości geograficznej, zobacz Projektowanie aplikacji o wysokiej dostępności przy użyciu nadmiarowości geograficznej.

  • Podczas awarii w regionie aplikacji internetowej należy ręcznie wdrożyć wszystkie wymagane zasoby zależne usługi App Service przy użyciu kopii zapasowych z konta usługi Azure Storage, najprawdopodobniej z regionu pomocniczego z dostępem do odczytu. Cel czasu odzyskiwania może być godzinami lub dniami.

  • Aby zminimalizować cel czasu odzyskiwania, zdecydowanie zaleca się posiadanie kompleksowego podręcznika przedstawiającego wszystkie kroki wymagane do przywrócenia kopii zapasowej aplikacji internetowej do innego regionu świadczenia usługi Azure.

Kroki tworzenia regionu pasywnego zimnego dla aplikacji internetowej w usłudze App Service są podsumowane w następujący sposób:

  1. Utwórz konto usługi Azure Storage w tym samym regionie co aplikacja internetowa. Wybierz warstwę wydajności Standardowa i wybierz nadmiarowość jako magazyn geograficznie nadmiarowy (GRS) lub magazyn geograficznie nadmiarowy (GZRS).

  2. Włącz ra-GRS lub RA-GZRS (dostęp do odczytu dla regionu pomocniczego).

  3. Skonfiguruj niestandardową kopię zapasową dla aplikacji internetowej. Możesz zdecydować się na ustawienie harmonogramu tworzenia kopii zapasowych aplikacji internetowej, takich jak co godzinę.

  4. Sprawdź, czy pliki kopii zapasowej aplikacji internetowej można pobrać w regionie pomocniczym konta magazynu.

Napiwek

Oprócz usługi Azure Front Door platforma Azure oferuje inne opcje równoważenia obciążenia, takie jak Usługa Azure Traffic Manager. Aby zapoznać się z porównaniem różnych opcji, zobacz Opcje równoważenia obciążenia — Centrum architektury platformy Azure.

Odzyskiwanie po awarii w lokalizacji geograficznej z jednym regionem

Jeśli region aplikacji internetowej nie ma magazynu GZRS lub GRS lub jeśli znajdujesz się w regionie świadczenia usługi Azure, który nie jest jedną z par regionalnych, musisz użyć magazynu strefowo nadmiarowego (ZRS) lub magazynu lokalnie nadmiarowego (LRS), aby utworzyć podobną architekturę. Na przykład możesz ręcznie utworzyć region pomocniczy dla konta magazynu w następujący sposób:

Diagram przedstawiający sposób tworzenia pasywnego lub zimnego regionu bez magazynu GRS lub GZRS.

Kroki tworzenia regionu pasywnego zimnego bez magazynu GRS i magazynu GZRS są podsumowane w następujący sposób:

  1. Utwórz konto usługi Azure Storage w tym samym regionie aplikacji internetowej. Wybierz warstwę wydajności Standardowa i wybierz nadmiarowość jako magazyn strefowo nadmiarowy (ZRS).

  2. Skonfiguruj niestandardową kopię zapasową dla aplikacji internetowej. Możesz zdecydować się na ustawienie harmonogramu tworzenia kopii zapasowych aplikacji internetowej, takich jak co godzinę.

  3. Sprawdź, czy pliki kopii zapasowej aplikacji internetowej można pobrać w regionie pomocniczym konta magazynu.

  4. Utwórz drugie konto usługi Azure Storage w innym regionie. Wybierz warstwę wydajności Standardowa i wybierz nadmiarowość jako magazyn lokalnie nadmiarowy (LRS).

  5. Korzystając z narzędzia takiego jak AzCopy, zreplikuj niestandardową kopię zapasową (pliki zip, XML i dziennika) z regionu podstawowego do magazynu pomocniczego. Na przykład:

    azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'

    Możesz użyć usługi Azure Automation z elementem Runbook przepływu pracy programu PowerShell, aby uruchomić skrypt replikacji zgodnie z harmonogramem. Upewnij się, że harmonogram replikacji jest zgodny z harmonogramem podobnym do kopii zapasowych aplikacji internetowej.

Następne kroki