Ceph Netzwerk Routing

[Haithabu84]

Hallo,

ich habe ein Problem und komme hier irgendwie nicht weiter. Vermutlich ist das Problem relativ einfach zu lösen, aber ich komme nicht drauf... sehe den Wald vermutlich vor lauter Bäumen nicht.

Mein Ceph Netzwerk ist ein Routed Mesh mit 3 Nodes.

Die Nodes haben folgende Adressen:

Node A 10.10.10.10
Node B 10.10.10.11
Node C 10.10.10.12

Wenn ich jetzt stur nach Wiki vorgehe, dann braucht nur der Link zu Node C ausfallen und viele PGs sind degraded. Jetzt habe ich gelesen das es möglich wäre, im Fall der Fälle über den z.B. von Node A über Node B zu Node C zu kommen. Genauso will ich von Node B zu Node C über Node A kommen, sollte der direkte Link ausfallen.... usw. usf.

Bin dann wie hier beschrieben vorgegangen:

https://forum.proxmox.com/threads/ceph-in-mesh-network-fault-tolerance.56764/post-261587

Aber das funktioniert nicht. Nach deaktivieren des direkten Links, versucht er eine Route über das Standard-Gateway zu finden.

Hier mal eine Beispiel-Config von Node A:

auto enp197s0f0np0

iface enp197s0f0np0 inet static

        address 10.10.10.10/32

        up ip route add 10.10.10.12/32 dev enp197s0f0np0

        up ip route add 10.10.10.11/32 nexthop via  dev enp197s0f0np0 weight 10

        down ip route del 10.10.10.12/32 dev enp197s0f0np0

        down ip route del 10.10.10.11/32 dev enp197s0f0np0

        mtu 9000


auto enp197s0f1np1

iface enp197s0f1np1 inet static

        address 10.10.10.10/32

        up ip route add 10.10.10.11/32 dev enp197s0f1np1

        up ip route add 10.10.10.12/32 nexthop dev enp197s0f1np1 weight 10

        down ip route del 10.10.10.11/32 dev enp197s0f1np1

        down ip route del 10.10.10.12/32 dev enp197s0f1np1

        mtu 9000

IP Forwarding habe ich bereits aktiviert. Bringt aber auch nichts.

Hat sowas jemand schonmal zu laufen bekommen? Was mache ich falsch?

Gruß

 

[jsterr]

Ich setze hier mal ein "Watch" auf den Post. Etwas Offtopic aber ich möchte gerne ergänzen:

Einfach wären 4 Ports im 3 Node System mit Meshed Round Robin (geht auch und toleriert Kabel-Fehler). Wir haben gemerkt dass je nach "Konstellation" eventuell sogar das ganze Ceph nicht mehr funktioniert wenn ein einzelner Link ausfällt, da das Ceph MON Quorum zwischen den restlichen Servern flapped. Kommt nicht oft vor, hatten wir aber schon. Die Frage ist auch wie wahrscheinlich sind Kabel-Ausfälle bei DAC bei Enterprise Systemen - und selbst einen Serverausfall verkraftet ja so ein 3 Node Setup ohne Probleme, dafür ist es ja da?

 

[aaron]

Die Variante aus dem Thread war mir selber noch nicht bekannt. Ich glaub auch, da brauchts noch ein wenig mehr. Zum Beispiel IP forwarding, damit die Node in der Mitte die Pakete weiterleitet. Aber das werde ich dann wohl mal im Lab nachstellen und wenn ich da eine Variante finde die gut klappt, das in der Wiki entsprechend dokumentieren.

Ansonsten gibt es im Moment im Full Mesh PVE Wiki Artikel die Variante mit RSTP, die den Ausfall eines beliebigen Links zwischen den Nodes gut verkraften sollte.

 

[Haithabu84]

Ich setze hier mal ein "Watch" auf den Post. Etwas Offtopic aber ich möchte gerne ergänzen:

Einfach wären 4 Ports im 3 Node System mit Meshed Round Robin (geht auch und toleriert Kabel-Fehler). Wir haben gemerkt dass je nach "Konstellation" eventuell sogar das ganze Ceph nicht mehr funktioniert wenn ein einzelner Link ausfällt, da das Ceph MON Quorum zwischen den restlichen Servern flapped. Kommt nicht oft vor, hatten wir aber schon. Die Frage ist auch wie wahrscheinlich sind Kabel-Ausfälle bei DAC bei Enterprise Systemen - und selbst einen Serverausfall verkraftet ja so ein 3 Node Setup ohne Probleme, dafür ist es ja da?

