View a markdown version of this page

Referenz zu den Szenarien - AWS Service zur Fehlerinjektion

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

Die in der Szenariobibliothek enthaltenen Szenarien sind so konzipiert, dass nach Möglichkeit Tags verwendet werden. 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 gemeinsamen Parameterbearbeitung Ihre eigenen Tags festlegen (sieheMithilfe eines Szenarios).

Diese Referenz beschreibt die gängigen Szenarien in der AWS FIS-Szenariobibliothek. Sie können die unterstützten Szenarien auch mithilfe der AWS FIS-Konsole auflisten.

Weitere Informationen finden Sie unter Wir arbeiten mit dem AWS FIS Szenario-Bibliothek.

AWS FIS unterstützt die folgenden Amazon EC2-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 https://docs.aws.amazon.com/fis/latest/userguide/actions-ssm-agent.html verwendet.

  • EC2-Stress: Instance-Ausfall — Untersuchen Sie die Auswirkungen eines Instance-Ausfalls, indem Sie eine oder mehrere EC2-Instances stoppen.

    Ziel-Instances in der aktuellen Region, denen ein bestimmtes Tag zugeordnet ist. In diesem Szenario stoppen wir diese Instances und starten sie am Ende der Aktionsdauer neu, standardmäßig 5 Minuten.

  • EC2-Stress: Festplatte — Erkunden Sie die Auswirkungen einer erhöhten Festplattenauslastung auf Ihre EC2-basierte Anwendung.

    In diesem Szenario zielen wir auf EC2-Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugeordnet ist. In diesem Szenario können Sie die Erhöhung der Festplattenauslastung, die den ausgewählten EC2-Instances zugeführt wird, für die Dauer der Aktion anpassen, standardmäßig 5 Minuten für jede Aktion zur Festplattenbelastung.

  • EC2-Stress: CPU — Erkunden Sie die Auswirkungen einer erhöhten CPU-Auslastung auf Ihre EC2-basierte Anwendung.

    In diesem Szenario zielen wir auf EC2-Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugeordnet ist. In diesem Szenario können Sie die Erhöhung der CPU-Belastung, die den ausgewählten EC2-Instances zugeführt wird, für die Dauer der Aktion anpassen, standardmäßig 5 Minuten für jede CPU-Belastungsaktion.

  • EC2-Stress: Arbeitsspeicher — Untersuchen Sie die Auswirkungen einer erhöhten Speicherauslastung auf Ihre EC2-basierte Anwendung.

    In diesem Szenario zielen wir auf EC2-Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugeordnet ist. In diesem Szenario können Sie die Erhöhung der Speicherbelastung, die den ausgewählten EC2-Instances für die Dauer der Aktion injiziert wird, anpassen, standardmäßig 5 Minuten für jede Aktion mit Speicherbelastung.

  • EC2-Stress: Netzwerklatenz — Erkunden Sie die Auswirkungen einer erhöhten Netzwerklatenz auf Ihre EC2-basierte Anwendung.

    In diesem Szenario zielen wir auf EC2-Instances in der aktuellen Region ab, denen ein bestimmtes Tag zugeordnet ist. In diesem Szenario können Sie die Erhöhung der Netzwerklatenz, die auf bestimmte EC2-Instances übertragen 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 die Bezeichnungen 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-Fehlers, indem Sie einen oder mehrere Pods löschen.

    In diesem Szenario zielen wir auf Pods in der aktuellen Region ab, die mit einem Anwendungslabel verknüpft sind. In diesem Szenario beenden wir alle passenden Pods. Re-creation Die Anzahl der 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 mit einem Anwendungslabel verknüpft sind. In diesem Szenario können Sie die Erhöhung der CPU-Auslastung, die den ausgewählten EKS-Pods ausgesetzt wird, für die Dauer der Aktion anpassen, standardmäßig 5 Minuten für jede CPU-Belastungsaktion.

  • EKS-Stress: Festplatte — Untersuchen 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 mit einem Anwendungslabel verknüpft sind. In diesem Szenario können Sie die Erhöhung der Festplattenbelastung, die den ausgewählten EKS-Pods ausgesetzt wird, für die Dauer der Aktion anpassen, standardmäßig 5 Minuten für jede CPU-Belastungsaktion.

  • EKS-Stress: Arbeitsspeicher — Untersuchen 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 mit einem Anwendungslabel verknüpft sind. In diesem Szenario können Sie die Erhöhung der Speicherbelastung, die den ausgewählten EKS-Pods ausgesetzt wird, für die Dauer der Aktion anpassen, standardmäßig 5 Minuten für jede Aktion mit Speicherbelastung.

  • 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 mit einem Anwendungslabel verknüpft sind. In diesem Szenario können Sie die Erhöhung der Netzwerklatenz, die den EKS-Ziel-Pods injiziert wird, für die Dauer der Aktion anpassen, standardmäßig 5 Minuten für jede Latenzaktion.

