Niezawodność w usłudze Azure Functions
W tym artykule opisano obsługę niezawodności w usłudze Azure Functions i opisano zarówno odporność wewnątrz regionów, jak i stref dostępności oraz odzyskiwanie między regionami i ciągłość działalności biznesowej. Aby uzyskać bardziej szczegółowe omówienie zasad niezawodności na platformie Azure, zobacz Niezawodność platformy Azure.
Obsługa stref dostępności dla usługi Azure Functions jest dostępna zarówno w planach Premium (Elastic Premium) i Dedicated (App Service). Ten artykuł koncentruje się na obsłudze nadmiarowości stref dla planów Premium. Aby uzyskać nadmiarowość stref w planach dedykowanych, zobacz Migrowanie usługi App Service do obsługi stref dostępności.
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.
Usługa Azure Functions obsługuje wdrożenie strefowo nadmiarowe.
Po skonfigurowaniu usługi Functions jako strefowo nadmiarowej platforma automatycznie rozdziela wystąpienia aplikacji funkcji 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ń aplikacji funkcji to trzy.
- Po określeniu pojemności większej niż trzy wystąpienia są rozłożone równomiernie tylko wtedy, gdy pojemność jest wielokrotną 3.
- W przypadku wartości pojemności większej niż 3*N dodatkowe wystąpienia są rozłożone w pozostałych strefach.
Ważne
Usługa Azure Functions może działać na platformie usługi aplikacja systemu Azure. Na platformie App Service plany hostujące aplikacje funkcji planu Premium są określane jako plany Elastic Premium z nazwami jednostek SKU, takimi jak EP1. Jeśli zdecydujesz się uruchomić aplikację funkcji w planie Premium, pamiętaj, aby utworzyć plan o nazwie jednostki SKU rozpoczynającej się od "E", takiej jak EP1. Nazwy jednostek SKU planu usługi App Service rozpoczynające się od "P", takie jak P1V2 (Premium V2 Small plan), są rzeczywiście dedykowanymi planami hostingu. Ponieważ są one dedykowane, a nie elastyczne Premium, plany o nazwach jednostek SKU rozpoczynających się od "P" nie będą skalowane dynamicznie i mogą zwiększyć koszty.
Dostępność w regionach
Plany Premium strefowo nadmiarowe są dostępne w następujących regionach:
| Ameryka Północna i Południowa | Europa | Bliski Wschód | Afryka | Azja i Pacyfik |
|---|---|---|---|---|
| Brazylia Południowa | Francja Środkowa | Izrael Centralny | Północna Republika Południowej Afryki | Australia Wschodnia |
| Kanada Środkowa | Niemcy Środkowo-Zachodnie | Katar Środkowy | Indie Środkowe | |
| Central US | Włochy Północne | Północne Zjednoczone Emiraty Arabskie | Chiny Północne 3 | |
| East US | Europa Północna | Azja Wschodnia | ||
| Wschodnie stany USA 2 | Norwegia Wschodnia | Japonia Wschodnia | ||
| South Central US | Szwecja Środkowa | Southeast Asia | ||
| Zachodnie stany USA 2 | Szwajcaria Północna | |||
| Zachodnie stany USA 3 | Południowe Zjednoczone Królestwo | |||
| West Europe |
Wymagania wstępne
Obsługa strefy dostępności jest właściwością planu Premium. Poniżej przedstawiono bieżące wymagania/ograniczenia dotyczące włączania stref dostępności:
- Strefy dostępności można włączyć tylko podczas tworzenia planu Premium dla aplikacji funkcji. Nie można przekonwertować istniejącego planu Premium na strefy dostępności.
- Musisz użyć konta magazynu strefowo nadmiarowego (ZRS) dla konta magazynu aplikacji funkcji. Jeśli używasz innego typu konta magazynu, funkcje mogą wyświetlać nieoczekiwane zachowanie podczas awarii strefowej.
- Obsługiwane są systemy Windows i Linux.
- Musi być hostowany w ramach elastycznego planu hostingu premium lub dedykowanego. Aby dowiedzieć się, jak używać nadmiarowości stref z dedykowanym planem, zobacz Migrowanie usługi App Service do obsługi stref dostępności.
- Obsługa strefy dostępności nie jest obecnie dostępna dla aplikacji funkcji w planach zużycie .
- Aplikacje funkcji hostowane w planie Premium muszą mieć minimalną liczbę zawsze gotowych wystąpień .
- Platforma wymusza tę minimalną liczbę w tle, jeśli określisz liczbę wystąpień mniej niż trzy.
- Jeśli nie używasz planu Premium lub jednostki skalowania obsługującej strefy dostępności, znajdują się w nieobsługiwanym regionie lub nie masz pewności, zapoznaj się ze wskazówkami dotyczącymi migracji.
Cennik
Nie ma dodatkowych kosztów związanych z włączaniem stref dostępności. Ceny strefowo nadmiarowego planu usługi App Service w warstwie Premium są takie same jak plan Premium z jedną strefą. Dla każdego używanego planu usługi App Service opłaty są naliczane na podstawie wybranej jednostki SKU, 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 dla planu usługi App Service, platforma wymusza minimalną liczbę wystąpień wynoszącą trzy dla tego planu usługi App Service i nalicza opłaty za te trzy wystąpienia.
Tworzenie strefowo nadmiarowego planu Premium i aplikacji funkcji
Obecnie istnieją dwa sposoby wdrażania strefowo nadmiarowego planu Premium i aplikacji funkcji. Możesz użyć witryny Azure Portal lub szablonu usługi ARM.
Otwórz witrynę Azure Portal i przejdź do strony Tworzenie aplikacji funkcji. Informacje na temat tworzenia aplikacji funkcji w portalu można znaleźć tutaj.
Na stronie Podstawy wypełnij pola aplikacji funkcji. Zwróć szczególną uwagę na pola w poniższej tabeli (wyróżnione również na poniższym zrzucie ekranu), które mają określone wymagania dotyczące nadmiarowości strefy.
Na stronie Hosting wypełnij pola planu hostingu aplikacji funkcji. Zwróć szczególną uwagę na pola w poniższej tabeli (wyróżnione również na poniższym zrzucie ekranu), które mają określone wymagania dotyczące nadmiarowości strefy.
Ustawienie Sugerowana wartość Uwagi dotyczące nadmiarowości strefy Konto magazynu Konto magazynu strefowo nadmiarowego Jak wspomniano powyżej w sekcji wymagań wstępnych, zdecydowanie zalecamy użycie konta magazynu strefowo nadmiarowego dla aplikacji funkcji strefowo nadmiarowej. Typ planu Functions Premium W tym artykule opisano sposób tworzenia strefowo nadmiarowej aplikacji w planie Premium. Nadmiarowość strefy nie jest obecnie dostępna w planach Zużycie. Informacje na temat nadmiarowości stref w planach usługi App Service można znaleźć w tym artykule. Nadmiarowość strefy Włączona To pole wypełnia flagę określającą, czy aplikacja jest strefowo nadmiarowa, czy nie. Nie będzie można wybrać Enabled, chyba że wybrano region obsługujący nadmiarowość strefy, jak wspomniano w kroku 2.
W pozostałej części procesu tworzenia aplikacji funkcji utwórz aplikację funkcji w zwykły sposób. W pozostałej części procesu tworzenia nie ma pól, które mają wpływ na nadmiarowość strefy.
Po utworzeniu i wdrożeniu planu strefowo nadmiarowego każda aplikacja funkcji hostowana w nowym planie jest uważana za strefowo nadmiarową.
Migracja strefy dostępności
Obecnie aplikacje funkcji platformy Azure nie obsługują migracji w miejscu istniejących wystąpień aplikacji funkcji. Aby uzyskać informacje na temat migrowania publicznego wielodostępnego planu Premium z strefy niedostępnej do obsługi stref dostępności, zobacz Migrowanie usługi App Service do obsługi stref dostępności.
Środowisko strefowe w dół
Wszystkie dostępne wystąpienia aplikacji funkcji strefowo nadmiarowych są włączone i przetwarzają zdarzenia. Gdy strefa ulegnie awarii, usługa Functions wykrywa utracone wystąpienia i automatycznie próbuje znaleźć nowe wystąpienia zastępcze w razie potrzeby. Zachowanie elastycznego skalowania nadal ma zastosowanie. Jednak w scenariuszu w dół strefy nie ma gwarancji, że żądania dotyczące dodatkowych wystąpień mogą zakończyć się powodzeniem, ponieważ ponowne wypełnianie utraconych wystąpień odbywa się w oparciu o najlepsze wysiłki. Aplikacje wdrożone w strefie dostępności z włączonym planem Premium będą nadal działać nawet wtedy, gdy w innych strefach w tym samym regionie wystąpiła awaria. Istnieje jednak możliwość, że zachowania inne niż środowisko uruchomieniowe nadal mogą mieć wpływ na awarię w innych strefach dostępności. Te zachowania, których to dotyczy, mogą obejmować skalowanie planu Premium, tworzenie aplikacji, konfigurację aplikacji i publikowanie aplikacji. Nadmiarowość stref dla planów Premium gwarantuje tylko ciągły czas pracy wdrożonych aplikacji.
Gdy usługa Functions przydziela wystąpienia do strefowo nadmiarowego planu Premium, korzysta z najlepszego równoważenia nakładu pracy oferowanego przez bazowe zestawy skalowania maszyn wirtualnych platformy Azure. Plan Premium jest uznawany za zrównoważony, gdy każda strefa ma taką samą liczbę maszyn wirtualnych (± 1 maszyny wirtualnej) we wszystkich pozostałych strefach używanych przez plan Premium.
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 strategie, których można użyć do wdrożenia usługi Functions w celu umożliwienia odzyskiwania po awarii.
Odzyskiwanie po awarii w wielu regionach
Ponieważ nie ma wbudowanej nadmiarowości, funkcje są uruchamiane w aplikacji funkcji w określonym regionie świadczenia usługi Azure. Aby uniknąć utraty wykonywania podczas przestojów, można nadmiarowo wdrożyć te same funkcje w aplikacjach funkcji w wielu regionach. Aby dowiedzieć się więcej na temat wdrożeń w wielu regionach, zobacz wskazówki dotyczące aplikacji internetowej o wysokiej dostępności w wielu regionach.
Po uruchomieniu tego samego kodu funkcji w wielu regionach istnieją dwa wzorce do rozważenia, aktywne-aktywne i aktywne-pasywne.
Wzorzec aktywny-aktywny dla funkcji wyzwalacza HTTP
W przypadku wzorca aktywny-aktywny funkcje w obu regionach aktywnie działają i przetwarzają zdarzenia , w sposób zduplikowany lub w rotacji. Zaleca się użycie wzorca aktywne-aktywne w połączeniu z usługą Azure Front Door dla krytycznych funkcji wyzwalanych przez protokół HTTP, które mogą kierować i okrężne żądania HTTP między funkcjami uruchomionymi w wielu regionach. Usługa Front Door może również okresowo sprawdzać kondycję każdego punktu końcowego. Gdy funkcja w jednym regionie przestaje odpowiadać na kontrole kondycji, usługa Azure Front Door usuwa ją z rotacji i przekazuje tylko ruch do pozostałych funkcji w dobrej kondycji.
Ważne
Chociaż zdecydowanie zaleca się używanie wzorca aktywny-pasywny dla funkcji wyzwalacza bez protokołu HTTPS. Można tworzyć wdrożenia aktywne-aktywne dla funkcji niezwolonych przez protokół HTTP. Należy jednak rozważyć, w jaki sposób dwa aktywne regiony współdziałają ze sobą lub koordynują ze sobą. Podczas wdrażania tej samej aplikacji funkcji w dwóch regionach z każdym wyzwalającym w tej samej kolejce usługi Service Bus będą działać jako konkurujący użytkownicy w przypadku de-kolejkowania tej kolejki. Oznacza to, że każdy komunikat jest przetwarzany tylko przez jedno z wystąpień, ale oznacza to również, że w pojedynczym wystąpieniu usługi Service Bus nadal występuje pojedynczy punkt awarii.
Zamiast tego można wdrożyć dwie kolejki usługi Service Bus z jedną w regionie podstawowym, jedną w regionie pomocniczym. W takim przypadku możesz mieć dwie aplikacje funkcji, z których każda wskazuje na kolejkę usługi Service Bus aktywną w ich regionie. Wyzwanie z tą topologią polega na tym, jak komunikaty kolejek są dystrybuowane między dwoma regionami. Często oznacza to, że każdy wydawca próbuje opublikować komunikat w obu regionach, a każdy komunikat jest przetwarzany przez obie aktywne aplikacje funkcji. Chociaż powoduje to utworzenie żądanego wzorca aktywnego/aktywnego, stwarza również inne wyzwania związane z duplikowaniem obliczeń i czasu lub sposobu konsolidacji danych.
Wzorzec aktywny-pasywny dla funkcji wyzwalacza bez protokołu HTTPS
Zaleca się używanie wzorca aktywne-pasywne dla funkcji wyzwalanych przez zdarzenia, które nie są wyzwalane przez protokół HTTP, takich jak wyzwalane funkcje usługi Service Bus i Event Hubs.
Aby utworzyć nadmiarowość dla funkcji wyzwalacza innych niż HTTP, użyj wzorca aktywne-pasywne. W przypadku wzorca aktywne-pasywne funkcje działają aktywnie w regionie, w którym są odbierane zdarzenia; chociaż te same funkcje w drugim regionie pozostają bezczynne. Wzorzec aktywny-pasywny umożliwia przetwarzanie każdego komunikatu tylko przez jedną funkcję, zapewniając jednocześnie mechanizm przełączania w tryb failover do regionu pomocniczego w przypadku awarii. Aplikacje funkcji współpracują z zachowaniami trybu failover usług partnerskich, takimi jak odzyskiwanie geograficzne usługi Azure Service Bus i odzyskiwanie geograficzne usługi Azure Event Hubs.
Rozważmy przykładową topologię przy użyciu wyzwalacza usługi Azure Event Hubs. W takim przypadku wzorzec aktywny/pasywny wymaga użycia następujących składników:
- Usługa Azure Event Hubs wdrożona zarówno w regionie podstawowym, jak i pomocniczym.
- Po awarii geograficznej włączono parowanie głównych i pomocniczych centrów zdarzeń. Spowoduje to również utworzenie aliasu, za pomocą którego można nawiązać połączenie z centrami zdarzeń i przełączyć się z podstawowej na pomocniczą bez zmieniania informacji o połączeniu.
- Aplikacje funkcji są wdrażane zarówno w regionie podstawowym, jak i pomocniczym (tryb failover), a aplikacja w regionie pomocniczym jest zasadniczo bezczynna, ponieważ komunikaty nie są tam wysyłane.
- Aplikacja funkcji wyzwala bezpośrednie (inne niż alias) parametry połączenia dla odpowiedniego centrum zdarzeń.
- Wydawcy w centrum zdarzeń powinni publikować w aliasie parametry połączenia.
Przed przejściem w tryb failover wydawcy wysyłający do udostępnionego aliasu kierują do podstawowego centrum zdarzeń. Podstawowa aplikacja funkcji nasłuchuje wyłącznie do podstawowego centrum zdarzeń. Aplikacja funkcji pomocniczej jest pasywna i bezczynna. Po zainicjowaniu trybu failover wydawcy wysyłający do udostępnionego aliasu są kierowani do pomocniczego centrum zdarzeń. Aplikacja funkcji pomocniczej staje się teraz aktywna i uruchamia się automatycznie. Skuteczne przejście w tryb failover do regionu pomocniczego może być całkowicie sterowane z centrum zdarzeń, a funkcje stają się aktywne tylko wtedy, gdy odpowiednie centrum zdarzeń jest aktywne.
Przeczytaj więcej na temat informacji i zagadnień dotyczących trybu failover w usługach Service Bus i Event Hubs.