Modelowanie kondycji dla obciążeń o krytycznym znaczeniu

Artykuł
2025-03-08

Monitorowanie aplikacji i infrastruktury jest ważną częścią każdego wdrożenia infrastruktury. W przypadku obciążenia o krytycznym znaczeniu monitorowanie jest krytyczną częścią wdrożenia. Monitorowanie kondycji aplikacji i kluczowych metryk zasobów platformy Azure pomaga zrozumieć, czy środowisko działa zgodnie z oczekiwaniami.

Aby w pełni zrozumieć te metryki i ocenić ogólną kondycję obciążenia, wymaga całościowego zrozumienia wszystkich monitorowanych danych. Model kondycji może pomóc w ocenie ogólnego stanu kondycji, wyświetlając wyraźne wskazanie kondycji obciążenia zamiast nieprzetworzonych metryk. Stan jest często przedstawiany jako wskaźniki "światła drogowego", takie jak czerwony, zielony lub żółty. Reprezentacja modelu kondycji z jasnymi wskaźnikami ułatwia operatorowi zrozumienie ogólnej kondycji obciążenia i szybkie reagowanie na pojawiające się problemy.

Modelowanie kondycji można rozszerzyć na następujące zadania operacyjne dla wdrożenia o krytycznym znaczeniu:

Usługa kondycji aplikacji — składnik aplikacji w klastrze obliczeniowym, który udostępnia interfejs API w celu określenia stanu aplikacji.
Monitorowanie — zbieranie liczników wydajności i aplikacji, które oceniają kondycję i wydajność aplikacji i infrastruktury.
Alerty — alerty z możliwością działania dotyczące problemów lub awarii w infrastrukturze i aplikacji.
Analiza niepowodzeń — podział i analiza wszelkich awarii, w tym dokumentacja głównej przyczyny.

Te zadania stanowią kompleksowy model kondycji infrastruktury o krytycznym znaczeniu. Opracowywanie modelu kondycji może i powinno być wyczerpującą i integralną częścią każdego wdrożenia o znaczeniu krytycznym.

Aby uzyskać więcej informacji, zobacz Modelowanie kondycji i obserwowanie obciążeń o znaczeniu krytycznym na platformie Azure.

Usługa zdrowia aplikacji

Usługa kondycji aplikacji (HealthService) to składnik aplikacji, który działa wraz z Usługą katalogu (CatalogService) i Usługą przetwarzania w tle (BackgroundProcessor) w klastrze obliczeniowym. Usługa HealthService udostępnia interfejs API REST, który Azure Front Door może wywołać, aby określić stan znacznika. HealthService to złożony składnik, który odzwierciedla stan zależności, jak również jego własny.

Gdy klaster obliczeniowy nie działa, usługa zdrowotna nie odpowiada. Gdy usługi są uruchomione, przeprowadza okresowe kontrole względem następujących składników w infrastrukturze:

Próbuje wykonać zapytanie względem usługi Azure Cosmos DB.
Próbuje wysłać komunikat do usługi Event Hubs. Pracownik w tle filtruje komunikat.
Wyszukuje plik stanu na koncie magazynującym. Ten plik może służyć do wyłączenia regionu, nawet jeśli inne sprawdzenia nadal działają poprawnie. Ten plik może służyć do komunikowania się z innymi procesami. Na przykład, jeśli pieczęć ma zostać usunięta do celów konserwacji, plik można usunąć, aby wymusić stan nieprawidłowy i przekierować ruch sieciowy.
Wysyła zapytanie do modelu kondycji, aby określić, czy wszystkie metryki operacyjne znajdują się w wstępnie określonych progach. Gdy model zdrowia wskazuje, że znacznik jest niezdrowy, ruch nie powinien być kierowany do znacznika, nawet jeśli inne testy przeprowadzane przez usługę HealthService kończą się pomyślnie. Model kondycji ma bardziej pełny widok stanu kondycji.

Wszystkie wyniki kontroli kondycji są buforowane w pamięci przez konfigurowalną liczbę sekund, domyślnie 10. Ta operacja może spowodować dodanie małego opóźnienia w wykrywaniu awarii, ale gwarantuje, że nie każde zapytanie HealthService wymaga wywołań zaplecza, co zmniejsza obciążenie klastra i usług podrzędnych.

