PLOSSYS 5 und Kubernetes

von  Thomas Tikwinski

Mit PLOSSYS 5 entwickelt SEAL Systems die nächste Generation von Output Management System. Obwohl es natürlich weiterhin möglich ist, PLOSSYS 5 lokal, also on premises zu installieren, ist das System von Anfang an für den Betrieb in der Cloud konzipiert worden. Statt eines monolithischen Systems läuft PLOSSYS 5 in der Cloud als Cluster von Microservices, die je nach aktueller Last gestartet oder gestoppt werden können. Das System verwendet damit immer nur so viele Ressourcen, wie gerade tatsächlich benötigt werden.

In diesem Blogbeitrag stellen wir vor, wie dieses Verfahren in der Praxis aussieht – und wie flexibel auch Ihr Output Management System in Zukunft arbeiten könnte. Als Beispiel für eine Cloudumgebung haben wir uns einen Kubernetes-Cluster auf Basis der Amazon Web Services (AWS) ausgesucht. Wir hätten auch andere Anbieter und Clustermanager verwenden können, etwa Azure als Basis oder OpenShift. Die gewählte Kombination erlaubt es lediglich besonders gut, die Vorteile dieser Technik aufzuzeigen.

Szenario

Was wir in diesem Post zeigen wollen, ist ein typisches Szenario für einen kleinen bis mittelgroßen Einsatz von PLOSSYS 5: Eine operative Datenbank (ausfallsicher im Verbundbetrieb mit drei DB-Instanzen), eine Instanz der Logdatenbank, und ein Satz P5-Microservices. Dieses Szenario ist beispielsweise für SAP-Spool- und Windowsdruck mit bis zu 100.000 Druckjobs pro Tag sehr gut geeignet. Wir erklären, wie das Szenario aufgebaut ist, und zeigen, wie die Clustertechnik Ausfallsicherheit und sparsamen Ressourceneinsatz unter einen Hut bringt.

Aufbau

Kubernetes-3-web-300x188 PLOSSYS 5 und KubernetesAusgangspunkt ist PLOSSYS 5, das wir in Form von Softwarecontainern für den Betrieb im Cloud-Cluster vorbereitet haben. Auf AWS haben wir für unseren Cluster vier virtuelle Maschinen aufgesetzt, die von Kubernetes als Knoten verwaltet und zu einem Cluster zusammengefasst werden. Ein Managerknoten kümmert sich um die Überwachung, Steuerung, Lastverteilung, Konfiguration und das interne Netzwerk. Drei Workerknoten betreiben den Datenbank-Cluster und stellen ihre restliche Rechenleistung für den eigentlichen PLOSSYS-5-Betrieb zur Verfügung. Der Manager sorgt wiederum dafür, dass diese Leistung optimal genutzt wird. Die Managerknoten sind dabei als eigene Autoscale-Gruppe realisiert: Wenn Managerknoten ausfallen sollten, startet AWS selbständig neue Managerknoten nach, so dass der Cluster nie ganz ausfällt. Die Clusterleistung überwachen wir mit Prometheus, die Dashboards erzeugen wir mit Graphana.

Das folgende Bild zeigt den Zustand des Clusters mit drei Knoten á zwei CPU-Kerne und 16GB RAM (also insgesamt 6 Kerne und 48GB RAM). Auf dem Cluster sind 36 Services aktiv, einschließlich Datenbanken, PLOSSYS-Services und Überwachung. Die Services reservieren sich 79% der verfügbaren CPU-Kapazität und 16% des verfügbaren RAMs. Die tatsächliche Last ist sehr gering (links im Diagramm erkennbar). Unter Last zeigen die blauen Balken die tatsächliche Ressourcenauslastung im Cluster über die Zeit.

Arbeiten mit flüchtigen virtuellen Maschinen

Für alle Clusterknoten auf AWS setzen wir sogenannte Spot-Instanzen ein. Diese virtuellen Maschinen können von Amazon zwar jederzeit mit wenigen Minuten Vorlaufzeit abgeschaltet werden, wenn die Ressourcen anderweitig benötigt werden. Im Gegenzug sind die Spot-Instanzen aber drastisch günstiger als dauerhaft laufende virtuelle Maschinen. Diesen Vorteil können wir nutzen, weil Clustertechnik und Microservices PLOSSYS 5 von festen virtuellen Maschinen unabhängig machen. Wird eine der Spot-Instanzen gestoppt, fällt sie einfach aus dem Cluster heraus. Der Cluster-Manager registriert das Fehlen von Ressourcen und Services, fährt eine neue virtuelle Maschine hoch, bindet sie in den Cluster ein und startet die fehlenden Microservices automatisch nach.

