Verständnisfrage zum Netzwerk eines PVE-/CEPH-Cluster

[CHoe]

Moin zusammen,

aktuell setzen wir einen kleinen Proxmox-Cluster jeweils mit lokalem Storage via ZFS ein. Da die Hardware zur Reinvestition ansteht, plane ich einen neuen PVE-Cluster mit CEPH und habe dazu noch ein paar Fragen, die ich trotz Recherche hier und via Google nicht oder teilweise widersprüchlich beantwortet bekomme. Erstmal zu der geplanten Hardware:

3 Nodes:

• 2x12 Cores
• 512GB RAM
• 2x 480GB M.2 auf eigenem Hardware Raid 1 als Boot (ja ich weiß, dass das oversized ist! Aber unser Serverlieferant hat keine kleineren M2-SSDs )
• 4 x 3,84 TB NVMe (PCIe 5.0) für CEPH-Storage.
• 8x 10GB-Ethernet
• 2x 100GB-Ethernet

Das Netzwerk habe ich aktuell folgendermaßen geplant (natürlich je Node):

• 2x 10GBit (LACP oder Active Backup) für Corosync
• 2x 10GBit (LACP oder Active Backup) für VM-Traffic und Management
• 2x 10GBit (LACP oder Active Backup) für die Anbindung an die Proxmox Backup Server
• 2x 100GBit Mesh-Netzwerk für CEPH (entsprechend https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server)

Eine spätere Erweiterung des Clusters auf 4 oder mehr Nodes ist aktuell nicht denkbar, da selbst die 3 Nodes in unserem aktuellen Szenario noch massiv Reserven bieten. Auch würde in einem 3er Cluster der Ausfall eines Nodes zu keinen Ressourcen- oder Performance-Engpässen führen.

Nun zu meinen Fragen:

1. Wenn ich richtig informiert bin, nutzt CEPH ebenfalls Corosync für seinen Cluster. Benötigt CEPH auf PVE ein eigenes Corosync-Netzwerk und somit ein vom Proxmox-Corosync getrenntes LAN? Oder teilen sich PVE und CEPH den Corosync-Dienst?
2. Für unsere Server nutzen wir aktuell einen Stack aus 2x 48-Port 10GBit-Switchen. Die Nodes würden natürlich jeweils mit einem Port auf beiden Switchen angebunden. Ist es für Corosync zwingend notwendig einen eigenen Switch(-Stack) zu verwenden, oder reicht auch ein nicht-geroutetes und somit gekapseltes VLAN zwischen für Corosync dedizierten Ports auf unserem Stack aus?
3. Unseren aktuellen VMs reichen eine einzelne 10GBit-Leitung performancetechnisch problemlos aus und daher haben wir dort den zweiten Port als active-backup konfiguriert. Unser Rechenzentrumsbetreiber meinte, dass sie in der Vergangenheit mehrfach Probleme mit LACP hatten und mir daher auch für den neuen Cluster zu active-backup raten würden. Wie ist Eure Erfahrung bzw. zu was würdet Ihr mir raten?

Wäre super, wenn Ihr mir helfen könntet etwas Licht ins Dunkel zu bringen

 

[Falk R.]

Moin zusammen,

aktuell setzen wir einen kleinen Proxmox-Cluster jeweils mit lokalem Storage via ZFS ein. Da die Hardware zur Reinvestition ansteht, plane ich einen neuen PVE-Cluster mit CEPH und habe dazu noch ein paar Fragen, die ich trotz Recherche hier und via Google nicht oder teilweise widersprüchlich beantwortet bekomme. Erstmal zu der geplanten Hardware:

3 Nodes:

• 2x12 Cores

Bitte nicht, nimm dann lieber eine 24 Core CPU, die Skaliert deutlich besser als zwei kleine CPUs mit QPI oder UPI Link dazwischen.

• 512GB RAM
• 2x 480GB M.2 auf eigenem Hardware Raid 1 als Boot (ja ich weiß, dass das oversized ist! Aber unser Serverlieferant hat keine kleineren M2-SSDs )

Das ist inzwischen normal.

• 4 x 3,84 TB NVMe (PCIe 5.0) für CEPH-Storage.
• 8x 10GB-Ethernet
• 2x 100GB-Ethernet

