News

Welche Rolle unser durchgehend redundantes Setup spielt

Bei Upgrades kommt uns die Auslegung unserer Systeme auf Hochverfügbarkeit entgegen, wobei sämtliche Komponenten in mindestens zweifacher Ausführung vorhanden sind bzw. mindestens dreifach, wenn ein Quorum erforderlich ist. Dieses Setup schützt uns und unsere Kunden nicht nur vor ungeplanten Downtimes beim Ausfall einzelner Systeme, sondern erlaubt es uns auch, bei Wartungsarbeiten die Systeme sequenziell zu bearbeiten, so dass der produktive Betrieb des Gesamtsystems ohne Unterbruch gewährleistet bleibt.

Die OpenStack-Komponenten, die für die Erstellung und Verwaltung der virtuellen Server zuständig sind, konnten wir so System für System aktualisieren. Und weil von jeder Komponente immer mindestens zwei Instanzen in Betrieb waren, blieb auch die Verwaltung der virtuellen Server via Cloud-Control-Panel und API für unsere Kunden verfügbar. Im Fall der Compute-Nodes, auf denen die virtuellen Server laufen, wäre ein OpenStack-Upgrade sogar im laufenden Produktiv-Betrieb möglich. Gleichzeitig anstehende Upgrades des darunterliegenden Linux-Systems erfordern oft trotzdem einen Reboot. Ihre virtuellen Server bleiben jedoch dank vorgängiger Live-Migration auf einen anderen Compute-Node selbst in einem solchen Fall ohne Unterbrechung online.

Wie OpenStack unterbrechungsfreie Upgrades unterstützt

OpenStack ist ein komplexes System aus verschiedenen Komponenten, die miteinander interagieren. Dass es möglich ist, diese Komponenten (bzw. im Falle eines redundanten Aufbaus nur einzelne Instanzen davon) nacheinander zu aktualisieren, ist dabei nicht ganz selbstverständlich: im Laufe dieses Prozesses befindet sich ja ein Teil des OpenStack Gesamtsystems noch auf dem alten, der andere Teil aber schon auf dem neuen Stand. Das OpenStack-Projekt achtet deshalb bewusst darauf, dass die einzelnen Komponenten auch mit solchen Komponenten zusammen funktionieren, die noch auf der Vorversion laufen. Erst dadurch ist es möglich, das Gesamtsystem während des ganzen Upgrade-Prozesses funktionsfähig zu halten.

Beim kürzlichen Upgrade auf OpenStack "Pike" starteten wir wie immer mit umfassenden Tests in unserer Lab-Umgebung. Dabei optimierten wir unsere Ansible-Playbooks, so dass jederzeit von jeder OpenStack-Komponente immer mindestens zwei Instanzen verfügbar bleiben. Um sicherzugehen, dass das Zusammenspiel der Komponenten auch über Versionsgrenzen hinweg wie erwartet funktioniert, liessen wir geskriptet via API permanent neue virtuelle Server erstellen – ein potenzielles Problem wäre an dieser Stelle schon im Lab aufgefallen.

Was wir tun, um Auswirkungen weiter zu reduzieren

In einigen Fällen liessen sich kurze Unterbrüche (in der Regel unter 5 Minuten) des Cloud-Control-Panels und der API dennoch nicht vermeiden, z.B. wenn die Konfiguration eines Loadbalancers zeitgleich an die neue Version der dahinterliegenden OpenStack-Komponente angeglichen werden musste. Während laufende virtuelle Server davon unbeeinflusst bleiben, sind Änderungen in so einem Moment nicht möglich – insbesondere auch nicht das Verschieben einer Floating IP zu einem anderen virtuellen Server, welches viele unserer Kunden als Failover-Mechanismus für hochverfügbare Setups nutzen.

Wir arbeiten deshalb daran, nötige Downtimes noch enger begrenzen zu können, indem wir z.B. betroffene Operationen sperren, während Control-Panel und API als Ganzes verfügbar bleiben. Beim Upgrade auf "Pike" konnten wir bereits einen solchen Mechanismus nutzen: als durch grössere Änderungen in der OpenStack-eigenen API das Skalieren von Volumes vorübergehend nicht möglich war, konnten wir dies gezielt in unseren Interfaces abbilden und alle anderen Aktionen weiterhin zulassen.

Das Upgrade eines so komplexen Systems wie OpenStack ist eine Sache von mehreren Stunden. Es ist nicht ganz trivial, auch während dieses Prozesses durchgängig die bestmögliche Verfügbarkeit sicherzustellen. Mit redundanten Systemen auf jeder Stufe sind wir hier schon gut gerüstet. Wo dennoch Unterbrechungen zwingend sind, versuchen wir, diese möglichst gering zu halten – im Idealfall muss nur eine einzelne Operation kurzzeitig blockiert werden. Und wie immer gilt: testen, testen und nochmals testen.

Seriös vorbereitet,
Ihr cloudscale.ch-Team