GODAV Verwaltung: viele Instanzen, ein Überblick

Bisher war GODAV Pro eine Anwendung, die man auf einem eigenen Server installiert. Und dieser Server war mein eigener Rechner. Mit dem Cloudbetrieb kommt eine zweite Art dazu: Der skalierbare Cloudbetrieb. Jeder Kunde bekommt seine eigene Instanz unter einer eigenen Adresse auf separaten Servern. Das wirft sofort eine praktische Frage auf: Wie behalte ich den Überblick, wenn auf unterschiedlichen Servern nicht eine, sondern zehn oder zwanzig Instanzen laufen? Die Antwort ist die GODAV Verwaltung, ein eigenes kleines Programm, das ich in den letzten Tagen gebaut habe.

Ganze nebenbei schützt der Cloudbetrieb auch mein Backend und somit meinen Quellcode. Eine lokal installierte Instanz auf den Servern eines Kunden kann vom Kunden auch verändert werden. Mit dem entsprechenden Know-How kann zum Beispiel die Lizenzprüfung deaktiviert werden.

Eine Instanz je Kunde

Die wichtigste Entscheidung fiel, bevor die erste Zeile der Verwaltung entstand: Jeder Kunde bekommt eine eigene Instanz mit eigenem Serverprozess und eigener Datenbank. Der Programmstand ist für alle derselbe, die Daten liegen strikt getrennt.

Die Alternative wäre eine gemeinsame Datenbank für alle Kunden gewesen, in der jede Zeile eine Kundenkennung trägt. Das ist das übliche Muster bei großen Cloudanwendungen. Für GODAV hätte es bedeutet, rund 160 Tabellen umzubauen und an jeder einzelnen Abfrage daran zu denken, nach dem richtigen Kunden zu filtern. Eine vergessene Bedingung ist dort kein Absturz, sondern ein Datenleck: Kunde A sieht die Projekte von Kunde B. Mit getrennten Instanzen kann dieser Fehler gar nicht erst entstehen. Der Preis ist mehr Betriebsaufwand, und genau den nimmt mir die Verwaltung ab.

Auf einen Blick: Laufen alle Instanzen, sind sie von außen erreichbar, welche Version, welche Lizenz, wann zuletzt gesichert.

Was die Verwaltung kann

Die Übersicht beantwortet die Fragen, die man morgens als Erstes stellt: Läuft alles? Ist jede Instanz auch wirklich von außen erreichbar? Gibt es eine Lizenz, die bald abläuft oder ganz fehlt? Ist eine Sicherung überfällig? Von dort geht es in jede einzelne Instanz, und dort lässt sich alles erledigen, was im Betrieb anfällt:

• Instanzen anlegen und entfernen. Vor dem Entfernen wird gesichert, und die Sicherungen bleiben auf dem Server.
• Lizenzen ausstellen und verlängern und direkt in die Instanz einspielen.
• Updates je Instanz, mit Rücksprung auf den vorherigen Stand.
• Sicherungen sofort oder nach Zeitplan, je Instanz eigener Takt, mit Wiederherstellung.
• Verfügbarkeit jetzt und im Verlauf von 24 Stunden bis zwölf Monate.
• Ressourcen des Servers samt der Frage, ob er erweitert werden muss.

Updates, die sich zurücknehmen lassen

Jede Instanz läuft auf ihrem eigenen Programmstand. Ein neues Paket wird auf dem Server neben die vorhandenen Versionen gelegt, und dann entscheide ich je Instanz, wann sie umzieht. So kann ein neuer Stand erst bei einem Testkunden laufen, bevor alle anderen folgen.

Wichtiger noch ist der Weg zurück. Antwortet eine Instanz nach dem Update nicht, springt sie von selbst auf die vorige Version zurück, und im Verlauf steht, warum. Im Bildschirmfoto unten sieht man genau so einen Fall: „Instanz antwortete nach dem Update nicht”. Das ist mir beim Testen tatsächlich passiert, und statt eines nächtlichen Notfalls war es ein Eintrag in einer Tabelle.

Jede Version liegt auf dem Server bereit; „Zurückspringen” ist ein Klick, und ein gescheitertes Update nimmt sich selbst zurück.

Gemessen wird auf dem Server, nicht auf meinem Rechner

Eine Entscheidung, die man nicht sieht, die aber viel ausmacht: Verfügbarkeit, Ressourcen und Sicherungszeitpläne laufen auf dem Server selbst, als Zeitgeber des Betriebssystems. Die Verwaltung liest diese Daten nur und stellt die Zeitpläne ein.

