 Ja, herzlich willkommen zurück auf dem Femme-Channel. Gleich lässt die Femme ein wenig die Hosen runter, denn Jenny wird gleich ein paar Vorfälle im Femnet vorstellen, wo unsere Systeme, von denen wir eigentlich dachten, dass sie hoch verfügbar waren, es dann am Ende vielleicht doch nicht ganz so war. Für diesen Talk wird es leider kein Q&A geben und auch später keine Breakout-Session, aber vielleicht sieht man sich ja mal später in der Welt. Jenny hat halt leider im Moment keine Zeit, denn auch sie ist heute hier im Studio stark beschäftigt. Ja, this talk will also be translated into the English language. If you want to hear the English translation, please select the translated audio stream in the web player. Und nun wünsche ich viel Spaß mit, das ist doch Ha! Hallo, ich bin Jenny und ich werde euch heute etwas über High Availability-Konstrukte erzählen, die sich im Endeffekt aus lustigen Gründen als vielleicht doch nicht so Ha herausgestellt haben. Erst mal ganz kurz werde ich euch fragen, wer ist Jenny? Ja, ich bin eine Informatik-Studentin an der TU Immena seit 2017 und ebenfalls bin ich seit 2017 im Ressort-Technik der Femm-Aktiv. Und dort betreue ich auch einige Softwareklumpen im Femnet. Hier noch so ein bisschen Social Media und Kontakt, meine E-Mail-Adresse, mein Mast oder mein Twitter GitHub. Wer wissen möchte, was ich so tue, da könnte man es herausfinden. Ja, erst mal einen kurzer Ausblick, das eben war die Einführung. Jetzt werde ich euch gleich noch die Motivation erklären, weshalb wir diesen Spaß hier überhaupt machen. Und dann werden wir uns einige Gründe für das Auseinanderfallen von Ha-Konstrukten angucken. Genau, erst mal, warum machen wir denn das eigentlich? Bei der Femme gibt es sehr viele große, teils selbstgebaute Softwarekonstrukte. Und diese sind an einigen Stellen deutlich komplizierter gebaut, als sie sein müssten. Und deshalb fallen sie häufig aus lustigen oder auch traurigen Gründen, wie man es sieht, auseinander. Und heute wollen wir uns die Gründe für diese lustigen oder traurigen Gründe einmal anschauen. Ja, fangen wir erst mal an mit etwas, wo ich eher weniger Berührungspunkte mit habe und was mit unserem Femm-Jitzi. Und zwar betreibt die Femm schon seit vor Corona-Zeiten eine Jitzi-Instanz. Das war damals nur eine einzelne Femm. Aber als Corona anfing und alles auf Online verschoben wurde und halt der Bedarf, da war ein Jitzi zu haben, musste das Jitzi ausgebaut werden. Und das wurde entsprechend auch getan. Dann gab es eine Master-Femm, welche von Welt aus erreichbar ist und enden verschiedene Videobridges, die dahinter hingen und halt vom Master gesteuert worden sind. Und die Master-Femm hatte die Public-LPs, also vor 4 und vor 6 der alten Standalone-Femm übernommen und die alte Standalone-Femm wurde abgeschaltet. Jetzt gab es dann jedoch ein kleines Problem, wenn wir uns mal die Konfiguration im Proxmox der alten Standalone-Femm angucken. Da sehen wir hier sehr schön, als Start-At-Boot vergessen wurde, abzuschalten, weil dieser Femm die inaktiv war. Und ja, das hat dann bei einem Proxmox-Update für Probleme geführt. Und es war, als wir den Node rebooted haben, war die Femm dann auch wieder an, hinterher. Und hat sich auch ihre statisch konfigurierte IP wieder geholt, die jedoch auch am anderen Master-Anlag. Das hat jetzt dafür geführt, dass das Jitzi so halb kaputt war, weil wir zwei Master mit der gleichen IP hatten, wovon einer auch noch halb kaputt war, weil laut Angaben war die alte Standalone-Femm sowieso. Und was spannend ist, das Jitzi war aber trotzdem größtenteils noch verwendbar. Also man konnte Konferenz nehmen, manchmal haben sich Leute nicht gehört, manchmal konnten sich Leute nicht verbinden, whatever, und man hat sich gefragt, woran lag es. Laut Angaben, unsere Jitzi-Admins, konnte man sich auch wunderbar hinessen, das hat zwar hier und da ein bisschen geleckt, aber es ging noch. Naja, jedenfalls, als dann die alte Master-Femm ausgeschaltet wurde, ging wieder alles wunderbar dann. Genau, dann jetzt etwas, wo ich doch etwas mehr Berührungspunkte zu habe, Web 1. Und zwar werde ich euch jetzt mal fragen, was ist denn das? Ja, das Web 1 ist das Web-Cluster der Femm und das wird unter anderem von mir betreut und es wird größtenteils benutzt, um Web-Posting für uns, also für die Femm zu machen, aber auch für andere Vereine und Gremien auf dem Campus, also an der Uni. Und wir machen da dann praktisch shared hosting für die. Und da sich sehr viele Institutionen, halt auch wir, auf dieses Web-Cluster verlassen, wurde bei der Entwicklung auch sehr viel auf Hoferfügbarkeit des Clusters geachtet. Genau, da habe ich dann hier einmal eine Skizze des, von Web 1, wurde von dem lieben Nex aus unserem Verein in einmal für Latech gezeichnet. Danke an dieser Stelle an Nex. Und ja, einmal nur ganz kurz, wie dieses Konstrukt aufgebaut ist. Wir haben ganz oben den Load-Belenzer. Das sind zwei Notes, die sich einer HAAP hin und her schieben und zusätzlich auch port 22 an Web 1-Manage vorworden, damit sich die Leute, die unser Web-Cluster verwenden per SFTP einloggen können. Ja, genau. Und dann der jeweils aktive Load-Belenzer vorwortet dann halt die Request an jeweils die Web-Nodes. Davon haben wir pro HAAP-Version zwei verschiedene Web-Nodes, die dann halt da sind. Also aktuell sind es halt zwei für per HAAP 7.1, zwei für 7.0, ein zwei für 5.6. Ja, das ist veraltet, aber wird auch demnächst noch alles neu gebaut. Das habe ich halt so übernommen, wie es ist. Und ich betreue es eigentlich nur, ich habe es nicht gebaut. Genau zusätzlich können die per P-Anwendung auf den Web-Nodes noch auf MySQL zugreifen oder auf Postgres, je nachdem, wie sie es brauchen. MySQL 2, das ist unser MySQL-Cluster, besteht aus Istmaria.deb mit einer Master-Master Replication, besteht aus zwei Notes. Also auch hier haben wir HAAP und PQS SQL 2, das habe ich tatsächlich selbst gebaut. Das ist die einzige Komponente von mir hier, die ich selbst gebaut habe. Da haben wir drei Notes, die in einem Hot-Standby sind. Also das ist ein Postgres 13 mit Hot-Standby über Wrap-Manager. Also hierbei haben wir auch High-Availability. Genau, und die ganzen Web-Nodes greifen über NFS auf die Dateien zu, die auf HAAP Storage 1 liegen. Die ganzen per P-Skripte, HTML, whatever, was halt so eine Website so braucht zum existieren. Und diese Dateien, die da liegen, die können über dieses ja NFS-Mount, ist auch auf Web1 Manage eingehangen, damit sich die Leute, die sich per SFTP eingelockt haben, auf ihre Dateien zu greifen können und die Websites entsprechend ändern können. Der Authentifizierung passiert dann gegen MySQL 2, über die Personen gebundenen MySQL-Logins der Personen. Einfach nur mit dem Hintergrund, dass wir da nicht so viele Logins pflegen müssen. Dann haben wir das einfach. Ja genau, und bei jetzt sehen wir hier HAAP Storage 1. Da steht hier so ganz alleine da, da hat sich jetzt nichts zu gesagt. Wird das ein Grund haben, weshalb das kein HAAP? Und ja, das hat einen Grund. Und zwar, das war mal als HAAP Storage geplant ganz damals. Das sollte mit GlasterFS umgesetzt werden. Aber da hat man festgestellt, dass das Dorf langsam ist und viele Gründe war weit vor meiner Zeit, wurde mir nur so überliefert. Und deshalb wurde dieser Ansatz dann wieder verworfen. Und jetzt ist es dann nur noch ein Note, der den NFS Share anbietet. Und wenn der Note aus ist, sind sämtliche PHP-Skrips weg und auch Statushart, dem L-Dateien und alle Webseiten sind aus. Und ja, damit ist dann praktisch Web 1 kaputt. Und da sieht man wieder, es wurde so viel auf A geachtet und diese eine Komponente. Aber eigentlich Blick ist zu sehen, es wurde bereits an HAAP Storage 2 gebaut und da haben wir dann tatsächlich HA mit jetzt DABD. Was denn DABD genau ist, da können wir gleich zu bei dem nächsten Softwareklumpen, den wir uns mal anschauen werden. Und zwar ist unserer allzeit geliebte Admin DB. Jetzt werden sich außenstehende Menschen fragen, was ist denn eine Admin DB? Ja, also grob gesagt ist die Admin DB die Mitgliedsdatbank der FEMM. Das klingt erstmal unschuldig und lieb und nett. Und ja, das Ding wird unter anderem auch von mir betreut, aber auch hier der Disclaimer, ich habe das Ding nicht gebaut, ich habe jetzt nur am Leben und der Bicke ist hier und da etwas weiter. Und ja, verwaltet alle Geräte im FEMMnet und konfiguriert auch die Switche. Also unsere Mitglieder haben Geräte, die müssen über uns anmelden und das hat den Grund, weil die Uni, von der wir das Netz bekommen, die möchte zum einen wissen, welche Geräte sich hier in ihrem Netz tummeln und zweitens dürfen nur Universitätsangehörige, die die Nutzungsbedingungen des AZ unterschrieben haben, unseren Netz benutzen. Ja, und deshalb müssen sich die Leute anmelden und die Geräte der Mitglieder kriegen auch statische IPs zugeordnet, Public IPs, damit man in den Views verlesen weiß, wer wann was getan hat. Und dafür konfiguriert die Admin DB auch den DRCP Server und setzt bei Belieben auch den S-Records auf die IPs, die die Mitglieder haben, damit sie sich selber den S klicken können bei uns intern. Genau. Dann hier einmal eine sehr stark vereinfachte Struktur der Admin DB, da ich mir ein paar Notizien mache, wie ich das hier euch ordentlich erklären kann. Und zwar ist das hier der Admin DB 2 DB. Das ist die zentrale Postgres-Datenbank der Admin DB und ist auch hier ein Hot-Standby-Konstrukt, bestehend aus zwei Masters, die Hot-Standby mit jetzt DRPD machen und zwei Slaves, die halt immer Slaves sind und einer davon spielt auch Arbiter für die HA-IP, die an dem aktiven Master anliegt. Und ja, das ist halt hier so realisiert, dass die Postgres-Daten auf einem DRPD liegen. DRPD ist praktisch ein Web-1, ein Wade-1 über das Netzwerk und das kann halt nur auf einem Not gleichzeitig aktiv sein. Und ja, das ist tatsächlich eine von Postgres empfohlenene Möglichkeit, Hot-Standby zu realisieren. Also das Verzeichnis war, alle Postgres liegt auf einem solchen DRPD-Block-Device und das wird halt repliziert und auf dem, der halt gerade die HA-IP hat, wird das Block-Device auf Primary gesetzt. Das Ding wird gemountet, Postgres wird gestartet, HA-IP hingeschoben und ja, dann ist der Primary. Genau. Und dass das jedoch nicht so gut klappt, ist vielleicht nochmal zu kommen in manchen Situationen. Genau, dann einmal ganz kurz, der AdminDB2 Web. Das ist unser Webfrontend für die AdminDB, bestehend aus zwei Notes und einem Arbiter einfach nur. Also das ist auch Hot-Standby, also was heißt Hot-Standby, die sind beide immer aktiver bei einer der HA-IP und ja, das ist einfach nur das Webfrontend, um die AdminDB zu verwalten. Genau, dann haben wir AdminDB2 Radius. Wir haben zwei immer aktive Free-Radius-Server, gegen welche sich unsere Switche und das WLAN im Femnet authentifizieren. Und diese Authentifizierung wird dann halt weitergegeben ans SQL, also der Radius-Server guckt dann beispielsweise darauf Mac-Adresse XY an Switchboard Z, gerade das Internet benutzt und welches VLan kriegt, bla, solche Sachen. Dann sieht man hier auch, die Switche werden konfiguriert von AdminDB2 EXT. Jetzt fragt man sich wofür steht denn EXT, alles andere sind sehr eindeutige Begriffe, ja, ich weiß es auch nicht genau, aber laut unserem Wiki steht, laufen da die Hintergrunddienst, also denke ich meist für so was wie Extra stehen. Und da laufen halt solche Dinge wie unser DB2 Switch beispielsweise, was die Switche voll automatisch per SSH konfiguriert, die Dinge einzurichten, die nicht per Radius eingerichtet werden können. Das sind zum Beispiel Tech-TV-Lahans Anliegen oder ähnliches oder PoE-Anscheiden auf manchen Switchboards, die werden halt darüber dann voll automatisch verweitet, genau. Und zusätzlich ist das Ding auch noch der primäre DNS-Server für alle unsere internen Zonen, die wir bei uns im Netz haben. Und ja genau, das ist dann halt ein Power-DNS, der sich dann per Postgres bei Power-DNS kann sich aus SQL eine Zone definieren und das holt er sich halt aus unserer Postgres-Datenbank. Und ja, hier haben wir einfach wieder zwei Notes auch mit einem Arbitternode, die sich die Dienste einfach teilen. Also auch manche Dinge laufen halt, manche Dinge. Auf einem läuft beispielsweise das DB2 Switch, auf einem läuft der Power-DNS, whatever. Genau, dann haben wir Admin DB2 DNS. Das sind unsere sekundären DNS-Server, also unsere DNS Slaves für unsere internen Zonen und zusätzlich die DNS Resolver für alle unsere Clients. Also unsere Clients kriegen per DHCP, diese DNS-Server ausgeteilt, sind auch wieder zwei Server, die sich eigentlich nur, das HA ist hierfür da, um die IP von dem einen Server auch noch an den anderen zu schieben, falls er aus ist. Damit beide DNS IPs in jedem Fall erreichbar sind. Und ja, auch hier haben wir wieder einen Arbitter und ja, die Clients kriegen dann wie gesagt vom DHCP, wo wir jetzt zukommen, ihre IPs. Und ja, der ist auch wieder voll HA, das ist heutzutage, sind es zwei Load-Belänzende DHCP-Server, die halt in unterschiedlichen V-Lands hängen, beispielsweise in Load1 hängen jetzt in V-Lan 1 bis 3, Load2 hängt in V-Lan 4 bis 6 und da spielt die halt der DHCP-Server. Ihre Konfig holen die sich auch aus der Admin-DB, da gibt es Kripte, die templateigen Magie machen und zusätzlich sieht man dann auch hier diesen Fall, das ist das ARP Watch. Und was genau das ist, da kommen wir dann später nochmal zu. Aber es sei nun schon mal angemerkt. Ja genau, und jetzt kommen wir zu einigen Problemen, die bei diesem eventuell doch leicht over-engineerten Design auftreten können. Und zwar erst mal zu Admin-DB 2DB. Wie gesagt, zentrale Postgres-Datenbank und damit das Herzstück unserer Admin-DB und HA mittels Hot-Standby über DRBD. Und ja, wie schon erwähnt, nur der aktuelle Primary-Note hat das DRBD mit den Postgres-Daten gemountet und das Problem ist, oder war gewesen, mittlerweile ist es oben, beim Stoppen möchte Postgres unbedingt noch auf die Festplatte schreiben mit, ich bin jetzt gestoppt, ich bin ordentlich heruntergefahren. Und jedoch ist dann das Problem, dass bevor das passiert ist, hatte das DRBD in den meisten Fällen schon den Failover zum anderen Not gemacht, als das Postgres hatte sein Dateisystem nicht mehr und konnte nicht mehr den letzten Satz hinschreiben mit, ich hatte jetzt einen ordentlichen Shutdown. Und ja, wie gesagt, der alte Note konnte nicht mehr, ich bin gestoppt, schreiben, der neue Note konnte nicht mehr starten, der Postgres-Jahr anscheinend nicht ordentlich gestoppt wurde und dann war er traurig und dann war die Admin-DB kaputt und dann war es schon wieder kaputt. Also so komplett, das bröselt dann nach und nach, die Radioserver haben noch ein bisschen ihren Cash, aber der DHCP kann seine Konfig nicht mehr regenerieren, im WLAN kann man sich gar nicht mehr anmelden, weil auch über den Radios kommen die PSKs fürs WLAN und ganz schwierig und im Großen und Ganzen ist dann nach und nach immer das Netz kaputt, wenn wir solche kleinen Spielereien haben. Genau, dann noch eine kleine SKP-Harte mit unserer Datenbank und zwar ist es so eine kleine Eigenheit bei uns, man redet nicht direkt mit den SQL-Tabellen, sondern ausschließlich mit SQL-Funktionen. Ja, das hat den Hintergrund, dass damit sowohl Berechtigungen überprüft werden können, also wir haben da ein einfaches baumartiges Berechtigungssystem und man lockt sich mit seinem Postgres-Benutzermahlen und die Funktionen gucken dann Dorfpersonen, XY über die Räume, die sie hat, diese Funktion ausführen. Aber zum anderen können auch Zugriffer aufteilt sehr empfindliche Mitgliedsdaten gelockt werden. Also die Intention ist schon richtig. Genau, jedoch wollen wir natürlich auch innerhalb von Transaktionen locken und die Logs von Transaktionen sollen nicht bei einer abgebrochenen Transaktion verschwinden. Sonst könnte man ja beispielsweise sagen, ja, ich mache jetzt ganz schlimme illegale Sachen, ich gucke mir Dinge an, die ich nicht angucken darf und dann breche ich die Transaktionen ab und dann sind die Logs weg, die in der Zwischenzeit geschrieben worden sind. Und deshalb, das kann man sich jetzt überlegen, wie man das findet, also da kann jetzt hier das eine eigene Meinung zu haben, aber wir realisieren das Logging deshalb durch eine Postgres-Funktion, die in Python geschrieben wurde und in eine MongoDB-Log. Wie gesagt, kann sich jeder dazu denken, wie intuitive oder nicht man das findet. Ja, genau, dafür läuft auf beiden DB-Mastern jedenfalls eine replizierte MongoDB und in diese werden die Logs dann noch reingeschrieben. Ja, und jetzt habe ich dann hier mal einen kleinen Code-Ausschnitt mitgebracht und es war es von adminDB-Log. Die habe ich ein kleines bisschen modifiziert dafür, aber eigentlich ist diese Stelle hier nur das Interessante. Ich hoffe mal, dass man das auch erkennt, gar nicht im Vortrag. Ich habe die Zeile hier etwas umgebrochen, normalerweise wäre das bis hierhin eine Zeile gewesen. Jedenfalls, was man hier sieht, baut zum Log eine Verbindung auf, zum MongoDB auf adbDB2DB Master1 oder auf Master1. Ja, das hat dann jetzt den tollen Effekt gehabt, als wir mal den VM-Houst aus hatten, auf dem Master1 lief und die VM wirklich auch aus war, wo Master1 drauf war, habe ich festgestellt, Master2 läuft, die Postgres da hatten Bankenprimerie, Fiora hat alles geklappt, die hat sich ihre IP geholt, aber man kann gar keine Funktionen ausführen, weil es Vlogging nicht geht. Dann habe ich mal nachgeguckt und habe hier im Code gesehen, oh, das ist ja doof. Logs entweder auf den Note oder auf nochmal den gleichen Note. Da ließ ich dann jedoch relativ einfach beheben, dass ich aus einer dieser Einsen eine 2 gemacht habe und wo wohnt noch es gegen. Denn wenn nichts gelockt werden kann, selbst das generierende RACP-Config wird gelockt, legt das auch so ziemlich das gesamte Femnetlamm. Also, je alte RACP-Config besteht dann noch bis auf weiteres, aber RACP-Updates und eigentlich können nicht eingespielt werden. Und das macht das Femnet in diesem Fall auch kaputt. Also, hier ist das Haar, dann auch wieder ein gutes Stück auseinander gefallen. Genau, dann noch eine nächste Komponente, die ab und zu mal kaputt geht und zwar aus unserer schönen RACP-Server. Und zwar das kabelgebundene Gerät, bei uns im Femnet bekommen Public IPv4-Adressen, damit sie nicht durch den Natten müssen, weil wenn man sich per Kabel ansteckt hat, bei uns in der Regel mindestens Gigabit und Gigabit zu Natten auf mehrere Leute macht ab einer gewissen Stelle keinen Spaß mehr und deshalb hat man da halt Public IPv4-Adressen. Genau, aber hier haben wir nicht all so viele IPv4-Adressen und zusätzlich werden die IPs den Max jeweils statisch zugewiesen aus eben genannten Gründen der Nachvollziehbarkeit und damit wir bei In-App Use-Fan wissen, wer, wann, welche IP er hatte. Genau, aber wir möchten jetzt auch, dass es möglich ist, wenn ein IP freigegeben wurde, dass diese möglichst schnell wieder alluziert werden kann. Und deshalb haben wir eine Lease-Live-Time im Femnet von fünf Minuten und jetzt haben wir jedoch auch so um die 5.000 Geräte bei uns im Femnet. Das bedeutet, jedes dieser 5.000 Geräte, wenn sie dann gleich immer angenommen, gleichzeitig aktiv sein sollten, kommt zum DHCP-Server und fragt alle fünf Minuten an, ob seine IP-Adresse noch gültig ist. Der DHCP-Server hat dadurch sehr viel Spaß und zusätzlich zum normalen DHCP hat der DHCP-Server nun jedoch auch noch die Aufgabe, das eben schon erwähnte sogenannte Abwatch auf Admin DB2 X zu befittern. Und erst mal, was ist Abwatch? Abwatch lauscht in jedem Folen auf Ab und guckt, ob jede IP auch bei der Mac ist, bei der sie eigentlich sein sollte. Und der DHCP-Server sagt dem Abwatch dann, welche IP er an welche Mac vergeben hat. Es läuft so ab, indem bei jedem DHCP-Acknowledgement, also wenn das DHCP komplett durch ist, wird ein Perlskript aufgerufen, welches in ein Redes auf Admin DBX schreibt. Ich habe jetzt dieser Mac, dieser IP, gegeben zu diesem Zeitpunkt. Kann man sich wieder drüber streiten, wie sinnvoll das ist und wie nicht sinnvoll das ist Jedenfalls schreibt einem dieses wunderschöne Abwatch-Skript auch eine E-Mail, wenn es eine IP findet, die an einer nicht bösen Mac erhält, die an einer Mac ist, die er nicht kennt und es kommen sehr viele E-Mails, so viel sei schon einmal gesagt. Genau. Das sorgt dann aber dafür, dass der DHCP-Server alle fünf Minuten pro Gerät einen Lies verteilen muss und auch gleichzeitig noch dem Abwatch Bescheid sagen muss. Und damals war es so, das ist heute nicht mehr so, deshalb hatte ich es auch eben entsprechend erklärt, wie es heute ist in unserem Konstrukt. Das war ein einzelner ISC DHCP-Server, wobei ein Prozess für alle V-Lands zuständig war. Also da war praktisch das DHCP-Konstrukt, das waren auch die zwei Noten, aber das war auch so als hot-stand by zu verstehen. Es war wirklich nur einer war aktiv und einer war mit einem Prozess für alle V-Lands zuständig. Und ja, zu Stoßzeiten hatte der DHCP dann manchmal keine Lust mehr gehabt, weil es halt einfach in die Knie gegangen von der Last. Und ja, dann war der DHCP halt kaputt und auch Neustorben hat nicht viel geholfen, weil die gleichen DHCP-Requests kamen immer noch, also die Last hat halt nicht abgenommen. Und ja, dann war Legacy IP kaputt und dann konnte man sehr schön beobachten, wie viele Mails reinkamen mit, ich kam nur noch auf Google und YouTube, aber der Rest geht nicht mehr. Genau. Jedenfalls, das war ein kleiner Einblick in unsere HA-Strukturen. Es gibt auch sehr viele mehr, die so auseinanderfallen, aber das waren nur ein paar Highlights, vor allem mit denen ich auch viel zu tun hatte. Und ja, ich danke für die Aufmerksamkeit und hoffe, dass es zur Eurobelöstigung war. Ja, vielen Dank Jenny für den wirklich interessanten und zum Teil auch wirklich sehr lustigen Talk. Next up, 19 Uhr geht es weiter mit der nächsten Harriet News Show und um 20.15 Uhr stellt unsere gute Franca Battle of Render Engines vor. Dort schauen wir uns einmal verschiedene Render Engines an und wie Material dort unterschiedlich gerendert wird. Viel Spaß dabei.