AWS FIS unterstützt die folgenden Szenarien für Single-AZ-, Multi-AZ- und Multiregion-Anwendungen. Diese Szenarien zielen auf mehrere Ressourcentypen ab.

  • AZ Availability: Power Interruption- Geben Sie die erwarteten Symptome einer vollständigen Unterbrechung der Stromversorgung in eine Availability Zone (AZ) ein. Weitere Informationen zu AZ-Verfügbarkeit: Stromunterbrechung.

  • AZ: Application Slowdown- Erhöhen Sie die Latenz zwischen Ressourcen innerhalb einer einzelnen Availability Zone (AZ), um eine Anwendung zu verlangsamen. Weitere Informationen zu AZ: Verlangsamung der Anwendung.

  • Cross-AZ: Traffic Slowdown- Fügen Sie Paketverlust hinzu, um den Verkehr zwischen Availability Zones (AZs) zu unterbrechen und zu verlangsamen. Weitere Informationen zu Cross-AZ: Verlangsamung des Verkehrs.

  • 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: Konnektivität.

AWS FIS unterstützt die folgenden Szenarien für Amazon EBS-Volumes. Diese Szenarien zielen auf Volumes mithilfe von Tags ab. Sie können Ihre eigenen Tags oder die im Szenario enthaltenen Standard-Tags verwenden. Die Zielvolumes müssen sich in derselben Availability Zone befinden. Weitere Informationen finden Sie unter Fehlertests auf Amazon EBS.

  • EBS: Sustained Latency— Erkunden 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 zugeordnet 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 eingeführt, wobei eine einzige Latenzaktion über einen Zeitraum von 15 Minuten verwendet wird. In diesem Szenario können Sie den Umfang der injizierten Latenz, den Prozentsatz der I/O injizierten Latenz und die Dauer der Aktion anpassen.

  • EBS: Increasing Latency— Untersuchen Sie die Auswirkungen einer zunehmenden I/O Latenz auf Ihre Anwendung.

    In diesem Szenario zielen wir auf Volumes in der aktuellen Availability Zone ab, denen ein bestimmtes Tag zugeordnet ist. In diesem Szenario steigt die Latenz von 50 ms, 200 ms, 700 ms, 1 Sekunde und 15 Sekunden bei 10 Prozent der Lese- und 25 Prozent der Schreibvorgänge eines Volumes an, wobei fünf Latenzaktionen über einen Zeitraum von 15 Minuten verwendet werden. In diesem Szenario können Sie den Umfang der injizierten Latenz, den Prozentsatz der I/O injizierten Latenz und die Aktionsdauer für jede Latenzaktion 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 zugeordnet 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 den einzelnen Spitzen über einen Zeitraum von 15 Minuten Wiederherstellungsintervalle liegen. In diesem Szenario können Sie den Umfang der injizierten Latenz, den Prozentsatz der I/O injizierten Latenz und die Aktionsdauer für jede Latenzaktion anpassen.

  • EBS: Decreasing Latency— Untersuchen Sie die Auswirkungen einer sinkenden I/O Latenz auf Ihre Anwendung.

    In diesem Szenario zielen wir auf Volumes in der aktuellen Availability Zone ab, denen ein bestimmtes Tag zugeordnet ist. Dieses Szenario führt bei 10 Prozent der Lese- und Schreibvorgänge für ein Volume zu einer Verringerung der Latenz um 20 Sekunden, 5 Sekunden, 900 ms, 300 ms und 40 ms, wobei fünf Latenzaktionen über einen Zeitraum von 15 Minuten verwendet werden. In diesem Szenario können Sie den Umfang der injizierten Latenz, den Prozentsatz der I/O injizierten Latenz und die Aktionsdauer für jede Latenzaktion anpassen.