Analiza trybu awarii dla aplikacji platformy Azure

Analiza trybu awarii (FMA) to proces tworzenia niezawodności w systemie przez zidentyfikowanie możliwych punktów awarii. Narzędzie FMA powinno być częścią faz architektury i projektowania, dzięki czemu można tworzyć zarówno odporność (możliwość wytrzymania awarii) i możliwości odzyskiwania (możliwość przywracania funkcjonalności po awariach) do systemu od początku.

Oto ogólny proces przeprowadzania FMA:

1. Zidentyfikuj wszystkie składniki w systemie. Uwzględnij zależności zewnętrzne, takie jak dostawcy tożsamości i usługi innych firm.

2. Dla każdego składnika zidentyfikuj potencjalne błędy, które mogą wystąpić. Jeden składnik może mieć więcej niż jeden tryb awarii. Na przykład należy rozważyć oddzielne błędy odczytu i błędy zapisu, ponieważ wpływ i możliwe kroki zaradcze będą inne.

3. Oceń każdy tryb awarii zgodnie z ogólnym ryzykiem. Rozważ następujące czynniki:

   • Jakie jest prawdopodobieństwo awarii? Czy jest to stosunkowo powszechne? Niezwykle rzadkie? Nie potrzebujesz dokładnych liczb; celem jest ułatwienie rangi priorytetu.
   • Jaki jest wpływ na aplikację, pod względem dostępności, utraty danych, kosztów pieniężnych i zakłóceń w działalności biznesowej?

4. Dla każdego trybu awarii określ, jak aplikacja będzie reagować i odzyskiwać. Rozważ kompromisy w kosztach i złożoności aplikacji.

Jako punkt wyjścia dla procesu FMA ten artykuł zawiera wykaz potencjalnych trybów awarii i ich kroków ograniczania ryzyka. Wykaz jest zorganizowany według technologii lub usługi platformy Azure oraz ogólnej kategorii projektowania na poziomie aplikacji. Wykaz nie jest wyczerpujący, ale obejmuje wiele podstawowych usług platformy Azure.

Microsoft Entra ID

Uwierzytelnianie openID Connect kończy się niepowodzeniem.

Wykrywanie. Możliwe tryby awarii obejmują:

1. Identyfikator entra firmy Microsoft jest niedostępny lub nie można go uzyskać z powodu problemu z siecią. Przekierowanie do punktu końcowego uwierzytelniania kończy się niepowodzeniem, a oprogramowanie pośredniczące OpenID Connect zgłasza wyjątek.
2. Dziedzina Microsoft Entra nie istnieje. Przekierowanie do punktu końcowego uwierzytelniania zwraca kod błędu HTTP, a oprogramowanie pośredniczące OpenID Connect zgłasza wyjątek.
3. Użytkownik nie może uwierzytelnić się. Nie jest wymagana żadna strategia wykrywania; Identyfikator Entra firmy Microsoft obsługuje błędy logowania.

Odzyskiwanie:

1. Przechwytywanie nieobsługiwanych wyjątków w oprogramowaniu pośredniczącym.
2. Obsługa AuthenticationFailed zdarzeń.
3. Przekieruj użytkownika na stronę błędu.
4. Użytkownik ponawia próbę.

Wyszukiwanie AI platformy Azure

Zapisywanie danych w usłudze Azure AI Search kończy się niepowodzeniem.

Wykrywanie. Przechwyć Microsoft.Rest.Azure.CloudException błędy.

Odzyskiwanie:

Search .NET SDK automatycznie ponawia próbę wykonania po przejściowych niepowodzeniach. Wszelkie wyjątki zgłaszane przez zestaw SDK klienta powinny być traktowane jako błędy nienaprawialne.

Domyślna polityka ponawiania prób używa eksponencjalnego odczekania. Aby użyć innej polityki ponawiania, wywołaj SetRetryPolicy na klasie SearchIndexClient lub SearchServiceClient. Aby uzyskać więcej informacji, odwiedź Automatyczne ponawianie prób.

Diagnostyka. Użyj Analizatora ruchu z wyszukiwarki.

Odczytywanie danych z usługi Azure AI Search kończy się niepowodzeniem.

Wykrywanie. Przechwyć Microsoft.Rest.Azure.CloudException błędy.

