Hatte ich noch als Aufgabe von letzer Woche.
Die “Schritte” sind keine Aufgaben, diese müssen noch abgeleitet werden, das erscheint mir aber recht offensichtlich.
Split Münster
Vorbedingung:
* Neue Domain ist Serverseitig einsatzbereit und getestet
* Es gibt eine Firmware für die neue Domain (ggf alte FW mit neuem Default)
* Neu Domain + Firmware für neue Domain sind getestet
* Aktuelle Firmware hat eine erhöhte Check-Update Frequenz (zb 2h) und ist ausgerollt.
A - Aufgabe, K-Erfüllungskriterium, R-Risiko
A1: Verfahren um Nodes in Münster identifizieren ist bereit
:= Nodes mit Koordinaten in Münster +
mit Mesh verbundene Nodes +
bekannte Knoten die nicht auf der Karte sind (Flüchtlingsheime)
K:
[ ] Liste lässt sich robust vollständig erzeugen
[ ] Stichprobe von >20% der MACs positiv, keine Fehler
Optional: Wenn die "Stadt" in weitere kleine Einheiten geteilt werden soll um eine Big-Bang Migration zu vermeiden:
[ ] Die Knoten der Stadt werden eine Menge von (z.b. geografisch geordneten) Zonen unterteilt.
[ ] Diese Zonen sind überschneidungsfrei in Bezug auf Knoten (d.h. ein Knoten ist nicht in zwei Zonen, das ist später w.g der Wellen wichtig).
[ ] Es besteht keine Mesh-Verbindung zwischen Knoten unterschiedlicher Zonen (dann Verschiebung der Blätter in Richtung Wurzel-Zone)
[ ] Stichprobenhafte Prüfung, idealerweise per Visualisierung.
R: -
A2: Verfahren um Update-Reihenfolge zu bestimmen ist bereit
(Bester bekannter Ansatz: Netz als Graph von den Zweigen her aufrollen. Bisher sprachen wir glaube ich nur über 2-3 Ebenen
Doku + Software: https://saar.freifunk.net/technische-infrmationen-zum-freifunk-netzupdate/)
K: [ ] die Liste aus A1 kann in "Wellen" segmentiert werden (dazu muss der Saar Ansatz erweitert werden)
[ ] A1+A2 lassen sich (halb-) automatisch ausführen.
[ ] Ergebnis sind NGINX "allow" Konfigurationsbruchstücke.
R: -
Neue Vorbedingung: Es gibt zwei neue Builds (V' und V'') der bestehenden Software (alte Domain).
Diese unterscheidet sich jeweils nur (!) in der Version und diesen als "Blindupdate" um den Update Mechanismus zu testen.
Diese zweite Version wird auf dem Download Server bereitgestellt.
A3: Software Update Steuerung per NGINX MAC Liste wird mit einzelnem Blindupdate erprobt
Dazu: Manuelle einen Eintrag in der Art der später mechanisch für die "Update Steuerung" erstellt
K: [ ] Nur die Testrouter (und keine anderen) zeigen nach einiger Zeit (abhängig von der eingangs genannten Update Check Frequenz die neue Version B').
Prüfung über graphite.
R1: Ausfall NGINX bei Fehlkonfiguration. Ist aber ohne Konsequenz da dann einfach keine Updates durchgeführt werden.
R2: Mechanismus in NGINX funktioniert falsch, worst case: alle bestehenden Router bekommen ungewollt die neue Version "zugewiesen".
Folgenlos, da die neue Version mit der alten identisch ist.
A4: Verfahren des Rollout in Wellen ist per Blindupdate erprobt.
Dazu werden in mehren Wellen die aus A1+A2 erstellten Update-Listen in Update Server NGINX eingespielt.
Dazwischen jeweils länger als "Update Check" warten.
Nach jeder Welle die Liste der Knoten und Versionen (z.b. nodes.json) regelmässig sichern, idealerweise ist dies ein automatischer Prozess damit man sich darum nicht kümmern muss. Descilla hat da was.
K: [ ] Abgleich nach jeder Welle ergibt das keine Knoten die nicht auf V'' umgeleitet wurden aktualisert wurden.
[ ] Nach Abschluss: Delta der zu aktualisierenden und praktisch aktualisierten Knoten ist in ihrer absoluten Menge für uns akzeptabel.
R: Siehe A3
Dann schauen wir uns die Chose nochmal an … und los geht’s!
p.s.: Einen Test des Updates auf einem Extra Webserver mit extra Firmware halte ich entsprechen der Risiken für nicht notwendig.
Matthias und ich haben schon getestet, wie das ganze funktioniert:
Wir haben einen nginx aufgesetzt mit 2 Verzeichnisbäumen, einen mit der Original-Version der Client-Software und einen mit einer Test-Version. Zusätzlich haben wir eine Variable per geo-Modul abhängig von der IPv6-Adresse des zugreifenden Rechners auf 0 oder 1 gesetzt. Durch diese Variable haben wir dann gesteuert, ob der Rechner die Original-Version oder die Test-Version sieht. Der Code-Block für das Setzen des Variable wird vom Skript neighbors.py erzeugt, so dass man es nur noch mit Copy&Paste einfügen muss. Hierbei unterstützen wir die notwendigen Wellen durch Abschnitte/Kommentare und auskommentierte Einträge.
Dazu haben wir dann 3 Freifunkrouter umkonfiguriert, so dass sie Updates vom Test-nginx holen. Hierbei waren 2 Router über Mesh verbunden.
Das Ergebnis war, dass alle 3 Router am Ende in der Pilot-Domäne waren. D.h. das Update in 2 Wellen hat funktioniert.
Beim Test hat sich noch ergeben, dass wir mit den Versionsnummern aufpassen müssen. Die Firmwares, auf die wir schwenken wollen, müssen eine höhere Nummer haben, als die zu dem Zeitpunkt laufenden und als die für die alte Domäne runterladbare.
Ich bin gerade dabei das Migrations-Graphen-Nodes-Migrations-Graphen-Selektions-Hierarchie-Whatever-Script zu verfeinern.
Dazu folgende Fragestellung:
@Parad0x sprach mich letztens darauf an, dass es sinnvoll wäre nicht nur den derzeitigen Zustand zu berücksichtigen, sondern auch vergangenes mit einzubeziehen. D. h. in die Berechnung der Migrations-Reihenfolge sollen auch Router mit einbezogen werden, die gerade nicht online sind. Und auch Mesh-Links zu berücksichtigen, die gerade nicht vorhanden sind. Gründe sind wohl Router, die am Stromkreis der Weihnachtsbeleuchtung o. Ä. hängen und daher nicht immer online sind.
Prinzipiell eine gute Überlegung, jedoch sollten wir klären, wie lang der Offline-Zustand vorhanden sein darf, bzw. wie lange der Mesh-Link abgebrochen sein darf, damit er noch in der Berechnung berücksichtigt wird.
Quasi unabhängig davon sollten wir uns außerdem überlegen, wie lange die einzelnen „Wellen“ dauern dürfen. Also wie lange ein Nodes Zeit bekommen sollte sich die aktuelle Firmware abzuholen. Da die Nodes, die schon die neue Firmware haben so lange offline sind, bis alle Nodes auf dem Pfad bis zum Node mit VPN die neue Firmware haben, sollte dieses Intervall auch nicht all zu lang sein.
Um dieses Problem zu umgehen könnte man natürlich alle Mesh-Wolken einzeln betrachten. Das würde jedoch im Vergleich zum Wellen-Verfahren die dynamische Generierung der Webserver-Konfiguration erfordern oder sehr, sehr, sehr viel Handarbeit. Daher und weil die Struktur dahinter einfacher/robuster ist, favorisiere ich das Wellen-Prinzip.
Ich habe jetzt ein kleines Script zum Tracken des Umzugs gebaut. Das baut auf mein Script zum erzeugen der “Wellen” auf, denn dort wird nun für jede Domäne ein json File erzeugt, auf dessen Basis ich tracke. Eine Ausgabe sieht zum Beispiel so aus (es kann stets die aktuelle nodes.json vom Server gezogen werden, um den Fortschritt nachvollziehen zu können):
descilla@des-nobody-knows:~/git/tools/node_hierarchy$ ./track_statistics.py
Open node.json file: nodes.json
Open node.json file: ../domaenensplit_webserver_config/muenster_sued_node_statistics.json
Open node.json file: ../domaenensplit_webserver_config/muenster_stadt_node_statistics.json
Open node.json file: ../domaenensplit_webserver_config/kreis_coesfeld_node_statistics.json
Open node.json file: ../domaenensplit_webserver_config/kreis_warendorf_node_statistics.json
Open node.json file: ../domaenensplit_webserver_config/kreis_steinfurt_ost_node_statistics.json
Open node.json file: ../domaenensplit_webserver_config/kreis_steinfurt_west_node_statistics.json
Open node.json file: ../domaenensplit_webserver_config/kreis_borken_node_statistics.json
--------------------------------------------------
Printing statistics for domain: Münster Süd
Level: 0
v2015.1.2+169: 27
v2015.1.1+155+forcedeth: 1
Level: 1
v2015.1.2+169: 18
--------------------------------------------------
--------------------------------------------------
Printing statistics for domain: Münster Stadt
Level: 0
v2015.1.2+169: 129
v2015.1.2+178: 1
master+202: 1
master+201: 1
v2015.1.2+191: 1
v2014.4+136: 1
v2014.3.1+107: 1
0.7~09-21-15_22-48: 1
Level: 1
v2015.1.2+169: 29
Level: 2
v2015.1.2+169: 2
--------------------------------------------------
--------------------------------------------------
Printing statistics for domain: Kreis Coesfeld
Level: 0
v2015.1.2+169: 99
master+202: 3
Level: 1
v2015.1.2+169: 34
Level: 2
v2015.1.2+169: 5
Level: 3
v2015.1.2+169: 1
Level: 4
v2015.1.2+169: 1
Level: 5
v2015.1.2+169: 1
--------------------------------------------------
--------------------------------------------------
Printing statistics for domain: Kreis Warendorf
Level: 0
v2015.1.2+169: 53
gluon-master+206: 1
Level: 1
v2015.1.2+169: 8
master+202: 1
--------------------------------------------------
--------------------------------------------------
Printing statistics for domain: Kreis Steinfurt Ost
Level: 0
v2015.1.2+169: 111
master+202: 3
Level: 1
v2015.1.2+169: 29
master+202: 2
Level: 2
v2015.1.2+169: 7
--------------------------------------------------
--------------------------------------------------
Printing statistics for domain: Kreis Steinfurt West
Level: 0
v2015.1.2+169: 160
master+201: 7
master+202: 4
Level: 1
v2015.1.2+169: 37
master+202: 2
master+201: 1
Level: 2
v2015.1.2+169: 3
Level: 3
v2015.1.2+169: 1
--------------------------------------------------
--------------------------------------------------
Printing statistics for domain: Kreis Borken
Level: 0
v2015.1.2+169: 159
master+202: 1
Level: 1
v2015.1.2+169: 29
Level: 2
v2015.1.2+169: 2
gluon-master+206: 1
Level: 3
v2015.1.2+169: 1
--------------------------------------------------