Ansible-Konfiguration weiterentwickeln

Technik Ansible
1

Moin @FanLin, @Parad0x, @kgbvax, @void, @Fungur, @descilla, @paulinsche,

ich möchte hier mal eine Diskussion zur Weiterentwicklung unserer Ansible-Konfiguration machen.

I) Es zeichnet sich irgendwie ab, dass es nicht schlecht wäre, die Multi-Domänen-Batman-L2TP-Gateways noch um eine Backbonefunktionalität zu erweitern, sodass wir quasi alles innerhalb einer VM machen könnten, um z. B. die Kiste von @kgbvax zu unterstützen.

Dazu würde ich folgende Struktur vorschlagen:

  • Pro Host gibt es Variablen ist_backbone und ist_gateway, die unabhängig voneinander gesetzt werden können.
  • Dazu müssten die bird-Rollen zusammengeführt werden und jeweils mit If-Anweisungen gearbeitet werden.
  • Die Batman-, DHCP- etc. -Rollen würden dann nur noch ausgeführt, falls ist_gateway wahr ist.

II) Mehrkern-Systeme. @kgbvax hatte uns hier rausgesucht, dass man Batman wohl irgendwie auf eine CPU festnageln kann und es dann keine Panikattacken mehr bekommt.

Dann können wir die Virtualisierung auch noch anzünden, weil man es nativ auf einem Mehrkernsystem laufen lassen könnte und auf dem Host von Ingomar Gas geben. Allgemein würde unser Konzept deutlich schlanker. Virtualisierung würde dadurch nicht ausgeschlossen, wir werden aber deutlich flexibler bei der Auswahl der Hostingangebote und sind z. B. nicht mehr auf mehrere IPV4-Adressen angewiesen.

Meinungen erwünscht.

Als Testmaschine würde sich da die von Ingomar anbieten. Der FFRL wäre bestimmt so lieb, dort Tunnel hinzuschalten.

Grüße
Matthias

2

Ich denke I) lässt sich so umsetzen, wobei ich evtl. keine neuen Variablen einführen, sondern die bestehenden Variablen nutzen würde, die die Tunnel zum FFRL (ffrl_tun) bzw. die konfigurierten Domänen (domaenenliste) definieren:

Kein Tunnel, aber Domänen: normales Gateway
FFRL Tunnel, aber keine Domänen: Backbone
FFRL Tunnel und Domänen: Gateway mit Direktanbindung an FFRL

Bei II) ist die Lösung von @kgbvax aber sehr radikal: Es wird vom ganzen System nur eine CPU benutzt. Das ist nicht auf Batman beschränkt.

1 „Gefällt mir“
3

Das mit den Variablen finde ich super. Bzgl. der Tunnel müssen wir eh noch mal ran, siehe Issue #26 und #29.

Okay, das das für alles gilt, war mir nicht klar, ist aber auch nicht schlimm, weil wir keine CPU-Leistung brauchen.

4

Ich hatte mit kvm nie Probleme mit batman und mehr-Kern in einer vm, solange ich aufgepasst habe, das keine interfaces ständig ins batman kommen/gehen. Was habe ich verpasst?

Im übrigen bin ich für eine möglichst starke Dezentralisierung.

2 „Gefällt mir“
5

Die Trennung zwischen den Backbone und den Gateways wurde ursprünglich bewusst eingeführt um eine klare klare Trennung zwischen den Zuständigkeiten bzw. Aufgaben der einzelnen Server zu erzeugen.

Insbesondere die Backbone-Maschinen sollten hier so schlank wie möglich ausgelegt sein und explizit nicht teil der Batman Netze sein da wir ja immer wieder Stabilitätsprobleme mit dem Kernelmodul hatten.

Noch wichtiger ist hier jedoch der Punkt, dass die Bantman Version der einzelnen Domänen trennbar bleibt.
Auch wenn die Entwicklung von Batman mittlerweile so ausgelegt ist, dass es in absehbarer Zeit keine inkompatiblen Versionssprünge mehr gibt können wir uns nicht darauf verlassen.
Egal ob gewollt (weil doch noch notwendige inkompatible Änderungen zusammenkommen) oder ungewoll (weil durch Fehler oder unbeabsichtigt verursacht) wird es früher oder später sicher zu der Situation kommen dass wird zwischenzeitlich Domänen mit inkompatiblem Batman wersionen haben werden. Ohne eine saubere Trennung auf Backbone Ebene laufen wir dann möglicherwise auf Probleme.