Ich hätte die Messung auch in die Verwaltung einbauen können. Dann gäbe es aber nur Messwerte, solange mein Rechner läuft, und jede Nacht wäre eine Lücke im Verlauf. Eine Verfügbarkeit, die genau dann nicht misst, wenn niemand hinschaut, ist wertlos. So misst der Server jede Minute, lückenlos, und die Verwaltung zeigt beim nächsten Öffnen einfach den ganzen Verlauf.

Zusätzlich prüft die Verwaltung, solange sie läuft, die Erreichbarkeit von außen: Stimmt der Name im DNS, antwortet der Webserver, ist das Zertifikat gültig? Ein Dienst kann auf dem Server einwandfrei laufen und trotzdem für den Kunden nicht erreichbar sein, und genau diesen Unterschied soll man sehen.

Jede Minute auf dem Server gemessen, auch wenn mein Rechner aus ist.

Braucht der Server mehr Leistung?

Die Seite „Ressourcen” zeigt Prozessor, Arbeitsspeicher, Speicherplatz und Datenträger, je Instanz und im Verlauf bis zu 13 Monate. Die eigentliche Arbeit steckt aber in der Bewertung darüber: Muss der Server erweitert werden?

Eine hohe Auslastung allein ist dafür ein schlechter Maßstab. Ein Prozessor, der zeitweise voll ausgelastet ist, arbeitet einfach. Entscheidend ist, ob jemand warten musste. Linux misst das selbst: wie oft ein Prozess bereit war, aber auf Prozessor, Speicher oder Datenträger warten musste. Diese Wartezeit ist das sicherste Zeichen dafür, dass ein Kunde langsamer bedient wurde, und deshalb stützt sich die Bewertung darauf. Für den Speicherplatz kommt eine Prognose dazu, wann er voraussichtlich voll ist.

„Kein Ausbau nötig”: Die Bewertung stützt sich auf Wartezeiten, nicht auf die bloße Auslastung.

Wie sie mit dem Server spricht

Die Verwaltung ist eine kleine Webanwendung, die nur auf meinem eigenen Rechner läuft und nur von dort erreichbar ist. Bei jedem Start entsteht ein neuer Zugangsschlüssel, und den kennt nur das Browserfenster, das der Starter öffnet. Zum Server verbindet sie sich per SSH und ruft dort ein einziges Betriebsskript auf, das alles Eigentliche erledigt und seine Antwort als strukturierte Daten zurückgibt.

Zwei Dinge waren mir dabei wichtig:

• Die Verwaltung speichert keine Geheimnisse. Der SSH-Schlüssel bleibt, wo er ist. Das Startpasswort einer neuen Instanz erscheint genau einmal auf dem Bildschirm und landet nirgends im Verlauf.
• Der Zugang auf dem Server ist eng. Der Benutzer der Verwaltung darf genau dieses eine Skript mit erhöhten Rechten ausführen und sonst nichts. Jedes Argument wird außerdem so verpackt, dass der Server es als ein Wort versteht. Ohne das könnte ein ungünstiger Instanzname auf dem Server als zweiter Befehl ankommen, und zwar mit Administratorrechten.

Getestet an einem Server im Container

Ein Betriebsskript, das systemd, nginx und PostgreSQL braucht, lässt sich nicht sinnvoll gegen eine Attrappe testen. Deshalb gibt es einen Testserver im Container: ein vollständiges kleines Linux mit allen Diensten, auf dem der normale Installer und das Betriebsskript unverändert laufen. Alle Bildschirmfotos in diesem Beitrag stammen von dort, und die drei „Firmen” sind Testinstanzen.

Die Verwaltung ist bewusst ein eigenes Programm mit eigenem Repository. Sie gehört nicht ins Installationspaket von GODAV: Wer GODAV auf seinem eigenen Server betreibt, braucht sie nicht, und sie soll dort auch nicht auftauchen.

Außerdem

• Ein Starter für den Schreibtisch: Doppelklick, und die Verwaltung läuft. Ein zweiter Doppelklick öffnet nur den Browser erneut, statt einen zweiten Server zu starten.
• Die Oberfläche folgt denselben Gestaltungsregeln wie GODAV selbst, im hellen wie im dunklen Modus.
• Mehrere Server lassen sich eintragen und oben rechts umschalten.

Wie es weitergeht

Bisher ist die Verwaltung nur gegen meinen eigenen Rechner gelaufen. Der nächste Schritt ist der erste echte Server im Netz, und der wird zeigen, was ein Container nicht zeigen kann. Dafür arbeite ich mit einem IT-Unternehmen zusammen, die sich sehr darauf freuen GODAV Pro selbst zu nutzen. Zusätzlich kann ich so auch meine Microsoft Teams Integration weiter vorantreiben.