Verständnisfrage zu Ceph Full Mesh

[s25a]

Hallo Zusammen,

vielleicht kann jemand hier etwas Licht ins Dunkle bringen.

Ich habe ein 3 Node Cluster gebaut. Jeder der Knoten hat einen 2 x 10G Bond zu 2 Switchen (Im Stack). Zusätzlich habe ich jedem Knoten noch eine 25G Karte mit 2 Ports eingebaut. Diese sind im Ring verbunden. Nach dieser Anleitung habe ich ein SDN Openfabric erstellt: https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server#Routed_Setup_(with_Fallback)

Hat auch alles soweit geklappt und die Nodes sehen sich untereinander in diesem neuen Netz. Meine Frage wäre nun folgende:

Bei der Initialisierung von Ceph kann man (sollte man) die Ceph Public und Ceph Cluster Netze separieren. Meine Idee war es eigentlich den gesamten Ceph Verkehr über den Ring laufen zu lassen so dass dies unabhängig von den Switchen immer läuft. Beides in ein Netzwerk wäre aber auch keine sonderlich gute Idee. Ist es denn möglich auf dem Ring eine art zusätzliches VLAN zu erstellen um dort den Ceph Public zu separieren? (Stichwort Zones VXlan etc.) oder ist das keine gute Idee?

Würdet ihr eher auf dem Bond zu den Switches ein separates Vlan für Ceph Public erstellen?

Ich habe noch nicht viel Erfahrung damit und würde gerne damit etwas testen bevor ich einen Schritt weiter gehe.

Vielen Dank und VG Alex

 

[bl1mp]

Hi Alex,
also prinzipiell kannst du ceph public und ceph internal trennen (über Vlans oder über IPAM in deinem Setup).

Müssen tust du es nicht. Einen wirklichen Mehrwert sehe ich nur, falls du den Ceph von außerhalb deiner PVE-Hosts direkt zugreifbar machen möchtest. (z.B. aus einer VM heraus).

Ansonsten würde ich den zusätzlichen Aufwand + Komplexität vermeiden. Es läuft alles über dieselben Kabel. Zusätzliche Vlantags in den Paketen verringern sonst nur den Durchsatz.

BG, Lucas

 

[aaron]

Beides in ein Netzwerk wäre aber auch keine sonderlich gute Idee.

Warum wenn ich fragen darf?
Wie @bl1mp schon erwähnt hat, kann man Ceph Public und Ceph Cluster im gleichen IP subnet laufen lassen. Falls das Netz nicht mehr genug Bandbreite hat, kann man aber recht leicht die Last auf unterschiedliche IP subnetze, und damit einhergehend hoffentlich auch physische Netze verteilen.

 

[s25a]

Guten Morgen Zusammen,

vielen Dank erstmal an alle Nachteulen

Beides in ein Netzwerk wäre aber auch keine sonderlich gute Idee.

Warum wenn ich fragen darf?

Ich bin gerade erst dabei mich mit dem Thema auseinanderzusetzen. Aus etlichen unterschiedlichen Quellen habe ich rausgelesen das man diese Netze trennen sollte. Gar nicht mal nur aus Gründen der gesamt möglichen Bandbreite sondern aufgrund der logischen Trennung und gegenseitiger Beeinflussung der Netze. Ob das dann in der Praxis wirklich so ist weiß ich nicht hängt wahrscheinlich sehr stark von der geplanten Nutzung ab.

Ansonsten würde ich den zusätzlichen Aufwand + Komplexität vermeiden. Es läuft alles über dieselben Kabel. Zusätzliche Vlantags in den Paketen verringern sonst nur den Durchsatz.

Vielleicht nur noch ein paar Punkte zur Anwendung:

- Ich möchte im Nächsten Schritt CephFS anlegen
- Dann einen Nextcloud Container und diesem über MountPoints dann CephFS unterschieben. Das hatte ich bereits etwas getestet. Das hatte im Fehlerfall (Kabel ziehen, Knoten abschalten usw.) sehr gut funktioniert und war auf dieser Hardware auch relativ performant.
- CephFS deswegen weil ich eventuell noch einen SMABA / NFS Server plane (zumindest testen möchte) und auf dieselben Daten zugreifen muss.

Vielleicht wäre dann doch der sauberste Ansatz das Ceph Core einfach als Openfabric dezidiert auf dem Ring laufen zu lassen und das Ceph Public auf das "normale" Netz zu den Switchen zu legen. Dort als separates VLAN (was sich ja relativ einfach über die GUI realisieren lässt).

Danke euch für euren Input. Viele Grüße Alex

 

[aaron]

sondern aufgrund der logischen Trennung und gegenseitiger Beeinflussung der Netze.

