© Enkel/Shutterstock.com
Chaos Engineering Teil II

Willkommen in der Welt der Chaos Tools


Wie ihr im ersten Artikel zum Thema Chaos Engineering erfahren habt, steckt hinter dem Thema mehr als nur der Einsatz irgendwelcher Tools. Im zweiten Teil werde ich euch nun in die Welt von Chaos Tools entführen und euch zeigen, wie ihr auf den unteren drei Leveln des Chaos Engineerings einzelne Komponenten angreifen könnt.

Natürlich ist beim Chaos Engineering immer Fingerspitzengefühl gefragt. Denn wie wir gelernt haben, wollen wir kein Chaos herbeiführen und böswillig Dinge zerstören. Wir werden uns nun anschauen, wann es sinnvoll ist, unsere Chaos-Experimente zu automatisieren, und mit welchen Tools wir das sehr elegant und getreu der Open-Source-Philosophie umsetzen können.

Chaos Engineering muss zu etwas werden, von dem wir alle profitieren. Wir sollten unsere Experimente im Unternehmen und nach Möglichkeit auch mit anderen auf dieser Welt teilen. Es wäre doch großartig, würde jemand beispielsweise in einem AWS, Kubernetes oder OpenShift Environment Schwachstellen mit Hilfe seiner Chaos-Experimente entdecken und beheben. Und warum sollten andere nicht ebenfalls einen Nutzen daraus ziehen? Diese Überlegungen gaben Russ Miles, ebenfalls Chaos Engineer und Gründer von ChaosIQ [1], den Impuls, die Open Chaos Initiative zu gründen, zu der jeder herzlich eingeladen ist. Der aktuelle Stand und alle Informationen zu dieser Initiative sind auf open cha os. io [2] zu finden.

Doch nun gehen wir in medias res: Wir werden uns mit den drei unteren Leveln des Chaos Engineerings beschäftigen (Abb. 1) und ein paar nützliche Tools im Detail betrachten, mit Hilfe derer wir unsere ersten Experimente starten. Führt euch bitte immer wieder selbst vor Augen, dass unser Ziel die Härtung und Verbesserung unserer Systeme ist. Wir wollen mit den turbulenten Bedingungen umzugehen lernen und deren Auswirkungen auf unser System weitestgehend abmildern.

wilms_chaosengineering2_1.tif_fmt1.jpgAbb. 1: Levels of Chaos Engineering

Bevor wir konkret mit den ersten Attacken beginnen, möchte ich euch noch einmal auf die Methodik und das Vorgehen aufmerksam machen. Abbildung 2 stellt den Zyklus des Chaos Engineerings, wie ihn sich Russ Miles vorstellt, sehr treffend dar.

wilms_chaosengineering2_2.tif_fmt1.jpgAbb. 2: Chaos Engineering Cycle

Wir planen ein Chaos-Experiment unter anderem deshalb, weil wir die dunklen, uns nicht bekannten und unter der Oberfläche schlummernden „Schulden“ erkennen und beheben wollen (Surface Dark Debt). Die Erkenntnisse aus den Experimenten nutzen wir, um daraus zu lernen und Verbesserungen an unserem System vorzunehmen. Die daraus resultierenden Chaos-Tests wiederum wenden wir zur kontinuierlichen Kontrolle unserer Systeme an, ähnlich wie wir es mit Unit-, Integrations-, und Systemtests tun. Sollte ein Chaos-Test im späteren Verlauf doch wieder scheitern, dann ist erneut oder durch andere Umstände eine Schwachstelle aufgetreten, die wir beheben müssen.

Doch wie können wir nun die geplanten Experimente durchführen, welche Möglichkeiten haben wir, um zum Beispiel Last oder Latenz künstlich herbeizuführen? Wir starten auf dem Infrastrukturlevel, dem Level, auf dem auch die von Netflix bekannte Simian Army ansetzt und auf dem zum Beispiel der Netflix Chaos Monkey einzelne Instanzen eliminiert. Das Infrastrukturlevel ist aber zugleich auch das Level, auf dem ihr den meisten Schaden anrichten könnt. Dementsprechend solltet ihr euch der möglichen Auswirkung zu 100 Prozent bewusst sein. Alle Experimente, die ihr auf diesem Level ausführt, betreffen alle Komponenten, die auf diesem Host betrieben werden!

Tools – Infrastrukturlevel

Nehmen wir uns zuerst einmal des Falls an, dass wir auf einem dedizierten Host Last erzeugen möchten. Dies können wir unter anderem erreichen, indem wir dem Host etwas zur Berechnung geben.

