Lockdown oder: Wie ich lernte, die Cloud zu lieben
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Cloud
Lockdown oder: Wie ich lernte,
die Cloud zu lieben – Teil 2
Dr. Jörg Domaschka, Institut für Organisation und Management von Informationssystemen
Steffen Moser, School of Advanced Professional Studies (SAPS)
Thomas Nau, Kommunikations- und Informationszentrum (kiz)
Simon Volpert, Institut für Organisation und Management von Informationssystemen
Alle Autoren arbeiten an der Universität Ulm.
Die COVID-19-Pandemie hat im vergangenen Jahr oft schmerzhaft gezeigt, wie grundlegend wichtig eine
stabile, durchgehende, sichere und zeitgemäße Versorgung mit IT-Services im täglichen Leben ist. Auch
die Hochschulen bilden hier keine Ausnahme. Dabei spielt „die Cloud“, obwohl schon lange als nächs-
ter Schritt der IT-Evolution gehandelt, in diesem Bereich oft nach wie vor nur eine Nebenrolle. Dies ist
aus mehreren Gründen verständlich: Zum einen existieren vielfältige unterschiedliche Definitionen und
Ansichten über das, was eine Cloud ist beziehungsweise ausmacht. Zum anderen ist die IT oft sehr eng mit
lokalen Prozessen und Anforderungen verwoben, die eine On-Premises-Lösung – das scheinbare Gegen-
teil einer Cloud – geradezu erzwingen.
Dieser Artikel fasst die Geschehnisse in den Wochen vor und nach der Anordnung des Lockdowns an der
Universität Ulm im März 2020 zusammen. Ziel ist es, den Lesern die insbesondere technischen Vorausset-
zungen und Entscheidungen aufzuzeigen, die es letztendlich erlaubt haben, die Arbeitsfähigkeit von Lehre,
Verwaltung und Forschung an der Universität Ulm in sehr hohem Maße zu gewährleisten. Dieser Artikel
zeigt das Spannungsfeld auf und fasst die Entstehungsgeschichte unserer Cloud-Lösung für unser Video-
konferenzsystem sowie die gemachten Erfahrungen in der Hoffnung zusammen, anderen als Anregung für
eigene interne Diskussionen zu dienen.
64 www.aoug.at • www.doag.org • www.soug.ch
Teil 2: Konzeption und rio. Neben Eigenentwicklungen des BBB- ver eine harte Grenze für die maximale
Umsetzung Teams kommen hier auch andere Open- Größe eines Meetings. Um diese Grenze
Source-Komponenten zum Einsatz wie zu erhöhen, kann eine BBB-Installation
Der erste Teil der Serie (siehe Heft 03/2021) FreeSWITCH zur VoIP-Telekommunikati- nur klassisch vertikal, also durch Vergrö-
fokussierte sich auf die Darstellung der onslösung und Kurento als Medienserver. ßern des Servers, skaliert werden. Aber
organisatorischen und technischen Hin- auch hier sind der Skalierbarkeit Grenzen
tergründe und stellte die Video-Konfe- gesetzt: Zwar profitieren sowohl Free-
renz-Software BBB vor. Der vorliegen- Skalierbarkeit von BBB SWITCH als auch Kurento inzwischen in
de zweite Teil nimmt eine technischere hohem Maße von einer parallelen Ar-
Sichtweise ein und konzentriert sich auf Die verteilte Architektur von BBB er- chitektur, jedoch stellt in der derzeitigen
betriebliche Aspekte von BBB, seine Ska- laubt es prinzipiell, die Komponenten ei- stabilen Version von BBB nodejs einen
lierung und die Automatisierung des Be- ner BBB-Installation auf mehrere Server Flaschenhals dar, da es nur einen Re-
triebes. Der anschließend folgende Teil 3 zu verteilen. Dieses Vorgehen ist jedoch chenkern ausnutzen kann.
beschäftigt sich dann mit dem Konfigura- nicht dokumentiert und entsprechend Eine horizontale Skalierung ist inso-
tions-Management. wird von einem solchen Betriebsmodus fern möglich, als dass durch Hinzunah-
abgeraten. Stattdessen wird sowohl von me weiterer Server eine größere Zahl an
den Entwicklern als auch von der Com- Meetings unterstützt werden kann. Die
Überblick munity empfohlen, das Ubuntu-basier- maximale Größe einzelner Meetings ist
te BBB-Installationsskript zu verwenden, jedoch nach wie vor durch die Größe der
Wie in Teil 1 detailliert dargestellt, han- das dafür Sorge trägt, alle Module auf ei- Server begrenzt, da ein Meeting nicht
delt es sich bei BigBlueButton (BBB) um nen Server zu installieren und miteinan- über mehrere Server verteilt werden
eine Client-/Server-basierte Videokonfe- der zu verbinden. kann. Eine horizontale Skalierung lässt
renz-Software. Typischerweise ist BBB als Das Skript setzt Ubuntu 16.04 voraus sich am einfachsten durch die Verwen-
On-Premises-Lösung gedacht, die von der und installiert die als Ubuntu-Pakete be- dung des Scalelite-Load-Balancers rea-
nutzenden Einrichtung selbst auf einer reitgestellten BBB-Komponenten sowie lisieren (siehe Abbildung 1). Hier werden
Server-Infrastruktur gehostet wird. Archi- externe Pakete wie nodejs, Redis, Mon- neben dem Load-Balancer mehrere un-
tektonisch besteht BBB aus einem Server- goDB, aber auch FreeSWITCH und Kuren- abhängige BBB-Instanzen betrieben, wo-
Teil und einem Client, wobei Letzterer seit to. Durch die vielen gegenseitigen Abhän- bei der Load-Balancer bei jedem neu zu
Version 2.2.0 (erschienen im November gigkeiten der Module ist eine Migration startenden Meeting einen der BBB-Server
2019) in einem HTML5-fähigen Webbrow- auf andere Distributionen als Ubuntu, auswählt. In der Standard-Konfiguration
ser abläuft. Entsprechend werden auf Sei- oder sogar auf eine modernere Version erfolgt diese Auswahl basierend auf der
ten der Nutzer weder Plug-ins noch Brow- als die offiziell unterstützte 16.04, als sehr Anzahl der derzeit laufenden Meetings
ser-Extensions benötigt. schwierig einzustufen. sowie der aktiven Audio- und Videoströ-
Beim Server-Teil von BBB handelt es Auf Grund des Single-Server-Setups me. Die jeweiligen Statistiken erfragt der
sich um einen Verbund aus einer Vielzahl begrenzt die Kapazität des (physischen) Load-Balancer periodisch von den Ins-
von Modulen für die unterschiedlichen Servers die Leistungsfähigkeit der BBB- tanzen. So ermittelt er nicht nur deren
Aufgaben in einem Videokonferenzszena- Installation. Insbesondere setzt der Ser- Last, sondern kann auch feststellen, ob
Abbildung 1: Skalierte BBB-Installation mit Scalelite (Quelle: Thomas Nau)
Red Stack Magazin 04/2021 65
Cloud
BBB-Instanzen ausgefallen – im Sinne von blöcken und Tools, die sich bereits in der binare und Sprechstunden mit wenigen
nicht erreichbar – sind, und diese als Ziel Vergangenheit bewährt haben. Hierzu kleinen Übungsstunden von jeweils ca.
ausschließen. zählen der Verzicht auf die grafische GUI 5-25 Studierenden, die die Infrastruktur
der bwCloud, die Versionierung von Soft- bewältigen musste. Diese Last war pro-
ware-Artefakten mithilfe von Containern blemlos mit einer virtuellen Maschine (6
Releases und Release und der Einsatz eines Container-Orchest- vCores, 16 GB RAM) auf Grundlage eines
Management rierers zum Ausbringen von versionierten Oracle-Solaris-11.4-Servers zu stemmen.
Software-Artefakten und deren ebenfalls Hostübergreifende Parallelisierung war
Die Komponenten von BBB werden in versionierter Konfiguration. hier also nicht relevant.
Form mehrerer .deb-Pakete für Ubun- Zum Betrieb von BBB sind somit die Uns war klar, dass wir für den Betrieb
tu 16.04 herausgegeben. Ein Release von folgenden Schritte notwendig während des Semesters deutlich mehr
BBB wird also durch eine Komposition ver- Ressourcen benötigen würden. Deren
schiedener Versionen von .deb-Paketda- 1. Containerisierung von BBB, insbeson- Menge und Ausprägung war jedoch noch
teien definiert. Ein installiertes Release gilt dere unbekannt. Ebenso war klar, dass wir
nur dann als konsistent und korrekt instal- a. Containerisierung einer BBB-Single- während des Semesters Verbesserungen
liert, wenn alle .deb-Files auf die richtige Node-Instanz und Patches einspielen werden müss-
Version gebracht werden. Spielraum für b. Containerisierung und damit Versi- ten, da keine Zeit bestand, das System
Administratoren, nur Teilkomponenten zu onierung der BBB-Konfiguration im Vorfeld ausreichend zu testen und
aktualisieren, ist nicht vorgesehen. 2. Beschreibung eines BBB-Systems für zu härten. Eine Beschaffung von neuer
Mit dem operativen Alltag schwierig in einen Orchestrierer bestehend aus Hardware stand wegen der kurzen Zeit-
Einklang zu bringen ist das Release-Ma- a. Scalelite und Scalelite-Konfiguration spanne außer Frage und machte die Nut-
nagement von BBB. Bedingt durch die b. BBB-Container und BBB-Konfigura- zung einer Cloud-Infrastruktur zur nahe-
Pandemielage explodierte die Zahl der tion liegenden Alternative.
Nutzer in kürzester Zeit und damit auch c. Monitoring Unter anderem wegen der Echtzeit-An-
die Zahl der Feature-Wünsche und Pull- 3. Automatisierte Bereitstellung von vir- forderungen von BBB stand die Verwen-
Requests, die an die Entwickler gerichtet tuellen Maschinen und Orchestrierer. dung einer Public Cloud nicht zur Debatte,
wurden. Dies führte dazu, dass eine große da wir durch den europaweiten Lockdown
Zahl benötigter Merkmale, die ursprüng- Ein besonderer Fokus lag hierbei darin, mit einer erhöhten Last und damit erhöh-
lich für die kommende Version 2.3 geplant alle Schritte weitestgehend zu automa- ten Interferenz auf diesen Services rech-
waren, in Version 2.2 zurückportiert wur- tisieren und möglichst keine veränderli- neten. Stattdessen konnten wir auf die
den. Zwischenzeitlich wurde sogar die Pro- chen Elemente zu erlauben. So können regionale bwCloud am Standort Ulm aus-
duktivversion 2.2.x zum Hauptentwick- unter anderem schnelle Deployment-Ite- weichen [1]. Dies ermöglichte es uns unter
lungszweig, wodurch sich die Freigabe von rationen und eine angemessene Wartbar- anderem, ein besonderes Scheduling von
Version 2.3 deutlich verzögerte. keit erreicht werden. BBB-VMs zu realisieren, sodass hier im-
Eine Trennung zwischen der Bereit- merhin nicht mit Interferenzen durch an-
stellung neuer Merkmale, dem Korrigie- dere Workloads zu rechnen war.
ren von Bugs und der Beseitigung von Von 0 auf 100 in 12 Tagen Nichtsdestotrotz musste eine Lösung
Sicherheitslücken fand demnach kaum gefunden werden, die es uns erlaubte
noch statt. Zu Beginn der Pandemielage Mit Beginn des Lockdows standen der Vi-
wurden teilweise bis zu fünf Minor-Relea- deo-Conferencing-Task-Force zwölf Kalen- • ein Flotte von damals geschätzten 20
ses pro Monat freigegeben, die aufgrund dertage zur Verfügung, um eine BBB-In- BBB-Servern zu betreiben (im Winter-
der enthaltenen Sicherheitskorrekturen stallation bereitzustellen, die in Stoßzeiten semester 2020 betrug die Zahl der ein-
zeitnah in das Produktivsystem zu über- von damals geschätzt 5.000 Studierenden gesetzten BBB-Server tatsächlich 30),
führen waren. gleichzeitig genutzt werden kann, die Nut- • in dieser Flotte zeitnah und im laufen-
Die Vermischung der Herausgabe von zungszeiten zwischen 05:00 Uhr morgens den Betrieb Software-Updates einzu-
neuen Features sowie Bug- und Sicher- und 23:00 Uhr nachts hat und deren Ausfall spielen und neue Versionen zu testen
heits-Fixes erschwerte den Betrieb enorm, und Störung massive Nutzerbeschwerden (Canary Releases),
da es einen reinen Wartungsbetrieb un- nach sich ziehen und entsprechend First- • fehlerhafte Updates problemlos zurück-
möglich machte. Die Änderungen inner- und Second-Level Support-Ressourcen von zurollen und fehlerhafte Konfiguratio-
halb von Minor-Releases waren teilweise anderen Diensten abziehen würde. nen auf die einfachste mögliche Art und
so signifikant, dass invasive Anpassungen Zu diesem Zeitpunkt war bereits durch Weise zu beheben, nämlich durch ein
der Konfiguration notwendig wurden. die SAPS Know-how im Betrieb von BBB Neu-Erstellen einer virtuellen Maschine.
vorhanden, anzumerken ist jedoch, dass
die Nutzung des Tools in der Weiterbil- Das Institut für Organisation und Manage-
Lösungskonzept dung aus Betreibersicht keine besondere ment von Informationssystemen (OMI)
Herausforderung an die technische Infra- der Universität Ulm hat diese Themen als
Kern unseres Umsetzungskonzeptes ist struktur stellte. So waren es bis Frühjahr Arbeitsschwerpunkte und seine Mitarbei-
die Wiederverwendung von Funktions- 2020 doch üblicherweise abendliche We- ter haben in den letzten Jahren praktisch
66 www.aoug.at • www.doag.org • www.soug.ch
anwendbare Konzepte entwickelt, um fahr des „Configuration Drift”, also des barkeit. Wir erreichen eine ausreichende
den Betrieb noch weit größerer Software- Vorgangs, durch manuelles Aktualisieren Wartbarkeit durch die Identifikation von
Cluster durch weitreichende Automatisie- und Patchen der Systeme Dokumentati- zustandsbehafteten Teilen des Gesamt-
rung stark zu vereinfachen [2]. Auf dieses on und Wirklichkeit schleichend inkonsis- systems. Dies wird Thema des dritten
Vorwissen und passende Software-Tools tent werden zu lassen. Teils der Artikel-Serie sein.
konnten wir zurückgreifen. Automatisierung wiederum ist essen-
ziell für die Skalierbarkeit des Systems.
Hauptaugenmerk ist im Falle von BBB Deployment
Anforderungen das Skalieren der „Worker Nodes”, in Ab-
bildung 2 als „BBB VM“ und „BBB Contai- Für das Deployment (Ausbringen) der An-
Um von Beginn an eine solide Lösung zu ner“ dargestellt. Meetings werden nach wendungen auf der Cloud ist eine Auto-
betreiben, standen für uns drei techni- bestimmten Regeln auf diese Nodes ver- matisierung auf zwei Ebenen nötig: Zum
sche Aspekte im Vordergrund: Reprodu- teilt (siehe Skalierbarkeit von BBB). Diese einen muss die Anwendungs-Spezifika-
zierbarkeit, Skalierbarkeit und Wartbar- Verteilung wird von der ebenfalls in Ab- tion samt Konfiguration auf die virtuellen
keit. Dieser Fokus bewährte sich bereits bildung 2 dargestellten „Scalelite“-Kom- Maschinen ausgebracht werden. Dies ge-
in der Vergangenheit und ermöglicht es, ponente umgesetzt. Sollten alle Nodes schieht in unserem Fall mithilfe eines Or-
flexibel und agil zu bleiben. Insbesonde- gesättigt sein, muss ein neuer Node zur chestrierers. Zum anderen müssen die be-
re das Aufrechterhalten der Flexibilität Verfügung gestellt werden, um den Be- nötigten virtuellen Maschinen gestartet,
war ein zentrales Ziel für dieses Projekt, trieb aufrecht erhalten zu können. In die- das dort verwendete Betriebssystem kon-
da sich Details in der Installation und sem Fall ist ein rechtzeitiges und zügiges figuriert und die VMs an den Orchestrierer
Konfiguration erst durch eine Wechsel- Vorgehen äußerst wichtig. Dieses Vorge- angebunden werden. Für beide Schritte
wirkung zwischen Betrieb und Nutzern hen ermöglicht zudem, das Potenzial der sind eine Vielzahl von Tools vorhanden.
herausstellen. Elastizität auszuschöpfen. Insbesondere
Reproduzierbarkeit nimmt eine Schlüs- wäre es denkbar, dynamisch Nodes bei
selrolle bei der Automatisierung ein. Ist geringerer Gesamtauslastung zu stoppen Virtuelle Maschinen mit
jeder Schritt ausgehend vom Deployment oder gar zu löschen. Dieses Vorgehen wur- Ansible
der ersten VM bis hin zur Konfiguration de für BBB allerdings nicht umgesetzt, weil
vollständig dokumentiert und jederzeit dem Mehraufwand kein entsprechender Aufgrund von positiven Erfahrungen in
reproduzierbar, stellt dies die Basis für Nutzen gegenüberstand. der Vergangenheit haben wir uns zur Au-
eine vollständige Automatisierung dar. Auch die Wartbarkeit steht in großem tomatisierung der Interaktion mit dem
Zudem reduziert dieses Vorgehen die Ge- Zusammenhang mit der Reproduzier- Cloud API für Ansible [3] entschieden.
Abbildung 2: Deployment-Ebenen inklusive Zugriffsablauf (Quelle: Thomas Nau)
Red Stack Magazin 04/2021 67Cloud
Abbildung 3: Schrittweises Deployment der BBB-Anwendung in bwCloud (Quelle: Thomas Nau)
Ansible ist niederschwellig, aber gleich- Auch hier steht eine Vielzahl von Tools tet das für unser Gesamtkonzept, dass
zeitig mächtig genug, um alle unsere An- zur Verfügung, von denen Kubernetes eine VM nicht gelöscht werden muss,
forderungen zu erfüllen. Zudem bietet es [4] sicherlich das derzeit Bekannteste ist. wenn sich ein Container ändert, da Ran-
Module für die Verwaltung von virtuellen Kubernetes hat jedoch Probleme bei der cher dafür Sorge trägt, die Änderungen
Maschinen in OpenStack (bwCloud). Unterstützung von WebRTC. Zudem hat- umzusetzen.
Eine vollständig auf Ansible basieren- ten wir zum damaligen Zeitpunkt keine Der einzige Container, der in diesem
de Lösung wäre zwar umsetzbar, ist in wesentliche Betriebserfahrung damit. Die Fall noch mittels Betriebssystem-Konfi-
der Praxis jedoch unkomfortabel. Ins- Wahl fiel entsprechend pragmatisch auf guration gestartet wird, ist ein Adapter-
besondere das Verwalten der Container Rancher [5] (v1.6), weil wir damit bereits Container, der einen „Rancher Agent“
(mehrere Hundert) über Konfigurations- deutlich mehr Betriebserfahrung in kriti- implementiert. Dieser meldet sich am
Dateien, deren Verbindung auf Netzwer- schen Bereichen hatten und Rancher eine „Rancher Master” an, der wiederum das
kebene ist mühsam, fehleranfällig und wesentlich geringere Komplexität als an- API zur Konfiguration der Anwendung zur
potenziell sicherheitskritisch. Außerdem dere Orchestrierer aufweist. Verfügung stellt. Zum Ansprechen dieses
erfordert das Aktualisieren eines Contai- API steht ebenfalls ein Ansible-Modul zur
ners in diesem Fall ein erneutes Ausbrin- Verfügung.
gen der virtuellen Maschinen, auch wenn Synthese Die horizontale Skalierung der VMs
sich auf Betriebssystem-Ebene keine Än- und Container für die Worker-Nodes wird
derungen ergeben haben. Der Orchestrierer beziehungsweise Ran- von Ansible und nicht vom Orchestrie-
cher stellt das Bindeglied zwischen VMs rer umgesetzt. Dieses Vorgehen erleich-
und Containern dar. Rancher erstellt dy- tert den Canary Rollout und ermöglicht
Container mit Rancher namisch virtuelle Netzwerke und Tun- ein dediziertes Eingreifen in spezifische
nel zwischen den Containern. Zudem Deployments auf Worker Nodes. Teil der
Ein Container-Orchestrierer vereinfacht stellt Rancher einen DNS-Server zur Ver- Ansible-Konfiguration ist ein Skalierungs-
das Management von verteilten, contai- fügung, wodurch sich Container über parameter, der den Einfluss auf die Ska-
nerisierten Anwendungen. Bei der Ver- ihre jeweiligen Namen Host-übergrei- lierung des Deployments bestimmt. So
wendung eines Orchestrierers sorgt fend erreichen können. Daneben stellt werden im Falle eines Skalierungspara-
Ansible also lediglich dafür, dass ein Or- Rancher ein API zur Verfügung, über meters von „20“ unter anderem 20 Wor-
chestrierer-Master gestartet wird sowie das alle Aspekte von Containern verwal- ker VMs gestartet und dort jeweils eine
alle virtuellen Maschinen, auf denen BBB tet werden können. Dadurch muss so- BBB-Instanz installiert.
zur Ausführung kommen soll, mit diesem mit nicht mehr jeder Container Teil der Das schrittweise Deployment in der fi-
verbunden werden. Der Orchestrierer Betriebssystem-Konfiguration sein, son- nalen Umsetzung sieht entsprechend wie
kümmert sich dann um die Verteilung der dern kann dynamisch von Rancher ver- folgt aus und wird durch Abbildung 3 ver-
Container. waltet werden. Im Rückschluss bedeu- anschaulicht:
68 www.aoug.at • www.doag.org • www.soug.ch1. Deployment der virtuellen Maschinen fenen Entscheidungen und die umge- mutability und vertieft die technischen
2. Deployment des Rancher-Master-Ser- setzte Lösung zurück. Unser technisches Konzepte von Teil 2.
vers Konzept hat sich während der letzten 12
3. Rancher-Master-Daten werden an An- Monate sehr bewährt. Wir waren immer
sible übermittelt dazu in der Lage, schnell auf wechselnde Quellen
4. Rancher-Master-API ist verfügbar Anforderungen zu reagieren und Ände- [1] Siehe auch Red Stack Magazin Nr. 6 -
5. Rancher Agents melden sich bei Ran- rungen umzusetzen. Aus Mangel an Er- 12/2019 „Die eigene Cloud – Wann eine
cher an fahrungswerten bezüglich großer BBB-In- On-Premises-Lösung Sinn macht“
[2] https://medium.com/omi-uulm/the-vertical-
6. Deployment der funktionalen Anwen- stallationen erwies sich insbesondere die immutable-infrastructure-pattern-
dungen (Scalelite, BBB) und deren flexible Skalierung von Vorteil. ecd24b8af882
Konfiguration So war es eine Sache von ca. 30 Mi- [3] https://www.ansible.com/
[4] http://kubernetes.io/
7. Deployment der nicht-funktionalen nuten, die Anzahl der Server von 20 auf [5] https://rancher.com/docs/rancher/v1.6/en/
Anwendungen, insbesondere des Mo- 30 zu erhöhen und in Betrieb zu neh-
nitorings men. Auch die Änderung des Hardware-
Flavor zum Wintersemester (16 statt 8
Cores pro VM) konnte mittels Canary Re-
Zusammenfassung und lease ohne großen Aufwand und ohne
Ausblick Unterbrechung im Betrieb vonstatten-
gehen. Der dritte Teil dieser Beitragsse-
Nach etwa einem Jahr Produktiv-Betrieb rie widmet sich dem unserer Installation
blicken wir sehr zufrieden auf die getrof- zugrunde liegenden Konzept der Im-
Thomas Nau Simon Volpert Dr. Jörg Domaschka
thomas.nau@uni-ulm.de simon.volpert@uni-ulm.de joerg.domaschka@uni-ulm.de
Steffen Moser
steffen.moser@uni-ulm.de
Red Stack Magazin 04/2021 69Sie können auch lesen