Doppelte ausgeführte Kabel und Schnittstellen treiben natürlich die Kosten hoch.

Der erwähnte Fall mit der Konstellation das ein Link ausfällt und das ganze Ceph nicht mehr funktioniert, hatte ich erst vor kurzem und deshalb suche ich dringend nach einer Lösung.

RSTP Loop ist leider nicht wirklich eine, weil die Wahl auf Routing fiel wegen der besseren Performance. Bei Broadcast und eben RSTP Loop hat man teilweise bis zu 20% Performance-Einbußen. In bestimmten Situationen sogar mehr.

Deshalb wäre es genial wenn das irgendwie mit dem Routing lösbar wäre.

 

[Falk R.]

Ich finde das auch interessant, aber Redundanz ist nicht wirklich teuer. Eine 25GBit DP NIC bekommst du für 235€ und ein DAC für knapp 30€ Brutto.
Zuhause habe ich nur 10 GBit um die Kosten im Rahmen zu halten aber für den Speed und Flexibilität lasse ich es lieber über einen Switch laufen. Ich glaube Max Performance hast du nur geswitcht.

 

[kokel]

Wenn es sich um ein wirklich wichtiges Produktiv-System handelt geht meiner Meinung nach nichts an Redundanten NICs sowie Redundanten Switches vorbei. Ich finde diese Mesh-Setups nicht für den Produktiv-Betrieb geeignet. Vorteile mit Switches:

• redundante Links, können im Besten Fall mit LACP gebündelt werden
• Kein Link-Verlust an den verbleibenden Nodes, wenn ein Node durchbootet
• Spätestens wenn ein weiterer Node hinzukommt kommt man in Skalierungsprobleme
• Keine Mehrbelastung des Hop-Nodes aufgrund des Traffics.

 

[Haithabu84]

@SkyDiver79 und @kokel

Mein Setup hat als Backbone für das Ceph-Cluster 100Gbit. Dafür gibt es derzeit keine Geräte die vertretbare Kosten für eine Anschaffung rechtfertigen würden.

Eine weitere Skalierung ist nicht geplant, weil wenn man in drei Nodes soviel Leistung hat, wie man es derzeit überall zu kaufen bekommt... dann braucht man keine weiteren Nodes. Macht wirtschaftlich keinen Sinn.

Des weiteren: Ein Setup mit Switch wäre wieder ein SPoF, also müsste man wieder redundant ausführen. Doppelte Kosten... bei 100Gbit wohlgemerkt. Total überflüssig.

Wenn man sowieso plant, dass man irgendwann skaliert, dann mag das gehen was ihr schreibt. Aber für mein Setup, mittelständische Firma, macht es in den nächsten 5 Jahre keinen Sinn. Die drei Nodes im Mesh Network, sind von CPU/RAM/Festspeicher soweit skaliert, das auch bei konservativer Schätzung an keine Leistungsgrenze stoßen werden. Sollte es irgendwann, dennoch dazu kommen (da sprechen wir von frühstens in zwei Jahren), dann wird sowieso wieder komplett neu angeschafft.

Kurz gesagt: Redundanz bei 100Gbit ist absurd teuer und macht keinen Sinn, wenn es andere Wege gibt. Ich vermute auch das das Problem beim Routing marginal ist, wäre halt absolut brauchbar wenn es funktioniert. Sollte es das nicht, dann muss ich halt mit den vorhandenen Lösung vorlieb nehmen.

 

[Falk R.]

Naja ich gebe dir da nur fast recht. Ja du brauchst zwei Switches, aber da du nicht großartig skalieren willst würde ein einfaches Modell mit 100GBit Uplink Ports ausreichen. Bei dem Modell hättest du dann auch genügend 10GBit ports für das restliche Netzwerk: https://www.fs.com/de/products/115385.html
Ich glaube ein Mittelständiges Unternehmen kann sich zwei davon leisten.
Für die etwas größeren Umgebungen nehme ich lieber den großen Bruder mit 25GBit Ports, nur der ist leider schlechter verfügbar.

 

