Diverse Fragestellungen welche die Kaufentscheidung beeinflussen

[j.palm]

Guten Tag,

folgender Sachverhalt wir haben aktuell ca. 10 3-Node-Cluster Inhouse und viele kleine Cluster extern verteilt stehen.
Diese laufen aktuell noch mit Hyper-V von welchem wir uns trennen wollen um Zukunft auf z.B. Proxmox zu setzen.

Nun gibt es in dem Rahmen allerdings noch einige Fragestellungen welche unsere Entscheidung ,welche Technologie wir in Zukunft nutzen, beeinflusst.

Ich stelle im Anschluss meine Fragestellungen einfach in einer Art Liste bereit und freue mich auf jede Antwort.

1. Thema: Wieviele Ressourcen benötigt Proxmox zur Selbstverwaltung bei ca. 200 Maschinen und wie verhält sich das pro Maschine ? Gibt es da Erfahrungswerte oder eine Formel mit welcher man rechnen kann ?

2. Thema: Secure-Boot ( darüber konnte ich jetzt schon etwas im Forum lesen) Hintergrund ist das aufgrund der Firmenrichtlinien in Produktiv-Systemen Secureboot aktiv sein muss. Wenn ich es richtig gelesen habe gibt es zwar die Möglichkeit dies zu bewerkstelligen wenn man erst ein normales Debian installiert und dann darauf Proxmox. Diese Installationsart führt aber soweit ich das gelesen habe ja dazu dass man ein nicht supportetes Setup nutzt und es daher nichts bringt ein entsprechend großes Support-Abo abzuschliesen (welches aber in unserem Fall benötigt werden würde).

3. Thema: FC-Anbindung hab ich nach mehreren Anläufen und diversen Tutorials hinbekommen clusterweit zu integrieren mit Hilfe von OCFS2 ist es geplant bzw. irgendwie möglich ggf. die FC-Anbindung einfacher zu machen oder zu Automatisieren um damit Zeit zu sparen wenn wir ein neues LUN einbinden. Da ggf, noch eine Frage dazu ist es möglich ein erstelltes LUN direkt an die VM als Disk einzubinden und dann trotzdem die HA-Funktionalitäten zu behalten?

4.Thema: Multi-Cluster Ist es absehbar das dieses Feature kommt ? Hintergrund ist einfach das wir durch das oben beschriebene Szenario sonst ja mind. 10 versch. WebGUIs hätten und das den Verwaltungsaufwand natürlich enorm erhöht. Der Wechsel unseres Hyper-V-Systems zu ggf. Proxmox ist für Q1/23 geplant.
+ wie sieht es da mit Verteiltem RZ aus ... also wir haben z.B. zwischen 2 Standorten eine Darkfiber-Leitung mit aktuell 10gbits und weitere Standorte sind per MPLS mit angebunden .. gibt es da ggf. Probleme oder Dinge die Beachtet werden müssten ?

5.Thema: IPv6 lässt sich dies bedenklos komplett deaktivieren ohne das uns daraus Funktionseinschränkungen entstehen ?

6.Thema: Root-Login.. ist es möglich nach der Installation und Initialkonfiguration diesen einzuschränken/deaktivieren und stattdessen mit "sudo" zu arbeiten ?

7.Thema; MAC-Adressen Ist es möglich bei PXE Boot eine MAC-Reservierung durchzuführen ? und wenn ja wie kann man diese Implementieren? zum Thema MAC-Adressen bleiben diese gleich wenn für einmal für die VM erstellt ? Hintergrund dahinter es gibt Software die wohl auf die MAC-Adresse lizensiert wird, da wäre es ungünstig wenn diese bei Migrationen auf eine andere Cluster-Node .. ein komplett anderes Cluster oder beim Wiederherstellen aus einem Backup sich ändern würde.

8.Thema Migration von Hyper-V wie würde sich diese gestalten ? Einfach oder Schwierig umzusetzen ? Lässt sich das automatisieren oder zumindest teilweise automatisieren oder müssten wir jede VM einzeln umziehen ?

Ich danke euch schon im vorraus für Antworten auch wenn es ziemlich viele Themen sind die vermutlich teilweise nicht all zu einfach sind.

