Udostępnij za pośrednictwem

Odzyskiwanie po awarii w usłudze Azure Service Fabric

  • Artykuł

Krytyczną częścią dostarczania wysokiej dostępności jest zapewnienie, że usługi mogą przetrwać wszystkie różne typy awarii. Jest to szczególnie ważne w przypadku niepoplanowanych i spoza kontroli.

W tym artykule opisano niektóre typowe tryby awarii, które mogą być awariami, jeśli nie są prawidłowo modelowane i zarządzane. Omówiono również środki zaradcze i działania, które należy podjąć w przypadku awarii. Celem jest ograniczenie lub wyeliminowanie ryzyka przestoju lub utraty danych, gdy wystąpią awarie, planowane lub w inny sposób.

Unikanie awarii

Głównym celem usługi Azure Service Fabric jest ułatwienie modelowania środowiska i usług w taki sposób, że typowe typy błędów nie są awariami.

Ogólnie rzecz biorąc, istnieją dwa typy scenariuszy awarii/awarii:

  • Błędy sprzętowe i programowe
  • Błędy operacyjne

Błędy sprzętowe i programowe

Błędy sprzętowe i programowe są nieprzewidywalne. Najprostszym sposobem przetrwania błędów jest uruchomienie większej liczby kopii usługi na granicach błędów sprzętu lub oprogramowania.

Na przykład jeśli usługa jest uruchomiona tylko na jednej maszynie, awaria tej maszyny jest awarią tej usługi. Prostym sposobem uniknięcia tej awarii jest zapewnienie, że usługa jest uruchomiona na wielu maszynach. Testowanie jest również niezbędne, aby upewnić się, że awaria jednej maszyny nie zakłóca działania usługi. Planowanie pojemności gwarantuje, że wystąpienie zastępcze można utworzyć w innym miejscu i że zmniejszenie pojemności nie przeciąża pozostałych usług.

Ten sam wzorzec działa niezależnie od tego, czego próbujesz uniknąć awarii. Jeśli na przykład martwisz się o awarię sieci SAN, uruchomisz wiele sieci SAN. Jeśli martwisz się o utratę stojaka serwerów, uruchamiasz wiele stojaków. Jeśli martwisz się o utratę centrów danych, usługa powinna działać w wielu regionach świadczenia usługi Azure, w wielu Strefy dostępności platformy Azure lub we własnych centrach danych.

Gdy usługa jest objęta wieloma wystąpieniami fizycznymi (maszynami, stojakami, centrami danych, regionami), nadal podlegasz niektórym typom równoczesnych awarii. Jednak pojedyncze, a nawet wiele awarii określonego typu (na przykład awaria pojedynczej maszyny wirtualnej lub łącza sieciowego) są automatycznie obsługiwane i nie są już "katastrofą".

Usługa Service Fabric udostępnia mechanizmy rozszerzania klastra i obsługuje przywracanie węzłów i usług, które zakończyły się niepowodzeniem. Usługa Service Fabric umożliwia również uruchamianie wielu wystąpień usług, aby zapobiec nieplanowanym awariom, przekształcając się w rzeczywiste awarie.

Może być przyczyną, dla których uruchomienie wdrożenia wystarczająco duże, aby obejmować błędy, nie jest możliwe. Na przykład może to zająć więcej zasobów sprzętowych, niż chcesz płacić w stosunku do prawdopodobieństwa awarii. W przypadku aplikacji rozproszonych dodatkowe przeskoki komunikacji lub koszty replikacji stanu w różnych odległościach geograficznych mogą spowodować niedopuszczalne opóźnienie. Gdzie ten wiersz jest rysowany różni się dla każdej aplikacji.

W szczególności w przypadku błędów oprogramowania błąd może znajdować się w usłudze, którą próbujesz skalować. W takim przypadku więcej kopii nie zapobiega awarii, ponieważ warunek awarii jest skorelowany ze wszystkimi wystąpieniami.

Błędy operacyjne

Nawet jeśli twoja usługa jest rozpiętana na całym świecie z wieloma nadmiarowościami, nadal może wystąpić katastrofalne zdarzenia. Na przykład ktoś może przypadkowo ponownie skonfigurować nazwę DNS dla usługi lub usunąć ją wprost.

