Udostępnij przez

Niezawodność usługi Azure Container Instances

W tym artykule opisano obsługę niezawodności w usłudze Azure Container Instances, która zapewnia prosty sposób uruchamiania kontenerów systemu Linux lub Windows na platformie Azure bez konieczności zarządzania maszynami wirtualnymi lub wdrażania bardziej złożonej usługi wyższego poziomu.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Firma Microsoft oferuje szereg możliwości wspierania odporności systemów i odzyskiwania. Odpowiadasz za zrozumienie sposobu działania tych możliwości we wszystkich używanych usługach oraz wybór możliwości potrzebnych do osiągnięcia twoich celów biznesowych i celów dostępności.

W tym artykule opisano, jak usługa Azure Container Instances jest odporna na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie stref dostępności i awarie regionów. Wyróżnia kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi Azure Container Instances.

Zalecenia dotyczące wdrażania produkcyjnego pod kątem niezawodności

Aby zwiększyć niezawodność aplikacji produkcyjnych opartych na usłudze Container Instances, zalecamy wykonanie następujących akcji:

Omówienie architektury niezawodności

Aby użyć usługi Container Instances, należy wdrożyć grupę kontenerów. Grupa kontenerów zawiera co najmniej jeden kontener. Każdy kontener jest tworzony na podstawie obrazu kontenera, który jest przechowywany w rejestrze, takim jak usługa Azure Container Registry.

Wszystkie kontenery w grupie kontenerów są wdrażane razem jako pojedyncza jednostka logiczna i współużytkują tę samą infrastrukturę fizyczną.

Na poniższym diagramie przedstawiono relację między grupami kontenerów, kontenerami i obrazami.

Diagram przedstawiający grupę kontenerów z dwoma kontenerami. Każdy kontener używa oddzielnego obrazu w rejestrze.

Usługa Container Instances udostępnia następujące funkcje do zarządzania grupami kontenerów:

  • Grupy NGroup ( wersja zapoznawcza) udostępniają zestaw możliwości zarządzania wieloma powiązanymi grupami kontenerów. Podczas tworzenia grupy NGroup należy zdefiniować liczbę grup kontenerów do utworzenia. Usługa Container Instances udostępnia funkcje, takie jak automatyczne wdrażanie uaktualnień i rozpowszechnianie grup kontenerów w różnych strefach dostępności.

  • Pule rezerwowe tworzą pulę wstępnie aprowizowanych grup kontenerów, które mogą być używane w odpowiedzi na nadchodzący ruch. Pule rezerwowe są przeznaczone do optymalizacji tworzenia grup kontenerów i nie mają na celu zwiększenia odporności.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

Zestawy SDK dostarczane przez firmę Microsoft zwykle obsługują błędy przejściowe. Ponieważ hostujesz własne aplikacje w usłudze Container Instances, wykonaj kroki, aby zmniejszyć prawdopodobieństwo przejściowych błędów:

  • Uruchom wiele grup kontenerów dla ważnych obciążeń, aby upewnić się, że awaria w jednym kontenerze lub grupie kontenerów nie ma wpływu na całą aplikację.

  • Skompiluj kod aplikacji, aby był odporny na błędy przejściowe w usługach, z którymi nawiązujesz połączenie, na przykład przy użyciu zasad ponawiania prób ze strategiami wycofywania.

Aby uzyskać więcej informacji o innych błędach, które mogą wystąpić w czasie wykonywania i sposobie reagowania na nie, zobacz Problemy podczas wykonywania grupy kontenerów.

