Best practice bei Ceph und zwei Switches

herzkerl

herzkerl

Active Member
Mar 18, 2021
104
21
38
Hallo zusammen,

angenommen ich habe ein Cluster aus 5 Servern und nutze zwei Switche, die nicht ’stackable’ sind: Welche Netzwerkkonfiguration wäre hier ‚best practice‘? Ich habe einiges versucht im Testlab, hatte aber bisher keinen Erfolg.

Danke im Voraus!
 
Wie viele Ports und welche Geschwindigkeiten hast du denn?

Ich sag mal nur speziell was zu Corosync, denn da bietet sich was an:
Da der funktionierende Corosync für's Cluster absolut überlebenswichtig ist, könntest du über jeden Switch jeweils einen Corosync Ring konfigurieren.
So ist bei Ausfall eines Switches (oder einfach mal downtime wegen Updates) das Cluster weiterhin happy.
Zumindest die Ports eines Rings sollten von z.B.Storage-/Backuptraffic isoliert sein; bei Auslastung und zu hoher Latenz grätscht sich Corosync sonst ggfs. weg - der zweite Ring ist dann hoffentlich nicht gleichfalls ausgelastet^^

Mit genug freien Ports (z.B. ungenutzte Onboard 1Gbit) kann man so einen "sicheren" Ring0 bauen und z.B. über den Storage-/Usertraffic Trunkport als VLAN noch den Ring1 laufen lassen.

Hier sind passende Links: https://forum.proxmox.com/threads/adding-second-corosync-ring-best-practice.97996/
 
Wenn du keinen multicast-traffic haben wirst (CARP z.B.), kannst du mit openvswitch ein bond0 balance-slb (ohne LACP) darüber fahren.

Beide switche brauchen untereinander dann mind. 1 Kabel rüber und beide brauchen die gleichen vlans wie du als OVS IntPorts auf den nodes hast.
 
Es ist eine Weile her, aber nun ist endlich die Zeit da, das Thema nochmal anzugehen.

Mittlerweile sind es auch nur noch 3 Server, dennoch mit der gleichen Problematik: Unsere Switche sind nicht ‚stackable‘ – und folgendes soll erreicht werden:
• Alle drei Server sind mit beiden Switches verbunden (1x 10GBit/s für Ceph, 1x 10 GBit/s für Migration, 1x 10 GBit/s für VM-Netz)
• Sofern einer der beiden Switche ausfällt, sollen alle Dienste weiterhin laufen (es geht also nur um Verfügbarkeit/Redundanz)

@mr44er: Mit OVS hatte ich bisher noch nicht allzu viel zu tun, aber SLB ist mir ein Begriff. Wäre ‚balance-alb‘ beim ‚normalen‘ Linux Bond nicht damit gleichzusetzen?
 
Bei 3 Servern würde ich diese für ceph direkt verkabeln und Switches nur für extern verwenden, eine Fehlerquelle weniger ;)
 
herzkerl said:
Wäre ‚balance-alb‘ beim ‚normalen‘ Linux Bond nicht damit gleichzusetzen?
Click to expand...
Die kurze Antwort wäre ja, die lange Antwort mit einem aber und Details.

ubu said:
Bei 3 Servern würde ich diese für ceph direkt verkabeln und Switches nur für extern verwenden, eine Fehlerquelle weniger
Click to expand...
Ja, sehe ich auch so.
 
ubu said:
Bei 3 Servern würde ich diese für ceph direkt verkabeln und Switches nur für extern verwenden, eine Fehlerquelle weniger ;)
Click to expand...
Habe ich so tatsächlich gerade umgesetzt – nicht bei uns, bei einem Kunden – und das läuft (natürlich!) problemlos. Bei mehr als drei Servern wird es jedoch schnell teuer (weil man ja n-1 NICs je Server bräuchte)... Ich würde davon ausgehen, dass wir irgendwann dieses Jahr noch aufstocken werden, daher wäre mir die Alternative natürlich lieber :)
 
Du kannst einfach ein Active-Backup Bond machen. Das ist schon mal verfügbarer für Ceph.
Was für Switches hast du, dass die kein Stack können, sowas gibt es doch gar nicht mehr.
Eventuell können die ja MLAG, das wäre sogar verfügbarer als Stack.
 
  • Like
