Inleiding tot de Foutanalyseservice

De Fault Analysis Service is ontworpen voor het testen van services die zijn gebouwd op Microsoft Azure Service Fabric. Met de Fault Analysis Service kunt u zinvolle fouten veroorzaken en volledige testscenario's uitvoeren voor uw toepassingen. Deze fouten en scenario's oefenen uit en valideren de talrijke statussen en overgangen die een service gedurende de hele 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 om ingewikkelde scenario's te schrijven. Voorbeeld:

• 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 aan voor een stateful service 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 in-memory status volledig wordt gewist.

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

• Chaosscenario
• Failoverscenario

Testen als een service

De Fault Analysis Service is een Service Fabric-systeemservice die automatisch wordt gestart met een Service Fabric-cluster. Deze service fungeert als de host voor foutinjectie, testscenario-uitvoering 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 Fault Analysis Service 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 Fault Analysis Service. En omdat er tests in het cluster worden uitgevoerd, kan de service de status van het cluster en uw services onderzoeken om uitgebreidere informatie over fouten te bieden.

Gedistribueerde systemen testen

Service Fabric maakt het schrijven en beheren van gedistribueerde schaalbare toepassingen aanzienlijk eenvoudiger. De Fault Analysis Service 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 belangrijkste aspecten van Service Fabric is dat gedistribueerde toepassingen kunnen herstellen van verschillende fouten. Als u echter wilt testen of de toepassing kan herstellen van deze fouten, hebben we een mechanisme nodig om deze echte fouten in een gecontroleerde testomgeving te simuleren/genereren.
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 in de echte wereld kan plaatsvinden als gevolg van de interacties van deze individuele fouten is niet-triviaal.
3. Geïntegreerde 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 met één doos, tot het uitvoeren van dezelfde tests in grote testomgevingen, tot 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 vereiste garanties, helemaal vanuit een one-box ontwikkelaarsomgeving, om te testen in productieclusters. De Fault Analysis Service helpt de toepassingsontwikkelaars zich te concentreren op het testen van hun bedrijfslogica. De Fault Analysis Service biedt alle mogelijkheden die nodig zijn om de interactie van de service met het onderliggende gedistribueerde systeem te testen.

Foutscenario's in de praktijk simuleren/genereren

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

1. Geef vanuit de client een afsluitknooppuntaanvraag 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 wordt 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 is uitgeschakeld wanneer de opdracht het knooppunt heeft bereikt. In beide gevallen moet de test in staat zijn om correct te redeneren over de status en slagen of mislukken in de validatie. Een systeem dat buiten Service Fabric wordt geïmplementeerd om dezelfde set fouten uit te voeren, kan veel netwerk-, hardware- en softwareproblemen raken, waardoor het niet de voorgaande garanties kan bieden. In aanwezigheid van de eerder genoemde problemen, zal Service Fabric de clusterstatus opnieuw configureren om de problemen te omzeilen, en daarom kan de Foutanalyseservice nog steeds de juiste set garanties geven.

Vereiste gebeurtenissen en scenario's genereren

Hoewel het simuleren van een echte fout consistent lastig is om mee te beginnen, is de mogelijkheid om gecorreleerde fouten te genereren nog moeilijker. Een gegevensverlies treedt bijvoorbeeld op in een stateful persistente service wanneer de volgende dingen gebeuren:

1. Alleen een schrijfquorum van de replica's wordt bij de replicatie opgevangen. Alle secundaire replica's lopen achter op de primaire replica.
2. Het schrijfquorum gaat omlaag omdat de replica's omlaag gaan (vanwege een codepakket of knooppunt dat uitvalt).
3. Het schrijfquorum kan niet worden teruggezet omdat de gegevens voor de replica's verloren gaan (vanwege schijfbeschadiging of het opnieuw instellen van de computer).

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

Uniforme ervaring in verschillende omgevingen

De praktijk is traditioneel geweest 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 waarmee eenheidstests van afzonderlijke methoden zijn toegestaan.
2. Maak in de testomgeving fouten om end-to-end tests toe te staan die verschillende foutscenario's uitvoeren.
3. Houd de productieomgeving ongerept om eventuele niet-natuurlijke fouten te voorkomen en ervoor te zorgen dat er extreem snelle menselijke reactie op fouten is.

In Service Fabric, via de Foutanalyseservice, stellen we voor om dit om te zetten en dezelfde methodologie te gebruiken van de ontwikkelomgeving naar de productieomgeving. Er zijn twee manieren om dit te bereiken:

1. Als u gecontroleerde fouten wilt veroorzaken, gebruikt u de Fault Analysis Service-API's van een omgeving met één box tot productieclusters.
2. Als u het cluster koorts wilt geven die automatische inductie van fouten veroorzaakt, gebruikt u de Foutanalyseservice om automatische fouten te genereren. Door de snelheid van fouten via de configuratie te beheren, kan dezelfde service anders worden getest in verschillende omgevingen.

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

De Foutanalyseservice gebruiken

C#

De functies van Fault Analysis Service bevinden zich in de System.Fabric-naamruimte in het NuGet-pakket Microsoft.ServiceFabric. Als u de functies van 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 voor gebruik.

Volgende stappen

Om echt cloudservices te maken, is het essentieel om ervoor te zorgen dat services, zowel vóór als na de implementatie, 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 zeer belangrijk. De Fault Analysis Service helpt serviceontwikkelaars om dat precies te doen.

Begin met het testen van uw toepassingen en services met behulp van de ingebouwde testscenario's of ontwerp uw eigen testscenario's met behulp van de foutacties die worden geleverd door de Fault Analysis Service.