Załóżmy na przykład, że masz stanową usługę Service Fabric i ktoś przypadkowo usunął usługę. Chyba że istnieje inne środki zaradcze, ta usługa i cały stan, że już zniknął. Tego typu awarie operacyjne ("oops") wymagają różnych środków zaradczych i kroków odzyskiwania niż zwykłe nieplanowane awarie.

Najlepszym sposobem uniknięcia tego typu błędów operacyjnych jest:

  • Ogranicz dostęp operacyjny do środowiska.
  • Ściśle przeprowadź inspekcję niebezpiecznych operacji.
  • Wymuszanie automatyzacji, zapobieganie zmianom ręcznym lub poza pasmem oraz weryfikowanie określonych zmian w środowisku przed ich wprowadzeniem.
  • Upewnij się, że operacje destrukcyjne są "miękkie". Operacje nietrwałe nie działają natychmiast lub można je cofnąć w przedziale czasu.

Usługa Service Fabric udostępnia mechanizmy zapobiegania błędom operacyjnym, takim jak zapewnianie kontroli dostępu opartej na rolach dla operacji klastra. Jednak większość tych błędów operacyjnych wymaga wysiłków organizacyjnych i innych systemów. Usługa Service Fabric udostępnia mechanizmy pod kątem ocalałych błędów operacyjnych, w szczególności tworzenia kopii zapasowych i przywracania dla usług stanowych.

Zarządzanie błędami

Celem usługi Service Fabric jest automatyczne zarządzanie awariami. Jednak aby obsłużyć niektóre typy błędów, usługi muszą mieć dodatkowy kod. Inne typy awarii nie powinny być automatycznie rozwiązywane ze względów bezpieczeństwa i ciągłości działania.

Obsługa pojedynczych błędów

Pojedyncze maszyny mogą zakończyć się niepowodzeniem z różnych powodów. Czasami jest to przyczyna sprzętu, takich jak zasilacze i awarie sprzętu sieciowego. Inne błędy znajdują się w oprogramowaniu. Obejmują one błędy systemu operacyjnego i samą usługę. Usługa Service Fabric automatycznie wykrywa te typy awarii, w tym przypadki, w których maszyna staje się odizolowana od innych maszyn z powodu problemów z siecią.

Niezależnie od typu usługi uruchomienie pojedynczego wystąpienia powoduje przestój dla tej usługi, jeśli pojedyncza kopia kodu zakończy się niepowodzeniem z jakiegokolwiek powodu.

Aby obsłużyć dowolną pojedynczą awarię, najprostszą rzeczą, jaką można zrobić, jest zapewnienie, że usługi działają domyślnie na więcej niż jednym węźle. W przypadku usług bezstanowych upewnij się, że InstanceCount wartość jest większa niż 1. W przypadku usług stanowych minimalną rekomendacją jest to, że TargetReplicaSetSize obie MinReplicaSetSize wartości są ustawione na 3. Uruchomienie większej liczby kopii kodu usługi gwarantuje, że usługa może automatycznie obsługiwać wszystkie pojedyncze awarie.

Obsługa skoordynowanych błędów

Skoordynowane awarie w klastrze mogą być spowodowane zaplanowanymi lub nieplanowanymi awariami i zmianami infrastruktury albo zaplanowanymi zmianami oprogramowania. Usługa Service Fabric modeluje strefy infrastruktury, które doświadczają skoordynowanych awarii jako domen błędów. Obszary, które będą doświadczać skoordynowanych zmian oprogramowania, są modelowane jako domeny uaktualniania. Aby uzyskać więcej informacji o domenach błędów, domenach uaktualniania i topologii klastra, zobacz Opis klastra usługi Service Fabric przy użyciu usługi Resource Manager klastra.

Domyślnie usługa Service Fabric uwzględnia domeny błędów i uaktualniania podczas planowania miejsca, w którym powinny być uruchamiane usługi. Domyślnie usługa Service Fabric próbuje upewnić się, że usługi działają w kilku domenach błędów i uaktualnień, dzięki czemu w przypadku planowanych lub nieplanowanych zmian usługi pozostaną dostępne.

Załóżmy na przykład, że awaria źródła zasilania powoduje jednoczesne niepowodzenie wszystkich maszyn w stojaku. Po uruchomieniu wielu kopii usługi utrata wielu maszyn w błędzie domeny zamienia się w kolejny przykład pojedynczej awarii usługi. Dlatego zarządzanie domenami błędów i uaktualniania ma kluczowe znaczenie dla zapewnienia wysokiej dostępności usług.

