Konzept (DE)
Die Phasen einer Veranstaltung spiegelt sich auch in der Nutzung von OpenSlides wieder. Während der Vorbereitungszeit sind lediglich die Personen in OpenSlides aktiv, welche auch an der Vorbereitung der Veranstaltung mitwirken. Zu Beginn der Veranstaltung, steigt die Nutzung von OpenSlides sprunghaft an.
Alle Teilnehmer loggen sich ein und Arbeiten mit der Plattform. Dabei ist die obige Abbildung stark vereinfacht, da Konferenztage natürlich nicht über 24h anhalten, sondern i.d.R. 8 bis 12 Stunden dauern. Es verdeutlicht jedoch die Problematik, welche das Standard-Setup von 1 Instanz auf 1 Server (1:1) (1 Instanz ist dabei gleichbedeutend mit 1 Veranstaltung) mitbringt. Für diese Problematik sollen im folgenden einige Ansätze erläutert werden.
In dem openslides-docker wurde bereits eine
erste Virtualisierung für OpenSlides entwickelt. Hierbei wurden die
Services (welche für den Betrieb nötig sind) aufgeteilt, so dass die
einzelnen Komponenten für den Einsatz skaliert werden können.
Dieses Setup eignet sich, mit einem vorgeschaltetem nginx für einen
viele Instanzen auf 1 Server (n:1) Einsatz, so dass man mit geschickter
Planung für die Veranstaltungszeiträume der einzelnen Instanzen eine
bessere Auslastung schaffen kann.
Diese Planung erfordert jedoch noch viel händische Planung und Arbeit,
könnte jedoch, wie schon mit dem bisherigen
openslides-multiinstance-backend schon teil-automatisiert werden, so
dass Kunden sich eigene Instanzen erstellen können. Jedoch muss für
jeden Kunden hierbei eine eigene Serverumgebung geschaffen werden und
der Kunde braucht ein technisches Verständnis, da die Hardwareressourcen
in der Umgebung eine harte Grenze haben.
Das Ziel ist also ein System zu entwickeln, das nicht nur ein viele
Instanzen auf 1 Server(n:1)-Setup ermöglicht, sondern ein viele
Instanzen auf mehreren Servern (n:m)-Setup. Es soll automatisch
skalieren und es Kunden, ohne technisches Verständnis, möglich machen,
so viele Instanzen wie gewünscht zu starten, ohne dabei auf
Ressourcen-Grenzen achten zu müssen.
Um ein viele Instanzen auf mehreren Server (n:m)-Setup zu erreichen,
in dem die einzelnen Instanzen sich den Anforderungen (Nutzung)
anpassen, wird eine Orchestrierung benötigt. Die Instanzen sollen dabei
vollständig skalieren, d.h. bei Nicht-Nutzung über einen bestimmten
Zeitraum, sollen sie schlafen und erst bei Zugriffsanfrage wieder
aufwachen.
Des Weiteren muss es möglich sein, mit Vorlagen das Erstellen von Instanzen steuern zu können. Unterschiedliche Kunden haben unterschiedliche Anforderungen und brauchen unterschiedliche Vorbelegungen, Plugins oder Brandings. Diese müssen einfach auswählbar sein.
Ein System, welches diese Anforderungen abbilden kann, ist
kubernetes. Des Weiteren kann helm dazu genutzt
werden, um die Applikation und ihre Anforderungen zu definieren.
Das Gesamtsystem muss für Kunden einfach überwachbar sein, jedoch auch einen guten Einblick für Adminstration und Dev-Ops geben. Über einen einzelnen Punkt soll schnell einsehbar sein, wie der Gesundheitszustand des Gesamtsystems ist und ohne viele Umwege soll es auch möglich sein eine schnelle Fehleranalyse der einzelnen Instanzen zu betreiben. Dabei soll sowohl für Kunden, als auch für die Adminstration Statistiken angezeigt werden.
Ein mögliches System um eine solche Überwachung zu schaffen wäre
prometheus.
Damit Großkunden (bei denen OpenSlides auf mehreren Veranstaltungen und Gliederungsebenen genutzt wird) einem Nutzer Zugang zu mehreren Instanzen geben kann, wird ein Dritt-Dienst (Identitätsservice) benötigt, welcher die Nutzerverwaltung auf übergeordneter Ebene der Instanzen verwaltet. Des Weiteren soll es damit möglich sein, dass die Nutzer über diesen Dienst heraus finden können, auf welche Instanzen sie Zugriff haben und sich über ein zentrales Interface einloggen können.
Ein System mit dem man einen Großteil der Anforderungen umsetzen kann
ist keycloak.
Als DBMS für OpenSlides wird postgres eingesetzt. Als
Service zum Zwischenspeichern der Informationen ist redis im
Einsatz. Hierfür bieten Dienstleister häufig einen sogenannten PaaS
(Platform as a Service) an, also eine vorbereitete Installation der
Software, die vom Dienstleister gepflegt wird. Wenn diese genutzt werden
sollen, muss darauf geachtet werden, dass der Umgang mit den
schützenswerten Informationen aus OpenSlides nicht gefährdet wird und
die gleiche Sicherheitsstufe gewährleistet werden kann, wie bei einem
Einsatz von einzelnen Service-Instanzen für jede OpenSlides-Instanz.
Zudem wird für einige Kunden eine Streaming Replication von
postgres Streaming Replication angeboten, diese muss weiterhin möglich
sein. Dies wird eingesetzt, um bei einem eventuellen Verbindungsausfall
eine lokale Instanz offline zu nutzen.
Alle genannten Anforderungen müssen in ein Gesamtsystem gebracht werden. Dieses Gesamtsystem muss klein- und groß-mandantenfähig sein. Ein Kunde mit nur einer einzelnen Instanz soll ebenso wie ein Kunde mit einer Vielzahl von Instanzen (inkl. einem Identitäts-Management-Service) das gleiche System nutzen können.
Für die Abrechnungen sollen verschiedene Modelle hinterlegt werden können, die Abrechnungen auf unterschiedlichen Metriken erstellen.
Die Nutzer des Gesamtsystems sollten grundsätzlich getrennt von den Nutzern der einzelnen Instanzen sein. Dabei sollte es jedoch möglich sein, dass adminstrative Nutzer einer Instanz auch die Möglichkeit bekommen Zustand und Statistiken ihrer Instanz im Gesamtsystem einzusehen und adminstrative Tätigkeiten (z.B. Instanz stoppen/archivieren) übernehmen.
Um die einzelnen Instanzen zu erreichen, muss es möglich sein auf (kundeneigene) Domain-Wildcards zu lauschen.
Alle Statistiken, Übersichten und Adminstrationen müssen über das Gesamtsystem verwaltet werden können.
Dieses Gesamtsystem stellt den zentralen Zugang zur OpenSlides-Cloud dar. Es implementiert alle Features des bisherigen Mutltiinstance-Backends und enthält die neuen Features, die hier beschrieben sind.
Ein Möglicher Aufbau für das Gesamtkonzept ist nachstehend aufgezeigt.
Es wird ein Gesamtsystem entwickelt, welches auf einer skalierbaren Lösung aufsetzt, um den Fußabdruck für genutzte Hardwareressourcen so klein wie möglich zu halten. Es soll zudem den administrativen Aufwand verringern und die Bedienung so kundenfreundlich wie möglich gestalten. Dabei soll eine hohe Ausfallsicherheit gewährleistet und weiterhin die klare Trennung zwischen den einzelnen Instanzen beibehalten werden.
Für Kunden wird dabei eine einfache Oberfläche zur Verwaltung geboten, mit der einfach und schnell neue Instanzen bereit gestellt werden können.