Scénarios de testabilité

Les grands systèmes distribués, comme les infrastructures cloud, sont par définition peu fiables. Grâce à Azure Service Fabric, les développeurs sont en mesure d’écrire des services s’exécutant sur ces infrastructures. Pour écrire des services de haute qualité, les développeurs doivent pouvoir introduire de tels défauts de fiabilité, et ainsi tester la fiabilité des solutions qu’ils conçoivent.

Le service d’analyse des erreurs permet aux développeurs de provoquer des actions erronées afin de tester les services en présence de défaillances. Cependant, les erreurs simulées ciblées ne vous emmènent que jusqu’à un certain point. Pour approfondir les tests, vous pouvez utiliser les scénarios de test dans Service Fabric : un test de chaos et un test de basculement. Au sein du cluster, ces scénarios simulent des erreurs entrelacées en continu, avec et sans perte de données, sur des périodes prolongées. Une fois qu’un test est configuré avec le taux et le type d’erreurs, il peut être démarré via des API C# ou PowerShell pour générer des erreurs dans le cluster et votre service.

Avertissement

ChaosTestScenario est remplacé par un chaos plus robuste, basé sur le service. Pour plus d’informations, consultez le nouvel article Chaos contrôlé.

Test de chaos

Le scénario chaos génère des erreurs dans l’ensemble du cluster Service Fabric. Le scénario compresse les erreurs observées dans des mois ou des années à quelques heures. L’utilisation d’erreurs entrelacées avec un taux élevé d’erreurs permet d’identifier des dysfonctionnements qui n’auraient pu être isolés autrement. Il en résulte une amélioration significative de la qualité du code du service.

Erreurs simulées dans le test chaos

  • Redémarrer un nœud
  • Redémarrer un package de code déployé
  • Supprimer une réplique
  • Redémarrer une réplique
  • Déplacer une réplique principale (facultatif)
  • Déplacer une réplique secondaire (facultatif)

Le test de chaos exécute de multiples itérations de fautes et de validations de cluster pour la période spécifiée. Les délais de stabilisation du cluster et de validation sont également configurables. Le scénario échoue lorsqu'une seule erreur survient dans une validation de cluster.

Par exemple, supposons qu’un test soit défini pour s’exécuter une heure, avec un maximum de trois erreurs simultanées. Le test génère trois erreurs, puis valide l’intégrité du cluster. Le test itérera l’étape précédente jusqu’à ce que le cluster présente un défaut d’intégrité ou après une heure. Si le cluster devient défectueux dans une itération, autrement dit, il ne se stabilise pas dans un délai configuré, le test échoue avec une exception. Cette exception indique qu’une erreur est survenue et qu’un examen approfondi est nécessaire.

Dans sa forme actuelle, le moteur de génération de pannes du test chaos induit uniquement des défaillances sûres. Cela signifie qu’en l’absence d’erreurs externes, aucune perte de données ni de quorum ne survient.

Options de configuration importantes

  • TimeToRun : Temps total pendant lequel le test s'exécute avant de se terminer avec succès. Le test peut se terminer plus tôt en cas d'échec de validation.
  • MaxClusterStabilizationTimeout: délai maximal nécessaire à la restauration de l’intégrité du cluster, préalablement à l’échec du test. Les contrôles consistent à vérifier que l’intégrité du cluster est acceptable, que la taille cible du jeu de réplicas est atteinte pour l’ensemble des partitions et qu’aucun réplica InBuild n’existe.
  • MaxConcurrentFaults : nombre maximal d’erreurs simultanées introduites dans chaque itération. Plus le nombre est élevé, plus le test est efficace. Vous obtiendrez des combinaisons plus complexes de basculement et de transition. Le test garantit qu’en l’absence d’erreurs externes, il n’y aura pas de quorum ou de perte de données, quelle que soit la hauteur de cette configuration.
  • EnableMoveReplicaFaults: active ou désactive les erreurs provoquant le déplacement des réplicas primaires ou secondaires. Ces anomalies sont désactivées par défaut.
  • WaitTimeBetweenIterations : durée d’attente entre les itérations, autrement dit, après une série d’erreurs et de validation correspondante.

Procédure d’exécution du test chaos

Exemple de code C#

using System;
using System.Fabric;
using System.Fabric.Testability.Scenario;
using System.Threading;
using System.Threading.Tasks;