Po uruchomieniu usługi Service Fabric na platformie Azure domeny błędów i domeny uaktualniania są zarządzane automatycznie. W innych środowiskach mogą nie być. Jeśli tworzysz własne klastry lokalnie, pamiętaj, aby prawidłowo mapować i planować układ domeny błędów.

Domeny uaktualniania są przydatne w przypadku obszarów modelowania, w których oprogramowanie zostanie uaktualnione w tym samym czasie. W związku z tym domeny uaktualniania często definiują również granice, w których oprogramowanie jest wyłączane podczas planowanych uaktualnień. Uaktualnienia zarówno usługi Service Fabric, jak i usługi są zgodne z tym samym modelem. Aby uzyskać więcej informacji na temat uaktualnień stopniowego, domen uaktualniania i modelu kondycji usługi Service Fabric, który pomaga zapobiec niezamierzonym zmianom wpływającym na klaster i usługę, zobacz:

Układ klastra można wizualizować przy użyciu mapy klastra udostępnionej w narzędziu Service Fabric Explorer:

Węzły rozmieszczone między domenami błędów w narzędziu Service Fabric Explorer

Uwaga

Modelowanie obszarów awarii, uaktualnień stopniowego, uruchamiania wielu wystąpień kodu usługi i stanu, reguł umieszczania w celu zapewnienia, że usługi działają w domenach błędów i uaktualnień, a wbudowane monitorowanie kondycji to tylko niektóre funkcje, które usługa Service Fabric zapewnia, aby zachować normalne problemy operacyjne i awarie z przekształcania się w awarie.

Obsługa równoczesnych awarii sprzętu lub oprogramowania

Mówiliśmy o pojedynczych awariach. Jak widać, są one łatwe w obsłudze zarówno dla usług bezstanowych, jak i stanowych, dzięki przechowywaniu większej liczby kopii kodu (i stanu) działających w domenach błędów i uaktualnień.

Może się również zdarzyć wiele równoczesnych losowych awarii. Są one bardziej prawdopodobne, aby doprowadzić do przestoju lub rzeczywistej awarii.

Usługi bezstanowe

Liczba wystąpień dla usługi bezstanowej wskazuje żądaną liczbę wystąpień, które muszą być uruchomione. Gdy dowolne (lub wszystkie) wystąpienia kończą się niepowodzeniem, usługa Service Fabric reaguje automatycznie, tworząc wystąpienia zastępcze w innych węzłach. Usługa Service Fabric nadal tworzy zamienniki, dopóki usługa nie wróci do żądanej liczby wystąpień.

Załóżmy na przykład, że usługa bezstanowa ma InstanceCount wartość -1. Ta wartość oznacza, że jedno wystąpienie powinno być uruchomione w każdym węźle w klastrze. Jeśli niektóre z tych wystąpień nie powiedzą się, usługa Service Fabric wykryje, że usługa nie znajduje się w żądanym stanie i spróbuje utworzyć wystąpienia w węzłach, w których brakuje.

Usługi stanowe

Istnieją dwa typy usług stanowych:

  • Stan stanowy ze stanem trwałym.
  • Stan stanowy z stanem nietrwałym. (Stan jest przechowywany w pamięci).

Odzyskiwanie po awarii usługi stanowej zależy od typu usługi stanowej, liczby replik, których usługa miała, oraz liczby replik, które zakończyły się niepowodzeniem.

W usłudze stanowej dane przychodzące są replikowane między replikami (podstawowymi i dowolnymi aktywnymi sekundami). Jeśli większość replik odbiera dane, dane są uznawane za zatwierdzone kworum . (W przypadku pięciu replik trzy będą kworum). Oznacza to, że w dowolnym momencie będzie co najmniej kworum replik z najnowszymi danymi. Jeśli repliki kończą się niepowodzeniem (powiedzmy dwa na pięć), możemy użyć wartości kworum, aby obliczyć, czy możemy odzyskać. (Ponieważ pozostałe trzy z pięciu replik są nadal w górę, gwarantowane jest, że co najmniej jedna replika będzie zawierać pełne dane).