mfg Joe

 

[Dunuin]

1. Thema: Wieviele Ressourcen benötigt Proxmox zur Selbstverwaltung bei ca. 200 Maschinen und wie verhält sich das pro Maschine ? Gibt es da Erfahrungswerte oder eine Formel mit welcher man rechnen kann ?

Das hängt auch stark vom Storage und den Backups ab, welche die meisten Ressourcen fressen. An was dachtest du da?
Bei PBS läuft die AES-Verschlüsselung, Hashing and ZSTD-Kompression z.B. clientseitig ab.

2. Thema: Secure-Boot ( darüber konnte ich jetzt schon etwas im Forum lesen) Hintergrund ist das aufgrund der Firmenrichtlinien in Produktiv-Systemen Secureboot aktiv sein muss. Wenn ich es richtig gelesen habe gibt es zwar die Möglichkeit dies zu bewerkstelligen wenn man erst ein normales Debian installiert und dann darauf Proxmox. Diese Installationsart führt aber soweit ich das gelesen habe ja dazu dass man ein nicht supportetes Setup nutzt und es daher nichts bringt ein entsprechend großes Support-Abo abzuschliesen (welches aber in unserem Fall benötigt werden würde).

Ja, aktuell ist die PVE ISO noch nicht signiert. Soll aber nächstes Jahr kommen. Siehe hier: https://forum.proxmox.com/threads/proxmox-ve-install-failure.116700/post-505054

4.Thema: Multi-Cluster Ist es absehbar das dieses Feature kommt ? Hintergrund ist einfach das wir durch das oben beschriebene Szenario sonst ja mind. 10 versch. WebGUIs hätten und das den Verwaltungsaufwand natürlich enorm erhöht. Der Wechsel unseres Hyper-V-Systems zu ggf. Proxmox ist für Q1/23 geplant.
+ wie sieht es da mit Verteiltem RZ aus ... also wir haben z.B. zwischen 2 Standorten eine Darkfiber-Leitung mit aktuell 10gbits und weitere Standorte sind per MPLS mit angebunden .. gibt es da ggf. Probleme oder Dinge die Beachtet werden müssten ?

Corosync braucht eine Latenz von unter 1ms. Cluster über Rechenzentren hinweg ist also schwierig.

5.Thema: IPv6 lässt sich dies bedenklos komplett deaktivieren ohne das uns daraus Funktionseinschränkungen entstehen ?

Ja. Mache ich immer so indem ich net.ipv6.conf.all.disable_ipv6 = 1 in die "/etc/sysctl.conf" schreibe. Bin da noch nie mit auf Probleme gestoßen. Aber vielleicht kann da wer vom Support was zu sagen mit tiefem Einblick in den Quellcode, ob es da vielleicht doch Sonderfälle gibt.

6.Thema: Root-Login.. ist es möglich nach der Installation und Initialkonfiguration diesen einzuschränken/deaktivieren und stattdessen mit "sudo" zu arbeiten ?

Nicht komplett. Einige wenige Dinge sind aus Sicherheitsgründen auf den Root-Account hardcoded. Aber sudo kann man nachinstallieren und dann damit das meiste machen.

 

[j.palm]

Das hängt auch stark vom Storage und den Backups ab, welche die meisten Ressourcen fressen. An was dachtest du da?
Bei PBS läuft die AES-Verschlüsselung, Hashing and ZSTD-Kompression z.B. clientseitig ab.

Wir nutzen aktuell für den Storage eine HPE 3PAR welche mit 16Gbits per FC direkt an den Host angeschlossen ist.

Corosync braucht eine Latenz von unter 1ms. Cluster über Rechenzentren hinweg ist also schwierig.

Dank dir für die Info

Ja. Mache ich immer so indem ich net.ipv6.conf.all.disable_ipv6 = 1 in die "/etc/sysctl.conf" schreibe. Bin da noch nie mit auf Probleme gestoßen. Aber vielleicht kann da wer vom Support was zu sagen mit tiefem Einblick in den Quellcode, ob es da vielleicht doch Sonderfälle gibt.

Danke werd ich testen und evtl. gibt es ja noch ein Feedback vom Support der deine Ansicht bestätigen kann.