class Test
{
    public static int Main(string[] args)
    {
        string clusterConnection = "localhost:19000";

        Console.WriteLine("Starting Chaos Test Scenario...");
        try
        {
            RunChaosTestScenarioAsync(clusterConnection).Wait();
        }
        catch (AggregateException ae)
        {
            Console.WriteLine("Chaos Test Scenario did not complete: ");
            foreach (Exception ex in ae.InnerExceptions)
            {
                if (ex is FabricException)
                {
                    Console.WriteLine("HResult: {0} Message: {1}", ex.HResult, ex.Message);
                }
            }
            return -1;
        }

        Console.WriteLine("Chaos Test Scenario completed.");
        return 0;
    }

    static async Task RunChaosTestScenarioAsync(string clusterConnection)
    {
        TimeSpan maxClusterStabilizationTimeout = TimeSpan.FromSeconds(180);
        uint maxConcurrentFaults = 3;
        bool enableMoveReplicaFaults = true;

        // Create FabricClient with connection and security information here.
        FabricClient fabricClient = new FabricClient(clusterConnection);

        // The chaos test scenario should run at least 60 minutes or until it fails.
        TimeSpan timeToRun = TimeSpan.FromMinutes(60);
        ChaosTestScenarioParameters scenarioParameters = new ChaosTestScenarioParameters(
          maxClusterStabilizationTimeout,
          maxConcurrentFaults,
          enableMoveReplicaFaults,
          timeToRun);

        // Other related parameters:
        // Pause between two iterations for a random duration bound by this value.
        // scenarioParameters.WaitTimeBetweenIterations = TimeSpan.FromSeconds(30);
        // Pause between concurrent actions for a random duration bound by this value.
        // scenarioParameters.WaitTimeBetweenFaults = TimeSpan.FromSeconds(10);

        // Create the scenario class and execute it asynchronously.
        ChaosTestScenario chaosScenario = new ChaosTestScenario(fabricClient, scenarioParameters);

        try
        {
            await chaosScenario.ExecuteAsync(CancellationToken.None);
        }
        catch (AggregateException ae)
        {
            throw ae.InnerException;
        }
    }
}

PowerShell

Le module PowerShell Service Fabric comprend deux façons de démarrer un scénario chaos. Invoke-ServiceFabricChaosTestScenario est basé sur le client et si l’ordinateur client est arrêté à mi-chemin par le test, aucune erreur supplémentaire n’est introduite. Il existe également un ensemble de commandes destinées à maintenir le test en cours d’exécution en cas d’arrêt de l’ordinateur. Start-ServiceFabricChaos utilise un service système avec état et fiable appelé FaultAnalysisService ; ainsi, les erreurs demeurent introduites jusqu’à ce que TimeToRun soit écoulé. Stop-ServiceFabricChaos peut être utilisé pour arrêter manuellement le scénario, tandis que Get-ServiceFabricChaosReport obtient un rapport. Pour plus d’informations, consultez la référence PowerShell d’Azure Service Fabric et l’inducteur de chaos contrôlé dans les clusters Service Fabric.

$connection = "localhost:19000"
$timeToRun = 60
$maxStabilizationTimeSecs = 180
$concurrentFaults = 3
$waitTimeBetweenIterationsSec = 60

Connect-ServiceFabricCluster $connection

Invoke-ServiceFabricChaosTestScenario -TimeToRunMinute $timeToRun -MaxClusterStabilizationTimeoutSec $maxStabilizationTimeSecs -MaxConcurrentFaults $concurrentFaults -EnableMoveReplicaFaults -WaitTimeBetweenIterationsSec $waitTimeBetweenIterationsSec

Test de basculement

Le scénario de test de basculement est une version du test chaos qui cible une partition de service spécifique. Il évalue l’effet du basculement sur une partition spécifique de service, sans affecter les autres services. Une fois configuré avec les informations de partition cible et d’autres paramètres, il s’exécute en tant qu’outil côté client à l’aide des API C# ou de PowerShell pour générer des erreurs associées à une partition de service. Le scénario parcourt une séquence d’erreurs simulées et de validation de service, tandis que votre logique métier s’exécute en parallèle pour fournir une charge applicative. Un échec de validation de service indique une erreur nécessitant un examen approfondi.