Odzyskiwanie:

Search .NET SDK automatycznie ponawia próbę wykonania po przejściowych niepowodzeniach. Wszelkie wyjątki zgłaszane przez zestaw SDK klienta powinny być traktowane jako błędy nienaprawialne.

Domyślna polityka ponawiania prób używa eksponencjalnego odczekania. Aby użyć innej polityki ponawiania, wywołaj SetRetryPolicy na klasie SearchIndexClient lub SearchServiceClient. Aby uzyskać więcej informacji, odwiedź Automatyczne ponawianie prób.

Diagnostyka. Użyj Analizatora ruchu z wyszukiwarki.

Kasandra

Odczytywanie lub zapisywanie do węzła kończy się niepowodzeniem.

Wykrywanie. Przechwyć wyjątek. W przypadku klientów platformy .NET będzie to zazwyczaj System.Web.HttpException. Inny klient może mieć inne typy wyjątków. Aby uzyskać więcej informacji, zobacz Poprawne zarządzanie błędami w Cassandrze.

Odzyskiwanie:

• Każdy klient Cassandra ma własne zasady i możliwości ponawiania prób. Aby uzyskać więcej informacji, zobacz Poprawne zarządzanie błędami w Cassandrze.
• Użyj wdrożenia uwzględniającego lokalizację szaf rackowych, z węzłami danych rozmieszczonymi pomiędzy domenami błędów.
• Wdróż w wielu regionach z zachowaniem lokalnej spójności kworum. Jeśli wystąpi trwały błąd, przełącz się na inny region.

Diagnostyka. Dzienniki aplikacji

Magazyn kolejek

Pisanie komunikatu do usługi Azure Queue Storage ciągle kończy się niepowodzeniem.

Wykrywanie. Po ponowieniu próby N operacja zapisu nadal kończy się niepowodzeniem.

Odzyskiwanie:

• Zapisz dane w lokalnej pamięci podręcznej i przekaż operacje zapisu do pamięci masowej później, gdy usługa stanie się dostępna.
• Utwórz kolejkę pomocniczą i zapisz w tej kolejce, jeśli kolejka podstawowa jest niedostępna.

Diagnostyka. Użyj metryk przechowywania.

Aplikacja nie może przetworzyć określonego komunikatu z kolejki.

Wykrywanie. Specyficzne dla aplikacji. Na przykład komunikat zawiera nieprawidłowe dane lub logika biznesowa kończy się niepowodzeniem z jakiegoś powodu.

Odzyskiwanie:

Przenieś komunikat do oddzielnej kolejki. Uruchom osobny proces, aby przeanalizować wiadomości w tej kolejce.

Rozważ użycie kolejek komunikatów usługi Azure Service Bus, które w tym celu udostępniają funkcję kolejki wiadomości martwych listów.

Diagnostyka. Użyj rejestrowania aplikacji.

Baza danych SQL

Nie można nawiązać połączenia z bazą danych w regionie podstawowym.

Wykrywanie. Połączenie kończy się niepowodzeniem.

Odzyskiwanie:

• Aktywuj replikację strefy. Włączając nadmiarowość strefową, usługa Azure SQL Database automatycznie replikuje zapisy w wielu strefach dostępności Azure w obsługiwanych regionach. Aby uzyskać więcej informacji, zobacz Dostępność z nadmiarowością strefową.

• Włącz replikację geograficzną. Jeśli projektujesz rozwiązanie z wieloma regionami, rozważ włączenie aktywnej replikacji geograficznej usługi SQL Database.

  Wymaganie wstępne: baza danych musi być skonfigurowana do aktywnej replikacji geograficznej. Zobacz Aktywna replikacja geograficzna SQL Database.

  • Dla zapytań należy czytać z repliki wtórnej.
  • W przypadku operacji wstawiania i aktualizacji ręcznie przełącz w tryb failover do repliki zapasowej. Zobacz Inicjowanie planowanego lub nieplanowanego przełączenia awaryjnego dla usługi Azure SQL Database.

  Replika używa innych parametrów połączenia, dlatego należy zaktualizować parametry połączenia w aplikacji.

Klient wyczerpuje połączenia w puli połączeń.

Wykrywanie. Przechwyć System.InvalidOperationException błędy.

