Wprowadzenie do usługi Analizy błędów

Usługa Analizy błędów jest przeznaczona do testowania usług opartych na Microsoft Azure Service Fabric. Usługa Analizy błędów umożliwia wywoływanie znaczących błędów i uruchamianie kompletnych scenariuszy testowych względem aplikacji. Te błędy i scenariusze wykonują ćwiczenia oraz weryfikują liczne stany i przejścia, które usługa będzie doświadczać przez cały okres istnienia, a wszystko to w kontrolowany, bezpieczny i spójny sposób.

Akcje to poszczególne błędy przeznaczone dla usługi na potrzeby jej testowania. Deweloper usługi może użyć ich jako bloków konstrukcyjnych do pisania skomplikowanych scenariuszy. Przykład:

• Uruchom ponownie węzeł, aby zasymulować dowolną liczbę sytuacji, w których maszyna lub maszyna wirtualna została ponownie uruchomiona.
• Przenieś replikę usługi stanowej, aby symulować równoważenie obciążenia, tryb failover lub uaktualnianie aplikacji.
• Wywołaj utratę kworum w usłudze stanowej, aby utworzyć sytuację, w której nie można kontynuować operacji zapisu, ponieważ nie ma wystarczającej liczby replik "kopii zapasowych" lub "pomocniczych", aby akceptować nowe dane.
• Wywołaj utratę danych w usłudze stanowej, aby utworzyć sytuację, w której cały stan w pamięci zostanie całkowicie wyczyszczony.

Scenariusze to złożone operacje składające się z co najmniej jednej akcji. Usługa Analizy błędów udostępnia dwa wbudowane kompletne scenariusze:

• Scenariusz chaosu
• Scenariusz trybu failover

Testowanie jako usługa

Usługa Analizy błędów to usługa systemowa usługi Service Fabric, która jest automatycznie uruchamiana z klastrem usługi Service Fabric. Ta usługa działa jako host do wstrzykiwania błędów, wykonywania scenariusza testowego i analizy kondycji.

Po zainicjowaniu akcji błędów lub scenariusza testowego polecenie jest wysyłane do usługi Analizy błędów w celu uruchomienia akcji błędów lub scenariusza testowego. Usługa Analizy błędów jest stanowa, dzięki czemu może niezawodnie uruchamiać błędy i scenariusze oraz weryfikować wyniki. Na przykład długotrwały scenariusz testowy może być niezawodnie wykonywany przez usługę Analizy błędów. Ponieważ testy są wykonywane wewnątrz klastra, usługa może zbadać stan klastra i usług, aby uzyskać bardziej szczegółowe informacje o awariach.

Testowanie systemów rozproszonych

Usługa Service Fabric znacznie ułatwia pisanie rozproszonych aplikacji skalowalnych i zarządzanie nimi. Usługa Analizy błędów ułatwia testowanie aplikacji rozproszonej. Podczas testowania należy rozwiązać trzy główne problemy:

1. Symulowanie/generowanie błędów, które mogą wystąpić w rzeczywistych scenariuszach: Jednym z ważnych aspektów usługi Service Fabric jest umożliwienie rozproszonym aplikacjom odzyskiwania po różnych awariach. Jednak aby przetestować, czy aplikacja może odzyskać sprawność po tych awariach, potrzebujemy mechanizmu do symulowania/generowania tych rzeczywistych awarii w kontrolowanym środowisku testowym.
2. Możliwość generowania skorelowanych błędów: podstawowe błędy w systemie, takie jak awarie sieci i awarie maszyny, są łatwe do utworzenia osobno. Generowanie znacznej liczby scenariuszy, które mogą wystąpić w świecie rzeczywistym w wyniku interakcji z tymi pojedynczymi awariami, nie jest trywialne.
3. Ujednolicone środowisko na różnych poziomach programowania i wdrażania: istnieje wiele systemów iniekcji błędów, które mogą wykonywać różne typy awarii. Jednak środowisko we wszystkich tych scenariuszach jest słabe podczas przechodzenia z scenariuszy deweloperskich z jednym urządzeniem do uruchamiania tych samych testów w dużych środowiskach testowych, aby używać ich do testów w środowisku produkcyjnym.

Chociaż istnieje wiele mechanizmów rozwiązywania tych problemów, system, który wykonuje to samo z wymaganymi gwarancjami — od jedno boxowego środowiska deweloperskiego do testowania w klastrach produkcyjnych — brakuje. Usługa Analizy błędów pomaga deweloperom aplikacji skoncentrować się na testowaniu logiki biznesowej. Usługa Analizy błędów udostępnia wszystkie możliwości potrzebne do przetestowania interakcji usługi z bazowym systemem rozproszonym.

Symulowanie/generowanie rzeczywistych scenariuszy awarii

Aby przetestować niezawodność rozproszonego systemu przed awariami, potrzebujemy mechanizmu generowania błędów. Chociaż teoretycznie generowanie awarii, takiej jak węzeł w dół, wydaje się proste, zaczyna osiągać ten sam zestaw problemów ze spójnością, które usługa Service Fabric próbuje rozwiązać. Jeśli na przykład chcemy zamknąć węzeł, wymagany przepływ pracy jest następujący:

1. Z poziomu klienta wyślij żądanie węzła zamknięcia.

2. Wyślij żądanie do odpowiedniego węzła.

   a. Jeśli węzeł nie zostanie znaleziony, powinien zakończyć się niepowodzeniem.

   b. Jeśli węzeł zostanie znaleziony, powinien zostać zwrócony tylko wtedy, gdy węzeł zostanie zamknięty.

