Proxmox Ceph Cluster sizing

MLOrion

MLOrion

Active Member
Proxmox Subscriber
Feb 8, 2021
33
16
28
52
Hamburg
www.orionbulkers.com
Moin Zusammen

wir planen einen Proxmox Cluster mit 4 Nodes

Konfig per Node
AMD EPYC 9334 32 Core 2,7 GHz 128MB Cache
768 GB Ram DDR5 5600
10 x Micron 7500 PRO 3,8 TB OSD disks
2x Micron M.2 960GB ZFS boot
1x 2 Ports, 100GbE, QSFP56, Broadcom 57508
1x 4 Ports, 25GbE, SFP+ / SFP28, Broadcom 57504

Mikrotik CRS520-4XS-16XQ-RM Switch für Ceph Netzwerk.

Nun die Frage: reicht das Verhältnis Hauptspeicher zu Ceph OSD Speicher? Macht die gesamte Konfig so Sinn ?
 
Ähm… Hi?
Ich bin nur der nutzlose Wolf hier im Clusterwald, also bitte nicht hauen, wenn ich daneben liege… aber:


Ihr habt da 'ne Konfiguration, die klingt, als hättet ihr beim Setup +5 auf Netzwerk gewürfelt… und vielleicht eine kritische 1 bei „CPU-Verhandlung“?
Der EPYC 9334 – 32 Cores, klingt edel, klingt klug. Aber wenn das 100GbE-Netz loslegt, Ceph anfängt seine wilden Rebalancing-Rituale zu tanzen…
Könnte es sein, dass die CPU dann anfängt, mit sich selbst zu diskutieren? In einer Sprache, die nicht mal ZFS versteht?


RAM?
Da sag ich nix gegen. 768 GB klingt für mich nach „göttliche Intervention“. Vielleicht sogar overkillig schön? Die OSDs werden da sicher in goldenen Hallen tanzen.


Aber Netzwerk…
100GbE und 25GbE?
Ist das vielleicht… ein bisschen viel? Ich meine, das ist ja quasi, als hättet ihr einem Goblin eine Railgun gegeben. Sieht krass aus – aber… was, wenn der CPU beim nächsten Ceph-Bosskampf anfängt zu schreien?


Ich frag nur, weil…
– Kann der 9334 das überhaupt alles stemmen, wenn's heiß wird?
– Oder braucht man da eher einen EPYC mit mehr Takt und mehr… „Ceph-Widerstand“?
– Oder ist alles fein und ich sabbel hier Unsinn, während das Ding fliegt wie ein Datendrache auf Koffein?


Ich beobachte still vom Waldrand aus – deren.
Bin halt nur der nutzlose Wolf. Zwinker.


Möge eure Latenz niedrig sein
und eure Snapshots nie in Vergessenheit geraten.
 
MLOrion said:
Moin Zusammen

wir planen einen Proxmox Cluster mit 4 Nodes

Konfig per Node
AMD EPYC 9334 32 Core 2,7 GHz 128MB Cache
768 GB Ram DDR5 5600
10 x Micron 7500 PRO 3,8 TB OSD disks
2x Micron M.2 960GB ZFS boot
1x 2 Ports, 100GbE, QSFP56, Broadcom 57508
1x 4 Ports, 25GbE, SFP+ / SFP28, Broadcom 57504

Mikrotik CRS520-4XS-16XQ-RM Switch für Ceph Netzwerk.

Nun die Frage: reicht das Verhältnis Hauptspeicher zu Ceph OSD Speicher? Macht die gesamte Konfig so Sinn ?
Click to expand...
Hi,
soweit kann die Konfiguration schon passen, aber ich hätte lieber die im pro GB Preis günstigeren 7,68 TB NVMe genommen.
So ganz pauschal kannst du 1 Core + 5GB RAM pro OSD einplanen. Andere Dienste wie Monitor und Manager brauchen aber auch ein klein wenig.

UselessWolf said:
Ähm… Hi?
Ich bin nur der nutzlose Wolf hier im Clusterwald, also bitte nicht hauen, wenn ich daneben liege… aber:

Aber Netzwerk…
100GbE und 25GbE?
Ist das vielleicht… ein bisschen viel? Ich meine, das ist ja quasi, als hättet ihr einem Goblin eine Railgun gegeben. Sieht krass aus – aber… was, wenn der CPU beim nächsten Ceph-Bosskampf anfängt zu schreien?
Click to expand...
25G ist inzwischen quasi Standard bei neuen Netzwerken und Ceph mache ich nur unter Wiederstand mit unter 100G. Ich habe auch Kleinkunden mit 3 kleinen NVMe und 100G Netzwerk für Ceph. Sogar bei den drei kleinen NVMe (PCIe3) auf 3 Nodes habe ich im Peak bereits 60GBit gemessen.
 
  • Like
Reactions: MLOrion, Johannes S and UselessWolf
Ja, die meisten vergessen dass CEPH ordentlich CPU und RAM Ressourcen benötigt. Pro OSD lässt sich durchaus ein Kern ausnutzen. Wenn es NVME sind, auch mehr. Ich mag der einzige hier sein, aber CEPH AUF dem Host, welcher auch virtualisieren soll, schränkt aus meiner Sicht die Kapazitätzen für die Virtualisierung zu sehr ein.
Grundsätzlich gilt mindestens 1GB Ram für ein TB Storage: Also mindestens 40GB RAM pro Host für CEPH und bei 10 NMVE mindestens 10 Kerne für die OSDs (um die NVMe aber auszureizen können es durch aus 3 oder mehr pro NVME sein) und jweils 1 weitere für MDS und MON und MGR (ein MDS pro Cluster, 3 oder 5 MON pro Cluster, 1 MGR pro Cluster)

https://docs.ceph.com/en/quincy/start/hardware-recommendations/
https://pve.proxmox.com/wiki/Deploy_Hyper-Converged_Ceph_Cluster
 
Last edited:
  • Like
Reactions: Johannes S
s.meier77 said:
Ja, die meisten vergessen dass CEPH ordentlich CPU und RAM Ressourcen benötigt. Pro OSD lässt sich durchaus ein Kern ausnutzen. Wenn es NVME sind, auch mehr. Ich mag der einzige hier sein, aber CEPH AUF dem Host, welcher auch virtualisieren soll, schränkt aus meiner Sicht die Kapazitätzen für die Virtualisierung zu sehr ein.
Grundsätzlich gilt mindestens 1GB Ram für ein TB Storage: Also mindestens 40GB RAM pro Host für CEPH und bei 10 NMVE mindestens 10 Kerne für die OSDs (um die NVMe aber auszureizen können es durch aus 3 oder mehr pro NVME sein) und jweils 1 weitere für MDS und MON und MGR (ein MDS pro Cluster, 3 oder 5 MON pro Cluster, 1 MGR pro Cluster)
Click to expand...
Wenn das ein Cluster ist, der nur Ceph macht, bin ich bei dir, aber im HCI Setup sehe ich nie so hohe Last. Im Regelfall langweilen sich die OSD und wenn mal Peaklast auftritt, dann wird es halt kurz mal etwas kuschelig auf den Hosts.

Was ein echtes Argument ist, wenn ich trotzdem nur 10 Cores plane für Ceph, aber die Hosts mit Microsoft Lizenzen, durchlizensieren will, dann sollte man das mal neu durchrechnen.
 
  • Like
Reactions: Johannes S and s.meier77
Falk R. said:
Wenn das ein Cluster ist, der nur Ceph macht, bin ich bei dir, aber im HCI Setup sehe ich nie so hohe Last
Click to expand...
Ja, das stimmt. Dann sollte aber der produktive Storage der VM's (SMB, ausgelastete DBs) nicht auch über das Cliuster laufen, richtig?
 
s.meier77 said:
Ja, das stimmt. Dann sollte aber der produktive Storage der VM's (SMB, ausgelastete DBs) nicht auch über das Cliuster laufen, richtig?
Click to expand...
So ein Fileserver macht schon etwas Last, aber da bekommt Ceph in der Regel keinen Stress. DB Server machen oft viel weniger I/O als viele Denken, außer man hat den Server gerade neu gestartet und SQL muss den RAM erst einmal wieder füllen. So ein Mittelständler in der größenordnung hat aber mit einem solchen HCI Setup eine gut funktionierende Lösung. Im High End Bereich, wenn ich mehrere Tausend VMs habe, ist das Sizing deutlich komplexer.
 
  • Like
