Moin,
mir sind im Zuge der Entwicklung von Klassenorientierten puppet-Modulen ein guter und ein schlechter Punkt aufgefallen:
Der Gute: Ein Server kann mehrere Hoods parallel verwalten. Folglich können wir auch kleinere Hoods schaffen ohne Geld für Server mit viel zu viel Power zu verschwenden.
Klingt sehr gut :)
Der Schlechte: Mehrere Server pro Hood sind Mist. Die Server pflegen ein Full-Mesh (via tunnel) um das AS-interne Routing sicher zu stellen. Wenn zwei Server für eine Hood zuständig sind, sollten diese Server mit batman verbunden sein; ansonsten läuft man Gefahr, dass ein Teil des eigenen Subnetzes nicht erreichbar ist. Diese Verbindung kann zustande kommen indem man das batman-Interface der jeweiligen Hood mit dem Tunnel-Interface zum zweiten Server bridged. D. h. der Tunnel ist für das batman-Geraffel einer bestimmten Hood reserviert (ansonsten besteht die Gefahr zwei Hoods zu verbinden). Lösen könnte man das in dem man pro Hood eine VLAN ID darüberlegt und so an beiden Enden die Daten aus dem Tunnel auf die verschiedenen Hoods sortieren kann. Alternativ baut man für das batman-Geraffel pro Hood jeweils eigene Tunnel zum zweiten Server auf, was zusätzlichen Overhead mitbringt.
Ich halte Redundante Server für hoods schon für Wichtig um eben Ausfall Sicherheit vorzubeugen. Es ist in der neuen batman Version ist das VLAN problem behoben das könnten wir nutzen. Andernfalls müsste es auch möglich sein die Supernodes via fastd verbinden zu lassen und darüber den batman traffic pustet. Die Komplexität steigt dadurch zwar stark an allerdings gibt es auch einen single point of Failure weniger. Die Supernodes könnten trotzdem jeweils über Layer 3 mit den andern Supernodes verbunden sein. Es sollte ja kein Problem darstellen mehrere default Adressen zu announcen.
Außerdem habe ich Bauchschmerzen damit batman-Geraffel auf Inter-Server Verbindungen zu haben. batman schafft die Flexibilität einen Router einfach irgendwo mit ins Netz schmeißen zu können. Die Server sind aber wohl definierte Punkte des Netzes, weshalb batman Verbindungen zwischen diesen eigentlich überflüssig sind.
Folglich: Kann man zwar machen, ist aber halt kacke!
Die Problematik liegt in Batman selbst. Besteht diese Layer 2 Verbindung zwischen den Gateways nicht so entsteht Chaos im Routing und die DSL Anschlüsse werden dicht gemacht zudem fangend die Supernodes an sich gegenseitig mit ihrer vollen Anbindung zu DDosen. Das hatten bjo und ich Letztes ja bereits versucht. Dabei sind die Firewalls von Bytemine abgeraucht. War nicht soo cool :D
Mein Vorschlag: Ein Server pro Hood.
Den Nachteil der fehlenden Redundanz kann man ausgleichen, indem die Router wissen wo sie sich hin verbinden sollen, wenn ihr einziger Server ausfällt (sozusagen eine Backup-Hood).
Das führt dazu das wir relativ kleine Hoods haben werden geografisch betrachtet. Pro Server sollten maximal 150 VPN peers bestehen da fastd im userland läuft und auch nur auf singelcore. Es würde bedeuten das deutlich mehr Richtfunkstrecken Statisch eingerichtet werden müssten. Da die hood grenzen in Osnabrück z.B. nichtmal die ganze Stadt bedecken würden.
Alternativ (meine Präferenz) könnten sich die VPN Router bei Ausfall zufällig an irgendeine vorhandene Hood dranhängen, dann hätten wir bei Ausfall eines Servers keine punktuelle Mehrbelastung einer bestimmten anderen Hood. In einem bestimmten Intervall (z. B. Täglich) könnten die Router das Vorhandensein ihrer eigenen Hood prüfen und ggf. dahin wechseln.
Hm ja das ginge auch bin mir nicht ganz sicher ob das eine gute Lösung wäre.
Das Neu-Verbinden stellt kein zusätzliches Problem dar, da die Router die mit dem ausfallenden Server verbunden sind sich ohnehin neu verbinden müssen. Ob sich die ganze Hood neu verbindet (weil die gesamte Hood an einem Server hängt) oder nur ein Teil der Hood betroffen ist, macht für das Netz keinen Unterschied.
Das sehe ich auch nicht als problematisch. Zumal die anzahl der peers pro Server begrenzt ist um eben zu verhindern das Server überlastet werden.
vg Tarek