Das Netzwerk habe ich aktuell folgendermaßen geplant (natürlich je Node):

• 2x 10GBit (LACP oder Active Backup) für Corosync

Für Corosync bitte kein Bond. Da reicht auch locker 1 GBit und dann lieber 2 IPs für zwei getrennte Netze verwenden und jeweils als eigenen Ring angeben.

• 2x 10GBit (LACP oder Active Backup) für VM-Traffic und Management
• 2x 10GBit (LACP oder Active Backup) für die Anbindung an die Proxmox Backup Server

Für Backup würde ich auch keine extra NICs verschwenden, da du dort nur einmal am Tag kurz Traffic hast und mit dem PBS hast du außer beim ersten Backup immer wenig Traffic.

• 2x 100GBit Mesh-Netzwerk für CEPH (entsprechend https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server)

Kann man machen, ich persönlich finde aber über Switches schöner, da man da besser Troubleshooten kann. Ist aber Geschmackssache.
Ich benutze für die kleinen 3Node Cluster gern die Mikrotik CRS 504 Switches. Davon 2 Stück und MLAG können die Switches auch.
2x 800€ für die Switches und ein paar DAC Kabel sitzen in jedem Projekt noch drin.

Eine spätere Erweiterung des Clusters auf 4 oder mehr Nodes ist aktuell nicht denkbar, da selbst die 3 Nodes in unserem aktuellen Szenario noch massiv Reserven bieten. Auch würde in einem 3er Cluster der Ausfall eines Nodes zu keinen Ressourcen- oder Performance-Engpässen führen.

Nun zu meinen Fragen:

1. Wenn ich richtig informiert bin, nutzt CEPH ebenfalls Corosync für seinen Cluster. Benötigt CEPH auf PVE ein eigenes Corosync-Netzwerk und somit ein vom Proxmox-Corosync getrenntes LAN? Oder teilen sich PVE und CEPH den Corosync-Dienst?

Nein, Corosync wird nur vom PVE Cluster benutzt. Ceph nutzt sein eigenes Netzwerk.

1. Für unsere Server nutzen wir aktuell einen Stack aus 2x 48-Port 10GBit-Switchen. Die Nodes würden natürlich jeweils mit einem Port auf beiden Switchen angebunden. Ist es für Corosync zwingend notwendig einen eigenen Switch(-Stack) zu verwenden, oder reicht auch ein nicht-geroutetes und somit gekapseltes VLAN zwischen für Corosync dedizierten Ports auf unserem Stack aus?

Wenn du einen einzelnen Gigabit Switch rumstehen hast, freut sich Corosync auch über ein Dediziertes Netzwerk.
Wenn du nur diesen Stack hast, dann ist das wiederum egal, da eh alles zusammen hängt. Dann bitte das Ceph Netzwerk als weiteren Corosync Ring angeben.

1. Unseren aktuellen VMs reichen eine einzelne 10GBit-Leitung performancetechnisch problemlos aus und daher haben wir dort den zweiten Port als active-backup konfiguriert. Unser Rechenzentrumsbetreiber meinte, dass sie in der Vergangenheit mehrfach Probleme mit LACP hatten und mir daher auch für den neuen Cluster zu active-backup raten würden. Wie ist Eure Erfahrung bzw. zu was würdet Ihr mir raten?

LACP macht nie Probleme, außer man hat sein Netzwerk nicht im Griff. Bei einem RZ Betreiber ist das wieder schwierig, weil da jeder Kunde Bullshit konfigurieren kann, die der RZ Betreiber ausbaden muss.
Wenn du eigene Switches hast, welche du selbst konfigurieren kannst, dann nutze LACP. Hängst du an einem Stack vom RZ Betreiber, dann am besten nach seinen Wünschen richten.

Wäre super, wenn Ihr mir helfen könntet etwas Licht ins Dunkel zu bringen

 

[CHoe]

Bitte nicht, nimm dann lieber eine 24 Core CPU, die Skaliert deutlich besser als zwei kleine CPUs mit QPI oder UPI Link dazwischen.