Da spielt es grundsätzlich eine Rolle zwischen Ceph und anderen Diensten. Z.b. Proxmox VE cluster kommunikation via Corosync.

Das Ceph Cluster Netz ist eben nur für die Replication zuständig. Siehe https://docs.ceph.com/en/latest/rados/configuration/network-config-ref/
Alles andere, auch der Client Traffic (VMs, Ceph FS clients, ...) läuft über das Ceph Public. Weshalb das auch entsprechend performant sein sollte.

Wenn andere Clients – außer Proxmox VE – Ceph verwenden sollen, dann ist es tatsächlich am einfachsten das Ceph Public Netz auf ein geswitchtes Netz zu legen.

 

[s25a]

Hi Aaron,

vielen Dank für die Informationen und den Link. Das hat sehr weitergeholfen. Dann nochmal diese beiden Fragen um das final einschätzen zu können.

- Wenn ich mit beiden Ceph Netzen auf dem Ring bleibe (25G) dann habe ich verstanden seht ihr erstmal keine großen bedenken bei einer kleineren Installation (3 Node Cluster, ein paar Maschinen, etwas Storage). Vorteil. Ceph würde unabhängig von externer Infrastruktur zuverlässig auf dem Ring laufen. Ich möchte wie oben beschrieben ein bisschen testen u.A mit CephFS für Nextcloud- und Fileserver Container. Das sollte so wie ich es verstanden habe alles funktionieren da die Maschinen ja auf dem ProxMox laufen und damit Zugriff haben. Nur wenn externe Clients direkt auf Ceph zugreifen wird es problematisch mit dem gekapselten Ring. So richtig oder?

- Die zweite Variante wäre dann nur das Ceph Core auf den Ring zu legen und dass Ceph Public mit in ein separates VLAN auf die Switche zu legen. Dann habe ich das Thema (Und das ist mir leider jetzt erst bewusst geworden denn einer der Clients hat leider keine weiteren 10G Schnittstellen sondern nur Gigabit) dass ich die 2 Port 25G Karten wieder rausnehmen müsste und gegen 4 Port SFP+ (10G) Karten tauschen müsste. Heißt ich habe dann für das Core Netz "nur" noch 10G im ring.
Das Public Netz wäre ein separates VLAN auf einem 20G Bond (2*10G) (Das wären dann die 2ten 2 Ports auf den Karten) und würde sich die Bandbreite mit anderen Netzen wie Management, CoroSync, VM Access für Clients teilen.

Wenn du mir dazu vielleicht noch eine kurze Einschätzung geben könntest. Da die Installation doch nicht ganz trivial ist bzw. die Um Konfiguration bei Tausch von Netzwerkkarten etc. wäre das vorab schon einfacher

Danke und VG Alex

 

[aaron]

Ich möchte wie oben beschrieben ein bisschen testen u.A mit CephFS für Nextcloud- und Fileserver Container. Das sollte so wie ich es verstanden habe alles funktionieren da die Maschinen ja auf dem ProxMox laufen und damit Zugriff haben. Nur wenn externe Clients direkt auf Ceph zugreifen wird es problematisch mit dem gekapselten Ring. So richtig oder?

hmm, wenn die auch nur virtuelle disks verwenden, dann ist das kein Problem, verwenden aber den RBD Layer von Ceph.
Wenn die Gäste direkt CephFS reden sollen wirds komplizierter und wird mit einem Full-Mesh für das Ceph Public Netz wohl nicht mehr gehen. Denn dann reden ja die Gäste direkt, und nicht der Proxmox VE Host, mit Ceph via CephFS. Da wäre ein geswitchtes Netzwerk deutlich einfacher.

Die Frage ist halt, müssen eine Nextcloud usw die Daten in einem CephFS liegen haben, oder gehts nicht anders? Z.B. netzwerkshare direkt zwischen den VMs? Das nimmt einiges an Komplexität raus.

Was du nicht haben willst ist Ceph (oder andere Services die ähnlich hohe Bandbreite verursachen können) auf dem gleichen physischen Netz wie andere wichtige Dienste. Corosync ist hier das Hauptbeispiel. EIn Grund wieso es best practice ist, Corosync mehr Links zu geben, wobei einer davon physisch dediziert nur für Corosync verwendet werden sollte.