Gdy kworum replik kończy się niepowodzeniem , partycja jest zadeklarowana jako w stanie utraty kworum. Załóżmy, że partycja ma pięć replik, co oznacza, że co najmniej trzy mają gwarancję posiadania pełnych danych. Jeśli kworum (trzy na pięć) replik nie powiedzie się, usługa Service Fabric nie może ustalić, czy pozostałe repliki (dwa na pięć) mają wystarczającą ilość danych do przywrócenia partycji. W przypadkach, gdy usługa Service Fabric wykrywa utratę kworum, jego domyślnym zachowaniem jest zapobieganie dodatkowym zapisom w partycji, deklarowanie utraty kworum i oczekiwanie na przywrócenie kworum replik.

Określenie, czy wystąpiła awaria dla usługi stanowej, a następnie zarządzanie nią odbywa się na trzech etapach:

  1. Określanie, czy wystąpiła utrata kworum, czy nie.

    Utrata kworum jest deklarowana, gdy większość replik usługi stanowej nie działa w tym samym czasie.

  2. Określenie, czy utrata kworum jest trwała, czy nie.

    W większości przypadków błędy są przejściowe. Procesy są ponownie uruchamiane, węzły są ponownie uruchamiane, maszyny wirtualne są ponownie uruchamiane, a partycje sieciowe są przywracane. Czasami jednak błędy są trwałe. Czy awarie są trwałe, czy nie zależą od tego, czy usługa stanowa utrzymuje stan, czy przechowuje ją tylko w pamięci:

    • W przypadku usług bez stanu trwałego awaria kworum lub większej liczby replik powoduje natychmiastową utratę kworum. Gdy usługa Service Fabric wykryje utratę kworum w stanowej nietrwale usługi, natychmiast przejdzie do kroku 3, deklarując (potencjalną) utratę danych. Przejście do utraty danych ma sens, ponieważ usługa Service Fabric wie, że nie ma sensu czekać na powrót replik. Nawet jeśli zostaną odzyskane, dane zostaną utracone z powodu nietrwałego charakteru usługi.
    • W przypadku usług trwałych stanowych błąd kworum lub więcej replik powoduje, że usługa Service Fabric czeka na powrót replik i przywrócenie kworum. Powoduje to awarię usługi dla wszystkich zapisów w partycji, której dotyczy problem (lub "zestaw replik") usługi. Jednak odczyty mogą być nadal możliwe z ograniczonymi gwarancjami spójności. Domyślny czas oczekiwania na przywrócenie kworum przez usługę Service Fabric jest nieskończony, ponieważ kontynuowanie to (potencjalne) zdarzenie utraty danych i niesie ze sobą inne zagrożenia. Oznacza to, że usługa Service Fabric nie przejdzie do następnego kroku, chyba że administrator podejmie działania w celu zadeklarowania utraty danych.

  3. Określanie, czy dane zostaną utracone, i przywrócenie z kopii zapasowych.

    Jeśli utrata kworum została zadeklarowana (automatycznie lub za pośrednictwem akcji administracyjnej), usługa Service Fabric i usługi przechodzą do określania, czy dane zostały rzeczywiście utracone. W tym momencie usługa Service Fabric wie również, że inne repliki nie wracają. To była decyzja podjęta, gdy przestaliśmy czekać na utratę kworum, aby rozwiązać się. Najlepszym sposobem działania usługi jest zwykle zamrożenie i oczekiwanie na określoną interwencję administracyjną.

    Gdy usługa Service Fabric wywołuje metodęOnDataLossAsync, zawsze jest to spowodowane podejrzeniem utraty danych. Usługa Service Fabric zapewnia, że to wywołanie jest dostarczane do najlepszej pozostałej repliki. Jest to dowolna replika, która poczyniła największy postęp.

    Powodem, dla którego zawsze mówimy , że podejrzewamy utratę danych, jest możliwość, że pozostała replika ma taki sam stan, jak w przypadku utraty kworum. Jednak bez tego stanu, aby go porównać, nie ma dobrego sposobu, aby usługa Service Fabric lub operatory wiedziały na pewno.

    Co więc robi typowa implementacja OnDataLossAsync metody?

    1. Dzienniki implementacji, które OnDataLossAsync zostały wyzwolone i wyzwalane są wszelkie niezbędne alerty administracyjne.

    2. Zazwyczaj implementacja wstrzymuje się i czeka na podjęcie dalszych decyzji i akcji ręcznych. Dzieje się tak, ponieważ nawet jeśli kopie zapasowe są dostępne, może być konieczne przygotowanie ich.

      Jeśli na przykład dwie różne usługi koordynują informacje, może być konieczne zmodyfikowanie tych kopii zapasowych, aby upewnić się, że po zakończeniu przywracania informacje o tych dwóch usługach są spójne.

    3. Często istnieją inne dane telemetryczne lub wyczerpanie z usługi. Te metadane mogą być zawarte w innych usługach lub w dziennikach. Te informacje mogą być używane zgodnie z potrzebami, aby określić, czy istnieją jakiekolwiek wywołania odebrane i przetworzone w lokalizacji podstawowej, które nie były obecne w kopii zapasowej lub replikowane do tej konkretnej repliki. Te wywołania mogą być konieczne odtworzona lub dodana do kopii zapasowej przed wykonaniem przywracania.

    4. Implementacja porównuje stan pozostałej repliki z tym, który znajduje się w dowolnych dostępnych kopiach zapasowych. Jeśli używasz niezawodnych kolekcji usługi Service Fabric, dostępne są narzędzia i procesy . Celem jest sprawdzenie, czy stan w ramach repliki jest wystarczający i zobaczyć, czego może brakować kopii zapasowej.

    5. Po zakończeniu porównania i zakończeniu przywracania (w razie potrzeby) kod usługi powinien zwrócić wartość true , jeśli wprowadzono jakiekolwiek zmiany stanu. Jeśli replika ustali, że jest to najlepsza dostępna kopia stanu i nie wprowadzono żadnych zmian, kod zwraca wartość false.

      Wartość true wskazuje, że wszystkie pozostałe repliki mogą być teraz niespójne z tą repliką. Zostaną one usunięte i ponownie skompilowane z tej repliki. Wartość false wskazuje, że nie wprowadzono żadnych zmian stanu, więc inne repliki mogą zachować to, co mają.