Nicht komplett. Einige wenige Dinge sind aus Sicherheitsgründen auf den Root-Account hardcoded. Aber sudo kann man nachinstallieren und dann damit das meiste machen.

Es ist also möglich den Remote Root Login auf Permit zu setzen und dann im Proxmox mit "Sudo" oder falls doch root benötigt wird mit "su -" zu arbeiten oder

Ich dank dir schonmal vielmals für die ganzen Infos.

mfg Joe

 

[Dunuin]

Es ist also möglich den Remote Root Login auf Permit zu setzen und dann im Proxmox mit "Sudo" oder falls doch root benötigt wird mit "su -" zu arbeiten oder

Ich dank dir schonmal vielmals für die ganzen Infos.

Ja, mit sudo über die CLI gibt es nicht viele Probleme. Aber mit einem anderen User im WebUI einloggen, auch wenn der alle Admin-Privilegien zugeteilt hat, klappt nicht so toll. Da geht weniges dann wirklich nur, wenn man sich als root@pam einloggt. Daher kann man den Root-User nicht komplett verbieten. Root-Login in der /etc/ssh/sshd_config komplett verbieten kann man aber durchaus und dann mit sudo arbeiten oder zur Not it su - zum Root-User wechseln.

Cluster-Beitritt über die API war glaube ich z.B. einer der Punkte, welche man als root@pam duchführen kann.

PVE ist ja grundlegend auch nur ein Debian 11 mit Custom Ubuntu Kernel und PVE Packages oben drauf. Was da mit einem Debian geht, geht üblicher weise auch mit PVE.

 

[aaron]

1. Thema: Wieviele Ressourcen benötigt Proxmox zur Selbstverwaltung bei ca. 200 Maschinen und wie verhält sich das pro Maschine ? Gibt es da Erfahrungswerte oder eine Formel mit welcher man rechnen kann ?

Schwierig so generell zu beantworten. Ein einfacher Proxmox VE server wird nicht viele Ressourcen verbrauchen. Aber was ist an eventueller Drittsoftware installiert?
Wird ZFS verwendet? Dann ist mehr RAM gut, damit der für den ZFS Cache verwendet werden kann.
Ist es ein hyperkonvergenter Ceph Cluster? Hier brauchen die Ceph Dienste auch Ressourcen...

3. Thema: FC-Anbindung hab ich nach mehreren Anläufen und diversen Tutorials hinbekommen clusterweit zu integrieren mit Hilfe von OCFS2 ist es geplant bzw. irgendwie möglich ggf. die FC-Anbindung einfacher zu machen oder zu Automatisieren um damit Zeit zu sparen wenn wir ein neues LUN einbinden. Da ggf, noch eine Frage dazu ist es möglich ein erstelltes LUN direkt an die VM als Disk einzubinden und dann trotzdem die HA-Funktionalitäten zu behalten?

Braucht ihr Snapshots? Wenn nicht, ist es bei iSCSI/FC möglich, ein großes LUN zu machen und darauf ein (thick) LVM zu konfigurieren. Die einzelnen LVs sind strickt getrennt und Proxmox VE stellt sicher, dass immer nur ein Gast gleichzeitig in ein LV schreibt.
Der Nachteil ist, dass keine Snapshots möglich sind.

4.Thema: Multi-Cluster Ist es absehbar das dieses Feature kommt ? Hintergrund ist einfach das wir durch das oben beschriebene Szenario sonst ja mind. 10 versch. WebGUIs hätten und das den Verwaltungsaufwand natürlich enorm erhöht. Der Wechsel unseres Hyper-V-Systems zu ggf. Proxmox ist für Q1/23 geplant.
+ wie sieht es da mit Verteiltem RZ aus ... also wir haben z.B. zwischen 2 Standorten eine Darkfiber-Leitung mit aktuell 10gbits und weitere Standorte sind per MPLS mit angebunden .. gibt es da ggf. Probleme oder Dinge die Beachtet werden müssten ?

Multicluster-Management ist auf der Roadmap und wir hoffen bald eine erste Beta veröffentlichen zu können.