Ten wzorzec buforowania jest istotny, ponieważ liczba zapytań usługi HealthService znacznie rośnie w przypadku korzystania z routera globalnego, takiego jak Azure Front Door: każdy węzeł brzegowy w każdym centrum danych platformy Azure, które obsługuje żądania, wywołuje usługę HealthService, aby określić, czy ma funkcjonalne połączenie zaplecza. Buforowanie wyników zmniejsza dodatkowe obciążenie klastra generowane przez kontrole kondycji.

Konfigurowanie

HealthService i CatalogService mają wspólne ustawienia konfiguracji między składnikami, z wyjątkiem następujących ustawień używanych wyłącznie przez usługę HealthService:

Ustawienie	Wartość
`HealthServiceCacheDurationSeconds`	Określa czas wygaśnięcia pamięci podręcznej w sekundach.
`HealthServiceStorageConnectionString`	Parametry połączenia dla konta magazynowego, w którym jest plik stanu.
`HealthServiceBlobContainerName`	Kontener magazynu, w którym powinien znajdować się plik stanu.
`HealthServiceBlobName`	Nazwa pliku stanu — kontrola stanu zdrowia wyszukuje ten plik.
`HealthServiceOverallTimeoutSeconds`	Limit czasu dla całego sprawdzenia — wartość domyślna to 3 sekundy. Jeśli sprawdzanie nie zostanie zakończone w tym interwale, usługa zgłasza złą kondycję.

Implementacja

Wszystkie kontrole są wykonywane asynchronicznie i równolegle. Jeśli którykolwiek z nich zakończy się niepowodzeniem, cała sygnatura zostanie uznana za niedostępną.

Wyniki sprawdzania są buforowane w pamięci przy użyciu standardowego, niedystrybuowanego ASP.NET Core MemoryCache. SysConfig.HealthServiceCacheDurationSeconds steruje wygaśnięciem pamięci podręcznej. Ustawienie domyślne to 10 sekund.

Uwaga

Ustawienie konfiguracji SysConfig.HealthServiceCacheDurationSeconds zmniejsza dodatkowe obciążenie generowane przez kontrole kondycji, ponieważ nie każde żądanie powoduje wywołanie podrzędne do usług zależnych.

Poniższa tabela zawiera szczegółowe informacje na temat kontroli kondycji składników w infrastrukturze:

Składnik	Sprawdzanie kondycji
Konto magazynu Blob	Sprawdzanie obiektu blob obecnie służy dwóm celom: 1. Przetestuj, czy jest możliwe dotarcie do usługi Blob Storage. Konto magazynowe jest używane przez inne składniki w komponencie i jest uznawane za zasób krytyczny. 2. Ręcznie "wyłącz" region, usuwając plik stanu. Podjęto decyzję projektową, że sprawdzenie ma się ograniczać do szukania obecności pliku stanu w określonym kontenerze blobów. Zawartość pliku nie jest przetwarzana. Istnieje możliwość skonfigurowania bardziej zaawansowanego systemu, który odczytuje zawartość pliku i zwraca inny stan na podstawie zawartości pliku. Przykłady zawartości to DOBRA KONDYCJA, ZŁA KONDYCJA I KONSERWACJA. Usunięcie pliku stanu powoduje dezaktywację pieczęci. Upewnij się, że plik kontrolny jest obecny po wdrożeniu aplikacji. Brak pliku zdrowia powoduje, że usługa zawsze odpowiada komunikatem NIEZDROWY. Usługa Front Door nie rozpoznaje serwera zaplecza jako dostępnego. program Terraform tworzy plik, który powinien być obecny po wdrożeniu infrastruktury.
Centrum zdarzeń	Raportowanie stanu usługi Event Hubs obsługuje `EventHubProducerService`. Ta usługa zgłasza dobrą kondycję, jeśli jest w stanie wysłać nową wiadomość do usługi Event Hubs. Do filtrowania ten komunikat ma dodaną właściwość identyfikującą: `HEALTHCHECK=TRUE` Ten komunikat jest ignorowany po stronie odbiorcy. Ustawienie `AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync()` konfiguracji sprawdza właściwość `HEALTHCHECK` .
Azure Cosmos DB	Raportowanie kondycji Azure Cosmos DB obsługuje `CosmosDbService`, która zgłasza dobrą kondycję, jeśli spełnione są warunki: 1. Możliwość nawiązywania połączenia z bazą danych usługi Azure Cosmos DB i wykonywania zapytania. 2. Możliwość zapisania dokumentu testowego w bazie danych. Dokument testowy ma krótki czas wygaśnięcia. Usługa Azure Cosmos DB automatycznie je usuwa. Usługa HealthService wykonuje dwie oddzielne sondy. Jeśli usługa Azure Cosmos DB jest w stanie, w którym operacje odczytu i zapisu nie działają, te dwie sondy zapewniają wyzwolenie alertu.