Reactions: Johannes S
MLOrion said:
Moin Zusammen

wir planen einen Proxmox Cluster mit 4 Nodes
Click to expand...
P.S. wenn möglich eventuell einen 5. kleinen Node ohne OSDs, nur mit einer Corosync Stimme und einem Monitor Deamon laufen lassen.
 
  • Like
Reactions: MLOrion, Johannes S, gurubert and 1 other person
so es wurde bestellt.

4 Stk.

AMD EPYC 9355 32 Core 3,55 GHz 256MB Cache
768 GB Ram DDR5 6400
6 x Micron 7500 PRO 7,6 TB OSD disks
2x Micron 7500 Pro 960GB ZFS boot
1x 2 Ports, 100GbE, QSFP56, Broadcom 57508
1x 4 Ports, 25GbE, SFP+ / SFP28, Broadcom 57504

mal gucken wie ich jetzt die Netze verteile.
der Plan ist Ceph rein über den Mikrotik laufen zu lassen mit 100Gbe
Alles andere auf 25 Gbe LACP Links

Wir werden sehen
 
  • Like
Reactions: Johannes S
MLOrion said:
so es wurde bestellt.

4 Stk.

AMD EPYC 9355 32 Core 3,55 GHz 256MB Cache
768 GB Ram DDR5 6400
6 x Micron 7500 PRO 7,6 TB OSD disks
2x Micron 7500 Pro 960GB ZFS boot
1x 2 Ports, 100GbE, QSFP56, Broadcom 57508
1x 4 Ports, 25GbE, SFP+ / SFP28, Broadcom 57504

mal gucken wie ich jetzt die Netze verteile.
der Plan ist Ceph rein über den Mikrotik laufen zu lassen mit 100Gbe
Alles andere auf 25 Gbe LACP Links

Wir werden sehen
Click to expand...
Hoffentlich hast du nicht nur einen 100G Switch, sondern Redundanz. Ein kleiner PC oder so als Quorum ist ja wahrscheinlich vorhanden.
 
  • Like
Reactions: Johannes S
Falk R. said:
Hoffentlich hast du nicht nur einen 100G Switch, sondern Redundanz. Ein kleiner PC oder so als Quorum ist ja wahrscheinlich vorhanden.
Click to expand...
Ja sind zwei CRS520-4XS-16XQ-RM
LACP zwischen den beiden Switchen und die Ports für Ceph mit balance-alb und je ein Port pro Switch.
Also pur Layer 2

Die sind auch schon eingerichtet, warte nur noch auf die Server.

Code: 
      +--------------------+  2×100 G  Bond (ISL)
      |  CRS520‑A (SW1)    |=========================|
      |  Bridge „bridge‑ceph“               |        |
      |   ├─qsfp28-1‑1  ─ Server‑1 (eno1)       |        |
      |   ├─qsfp28-1‑2  ─ Server‑2 (eno1)       |        |
      |   ├─qsfp28-1‑3  ─ Server‑3 (eno1)       |        |
      |   ├─qsfp28-1‑4  ─ Server‑4 (eno1)       |        |
      |   └─bond‑isl (qsfp28-1‑1/1‑2)===========+========+
      +--------------------+                          |
                                                      |
      +--------------------+                          |
      |  CRS520‑B (SW2)    |==========================+
      |  Bridge „bridge‑ceph“               |        |
      |   ├─qsfp28-1‑1  ─ Server‑1 (eno2)       |        |
      |   ├─qsfp28-1‑2  ─ Server‑2 (eno2)       |        |
      |   ├─qsfp28-1‑3  ─ Server‑3 (eno2)       |        |
      |   ├─qsfp28-1‑4  ─ Server‑4 (eno2)       |        |
      |   └─bond‑isl (qsfp28-1‑1/1‑2)===========+========+
      +--------------------+
 
  • Like
Reactions: Johannes S
Warum hast du den Port gesplittet? Du hast doch 100G NICs, dann eher qsfp28-1-1 = Server 1 und qsfp28-2-1 = Server2.
Außerdem bin ich kein Freund von ALB bei ceph, sondern nutze lieber MLAG auf den Switches und LACP Layer3+4 auf den Hosts.
Die Doku von Mikrotik mit der MLAg Einrichtung ist ganz gut, wenn man das aber zum ersten mal macht, gibt es ein gutes Video von einem Inder auf YT, das kann man schön nachklicken und lernen. ;)
 
