Best practice bei Ceph und zwei Switches
- Thread starter herzkerl
- Start date
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/
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.
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?
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?
Die kurze Antwort wäre ja, die lange Antwort mit einem aber und Details.
Ja, sehe ich auch so.
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 lieberBei 3 Servern würde ich diese für ceph direkt verkabeln und Switches nur für extern verwenden, eine Fehlerquelle weniger
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
Mit den beiden letzteren hatte ich tatsächlich ein etwas merkwürdiges Verhalten. Bei "Lasttests" in einer VM mit
Habt ihr Erfahrung damit sammeln können? Wie läuft es bei euch?
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?
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.
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.
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.
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.