Zapytania usługi Azure Cosmos DB

W przypadku zapytania tylko do odczytu używane jest następujące zapytanie, które nie pobiera żadnych danych i nie ma dużego wpływu na ogólne obciążenie:

SELECT GetCurrentDateTime ()

Zapytanie zapisu tworzy manekin ItemRating z minimalną zawartością:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

Monitorowanie

Azure Log Analytics jest używany jako centralny magazyn dzienników i metryk dla wszystkich składników aplikacji i infrastruktury. aplikacja systemu Azure Insights jest używana dla wszystkich danych monitorowania aplikacji. Każda instancja w infrastrukturze ma dedykowany obszar roboczy usługi Log Analytics i instancję usługi Application Insights. Oddzielny obszar roboczy usługi Log Analytics jest używany dla zasobów udostępnionych globalnie, takich jak usługi Front Door i Azure Cosmos DB.

Wszystkie znaczki są krótkotrwałe i stale zastępowane przy każdym nowym wydaniu. Obszary robocze Log Analytics w podziale na jednostki są wdrażane jako zasób globalny w oddzielnej grupie zasobów monitorowania, podobnie jak inne zasoby Log Analytics. Te zasoby nie dzielą cyklu życia pieczęci.

Aby uzyskać więcej informacji, zobacz Ujednolicone repozytorium danych do analizy skorelowanej.

Monitorowanie: źródła danych

Ustawienia diagnostyczne: wszystkie usługi platformy Azure używane na potrzeby usługi Azure Mission-Critical są skonfigurowane do wysyłania wszystkich danych diagnostycznych, w tym dzienników i metryk do obszaru roboczego usługi Log Analytics specyficznego dla wdrożenia (globalnego lub sygnatury). Ten proces odbywa się automatycznie w ramach wdrożenia programu Terraform. Nowe opcje są identyfikowane automatycznie i dodawane w ramach terraform apply.
Monitorowanie rozwiązania Kubernetes: ustawienia diagnostyczne służą do wysyłania dzienników i metryk usługi Azure Kubernetes Service (AKS) do usługi Log Analytics. Usługa AKS jest skonfigurowana do używania usługi Container Insights. Usługa Container Insights wdraża moduł OMSAgentForLinux za pośrednictwem zestawu DaemonSet platformy Kubernetes w każdym węźle w klastrach AKS. Narzędzie OMSAgentForLinux może zbierać dodatkowe dzienniki i metryki z klastra Kubernetes i wysyła je do odpowiedniego obszaru roboczego usługi Log Analytics. Te dodatkowe logi i metryki zawierają bardziej szczegółowe dane dotyczące zasobników, wdrożeń, usług i ogólnej kondycji klastra. Aby uzyskać więcej szczegółowych informacji z różnych składników, takich jak ingress-nginx, cert-manager i inne składniki wdrożone na platformie Kubernetes obok obciążenia o krytycznym znaczeniu, można użyć narzędzia Prometheus scraping. Narzędzie funkcjonalności scraping Prometheus konfiguruje OMSAgentForLinux do zbierania metryk z Prometheus z różnych punktów końcowych w klastrze.
Monitorowanie danych usługi Application Insights: Usługa Application Insights służy do zbierania danych dotyczących monitorowania z aplikacji. Kod jest instrumentowany w celu zbierania danych dotyczących wydajności aplikacji przy użyciu zestawu SDK usługi Application Insights. Informacje krytyczne, takie jak wynikowy kod stanu i czas trwania wywołań zależności, i liczniki dla nieobsługiwanych wyjątków, są zbierane. Te informacje są używane w modelu kondycji i są dostępne do zgłaszania alertów i rozwiązywania problemów.

