Inleiding tot de foutanalyseservice

De foutanalyseservice is ontworpen voor het testen van services die zijn gebouwd op Microsoft Azure Service Fabric. Met de Foutanalyseservice kunt u zinvolle fouten veroorzaken en volledige testscenario's uitvoeren voor uw toepassingen. Deze fouten en scenario's oefenen en valideren de talrijke statussen en overgangen die een service gedurende de levensduur zal ervaren, allemaal op een gecontroleerde, veilige en consistente manier.

Acties zijn de afzonderlijke fouten die gericht zijn op een service om deze te testen. Een serviceontwikkelaar kan deze gebruiken als bouwstenen voor het schrijven van complexe scenario's. Bijvoorbeeld:

• Start een knooppunt opnieuw op om een willekeurig aantal situaties te simuleren waarin een machine of VM opnieuw wordt opgestart.
• Verplaats een replica van uw stateful service om taakverdeling, failover of toepassingsupgrade te simuleren.
• Roep quorumverlies op een stateful service aan om een situatie te creëren waarin schrijfbewerkingen niet kunnen worden voortgezet omdat er onvoldoende 'back-up'- of 'secundaire' replica's zijn om nieuwe gegevens te accepteren.
• Roep gegevensverlies aan op een stateful service om een situatie te creëren waarin alle statussen in het geheugen volledig worden gewist.

Scenario's zijn complexe bewerkingen die bestaan uit een of meer acties. De foutanalyseservice biedt twee ingebouwde volledige scenario's:

• Chaosscenario
• Failoverscenario

Testen als een service

De Foutanalyseservice is een Service Fabric-systeemservice die automatisch wordt gestart met een Service Fabric-cluster. Deze service fungeert als de host voor foutinjectie, uitvoering van testscenario's en statusanalyse.

Wanneer een foutactie of testscenario wordt gestart, wordt een opdracht verzonden naar de foutanalyseservice om de foutactie of het testscenario uit te voeren. De Foutanalyseservice is stateful, zodat fouten en scenario's betrouwbaar kunnen worden uitgevoerd en resultaten kunnen worden gevalideerd. Een langlopend testscenario kan bijvoorbeeld betrouwbaar worden uitgevoerd door de foutanalyseservice. En omdat er tests in het cluster worden uitgevoerd, kan de service de status van het cluster en uw services onderzoeken om gedetailleerdere informatie over fouten te bieden.

Gedistribueerde systemen testen

Service Fabric maakt het schrijven en beheren van gedistribueerde schaalbare toepassingen aanzienlijk eenvoudiger. De Foutanalyseservice maakt het testen van een gedistribueerde toepassing op dezelfde manier eenvoudiger. Er zijn drie belangrijke problemen die moeten worden opgelost tijdens het testen:

1. Fouten simuleren/genereren die kunnen optreden in praktijkscenario's: Een van de belangrijke aspecten van Service Fabric is dat gedistribueerde toepassingen kunnen herstellen van verschillende fouten. Om te testen of de toepassing kan herstellen van deze fouten, hebben we echter een mechanisme nodig om deze echte fouten te simuleren/genereren in een gecontroleerde testomgeving.
2. De mogelijkheid om gecorreleerde fouten te genereren: basisfouten in het systeem, zoals netwerkfouten en machinefouten, zijn eenvoudig afzonderlijk te produceren. Het genereren van een aanzienlijk aantal scenario's dat zich in de echte wereld kan voordoen als gevolg van de interacties van deze afzonderlijke fouten is niet triviaal.
3. Uniforme ervaring op verschillende niveaus van ontwikkeling en implementatie: Er zijn veel foutinjectiesystemen die verschillende soorten fouten kunnen uitvoeren. De ervaring in al deze scenario's is echter slecht wanneer u overstapt van scenario's voor ontwikkelaars met één doos, naar het uitvoeren van dezelfde tests in grote testomgevingen, naar het gebruik ervan voor tests in productie.

Hoewel er veel mechanismen zijn om deze problemen op te lossen, ontbreekt een systeem dat hetzelfde doet met de vereiste garanties, helemaal van een one-box ontwikkelaarsomgeving tot testen in productieclusters. De Foutanalyseservice helpt de ontwikkelaars van toepassingen zich te concentreren op het testen van hun bedrijfslogica. De Foutanalyseservice biedt alle mogelijkheden die nodig zijn om de interactie van de service met het onderliggende gedistribueerde systeem te testen.

Echte foutscenario's simuleren/genereren

Om de robuustheid van een gedistribueerd systeem te testen op fouten, hebben we een mechanisme nodig om fouten te genereren. Hoewel het genereren van een fout zoals een knooppunt offline in theorie eenvoudig lijkt, krijgt het dezelfde set consistentieproblemen die Service Fabric probeert op te lossen. Als we bijvoorbeeld een knooppunt willen afsluiten, is de vereiste werkstroom als volgt:

1. Geef vanuit de client een aanvraag voor het afsluiten van het knooppunt uit.