Das kommt immer auf den Anwendungszweck an. In unserem Fall ist es aber tatsächlich irrelevant und in unserem Rahmenvertrag waren 2x12C deutlich günstiger als 1x24C.
Edit (vorhin vergessen): Ein weiterer Grund waren die PCIe-Lanes. Da wir NVMe-Laufwerke einsetzen und unser Standard-Server bei NMVe-Ausstattung nicht Single-CPU konfigurierbar ist. Eh Du fragst: es wird langfristig definitiv nicht bei den 4 NVMe bleiben.

Für Corosync bitte kein Bond. Da reicht auch locker 1 GBit und dann lieber 2 IPs für zwei getrennte Netze verwenden und jeweils als eigenen Ring angeben.

Okay, das sollte kein Problem sein und werde ich berücksichtigen. Das mit 1GBit für Corosync war mir bewusst aber die 10G wurden bewusst gewählt, da der Aufpreis marginal war und wir so mit der Hardware flexibler sind.

Für Backup würde ich auch keine extra NICs verschwenden, da du dort nur einmal am Tag kurz Traffic hast und mit dem PBS hast du außer beim ersten Backup immer wenig Traffic.

Wenn man nur einmal am Tag sichert stimme ich Dir zu 100% zu. Wir sichern jedoch einige Systeme deutlich häufiger (teilweise alle 2 Stunden) - und das auch während unserer Geschäftszeiten. Da haben wir in der Vergangenheit schonmal die Erfahrungen gesammelt, dass ein Backup gedrosselt werden musste, damit die Server nicht unnötig gebremst wurden.

Kann man machen, ich persönlich finde aber über Switches schöner, da man da besser Troubleshooten kann. Ist aber Geschmackssache.
Ich benutze für die kleinen 3Node Cluster gern die Mikrotik CRS 504 Switches. Davon 2 Stück und MLAG können die Switches auch.
2x 800€ für die Switches und ein paar DAC Kabel sitzen in jedem Projekt noch drin.

3x DAC-Kabel musste ich ja für das Mesh sowieso mit einplanen. Danke aber für den Tipp mit den Mikrotik Switches, die waren mir bisher nicht bekannt. Ich kannte bisher nur Geräte jenseits der 10k€. Die Mikrotik werde ich auf jeden Fall im Hinterkopf halten, falls wir Probleme mit dem Mesh bekommen sollten und ich werde mich bei denen bzgl. der Performance mal schlau machen!

Nein, Corosync wird nur vom PVE Cluster benutzt. Ceph nutzt sein eigenes Netzwerk.

Top, danke!

Wenn du einen einzelnen Gigabit Switch rumstehen hast, freut sich Corosync auch über ein Dediziertes Netzwerk.
Wenn du nur diesen Stack hast, dann ist das wiederum egal, da eh alles zusammen hängt. Dann bitte das Ceph Netzwerk als weiteren Corosync Ring angeben.

Leider nicht. Das CEPH-Netz werde ich aber mit angeben. Danke für den Tipp!

LACP macht nie Probleme, außer man hat sein Netzwerk nicht im Griff. Bei einem RZ Betreiber ist das wieder schwierig, weil da jeder Kunde Bullshit konfigurieren kann, die der RZ Betreiber ausbaden muss.

Ich kenne LACP eigentlich auch nur als unproblematisch. Unser RZ betreibt selber hunderte Server (ich befinde mich hier in einer "etwas größeren" Stadtverwaltung) und die haben inhouse angeblich diese Erfahrungen gesammelt. Wenn ich aber auf LACP bestehe, werden die mir die Ports entsprechend konfigurieren. Es ist leider nur nicht so einfach immer alles unter einen Hut zu bekommen, wenn man seine Hardware nicht zu 100% selbst unter der Kontrolle hat.

Aber vielen Dank für Deine Antworten, Du hast mich damit schon deutlich weiter gebracht und ich werde schauen, was ich davon wie berücksichtigen/umsetzen kann.

 

[Falk R.]

Das kommt immer auf den Anwendungszweck an. In unserem Fall ist es aber tatsächlich irrelevant und in unserem Rahmenvertrag waren 2x12C deutlich günstiger als 1x24C.
Edit (vorhin vergessen): Ein weiterer Grund waren die PCIe-Lanes. Da wir NVMe-Laufwerke einsetzen und unser Standard-Server bei NMVe-Ausstattung nicht Single-CPU konfigurierbar ist. Eh Du fragst: es wird langfristig definitiv nicht bei den 4 NVMe bleiben.