[Haithabu84]

Naja ich gebe dir da nur fast recht. Ja du brauchst zwei Switches, aber da du nicht großartig skalieren willst würde ein einfaches Modell mit 100GBit Uplink Ports ausreichen. Bei dem Modell hättest du dann auch genügend 10GBit ports für das restliche Netzwerk: https://www.fs.com/de/products/115385.html
Ich glaube ein Mittelständiges Unternehmen kann sich zwei davon leisten.
Für die etwas größeren Umgebungen nehme ich lieber den großen Bruder mit 25GBit Ports, nur der ist leider schlechter verfügbar.

Das mag ja alles gut und schön sein, aber wenn man ein Budget bekommt und dann sollen bestimmte Anforderungen alleine beim Cluster erfüllt sein, dann bleibt zumindest in meinem Fall nicht viel übrig. Im Endeffekt hat es dann für paar ordentlich Switche nicht mehr gereicht und es wurde auch nicht als nötig erachtet.

Deshalb wäre es weiterhin für mich ein absoluter Gewinn, wenn das mit dem Routing redundant funktionieren würde.

 

[Falk R.]

Da die Server schon beschafft sind ist es etwas zu spät.
Aber wenn man den CPU Overhead des Routings abzieht, der bei 100GBit schon einiges ausmacht, hätte man kleinere CPUs und dafür Switches planen können. Eventuell beim nächsten mal.

 

[Haithabu84]

Zusammen mit einem Kollegen habe ich nun eine Lösung gefunden... das war ganz schön knifflig:

Die Lösung aus meinem geposteten Link mit "weight" bewirkt keine Gewichtung, nachdem Motto "Wer niedriger ist, wird als priviligiert angesehen und verwendet" sondern beeinflusst den Usage. Beispiel: Bei einem Hop weight 5 und bei einem anderen 10, wird 1/3 des Traffics über den ersteren gesendet und der Rest über den anderen.

Das bringt mir bei meinem Problem nichts. Besser gesagt: Funktioniert auch nicht.

Allerdings funktioniert es mit ganz normaler Metrik. Also Option von "ip route" + "metric 100".

Beispiel:

auto enp197s0f0np0
iface enp197s0f0np0 inet static
        address 10.10.10.10/24
        pre-up /sbin/ethtool -G enp197s0f0np0 rx 8192 tx 8192
        up ip route add 10.10.10.12 dev enp197s0f0np0
        up ip route add 10.10.10.11 via 10.10.10.12 dev enp197s0f0np0 metric 100
        mtu 9000

auto enp197s0f1np1
iface enp197s0f1np1 inet static
        address 10.10.10.10/24
        pre-up /sbin/ethtool -G enp197s0f1np1 rx 8192 tx 8192
        up ip route add 10.10.10.11 dev enp197s0f1np1
        up ip route add 10.10.10.12 via 10.10.10.11 dev enp197s0f1np1 metric 100
        mtu 9000

Wichtig: Die Adresse auf dem einzelnen Interface braucht die Subnetz-Maske vom gesamten Netz! In diesem Fall die /24 statt der /32 (wie es im Wiki z.B. steht)

Wichtig: IP-Forwarding muss aktiv sein!

Es gibt noch kleines weiteres Problem. Ich habe zum Beispiel das so getestet, das ich die Schnittstelle die den direkten Link darstellt, mit ifdown deaktiviert habe. Dann wird dem Kernel auch der State "Down" präsentiert. Aber auf der Gegenstelle bleibt dieser, je nach verwendeter Optik/DAC (aktiv), weiterhin im State "UP". Die Pakete kommen zwar nun über den "Mitteleren Node", aber die Antworten versucht der Empfänger weiterhin über den "toten" Link zu senden.

Dies kann man aber mit ein wenig Scripting lösen.

Insgesamt kann ich sagen das es nach ersten Erkenntnissen sehr gut funktioniert. Die Latenz erhöht sich zwar um knapp 30%... aber besser einen Link, als überhaupt keinen.

Mich würde es sehr freuen wenn @aaron diese Variante verifizieren könnte und dann eventuell mit ins Wiki überträgt.

Gruß

 

[Falk R.]

