Veröffentlicht am: Nov 8, 2021
Sie können jetzt AWS Fault Injection Simulator (FIS) Experimente kreieren und durchführen, die den Zustand von Amazon CloudWatch Alarmen prüfen und automatisierte Abläufe für den AWS Systems Manager (SSM) betreiben. Sie können außerdem jetzt neue FIS-Experimentaktionen durchführen, die I/O eingeben, einen schwarzes Loch vernetzen und Verlustfehler in ihre Amazon-EC2-Instances verpacken, wobei Sie vorkonfigurierte SSM Agent Dokumente verwenden. Da es schwierig sein kann vorherzusagen, wie sich Anwendungen unter realen Bedingungen verhalten, ob in Test- oder Produktionsumgebungen, kann die Integration von Alarmchecks und automatisierten Runbooks in Ihre FIS-Experimente helfen, Ihnen mehr Vertrauen zu vermitteln, wenn Sie disruptive Ereignisse eingeben, wie etwa Netzwerkprobleme, Beendigung von Instances, API-Fehler oder andere negative Bedingungen.
Zuerst erlaubt Ihnen die neue CloudWatch Aktion, den Zustand eines CloudWatch Alarms als Teil Ihres FIS Experiments-Ablaufs anzunehmen. Danach, wenn das Experiment läuft, wird es verifizieren, ob der Alarm im erwarteten Zustand ist: OK, ALARM oder UNZUREICHENDE_DATEN. Sie können dieses Beispiel verwenden, um zu prüfen, ob die Auswirkungen einer vorherigen Aktion (wie latente Netzwerkeingabe) wirksam geworden sind, bevor Sie zur nächsten Aktion im Experiment weitergehen (z.B. einem EC2-Reboot-Beispiel).
Als Nächstes können Sie jetztAWS Systems Manager Automation Runbooks ausführen, innerhalb eines FIS Experiments. AWS Systems Manager Automation ermöglicht es Ihnen, Automatisierung zu erstellen und zu betreiben, um eine Vielfalt von gängigen Aufgaben durchzuführen, wie etwa Kreieren und Löschen von EC2 AMIs oder CloudFormation Vorlagen, Löschen von S3 Buckets, Betreiben von AWS Step Funktionsschrittmaschinen, AWS Lambda Funktionen einleiten, Kreieren von Tags, EC2 Beispiele ausgeben oder AWS APIs Anfragen zu machen. Durch die Konfigurierung von Automations-Runbooks innerhalb von FIS Experimenten können Sie einfacher, sicherer und auf wiederholbare komplexe Fehlerbedingungen erschaffen, die näher an einer realen Situation sind.
Schließlich sind jetzt neue und aktualisierten SSM Dokumente verfügbar und können als Falscheingabe-Aktionen ausgeführt werden, einschließlich: einer IO Stressaktion, einer Netzwerk-Black-Hole-Aktion, die eingebundenen oder nicht eingebundenen Verkehr für ein vorhandenes Protokoll/einen vorhandenen Port fallen lässt, eine latente Netzwerkaktion die Latenz bzw. Zittern durch ein vorhandenes Netzwerkinterface addiert, zu oder von Quellen, die Sie als IP Adressen/-blocks, Domänen oder AWS Dienste spezifizieren, einschließlich S3 und DynamoDB; und zwei Netzwerkpaketverlustaktionen, die Paketverluste eingeben können, in eine vorhandene Oberfläche und (optional) Quelle. Diese SSM Dokumente sind vorkonfiguiert für EC2 Beispiele, die unter Amazon Linux und Ubuntu laufen.
Sie können damit beginnen Fehleingaben-Experimente zu kreieren und auszuführen, in der AWS-Managementkonsole oder mit den AWS SDKs, und jedes dieser neuen Elemente ist heute verfügbar. Diese Funktion ist in allen kommerziellen AWS-Regionen verfügbar.