Das Problem mit den Rahmenverträgen kenne ich. Ich empfehle auch immer AMD Systeme für Virtualisierung und bei den Single Socket AMD ist man zwar auf 20 NVMe limitiert, aber damit kommen die meisten hin.
Ohne Rahmenvertrag ist das in etwa Preisgleich aber läuft performanter.

Wenn man nur einmal am Tag sichert stimme ich Dir zu 100% zu. Wir sichern jedoch einige Systeme deutlich häufiger (teilweise alle 2 Stunden) - und das auch während unserer Geschäftszeiten. Da haben wir in der Vergangenheit schonmal die Erfahrungen gesammelt, dass ein Backup gedrosselt werden musste, damit die Server nicht unnötig gebremst wurden.

Was beim PBS Backup bremst ist extrem selten das Netzwerk, sondern eher die Diskausstattung des PBS. Sogar bei den Full NVMe PBS bei meinen Kunden, haben wir kein Netzwerkproblem. Das ist nicht wie bei Veeam wo der Host die Daten zum Proxy transportieren muss, sondern der Backupclient läuft auf dem PVE und schickt nur komprimierte Chunks wenn diese im Dedup noch nicht vorhanden sind. Sonst nur Metadaten.

3x DAC-Kabel musste ich ja für das Mesh sowieso mit einplanen. Danke aber für den Tipp mit den Mikrotik Switches, die waren mir bisher nicht bekannt. Ich kannte bisher nur Geräte jenseits der 10k€. Die Mikrotik werde ich auf jeden Fall im Hinterkopf halten, falls wir Probleme mit dem Mesh bekommen sollten und ich werde mich bei denen bzgl. der Performance mal schlau machen!

Ich habe so einen CRS504 bei mir zuhause stehen, aber der läuft in der Spielumgebung nur mit 40 GBit.
Bei Kunden habe ich diese öfters im Einsatz, auch den CRS520 mit 16x 100GBit für die etwas größeren Cluster.
Die sind etwas anders in der Bedienung (alles Linux like, satt Cisco like)

Ich kenne LACP eigentlich auch nur als unproblematisch. Unser RZ betreibt selber hunderte Server (ich befinde mich hier in einer "etwas größeren" Stadtverwaltung) und die haben inhouse angeblich diese Erfahrungen gesammelt. Wenn ich aber auf LACP bestehe, werden die mir die Ports entsprechend konfigurieren. Es ist leider nur nicht so einfach immer alles unter einen Hut zu bekommen, wenn man seine Hardware nicht zu 100% selbst unter der Kontrolle hat.

Kanne ich nur zu gut, auch ich betreue ein paar Städte und Landkreise.

 

[CHoe]

Was beim PBS Backup bremst ist extrem selten das Netzwerk, sondern eher die Diskausstattung des PBS. Sogar bei den Full NVMe PBS bei meinen Kunden, haben wir kein Netzwerkproblem. Das ist nicht wie bei Veeam wo der Host die Daten zum Proxy transportieren muss, sondern der Backupclient läuft auf dem PVE und schickt nur komprimierte Chunks wenn diese im Dedup noch nicht vorhanden sind. Sonst nur Metadaten.

Wir haben betreiben aktuell 3 Proxmox-Cluster und einen davon bereits mit neuer NVMe-Hardware (allerdings ohne CEPH, sondern mit ZFS+Replikation, da nur 2 Nodes und nur unwichtige Dienste) und dabei habe ich es schon mehrfach geschafft die eingestellten 800MB/s (Der Cluster hat noch kein separates Backup-Netz, da habe ich Migrationen und Backups auf 800MB/s begrenzt) auszulasten. Will somit bei dem neuen Cluster auf Nummer sicher gehen.

Ich habe so einen CRS504 bei mir zuhause stehen, aber der läuft in der Spielumgebung nur mit 40 GBit.
Bei Kunden habe ich diese öfters im Einsatz, auch den CRS520 mit 16x 100GBit für die etwas größeren Cluster.
Die sind etwas anders in der Bedienung (alles Linux like, satt Cisco like)

Keine Ahnung, warum ich die vorher nie gefunden habe. Was die Bedienung betrifft mache ich mir aber keine Sorgen. Linux ist überhaupt kein Problem für mich. Und schließlich würden damit ja keine komplexen und gerouteten Netze aufgebaut.

 

[Falk R.]

Wir haben betreiben aktuell 3 Proxmox-Cluster und einen davon bereits mit neuer NVMe-Hardware (allerdings ohne CEPH, sondern mit ZFS+Replikation, da nur 2 Nodes und nur unwichtige Dienste) und dabei habe ich es schon mehrfach geschafft die eingestellten 800MB/s (Der Cluster hat noch kein separates Backup-Netz, da habe ich Migrationen und Backups auf 800MB/s begrenzt) auszulasten. Will somit bei dem neuen Cluster auf Nummer sicher gehen.

Habt ihr da sehr große Änderungsraten bei euren Servern? Wird denn das Limit nur kurzzeitig im Peak gerissen, oder dauerhaft?
Wenn ich ein LACP über 2x 10G fahre, hat man keinen Stress mit dem Backup, da jeder Server nur eine Connection zum PBS aufbaut und somit mit dem einen Stream nur 1x 10GBit sättigen kann, was in der Regel nur ganz kurz im Peak passiert. Für die weiteren Connections hat man dann ja noch 10GBit frei.

 

[CHoe]

Das ist manchmal ganz unterschiedlich. Aber bei den DB- und auch den File-Servern kann das mal passieren. Eine Kurze 100% Peak kann hier schon Probleme mit unserem ERP-System verursachen: Den Clients fliegt dann die Verbindung weg und die Mitarbeitenden müssen sich neu verbinden.
Was die LAG betrifft hast Du nur bedingt recht: Wenn der Backup-Server ebenfalls via LAG angeschlossen ist und mehrere Backups parallel laufen, dann kann ich damit auch mehr als 2 Streams aufbauen und somit trotzdem die Leitung dicht machen. Aber vielleicht mache ich auch einfach eine "universelle" 4-port LAG aus den oben geplanten Ports und dann sollte es auch ruhig bleiben.

 

[Falk R.]

Das ist manchmal ganz unterschiedlich. Aber bei den DB- und auch den File-Servern kann das mal passieren. Eine Kurze 100% Peak kann hier schon Probleme mit unserem ERP-System verursachen: Den Clients fliegt dann die Verbindung weg und die Mitarbeitenden müssen sich neu verbinden.

Klingt eher nach schlechter ERP Software, aber daran können wir ja nix ändern.

Was die LAG betrifft hast Du nur bedingt recht: Wenn der Backup-Server ebenfalls via LAG angeschlossen ist und mehrere Backups parallel laufen, dann kann ich damit auch mehr als 2 Streams aufbauen und somit trotzdem die Leitung dicht machen. Aber vielleicht mache ich auch einfach eine "universelle" 4-port LAG aus den oben geplanten Ports und dann sollte es auch ruhig bleiben.

Leider hast du da nicht recht. Es kann immer nur ein Backupjob auf einmal auf einem Host laufen. Damit kannst du mit dem Backup auch nur einen Stream sättigen. Ich habe auch Kunden mit ganz empfindlichen Anwendungen, da hat noch nie einer Probleme mit dem Backup gehabt. Was eher mal Probleme verursacht, wenn der BPS zu langsam ist und die VM damit auf ihren Disks gebremst wird, während dem Backup.

 

[CHoe]

Klingt eher nach schlechter ERP Software, aber daran können wir ja nix ändern.

Yep - aber leider gibt es für uns keinerlei Alternativen. Ich habe aber die Hoffnung, dass es mit dem nächsten großen Major-Release besser wird.

Leider hast du da nicht recht. Es kann immer nur ein Backupjob auf einmal auf einem Host laufen. Damit kannst du mit dem Backup auch nur einen Stream sättigen. Ich habe auch Kunden mit ganz empfindlichen Anwendungen, da hat noch nie einer Probleme mit dem Backup gehabt. Was eher mal Probleme verursacht, wenn der BPS zu langsam ist und die VM damit auf ihren Disks gebremst wird, während dem Backup.

Leider muss ich Dir da Recht geben! Muss das wohl mit den Migrations-Workern verwechselt haben. Mehrere Backups laufen ja nur parallel, wenn auf mehreren Cluster-Nodes VMs gesichert werden sollen. Sorry, my fault!

Aber ich stelle fest, die Backup-Infrastruktur muss ich nochmal überdenken. Bin derzeit noch dabei zu überlegen, wie ich eine möglichst gute Trennung der Backup-Systeme vom restlichen Netz hinbekomme.

Grundsätzlich kann ich mit den Firewalls natürlich alle Zugriffe einschränken. Die Frage ist nur, ob ich mit einer Netz-Trennung hier noch eine höhere Sicherheit hinbekomme? Separate LANs schaden ja grundsätzlich nicht. Die Frage ist, ob hier separate LAN-Ports oder -Adapter noch eine höhere Sicherheit bringen. Klar, der PVE-Node ist unvermeidbar die Verbindung zwischen beiden Welten solange der Storage im Node selbst sitzt. Im Falle eines VM-Escapes wäre ein Angreifer dann auf dem Node und hätte vermutlich (root-)Zugriff auf alle LAN-Ports und ich hätte hier eh verloren.
Aber abgesehen davon: Solange das Management des PVE in einem separaten VLAN stattfindet, sollte man aus einer VM heraus (auf dem normalen Weg über den virtuellen Netzwerkadapter) im Normalfall ja an den Firewalls hängen bleiben.
Gibt es ein bekanntes Angriffsszenario, bei dem mir das Ganze um die Ohren fliegen kann solange der gesamte Traffic über ein und den selben physischen Adapter (bzw. LAG) läuft?

Ich weiß, die Gedanken sind gerade vielleicht etwas sehr "konstruiert", aber ich möchte versuchen soviele Szenarien wie möglich vorher zu betrachten.

 

[Falk R.]

Yep - aber leider gibt es für uns keinerlei Alternativen. Ich habe aber die Hoffnung, dass es mit dem nächsten großen Major-Release besser wird.


Leider muss ich Dir da Recht geben! Muss das wohl mit den Migrations-Workern verwechselt haben. Mehrere Backups laufen ja nur parallel, wenn auf mehreren Cluster-Nodes VMs gesichert werden sollen. Sorry, my fault!

Aber ich stelle fest, die Backup-Infrastruktur muss ich nochmal überdenken. Bin derzeit noch dabei zu überlegen, wie ich eine möglichst gute Trennung der Backup-Systeme vom restlichen Netz hinbekomme.

Grundsätzlich kann ich mit den Firewalls natürlich alle Zugriffe einschränken. Die Frage ist nur, ob ich mit einer Netz-Trennung hier noch eine höhere Sicherheit hinbekomme? Separate LANs schaden ja grundsätzlich nicht. Die Frage ist, ob hier separate LAN-Ports oder -Adapter noch eine höhere Sicherheit bringen. Klar, der PVE-Node ist unvermeidbar die Verbindung zwischen beiden Welten solange der Storage im Node selbst sitzt. Im Falle eines VM-Escapes wäre ein Angreifer dann auf dem Node und hätte vermutlich (root-)Zugriff auf alle LAN-Ports und ich hätte hier eh verloren.
Aber abgesehen davon: Solange das Management des PVE in einem separaten VLAN stattfindet, sollte man aus einer VM heraus (auf dem normalen Weg über den virtuellen Netzwerkadapter) im Normalfall ja an den Firewalls hängen bleiben.
Gibt es ein bekanntes Angriffsszenario, bei dem mir das Ganze um die Ohren fliegen kann solange der gesamte Traffic über ein und den selben physischen Adapter (bzw. LAG) läuft?

Ich weiß, die Gedanken sind gerade vielleicht etwas sehr "konstruiert", aber ich möchte versuchen soviele Szenarien wie möglich vorher zu betrachten.

Ich habe immer einen Primären PBS, ganz normal und dann einen Sekundären, welcher per Pull von ersten Synchronisiert. Diesen mache ich die Firewall eingehen komplett dicht, so dass ich nur über das BMC zugreifen kann. Da die BMC auch jeweils einen Webservice haben, wird der Port dafür auf dem Switch disabled.
Damit sind die Sekundärbackups schon sehr gut geschützt.