Monitorowanie: testy dostępności usługi Application Insights

Aby monitorować dostępność poszczególnych znaczków oraz pełnego rozwiązania z zewnętrznego punktu widzenia, testy dostępności Application Insights Availability Tests są konfigurowane w dwóch miejscach.

Regionalne testy dostępności: te testy są konfigurowane w regionalnych wystąpieniach Application Insights i wykorzystywane do monitorowania dostępności znaczków. Testy te dotyczą klastrów i statycznych kont magazynowych pieczęci bezpośrednio. Aby bezpośrednio wywoływać punkty wejściowe klastrów, żądania muszą zawierać prawidłowy nagłówek identyfikatora Front Door, w przeciwnym razie kontroler ruchu wejściowego odrzuca wywołania.
Globalny test dostępności: Testy te są konfigurowane w globalnym wystąpieniu Application Insights i służą do monitorowania dostępności całego rozwiązania poprzez wysyłanie poleceń ping do Front Door. Używane są dwa testy: jeden do testowania wywołania interfejsu API względem usługi CatalogService i jednego do testowania strony głównej witryny internetowej.

Monitorowanie: zapytania

Usługa Azure Mission-Critical używa różnych zapytań języka Kusto Query Language (KQL) do implementowania niestandardowych zapytań jako funkcje w celu pobierania danych z usługi Log Analytics. Te zapytania są przechowywane jako pojedyncze pliki w naszym repozytorium kodu, oddzielnie dla wdrożeń globalnych i sygnaturowych. Są one importowane i stosowane automatycznie za pośrednictwem narzędzia Terraform przy każdym uruchomieniu potoku infrastruktury.

Takie podejście oddziela logikę zapytania od warstwy wizualizacji. Zapytania usługi Log Analytics są wywoływane bezpośrednio z kodu, na przykład z interfejsu API usługi HealthService. Innym przykładem jest narzędzie do wizualizacji, takie jak pulpity nawigacyjne platformy Azure, skoroszyty monitora lub narzędzie Grafana.

Monitorowanie: wizualizacja

Używamy Grafany do wizualizacji wyników zapytań dotyczących kondycji Log Analytics w naszej wersji referencyjnej. Aplikacja Grafana wyświetla wyniki zapytań usługi Log Analytics i nie zawiera żadnej logiki. Wypuszczamy stos Grafana oddzielnie od cyklu wdrażania rozwiązania.

Aby uzyskać więcej informacji, zobacz Wizualizacja.

Generowanie alertów

Alerty są ważną częścią ogólnej strategii operacji. Proaktywne monitorowanie, takie jak korzystanie z pulpitów nawigacyjnych, powinno być używane z alertami, które zwracają natychmiastową uwagę na problemy.

Te alerty stanowią rozszerzenie modelu zdrowia, ostrzegając operatora o zmianie stanu zdrowia, czy to na pogorszony/żółty, czy też na niezdrowy/czerwony. Ustawiając alert w węźle głównym modelu kondycji, operator natychmiast jest świadomy jakiegokolwiek wpływu na poziomie biznesowym na stan rozwiązania: W końcu ten węzeł główny zmieni kolor na żółty lub czerwony, jeśli którykolwiek z podstawowych przepływów użytkownika lub zasobów zgłosi żółtą lub czerwoną metrykę. Operator może zwrócić uwagę na wizualizację Modelu kondycji na potrzeby rozwiązywania problemów.

Aby uzyskać więcej informacji, zobacz Automatyczną odpowiedź na zdarzenia.

Analiza niepowodzeń

Tworzenie analizy niepowodzeń jest głównie teoretycznym ćwiczeniem planowania. To ćwiczenie teoretyczne powinno być używane jako dane wejściowe dla automatycznych iniekcji błędów, które są częścią procesu ciągłej walidacji. Symulując tryby awarii zdefiniowane w tym miejscu, możemy zweryfikować odporność rozwiązania na te błędy, aby zminimalizować awarie.

W poniższej tabeli wymieniono przykładowe przypadki awarii różnych składników implementacji referencyjnej Azure Mission-Critical.

