Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Referenz zu den Szenarien
In der Szenariobibliothek enthaltene Szenarien sind so konzipiert, dass sie nach Möglichkeit Tags verwenden. Jedes Szenario beschreibt die erforderlichen Tags in den Abschnitten Voraussetzungen und Funktionsweise der Szenariobeschreibung. Sie können Ihre Ressourcen mit diesen vordefinierten Tags kennzeichnen oder mithilfe der Funktion zur Bearbeitung mehrerer Parameter eigene Tags festlegen (sieheAnhand eines Szenarios).
In dieser Referenz werden die gängigen Szenarien in der AWS FIS-Szenariobibliothek beschrieben. Sie können die unterstützten Szenarien auch mithilfe der AWS FIS-Konsole auflisten.
Weitere Informationen finden Sie unter Arbeiten mit der AWS FIS Szenariobibliothek.
AWS FIS unterstützt die folgenden EC2 Amazon-Szenarien. Diese Szenarien zielen auf Instances ab, die Tags verwenden. Sie können Ihre eigenen Tags oder die im Szenario enthaltenen Standard-Tags verwenden. In einigen dieser Szenarien werden SSM-Dokumente verwendet.
-
EC2 Stress: Instanzausfall — Untersuchen Sie die Auswirkungen eines Instanzausfalls, indem Sie eine oder mehrere EC2 Instanzen stoppen.
Ziel-Instances in der aktuellen Region, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario stoppen wir diese Instances und starten sie am Ende der Aktionsdauer neu, standardmäßig 5 Minuten.
-
EC2 stress: Disk — Erkunden Sie die Auswirkungen einer erhöhten Festplattenauslastung EC2 auf Ihre Basisanwendung.
In diesem Szenario zielen wir auf EC2 Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario können Sie für die Aktionsdauer eine zunehmende Festplattenauslastung festlegen, die auf die EC2 Zielinstanzen injiziert wird, standardmäßig 5 Minuten für jede Festplattenbelastungsaktion.
-
EC2 stress: CPU — Erkunden Sie die Auswirkungen einer erhöhten CPU-Auslastung EC2 auf Ihre Basisanwendung.
In diesem Szenario zielen wir auf EC2 Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario können Sie eine zunehmende Menge an CPU-Belastung, die auf EC2 Zielinstanzen injiziert wird, für die Aktionsdauer anpassen, standardmäßig 5 Minuten für jede CPU-Belastungsaktion.
-
EC2 stress: Memory — Erkunden Sie die Auswirkungen einer erhöhten Speicherauslastung EC2 auf Ihre Basisanwendung.
In diesem Szenario zielen wir auf EC2 Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario können Sie eine zunehmende Menge an Speicherbelastung, die auf EC2 Zielinstanzen injiziert wird, für die Aktionsdauer anpassen, standardmäßig 5 Minuten für jede Speicherbelastungsaktion.
-
EC2 Stress: Netzwerklatenz — Erkunden Sie die Auswirkungen einer erhöhten Netzwerklatenz EC2 auf Ihre Basisanwendung.
In diesem Szenario zielen wir auf EC2 Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario können Sie eine zunehmende Menge an Netzwerklatenz, die den EC2 Ziel-Instances zugewiesen wird, für die Aktionsdauer anpassen, standardmäßig 5 Minuten für jede Latenzaktion.
AWS FIS unterstützt die folgenden Amazon EKS-Szenarien. Diese Szenarien zielen auf EKS-Pods ab, die Labels einer Kubernetes-Anwendung verwenden. Sie können Ihre eigenen Labels oder die im Szenario enthaltenen Standardlabels verwenden. Weitere Informationen zu EKS mit FIS finden Sie unterEKS-Pod-Aktionen.
-
EKS-Stress: Pod Delete — Erkunden Sie die Auswirkungen eines EKS-Pod-Ausfalls, indem Sie einen oder mehrere Pods löschen.
In diesem Szenario zielen wir auf Pods in der aktuellen Region ab, die einem Anwendungslabel zugeordnet sind. In diesem Szenario werden wir alle passenden Pods beenden. Die Neuerstellung von Pods wird durch die Kubernetes-Konfiguration gesteuert.
-
EKS-Stress: CPU — Erkunden Sie die Auswirkungen einer erhöhten CPU-Auslastung auf Ihre EKS-basierte Anwendung.
In diesem Szenario zielen wir auf Pods in der aktuellen Region ab, die einem Anwendungslabel zugeordnet sind. In diesem Szenario können Sie für die Aktionsdauer eine zunehmende Menge an CPU-Belastung, die auf gezielte EKS-Pods injiziert wird, anpassen, standardmäßig 5 Minuten für jede CPU-Stressaktion.
-
EKS-Stress: Disk — Erkunden Sie die Auswirkungen einer erhöhten Festplattenauslastung auf Ihre EKS-basierte Anwendung.
In diesem Szenario zielen wir auf Pods in der aktuellen Region ab, die einem Anwendungslabel zugeordnet sind. In diesem Szenario können Sie für die Aktionsdauer eine zunehmende Menge an Festplattenbelastung anpassen, die auf gezielte EKS-Pods injiziert wird, standardmäßig 5 Minuten für jede CPU-Belastungsaktion.
-
EKS-Stress: Arbeitsspeicher — Erkunden Sie die Auswirkungen einer erhöhten Speicherauslastung auf Ihre EKS-basierte Anwendung.
In diesem Szenario zielen wir auf Pods in der aktuellen Region ab, die einem Anwendungslabel zugeordnet sind. In diesem Szenario können Sie eine zunehmende Menge an Speicherstress, der auf gezielte EKS-Pods injiziert wird, für die Aktionsdauer anpassen, standardmäßig 5 Minuten für jede Speicherstressaktion.
-
EKS-Stress: Netzwerklatenz — Erkunden Sie die Auswirkungen einer erhöhten Netzwerklatenz auf Ihre EKS-basierte Anwendung.
In diesem Szenario zielen wir auf Pods in der aktuellen Region ab, die einem Anwendungslabel zugeordnet sind. In diesem Szenario können Sie eine zunehmende Menge an Netzwerklatenz, die auf gezielte EKS-Pods übertragen wird, für die Aktionsdauer anpassen, standardmäßig 5 Minuten für jede Latenzaktion.
AWS FIS unterstützt die folgenden Szenarien für Multi-AZ- und Multi-Region-Anwendungen. Diese Szenarien zielen auf mehrere Ressourcentypen ab.
-
AZ Availability: Power Interruption- Injizieren Sie die zu erwartenden Symptome einer vollständigen Stromunterbrechung in einer Availability Zone (AZ). Weitere Informationen zu AZ Availability: Power Interruption.
-
Cross-Region: Connectivity- Blockieren Sie den Netzwerkverkehr der Anwendung von der Versuchsregion zur Zielregion und unterbrechen Sie die regionsübergreifende Datenreplikation. Erfahren Sie mehr über die Verwendung vonCross-Region: Connectivity.
AWS FIS unterstützt die folgenden Szenarien für Amazon EBS-Volumes. Diese Szenarien zielen mithilfe von Tags auf Volumes ab. Sie können Ihre eigenen Tags oder die im Szenario enthaltenen Standardtags verwenden. Die Zielvolumes müssen sich in derselben Availability Zone befinden. Weitere Informationen finden Sie unter Fehlertests auf Amazon EBS.
-
EBS: Sustained Latency— Untersuchen Sie die Auswirkungen anhaltender I/O Latenz auf Ihre Anwendung.
In diesem Szenario zielen wir auf Volumes in der aktuellen Availability Zone ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario wird eine konstante Latenz von 500 ms bei 50 Prozent der Lese- und 100 Prozent der Schreibvorgänge für ein Volume erreicht, wobei eine einzige Latenzaktion über einen Zeitraum von 15 Minuten verwendet wird. In diesem Szenario können Sie die Höhe der eingespeisten Latenz, den Prozentsatz der I/O injizierten Latenz und die Dauer der Aktion anpassen.
-
EBS: Increasing Latency— Untersuchen Sie, wie sich die Erhöhung der I/O Latenz auf Ihre Anwendung auswirkt.
In diesem Szenario zielen wir auf Volumes in der aktuellen Availability Zone ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario wird bei 10 Prozent der Lese- und 25 Prozent der Schreibvorgänge für ein Volume mit fünf Latenzaktionen über einen Zeitraum von 15 Minuten eine zunehmende Latenz von 50 ms, 200 ms, 700 ms, 1 Sekunde und 15 Sekunden erreicht. In diesem Szenario können Sie für jede Latenzaktion die Menge der injizierten Latenz, den Prozentsatz der I/O injizierten Latenz und die Aktionsdauer anpassen.
-
EBS: Intermittent Latency— Untersuchen Sie die Auswirkungen intermittierender I/O Latenzspitzen auf Ihre Anwendung.
In diesem Szenario zielen wir auf Volumes in der aktuellen Availability Zone ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario werden bei 0,1 Prozent der Lese- und I/O Schreibvorgänge für ein Volume drei starke, intermittierende Latenzspitzen von 30 Sekunden, 10 Sekunden und 20 Sekunden ausgelöst. Dabei werden drei Latenzaktionen verwendet, wobei zwischen jedem Anstieg über einen Zeitraum von 15 Minuten Wiederherstellungsintervalle liegen. In diesem Szenario können Sie für jede Latenzaktion den Umfang der injizierten Latenz, den Prozentsatz der I/O injizierten Latenz und die Aktionsdauer anpassen.
-
EBS: Decreasing Latency— Untersuchen Sie die Auswirkungen abnehmender I/O Latenz auf Ihre Anwendung.
In diesem Szenario zielen wir auf Volumes in der aktuellen Availability Zone ab, denen ein bestimmtes Tag zugewiesen ist. In diesem Szenario wird bei 10 Prozent der Lese- und Schreibvorgänge für ein Volume eine verringerte Latenz von 20 Sekunden, 5 Sekunden, 900 ms, 300 ms und 40 ms erreicht, wobei fünf Latenzaktionen über einen Zeitraum von 15 Minuten verwendet werden. In diesem Szenario können Sie für jede Latenzaktion den Umfang der zugeführten Latenz, den Prozentsatz der I/O injizierten Latenz und die Aktionsdauer anpassen.