Wei schon erwähnt, braucht ein Proxmox VE Cluster der via Corosync kommuniziert, eine niedrige Latenz. Je nachdem wen man fragt ist auch <10ms noch okay
Die Frage ist dann aber viel mehr bei der Latenz zu den Storages, da dies ja merklich die Performance der VMs beeinflusst. Lokale ZFS Storages in Kombination mit dem Replication Feature können hier einen Mittelweg darstellen. Wie zum Beispiel in diesem Testimonial. Wichtig ist hierbei aber auch, wie sich ein evtl. größer aufgespannter Cluster verhält, wenn es Probleme gibt zwischen den DCs. Ein Proxmox VE Cluster funktioniert, indem eine Mehrheit der Nodes ein Quorum bilden. Es gibt keine dedizierte Master Node. Gerade wenn man den HA Stack verwenden will, ist ein stabiles Corosync Netz wichtig! Deshalb sollte man hier keine zu komplizierten Setups bauen, um den Überblick nicht zu verlieren, wie der Cluster in diversen Fehlerszenarien reagieren wird.

5.Thema: IPv6 lässt sich dies bedenklos komplett deaktivieren ohne das uns daraus Funktionseinschränkungen entstehen ?

Ja, kann man einfach deaktivieren wie schon erwähnt, wenn man es nicht braucht.

7.Thema; MAC-Adressen Ist es möglich bei PXE Boot eine MAC-Reservierung durchzuführen ? und wenn ja wie kann man diese Implementieren? zum Thema MAC-Adressen bleiben diese gleich wenn für einmal für die VM erstellt ? Hintergrund dahinter es gibt Software die wohl auf die MAC-Adresse lizensiert wird, da wäre es ungünstig wenn diese bei Migrationen auf eine andere Cluster-Node .. ein komplett anderes Cluster oder beim Wiederherstellen aus einem Backup sich ändern würde.

Die MAC Adressen werden beim Erstellen einer VM festgelegt. Entweder setzt man diese explizit, oder es wird zufällig eine generiert. Diese bleibt dann aber fix der VM, oder genauer, der jeweiligen NIC der VM zugewiesen. Falls nötig, kann man auch Prefixe konfigurieren, dann wird nur der restliche Teil automatisch generiert.

8.Thema Migration von Hyper-V wie würde sich diese gestalten ? Einfach oder Schwierig umzusetzen ? Lässt sich das automatisieren oder zumindest teilweise automatisieren oder müssten wir jede VM einzeln umziehen ?

Schon https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE und https://pve.proxmox.com/wiki/Additional_ways_to_migrate_to_Proxmox_VE gesehen? Bei WIndows VMs ist vor allem der letzte Teil ( https://pve.proxmox.com/wiki/Additi...rt_Windows_to_use_.28VirtIO.29_SCSI_.28KVM.29 ) interessant, damit bestehende Windows Gäste auf deutlich performantere VirtIO Treiber für die Festplatten wechseln können.

 

[j.palm]

Schwierig so generell zu beantworten. Ein einfacher Proxmox VE server wird nicht viele Ressourcen verbrauchen. Aber was ist an eventueller Drittsoftware installiert?
Wird ZFS verwendet? Dann ist mehr RAM gut, damit der für den ZFS Cache verwendet werden kann.
Ist es ein hyperkonvergenter Ceph Cluster? Hier brauchen die Ceph Dienste auch Ressourcen...

Wir nutzen aktuell im Test-Setup weder ZFS noch Ceph .. wir nutzen halt das OCFS2 von Oracel um den FC-Storage CLuster weit verfügbar zu haben.Geht uns halt vorwiegend darum wie hoch halt der Ressourcen-Verbrauch ca. wäre bei Größen um die 200 VMs... nur damit wir grob rechnen können was für an den Server-Ressourcen für die VMs nutzen können und wv. wir ca. dem Host lassen damit dieser normal arbeiten kann.

Braucht ihr Snapshots? Wenn nicht, ist es bei iSCSI/FC möglich, ein großes LUN zu machen und darauf ein (thick) LVM zu konfigurieren. Die einzelnen LVs sind strickt getrennt und Proxmox VE stellt sicher, dass immer nur ein Gast gleichzeitig in ein LV schreibt.
Der Nachteil ist, dass keine Snapshots möglich sind.

Dank dir für die Informationen, ich werde das in Erfahrung bringen und es im Hinterkopf behalten.

Wei schon erwähnt, braucht ein Proxmox VE Cluster der via Corosync kommuniziert, eine niedrige Latenz. Je nachdem wen man fragt ist auch <10ms noch okay
Die Frage ist dann aber viel mehr bei der Latenz zu den Storages, da dies ja merklich die Performance der VMs beeinflusst. Lokale ZFS Storages in Kombination mit dem Replication Feature können hier einen Mittelweg darstellen. Wie zum Beispiel in diesem Testimonial. Wichtig ist hierbei aber auch, wie sich ein evtl. größer aufgespannter Cluster verhält, wenn es Probleme gibt zwischen den DCs. Ein Proxmox VE Cluster funktioniert, indem eine Mehrheit der Nodes ein Quorum bilden. Es gibt keine dedizierte Master Node. Gerade wenn man den HA Stack verwenden will, ist ein stabiles Corosync Netz wichtig! Deshalb sollte man hier keine zu komplizierten Setups bauen, um den Überblick nicht zu verlieren, wie der Cluster in diversen

Vielen Dank für den Lösungsansatz das ist mir noch nicht eingefallen dies ggf. so zu realisieren.

Die MAC Adressen werden beim Erstellen einer VM festgelegt. Entweder setzt man diese explizit, oder es wird zufällig eine generiert. Diese bleibt dann aber fix der VM, oder genauer, der jeweiligen NIC der VM zugewiesen. Falls nötig, kann man auch Prefixe konfigurieren, dann wird nur der restliche Teil automatisch generiert.

Danke für die Bestätigung

Schon https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE und https://pve.proxmox.com/wiki/Additional_ways_to_migrate_to_Proxmox_VE gesehen? Bei WIndows VMs ist vor allem der letzte Teil ( https://pve.proxmox.com/wiki/Additi...rt_Windows_to_use_.28VirtIO.29_SCSI_.28KVM.29 ) interessant, damit bestehende Windows Gäste auf deutlich performantere VirtIO Treiber für die Festplatten wechseln können.

Schau ich mir direkt mal an .. Vielen Dank dafür.

mfg Joe

 

[aaron]

Was ich vorhin noch nicht verlinkt hatte, waren die Systemanforderungen: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_system_requirements

Als OS Disk sollten 60GB mehr als ausreichen für einen einfachen Proxmox VE Server ohne Ceph.

Was an CPUs und RAM schlussendlich gebraucht wird, hängt natürlich von den VMs ab. Overhead gibt es nicht viel. Ich würde den RAM aber auch nicht bis aufs GB genau auslegen, sondern immer großzügig Reserve einplanen, um auf der sicheren Seite zu sein.

Wie viel Ressourcen OCFS2 braucht, kann ich nicht sagen, das ist nicht Teil einer Standardinstallation. Wir haben dafür entsprechend wenig Erfahrung und supporten es nicht direkt.
Ich kann den Wunsch verstehen, bestehende Infrastruktur weiterzuverwenden, aber mit anderer Software funktionieren Dinge manchmal sehr anders. Deshalb ist es mitunter nicht möglich, die Storages mit den gleichen Features 1zu1 weiterzuverwenden. Es gibt mitunter auch andere Features, mit denen man den ganzen Cluster ganz anders aufbauen kann.


Zu den Clustern über RZs hinweg sei noch gesagt, dass so ein Setup nicht trivial ist. Es ist leicht, einen single point of failure zu übersehen. Wenn Ihr die HA Funktionalität verwenden wollt, würde ich stark davon abraten. Denn wenn eine Node mit HA Gästen den Kontakt zur Mehrheit im Cluster verliert, wird sich diese nach circa einer Minute fencen (hard reset). Das passiert, damit die HA Gäste auch sicher aus sind, bevor sie im (hoffentlich noch vorhandenen) restlichen Cluster gestartet werden. Bröselt jetzt aber das Netzwerk so zusammen, dass sich keine Mehrheit mehr bilden kann, dann werden sich alle Nodes mit HA Gästen neu starten. Das sieht dann von Außen mitunter so aus, als ob sich der gesamte Cluster neu gestartet hat.