Odzyskiwanie:

• Spróbuj ponownie wykonać operację.
• W ramach planu ograniczania ryzyka izoluj pule połączeń dla każdego przypadku użycia, aby jeden przypadek użycia nie mógł zdominować wszystkich połączeń.
• Zwiększ maksymalną liczbę pul połączeń.

Diagnostyka. Dzienniki aplikacji.

Osiągnięto limit połączeń z bazą danych.

Wykrywanie. Usługa Azure SQL Database ogranicza liczbę współbieżnych procesów roboczych, logowań i sesji. Limity zależą od warstwy usługi. Aby uzyskać więcej informacji, zobacz Limity zasobów usługi Azure SQL Database.

Aby wykryć te błędy, przechwyć System.Data.SqlClient.SqlException i sprawdź wartość kodu błędu SQL w SqlException.Number. Aby uzyskać listę odpowiednich kodów błędów, zobacz Kody błędów SQL dla aplikacji klienckich usługi SQL Database: Błąd połączenia z bazą danych i inne problemy.

Odzyskiwanie. Te błędy są uznawane za przejściowe, więc ponowienie próby może rozwiązać ten problem. Jeśli stale osiągasz te błędy, rozważ skalowanie bazy danych.

Diagnostyka. — Zapytanie sys.event_log zwraca pomyślne połączenia z bazą danych, błędy połączeń i zakleszczenia.

• Utwórz regułę alertu dla połączeń, które zakończyły się niepowodzeniem.
• Włącz inspekcję usługi SQL Database i sprawdź, czy nie powiodło się logowanie.

Komunikaty usługi Service Bus

Odczytywanie komunikatu z kolejki usługi Service Bus kończy się niepowodzeniem.

Wykrywanie. Przechwyć wyjątki z SDK klienta. Klasa podstawowa wyjątków usługi Service Bus to MessagingException. Jeśli błąd jest przejściowy, IsTransient właściwość ma wartość true.

Aby uzyskać więcej informacji, zobacz Wyjątki komunikatów dla Service Bus.

Odzyskiwanie:

1. W przypadku błędów tymczasowych, ponów próbę.
2. Komunikaty, których nie można dostarczyć do żadnego odbiorcy, są umieszczane w kolejce utraconych komunikatów. Użyj tej kolejki, aby zobaczyć, których komunikatów nie można było odebrać. Nie ma automatycznego czyszczenia kolejki wiadomości niedostarczonych. Komunikaty pozostają tam do momentu, dopóki ich nie pobierzesz samodzielnie. Zobacz Omówienie kolejki martwych listów w usłudze Service Bus.

Zapisywanie komunikatu w kolejce usługi Service Bus kończy się niepowodzeniem.

Wykrywanie. Przechwyć wyjątki z SDK klienta. Klasa podstawowa wyjątków usługi Service Bus to MessagingException. Jeśli błąd jest przejściowy, IsTransient właściwość ma wartość true.

Aby uzyskać więcej informacji, zobacz Wyjątki komunikatów dla Service Bus.

Odzyskiwanie:

• Klient usługi Service Bus automatycznie ponawia próby po błędach przejściowych. Domyślnie używa wycofywania wykładniczego. Po maksymalnej liczbie ponownych prób lub maksymalnym przedziale czasu klient zgłasza wyjątek.

• Jeśli limit kolejki zostanie przekroczony, klient zgłasza wyjątek QuotaExceededException. Komunikat o wyjątku zawiera więcej szczegółów. Usuń część komunikatów z kolejki przed ponowną próbą i rozważ użycie wzorca Circuit Breaker, aby uniknąć kontynuacji ponownych prób, gdy limit przydziału zostanie przekroczony. Upewnij się również, że właściwość BrokeredMessage.TimeToLive nie jest ustawiona zbyt wysoko.

• W obrębie regionu odporność można poprawić przy użyciu partycjonowanych kolejek lub tematów. Kolejka lub temat wiadomości bez partycji jest przypisywany do jednego magazynu wiadomości. Jeśli ten sklep komunikatów jest niedostępny, wszystkie operacje na tej kolejce lub temacie zakończą się niepowodzeniem. Partycjonowana kolejka lub temat wiadomości jest partycjonowane w wielu magazynach wiadomości.