Niezwykle ważne jest, aby autorzy usługi ćwiczyli potencjalne scenariusze utraty danych i awarii przed wdrożeniem usług w środowisku produkcyjnym. Aby chronić się przed możliwością utraty danych, ważne jest, aby okresowo tworzyć kopie zapasowe stanu dowolnych usług stanowych w magazynie geograficznie nadmiarowym.

Należy również upewnić się, że masz możliwość przywrócenia stanu. Ponieważ kopie zapasowe wielu różnych usług są wykonywane w różnych godzinach, należy upewnić się, że po przywróceniu usługi mają spójny widok nawzajem.

Rozważmy na przykład sytuację, w której jedna usługa generuje liczbę i przechowuje ją, a następnie wysyła ją do innej usługi, która również ją przechowuje. Po przywróceniu można wykryć, że druga usługa ma liczbę, ale pierwsza nie, ponieważ jej kopia zapasowa nie zawierała tej operacji.

Jeśli okaże się, że pozostałe repliki są niewystarczające do kontynuowania w scenariuszu utraty danych i nie można odtworzyć stanu usługi z telemetrii lub wyczerpania, częstotliwość tworzenia kopii zapasowych określa najlepszy możliwy cel punktu odzyskiwania (RPO). Usługa Service Fabric udostępnia wiele narzędzi do testowania różnych scenariuszy awarii, w tym stałego kworum i utraty danych, które wymagają przywrócenia z kopii zapasowej. Te scenariusze są uwzględniane jako część narzędzi do testowania w usłudze Service Fabric zarządzanych przez usługę Analizy błędów. Aby uzyskać więcej informacji na temat tych narzędzi i wzorców, zobacz Wprowadzenie do usługi Analizy błędów.

Uwaga

Usługi systemowe mogą również cierpieć na utratę kworum. Wpływ jest specyficzny dla danej usługi. Na przykład utrata kworum w usłudze nazewnictwa ma wpływ na rozpoznawanie nazw, podczas gdy utrata kworum w usłudze Menedżer trybu failover blokuje tworzenie nowych usług i tryb failover.

Usługi systemowe usługi Service Fabric są zgodne z tym samym wzorcem co usługi do zarządzania stanem, ale nie zalecamy próby przeniesienia ich z utraty kworum i do potencjalnej utraty danych. Zamiast tego zalecamy znalezienie rozwiązania ukierunkowanego na Twoją sytuację. Zwykle zaleca się po prostu poczekać, aż repliki w dół zwrócą.

Rozwiązywanie problemów z utratą kworum