Das kann passieren, wenn das Netzwerk für Corosync wirklich down ist oder die Latenz für die Corosyncpakete zu hoch wird und Corosync keinen brauchbaren Link zum Ausweichen mehr zur Verfügung hat.

 

[j.palm]

Was ich vorhin noch nicht verlinkt hatte, waren die Systemanforderungen: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_system_requirements

Als OS Disk sollten 60GB mehr als ausreichen für einen einfachen Proxmox VE Server ohne Ceph.

Was an CPUs und RAM schlussendlich gebraucht wird, hängt natürlich von den VMs ab. Overhead gibt es nicht viel. Ich würde den RAM aber auch nicht bis aufs GB genau auslegen, sondern immer großzügig Reserve einplanen, um auf der sicheren Seite zu sein.

Wie viel Ressourcen OCFS2 braucht, kann ich nicht sagen, das ist nicht Teil einer Standardinstallation. Wir haben dafür entsprechend wenig Erfahrung und supporten es nicht direkt.
Ich kann den Wunsch verstehen, bestehende Infrastruktur weiterzuverwenden, aber mit anderer Software funktionieren Dinge manchmal sehr anders. Deshalb ist es mitunter nicht möglich, die Storages mit den gleichen Features 1zu1 weiterzuverwenden. Es gibt mitunter auch andere Features, mit denen man den ganzen Cluster ganz anders aufbauen kann.


Zu den Clustern über RZs hinweg sei noch gesagt, dass so ein Setup nicht trivial ist. Es ist leicht, einen single point of failure zu übersehen. Wenn Ihr die HA Funktionalität verwenden wollt, würde ich stark davon abraten. Denn wenn eine Node mit HA Gästen den Kontakt zur Mehrheit im Cluster verliert, wird sich diese nach circa einer Minute fencen (hard reset). Das passiert, damit die HA Gäste auch sicher aus sind, bevor sie im (hoffentlich noch vorhandenen) restlichen Cluster gestartet werden. Bröselt jetzt aber das Netzwerk so zusammen, dass sich keine Mehrheit mehr bilden kann, dann werden sich alle Nodes mit HA Gästen neu starten. Das sieht dann von Außen mitunter so aus, als ob sich der gesamte Cluster neu gestartet hat.

Das kann passieren, wenn das Netzwerk für Corosync wirklich down ist oder die Latenz für die Corosyncpakete zu hoch wird und Corosync keinen brauchbaren Link zum Ausweichen mehr zur Verfügung hat.

Vielen Dank für das Feedback.
Also wir haben dann nicht vor HA über das verteilte Netz zu machen sondern maximal noch zwischen unseren 2 Standorten mit der DarkFiber-Leitung welche auch nur ca. 1-2km voneinander entfernt sind. Bei den Restlichen Clustern würden wir uns größtenteils auf Cold-Standby oder bei ausgewählten Clustern unter Umständen noch mit Replikation arbeiten um da ggf. einen Warm-Standby dadurch zu realisieren.
Der Punkt bei dem Storage ist halt das er nun einmal angeschafft ist und nicht gerade günstig war und der somit nicht mal eben wieder ersetzbar ist, was mir das überreden zu einem Ceph-Cluster z.B. sehr schwer macht.
Auch ein Punkt warum mir gesagt wurde das ein Ceph-Cluster bei uns gerade nicht optimal wäre ist der hohe Netzwerktraffic bzw. die benötigte Netzwerkanbindung um dies mit sinnvoller Geschwindigkeit zu realisieren.

mfg Joe

 

[j.palm]

Braucht ihr Snapshots? Wenn nicht, ist es bei iSCSI/FC möglich, ein großes LUN zu machen und darauf ein (thick) LVM zu konfigurieren. Die einzelnen LVs sind strickt getrennt und Proxmox VE stellt sicher, dass immer nur ein Gast gleichzeitig in ein LV schreibt.
Der Nachteil ist, dass keine Snapshots möglich sind.

Also ich hab mich deswegen nochmal Firmen-Intern umgehört. Hintergrund das wir pro VM ein eigenes LUN möchten hängt wohl mit Problemen aus der Vergangenheit zusammen und zwar hatten wir unter Hyper-V ein Großes LUN für das Hyper-V Cluster dies hatte allerdings ab ner gewissen Größe die Folge das der Storage wohl teilweise mehrere Sekunden gebraucht hat um zu reagieren was ja etwas ungünstig wenn dort die VMs darauf zugreifen wollen.

