Wprowadzenie do usługi Analizy błędów
Usługa Analizy błędów jest przeznaczona do testowania usług opartych na usłudze 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 do testowania. Deweloper usługi może ich używać jako bloków konstrukcyjnych do pisania skomplikowanych scenariuszy. Na przykład:
- Uruchom ponownie węzeł, aby zasymulować dowolną liczbę sytuacji, w których maszyna lub maszyna wirtualna jest ponownie uruchamiana.
- 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 operacje zapisu nie mogą kontynuować, 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 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łędu lub scenariusza testowego polecenie jest wysyłane do usługi Analizy błędów w celu uruchomienia akcji błędu 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:
- 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.
- Możliwość generowania skorelowanych błędów: podstawowe błędy w systemie, takie jak awarie sieci i awarie maszyn, są łatwe do utworzenia osobno. Generowanie znacznej liczby scenariuszy, które mogą wystąpić w świecie rzeczywistym w wyniku interakcji z tymi poszczególnymi awariami, nie jest proste.
- 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 ze scenariuszy deweloperskich jedno box 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 — przez cały czas 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ę łatwe, zaczyna osiągać ten sam zestaw problemów ze spójnością, które próbuje rozwiązać usługa Service Fabric. Jeśli na przykład chcemy zamknąć węzeł, wymagany przepływ pracy jest następujący:
Od klienta należy wysłać żądanie węzła zamknięcia.
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ąpi awaria. 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 Analysis Service będzie nadal mogła udzielić odpowiedniego zestawu gwarancji.
Generowanie wymaganych zdarzeń i scenariuszy
Chociaż symulowanie rzeczywistej awarii stale jest trudne do rozpoczęcia, zdolność 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:
- Tylko kworum zapisu replik jest przechwytywane podczas replikacji. Wszystkie repliki pomocnicze są opóźniane za podstawową.
- Kworum zapisu spada z powodu spadku replik (ze względu na spadek pakietu kodu lub węzła).
- Kworum zapisu nie może zostać przywrócone, ponieważ dane replik zostaną utracone (z powodu uszkodzenia dysku lub ponownego utworzenia maszyny).
Te skorelowane błędy występują w świecie rzeczywistym, ale nie tak często, jak poszczególne błędy. 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 o wiele lepsze niż to się zdarzyć po raz pierwszy w produkcji o 2:00 rano.
Ujednolicone środowisko w różnych środowiskach
Tradycyjnie praktyką było utworzenie trzech różnych zestawów środowisk, po jednym dla środowiska deweloperskiego, jednego dla testów i jednego dla środowiska produkcyjnego. Model był:
- W środowisku projektowym tworzy przejścia stanu, które umożliwiają testy jednostkowe poszczególnych metod.
- W środowisku testowym wygeneruj błędy, aby umożliwić kompleksowe testy, które wykonują różne scenariusze awarii.
- Zachowaj nieskazitelne środowisko produkcyjne, aby zapobiec wszelkim niepowodzeniom naturalnym i zapewnić niezwykle szybką reakcję człowieka na awarię.
W usłudze Service Fabric, za pośrednictwem usługi Analizy błędów, zalecamy odwrócenie tej metody i użycie tej samej metodologii ze środowiska deweloperskiego do środowiska produkcyjnego. Istnieją dwa sposoby osiągnięcia tego celu:
- Aby wywołać kontrolowane awarie, użyj interfejsów API usługi Fault Analysis Service ze środowiska jedno box do klastrów produkcyjnych.
- Aby dać klastrowi gorączkę, która powoduje automatyczną indukcję 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, chociaż skala awarii byłaby inna w różnych środowiskach, rzeczywiste mechanizmy byłyby identyczne. Pozwala to na znacznie szybszy potok wdrażania kodu i możliwość testowania usług pod rzeczywistym obciążeniem.
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 Fault Analysis Service, dołącz pakiet NuGet jako odwołanie do projektu.
Program PowerShell
Aby użyć 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, należy zapewnić, 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 dokładnie to zrobić.
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.