OpenSSL

Das folgende Beispiel (OpenSSL Beispiel 1) stammt von Tammy Butow, ebenfalls Chaos Engineer beziehungsweise Principal SRE (Site Reliability Engineer) bei Gremlin Inc. aus den USA:

# burn.zsh while true; do openssl speed; done EOF

Hier verwenden wir OpenSSL [3], um die Performance bei der Berechnung von Kryptografiealgorithmen zu testen. Da mit nur einem einzigen Prozess noch etwas wenig Last auf dem System ist, werden wir dies mit insgesamt 32 Prozessen durchführen (OpenSSL Beispiel 2). So bekommen wir selbst die dicken Kisten zum schwitzen, die uns die Cloud-Provider so nett zur Verfügung stellen.

# cpu_burning.zsh for i in {1..32} do nohup /bin/zsh burn.zsh & done

Aber vielleicht erkennt ihr auch bereits an dieser Stelle, dass dies nicht sehr kontrolliert stattfindet und wir im Nachgang auch immer noch versuchen müssen, alle 32 Prozesse wieder zu stoppen beziehungsweise zu killen. Es geht auch eleganter und kontrollierter.

Stress CPU

Anstelle von 32 wildgewordenen Prozessen können wir auch Stress CPU [4] einsetzen – eine Möglichkeit, die uns in den gängigsten Linux-Distributionen zur Verfügung steht. Alternativ gäbe es auch noch cpuburn [5].

Beim Einsatz dieser kleinen Helfer können wir die CPU unter Last setzen, den Arbeitsspeicher volllaufen lassen und IO-Operationen durchführen. Entweder einzeln oder alles auf einmal, wie im folgenden Beispiel zu sehen. Das Gute daran ist, dass wir beim Start mitgeben können, wie lange dieser Test durchgeführt werden soll. Zudem können wir auch jederzeit unterbrechen:

stress --cpu 2 --io 1 --vm 1 --vm-bytes 128M --timeout 10s --verbose

Es geht aber noch weiter: In verteilten Applikationen haben wir immer wieder mit dem lästigen Thema Latenz zu kämpfen. Dadurch, dass unsere Applikationen hochverfügbar sein müssen und wir dynamisch die Ressourcen nehmen, die wir benötigen, stecken wir in dem Dilemma, dass sich unsere Applikationen nicht mehr in unmittelbarer Nähe zueinander befinden. Das Ganze verstärkt oder verschlimmert sich, sobald wir unsere Anwendungen bei Cloud-Anbietern betreiben. Denn dann haben wir keinen Einfluss mehr darauf, welcher Service in welchem Bereich des Rechenzentrums läuft.

Daher wäre es gut, wenn wir auf Netzwerkebene Latenz oder Fehler herbeiführen könnten, um herauszubekommen, wie unsere Applikationen mit diesen Umständen umgehen.

Traffic Control Package IPRoute2

Mit Traffic Control (TC) [6] können wir das Verhalten in verteilten Anwendungen gezielt beeinflussen und zum Beispiel Latenz herbeiführen, Netzwerkpakete duplizieren, droppen oder als korrupt kennzeichnen. TC beeinflusst dabei den gesamten Traffic eines gezielten Netzwerkdevice und muss nach unserem Chaos-Experiment auch wieder manuell entfernt werden!

delay - fügt allen Paketen eine Latenz zwischen 100ms bis 120ms hinzu tc qdisc add dev eth0 root netem delay 100ms 20ms packet loss - erzeugt einen Paketverlust von zum Beispiel 10% tc qdisc add dev eth0 root netem loss 10% packet duplication - dupliziert zum Beispiel 10% der Netzwerkpakete tc qdisc add dev eth0 root netem duplicate 10% packe corruption - 10% aller Pakete werden als korrupt gekennzeichnet tc qdisc add dev eth0 root netem corrupt 10%

Es sind auch noch andere wilde Kombinationen möglich, die natürlich auch den Root-Zugriff auf dem entsprechenden Server voraussetzen. Daher wird es Zeit, uns dem nächsten Level des Chaos Engineerings zu widmen.

Tools – Plattformlevel

Anders als auf dem Infrastrukturlevel könnt ihr auf dem Plattformlevel viel besser und vor allem sicher steuern, welche Komponenten von euren Chaos-Experimenten betroffen sind. Ihr könnt den Blast-Radius kontrollieren und steuern, wie groß die Auswirkungen auf andere Komponenten sein werden....

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang