Verteilung der verschiedenen Traffic-Arten im Cluster auf verschiedene Interfaces

[converged]

Hi,

ich baue hier einen hyper-converged cluster mit drei Knoten. Jeder Knoten hat eine NVMe-OSD und eine HDD-OSD. Da ich nur einen Switch zur Verfügung habe soll aller cluster-interner Traffic in Mesh-Netzen laufen. Zwischen den Knoten habe ich 1 x 40 GBe mesh und 3 x 10 GBe mesh, jeder Knoten hat noch 2 x 10 GBe zum Switch (für Host- und VM-Traffic).

Meine Frage ist jetzt, wie teile ich den verschiedenen Traffic im Cluster am besten zwischen meinen Mesh-Netzen auf. An Traffic wären da:
1. corosync
2. Cluster-Traffic (die IPs auf die die jeweiligen Hostnamen resolven, was geht da eigentlich alles genau drüber?)
3. Live-Migration
4. Ceph public
5. Ceph private

Bisher habe ich:
corosync in einem eigenen Netz
Ceph private im 40GBe Netz

Bleiben noch 2 x 10 GBe übrig. Wie verteile ich jetzt Cluster, Migration und Ceph public am besten darauf?

Gruß

converged

 

[converged]

Hi,

ist die Frage zu schwierig oder zu trivial? Oder hat einfach niemand Erfahrung damit?

Gruß converged

 

[antimon]

Ich glaube, dass deine Frage schwierig zu beantworten ist, da es natürlich davon abhängt, was du für ne Workload hast und was dein Cluster genau machen soll. Willst du HA fahren, soll regelmäßig repliziert werden?
Mit Ceph kenne ich mich jetzt nicht so gut aus, deswegen vielleicht eine blöde Frage: Warum public/private? Wenn du zwischen den beiden Nodes ein CEPH aufbaust, sind die doch jeweils die Clients - externe Clients greifen doch nicht direkt auf dein CEPH Storage zu, oder? Brauchst du überhaupt ein Client Netz?
Grundsätzlich sollte dein Netz fürs Storage ordentlich Wumms haben - das hast du ja. Die Client-Anbindung hast du auch, also bleibt noch das CoroSync (das glaube ich nicht ganz so viel Bandbreite braucht, die Zuverlässigkeit ist da IMHO wichtiger) und dein Migrations-Netz. Letzeres hängt halt davon ab, wie intensiv du das nutzt und wie wichtig da die Geschwindigkeit ist. Wenn die VMs eh über einen bereits replizierten Storage bedient werden, muss lediglich der RAM-Inhalt sowie ein paar Statusinfos über dieses Netz übertragen werden - damit kann man sich einfach ausrechnen, wie lange der Vorgang dann dauert und ob das dann schnell genug ist...
Vielleicht noch ein Denkanstoß: Evtl. würds auch Sinn machen, das Backup über ein eigenes Netz zu fahren - oder mann nimmt z.B. das Replikations-Netz her, damit Backups nicht zu viel Einfluss auf den normalen Betrieb haben...

 

[converged]

Ich glaube, dass deine Frage schwierig zu beantworten ist, da es natürlich davon abhängt, was du für ne Workload hast und was dein Cluster genau machen soll. Willst du HA fahren, soll regelmäßig repliziert werden?

Es soll nen HA Cluster werden. Hauptsächlich Linux-VM mit Datenbank und Webservern, alles eher read-orientiert. Vielleicht auch ein, zwei Windows-Server dazwischen.

Mit Ceph kenne ich mich jetzt nicht so gut aus, deswegen vielleicht eine blöde Frage: Warum public/private? Wenn du zwischen den beiden Nodes ein CEPH aufbaust, sind die doch jeweils die Clients - externe Clients greifen doch nicht direkt auf dein CEPH Storage zu, oder? Brauchst du überhaupt ein Client Netz?

Wenn ich das richtig verstehe handled das CEPH client/public-Netz die Kommunikation mit den Clients (also den Cluster-Nodes). Das private wird für die Kommunikation zwischen den Ceph-Nodes genutzt (also Replikation). In nem drei Node-Cluster ist es wahrscheinlich wirklich nicht so sinnvoll die Netze zu trennen.
Das Live-Migrationsnetz sollte eigentlich wenig Traffic sehen und wäre somit wohl für Backups mit nutzbar.

Mir scheint die sinnvollste Aufteilung dann:
40 GBe: Ceph
10 GBe: corosync
10 GBe: cluster
10 GBe: Live-Migration und Backup
zu sein.

Die drei nicht-corosync-Netze würde ich dann als Backup definieren. Oder schaden mehr corosync-ringe, als sie helfen?

 

[Ingo S]

Ich weiß nicht genau, was mit "Cluster" gemeint ist, aber der Cluster kommuniziert eigentlich via Corosync. Konsolen (VNC etc. ) und SSH Sitzungen etc. können ganz normal über das User Netz laufen. Das braucht nur wenig Traffic, der nicht stört.

