Für die digitale Bundesdelegiertenkonferenz 2020 der Grünen betrieben wir als gemeinsames Team der verdigado und Netzbegrünung das Streaming- und Abstimmungsportal, das während der Veranstaltung unter bdk.gruene.de zur Verfügung stand. Außerdem waren wir, ähnlich wie bei früheren BDKs, zusammen mit vielen anderen an der Produktion und der technischen Infrastruktur für den Video-Livestream beteiligt. Im folgenden Beitrag möchten wir die Technik und auch die aufgetretenen Probleme ein bisschen näher beleuchten. In den Fußnoten finden sich weitere technische Details für Interessierte.
Bereits zur Beginn der Corona-Pandemie Anfang März, sammelten wir wertvolle Erfahrungen, wie wir als Netzbegrünung und gerade im Aufbau befindliche Genossenschaft verdigado, das sich digitalisierende Partei-Leben mit der Bereitstellung, bzw. dem Ausbau existierender Onlinedienste stärker unterstützen konnten. Erster Höhepunkt dieser Bemühungen war außerdem der digitale Länderrat Anfang Mai, als wir mit weitaus weniger Delegierten einen ersten kleinen Parteitag via Videokonferenz-Lösungen abhielten. Uns wurde aber schnell klar, dass die BDK eine Veranstaltung ganz anderen Kalibers sein würde.
Selbstentwickeltes Abstimmungstool & Open Source Software
Die Vorbereitungen zur technischen Umsetzung starteten im August 2020, nachdem sich abzeichnete, dass die Durchführbarkeit der BDK als Präsenzveranstaltung immer unwahrscheinlicher werden würde. Frühzeitig war klar, dass ein Video-Livestream der Kern einer digitalen Konferenz sein muss. Hier liegt natürlich eine Kernkompetenz im Know-How der Netzbegrünung, die bereits seit vielen Jahren Parteitage so live ins Netz bringt. Dementsprechend waren Technik und Know How dafür bereits erprobt vorhanden, auch wenn sich durch den Rahmen einige Dinge ändern würden. Da das Grundsatzprogramm verabschiedet werden musste, war ebenfalls klar, dass ein System für Abstimmungen nötig war, die über einfachste Lösungen hinausgeht, denn Delegationen und Stimmberechtigungen wollen sorgsam verwaltet werden. Auch hier konnte auf bereits existierende Software zurückgegriffen werden: Das Abstimmungsgrün, welches im Frühsommer 2020 von Personen aus der Netzbegrünung im Auftrag der Bundesgeschäftsstelle entwickelt wurde. Ebenso stehen Mitgliedern der Partei seit Jahren weitere digitale Werkzeuge zur Verfügung, beispielsweise das Antragsgrün, die Chatbegrünung (ein Rocket.Chat), die Wolke (Nextcloud), sowie einer öffentlichen Videokonferenzlösung (Jitsi Meet). Insbesondere auf unserem Jitsi lag der Fokus unserer Arbeiten im März. Diese Komponenten sollten nun also in einen Rahmen gegossen werden, der einen flüssigen Ablauf der Veranstaltung ermöglichen konnte.
Die oberflächlichen Anforderungen ließen sich mit den existierenden Komponenten leicht abdecken: ein Stream vom Veranstaltungsort ermöglicht live Redebeiträge, via Jitsi können Redner:innen von zu Hause zugeschaltet werden, und alle Delegierten und Parteimitglieder können sich im Hintergrund via Rocket.Chat austauschen. So wurde beschlossen, diese Komponenten in einer Plattform zusammenzuführen, die auch neben Parteimitgliedern der Öffentlichkeit das Verfolgen des Parteitags ermöglichen sollte.
Wenig Zeit, viele Funktionenwünsche und Live-Support
Für ein IT-Projekt, welches auf eine so große Veranstaltung abzielt, war der verbleibende Umsetzungszeitraum von nur drei Monaten extrem knapp bemessen, weswegen sehr schnell die Entscheidung für einen vergleichsweise einfachen Aufbau gefällt wurde: Stream und Chat sollten nur via iframes eingebunden werden, lediglich Abstimmungen, ein Jitsi-Raummanagement und ein Emotions-Feedback sollten direkt in die Plattform integriert werden. Die Idee für das Jitsi-Raummanagement entsprang der Erfahrung, dass sich für stabile Redebeiträge eine dedizierte Audioverbindung ohne Einflüsse von weiteren Konferenzteilnehmer:innen als sinnvoll erwiesen hatte.
In der Detailumsetzung zeigten sich dann, wie bei Software-Projekten üblich, die Probleme. Für den flüssigen Ablauf der Veranstaltung mussten nun doch relativ viele Funktionen neben den eigentlichen Abstimmungen integriert werden: eine Verknüpfung von Anträgen im Antragsgrün mit Abstimmungen, das Einreichen von GO-Anträgen, das Anmelden spontaner Redebeiträge, die Verwaltung von Einbringungsreden und Gegenreden. Zudem sollen Delegierte ihre Stimmberechtigung an die jeweiligen Ersatz-Delegierten sehr schnell temporär abtreten können, ohne dass diese parallel von beiden in Anspruch genommen werden kann. Gleichzeitig musste das Präsidium und die Veranstaltungsleitung schnell über Änderungen informiert werden können. Die mit den vielen Funktionen eingeführte Komplexität machte es auch nötig, ein Support-System für Delegierte und Mitglieder zu integrieren, so dass diese bei technischen Schwierigkeiten schnelle Hilfe erhalten können. Dabei fiel die Wahl auf das moderne Ticketsystem Zammad, welches die Integration eines Support-Chats ermöglicht und von der Netzbegrünung ebenfalls seit Jahren genutzt wird.
Letzte Tests in Bayern und NRW vor der #dbdk20
Ende Oktober waren die meisten Komponenten integriert, und auf dem Weg zur BDK fanden diverse kleinere Veranstaltungen statt, die Zwischenstände der Entwicklung erprobten. Auf der Landesdelegiertenkonferenz der Grünen Bayern wurde das System mit fast fertigem Funktionsumfang zum ersten Mal getestet, wobei während der Veranstaltung noch diverse kleinere und größere Probleme behoben wurden. Am darauffolgenden Tag fand in NRW der Landesparteirat statt, auf dem das Portal dann tatsächlich technisch weitgehend reibungsfrei funktionierte. Allerdings zeigten sich noch einige Schwächen im organisatorischen Ablauf. Ein Teil der Probleme wurde in den nur noch zwei verbleibenden Wochen behoben und weitere kleinere Funktionen hinzugefügt.
Am Dienstag vor der BDK reiste das Team der verdigado und Netzbegrünung nach Berlin, um den produktiven Einsatz vorzubereiten. Wir bezogen die Lounge des Tempodroms, Abseits der großen Halle, um ungestört arbeiten zu können und um in Notfällen einen Rückzugsort zu haben. Vor Ort mussten einige Unwägbarkeiten beseitigt werden, welche erst am späten Mittwoch Abend weiteres Arbeiten an der Plattform ermöglichten. Insbesondere war eine stabile Internetverbindung den gesamten Mittwoch ein Problem, und erst ein VPN-Tunnel durch die Firewall der Veranstaltungs-Internetverbindung ermöglichte wieder ein normales Arbeiten (1) und Jitsi-Zuschaltungen. Der Mobilfunkempfang war in der Lounge auch zu schlecht, um damit arbeiten zu können. Der Donnerstag und Freitag verflogen dann mit viel Mate sehr schnell mit dem Aufbau der Technik, den finalen Vorbereitungen und Last-Tests, so dass wir am Freitag Nachmittag vorsichtig optimistisch waren, dass alles funktionieren würde.
Zwischen 16 und 17 Uhr sollten die Delegierten die Gelegenheit bekommen, sich mit dem Portal vertraut zu machen, ab 17 Uhr sollte dann offiziell die BDK starten. Kurz vor 16 Uhr kam der Portal-Server dann unerwartet jedoch dennoch an sein Limit, und zunächst konnten wir die Probleme nicht richtig lokalisieren. Nach ein paar verzweifelten Neustarts, konnten wir den Fehler gegen 16:05 beheben, und der Portal-Server funktionierte das restliche Wochenende weitgehend reibungsfrei. (2) Gegen 16:20 stellte sich heraus, dass die Hardware des Rocket.Chat-Servers den Herausforderungen nicht gewachsen sein würde, weswegen wir ihn kurzfristig für 20 Minuten offline nahmen, um ihn auf eine leistungsfähigere Hardware zu verschieben. Gegen 16:40 war der Chat wieder verfügbar – für ungefähr 15 Minuten. Kurz vor 17 Uhr kamen dann immer mehr Parteimitglieder auf die Plattform, was zu einer erneuten Überlastung des Rocket.Chat führte. (2)
Server fit machen für Tag 2
Auch das Abstimmungsgrün, welches als Back-End-System fungierte, hatte zu Beginn immer wieder Aussetzer. Die reale Last schien sich von den idealisierten Tests doch in größerem Umfang zu unterscheiden, so dass über mehrere Stunden hinweg kontinuierlich die Systeme optimiert wurden. (3) Ab ungefähr 19 Uhr liefen die Systeme wieder weitgehend stabil, bis zum Ende des Programms am Freitag Abend, die Antwortzeiten waren für einige Nutzer:innen dennoch zu groß. In Konsequenz wurde am späten Abend beschlossen, die komplette Server-Struktur noch einmal zu ändern. Diese Arbeiten waren dann gegen 3 Uhr am frühen Samstag Morgen abgeschlossen. (4) Am Samstag Vormittag musste allerdings unter Hochdruck noch einmal das interne Netzwerk zwischen verschiedenen Server-Instanzen umkonfiguriert werden, was vor Start des BDK-Programms zu einer Nicht-Verfügbarkeit des Abstimmungssystems von gut einer Stunde führte. Nach Umbau des Netzwerks wurden noch weitere 3 Server hinzugefügt, so dass nun insgesamt 12 virtuelle Server für das Abstimmungsgrün zur Verfügung standen. Die Arbeiten der Nacht und des Vormittags zahlten sich aus: Ab diesem Zeitpunkt liefen alle Abstimmungen wesentlich schneller als am Freitag Abend.
Über den Samstag hinweg liefen die Systeme, abgesehen von kleineren Bugs bei der Benutzung, problemfrei. Zu diesem Zeitpunkt war ein übermüdeter Teil des Admin-Teams bereits ins Hotel zurück gegangen, um Schlaf nachzuholen. Die verbleibenden Kollegen sehnten sich das Ende des Programms für diesen Tag herbei, um auch etwas Schlaf zu bekommen. Exakt um 22:59 Uhr zeigte das Monitoring allerdings ein Bild, das bei allen noch im Raum Anwesenden den Herzschlag augenblicklich in die Höhe schießen lies:
Innerhalb nur einer halben Minute war die Last aller Abstimmungsgrün-Systeme quasi auf Null eingebrochen. Nach 2 Minuten wurden alle Personen reaktiviert, die bereits im Hotel waren. Unter Hochdruck wurde nach der Ursache gesucht, und nach 10 Minuten war sie gefunden: ein gelöschter Antrag aus dem Antragsgrün war ein Szenario, welches so nicht berücksichtigt war. Um das Antragsgrün zu entlasten, wurden alle Anträge von den BDK-Servern zwischengespeichert: Nun fragten alle BDK Server gleichzeitig bei dem Antragsgrün nach einer aktualisierten Version eines Antrags, der nicht mehr existierte. Nach weiteren 20 Minuten waren die Zwischenspeicher gelöscht, und das System wurde für einen Neustart konfiguriert, nach gut 40 Minuten liefen die Systeme wieder normal. (5) Bis 1 Uhr wurden dann noch weitere Patches erstellt und eingespielt, die ähnliche Fehler verhindern sollten.
Wenig Schlaf, wachsende Datenmengen und ruhiger Sonntag
Der Sonntag verlief dann ohne äußerliche Probleme. Aufgrund der immer weiter wachsenden Datenmengen, die im System verwaltet wurden, wurden allerdings noch weitere fünf Server dem System hinzugefügt. (6)
Trotz vieler aufgetretener Probleme sind wir dennoch mit dem Verlauf der ersten digitalen Bundesdelegiertenkonferenz zufrieden. Wir konnten unseren Beitrag leisten, dass die Grünen ihr neues Grundsatzprogramm nicht nur erfolgreich diskutieren, sondern auch abstimmen konnten. Dabei lief die komplette Infrastruktur auf eigener Hardware oder zumindest in deutschen Rechenzentren. Die eingesetzt Software ist fast vollständig Open Source. Der kurze Entwicklungszeitraum war allerdings ein Problem, das wir hoffentlich in Zukunft so nicht wiederholt sehen. Weitaus mehr Zeit hätte in die Optimierung von Performance und Stabilitätstest fließen müssen, um einen noch reibungsloseren Ablauf zu gewährleisten.
1) Da die BDK nur 3 Wochen vor Start von Karlsruhe nach Berlin verlegt wurde, war am Veranstaltungsort nur eine Internetverbindung durch eine Kaskade dreier IPv4-NAT-Gateways ohne IPv6 verfügbar. Zunächst musste eine Glasfasern vom Hausanschluss in den festgelegten Technik-Raum verlegt werden, was mehrere Stunden in Anspruch nahm. In dieser Zeit arbeitete ein Teil des Teams mit mobilen Hotspots weiter. Nachdem die Glasfaser angeschlossen war, stellte sich allerdings heraus, dass eine übereifrige Deep-Packet-Inspection-Firewall TLSv1.3-Verbindungen sang- und klanglos unterband, und diverse Ports blockiert waren, darunter Port 10000 UDP. Da ein Teil der Netzbegrünungs- und verdigado-Infrastruktur inzwischen kein IPv4 mehr spricht, mussten mehrfach SSH Jump-Hosts eingesetzt werden. Das größte Problem stellte jedoch dar, dass eine reibungslose Nutzung der Jitsi-Konferenzlösung durch diese Firewall nicht gegeben war. Um dieses Problem zu umgehen, versuchten wir zunächst einen Wireguard-VPN-Tunnel aufzubauen, erfolgreich war jedoch erst im zweiten Versuch ein OpenVPN, womit wir jedoch einige Kompromisse bei der zur Verfügung stehenden Bandbreite eingehen mussten, bzw. individuelle Gegenstellen um den Tunnel herum-routeten. Für die Konfiguration von IPv6 via VPN-Tunnel verblieb leider keine Zeit mehr. Lesson Learned: Die Netzwerk-Situation müssen wir bereits vor Ankunft zuverlässig im Blick haben. Wir denken über Router nach, die wir bereits im Vorfeld zu den Veranstaltungs-Locationen schicken könnten, sowie LTE- oder 5G-Lösungen, die wir insbesondere auf Landesparteitagen bereits häufiger zum Einsatz gebracht haben, von vornherein auch hinsichtlich notwendiger Kabelwege mit einzuplanen.
2) Lesson learned: Open File Limits, Open File Limits und Open File Limits, sowohl für die einzelnen Prozesse, als auch global. Auf dem Rocket.Chat Server laufen 6 Rocket.Chat-Prozesse und eine MongoDB. Insbesondere beim MongoDB mussten die Open File Limits massiv angehoben werden. Und damit auch die Limits des gesamten Systems. In der Spitze waren dann über 1500 User gleichzeitig online. Das scheint die Obergrenze zu sein, ohne die MongoDB und die Rocket.Chat Prozesse über mehrere Server zu verteilen.
3) Die Anzahl der parallelen PHP-FPM Prozesse, PHP memory Leaks, MariaDB-Verbindungs-Limits, und Nginx Open File Limits mussten angepasst werden. Insbesondere PHP Memory Leaks waren anfangs ein riesiges Problem, bis die Anzahl der maximalen Verbindungen pro Prozess auf 100 begrenzt wurde.
4) Die ursprüngliche Konfiguration bestand aus 3 Nginx Servern, die auch jeweils lokale PHP-FPM-Server beinhalteten, 3 zusätzlichen remote PHP-FPM Servern, einem MariaDB Master für Writes und 3 MariaDB Slaves für Reads. Dazu gab es einen single threaded Redis Server. Dieses Setup war nicht besonders effizient, insbesondere der interne Netzwerk-Traffic der SQL Reads und der einzelne Redis Prozess waren enge Bottlenecks. Das Fazit war: keine Remote PHP-FPM Prozesse. In der Nacht bekamen alle Server jeweils einen eigenen Nginx, mit nur PHP-FPM über lokalen Socket und einen lokalen MariaDB Slave. Die Write Prozesse waren so wenige, dass die interne Netzwerk-Kommunikation von jeweils über einem Gbits zwischen allen Nodes (remote PHP-FPM + MariaDB reads) anschließend auf 500 Mbits zum Redis Server gesenkt wurde.
5) Lesson learned: Mate ist keine Lösung (für alles). Mehrere Personal-Schichten für den Betrieb von komplexen Systemen über einen langen Tag sind sinnvoll. Das System hätte bereits nach gut 10 bis 15 Minuten wieder laufen können, wären genügend Personen vor Ort und ausgeruht gewesen. Auch ohne Müdigkeit ist eine solche Situation extrem belastend und es passieren schnell Fehler. Mit nicht ausgeruhtem Personal steigt die Fehlerrate entsprechend. Es war auch hilfreich, in einem eigenen Raum zu sein, und vom Trubel außen herum nichts mitzubekommen. Das ermöglicht ein konzentrierteres Arbeiten. Außerdem: Grafana auf großen Bildschirmen sieht nicht nur toll aus. Man erkennt Probleme tatsächlich sehr schnell.
6) Natürlich gibt es keine Cloud. Aber manchmal ist es praktisch, die Rechner Anderer spontan nutzen zu können.