Aby zweryfikować błąd z perspektywy testu, test musi wiedzieć, że po wywołaniu tego błędu faktycznie występuje błąd. Gwarancja zapewniana przez usługę Service Fabric polega na tym, że węzeł przejdzie w dół lub został już wyłączony, gdy polecenie dotarło do węzła. W obu przypadkach test powinien mieć prawidłową przyczynę stanu i powodzenia lub niepowodzenia w jego weryfikacji. System zaimplementowany poza usługą Service Fabric w celu wykonania tego samego zestawu awarii może napotkać wiele problemów z siecią, sprzętem i oprogramowaniem, co uniemożliwiłoby zapewnienie powyższych gwarancji. W obecności podanych wcześniej problemów usługa Service Fabric ponownie skonfiguruje stan klastra w celu obejścia problemów, dlatego usługa Analizy błędów nadal będzie mogła nadać odpowiedni zestaw gwarancji.

Generowanie wymaganych zdarzeń i scenariuszy

Podczas symulowania rzeczywistej awarii stale jest trudne do rozpoczęcia, możliwość generowania skorelowanych niepowodzeń jest jeszcze trudniejsza. Na przykład utrata danych występuje w stanowej utrwalonej usłudze, gdy wystąpią następujące elementy:

1. Tylko kworum zapisu replik jest przechwytywane podczas replikacji. Wszystkie repliki pomocnicze pozostaje w tyle za serwerem podstawowym.
2. Kworum zapisu spada z powodu spadku replik (z powodu awarii pakietu kodu lub węzła).
3. Kworum zapisu nie może wrócić, ponieważ dane replik zostaną utracone (z powodu uszkodzenia dysku lub ponownego utworzenia maszyny).

Te skorelowane awarie występują w świecie rzeczywistym, ale nie tak często, jak poszczególne awarie. Możliwość testowania tych scenariuszy przed ich rozpoczęciem w środowisku produkcyjnym ma kluczowe znaczenie. Jeszcze ważniejsze jest możliwość symulowania tych scenariuszy przy użyciu obciążeń produkcyjnych w kontrolowanych okolicznościach (w środku dnia ze wszystkimi inżynierami na pokładzie). To jest znacznie lepsze niż to się zdarzyć po raz pierwszy w produkcji o 2:00 rano.

Ujednolicone środowisko w różnych środowiskach

Praktyką tradycyjnie było tworzenie trzech różnych zestawów środowisk, jeden dla środowiska deweloperskiego, jeden dla testów i jeden dla środowiska produkcyjnego. Model był:

1. W środowisku projektowym twórz przejścia stanu, które umożliwiają testy jednostkowe poszczególnych metod.
2. W środowisku testowym wygeneruj błędy, aby umożliwić kompleksowe testy, które wykonują różne scenariusze awarii.
3. Zachowaj nieskazitelne środowisko produkcyjne, aby zapobiec wszelkim niepowodzeniu naturalnym i zapewnić bardzo szybką reakcję człowieka na awarie.

W usłudze Service Fabric, za pośrednictwem usługi Analizy błędów, proponujemy włączenie tej metody i użycie tej samej metodologii od środowiska deweloperskiego do środowiska produkcyjnego. Istnieją dwa sposoby osiągnięcia tego celu:

1. Aby wywołać kontrolowane awarie, użyj interfejsów API usługi Fault Analysis Service ze środowiska jedno box do klastrów produkcyjnych.
2. Aby dać klastrowi gorączkę, która powoduje automatyczne indukowanie awarii, użyj usługi Analizy błędów, aby wygenerować automatyczne błędy. Kontrolowanie szybkości awarii za pomocą konfiguracji umożliwia testowanie tej samej usługi w różnych środowiskach.

W przypadku usługi Service Fabric skala błędów różniłaby się w różnych środowiskach, jednak rzeczywiste mechanizmy byłyby identyczne. Umożliwia to znacznie szybsze wdrażanie potoku kodu do wdrożenia oraz możliwość testowania usług w ramach rzeczywistych obciążeń.

Korzystanie z usługi Analizy błędów

C#

Funkcje usługi Fault Analysis Service znajdują się w przestrzeni nazw System.Fabric w pakiecie NuGet Microsoft.ServiceFabric. Aby użyć funkcji usługi Analizy błędów, uwzględnij pakiet nuget jako odwołanie w projekcie.

Program PowerShell

Aby korzystać z programu PowerShell, należy zainstalować zestaw SDK usługi Service Fabric. Po zainstalowaniu zestawu SDK moduł ServiceFabric programu PowerShell zostanie automatycznie załadowany do użycia.

Następne kroki

Aby utworzyć naprawdę usługi w skali chmury, ważne jest zapewnienie, zarówno przed wdrożeniem, jak i po wdrożeniu, że usługi mogą wytrzymać rzeczywiste awarie. Obecnie w świecie usług możliwość szybkiego wprowadzania innowacji i szybkiego przenoszenia kodu do środowiska produkcyjnego jest bardzo ważna. Usługa Analizy błędów pomaga deweloperom usług w tym celu.

Rozpocznij testowanie aplikacji i usług przy użyciu wbudowanych scenariuszy testowych lub utwórz własne scenariusze testowe przy użyciu akcji błędów udostępnianych przez usługę Analizy błędów.