Erreurs simulées dans le test de basculement

  • Redémarrez un package de code déployé à l’emplacement d’hébergement de la partition
  • Supprimez une instance sans état ou un réplica principal/secondaire
  • Redémarrez une réplique principale/secondaire (si le service est persistant)
  • Déplacer une réplique principale
  • Déplacez une réplique secondaire
  • Redémarrez la partition

Le test de basculement introduit une erreur déterminée, avant d’exécuter une validation du service afin d’évaluer sa stabilité. Le test de basculement induit une seule panne à la fois, contrairement au test de chaos, qui peut en induire plusieurs en même temps. Si la partition de service ne se stabilise pas dans le délai d’expiration configuré après chaque erreur, le test échoue. Le test induit uniquement des défaillances sûres. Cela signifie qu’en l’absence d’échecs externes, un quorum ou une perte de données ne se produit pas.

Options de configuration importantes

  • PartitionSelector: objet de sélecteur qui spécifie la partition à cibler.
  • TimeToRun: durée totale d’exécution du test.
  • MaxServiceStabilizationTimeout: délai maximal nécessaire à la restauration de l’intégrité du cluster, préalablement à l’échec du test. Les contrôles consistent à vérifier que l’intégrité du service est acceptable, que la taille cible du jeu de réplicas est atteinte pour l’ensemble des partitions et qu’aucun réplica InBuild n’existe.
  • WaitTimeBetweenFaults: délai d’attente avant chaque erreur et cycle de validation.

Procédure d’exécution du test de basculement

C#

using System;
using System.Fabric;
using System.Fabric.Testability.Scenario;
using System.Threading;
using System.Threading.Tasks;

class Test
{
    public static int Main(string[] args)
    {
        string clusterConnection = "localhost:19000";
        Uri serviceName = new Uri("fabric:/samples/PersistentToDoListApp/PersistentToDoListService");

        Console.WriteLine("Starting Chaos Test Scenario...");
        try
        {
            RunFailoverTestScenarioAsync(clusterConnection, serviceName).Wait();
        }
        catch (AggregateException ae)
        {
            Console.WriteLine("Chaos Test Scenario did not complete: ");
            foreach (Exception ex in ae.InnerExceptions)
            {
                if (ex is FabricException)
                {
                    Console.WriteLine("HResult: {0} Message: {1}", ex.HResult, ex.Message);
                }
            }
            return -1;
        }

        Console.WriteLine("Chaos Test Scenario completed.");
        return 0;
    }

    static async Task RunFailoverTestScenarioAsync(string clusterConnection, Uri serviceName)
    {
        TimeSpan maxServiceStabilizationTimeout = TimeSpan.FromSeconds(180);
        PartitionSelector randomPartitionSelector = PartitionSelector.RandomOf(serviceName);

        // Create FabricClient with connection and security information here.
        FabricClient fabricClient = new FabricClient(clusterConnection);

        // The chaos test scenario should run at least 60 minutes or until it fails.
        TimeSpan timeToRun = TimeSpan.FromMinutes(60);
        FailoverTestScenarioParameters scenarioParameters = new FailoverTestScenarioParameters(
          randomPartitionSelector,
          timeToRun,
          maxServiceStabilizationTimeout);

        // Other related parameters:
        // Pause between two iterations for a random duration bound by this value.
        // scenarioParameters.WaitTimeBetweenIterations = TimeSpan.FromSeconds(30);
        // Pause between concurrent actions for a random duration bound by this value.
        // scenarioParameters.WaitTimeBetweenFaults = TimeSpan.FromSeconds(10);

        // Create the scenario class and execute it asynchronously.
        FailoverTestScenario failoverScenario = new FailoverTestScenario(fabricClient, scenarioParameters);

        try
        {
            await failoverScenario.ExecuteAsync(CancellationToken.None);
        }
        catch (AggregateException ae)
        {
            throw ae.InnerException;
        }
    }
}

PowerShell

$connection = "localhost:19000"
$timeToRun = 60
$maxStabilizationTimeSecs = 180
$waitTimeBetweenFaultsSec = 10
$serviceName = "fabric:/SampleApp/SampleService"

Connect-ServiceFabricCluster $connection

Invoke-ServiceFabricFailoverTestScenario -TimeToRunMinute $timeToRun -MaxServiceStabilizationTimeoutSec $maxStabilizationTimeSecs -WaitTimeBetweenFaultsSec $waitTimeBetweenFaultsSec -ServiceName $serviceName -PartitionKindSingleton
  • Last updated on