Fortsetzung der Diskussion von Neuer Firmwaredownloader:
Die Frage möchte ich noch einmal aufgreifen, denn ich denke wir sollten uns überlegen wann und wie wir einen neuen Domänsplit einleiten wollen. Z.B. wml ist schon bald wieder an der magischen 200 Knoten Grenze von der ich mal gehört habe.
Wie sind eure Gedanken dazu?
WML hat sogar schon die Grenze von 220 Knoten online überschritten. Wird bald ™ in Angriff genommen. Wir haben letztens in der wz schon drüber gesprochen und mit den WMLern die Grenzen abgesteckt.
Ein festes Protokoll nach dem wir vorgehen haben wir nicht. Aber ich denke die meisten sind der Ansicht, dass man ab ~200-250 splitten sollten. Gerne auch schon eher. Wenn sich jemand konkret was wünscht, soll er das äußern und dann schauen wir mal…
Domäne2 ist auch bereits an die 200 Knoten angelangt.
Jap. Ich denke Domäne 06, Domäne 03 und Domäne 02 werden die nächsten Kandidaten sein. Aber ich denke, wir sollten erst die Legacy-Domäne leer fegen (oder zumindest die Knotenanzahl noch mal drastisch verringern). Dann haben wir auch wieder VMs, die wir verwenden können. Also haut rein. 
Ich werde morgen schon mal die geplante Teilung von Domäne 06 in die uMap-Karte eintragen (in einen eigenen Layer, der by default ausgeblendet ist). Ihr könnt euch bzgl. Domäne 02 ja auch schon mal Gedanken machen.
Update: Ich habe für WML mal die Flächen eingezeichnet: FFMS Domänen - uMap (auf der linken Seite unter den +/- Buttons auf den Button mit den zwei Markern klicken und dann die „WML Split“ Ebene einblenden). Hatte ich das richtig im Kopf oder habe ich mich vertan?
@descilla, sieht erstmal top aus. Jedoch bin ich der Meinung das wir zu der “Nord-Domäne-wml” noch Gescher und Südlohn/Oeding hinzu nehmen sollten. Denn im Süden des Kreises ist ein großes Wachstum zu erwarten. Ca. 150 Knoten kurzfristig. Im Norden + südlohn, Oeding und Gescher wird eher weniger passieren. Oder @desmaster und @guido_spoltmann wie denkt ihr darüber ?
Außerdem sollten wir den ersten Split erstmal hinter uns bringen 
Genau. Und die Sache mit der Firmware klären usw.
Statt es räumlich immer weiter zu zerteilen, wäre ich dafür einzelne Städte oder Gemeinden, mit vielen Knoten auszugliedern. Z. B. Steinfurt oder bei auch im WML die Stadt mit den meisten Knoten. Ich glaube, dass das für die Knotenaufsteller eher nachvollziehbar bleibt, als da Striche auf der Landkarte zu ziehen.
200 Knoten sind nicht optimal, aber auch nicht dramatisch. Daher denke ich auch, dass wir erstmal die Münsterlanddomäne aufräumen sollten. Dann haben wir auch wieder VM-Kapazitäten frei.
Vom Ablauf her ist das an einem Abend zu machen. VMs auf Jessie umstellen und dann Ansible drauf, bisschen Firmware bauen und dann noch die Karte aktualisieren.
Grüße
Matthias
In der Warpzone hatten @desmaster und meine wenigkeit es doch eigentlich so mit @descilla abgesprochen, das die B525 als ungefähre Grenze gezogen wird (und Oeding sollte, wenn möglich auch noch mit in den Norden gehen), damit wir für den Süden auch auch einige Wachstumsmöglichkeiten haben.
[Nur falls wir demnächst einen weiteren Splitt durchführen (müssen)]
Ja, deswenge habe ich gefragt, hatte es vergessen 
.
Ich finde die Idee von @MPW auch nicht schlecht, einzelne Städte auszugliedern. Was haltet ihr davon?
Auch das kann gern geschehen…wir haben grade die nächsten 350-400 Knoten im WML in Planung für die n#chsten 5 Monate…
Plan ist IMHO egal. Ansatz ist soweit ich weiss: Gesplittet wird wo (echter) Bedarf besteht.
Ich habe es jetzt mal aktualisiert. Besser so? Oder wirklich stumpf dem Verlauf der B525 folgen?
Hier nochmal zur Erklärung, warum eine weitere Unterteilung der jetzigen Domänen Quatsch ist: Wenn die WMLer es wirklich schaffen weitere 350 Knoten aufzubauen wären es mit den jetzigen ~600. Das macht also schon drei Domänen und nicht bloß eine Zweiteilung. Besser vier, denn es soll ja weiter wachsen.
Wird das dann Nord-Westmünsterland, Süd-Westermünsterland, West-Westmünterland und Ost-Westmünsterland? Das ist Quatsch.
Besser ein paar Städte mit vielen Knoten ausgliedern und das, wie @kgbvax es sagte, nach Bedarf. Wir können da bald mal anfangen, schließlich haben die schon 250 Knoten. Vorher sollten wir aber auch mal den Fokus auf Multi-Batman legen, den sonst wird das ganze irgendwann echt ein teures Hobby :).
Und mittel- bis langfristig hilft nur das Aachener Modell, denn irgendwann werden auch einzelne Städte eine gewisse magische Grenze überschreiten.
Für Ennigerloh prüfen wir gerade, inwieweit wir hier vor Ort was auf die Beine stellen können.
Wenn man den Kreis Borken auf der Karte mal betrachtet fällt einem schnell auf, das in den größten Städten (Bocholt,Borken,Ahaus…) noch kaum was los ist. Wenn die erstmal kommen kann man das mit Gebieten IMHO kaum noch realisieren. Ich glaube auch, das es sinnvoller ist, Städte, die jetzt schon eine höhere knotendichte haben rauszunehmen.
Und dann muss man natürlich auch klären, wie man sowas finanziert bekommt…
aus Neugierde: Wie genau sieht das aus?
Wie schon oben geschrieben finde ich das Modell einzelne Städte herauszunehmen gut. Jedoch ist es imho die Entscheidung der WML Community, wie sie aufteilen wollen.
Ist mir doch egal. Ich kenne mich dort nicht aus, habe die daher erstmal so genannt.
Jap, Grundlage sollte schon der IST-Zustand sein. Aber auch dort ist WML schon so groß, dass man mit Überlegungen beginnen sollte.
Die Frage ist, wie viel Traffic wir durch einen Host so schießen wollen. Ich denke spätestens nach dem nächsten Monat auf unserer „neuen“ Infrastruktur werden wir merken, dass wir für den ganzen Traffic noch etwas mehr Geld in die Hand nehmen müssen. Und dann kommen wir zur Frage: Machen wir Multi-Batman und zahlen dann extra für den Traffic. Oder mieten wir weitere Bleche und nutzen jeweils den Inklusiv-Traffic. Wir können uns natürlich jetzt vorwerfen lassen, dass wir auf Hoster setzen die keine volle Traffic-Flatrate anbieten, wir können dann aber auch gerne ausproieren, was passiert wenn wir bei einem Hoster mit Traffic-Flatrate sind und da ein paar Monate ordentlich was durchschieben. Entweder wir werden wieder zu irgendwelchen Urban-Legends, wie „Hoster xy drosselt wv-Pakete“ kommen oder wir werden rausgeworfen. Oder anders ausgedrückt: Meiner Meinung nach macht Multi-Batman Sinn, wenn wir in der derzeitigen Situation die Domänen einfach nur verkleinern wollen. Wenn wir das jedoch machen, um weiteres Wachstum zu verkraften, werden wir sehr schnell in die Traffic-Falle geraten.
Ja. Aber hier muss sich auch erst noch zeigen, ob das in der Praxis wirklich so funktioniert wie erdacht.
Ja, da bin ich optimistisch. Wir sollten nur noch mehr nach außen kommunizieren, dass die ganze Infrastruktur Geld kostet und das nicht irgendwo eine ominöse Wolke ist, die einfach da ist. Wenn wir von heute auf morgen sagen wir brauchen Geld, könnte das zu Unverständnis führen. Daher lieber die Leute jetzt schon für das Thema sensibilisieren.
@d00: Das Aachener-Modell sieht es vor, dass jede lokale Wolke automatisch separiert wird. Jeder kann mit jedem meschen, aber erst wenn zwei Wolken über die Luft meschen, werden sie auch am Gateway zusammen geschaltet.
Die Aachener bauen das gerade. Das ist dann defacto das Ende des Layer2-Netzes und funktioniert in der Theorie bis zu Wolkengrößen von 250-300 Knoten.
Ob die Flatrate bei MyLoc eine bleibt, werden wir denke ich schnell auf Greyworm merken. Da müsste ungefähr fast genauso viel durchgehen, wie durch Remü. @kgbvax, kannst du mal Statistiken zu dem Blech veröffentlichen?
Naja, ich habe das anders verstanden. Nicht JEDE Wolke wird separiert respektive bekommt ein eigenes Netz. Vielmehr gibt es dort eine Aufteilung ganz ähnlich wie bei uns. Der entscheidende Unterschied ist, dass die nicht für jede Domäne eine eigene Firmware backen wollen, sondern die Zuweisung serverseitig lösen wollen. Das macht einen unterschied von > 1000 Segmenten zu einigen Dutzend (am Anfang einem Dutzend) Segmenten.
Also im Grunde findet die Entscheidung immer noch aufgrund der Positionsdaten der Knoten statt. Jedoch macht es der Automatismus möglich Planquadratepolygone nach technischen Gegebenheiten zu wählen und man muss nicht darauf achten, dass die Unterteilungen für Außenstehende Sinn ergeben (so wie bei uns → Kreis- & Stadtgrenzen). Mit hin und her schalten ist gemeint, dass ein Knoten, der nach seinen Positionsdaten eigentlich in ein Segment A gehört, aber mit Nodes aus Segment B mesht nach Segment B verschoben wird. Bei der Segmentierung sind nur VPN-Nodes relevant, weil alle Nodes mit Allen meshen können. Und solange alle VPN-„Erdungen“ einer lokalen Wolke im selben Segment sind, geht alles gut. Also bilden die Knoten einer lokalen Wolke kein eigenes Segment, sondern SIND (mit anderen) in einem Segment. Genau das (also lokale Meshwolke hat einer stärkere Bindung als die Geo-Position) findet im Übrigen in unserem Migrationsscript auch schon Berücksichtigung.
Das ist für mich jedoch nur eine (in der Umsetzung natürlich nicht zu vernachlässigende) Randnotiz. Wesentlich ist halt, dass deren Infrastruktur wohl ganz ähnlich (von layer2 segmentation sind die abgerückt und machen jetzt auch layer3 routing) wie unsere Aufgebaut ist, „nur“ dass deren Black-&White-Listing ein „bisschen“ Magie enthält, dafür aber nur eine Firmware ausgeliefert werden muss.
Nachdem ich bei dem zuvor berichteten eher skeptisch war, bin ich jetzt sehr angetan von dieser Lösung. Ich bin dafür, dass wir ebenfalls in dieses Experiment einsteigen. Ich denke da können sich gute Synergien ergeben. Das ein oder andere haben wir ja auch schon gelernt in Bezug auf Routing und Systeme mit mehr als einer Handvoll VMs zu fahren. 
Falls dieser Kurswechselkorrektur auf breite Ablehnung stoßen sollte, bliebe uns noch die Möglichkeit die Firmwaremigration weiter zu automatisieren. Ich denke, dass wir nun ausreichend Erfahrungen gesammelt haben um den Vorgang nahezu automatisch ablaufen zu lassen. Es würde sicherlich ein paar weitere Zeilen Code benötigen, aber sich im Rahmen des Machbaren bewegen. Jedoch zieht diese Vorgehensweise einen ganzen Rattenschwanz negativen Aspekten hinter sich her; es muss diverse Firmware gebaut werden;es muss Firmware getestet werden;es muss Firmware signiert werden;der Knotenbetreiber muss herausfinden, welche Firmware er braucht…
Meine Idee wäre, das in einer Domäne, die zeitnah unterteilt werden soll zu testen. Also natürlich nur mit ausgewählten Knoten.
Au ja! Das probiere ich auch mal: einfach anhand der mac Adresse des Knoten entscheiden, dass der in eine andere Wolke kommt. Kann man anfangs ja statisch machen. Muss dafür aber den DHCP Server für jede Wolke einen Range geben. Das wird bestimmt lustig!