2. Verzend de aanvraag naar het juiste knooppunt.

   a. Als het knooppunt niet wordt gevonden, mislukt het.

   b. Als het knooppunt wordt gevonden, moet het alleen worden geretourneerd als het knooppunt is afgesloten.

Als u de fout vanuit een testperspectief wilt controleren, moet de test weten dat wanneer deze fout wordt veroorzaakt, de fout daadwerkelijk optreedt. De garantie die Service Fabric biedt, is dat het knooppunt uitvalt of al offline was toen de opdracht het knooppunt bereikte. In beide gevallen moet de test correct kunnen redeneren over de status en slagen of mislukken in de validatie. Een systeem dat buiten Service Fabric is geïmplementeerd om dezelfde set fouten uit te voeren, kan veel netwerk-, hardware- en softwareproblemen ondervinden, waardoor het de voorgaande garanties niet kan bieden. In aanwezigheid van de problemen die eerder zijn vermeld, configureert Service Fabric de clusterstatus opnieuw om de problemen te omzeilen. Daarom kan de Foutanalyseservice nog steeds de juiste set garanties geven.

Vereiste gebeurtenissen en scenario's genereren

Hoewel het lastig is om een echte fout consistent te simuleren, is het nog moeilijker om gecorreleerde fouten te genereren. Een gegevensverlies vindt bijvoorbeeld plaats in een stateful persistente service wanneer het volgende gebeurt:

1. Alleen een schrijfquorum van de replica's wordt ingehaald bij replicatie. Alle secundaire replica's blijven achter op de primaire replica.
2. Het schrijfquorum gaat omlaag omdat de replica's uitvalt (omdat een codepakket of knooppunt uitvalt).
3. Het schrijfquorum kan niet worden teruggezet omdat de gegevens voor de replica's verloren zijn gegaan (vanwege schijfbeschadiging of het herstellen van de computer).

Deze gecorreleerde fouten vinden wel plaats in de echte wereld, maar niet zo vaak als individuele fouten. De mogelijkheid om deze scenario's te testen voordat ze in productie plaatsvinden, is essentieel. Nog belangrijker is de mogelijkheid om deze scenario's te simuleren met productieworkloads in gecontroleerde omstandigheden (midden op de dag met alle engineers aan dek). Dat is veel beter dan dat het voor het eerst gebeurt in productie om 02:00 uur.

Uniforme ervaring in verschillende omgevingen

De praktijk is traditioneel om drie verschillende sets ervaringen te maken, één voor de ontwikkelomgeving, één voor tests en één voor productie. Het model was:

1. In de ontwikkelomgeving produceert u statusovergangen die eenheidstests van afzonderlijke methoden mogelijk maken.
2. In de testomgeving produceert u fouten om end-to-end-tests toe te staan die verschillende foutscenario's uitvoeren.
3. Houd de productieomgeving intact om eventuele niet-natuurlijke storingen te voorkomen en om ervoor te zorgen dat er zeer snelle menselijke reactie op fouten is.

In Service Fabric, via de Foutanalyseservice, stellen we voor om dit om te draaien en dezelfde methodologie te gebruiken, van ontwikkelaarsomgeving tot productie. U kunt dit op twee manieren doen:

1. Als u gecontroleerde fouten wilt veroorzaken, gebruikt u de Foutanalyseservice-API's van een one-box-omgeving tot aan productieclusters.
2. Als u het cluster koorts wilt geven die automatische inductie van storingen veroorzaakt, gebruikt u de Foutanalyseservice om automatische fouten te genereren. Als u de snelheid van fouten via configuratie beheert, kan dezelfde service op verschillende manieren worden getest in verschillende omgevingen.

Met Service Fabric zouden de werkelijke mechanismen identiek zijn, hoewel de schaal van fouten in de verschillende omgevingen anders zou zijn. Dit zorgt voor een veel snellere pijplijn voor code-naar-implementatie en de mogelijkheid om de services te testen onder werkelijke belasting.

De foutanalyseservice gebruiken

C#

Fault Analysis Service-functies bevinden zich in de System.Fabric-naamruimte in het Microsoft.ServiceFabric NuGet-pakket. Als u de functies van de Fault Analysis Service wilt gebruiken, neemt u het nuget-pakket op als referentie in uw project.

PowerShell

Als u PowerShell wilt gebruiken, moet u de Service Fabric SDK installeren. Nadat de SDK is geïnstalleerd, wordt de ServiceFabric PowerShell-module automatisch geladen zodat u deze kunt gebruiken.

Volgende stappen

Als u services op cloudschaal wilt maken, is het essentieel om ervoor te zorgen, zowel voor als na de implementatie, dat services bestand zijn tegen fouten in de echte wereld. In de huidige serviceswereld is de mogelijkheid om snel te innoveren en code snel naar productie te verplaatsen erg belangrijk. De Foutanalyseservice helpt serviceontwikkelaars om precies dat te doen.

Begin met het testen van uw toepassingen en services met behulp van de ingebouwde testscenario's of stel uw eigen testscenario's op met behulp van de foutacties die worden geleverd door de Foutanalyseservice.