MLOrion said:
@Falk R.
Die Mlag Doku für den CRS520-4XS-16XQ-RM habe ich nicht gefunden und das was ich gefunden habe machte für mich keinen Sinn.

Ich bin aus der Mellanox / HP Switch Welt.

Wird so erstmal getestet...
Click to expand...
Wenn ich bei google MikroTik und MLAG eingebe bekomme ich als ersten Treffer immer diese Doku: https://help.mikrotik.com/docs/spaces/ROS/pages/67633179/Multi-chassis+Link+Aggregation+Group

Sonst schau dir das mal an: https://www.youtube.com/watch?v=xvb7Nd1xvRw
 
  • Like
Reactions: Johannes S and MLOrion
Eigentlich nicht so schwer, man muss nur sein Wissen über andere Switches einmal ausblenden und dann kommt man schon rein.
Eigentlich ganz simpel. Du musst aber unbedingt getaggte VLANs benutzen auf dem Peer Link, und das VLAN1 nicht benutzen, dann läuft es.
Der Einzig verweirrende Unterschied zu anderen Herstellern, hier gibt man nur den Peer Port an und bei allen anderen eine Peer IP.
 
  • Like
Reactions: Johannes S
kurzer einwurf. eine gerade anzahl an nodes ist schlecht aufgrund von möglichen split-brain szenarien. es sollte immer eine ungerade anzahl nodes sein.
man sollte hier auf jeden fall noch einen node haben der als 5. stimme fungiert, oder zumindest ein qdevice am laufen haben, das hier als tiebreaker agiert im fall der fälle.
 
  • Like
Reactions: Johannes S
beisser said:
kurzer einwurf. eine gerade anzahl an nodes ist schlecht aufgrund von möglichen split-brain szenarien. es sollte immer eine ungerade anzahl nodes sein.
man sollte hier auf jeden fall noch einen node haben der als 5. stimme fungiert, oder zumindest ein qdevice am laufen haben, das hier als tiebreaker agiert im fall der fälle.
Click to expand...
ja ist geplant

und ich werde von ALB auf active / passive failover gehen. NAch dem Motto "keep it simple"
 
Last edited:
  • Like
Reactions: Johannes S
noch eine Frage zu de Thema corosync.

jeder Server hat 6 SFP+ Links.

1x LACP Link mit VLans für
Migration
Cluster
Backup (PBS)

1x LACP Link mit VLans für
vm's


die zwei übrigen würde ich für den Corosync nutzen wollen.
LACP solll ja nicht die beste Idee für Corosync sein.

also folgende Idee:

Die 2 verbleibenden Links pro Server in einem Broadcast Bond mit IP und einer Bridge mit dem Bond als slave fürs qdevice.
Ohne VLan Tagging

dumme Idee ? andere Vorschläge ?
 
MLOrion said:
noch eine Frage zu de Thema corosync.

jeder Server hat 6 SFP+ Links.

1x LACP Link mit VLans für
Migration
Cluster
Backup (PBS)

1x LACP Link mit VLans für
vm's


die zwei übrigen würde ich für den Corosync nutzen wollen.
LACP solll ja nicht die beste Idee für Corosync sein.

also folgende Idee:

Die 2 verbleibenden Links pro Server in einem Broadcast Bond mit IP und einer Bridge mit dem Bond als slave fürs qdevice.
Ohne VLan Tagging

dumme Idee ? andere Vorschläge ?
Click to expand...
Broadcast Bond finde ich eine schlechtere Idee als LACP.
Für Corosync brauchst du keine Bandbreite, daher würde auch locker GBit reichen.
Dann aber bitte lieber 2 getrennte Netze, möglichst die IPs jeweils direkt auf die NIC. Du kannst ja mehrere Netzwerke für Corosync angeben. Ich weiß nicht ob es ein Limit gibt, aber ich habe noch keins gesehen. Bisher war das meiste bei mir 6 Corosync Ringe. Zuerst die Dedizierten NICs und gern auch Storage NIC oder Management NIC ebenfalls als möglichen Failover rein nehmen.
 
  • Like
Reactions: Johannes S
You must log in or register to reply here.
Top Bottom