Odporność na błędy strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Usługa Container Instances obsługuje strefy dostępności na różne sposoby, w zależności od sposobu wdrażania grup kontenerów:

  • Ręcznie utworzone grupy kontenerów: Pojedyncza grupa kontenerów jest zasobem strefowym , co oznacza, że można je wdrożyć w pojedynczej wybranej strefie dostępności. Wszystkie kontenery w grupie są wdrażane w tej samej strefie dostępności. Jeśli ta strefa dostępności ma awarię, może dojść do przestoju grupy kontenerów i wszystkich jej kontenerów.

    Na poniższym diagramie przedstawiono grupę kontenerów, która została ręcznie wdrożona w strefie dostępności 1:

    Diagram przedstawiający grupę kontenerów z dwoma kontenerami wdrożonymi w jednej strefie dostępności.

    Uwaga / Notatka

    Aby upewnić się, że aplikacja będzie nadal działać, gdy każda strefa w regionie ulegnie awarii, zalecamy utworzenie co najmniej dwóch grup kontenerów w dwóch różnych strefach dostępności.

    Jeśli nie określisz stref dostępności do użycia dla grupy kontenerów, będzie to niezonalne lub regionalne, co oznacza, że może zostać umieszczona w dowolnej strefie dostępności w regionie lub w tej samej strefie. Jeśli jakakolwiek strefa dostępności w regionie ma problem, grupa kontenerów może doświadczyć przestoju.

  • NGroups: Podczas wdrażania grupy NGroup można określić co najmniej jedną strefę, w której ma zostać wdrożona. Jeśli wdrożysz grupę NGroup w co najmniej dwóch strefach, jest to strefowo nadmiarowa grupa NGroup i awaria jednej strefy dostępności powoduje tylko problemy dla grup kontenerów w strefie, której dotyczy problem.

    Na poniższym diagramie przedstawiono grupę NGroup wdrożoną w trzech strefach dostępności.

    Diagram przedstawiający grupę NGroup z trzema grupami kontenerów wdrożonych w trzech strefach dostępności.

    Jeśli nie określisz stref dostępności do użycia dla grupy NGroup, będzie to niezonalne i może wystąpić przestój, jeśli w regionie wystąpi problem.

  • Pule rezerwowe: Podczas wdrażania puli rezerwowej można opcjonalnie określić co najmniej jedną strefę. Platforma może żądać kontenerów w wybranych strefach.

    Jednak pule rezerwowe nie są redundantne na poziomie stref ani odporne na awarie stref, ponieważ nie ma gwarancji, że kontenery są tworzone w wielu strefach. Jeśli wystąpi awaria strefy, możliwe, że wszystkie kontenery w puli mogą znaleźć się w zainfekowanej strefie.

    Ponieważ pule rezerwowe nie są zaprojektowane do zapewnienia odporności na awarie stref, ten przewodnik nie opisuje szczegółowego działania pul rezerwowych w kontekście stref dostępności.

    Ważne

    Pule rezerwowe nie są zaprojektowane tak, aby były odporne na strefy. Nie należy ich używać w przypadku obciążeń wymagających odporności na awarie strefy.

Obsługa regionów

Wdrożenia grup kontenerów strefowych są obsługiwane we wszystkich regionach ze strefami dostępności.

Requirements

  • Wdrożenia strefowe są dostępne dla grup kontenerów systemów Linux i Windows Server 2019.

  • Aby wybrać strefę dostępności, musisz użyć typu SKU klasy Standard. Grupy kontenerów strefowych nie są dostępne w przypadku SKU typu Confidential.

Rozważania

Kontenery typu spot nie obsługują stref dostępności i są zawsze niezonowe.

Koszt

Nie ma dodatkowych kosztów konfigurowania stref dostępności dla grupy kontenerów.

Konfiguruj obsługę stref dostępności

  • Utwórz grupy kontenerów z obsługą stref dostępności. Podejście używane do konfigurowania stref dostępności zależy od sposobu tworzenia grup kontenerów.

  • Włącz obsługę strefy dostępności dla istniejących zasobów. Podejście używane do konfigurowania stref dostępności zależy od sposobu tworzenia grup kontenerów.

    • Ręcznie utworzone grupy kontenerów: Nie można włączyć stref dostępności w istniejącej niezonowej grupie kontenerów. Należy usunąć grupę kontenerów i utworzyć grupę kontenerów strefowych.

    • NGroups: Nie można włączyć stref dostępności w istniejącej niezonowej grupie NGroup. Należy usunąć grupę NGroup i utworzyć strefowo nadmiarową grupę NGroup.

    • Pule rezerwowe: Nie można włączyć stref dostępności w istniejącej puli rezerwowej niezonowej. Należy usunąć grupę kontenerów i utworzyć nową pulę rezerwową korzystającą z wielu stref dostępności.

  • Przeniesienie grup kontenerów między strefami lub wyłączenie obsługi stref dostępności. Podejście używane do modyfikowania stref dostępności zależy od sposobu tworzenia grup kontenerów.

    • Ręcznie utworzone grupy kontenerów: Aby zmienić strefę dostępności grupy kontenerów, należy usunąć grupę kontenerów i utworzyć inną grupę kontenerów przy użyciu nowej strefy dostępności. Aby dowiedzieć się, jak usunąć grupę kontenerów, zobacz następujące zasoby:

    • NGroups: Strefy można dodawać do grupy NGroup, ale nie można usuwać stref.

    • Pule rezerwowe: Strefy można dodawać do puli rezerwowej, ale nie można usuwać stref.