• Użyj nadmiarowości w strefie, aby zmiany automatycznie replikować między wieloma strefami dostępności. Jeśli jedna strefa dostępności ulegnie awarii, przełączenie następuje automatycznie. Aby uzyskać więcej informacji, zobacz Najlepsze praktyki dotyczące izolowania aplikacji przed awariami i katastrofami usługi Service Bus.

• Jeśli projektujesz rozwiązanie z wieloma regionami, utwórz dwie przestrzenie nazw usługi Service Bus w różnych regionach i zreplikuj komunikaty. Można użyć aktywnej replikacji lub replikacji pasywnej.

  • Aktywna replikacja: klient wysyła każdą wiadomość do obu kolejek. Odbiornik nasłuchuje w obu kolejkach. Tagowanie komunikatów przy użyciu unikatowego identyfikatora, aby klient mógł odrzucić zduplikowane komunikaty.
  • Replikacja pasywna: klient wysyła komunikat do jednej kolejki. Jeśli wystąpi błąd, klient wróci do innej kolejki. Odbiornik nasłuchuje w obu kolejkach. Takie podejście zmniejsza liczbę wysyłanych zduplikowanych komunikatów. Jednak odbiorca musi nadal obsługiwać zduplikowane komunikaty.

  Aby uzyskać więcej informacji, zobacz przykład GeoReplication i najlepsze praktyki dotyczące izolowania aplikacji przed awariami i klęskami usługi Service Bus.

Zduplikowany komunikat.

Wykrywanie. Sprawdź właściwości MessageId i DeliveryCount komunikatu.

Odzyskiwanie:

• Jeśli to możliwe, zaprojektuj operacje przetwarzania komunikatów jako idempotentne. W przeciwnym razie przechowuj identyfikatory komunikatów, które są już przetwarzane, i sprawdź identyfikator przed przetworzeniem komunikatu.

• Włącz wykrywanie duplikatów, tworząc kolejkę, ustawiając wartość RequiresDuplicateDetection na true. Dzięki temu ustawieniu usługa Service Bus automatycznie usuwa wszystkie komunikaty wysyłane z taką samą MessageId jak poprzednia wiadomość. Należy uwzględnić następujące informacje:

  • To ustawienie uniemożliwia umieszczanie zduplikowanych komunikatów w kolejce. Nie uniemożliwia odbiornikowi przetwarzania tego samego komunikatu więcej niż raz.
  • Wykrywanie duplikatów ma przedział czasu. Jeśli duplikat zostanie wysłany poza to okno, nie zostanie wykryty.

Diagnostyka. Rejestruje zduplikowane komunikaty.

Aplikacja nie może przetworzyć określonego komunikatu z kolejki.

Wykrywanie. Specyficzne dla aplikacji. Na przykład komunikat zawiera nieprawidłowe dane lub logika biznesowa kończy się niepowodzeniem z jakiegoś powodu.

Odzyskiwanie:

Istnieją dwa tryby awarii, które należy wziąć pod uwagę.

• Odbiornik wykrywa błąd. W takim przypadku przenieś komunikat do kolejki wiadomości wymagających interwencji. Następnie uruchom oddzielny proces, aby przeanalizować wiadomości w kolejce wiadomości nieodebranych.
• Odbiornik ulega awarii podczas przetwarzania komunikatu — na przykład z powodu nieobsługiwanego wyjątku. Aby obsłużyć ten przypadek, użyj PeekLock trybu. W tym trybie, jeśli blokada wygaśnie, komunikat stanie się dostępny dla innych odbiorników. Jeśli komunikat przekracza maksymalną liczbę prób dostarczenia lub czas wygaśnięcia, zostaje automatycznie przeniesiony do kolejki martwych listów.

Aby uzyskać więcej informacji, zobacz Omówienie kolejek martwych listów usługi Service Bus.

Diagnostyka. Za każdym razem, gdy aplikacja przenosi komunikat do kolejki martwych listów, sporządź zapis zdarzenia w dziennikach aplikacji.

Magazyn

Zapisywanie danych w usłudze Azure Storage kończy się niepowodzeniem

Wykrywanie. Klient otrzymuje błędy podczas zapisywania.

Odzyskiwanie:

1. Spróbuj ponownie wykonać operację, aby odzyskać sprawność po przejściowych błędach. Polityka ponawiania prób w zestawie SDK klienta obsługuje to automatycznie.

2. Zaimplementuj wzorzec przerywacza obwodów, aby uniknąć nadmiernego obciążenia pamięci.

3. Jeśli N ponownych prób nie powiedzie się, wykonaj zasadne rozwiązanie alternatywne. Na przykład:

   • Zapisz dane w lokalnej pamięci podręcznej i przekaż operacje zapisu do pamięci masowej później, gdy usługa stanie się dostępna.
   • Jeśli akcja zapisu znajdowała się w zakresie transakcyjnym, skompensuj transakcję.

Diagnostyka. Użyj metryk przechowywania.

Odczytywanie danych z usługi Azure Storage kończy się niepowodzeniem.

Wykrywanie. Klient otrzymuje błędy podczas odczytywania.

Odzyskiwanie:

1. Spróbuj ponownie wykonać operację, aby odzyskać sprawność po przejściowych błędach. Polityka ponawiania prób w zestawie SDK klienta obsługuje to automatycznie.
2. W przypadku magazynu RA-GRS w przypadku niepowodzenia odczytu z podstawowego punktu końcowego spróbuj odczytać z pomocniczego punktu końcowego. Zestaw SDK klienta może obsługiwać to automatycznie. Zobacz replikację usługi Azure Storage.
3. Jeśli próby ponowienia N się nie powiodą, wykonaj akcję rezerwową, aby zachować płynność działania. Jeśli na przykład nie można pobrać obrazu produktu z magazynu, pokaż ogólny obraz zastępczy.

Diagnostyka. Użyj metryk przechowywania.

Maszyna wirtualna

Połączenie z maszyną wirtualną zaplecza kończy się niepowodzeniem.

Wykrywanie. Błędy połączenia sieciowego.

Odzyskiwanie:

• Wdróż co najmniej dwie maszyny wirtualne backendu w zestawie dostępności za pomocą modułu równoważenia obciążenia.
• Jeśli błąd połączenia jest przejściowy, czasami protokół TCP pomyślnie ponowi próbę wysłania komunikatu.
• Zaimplementuj zasady ponawiania prób w aplikacji.
• W przypadku trwałych lub nieprzejściowych błędów zaimplementuj wzorzec Wyłącznika Obwodu.
• Jeśli wywołująca maszyna wirtualna przekroczy limit ruchu wychodzącego sieci, kolejka wychodząca zostanie wypełniona. Jeśli kolejka wychodząca jest spójnie pełna, rozważ skalowanie w poziomie.

Diagnostyka. Rejestruj zdarzenia na granicach usługi.

Instancja maszyny wirtualnej staje się niedostępna lub niezdrowa.

Wykrywanie. Skonfiguruj test kondycji modułu równoważenia obciążenia, który sygnalizuje, czy instancja maszyny wirtualnej jest w dobrej kondycji. Sonda powinna sprawdzić, czy funkcje krytyczne odpowiadają poprawnie.

Odzyskiwanie. Dla każdej warstwy aplikacji umieść wiele wystąpień maszyn wirtualnych w tym samym zestawie dostępności i umieść moduł równoważenia obciążenia przed maszynami wirtualnymi. Jeśli sonda kondycji się nie powiedzie, moduł równoważenia obciążenia przestanie wysyłać nowe połączenia do niezdrowej instancji.

Diagnostyka. — Użyj analizy dzienników usługi Load Balancer.

• Skonfiguruj system monitorowania, aby monitorować wszystkie punkty końcowe monitorowania kondycji.

Operator przypadkowo zamyka maszynę wirtualną.

Wykrywanie. Nie dotyczy

Odzyskiwanie. Ustaw blokadę zasobu na poziomie ReadOnly. Zobacz Blokowanie zasobów za pomocą usługi Azure Resource Manager.

Diagnostyka. Użyj dzienników aktywności platformy Azure.

Następne kroki

Zobacz Zidentyfikuj zależności w ramach Azure Well-Architected Framework. Wbudowanie mechanizmów odzyskiwania po awarii w systemie powinno być częścią etapów architektury i projektowania od samego początku, aby uniknąć ryzyka awarii.