Ich bin daher klar dafür die Backbone-Ebene beizubehalten und nicht mit der Gateway Ebene zu vermischen.

Auf ebene der Gatways die Server zusammenzulegen um die verfügbaren Ressourcen besser auszulasten ist gut.
Hier steckt entsprechend potential um die Verfügbaren Ressourcen besser auszulasten.

Entsprechende Dezentralisierung und Verteilung ist allerdings immer noch wichtig und sollte dadurch nicht entfallen. Schließlich müssen wir immer damit rechnen dass einzelne Maschinen aufgrund des hohen Traffics vom Netz genommen werden. Der Impact sollte hierbei möglichst gering sein.

2 „Gefällt mir“
6

Radikal ja, aber besser ein stabiler Host mit einem Kern als ein instabiler mit mehreren.

1 „Gefällt mir“
7

Wir haben nicht vor, die derzeitigen Backbone-Rechner aufzugeben, sondern ggf. Gateway-Rechner direkt ans FFRL anzubinden, die dann aber nicht für andere Gateways die Backbone-Rolle übernehmen. D.h. man könnte so einem Gateway genausogut wie bislang eine neue Batman-Version geben.

Wir sparen uns damit aber einen Hop durchs internet, was besonders für Gateways, die nicht im gleichen Rechenzentrum wie unsere Backbone-Rechner stehen, Zeit und Geld sparen würde.

Der einzige Nachteil, den ich sehe, ist der erhöhte Aufwand beim FFRL (bzw. Kommunikation mit FFRL), weil die uns die Tunnel schalten müssen. Laut Matthias ist das aber kein Problem. Er hat ja diese Woche schon einen neuen Backbone-Rechner eingerichtet.

1 „Gefällt mir“
8

Wir haben das getrennt, weil wir es uns routingtechnisch nicht zugetraut haben, alles auf eines zu schmeißen. Jetzt können wir das.

Betonung liegt auf hatten, Systeme laufen absolut stabil. Fanlin ist auf Grund eines Hardwaredefektes ausgefallen.

Und diese Trennung ist gerade genau das Problem. Wir routen auf Greyworm zwischen den VMs über einen Router von MyLoc. Das ist einfach Käse. Wir routen teilweise von Commander zu Greyworm einfach nur, weil das schneller ist.

Bleibt ist falsch, ist derzeit auch nicht gegeben. Die Batmanversion der einzelnen Domänen muss schon jetzt identisch sein, da wir z. B. auf Remü-08 (eine VM, nicht das Blech) die Domänen 07 bis 12 fahren, also sechs Stück. Die müssen alle identisch sein.

Was auch überhaupt kein Problem ist. Wie ich oben geschrieben hatte, will ich, dass eine VM als Gateway, als Backbone oder als beides konfiguriert werden kann. Wir können nach wie vor dann VMs als reine Gateways mit anderen Batmanversionen anflanschen.

Ich möchte nochmal darauf hinweisen, dass die Anzahl an Tunneln für IPv4 auf acht begrenzt ist. Wir haben derzeit 12 Nat-IPs, davon müssen wir aber einen /30-Block zurückgeben.

Ich möchte einfach die Flexibilität erhöhen, um, wie oben geschrieben, den Server von @kgbvax vernünftig nutzen zu können. Dieser kann keine weitere IP bekommen und somit muss alles auf eines. Ob wir das bei Hetzner genauso machen, wird die Praxis zeigen, aber dafür ist es erstmal nicht geplant.

Was keinen Sinn macht, sind auf den Server bei Scaleway nur Gateways zu schmeißen. Dann bezahlen wir doppelt. Einmal am Backbone rüber zu Scaleway und dann dort nochmal zu den Knoten raus.

9

Übrigens ist “Die Lösung von @kgbvax” nicht das auf einen Core zu beschränken. Das finde ich einen gruseligen Workaround.
Was ich eher meinte ist das Statement der Wuppertaler das es wohl nicht crashed wenn man keine Bridge verwendet.

10

Hmm, für l2tp brauchen wir aber eine Bridge, da batman abschmiert, wenn man oft Interfaces entfernt, was bei l2tp der Fall ist. Aber in unserem Szenario ist die Bridge in Batman eingebunden und nicht umgekehrt.

Wahrscheinlich müssen wir doch mal selbst einen Test machen, um festzustellen, was jetzt stabil ist und was nicht.

