Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Référence de scénarios
Les scénarios inclus dans la bibliothèque de scénarios sont conçus pour utiliser des balises dans la mesure du possible et chaque scénario décrit les balises requises dans les sections Prérequis et Comment ça fonctionne de la description du scénario. Vous pouvez baliser vos ressources avec ces balises prédéfinies ou définir vos propres balises à l'aide de l'expérience d'édition de paramètres partagée (voirÀ l'aide d'un scénario).
Cette référence décrit les scénarios courants de la bibliothèque de scénarios AWS FIS. Vous pouvez également répertorier les scénarios pris en charge à l'aide de la console AWS FIS.
Pour de plus amples informations, veuillez consulter En collaboration avec AWS FIS bibliothèque de scénarios.
AWS FIS prend en charge les scénarios Amazon EC2 suivants. Ces scénarios ciblent des instances à l'aide de balises. Vous pouvez utiliser vos propres balises ou utiliser les balises par défaut incluses dans le scénario. Certains de ces scénarios utilisent des documents SSM.
-
Stress EC2 : défaillance d'instance : explorez l'effet d'une défaillance d'instance en arrêtant une ou plusieurs instances EC2.
Instances cibles de la région actuelle auxquelles est attachée une balise spécifique. Dans ce scénario, nous arrêterons ces instances et les redémarrerons à la fin de la durée de l'action, par défaut 5 minutes.
-
Contrainte EC2 : disque : explorez l'impact d'une utilisation accrue du disque sur votre application basée sur EC2.
Dans ce scénario, nous ciblerons les instances EC2 de la région actuelle auxquelles une balise spécifique est attachée. Dans ce scénario, vous pouvez personnaliser une quantité croissante d'utilisation du disque injectée sur des instances EC2 ciblées pendant la durée de l'action, par défaut 5 minutes pour chaque action de contrainte du disque.
-
Stress EC2 : processeur - Découvrez l'impact d'une augmentation du processeur sur votre application basée sur EC2.
Dans ce scénario, nous ciblerons les instances EC2 de la région actuelle auxquelles une balise spécifique est attachée. Dans ce scénario, vous pouvez personnaliser une quantité croissante de stress du processeur injectée sur les instances EC2 ciblées pendant la durée de l'action, par défaut 5 minutes pour chaque action de contrainte du processeur.
-
Stress EC2 : mémoire - Découvrez l'impact d'une utilisation accrue de la mémoire sur votre application basée sur EC2.
Dans ce scénario, nous ciblerons les instances EC2 de la région actuelle auxquelles une balise spécifique est attachée. Dans ce scénario, vous pouvez personnaliser une quantité croissante de stress mémoire injecté sur des instances EC2 ciblées pendant la durée de l'action, par défaut 5 minutes pour chaque action de stress mémoire.
-
Stress EC2 : latence du réseau : explorez l'impact de l'augmentation de la latence du réseau sur votre application basée sur EC2.
Dans ce scénario, nous ciblerons les instances EC2 de la région actuelle auxquelles une balise spécifique est attachée. Dans ce scénario, vous pouvez personnaliser une quantité croissante de latence réseau injectée sur les instances EC2 ciblées pendant la durée de l'action, par défaut 5 minutes pour chaque action de latence.
AWS FIS prend en charge les scénarios Amazon EKS suivants. Ces scénarios ciblent les pods EKS à l'aide d'étiquettes d'application Kubernetes. Vous pouvez utiliser vos propres étiquettes ou utiliser les étiquettes par défaut incluses dans le scénario. Pour plus d'informations sur EKS avec FIS, consultezActions du module EKS.
-
Stress EKS : suppression du pod : explorez l'effet d'une défaillance du pod EKS en supprimant un ou plusieurs pods.
Dans ce scénario, nous ciblerons les pods de la région actuelle qui sont associés à une étiquette d'application. Dans ce scénario, nous mettrons fin à tous les pods correspondants. Re-creation des pods seront contrôlés par la configuration de Kubernetes.
-
Stress EKS : processeur - Découvrez l'impact d'une augmentation du processeur sur votre application basée sur EKS.
Dans ce scénario, nous ciblerons les pods de la région actuelle qui sont associés à une étiquette d'application. Dans ce scénario, vous pouvez personnaliser une quantité croissante de stress du processeur injectée sur les pods EKS ciblés pendant la durée de l'action, par défaut 5 minutes pour chaque action de stress du processeur.
-
Stress EKS : disque : explorez l'impact d'une utilisation accrue du disque sur votre application basée sur EKS.
Dans ce scénario, nous ciblerons les pods de la région actuelle qui sont associés à une étiquette d'application. Dans ce scénario, vous pouvez personnaliser une quantité croissante de contraintes de disque injectées sur les pods EKS ciblés pendant la durée de l'action, par défaut 5 minutes pour chaque action de contrainte du processeur.
-
Stress EKS : mémoire - Découvrez l'impact d'une utilisation accrue de la mémoire sur votre application basée sur EKS.
Dans ce scénario, nous ciblerons les pods de la région actuelle qui sont associés à une étiquette d'application. Dans ce scénario, vous pouvez personnaliser une quantité croissante de stress de mémoire injecté sur des modules EKS ciblés pendant la durée de l'action, par défaut 5 minutes pour chaque action de stress de mémoire.
-
Stress EKS : latence du réseau : explorez l'impact de l'augmentation de la latence du réseau sur votre application basée sur EKS.
Dans ce scénario, nous ciblerons les pods de la région actuelle qui sont associés à une étiquette d'application. Dans ce scénario, vous pouvez personnaliser une quantité croissante de latence réseau injectée sur les pods EKS ciblés pendant la durée de l'action, par défaut 5 minutes pour chaque action de latence.
AWS FIS prend en charge les scénarios suivants pour les applications mono-AZ, multi-AZ et multi-régions. Ces scénarios ciblent plusieurs types de ressources.
-
AZ Availability: Power Interruption- Injectez les symptômes attendus d'une interruption complète de l'alimentation dans une zone de disponibilité (AZ). En savoir plus sur Disponibilité AZ : coupure de courant.
-
AZ: Application Slowdown- Ajoutez de la latence entre les ressources au sein d'une même zone de disponibilité (AZ) pour ralentir une application. En savoir plus sur AZ : ralentissement des applications.
-
Cross-AZ: Traffic Slowdown- Injectez la perte de paquets pour perturber et ralentir le trafic entre les zones de disponibilité (AZ). En savoir plus sur Cross-AZ: Ralentissement du trafic.
-
Cross-Region: Connectivity- Bloquez le trafic réseau des applications de la région expérimentale vers la région de destination et interrompez la réplication des données entre les régions. En savoir plus sur l'utilisationCross-Region: Connectivité.
AWS FIS prend en charge les scénarios suivants pour les volumes Amazon EBS. Ces scénarios ciblent des volumes à l'aide de balises. Vous pouvez utiliser vos propres balises ou utiliser les balises par défaut incluses dans le scénario. Les volumes cibles doivent se trouver dans la même zone de disponibilité. Pour plus d'informations, consultez Tests d'erreurs sur Amazon EBS.
-
EBS: Sustained Latency— Explorez l'impact de la I/O latence persistante sur votre application.
Dans ce scénario, nous ciblerons les volumes de la zone de disponibilité actuelle auxquels une étiquette spécifique est attachée. Ce scénario injecte une latence constante de 500 ms sur 50 % des opérations de lecture et 100 % des opérations d'écriture d'un volume, en utilisant une seule action de latence sur une période de 15 minutes. Dans ce scénario, vous pouvez personnaliser la quantité de latence injectée, le pourcentage de latence I/O injectée et la durée de l'action.
-
EBS: Increasing Latency— Explorez l'impact de l'augmentation de la I/O latence sur votre application.
Dans ce scénario, nous ciblerons les volumes de la zone de disponibilité actuelle auxquels une étiquette spécifique est attachée. Ce scénario injecte une latence croissante de 50 ms, 200 ms, 700 ms, 1 seconde et 15 secondes sur 10 % des opérations de lecture et 25 % des opérations d'écriture d'un volume en utilisant cinq actions de latence sur une période de 15 minutes. Dans ce scénario, vous pouvez personnaliser la quantité de latence injectée, le pourcentage de latence I/O injectée et la durée de l'action pour chaque action de latence.
-
EBS: Intermittent Latency— Explorez l'impact des pics de I/O latence intermittents sur votre application.
Dans ce scénario, nous ciblerons les volumes de la zone de disponibilité actuelle auxquels une étiquette spécifique est attachée. Ce scénario injecte trois pics de latence intermittents de 30 secondes, 10 secondes et 20 secondes sur 0,1 % des I/O opérations de lecture et d'écriture d'un volume, en utilisant trois actions de latence, avec des intervalles de restauration entre chaque pic sur une période de 15 minutes. Dans ce scénario, vous pouvez personnaliser la quantité de latence injectée, le pourcentage de latence I/O injectée et la durée de l'action pour chaque action de latence.
-
EBS: Decreasing Latency— Découvrez l'impact de la diminution de la I/O latence sur votre application.
Dans ce scénario, nous ciblerons les volumes de la zone de disponibilité actuelle auxquels une étiquette spécifique est attachée. Ce scénario injecte une latence décroissante de 20 secondes, 5 secondes, 900 ms, 300 ms et 40 ms sur 10 % des opérations de lecture et d'écriture d'un volume, en utilisant cinq actions de latence sur une période de 15 minutes. Dans ce scénario, vous pouvez personnaliser la quantité de latence injectée, le pourcentage de latence I/O injectée et la durée de l'action pour chaque action de latence.