Dystrybucja grup kontenerów

Sposób dystrybucji grup kontenerów między strefami dostępności zależy od sposobu wdrażania grup kontenerów.

  • Ręcznie utworzone grupy kontenerów: Odpowiadasz za dystrybucję ręcznie utworzonych grup kontenerów w wielu strefach dostępności.

  • NGroups: Podczas operacji skalowania w dół, NGroups losowo usuwa wystąpienia, co może powodować nierównomierny rozkład w różnych strefach dostępności. Operacje skalowania w poziomie próbują ponownie zrównoważyć rozmieszczenie między strefami.

  • Pule rezerwowe: Pula rezerwowa może tworzyć kontenery w dowolnej ze stref dostępności skonfigurowanych w puli. Jednak kontenery mogą nie być tworzone w wielu strefach. Pule rezerwowe nie powinny być używane w przypadku obciążeń wymagających odporności na awarie stref.

Planowanie pojemności i zarządzanie nimi

Aby przygotować się na wypadek awarii strefy dostępności, rozważ nadmiarową aprowizację liczby grup kontenerów, które wdrażasz. Takie podejście pozwala rozwiązaniu tolerować pewną utratę pojemności i nadal działać bez obniżonej wydajności. Aby uzyskać więcej informacji, zobacz Zarządzanie pojemnością przy użyciu nadmiernej aprowizacji.