Reactions: ITT
Falk R. said:
Was für Switches hast du, dass die kein Stack können, sowas gibt es doch gar nicht mehr.
Eventuell können die ja MLAG, das wäre sogar verfügbarer als Stack.
Click to expand...
UniFi *hust* – es wird Zeit, dass die MLAG können...
 
Ich benutze dafür gern MikroTik und bei großen Clustern welche von FS.com
 
Falk R. said:
Du kannst einfach ein Active-Backup Bond machen. Das ist schon mal verfügbarer für Ceph.
Was für Switches hast du, dass die kein Stack können, sowas gibt es doch gar nicht mehr.
Eventuell können die ja MLAG, das wäre sogar verfügbarer als Stack.
Click to expand...
So machen wir das auch bei "kleinen" Clustern.
Active-Backup funktioniert hier verlässlich, sowohl VM-Traffic, Ceph, Corosync sowieso.
Hauptvorteil: Man ist gewissermaßen Switch-Funktionalitäts/Kompatibilitäts-unabhängig.
 
Wir haben bei uns ein ähnliches Setup. 5 Server, Ceph, 2 Switches die nicht gestacked sind.
Je Server 4x 25G. 2x für Ceph, 2x für VM-Traffic.

Aktuell läuft das Setup mit active-backup. Aber ich habe mich auch schon gefragt bzw. anfangs auch getestet, wie es mit balance-tlb und balance-alb läuft.
Mit den beiden letzteren hatte ich tatsächlich ein etwas merkwürdiges Verhalten. Bei "Lasttests" in einer VM mit dd, hat die Geschwindigkeit von Ceph spürbar geschwankt. Hat man bei der Auslastung der Interfaces und auch mit ceph -s deutlich gesehen. Erst beim Wechsel zurück auf active-backup hat sich alles wieder eingependelt und die Geschwindigkeit blieb konstant.

Habt ihr Erfahrung damit sammeln können? Wie läuft es bei euch?
 
confusing-charger said:
Wir haben bei uns ein ähnliches Setup. 5 Server, Ceph, 2 Switches die nicht gestacked sind.
Je Server 4x 25G. 2x für Ceph, 2x für VM-Traffic.

Aktuell läuft das Setup mit active-backup. Aber ich habe mich auch schon gefragt bzw. anfangs auch getestet, wie es mit balance-tlb und balance-alb läuft.
Mit den beiden letzteren hatte ich tatsächlich ein etwas merkwürdiges Verhalten. Bei "Lasttests" in einer VM mit dd, hat die Geschwindigkeit von Ceph spürbar geschwankt. Hat man bei der Auslastung der Interfaces und auch mit ceph -s deutlich gesehen. Erst beim Wechsel zurück auf active-backup hat sich alles wieder eingependelt und die Geschwindigkeit blieb konstant.

Habt ihr Erfahrung damit sammeln können? Wie läuft es bei euch?
Click to expand...
Da hast du Glück gehabt, dass dir dein Setup um die Ohren geflogen ist.
Die Load Balance Optionen sind für static LAGs auf den Switches gedacht. Also Single oder Stack.
Also Active/Backup lassen oder Switches mit MLAG Support benutzen und dann LACP nutzen.
 
  • Like
Reactions: ITT
Falk R. said:
Da hast du Glück gehabt, dass dir dein Setup um die Ohren geflogen ist.
Die Load Balance Optionen sind für static LAGs auf den Switches gedacht. Also Single oder Stack.
Also Active/Backup lassen oder Switches mit MLAG Support benutzen und dann LACP nutzen.
Click to expand...
Okay, interessant. Warum aber steht dann z.B. in der Doku auf https://www.kernel.org/doc/Documentation/networking/bonding.txt:

Adaptive load balancing: includes balance-tlb plus receive load balancing (rlb) for IPV4 traffic, and does not require any special switch support.

Beim Mode 802.3ad steht ja explizit dabei, dass das der Switch unterstützen muss.
 
  • Like
Reactions: itNGO
Hab noch mal nachgelesen. Static LAG ist tatsächlich nur bei balance RR und so weiter verpflichtend.
Bei tlb und rlb werden die arp Pakete modifiziert. Das kann aber trotzdem dazu führen, dass die Pakete nicht den optimalen Weg gehen und deinen Uplink zwischen den Switches strapazierst.
Das kann zu stark schwankender Performance führen. Ich bin der Freund von Active-Backup oder gleich richtig mit LACP.
 
  • Like
Reactions: herzkerl
You must log in or register to reply here.
Top Bottom