Niezawodność w usłudze aplikacja systemu Azure
W tym artykule opisano obsługę niezawodności w usłudze aplikacja systemu Azure oraz omówiono odporność wewnątrz regionalną ze strefami dostę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?
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 Zalecenia dotyczące 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
- Izrael Centralny
- Włochy Północne
- Japonia Wschodnia
- Korea Środkowa
- Meksyk Środkowy
- Europa Północna
- Norwegia Wschodnia
- Polska Środkowa
- Katar Środkowy
- Północna Republika Południowej Afryki
- South Central US
- Southeast Asia
- Hiszpania Środkowa
- 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
W przypadku środowisk wielodostępnych korzystających z planów Usługi App Service Premium w wersji 2 lub Premium w wersji 3 nie ma żadnych dodatkowych kosztów związanych z włączaniem stref dostępności, o ile masz co najmniej trzy wystąpienia w planie usługi App Service. 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. Środowisko App Service Environment w wersji 3 ma inny model cen dla stref dostępności. 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 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.
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 |
|---|---|---|
| Aplikacje internetowe usługi App Service (Warstwy cenowe Bezpłatna i Współdzielona) |
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. Zalecamy zaimplementowanie powszechnie używanych technik odzyskiwania po awarii, aby zapobiec przestojom i utracie danych podczas regionalnej awarii. |
| Aplikacje internetowe usługi App Service (Warstwy cenowe Podstawowa, Standardowa i 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ę lub 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 (V2 i V3) | W środowisku usługi aplikacja systemu Azure możesz tworzyć niestandardowe kopie zapasowe na żądanie lub używać automatycznych kopii zapasowych. Automatyczne kopie zapasowe można przywrócić do aplikacji docelowej w tym samym środowisku App Service Environment, a nie w innym środowisku App Service Environment. Niestandardowe kopie zapasowe można przywrócić do aplikacji docelowej w innym środowisku App Service Environment (na przykład z środowiska App Service Environment w wersji 2 do środowiska App Service Environment w wersji 3). Kopie zapasowe można przywrócić do docelowej aplikacji 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: Dedykowany plan |
Po uruchomieniu aplikacji funkcji w planie dedykowanej (App Service) wymagana zawartość aplikacji funkcji jest utrzymywana przy użyciu wbudowanego magazynu. W planie dedykowanym można tworzyć niestandardowe kopie zapasowe na żądanie lub używać automatycznych kopii zapasowych. Możesz przywrócić kopię zapasową, zastępując istniejącą aplikację lub 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. Usługa Azure Files nie jest używana przez plan dedykowany, ale jeśli aplikacja została nieprawidłowo skonfigurowana za pomocą połączenia usługi Azure Files, kopia zapasowa nie jest obsługiwana. |
Bieżące wskazówki dotyczące przenoszenia zasobów aplikacji funkcji do dedykowanego planu w trybie 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 należy zaplanować niezawodność w aplikacjach funkcji. Można również zapoznać się z powszechnie używanymi technikami odzyskiwania po awarii dla aplikacji funkcji w planie dedykowanym. |
| Azure Functions: Zużycie elastyczne, Zużycie i plany Premium |
Aplikacje funkcji uruchamiane w planie Flex Consumption w planie Zużycie lub w planie Premium nie mogą używać niestandardowych ani automatycznych funkcji tworzenia kopii zapasowych w usłudze App Service. W tych planach skalowania dynamicznego zawartość aplikacji funkcji jest przechowywana w usłudze 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. Możesz również pobrać istniejący projekt aplikacji funkcji jako plik .zip z witryny Azure Portal. |
Zdecydowanie zachęcamy do planowania niezawodności w aplikacjach funkcji. |
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 Testy dostępności usługi Application Insights.
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.
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:
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.
Utwórz dwa wystąpienia aplikacji internetowej z jednym w każdym planie usługi App Service.
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.
Ogranicz ruch sieciowy do aplikacji internetowych tylko z wystąpienia usługi Azure Front Door.
Skonfiguruj i skonfiguruj wszystkie inne usługi platformy Azure zaplecza, takie jak bazy danych, konta magazynu i dostawcy uwierzytelniania.
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).
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:
- 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ść.
- 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.
- Utwórz dwa wystąpienia aplikacji internetowej z jednym w każdym planie usługi App Service.
- 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.
- Ogranicz ruch sieciowy do aplikacji internetowych tylko z wystąpienia usługi Azure Front Door.
- Skonfiguruj i skonfiguruj wszystkie inne usługi platformy Azure zaplecza, takie jak bazy danych, konta magazynu i dostawcy uwierzytelniania.
- 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:
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).
Włącz ra-GRS lub RA-GZRS (dostęp do odczytu dla regionu pomocniczego).
Skonfiguruj niestandardową kopię zapasową dla aplikacji internetowej. Możesz zdecydować się na ustawienie harmonogramu tworzenia kopii zapasowych aplikacji internetowej, takich jak co godzinę.
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:
Kroki tworzenia regionu pasywnego zimnego bez magazynu GRS i magazynu GZRS są podsumowane w następujący sposób:
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).
Skonfiguruj niestandardową kopię zapasową dla aplikacji internetowej. Możesz zdecydować się na ustawienie harmonogramu tworzenia kopii zapasowych aplikacji internetowej, takich jak co godzinę.
Sprawdź, czy pliki kopii zapasowej aplikacji internetowej można pobrać w regionie pomocniczym konta magazynu.
Utwórz drugie konto usługi Azure Storage w innym regionie. Wybierz warstwę wydajności Standardowa i wybierz nadmiarowość jako magazyn lokalnie nadmiarowy (LRS).
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.