Podejście, jakie stosujesz do nadmiarowej aprowizacji grup kontenerów, zależy od tego, jak wdrażasz swoje grupy kontenerów.

  • Ręcznie utworzone grupy kontenerów: Odpowiadasz za planowanie pojemności ręcznie utworzonych grup kontenerów, w tym planowanie liczby grup kontenerów do wdrożenia w każdej strefie.

  • NGroup: Rozważ przewymiarowanie wydajności grupy NGroup, aby tolerować utratę strefy.

  • Pule rezerwowe: Pule rezerwowe nie są zaprojektowane tak, aby były odporne na awarie stref. Rozważ użycie wielu pul rezerwowych w różnych strefach lub użycie grup NGroup.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy zasoby usługi Container Instances są skonfigurowane pod kątem obsługi strefy dostępności, a wszystkie strefy dostępności działają.

  • Trasowanie ruchu między strefami: Odpowiadasz za trasowanie ruchu do swoich kontenerów. Na przykład możesz użyć usługi Azure Application Gateway jako bramy i modułu równoważenia obciążenia dla grup kontenerów.

    Jeśli używasz grup NGroup lub pul rezerwowych, odpowiadasz za równoważenie obciążenia w każdym kontenerze. Należy również skonfigurować system routingu ruchu w celu wykrywania kondycji każdej grupy kontenerów i przekierowywania ruchu do alternatywnej grupy w razie potrzeby.

  • Replikacja danych między strefami: Kontenery i grupy kontenerów są bezstanowe. Możesz dołączyć własny zasób plików lub połączyć się z bazami danych bądź innymi usługami przechowywania danych bezpośrednio z poziomu swoich aplikacji. Odpowiadasz za zapewnienie odporności strefowej tych udziałów plików i usług magazynowych. Zapoznaj się z przewodnikami dotyczącymi niezawodności dla każdej usługi, aby dowiedzieć się, jak zapewnić odporność poszczególnych stref składników.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać, gdy zasoby usługi Container Instances są skonfigurowane pod kątem obsługi strefy dostępności i występuje awaria strefy dostępności.

  • Wykrywanie i reagowanie: Odpowiedzialność za wykrywanie błędów strefy i skojarzonej odpowiedzi zależy od sposobu wdrażania grup kontenerów.

    • Ręcznie utworzone grupy kontenerów: Należy wykryć utratę strefy dostępności i zainicjować przejście w tryb failover do pomocniczej grupy kontenerów utworzonej w innej strefie dostępności.

    • NGroups: Platforma Container Instances jest odpowiedzialna za wykrywanie awarii w strefie dostępności i odpowiadanie.

      Jednak odpowiadasz za to, aby zapewnić, że ruch jest kierowany do kontenerów w zdrowej strefie.

    • Pule rezerwowe: Platforma Container Instances nie gwarantuje reagowania na błędy strefy dla pul rezerwowych. Pule rezerwowe nie powinny być używane w przypadku obciążeń wymagających odporności na awarie stref.

  • Powiadomienie: firma Microsoft nie powiadamia cię automatycznie, gdy strefa nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie błędy strefy, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

  • Aktywne żądania: Jeśli strefa ulegnie awarii, wszystkie kontenery uruchomione w tej strefie prawdopodobnie przestaną działać, w tym wszelką aktywną pracę, którą przetwarzają

  • Oczekiwana utrata danych: Ponieważ kontenery i grupy kontenerów są bezstanowe, nie oczekuje się utraty danych z powodu awarii strefy. Jednak odpowiadasz za zapewnienie odporności każdego komponentu obciążenia na awarie strefowe, w tym usług magazynowych i baz danych.

  • Oczekiwany przestój: Przestój, którego możesz się spodziewać w przypadku awarii strefy, zależy od sposobu, w jaki wdrażasz grupy kontenerów.

    • Ręcznie utworzone grupy kontenerów: W przypadku grup kontenerów strefowych, gdy strefa jest niedostępna, grupa kontenerów i jej kontenery są niedostępne do momentu odzyskania strefy dostępności.

    • NGroups: W przypadku grup NGroups, jeśli jedna strefa ulegnie awarii, aplikacja pozostaje dostępna, ponieważ pozostałe grupy kontenerów w grupach NGroup będą nadal działać w innych strefach. Nie oczekiwano przestoju.

    • Pule rezerwowe: Pule rezerwowe nie zapewniają odporności strefy. Jeśli wszystkie grupy kontenerów w puli rezerwowej znajdują się w jednej strefie, możliwe, że wszystkie grupy kontenerów i ich kontenery staną się niedostępne do momentu odzyskania strefy dostępności.

  • Przekierowywanie ruchu: Ponieważ odpowiadasz za kierowanie ruchu do kontenerów, odpowiadasz również za przekierowywanie ruchu, jeśli grupa kontenerów ulegnie awarii z powodu awarii strefy dostępności.

Odzyskiwanie strefy

Po odzyskaniu strefy platforma Azure automatycznie ponownie uruchamia grupy kontenerów, które przestały działać. Nie jest wymagana żadna akcja ze strony klienta.

Testowanie pod kątem niepowodzeń strefy

Nie ma możliwości symulowania awarii strefy dostępności zawierającej grupę kontenerów. Można jednak ręcznie skonfigurować nadrzędne bramy lub moduły równoważenia obciążenia, aby przekierowywać ruch do innej grupy kontenerów w innej strefie dostępności.

Odporność na awarie całego regionu

Container Instances to usługa jednoregionowa. Jeśli region stanie się niedostępny, grupy kontenerów i ich kontenery są również niedostępne.

Niestandardowe rozwiązania obejmujące wiele regionów w celu zapewnienia odporności

Opcjonalnie można wdrożyć oddzielne grupy kontenerów w wielu regionach. Odpowiadasz za wdrażanie i konfigurowanie grup kontenerów w każdym regionie. Należy również skonfigurować równoważenie obciążenia przy użyciu usługi, takiej jak Azure Traffic Manager lub Azure Front Door. Odpowiadasz za wszelkie synchronizacje danych, tryb failover i powrót po awarii.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

Treści powiązane

  • Last updated on