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 Fonctionnement de la description du scénario. Vous pouvez étiqueter vos ressources avec ces balises prédéfinies ou définir vos propres balises à l'aide de l'expérience de modification des paramètres en bloc (voirUtilisation 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 Utilisation de la bibliothèque de AWS FIS scénarios.
AWS FIS prend en charge les EC2 scénarios Amazon suivants. Ces scénarios ciblent les 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.
-
EC2 stress : échec d'instance - Explorez l'effet d'une défaillance d'instance en arrêtant une ou plusieurs EC2 instances.
Ciblez les instances de la région actuelle auxquelles une balise spécifique est attachée. 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.
-
EC2 stress : Disk - Explorez l'impact d'une utilisation accrue du disque sur votre application EC2 basée.
Dans ce scénario, nous ciblerons EC2 les instances 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 EC2 instances ciblées pendant la durée de l'action, par défaut 5 minutes pour chaque action de stress sur le disque.
-
EC2 stress : CPU - Explorez l'impact de l'augmentation du processeur sur votre application EC2 basée.
Dans ce scénario, nous ciblerons EC2 les instances 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 des EC2 instances ciblées pendant la durée de l'action, par défaut 5 minutes pour chaque action de stress du processeur.
-
EC2 stress : Mémoire - Découvrez l'impact d'une utilisation accrue de la mémoire sur votre application EC2 basée.
Dans ce scénario, nous ciblerons EC2 les instances 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 mnésique injecté sur des EC2 instances ciblées pendant la durée de l'action, par défaut 5 minutes pour chaque action de stress mnésique.
-
EC2 stress : latence du réseau - Explorez l'impact de l'augmentation de la latence du réseau sur votre application EC2 basée.
Dans ce scénario, nous ciblerons EC2 les instances 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 EC2 instances 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 EKS Pod.
-
Stress lié à l'EKS : suppression du module - Découvrez l'effet d'une défaillance du module EKS en supprimant un ou plusieurs modules.
Dans ce scénario, nous ciblerons les pods de la région actuelle associés à une étiquette d'application. Dans ce scénario, nous mettrons fin à tous les pods correspondants. La recréation des pods sera contrôlée par la configuration de Kubernetes.
-
Stress lié à l'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 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 lié à l'EKS : disque - Découvrez 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 associés à une étiquette d'application. Dans ce scénario, vous pouvez personnaliser une quantité croissante de stress du disque 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 lié à l'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 associés à une étiquette d'application. Dans ce scénario, vous pouvez personnaliser une quantité croissante de stress mnésique injecté sur les pods EKS ciblés pendant la durée de l'action, par défaut 5 minutes pour chaque action de stress mnésique.
-
Stress lié à l'EKS : latence du réseau - Découvrez 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 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 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 AZ Availability: Power Interruption.
-
Cross-Region: Connectivity- Bloquez le trafic réseau de l'application entre la région d'essai et la région de destination et interrompez la réplication des données entre régions. Apprenez-en davantage sur l'utilisationCross-Region: Connectivity.
AWS FIS prend en charge les scénarios suivants pour les volumes Amazon EBS. Ces scénarios ciblent les 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 la section Tests d'erreur 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 balise 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 balise 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 balise spécifique est attachée. Ce scénario injecte trois pics de latence intermittents brusques 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 récupération 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— Explorez l'impact de la réduction de la I/O latence sur votre application.
Dans ce scénario, nous ciblerons les volumes de la zone de disponibilité actuelle auxquels une balise 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.