Hi, wenn ihr eh schon einen großen Aufwand betreibt, nehmt lieber OSPF.
Da können alle Pfade online bleiben, kostet halt nur mehr CPU. Ist dafür aber robuster.

 

[Haithabu84]

Naja, OSPF ist ne ganze Ecke mehr. Zumal man somit wieder zusätzliche Software nachinstallieren und pflegen muss. Der hier gezeigte Weg wird hauptsächlich in der /etc/network/interfaces konfiguriert. Der zusätzliche Weg mit dem Script, sind wir auch nur gegangen, weil wir aktive Kabel verwenden und selbst dann benötigt man in der Minimal-Ausführung einen 5-Zeiler in einem Bash-Script. Deutlich überschaubarer. Zumindest für mich.

OSPF wäre jetzt schon wieder bisschen Overkill.

 

[Falk R.]

Ich finde den Aufwand den ospfd Deamon zu installieren und eine Konfigdatei anpassen nicht so groß.
Hab das aber bisher noch nicht gemacht. Ich bin aber immer dafür bewährte Protokolle statt Scripte zu nutzen.
Mit OSPF müsste die Latenz auch wieder runter gehen.

 

[mvs]

OpenFabric (abgespeckte Version von IS-IS Protokol) würde hier besser passen als OSPF.
IS-IS läuft direkt auf L2, man braucht also keine /30 Netze für P2P Links zu definieren. Die Zuordnung IP <-> NIC entfällt. Die physische Topologie wird automatisch ermittelt.

Die FRRouter Konfiguration sieht dann wie folgt aus:

/etc/frr/daemons
bfdd=yes
fabricd=yes
...

/etc/frr/frr.conf
Node1

frr version 8.0.1
frr defaults traditional
hostname pve01
log syslog informational
ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface lo
 ip address 10.0.0.1/32
 ip router openfabric 1
 openfabric passive
!
interface ens19
 ip router openfabric 1
 openfabric csnp-interval 2
 openfabric hello-interval 1
 openfabric hello-multiplier 2
!
interface ens20
 ip router openfabric 1
 openfabric csnp-interval 2
 openfabric hello-interval 1
 openfabric hello-multiplier 2
!
line vty
!
router openfabric 1
 net 49.0001.1111.1111.1111.00
 lsp-gen-interval 1
 max-lsp-lifetime 600
 lsp-refresh-interval 180
!

Node2

frr version 8.0.1
frr defaults traditional
hostname pve02
log syslog informational
ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface lo
 ip address 10.0.0.2/32
 ip router openfabric 1
 openfabric passive
!
interface ens19
 ip router openfabric 1
 openfabric csnp-interval 2
 openfabric hello-interval 1
 openfabric hello-multiplier 2
!
interface ens20
 ip router openfabric 1
 openfabric csnp-interval 2
 openfabric hello-interval 1
 openfabric hello-multiplier 2
!
line vty
!
router openfabric 1
 net 49.0001.2222.2222.2222.00
 lsp-gen-interval 1
 max-lsp-lifetime 600
 lsp-refresh-interval 180
!

Node2

frr version 8.0.1
frr defaults traditional
hostname pve03
log syslog informational
ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface lo
 ip address 10.0.0.3/32
 ip router openfabric 1
 openfabric passive
!
interface ens19
 ip router openfabric 1
 openfabric csnp-interval 2
 openfabric hello-interval 1
 openfabric hello-multiplier 2
!
interface ens20
 ip router openfabric 1
 openfabric csnp-interval 2
 openfabric hello-interval 1
 openfabric hello-multiplier 2
!
line vty
!
router openfabric 1
 net 49.0001.3333.3333.3333.00
 lsp-gen-interval 1
 max-lsp-lifetime 600
 lsp-refresh-interval 180
!

PS Die Timings sind reduziert um die Konvergenzzeit zu verringern.

 

[Falk R.]

Klingt auch interessant, so wie es aussieht wird dadurch auch die CPU geschont.

 

[aaron]

OpenFabric (abgespeckte Version von IS-IS Protokol) würde hier besser passen als OSPF.

Danke für den Hinweis!

Schaut tatsächlich sehr interessant aus. OSPF habe ich bisher nicht in Erwägung gezogen, da man dabei AFAIK zwischen den Nodes jeweils unterschiedliche Subnetze braucht.