mfg Joe

 

[aaron]

Bei einem Cluster über 2 Bereiche, ob das jetzt Brandabschnitte oder ganze RZ, die nahe beinander sind, sollte man folgendes Berücksichtigen:
- in jedem Teil gleich viele Nodes
- einen Tie Breaker an dritter Stelle. Dies kann, wenn es nur um einen Proxmox VE Cluster geht, auch ein QDevice sein. Sobald es um einen Hyperconvergenten Cluster geht, wird eine kleinere, aber vollständige Proxmox VE Node nötig sein, da es für Proxmox VE und Ceph einen Tie Breaker braucht. Somit muss noch ein Ceph MON auf dieser Tie-Breaker Node laufen.

Der Punkt bei dem Storage ist halt das er nun einmal angeschafft ist und nicht gerade günstig war und der somit nicht mal eben wieder ersetzbar ist, was mir das überreden zu einem Ceph-Cluster z.B. sehr schwer macht.

Verstehe ich gut, führt dann aber eben leider mitunter dazu, dass man irgendwo Kompromisse eingehen muss :-/

Auch ein Punkt warum mir gesagt wurde das ein Ceph-Cluster bei uns gerade nicht optimal wäre ist der hohe Netzwerktraffic bzw. die benötigte Netzwerkanbindung um dies mit sinnvoller Geschwindigkeit zu realisieren.

Ohne eure Situation jetzt genau zu kennen, niedrige Latenzen sind für ein nicht lokales Storage immer wichtig. Bei Ceph multiplizieren sich diese mitunter, da mehr Roundtrips über das Netzwerk nötig sind.


Ihr könntet euch schlaumachen, ob der Storagehersteller ein Storageplugin für Proxmox VE anbietet. Ich schätze die Wahrscheinlichkeit als nicht allzu groß ein, aber falls ja, sollte es das Managen des Storages für Proxmox VE deutlich leichter machen.

 

[j.palm]

Bei einem Cluster über 2 Bereiche, ob das jetzt Brandabschnitte oder ganze RZ, die nahe beinander sind, sollte man folgendes Berücksichtigen:
- in jedem Teil gleich viele Nodes
- einen Tie Breaker an dritter Stelle. Dies kann, wenn es nur um einen Proxmox VE Cluster geht, auch ein QDevice sein. Sobald es um einen Hyperconvergenten Cluster geht, wird eine kleinere, aber vollständige Proxmox VE Node nötig sein, da es für Proxmox VE und Ceph einen Tie Breaker braucht. Somit muss noch ein Ceph MON auf dieser Tie-Breaker Node laufen.

Danke für die Informationen, das werde ich bei der Planung berücksichtigen

Ihr könntet euch schlaumachen, ob der Storagehersteller ein Storageplugin für Proxmox VE anbietet. Ich schätze die Wahrscheinlichkeit als nicht allzu groß ein, aber falls ja, sollte es das Managen des Storages für Proxmox VE deutlich leichter machen.

Werde ich dann jetzt mal machen , wir nutzen für Storage aktuell HPE 3PAR an welche wir die Hosts mit 16 GBits anbinden.
Also Hosts kommen aktuell DL380 Gen9 und 10 zum Einsatz mit im Mittel ca. 256 GB RAM pro Host.

mfg Joe

 

[j.palm]

Hallo,

ich hätte nochmal eine Frage:
Ist es möglich bzw. wie ist möglich VMs zu Priorisieren ?
Hintergrund ist dass alle VMs bei uns Hochverfügbar sein sollen es aber dort VMs gibt die trotzdem wichtiger als andere sind und dementsprechend auch mit Vorzug behandelt werden sollten.

mfg Joe

 

[aaron]

Du meinst, dass die wichtigeren VMs im Falle, dass HA tätig werden muss, zuerst gestartet werden? Nein, das lässt sich im Moment nicht beeinflussen.
Du könntest im Bugtracker einen Enhancement Request aufmachen.