Share via

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 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. W tym artykule omówiono również środki zaradcze i działania, które należy podjąć w przypadku wystąpienia awarii. Celem jest ograniczenie lub wyeliminowanie ryzyka przestoju lub utraty danych w przypadku wystąpienia awarii, zaplanowanych 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, aby typowe typy awarii nie dotyczyły awarii.

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ętu i oprogramowania są nieprzewidywalne. Najprostszym sposobem przetrwania błędów jest uruchomienie większej liczby kopii usługi w granicach błędów sprzętu lub oprogramowania.

Jeśli na przykład usługa jest uruchomiona tylko na jednej maszynie, awaria tej jednej maszyny jest awarią tej usługi. Prostym sposobem uniknięcia tej awarii jest upewnienie się, ż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 można utworzyć wystąpienie zastępcze w innym miejscu, a zmniejszenie pojemności nie spowoduje przeciążenia 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 obawiasz się utraty stojaka serwerów, uruchamiasz wiele stojaków. Jeśli martwisz się o utratę centrów danych, twoja 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 obejmująca wiele wystąpień fizycznych (maszyn, stojaków, centrów danych, regionów), nadal podlegasz niektórym typom równoczesnych awarii. Jednak pojedyncze, a nawet wiele awarii określonego typu (na przykład jedna maszyna wirtualna lub niepowodzenie łącza sieciowego) są automatycznie obsługiwane i nie są już "awarią".

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 niepowodzeniu przekształcania się w rzeczywiste awarie.

Mogą wystąpić przyczyny, dla których uruchomienie wdrożenia na tyle duże, aby obejmowało awarie, 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 dostępna 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 są:

  • Ogranicz dostęp operacyjny do środowiska.
  • Ściśle przeprowadzaj inspekcję niebezpiecznych operacji.
  • Wymuszanie automatyzacji, zapobieganie ręcznym lub poza pasmem zmian oraz weryfikowanie określonych zmian w środowisku przed ich wprowadzeniem.
  • Upewnij się, że operacje destrukcyjne są "miękkie". Operacje nietrwałe nie są wykonywane 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 zapewnia mechanizmy dotyczące zachowanych 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 w celu obsługi niektórych typów błędów usługi muszą mieć dodatkowy kod. Inne rodzaje awarii nie powinny być automatycznie rozwiązywane ze względów bezpieczeństwa i ciągłości działalności biznesowej.

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 są w oprogramowaniu. Obejmują one błędy systemu operacyjnego i samą usługę. Usługa Service Fabric automatycznie wykrywa tego typu błędy, 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 nie powiedzie się z jakiegokolwiek powodu.

Aby obsłużyć każdy pojedynczy błąd, najprostszą rzeczą, jaką można zrobić, jest upewnienie się, ż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 planowanymi lub nieplanowanymi awariami i zmianami infrastruktury albo planowanych zmian 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 Resource Manager klastra.

Domyślnie usługa Service Fabric uwzględnia domeny błędów i uaktualnień podczas planowania miejsca, w którym usługi powinny być uruchamiane. 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 pojedynczego błędu dla usługi. Dlatego zarządzanie domenami błędów i uaktualniania ma kluczowe znaczenie dla zapewnienia wysokiej dostępności usług.

Gdy używasz 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 usługi Service Fabric i usług są zgodne z tym samym modelem. Aby uzyskać więcej informacji na temat uaktualnień stopniowych, domen uaktualniania i modelu kondycji usługi Service Fabric, które pomagają zapobiegać niezamierzonym zmianom wpływającym na klaster i usługę, zobacz:

Układ klastra można wizualizować przy użyciu mapy klastra podanej w Service Fabric Explorer:

Węzły rozłożone między domeny błędów w 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 udostępnia, aby zachować normalne problemy operacyjne i awarie przed przekształceniem 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) w domenach błędów i uaktualnień.

Może również wystąpić wiele równoczesnych losowych awarii. Są one bardziej narażone na przestój lub rzeczywistą awarię.

Usługi bezstanowe

Liczba wystąpień dla usługi bezstanowej wskazuje żądaną liczbę wystąpień, które muszą być uruchomione. Jeśli dowolne (lub wszystkie) wystąpienia kończą się niepowodzeniem, usługa Service Fabric odpowiada, automatycznie tworząc wystąpienia zastępcze w innych węzłach. Usługa Service Fabric nadal tworzy zamiany, 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 z utrwalonego stanu.
  • Stan stanowy z nietrwałym stanem. (Stan jest przechowywany w pamięci).

