Christian Nölle ist Abteilungsleiter im ZIM an der Uni Wuppertal und verantwortlich für die Bereiche Anwendungen, E-Learning, Qualifizierung und Support.
Ab sofort steht die Möglichkeit zur Verfügung in Zoom Dolmetscher*innen einzubinden und Veranstaltungen oder Tagungen simultan übersetzen zu lassen.
Teilnehmer können so zwischen verschiedenen Audiokanälen wählen und sich so die Übersetzung einer oder mehrerer Sprachen anhören. Dabei hören sie die Orginalsprache entweder leiser oder können diese ganz ausblenden.
Hosts müssen dazu die Verdolmetschung bei der Planung des Meetings aktivieren und zu Beginn der Konferenz starten und die Dolmetscher*innen entsprechend den Sprachen zuweisen.
Wir haben im Mai 2020 erneut alle unsere Nutzerinnen und Nutzer aufgerufen, per Online-Umfrage ihre Meinung zu unseren Angeboten zu sagen.
Wir wollen die von uns angebotenen Dienste und die Servicequalität evaluieren und verbessern. Unser Ziel ist, die IT-Infrastruktur der Universität möglichst an ihre Bedürfnisse in Studium und Lehre anzupassen.
Insgesamt haben 292 Personen an der diesjährigen Umfrage teilgenommen, was gegenüber 234 Teilnehmenden im Jahr 2019 eine erfreuliche Steigerung darstellt.
Auf unsere Frage nach der generellen Zufriedenheit mit dem ZIM haben 93% geantwortet, dass sie sehr oder eher zufrieden sind. Vielen Dank dafür!
Da stand ich gerade vor dem Problem, dass ich eine relativ komplexe Beschaffung nach einem bestimmten Produkt und dessen Lieferanten durchsuchen wollte. Jetzt umfasst dieser Beschaffungsantrag aber nicht einen Auftrag, sondern rund 18 Einzelaufträge an die verschiedensten Firmen. Versuche mit der Windows Suche schlugen fehl, diese indexiert wohl keine PDF inhaltlich – oder zumindest bei mir tut sie das nicht. Aber siehe da, der Acrobat Reader kann das:
Mit der Tastenkombination [Strg] + [Shift] + [F] ruft man die Suchmaske auf
Auswahl von “Alle PDF-Dokuemnte in”
Ordner oder Pfad mit den PDFs auswählen
Suchwort eingeben und ggfs. Optionen entsprechend setzen.
Bisher hatten Nutzer*innen der Webkonferenzsoftware Zoom nur die Möglichkeit, den Zutritt zu Ihrer Konferenz, Veranstaltung oder Besprechung auf “angemeldete Nutzer*innen” zu beschränken. Dies ermöglicht aber nur eine geringe Kontrolle, welcher Personenkreis den nun tatsächlich da im Warteraum auftaucht. Ein Zoom-Konto ist schnell erstellt und das Scriptkiddie aus dem Kinderzimmer oder der Zoombomber aus einer Trollfabrik kann das auch.
Aus diesem Grund haben wir uns das Feature mal genauer angesehen und festgestellt, dass wir das sehr wohl auch auf unsere Organisation einschränken können.
Mein Kollege Joachim hat ja schon einen oder zwei erste Einblicke in die Arbeiten am Videoportal der Bergischen Universität gegeben. Ich würde mit euch nun gerne einen Blick unter die Motorhaube werfen und zeigen, dass das, was wir am Vergaser (IIS) nicht einstellen konnten, einfach durch einen ordentlichen Turbo (varnish) wieder wettgemacht haben. 😉 Nun aber genug der Autobilder, starten wir mal…
Der Aufbau des Videoportals der Uni Wuppertal ist nicht so ganz trivial, hier sind eine Menge Server im Spiel, welche miteinander interagieren und sich gegenseitig beeinflussen. Folgend daher nur die schematische Darstellung der für die Auslieferung wichtigen Server. Nur diese sind für uns relevant, schließlich ist ja hier der Flaschenhals zu erwarten.
Das Setup des Videoportals schematisch vereinfacht
Bei jedem Aufruf eines Videos werden die Elemente, die die Webseite des Videoportals ausmachen, von den beiden Webservern ausgeliefert. Die Fragmente der Videos, also das, worauf es ankommt, werden durch die Videoserver und einen Loadbalancer an die User geschickt. Aber eben leider nicht an besonders viele gleichzeitig, relativ schnell kam das System ins Stolpern, das hätte den Anforderungen von Uni@Home in der Form nicht standgehalten.
Da musste also mehr Power rein und das ganze sollte dann auch redundanter werden. Wir haben aus diesem Grund Kontakt mit der Firma varnish AB gesucht, da wir das Hauptprodukt, den varnish cache, schon für unsere TYPO3 Server verwenden und damit sehr zufrieden sind. varnish AB hat uns dann sehr zeitnah und absolut unbürokratisch nach Auftrag einen Techniker zur Seite gestellt. Lucas hat dann unser Setup umgebaut und vor unsere Video- und Webserver des Videoportals eine redundante varnish pro Installation realisiert.
Schematische Darstellung des varnish Video Streaming und VoD Setups
Die Architektur basiert auf einem 1-tier Aufbau mit zwei varnish Servern, die so konfiguriert sind sowohl die Web- als auch MediaSite Server zu erreichen. Das Setup ist in der Lage, die beiden Varnish Instanzen in einer aktiven/aktiven Konfiguration vorzuhalten. In normalen Situationen ist varnish01 für den Webseiteninhalt zuständig und varnish02 wird für das Streaming bzw. die Video on Demand Auslieferung verwendet. In Ausfallsituationen ist jede Instanz in der Lage mit den anderen Inhalten (Web und Video) umzugehen.
Die dahinterliegende Konfigurationsdatei in VCL (Varnish Configuration Language) für die beiden Server ist ziemlich schlank gehalten und konzentriert sich auf das Caching der Videofragmente. Die Webseite des Videoportals wird hierbei kaum zwischengespeichert, hier handelt es sich hauptsächlich um statische HTML und CSS Dateien, welche auch von einem IIS schnell ausgeliefert werden können. 😉 Die Videofragmente jedoch sind gut zu cachen und werden durch die beiden Server für drei Tage zwischengespeichert.
//#dont cache manifests
if (bereq.url ~ ".mpd|.m3u8|manifest") {
set beresp.uncacheable = true;
} else {
//#cache video fragments for max 3 days
set beresp.ttl = 3d;
}
Wichtig ist, die manifest Dateien nicht zu cachen, daher werden diese auf uncacheable gesetzt.
Weiterhin verlassen wir uns auf die “Probe”-Funktionalität von varnish. Damit können wir feststellen, ob die entsprechenden Mediasite-Server (Web und Video) denn überhaupt betriebsbereit sind oder ob varnish diese erstmal als “krank” markiert und nicht mehr darauf zugreift.
Für die Streamingserver lassen wir varnish ein sehr kleines .mp4 Video anfragen ;), die Webserver (siehe unten) werden auf die funktionierende API geprüft.
Interessant ist sicherlich auch noch die Skalierung der Maschinen, wir verwenden hier je Maschine einen RAM Cache in der Größe von ca. 112 GB, insgesamt verfügen die beiden Server jeweils über 128 GB Arbeitsspeicher. Varnish arbeitet hier mit dem brandneuen Memory Govenor in Verbindung mit der Massive Storage Engine.
Die o.a. Parameter im Startaufruf von varnish in Verbindung mit folgenden Zeilen in der mse.conf
env: {
id = "myenv";
memcache_size = "auto";
};
sorgen dafür, dass varnish im Rahmen des memory_targets seinen Bedarf selbstständig an die Begebenheiten anpassen kann.
Alles in allem ein einfaches wie bestechendes Setup, welches wir ohne die tatkräftige Hilfe der Mitarbeiter*innen bei varnish AB sicherlich nicht in der Kürze der Zeit so elegant realisiert bekommen hätten. Also Charlotte, Lucas und Jonatan: You rock! Danke!