11

@kgbvax: Wenn das hier noch aktuell ist, verwenden die Fastd. Unsere Fastd-Systeme haben auch keine Brücke.

Für L2TP braucht man das, weil jede einzelne Verbindung ein eigenes Interface ist. Jedes mal, wenn ein Interface aus Batman entfernt wird, gibt es eine kleine Wahrscheinlichkeit, dass das System crasht. Fastd wird quasi im normalen Betrieb nie ein Interface aus Batman entfernt, weil Fastd alle Verbindungen in einem Interface zusammen fasst. Mit L2TP aber jedes mal, wenn ein Knoten getrennt wird. Insbesondere nachts, wenn die ganzen Zwangstrennungen stattfinden, hängt sich das System regelmäßig weg. Das kann man mit der Bridge umgehen.

Daher haben wir für L2TP die Bridge wieder eingeführt.

Grüße
Matthias

12

@MPW: wir hatten früher eine Bridge in der Batman eingebunden war. Jetzt mit l2tp benutzen wir eine Bridge, die in Batman eingebunden ist. Kann ein signifikanter Unterschied sein.

13

Das ist nicht nur ein Unterschied, sondern sogar was ganz anderes…

14

Das soll aber beides funktionieren. Wir haben das ziemlich zufällig gewählt. Dass es was anderes ist, ist klar. Eine der beiden Lösungen mit Brücke funktioniert, ohne ist es nicht stabil.

Grüße
Matthias

15

@Fungur und ich haben heute eine neue bird-Rolle angefangen, die dann für Backbones, Gateways und Backways (also Backbone und Gateway in einem) funktionieren soll. Davon ist die bird-v4-Vorlage soweit fertig und kann getestet werden.

Grüße
Matthias

16

Der Grund war die bewusste Trennung er Server, nicht die Tatsache das richtig zu routen.
Warm die damals bewusst eingeführte Trennung ausgelöst werden soll begründest du hiermit nicht.

Das ist schon klar.
Wir können aber auf den Domänen, die nicht auf einer VM gefahren werden die Versionen unterschiedlich halten.

Wenn eine Versionsbedingte Trennung notwendig werden sollte geht das jetzt schon nicht so einfach.
Auch die Service-VM, de aktuell in allen netzen hängt blockiert das ganze zusätzlich.

Durch eine stärkere Vermischung von Backbone/Gateway erschweren wir das ganze dann noch und nehmen uns ein erhebliches stück an Flexibilität.

Das das routimg zwischen den VMs suboptimal gelöst ist hat hiermit nichts zu tun.

17

Ich will das eigentlich gar nicht ausdiskutieren, aber kurz zwei Punkte:

Wir schränken die Flexibilität bzgl. der Batmanversionen nicht weiter ein. Nach wie vor könnte man auf verschiedenen VMs verschiedene Versionen laufen lassen.

Wir wollen die Flexibilität gerade erhöhen und Ansible als Baukastensystem nutzen. Man kann dann auf eine VM Backbone konfigurieren, oder ein Gateway - das geschieht alleine durch die gesetzten Variablen pro Host. Und es geht dann eben auch beides.

Derzeit haben wir drei bird-Rollen. In Zukunft haben wir dann nur noch eine die mit if-Anweisungen in der Vorlage arbeitet.

Das alles erhöht die Flexibilität deutlich. Dort, wo es nicht erforderlich ist, können wir weiterhin Backbones und Gateways trennen. Und dort wo es nicht geht, weil wir z. B. nur eine IP haben, können wir dann alles auf eines schmeißen.

Wir bauen das jetzt erstmal um und gucken dann, ob es sich bewährt. Dann können wir weiter sehen. Ist eh noch viel Arbeit bis es fertig ist.

Grüße
Matthias

1 „Gefällt mir“
18

Die hier vorgestellte Strukturänderung ist so umgesetzt. Über die gateways.yml wird nun auch eine FFRL-Anbindung realisiert, wenn diese in der host_vars-Datei festgelegt ist. Ansonsten werden die entsprechenden Rollen übersprungen.

Derzeit läuft die Konfiguration als Backway so auf dem Parad0x-Gateway und wenn Barristan die FFRL-Anbindung bekommt, wird es dort ebenfalls so umgesetzt.

19

Dieses Thema ist nun geschlossen. Es ist nicht länger möglich, auf dieses Thema zu antworten.