Odzyskiwanie po awarii usługi stanowej zależy od typu usługi stanowej, liczby replik, które miały usługa, 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 serwerami pomocniczymi). 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 nie powiedzą się (powiedzmy dwa na pięć), możemy użyć wartości kworum do obliczenia, czy możemy odzyskać. (Ponieważ pozostałe trzy z pięciu replik są nadal w górę, gwarantuje to, że co najmniej jedna replika będzie zawierać kompletne dane).

Gdy kworum replik nie powiedzie się, 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 określić, czy pozostałe repliki (dwa na pięć) mają wystarczające dane, aby przywrócić partycję. W przypadkach, gdy usługa Service Fabric wykryje 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ę w 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ślanie, 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ą naprawiane. Czasami jednak awarie są trwałe. Czy awarie są trwałe, czy nie, zależy od tego, czy usługa stanowa utrzymuje stan, czy przechowuje ją tylko w pamięci:

    • W przypadku usług bez utrwalonego stanu awaria kworum lub większej liczby replik powoduje natychmiastową utratę kworum trwałego. Gdy usługa Service Fabric wykryje utratę kworum w stanowej usłudze nietrwale, 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 w przypadku ich odzyskania dane zostaną utracone z powodu nietrwałego charakteru usługi.
    • W przypadku usług trwałych stanowych niepowodzenie 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 ograniczoną gwarancją 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 została zadeklarowana utrata kworum (automatycznie lub za pośrednictwem akcji administracyjnej), usługa Service Fabric i usługi przechodzą do określenia, 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ększe postępy.

    Powodem, dla którego zawsze mówimy , że podejrzenie utraty danych jest możliwe, że pozostała replika ma cały taki sam stan, jak w przypadku utraty kworum. Jednak bez tego stanu do porównania nie ma dobrego sposobu, aby usługa Service Fabric lub operatorzy wiedzieli na pewno.

    Więc co 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.

      Na przykład jeśli informacje o współrzędnych dwóch różnych usługach, 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 dziennikach. Te informacje mogą być używane zgodnie z potrzebami, aby określić, czy istnieją jakieś wywołania odebrane i przetworzone w lokalizacji podstawowej, które nie były obecne w kopii zapasowej lub zreplikowane do tej konkretnej repliki. Te wywołania mogą wymagać odtworzenia lub dodania ich 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, oraz sprawdzenie, 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 oznacza, że wszystkie inne pozostałe repliki mogą być teraz niespójne z tą repliką. Zostaną one usunięte i ponownie skompilowane z tej repliki. Wartość false oznacza, że nie wprowadzono żadnych zmian stanu, więc inne repliki mogą zachować to, co mają.

Niezwykle ważne jest, aby autorzy usług ć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 momentach, 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 trwał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ż ponieść 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 przechodzenie w 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 potencjalnej utraty danych. Zamiast tego zalecamy znalezienie rozwiązania ukierunkowanego na Twoją sytuację. Zwykle lepiej jest po prostu poczekać, aż repliki w dół powróci.

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 był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. Zbieranie zrzutów awaryjnych i wykonywanie niezbędnych działań 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 wyświetlić węzły.

Czasami odzyskanie replik może być niemoż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 należy podjąć wszystkie wysiłki na rzecz 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 wyjścia z utraty kworum i potencjalnej utraty danych.
  • Jeśli klaster napotyka częste błędy, które powodują przejście usług do stanu utraty kworum i potencjalnej utraty danych jest akceptowalna, określenie odpowiedniej wartości KworumLossWaitDuration może pomóc usłudze w automatycznym odzyskiwaniu. 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 zawsze są uruchamiane z co najmniej trzema replikami, 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 nadal działa.

Usługi działającego klastra 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. Dane są jednak zachowywane.

W przypadku klastrów działających na platformie Azure możesz 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 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 jednego 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 aktywny/aktywny/pasywny z wieloma klastrami 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 dostępne w innych centrach danych lub regionach w przypadku 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 Deploy a Service Fabric cluster across Strefy dostępności (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ą, że obciążenia są dystrybuowane, 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 w klastrze, 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ść bazowego klastra.

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 usuną większość węzłów inicjowania w klastrze i nie zostaną szybko przywrócone, klaster zostanie automatycznie zamknięty. Następnie klaster 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 Silver lub Gold trwałość, podczas usuwania węzła inicjujące (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 będzie automatycznie korzystać 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 inicjuje, klaster zostanie zamknięty wkrótce potem.

Następne kroki