Repliki mogą być sporadycznie wyłączone z powodu błędu przejściowego. Poczekaj chwilę, gdy usługa Service Fabric próbuje je wywołać. Jeśli repliki zostały wyłączone przez więcej niż oczekiwany czas trwania, wykonaj następujące czynności rozwiązywania problemów:

  • Repliki mogą ulegać awarii. Sprawdź raporty kondycji na poziomie repliki i dzienniki aplikacji. Zbierz zrzuty awaryjne i podejmij niezbędne akcje w celu odzyskania.
  • Proces repliki mógł nie odpowiadać. Sprawdź dzienniki aplikacji, aby to sprawdzić. Zbierz zrzuty procesów, a następnie zatrzymaj proces, który nie odpowiada. Usługa Service Fabric utworzy proces wymiany i spróbuje przywrócić replikę.
  • Węzły hostujące repliki mogą nie działać. Uruchom ponownie podstawową maszynę wirtualną, aby przywrócić węzły.

Czasami odzyskanie replik może nie być możliwe. Na przykład dyski nie powiodły się lub maszyny fizycznie nie odpowiadają. W takich przypadkach usługa Service Fabric musi nie czekać na odzyskiwanie repliki.

Nie należy używać tych metod, jeśli potencjalna utrata danych jest niedopuszczalna, aby usługa stała się w trybie online. W takim przypadku wszystkie wysiłki należy wykonać w celu odzyskania maszyn fizycznych.

Następujące akcje mogą spowodować utratę danych. Przed ich wykonaniem sprawdź.

Uwaga

Nigdy nie można bezpiecznie używać tych metod innych niż w sposób ukierunkowany na określone partycje.

  • Użyj interfejsu Repair-ServiceFabricPartition -PartitionId API lub System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) . Ten interfejs API umożliwia określenie identyfikatora partycji w celu przeniesienia z utraty kworum i do potencjalnej utraty danych.
  • Jeśli klaster napotka częste błędy powodujące przejście usług do stanu utraty kworum, a potencjalna utrata danych jest akceptowalna, określenie odpowiedniej wartości kworumLossWaitDuration może pomóc w automatycznym odzyskaniu usługi. Usługa Service Fabric będzie czekać na podaną QuorumLossWaitDuration wartość (wartość domyślna jest nieskończona) przed wykonaniem odzyskiwania. Nie zalecamy tej metody, ponieważ może to spowodować nieoczekiwane straty danych.

Dostępność klastra usługi Service Fabric

Ogólnie rzecz biorąc, klaster usługi Service Fabric jest wysoce rozproszonym środowiskiem bez pojedynczych punktów awarii. Awaria jednego węzła nie spowoduje problemów z dostępnością ani niezawodnością klastra, przede wszystkim dlatego, że usługi systemowe usługi Service Fabric są zgodne z tymi samymi wytycznymi podanymi wcześniej. Oznacza to, że są one zawsze uruchamiane z co najmniej trzema replikami domyślnie, a usługi systemowe, które są bezstanowe uruchamiane na wszystkich węzłach.

Podstawowe warstwy sieci i wykrywania błędów usługi Service Fabric są w pełni rozproszone. Większość usług systemowych można odtworzyć z metadanych w klastrze lub wiedzieć, jak ponownie zsynchronizować ich stan z innych miejsc. Dostępność klastra może zostać naruszona, jeśli usługi systemowe przejdą do sytuacji utraty kworum, takich jak opisane wcześniej. W takich przypadkach może nie być możliwe wykonanie pewnych operacji w klastrze (na przykład uruchomienie uaktualnienia lub wdrożenie nowych usług), ale sam klaster jest nadal w górę.

Usługi w uruchomionym klastrze będą nadal działać w tych warunkach, chyba że wymagają zapisu w usługach systemowych w celu kontynuowania działania. Jeśli na przykład Menedżer trybu failover jest w stanie utraty kworum, wszystkie usługi będą nadal działać. Jednak wszystkie usługi, które kończą się niepowodzeniem, nie będą mogły zostać automatycznie uruchomione ponownie, ponieważ wymaga to zaangażowania Menedżera trybu failover.

Błędy centrum danych lub regionu świadczenia usługi Azure

W rzadkich przypadkach fizyczne centrum danych może stać się tymczasowo niedostępne z powodu utraty zasilania lub łączności sieciowej. W takich przypadkach klastry i usługi Service Fabric w tym centrum danych lub regionie świadczenia usługi Azure będą niedostępne. Jednak dane są zachowywane.

W przypadku klastrów działających na platformie Azure można wyświetlać aktualizacje awarii na stronie stanu platformy Azure. W przypadku wysoce mało prawdopodobnego, że fizyczne centrum danych jest częściowo lub w pełni zniszczone, wszystkie klastry usługi Service Fabric hostowane tam lub usługi wewnątrz nich mogą zostać utracone. Ta utrata obejmuje żaden stan, którego kopia zapasowa nie została utworzona poza tym centrum danych lub regionem.

Istnieje kilka różnych strategii utrzymania trwałej lub trwałej awarii pojedynczego centrum danych lub regionu:

  • Uruchom oddzielne klastry usługi Service Fabric w wielu takich regionach i użyj mechanizmu przejścia w tryb failover i powrotu po awarii między tymi środowiskami. Ten rodzaj modelu wielokrotnego klastra aktywnego/aktywnego/pasywnego wymaga dodatkowego kodu zarządzania i operacji. Ten model wymaga również koordynacji kopii zapasowych z usług w jednym centrum danych lub regionie, aby były one dostępne w innych centrach danych lub regionach, gdy ulegnie awarii.

  • Uruchom pojedynczy klaster usługi Service Fabric obejmujący wiele centrów danych. Minimalna obsługiwana konfiguracja dla tej strategii to trzy centra danych. Aby uzyskać więcej informacji, zobacz Wdrażanie klastra usługi Service Fabric w Strefy dostępności.

    Ten model wymaga dodatkowej konfiguracji. Jednak zaletą jest to, że awaria jednego centrum danych jest konwertowana z awarii na normalną awarię. Te błędy mogą być obsługiwane przez mechanizmy, które działają dla klastrów w jednym regionie. Domeny błędów, domeny uaktualniania i reguły umieszczania usługi Service Fabric zapewniają dystrybucję obciążeń, aby tolerowały normalne awarie.

    Aby uzyskać więcej informacji na temat zasad, które mogą pomóc w obsłudze usług tego typu klastra, zobacz Zasady umieszczania dla usług Service Fabric.

  • Uruchom pojedynczy klaster usługi Service Fabric obejmujący wiele regionów przy użyciu modelu autonomicznego. Zalecana liczba regionów to trzy. Aby uzyskać szczegółowe informacje na temat autonomicznej konfiguracji usługi Service Fabric, zobacz Tworzenie klastra autonomicznego.

Losowe błędy, które prowadzą do awarii klastra

Usługa Service Fabric ma pojęcie węzłów inicjowania. Są to węzły, które utrzymują dostępność klastra bazowego.

Węzły inicjujące pomagają zapewnić, że klaster pozostaje w górę, ustanawiając dzierżawy z innymi węzłami i służąc jako tiebreakers podczas niektórych rodzajów awarii. Jeśli losowe awarie usuwają większość węzłów inicjowania w klastrze i nie są one szybko przywracane, klaster zostanie automatycznie zamknięty. Klaster następnie kończy się niepowodzeniem.

Na platformie Azure dostawca zasobów usługi Service Fabric zarządza konfiguracjami klastra usługi Service Fabric. Domyślnie dostawca zasobów dystrybuuje węzły inicjowane między domenami błędów i uaktualnień dla typu węzła podstawowego. Jeśli typ węzła podstawowego jest oznaczony jako trwałość Silver lub Gold, podczas usuwania węzła inicjowania (przez skalowanie w typie węzła podstawowego lub przez ręczne usunięcie go), klaster spróbuje podwyższyć poziom innego węzła innego niż inicjujący z dostępnej pojemności typu węzła podstawowego. Ta próba zakończy się niepowodzeniem, jeśli masz mniej dostępnej pojemności niż wymagany poziom niezawodności klastra dla typu węzła podstawowego.

W autonomicznych klastrach usługi Service Fabric i na platformie Azure podstawowym typem węzła jest ten, który uruchamia nasiona. Podczas definiowania typu węzła podstawowego usługa Service Fabric automatycznie skorzysta z liczby węzłów udostępnianych przez utworzenie maksymalnie dziewięciu węzłów inicjowania i siedmiu replik każdej usługi systemowej. Jeśli zestaw losowych awarii wyjmuje większość tych replik jednocześnie, usługi systemowe wprowadzają utratę kworum. Jeśli większość węzłów inicjowania zostanie utracona, klaster zostanie wkrótce zamknięty.

Następne kroki