Ceph eigenständig zu halten ist in jedem Fall eine sehr gute Idee, denn wenn Ceph mal wegen eines defekten Laufwerks einen Rebalance macht, kann dir der Traffic das Interface für andere Dinge blockieren. Das ist dann unangenehm im besten Fall.

Wir haben das hier so gelöst:
1.) 10GBe für Ceph
2.) 10GBe für Client traffic
3.) 1GBe für Corosync (1 Ring, aber über einen active/backup bond der beiden onboard Netzwerkkarten der Server)

Migration läuft über das 2. Netz. Eine Migration stört interessanterweise den Betrieb nicht. Selbst wenn ich mal 6 VMs gleichzeitig von einem zum anderen Host live migriere können die User ganz normal weiter arbeiten.

Backups laufen Abends nach Dienstschluss ebenfalls über das 2. Netz, stört aber auch tagsüber nicht, wenn ich mal ein Backup außer der Reihe mache.

 

[converged]

Ich weiß nicht genau, was mit "Cluster" gemeint ist, aber der Cluster kommuniziert eigentlich via Corosync. Konsolen (VNC etc. ) und SSH Sitzungen etc. können ganz normal über das User Netz laufen. Das braucht nur wenig Traffic, der nicht stört.

Siehe 1. Post:
2. Cluster-Traffic (die IPs auf die die jeweiligen Hostnamen resolven, was geht da eigentlich alles genau drüber?)

Da weiß ich eben nicht genau was da alles läuft. Wenn es sowieso vernachlässigbar ist, wieso wird dann empfohlen corosync abtrennen?
Oder gilt die Empfehlung corosync abzutrennen nur, wenn man kein Shared-Storage und keine andere Verbindung für die Live-Migration hat?

 

[Ingo S]

Ah jetzt verstehe ich...
Also das Corosync abtrennen meint, die Corosync Cluster Kommunikation von den anderen Netzen zu trennen, insbesondere Ceph und das Netz wo die Backups drüber laufen. Das Corosync IST das Cluster Netz. Wenn es da zu störungen durch zu viel Traffic (lange Paketlaufzeiten etc) kommt, dann hast du große Probleme mit deinem Cluster. Hosts können sich dann untereinander nicht mehr ordentlich synchronisieren, so das die Hosts als offline angezeigt werden, obwohl sie online sind, du kannst Maschinen nicht mehr starten oder beenden, umkonfigurieren etc.
Das passiert aber nicht, wenn das Corosync über ein separates Netz läuft, das vom Traffic auf anderen Netzen unberührt ist. Dann kann z.B. Ceph seine Interfaces dicht ballern, aber dein Cluster lässt sich normal steuern.

Also Corosync abtrennen meint abtrennen von den anderen Netzen wie User oder Ceph.

 

[converged]

Ah jetzt verstehe ich...
Also das Corosync abtrennen meint, die Corosync Cluster Kommunikation von den anderen Netzen zu trennen, insbesondere Ceph und das Netz wo die Backups drüber laufen. Das Corosync IST das Cluster Netz. Wenn es da zu störungen durch zu viel Traffic (lange Paketlaufzeiten etc) kommt, dann hast du große Probleme mit deinem Cluster. Hosts können sich dann untereinander nicht mehr ordentlich synchronisieren, so das die Hosts als offline angezeigt werden, obwohl sie online sind, du kannst Maschinen nicht mehr starten oder beenden, umkonfigurieren etc.
Das passiert aber nicht, wenn das Corosync über ein separates Netz läuft, das vom Traffic auf anderen Netzen unberührt ist. Dann kann z.B. Ceph seine Interfaces dicht ballern, aber dein Cluster lässt sich normal steuern.

Also Corosync abtrennen meint abtrennen von den anderen Netzen wie User oder Ceph.

Ok, d.h. drei Meshes mit
40GBe für Ceph
10GBe für Corosync/Cluster/wieauchimmer (nur 10GBe weil nix kleineres da ist)
10GBe für Live-Migration und Backup
scheinen zu passen.
Host und VM Traffic würden über weitere Interfaces über den Switch gehen.

Korrekt so?

 

[antimon]

10GBe für Corosync/Cluster/wieauchimmer (nur 10GBe weil nix kleineres da ist)

Du könntest die Netzwerkkarten ja manuell auf 1G stellen

Ich finde, deine Config hört sich gut an - das Wichtigste ist ja Ceph von der Bandbreite her und dass das CoroSync separiert ist.
Falls du VLANs fahren kannst/willst, kannst du den zweiten CoroSync Ring noch irgendwo mit unterbringen - bei mir läuft der noch auf dem SAN-Netz mit. Normalerweise wird der zweite Ring ja nicht benötigt, wenn man aber am Haupt-CoroSync-Ring Wartungsarbeiten durchführen möchte, kommt das System dann aber nicht aus dem Tritt.