Denselben Mechanismus benutzt PLOSSYS 5 auch, um Ausfallsicherheit im Cluster herzustellen. Der einzige Unterschied zwischen dem Ausfall einer virtuellen Maschine und dem Abschalten einer Spot-Instanz besteht in der fehlenden Vorlaufzeit. Nach kurzer Zeit erkennt PLOSSYS 5 auch ohne Vorlauf den Ausfall der virtuellen Hardware und reagiert genau wie nach dem Abschalten einer Spot-Instanz: eine neue VM wird erzeugt, eingebunden und die fehlenden Services nachgestartet.

Auto-Skalierung

Kubernetes-2-web-300x188 PLOSSYS 5 und KubernetesÄhnlich wie bei Ausfall von Knoten reagiert der Cluster auch auf steigenden Ressourcenbedarf bei starker Last.  Werden mehr Ressourcen angefordert, als der Cluster bieten kann, wird die Autoskalierung aktiv. Der Cluster-Manager fährt dann automatisch zusätzliche Worker-Instanzen hoch, um weitere Services zu starten und die Lastspitze abzufangen. Fällt die Last später wieder ab, so dass der Cluster auch mit weniger Worker-Instanzen auskommen kann, räumt der Manager nach und nach Worker-Instanzen frei und schaltet sie automatisch wieder ab. Das Bild zeigt den Cluster in einem Zustand, in dem mehr Services gestartet wurden, als der Cluster betreiben kann (erkennbar an der Zahl der angeforderten CPU-Kerne und den sieben fehlenden Service-Instanzen, in rot dargestellt).

In diesem Fall startet der Cluster-Manager automatisch zusätzliche Worker-Instanzen mit weiteren sechs Kernen und 36GB RAM und bindet sie in den Cluster ein. Dort starten die angeforderten zusätzlichen Services. Dadurch normalisiert sich der Betrieb, die Last liegt wieder im nominellen Bereich.

Kubernetes-1-web-300x188 PLOSSYS 5 und KubernetesDiese Situation ist im folgenden Bild zu erkennen: Die Anzahl der CPU-Kerne im Cluster hat sich auf 12 erhöht, der verfügbare Speicher ist auf 84GB angewachsen. Insgesamt sind nun 83 Services aktiv.

Massive Kostenvorteile

Die Vorteile einer Cloud-Native-Anwendung mit Microservice-Architektur im Clusterbetrieb sind mannigfach. So ist es nicht nur möglich, die Anzahl der benötigten Services, sondern auch die Zahl der Server immer der tatsächlichen Systemauslastung automatisch anzupassen und damit unmittelbar Kosten zu sparen. Weitere Einsparungen ergeben sich aus der Nutzung der kostengünstigen, volatilen Spot-Instanzen, deren potentieller spontaner Ausfall von Kubernetes aufgefangen wird. Die Ausfallsicherheit auf Service- und Serverebene ist dabei bereits Teil von PLOSSYS 5.

Durch die ständige Erneuerung der Instanzen fallen obendrein die Aufwände für Wartung und Pflege der Server weg. Systeme mit veraltetem OS werden in Lauf der Zeit automatisch durch neue Systeme mit aktuellem OS ersetzt. Und auch die Abhängigkeit vom Cloud-Anbieter entfällt: Kubernetes und Openshift lassen sich mittlerweile bei nahezu jedem Cloud-Anbieter installieren.

Möchten Sie mehr wissen?

Fordern Sie unverbindlich die Kontaktaufnahme durch unsere Experten an!

*Kein Newsletter, keine Weitergabe, Kontaktaufnahme per E-Mail nur zum genannten Zweck.

 

Teilen

Hinterlassen Sie eine Antwort

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert. *

* = Pflichtfeld

  • Blog-Kategorien

  • Anstehende Veranstaltungen

    1. PLM Europe – Siemens PLM Connection 2018

      29. Oktober 2018 - 31. Oktober 2018
    2. SEAL Systems Schulungstage

      13. November 2018 - 15. November 2018