Bitte auch richtig zwischen Ceph Cluster und Ceph Public Netzwerk unterscheiden. Ceph Core gibts nicht
Ich persönlich würde auf CephFS als zentralen Datenspeicher verzichten.
Wenn ich das richtig verstehe, wirds evtl. drauf rauslaufen, dass Fileserver und Nextcloud die gleichen Daten vorhalten sollen? Dann würde ich eine der VMs als "zentrale" definieren und das auf der anderen als NFS einbinden.
Dadurch ist das ganze Setup weniger komplex und da die Daten in einer virtuellen Disk liegen, ist es auch sehr einfach davon Backups zu machen, weil es mit den Backups der VM mit dabei ist. Wenn sie am CephFS liegen, müsstest du dich selbst drum kümmern dass sie gesichert werden.

 

[s25a]

Hi Nochmal,

ok vielen Dank für deine ausführliche Antwort. Ich glaube dann weiß ich wie ich vorgehe.

1) Hardwareseitig werde ich das mit den beiden CEPH Netzen (Public & Cluster ) direkt auf der Fabrik jetzt einfach mal ausprobieren und sehen wie es läuft. Ist wie gesagt sowieso erstmal zum Testen. Und CoroSync wäre damit erstmal getrennt. (Für dieses Setup gibt es keine dezidierte Leitung für den Sync aber produktiv wäre das natürlich eine Vorraussetzung)
2) Was noch wichtiger Hinweis war ist das Thema mit CephFS. Das mit dem FileServer würde ich sowieso erstmal hinten anstellen und würde mich erstmal um den Unterbau von Nextcloud kümmern. Ich habe das jahrelang über NFS gemacht aber wollte das über CEPH einfach mal austesten. Das würde ich dann wie vorgeschlagen ohne CEPHFS machen.

Ich persönlich würde auf CephFS als zentralen Datenspeicher verzichten.
Wenn ich das richtig verstehe, wirds evtl. drauf rauslaufen, dass Fileserver und Nextcloud die gleichen Daten vorhalten sollen? Dann würde ich eine der VMs als "zentrale" definieren und das auf der anderen als NFS einbinden.

Du meinst: Du würdest dann CEPH erstmal einer VM mit Fileserver unterschieben und dies dann weiter über NFS?

VG Alex

 

[aaron]

Du meinst: Du würdest dann CEPH erstmal einer VM mit Fileserver unterschieben und dies dann weiter über NFS?

"unterschieben" ;-)

Den Fileserver einfach in einer VM laufen lassen, welche durchaus Ceph RBD als Storage verwendet für die virtuellen Disks. Und die Fileserver VM muss dann so oder so die Files irgendwie zur Verfügung stellen. Ob das jetzt SMB, NFS, oder ein Nextcloud/Opencloud oder was auch immer, ist dann eine Frage was du in deiner Umgebung brauchst.

Ich persönlich hab in einem 2-node cluster mit Replication (3-nodes wären wirklich overkill...) die klassische Fileserver VM für die Netzwerkshares auch komplett in einer VM laufen mit OpenMediaVault um da ein netteres web interface fürs Managen zu haben.

Aber das nur als Idee. Der Vorteil wenn das alles direkt Teil der VM ist, ist eben, dass Backups und Restores einfach sind und keine anderen Abhängigkeiten an andere Stellen haben, wo die eigentlichen Daten evtl. liegen.

 

[s25a]

Hi Aaron,

ok danke Dir für die Infos. Ich betreibe übrigens ebenfalls einen 2 Node Cluster mit Replication. Was mich immer schon gestört hat war das Thema Storage und Verfügbarkeit. Auf der einen Seite hat man ein (einigermaßen) hochverfügbares Cluster für die VMs auf der anderen Seite hängt es dann im Fall der Fälle am Storage - also nicht das ich man das über Backups nicht wieder herstellen kann aber die durchgängige Verfügbarkeit ist nicht unbedingt gegeben.

Ich hatte mal kurzzeitig einen Active/Passive Cluster von Synology aber das war mir einfach zu unflexibel und in Zeiten von 0,35€/kwh einfach zu teuer. Ich werde mal berichten wie das mit dem Testcluster so läuft. Die Tipps mit der VM (OpenmediaVault hatte ich vor einigen Jahren auch mal im Einsatz) sind auf jeden Fall sehr hilfreich.

VG Alex

 

[Johannes S]

ok danke Dir für die Infos. Ich betreibe übrigens ebenfalls einen 2 Node Cluster mit Replication. Was mich immer schon gestört hat war das Thema Storage und Verfügbarkeit. Auf der einen Seite hat man ein (einigermaßen) hochverfügbares Cluster für die VMs auf der anderen Seite hängt es dann im Fall der Fälle am Storage - also nicht das ich man das über Backups nicht wieder herstellen kann aber die durchgängige Verfügbarkeit ist nicht unbedingt gegeben.

Dann aber hoffentlich mit qdevice, um split brain scenarios zu vermeiden? https://pve.proxmox.com/wiki/Cluster_Manager#_corosync_external_vote_support