Usługa	Ryzyko	Wpływ/Łagodzenie/Komentarz	Awaria
Microsoft Entra ID	Identyfikator Entra firmy Microsoft staje się niedostępny.	Obecnie nie ma możliwości ograniczenia ryzyka. Podejście obejmujące wiele regionów nie ogranicza przestojów, ponieważ jest to usługa globalna. Ta usługa jest twardą zależnością. Identyfikator Microsoft Entra ID jest używany do operacji w płaszczyźnie sterowania, takich jak tworzenie nowych węzłów AKS, pobieranie obrazów kontenerów z ACR lub uzyskiwanie dostępu do Key Vault podczas uruchamiania podu. Istniejące, uruchomione składniki powinny być w stanie działać, gdy występują problemy z identyfikatorem Entra firmy Microsoft. Prawdopodobnie nowe zasobniki ani węzły AKS nie mogą się pojawić. W przypadku przeprowadzania operacji skalowania w tym czasie może to prowadzić do pogorszenia doświadczenia użytkownika i potencjalnie prowadzić do awarii.	Częściowe
Usługa DNS platformy Azure	Usługa Azure DNS stanie się niedostępna, a rozpoznawanie nazw DNS kończy się niepowodzeniem.	Jeśli usługa Azure DNS stanie się niedostępna, rozpoznawanie nazw DNS dla żądań użytkowników i między różnymi składnikami aplikacji kończy się niepowodzeniem. Obecnie nie ma możliwego ograniczenia ryzyka dla tego scenariusza. Podejście obejmujące wiele regionów nie ogranicza przestojów, ponieważ jest to usługa globalna. Usługa Azure DNS jest twardą zależnością. Zewnętrzne usługi DNS jako kopia zapasowa nie pomogłyby, ponieważ wszystkie używane składniki PaaS polegają na Azure DNS. Pomijanie systemu DNS przez przełączenie na adres IP nie jest opcją. Usługi platformy Azure nie mają statycznych, gwarantowanych adresów IP.	Pełny
Drzwi wejściowe	Ogólna awaria usługi Front Door.	Jeśli usługa Front Door ulegnie całkowitej awarii, nie ma środków zaradczych. Ta usługa jest twardą zależnością.	Tak
Drzwi frontowe	Błędy konfiguracji routingu/frontonu/zaplecza.	Może się zdarzyć z powodu niezgodności konfiguracji podczas wdrażania. Należy wychwycić podczas etapów testowania. Konfiguracja frontonu z systemem DNS jest specyficzna dla każdego środowiska. Działania naprawcze: Przywrócenie poprzedniej konfiguracji powinno rozwiązać większość problemów. Ponieważ wdrożenie zmian w usłudze Front Door trwa kilka minut, powoduje to przerwę w działaniu.	Pełny
Drzwi frontowe	Zarządzany certyfikat TLS/SSL jest usuwany.	Może się zdarzyć z powodu niezgodności konfiguracji podczas wdrażania. Powinny zostać wychwycone na etapach testowania. Technicznie witryna nadal działa, ale błędy certyfikatu TLS/SSL uniemożliwiają użytkownikom uzyskiwanie do niej dostępu. Środki zaradcze: Ponowne wystawianie certyfikatu może potrwać około 20 minut, a także naprawienie i ponowne uruchomienie potoku.	Pełny
Azure Cosmos DB	Nazwa bazy danych/kolekcji została zmieniona.	Może się zdarzyć z powodu niezgodności konfiguracji podczas wdrażania — program Terraform zastąpi całą bazę danych, co może spowodować utratę danych. Można zapobiec utracie danych przy użyciu blokad na poziomie bazy danych/kolekcji. Aplikacja nie może uzyskać dostępu do żadnych danych. Należy zaktualizować konfigurację aplikacji i ponownie uruchomić zasobniki.	Tak
Azure Cosmos DB	Awaria regionalna	Usługa Azure Mission-Critical ma włączone zapisy w wielu regionach. Jeśli wystąpi błąd podczas odczytu lub zapisu, klient ponawia próbę bieżącej operacji. Wszystkie przyszłe operacje są trwale kierowane do następnego regionu w kolejności preferencji. Jeśli lista preferencji miała jeden wpis (lub był pusty), ale konto ma dostępne inne regiony, zostanie przekierowany do następnego regionu na liście kont.	Nie.
Azure Cosmos DB	Duże ograniczanie przepustowości spowodowane brakiem jednostek RU.	W zależności od liczby jednostek RU i równoważenia obciążenia stosowanego na poziomie usługi Front Door niektóre sygnatury mogą być uruchamiane gorąco przy użyciu usługi Azure Cosmos DB, podczas gdy inne sygnatury mogą obsługiwać więcej żądań. Środki zaradcze: Lepszy rozkład obciążenia lub więcej jednostek RU.	Nie.
Azure Cosmos DB	Pełna partycja	Limit rozmiaru partycji logicznej usługi Azure Cosmos DB wynosi 20 GB. Jeśli dane klucza partycji w kontenerze osiągną ten rozmiar, dodatkowe żądania zapisu kończą się niepowodzeniem z powodu błędu "Klucz partycji osiągnął maksymalny rozmiar".	Tryb częściowy (zapisy do bazy danych są wyłączone)
Azure Container Registry	Awaria regionalna	Rejestr kontenerów używa usługi Traffic Manager do przełączania w tryb failover między regionami repliki. Każde żądanie powinno zostać automatycznie przekierowane do innego regionu. W najgorszym przypadku węzły usługi AKS nie ściągają obrazów platformy Docker przez kilka minut, podczas przełączenia awaryjnego DNS.	Nie.
Azure Container Registry	Usunięty obraz lub obrazy	Nie można ściągnąć żadnych obrazów. Może to wpłynąć jedynie na nowo utworzone/ponownie uruchomione węzły. Istniejące węzły powinny mieć obrazy buforowane. **Środki zaradcze: jeśli wykryto szybkie ponowne uruchomienie najnowszych potoków kompilacji, powinno przywrócić obrazy do rejestru.	Nie.
Azure Container Registry	Ograniczanie przepływności	Ograniczanie przepustowości może opóźniać operacje zwiększania skali, prowadząc do tymczasowego obniżenia wydajności. Środki zaradcze: Usługa Azure Mission-Critical używa jednostki SKU w warstwie Premium, która zapewnia 10 000 operacji odczytu na minutę. Obrazy kontenerów są zoptymalizowane i mają tylko niewielką liczbę warstw. Właściwość ImagePullPolicy jest ustawiona na IfNotPresent, aby najpierw używać lokalnie buforowanych wersji. Komentarz: Ściąganie obrazu kontenera składa się z wielu operacji odczytu w zależności od liczby warstw. Liczba operacji odczytu na minutę jest ograniczona i zależy od rozmiaru SKU ACR.	Nie.
Azure Kubernetes Service	Aktualizacja klastra kończy się niepowodzeniem.	Uaktualnienia węzłów usługi AKS powinny być przeprowadzane o różnych porach w różnych środowiskach. Jeśli jedno uaktualnienie zakończy się niepowodzeniem, drugi klaster nie powinien zostać dotknięty. Uaktualnienia klastra powinny być wdrażane w sposób stopniowy w węzłach, aby zapobiec niedostępności wszystkich węzłów.	Nie.
Azure Kubernetes Service	Pod aplikacji jest przerywany podczas przetwarzania żądania.	Ten wynik może spowodować, że użytkownik końcowy napotka błędy i słabe środowisko użytkownika. Środki zaradcze: Platforma Kubernetes domyślnie usuwa zasobniki w sposób bezproblemowy. Zasobniki są najpierw usuwane z usług, a obciążenie otrzymuje SIGTERM z okresem na dokończenie, aby zakończyć otwarte żądania i zapisać dane przed zakończeniem. Kod aplikacji musi obsługiwać SIGTERM, a okres prolongaty może wymagać dostosowania, jeśli zamknięcie obciążenia trwa dłużej.	Nie.
Azure Kubernetes Service	Nie można dodać więcej węzłów z powodu niedostępności pojemności obliczeniowej w regionie.	Skalowanie procesów w górę lub na zewnątrz nie udaje się, ale nie powinno to wpływać na istniejące węzły oraz ich funkcjonowanie. W idealnym przypadku ruch powinien być automatycznie przesuwany do innych regionów na potrzeby równoważenia obciążenia.	Nie.
Azure Kubernetes Service	Subskrypcja osiągnęła limit przydziału rdzeni procesora CPU na dodawanie nowych węzłów.	Operacje skalowania w górę/w poziomie kończą się niepowodzeniem, ale nie powinny wpływać na istniejące węzły i ich działanie. W idealnym przypadku ruch powinien być automatycznie przesuwany do innych regionów na potrzeby równoważenia obciążenia.	Nie.
Azure Kubernetes Service	Nie można wystawiać/odnawiać certyfikatów TLS/SSL.	Klaster powinien zgłaszać niezdrową kondycję do usługi Front Door, a ruch powinien przechodzić do innych serwerów. Środki zaradcze: Zbadaj główną przyczynę problemu/niepowodzenia w odnawianiu.	Nie.
Azure Kubernetes Service	Gdy żądania/limity zasobów są niepoprawnie skonfigurowane, zasobniki mogą osiągnąć 100% wykorzystania procesora i żądania mogą się nie powieść. Mechanizm ponawiania prób aplikacji powinien mieć możliwość odzyskania żądań, które zakończyły się niepowodzeniem. Ponawianie prób może spowodować dłuższy czas trwania żądania, bez ujawniania błędu klientowi. Nadmierne obciążenie ostatecznie powoduje awarię.	Nie (jeśli obciążenie nie jest nadmierne)
Azure Kubernetes Service	Obrazy kontenerów zewnętrznych dostawców / rejestr niedostępny	Niektóre składniki, takie jak cert-manager i ingress-nginx, wymagają pobrania obrazów kontenerów i wykresów helm z zewnętrznych rejestrów kontenerów (ruch wychodzący). W przypadku niedostępności co najmniej jednego z tych repozytoriów lub obrazów, nowe instancje na nowych węzłach (gdzie obraz nie jest jeszcze buforowany) mogą nie być w stanie się uruchomić. Możliwe środki zaradcze: w niektórych scenariuszach warto zaimportować obrazy kontenerów zewnętrznych firm do rejestru kontenerów dla poszczególnych rozwiązań. Ten scenariusz zwiększa złożoność i powinien być starannie zaplanowany i zoperacjonalizowany.	Częściowo (podczas operacji skalowania i aktualizacji/uaktualniania)
Centrum zdarzeń	Nie można wysyłać komunikatów do usługi Event Hubs	Pieczęć nie może już być używana do operacji zapisu. Usługa zdrowotna powinna automatycznie to wykryć i wyjąć pieczęć z obiegu.	Nie.
Centrum zdarzeń	Nie można odczytać wiadomości przez BackgroundProcessor	Wiadomości ustawiają się w kolejce. Wiadomości nie powinny być utracone, ponieważ są one utrwalane. Obecnie ta usterka nie jest objęta Służbą Zdrowia. Powinno być stosowane monitorowanie/alerty na pracowniku, aby wykrywać błędy podczas odczytywania komunikatów. Środki zaradcze: stempel powinien zostać ręcznie wyłączony, dopóki problem nie zostanie rozwiązany.	Nie.
Konto magazynu	Konto magazynu nie jest używane przez pracownika dla punktu kontrolnego usługi Event Hubs	"Stamp nie przetwarza komunikatów z Event Hubs." Konto magazynowe jest również używane przez usługę Zdrowie. Usługa Zdrowia wykrywa problemy z magazynowaniem i powinna wyjąć znacznik z użycia. Można się spodziewać, że inne usługi w systemie również będą dotknięte jednocześnie.	Nie.
Konto magazynu	Statyczna witryna internetowa napotyka problemy.	Jeśli statyczna witryna internetowa napotka problemy, usługa Front Door wykryje ten błąd. Ruch nie jest kierowany do tego konta przechowywania. Buforowanie w usłudze Front Door może również złagodzić ten problem.	Nie.
Magazyn kluczy	Usługa Key Vault jest niedostępna przy operacjach `GetSecret`.	Kiedy nowe zasobniki się uruchomią, sterownik AKS CSI pobiera wszystkie wpisy tajne z usługi Key Vault, ale to działanie kończy się niepowodzeniem. Pody nie mogą się uruchomić. Obecnie jest dostępna automatyczna aktualizacja co 5 minut. Aktualizacja kończy się niepowodzeniem. Błędy powinny być wyświetlane w `kubectl describe pod`, ale pod nadal działa.	Nie.
Magazyn kluczy	Usługa Key Vault jest niedostępna dla operacji `GetSecret` lub `SetSecret`.	Nie można wykonać nowych wdrożeń. Obecnie ten błąd może spowodować zatrzymanie całego procesu wdrażania, nawet jeśli dotyczy tylko jednego regionu.	Nie.
Repozytorium Kluczy	Ograniczanie przepustowości Key Vault	Usługa Key Vault ma limit 1000 operacji na 10 sekund. Ze względu na automatyczną aktualizację sekretów, teoretycznie można osiągnąć ten limit, jeśli masz wiele (tysiące) zasobników w jednym środowisku. Możliwe środki zaradcze: Zmniejsz częstotliwość aktualizacji jeszcze bardziej lub wyłącz ją całkowicie.	Nie.
Aplikacja	Błąd konfiguracji	Niepoprawne parametry połączenia lub wpisy tajne wprowadzone do aplikacji. Złagodzone przez automatyczne wdrażanie (pipeline automatycznie obsługuje konfigurację) oraz wdrażanie aktualizacji metodą blue-green.	Nie.
Aplikacja	Wygasłe poświadczenia (zasób pieczęci)	Jeśli na przykład token SAS centrum zdarzeń lub klucz konta magazynu został zmieniony bez właściwego zaktualizowania ich w usłudze Key Vault, aby zasobniki mogły z nich korzystać, konkretny składnik aplikacji ulegnie awarii. Ta awaria powinna następnie wpłynąć na Służbę Zdrowia, a pieczęć powinna zostać automatycznie wycofana z obiegu. Środki zaradcze: użyj uwierzytelniania opartego na identyfikatorze Entra firmy Microsoft dla wszystkich usług, które go obsługują. AKS wymaga, aby zasobniki uwierzytelniały się za pomocą załadowanej identyfikacji Microsoft Entra (wersja zapoznawcza). Użycie Pod Identity zostało uwzględnione w implementacji wzorcowej. Okazało się, że Pod Identity nie jest obecnie wystarczająco stabilna i zdecydowano się jej nie używać w obecnej architekturze referencyjnej. Tożsamość poda może być rozwiązaniem w przyszłości.	Nie.
Aplikacja	Wygasłe poświadczenia (zasób udostępniony globalnie)	Jeśli na przykład klucz interfejsu API usługi Azure Cosmos DB został zmieniony bez prawidłowego zaktualizowania go we wszystkich magazynach kluczy Azure, aby zasobniki mogły z nich korzystać, odpowiednie składniki aplikacji przestają działać poprawnie. Ta awaria spowoduje jednoczesne wyłączenie wszystkich serwisów i przerwę w funkcjonowaniu całego systemu. Aby dowiedzieć się, jak obejść potrzebę użycia kluczy i wpisów tajnych przy użyciu uwierzytelniania Microsoft Entra, zobacz poprzedni element.	Pełny
Sieć wirtualna	Wyczerpano przestrzeń adresów IP w podsieci	Jeśli przestrzeń adresowa IP w podsieci zostanie wyczerpana, nie mogą mieć miejsca żadne operacje związane z rozbudową, takie jak tworzenie nowych węzłów AKS lub podów. Awaria nie występuje, ale może obniżyć wydajność i wpłynąć na doświadczenie użytkownika. Działania łagodzące: zwiększ przestrzeń adresową IP (jeśli to możliwe). Jeśli nie jest to możliwe, zwiększenie ilości zasobów na węzeł (większe SKU maszyny wirtualnej) lub na pod (więcej CPU/pamięci) może pomóc, aby każdy pod mógł obsługiwać więcej ruchu, zmniejszając w ten sposób potrzebę skalowania w poziomie.	Nie.

Następne kroki

Wdróż implementację referencyjną, aby uzyskać pełną wiedzę na temat zasobów i ich konfiguracji używanej w tej architekturze.

Implementacja: Mission-Critical Online

Udostępnij za pośrednictwem