MLUconf basiert auf dem Open-Source-System Big Blue Button, das wiederum nicht erst seit gestern existiert und weit über Halle hinaus genutzt wird. Warum ist dafür ein Lasttest an der MLU überhaupt nötig, warum jetzt? Gibt es nicht andere „Baustellen“?
Ulrich Klaus: Wir arbeiten durchaus auf verschiedenen Baustellen, die WLAN-Verfügbarkeit wird ausgebaut, die Studierenden-Postfächer sollen vergrößert werden. Wir wissen aber auch, wie wichtig es ist, die Stabilität eines Dienstes einzuschätzen – in Bezug auf MLUconf gerade jetzt vor Beginn des neuen Semesters. Was das Konferenzsystem selbst betrifft: Zum einen befindet sich die Software in einer intensiven Entwicklungsphase, zum anderen findet die ausgedehnte Nutzung erst seit relativ kurzer Zeit statt, seit dem Beginn der Corona-Pandemie. Die Informationen zu den Lastgrenzen sind spärlich und auch widersprüchlich. Natürlich stehen wir mit anderen Universitäten im Kontakt und kennen deren Erfahrungen, aber auch das hilft uns nicht weiter, weil die Randbedingungen andere sind. Viele Akteure greifen bei größeren Veranstaltungen zudem doch auf kommerzielle Systeme zurück. Bisherige Erfahrungen mit Big Blue Button gehen bis zu einer Nutzung durch 400 Teilnehmende gleichzeitig, wir sind der Meinung, dass unsere Maschinen mehr aushalten.

Aber müssen Sie das auch? Das Rektorat hat gerade entschieden, dass das kommende Semester ein Hybridsemester wird, in dem es auch Präsenzveranstaltungen gibt. Sollte nach dem Onlinesemester da nicht die Belastung für die IT sinken?
Nein, für die IT-Systeme wird es erheblich anstrengender. Im Sommersemester wurden Lehrveranstaltungen einzeln aufgezeichnet, als „Konserven“ bereitgestellt und von Studierenden zeitlich entzerrt heruntergeladen. Jetzt wird es parallel stattfindende Veranstaltungen geben, die gleichzeitig live gestreamt werden – das gab es vorher nur bei kleineren Lehrangeboten. Der Leistungsbedarf ist damit deutlich höher und wir brauchen Daten, die uns zeigen, ob wir uns in sicherem Fahrwasser befinden. Im Ergebnis wollen wir sagen können, mit wie vielen Teilnehmenden maximal eine Lehrveranstaltung oder auch eine Konferenz möglich ist – 1.000 wäre ein Meilenstein – und wie viele Teilnehmende pro Server denkbar sind.

Wie soll der Lasttest konkret aussehen?
Am 6. Oktober wird es ab 14.30 Uhr zehn parallele Videokonferenzen mit 15- bis 20-minütigen Vorträgen und Mini-Workshops für jeweils bis zu 150 Interessierte geben. Dafür konnten wir zum Beispiel das Puppentheater Halle, das Zentrum für Lehrerbildung, das Unisportzentrum oder den Transfer- und Gründerservice gewinnen. Der Chemiker Prof. Dr. René Csuk wird seine bei der Langen Nacht der Wissenschaften sehr beliebte Experimentalvorlesung halten – diesmal unter dem Titel „Wenn’s weder stinkt noch kracht: chemische Experimente digital“, beim Studentenwerk geht es um Auslandsbafög. Genauere Infos werden wir noch über Stud.IP bereitstellen. Der eigentliche Lasttest steht am Ende an: Dann werden die Teilnehmerinnen und Teilnehmer zeitlich gestaffelt gebeten, einem gemeinsamen Konferenzraum auf einem isolierten Server beizutreten. Mit Bordmitteln der Software und unserem zentralen Monitoringsystem werden dabei die Leistungsdaten unserer Server gemessen.

Sie haben von einem Meilenstein von 1.000 Nutzerinnen und Nutzern gesprochen. Was passiert, wenn es nicht so viele werden oder sie sich ungleich auf die einzelnen Konferenzen im Vorfeld verteilen?
Im Sommersemester haben wir Veranstaltungen mit 160 bis 170 Teilnehmenden gesehen. Alles, was über dieser Zahl liegt, hilft uns auch. Wirklich sinnvoll wird die Auswertung ab 500 Menschen. Ich bin da aber guten Mutes. Zum einen stehen sowohl Unterhaltsames als auch handfeste Infos auf dem Programm, zum anderen macht es Studierenden vielleicht auch Spaß, ein IT-System an den Rand der Katastrophe zu bringen. Wenn es 1.500 Teilnehmende werden, bin ich sicher, dass die Lastgrenze erreicht ist und im großen Konferenzraum das Licht ausgeht. Auch das wäre eine spannende Erfahrung. Damit das nicht vorher schon bei einem der Vorträge passiert, werden diese tatsächlich auf 150 Teilnehmende begrenzt.

Stichwort Katastrophe – wenn die Server in die Knie gehen, welche Dienste und Services der Uni werden mitgerissen? Oder anderes gefragt: Legen Sie die gesamte IT der Uni lahm?
Nichts wäre fataler als den Produktivbetrieb der Uni zu gefährden. Wir haben das Glück, über eine größere Zahl an Servern zu verfügen, die auch noch gleich beschaffen sind – die werden für den Test geteilt in einen Part für den Produktivbetrieb und einen zweiten von vier bis fünf Servern, der „kaputtgehen darf“. Die Mailsysteme zum Beispiel werden nicht beeinflusst sein, der limitierende Faktor bei dem Lasttest ist die Rechenleistung der Server, nicht das Netzwerk. Durch die Abkopplung der Server schließe ich auch eine Beeinträchtigung zeitgleich stattfindender anderer Konferenzen aus.

Zum Schluss: Verraten Sie doch noch, warum man das Ganze nicht weit weniger personalaufwändig mit Bots testen kann.
Bots liefern nicht das gleiche Ergebnis wie menschliche Teilnehmende. Deren vielfältiges Verhalten während einer Konferenz lässt sich nicht so einfach nachstellen – die einen chatten nebenbei, andere geben Kamera beziehungsweise Mikro frei oder auch nicht, manche sitzen zu Hause im WLAN, andere auf dem Campus. Ein Ergebnis mit Bots wäre damit für uns nicht genügend belastbar. Außerdem: Wenn man den Test charmant gestaltet, hat er vielleicht einen zusätzlichen Werbeeffekt für MLUconf, das noch nicht jeder kennt.