Planung Proxmox Cluster + Storage

[Ingo S]

Moin zusammen

Ich plane zur Zeit einen neuen Proxmox Cluster. Dieser wird wahrscheinlich aus 4 Hosts bestehen. Mich treibt die Frage um, wie ich den Storage am besten designen könnte. Zur Zeit nutzen wir Ceph. Obwohl ich Ceph wirklich super finde, was die Sicherheit und "ease of use" angeht, ist es uns nicht performant genug, gerade was die IOps angeht. Wir haben ein paar Datenbanken und die leiden sehr unter Ceph.


Daher habe ich mir heute mal ZFS angeschaut und mir mal gedanken zu 2 Lösungsszenarien gemacht. Ich hätte dazu gerne Input udn Erfahrungswert, ob die Designs Sinnvoll sind und welches davon vll besser ist.

Design 1:
Jeder Node bekommt seinen eigenen ZFS Storage. Design so wie im Anhang "Node Storage Design" gezeigt. Das Gäbe vermutlich die beste Performance, da IO Lokal stattfindet. Live Migration könnten wir lösen, indem wir vor einer Migration die VM-Images auf einen zentralen migration Storage schieben. Dieser hat das gleiche Layout wie ein einzelner Node, stellt aber nur Storage für die Migration zur Verfügung, siehe Anhang "Cluster Storage Migration Design" und wäre per NFS als shared Storage angebunden.

Vorteile:

• Höchste Performance

Nachteile:

• Bei Ausfall eines Nodes, können Maschinen nicht innerhalb weniger Minuten auf einem anderen Node hochgefahren werden, da shared Storage nur für die Migration verwendet wird.

Design 2:
Die Nodes haben, bis auf für das OS, gar keinen eigenen Storage, sondern nutzen einen zentralen redundanten Storage Server, der z.B. via 25Gbit Ethernet angebunden ist (Siehe Anhang "Cluster Central Storage Design). Die Redundanz wäre dann pro Storage Node ein 2Way Mirror, statt wie bei Design 1 ein 3Way Mirror. Dafür gäbe es aber einen zweiten Storage Server, auf den der erste repliziert wird.

Vorteile:

• Shared Storage
  • problemlose Live Migration
  • schnelles Hochfahren von VMs auf anderen Nodes, wenn ein Node ausfällt
• Ggf Kosteneffektiver?
• Backups könnten vll vom Storage Server 2 gezogen werden, was die Performance dann im Betrieb nicht beeinflusst? (Bin nicht sicher, ob man das mit Proxmox Backup Server oder Veem sauber hinbekommt)

Nachteile:

• Möglicherweise negative Auswirkungen des Netzwerks auf die IO Performance
• Bei Ausfall des Storage Servers wäre der gesamte Cluster down, oder bekäme man den auch irgendwie redundant angebunden? iSCSI? irgendwelches ZFS Netzwerk Voodoo?

Habt ihr Anregungen? Ideen? Verbesserungsvorschläge? No Gos?

 

[FrankList80]

Die Forum-Kollegen hier werden sicherlich gleich antworten. Nach vielen Jahren und vielen Storage 'Dumpster-Fires' nutze ich nur noch local Storage, kein HA, und versuche die Availiability ausschliesslich über "Lightning Fast" Backups & Restore zu lösen (alternative: Application Aware / Level HA), gebe aber auch gegenüber Kunden jeweils RPO Zero und RTO Zero auf. (Deswegen nur SME Kunden). Ein Realtime-Uptime-Monitoring mit Alerting ist hier aber Pflicht. Den PBS (oder VEEAM/Storware) versuch ich maximal "Dick" an die individuellen Host anzubinden (und den PBS an sich dann nochmal zu spiegeln). Ist "Besonders" ich weiss, aber die Ops-Komplexität konnte ich dadurch deutlich reduzieren (insb. wenn ein Dritter ggf. den Restore machen muss).

​

---

[Virtualization Support for SME and NGOs | DLI Solutions ]

 

[quanto11]

kein HA, und versuche die Availiability ausschliesslich über "Lightning Fast" Backups & Restore zu lösen

das ist meiner Meinung nach vollkommen Absurd, sowas wird man vielleicht in sehr kleinen Unternehmen mit kleinen VMs umsetzen können, jedoch alles was über 200Gb groß ist, ist mit einem erhöhtem Zeitlichen Verlust zu rechnen, ganz zu schweigen wenn es mal zu Hardware Problemen kommt.

 

[Falk R.]

Habt ihr Anregungen? Ideen? Verbesserungsvorschläge? No Gos?

Moin Ingo,

hier mal meine Meinung dazu.

1. Für Standard VMs weiterhin Ceph benutzen und für die DB Server auf eventuell nur 2 Hosts einen ZFS Pool erstellen. Die DB VMs mit 1 Minute Frequenz replizieren für ein DR (HA) mit sehr kleinem Verlust. Live Migration geht damit ja auch.
Das ist die günstigere und von mir bevorzugte Variante.

2. Wenn du keinen Verlust von Daten, beim Verlust eines Nodes, haben möchtest würde ich ein Storage wie z.B. NetApp per NFS anbinden. Da gibt es Performance und auch Verfügbarkeit, aber eben für einen deutlich höheren Preis.

iSCSI oder ähnliches würde ich nicht machen, außer du hast ein Storage, was du weiter benutzen möchtest.
Backups vom zweiten Node bekommst du beim PBS, Veeam und allen anderen mir bekannten Lösungen nicht hin. Da brauchst du eher einen DB Cluster und da kannst du die Backups vom Standby Server machen, außer du fährst Active-Active.

 

[FrankList80]

das ist meiner Meinung nach vollkommen Absurd, sowas wird man vielleicht in sehr kleinen Unternehmen mit kleinen VMs umsetzen können, jedoch alles was über 200Gb groß ist, ist mit einem erhöhtem Zeitlichen Verlust zu rechnen, ganz zu schweigen wenn es mal zu Hardware Problemen kommt.

Addendum A) Anwendungsfall vorallem dezentral OnPrem/Edge / Addendum B): 1x "cold" pre-configured PVE stell ich daneben, mit Notfall NVMe und SSD, sowie einen "Harten" 3 Jahre Hardware Refresh des primären PVE Und mit dedizierten 10GB NICs zum PBS (200GB VMs bei 10 GB NIC ist "Machbar") , sowie dem Cold DR-PVE daneben. Ja, muss man mögen - ist ein sehr simplifizierter Ansatz und kommt auf den Kunden und die Skills vom Ops-Team OnSIte an. Ich versuche, ähnlich der "Cattle vs. Pets", Diskussion den PVE als "Cattle" (Heresie, ich weiss) anzusehen - fällt er gänzlich aus < 3 Jahren (selten), aktiviere ich den Cold, und bestelle neu einen COTS x86 und stell ihn wieder hin zur Site - Austauschbar, einfache Architektur, kein Expertenwissen z.B. beim OPS Team OnPrem notwendig. Der "Care-Aufwand" verschiebt sich in Verfügbarkeit des PBS (auch OnSite sind die 10GB PBSe). Aber wie richtig angemerkt: Weder RTO noch RPO ist Zero (15-30 Min) bei zeitnahem Alerting, mässig grossen VMs und Workloads (z.B. kleinere ERP, Non-Shopfloor VMs, CRM, VDI).

 

[Ingo S]

Danke erstmal für euren Input.

@FrankList80
Interessantes Konzept. Allerdings ist das bei uns so nicht umsetzbar. Wir haben ein paar dicke Brummer von VMs, die sich im TB Bereich bewegen. Da wäre die Recovery Zeit einfach zu lang. Letztlich hängt sowas natürlich immer an den Anforderungen des Kunden. Wenn der Fein ist mit "Wenn der Node ab raucht, sind wir in ca 30min wieder Online", dann ist das völlig OK.
Was ich an unserem Ceph so mag ist: Wenn ein Host ab raucht sind wir in 5-10min wieder Online, wenn es während der Arbeitszeit passiert.

@Falk R.
Deine Lösung 1 ist auch spannend. Wir haben allerdings ein Ticket/Kassensystem da laufen, bei dem wir uns im Grunde 0 Byte Datenverlust leisten wollen und auch unsere Buchhaltung läuft darauf.
In dem Fall geht deine Empfehlung ja eher auch zu einem zentralen Storage. Allerdings finde ich z.B. NetApp zu closed und zu teuer. Den würde ich dann evtl. mit z.B. TrueNAS selbst bauen.
Wie ist deine Erfahrung mit NFS? Hast du ne grobe Hausnummer, was man an Performance Impact gegenüber lokalem ZFS erwarten kann, was IOps angeht? Ich schätze für ganz normale Datenbanken und VMs ist das völlig ausreichend?

Später wollen wir vermutlich auch unsere Desktops durch Terminalserver ablösen. Aber ich denke, dafür bauen wir einen separaten Cluster, bzw. ein separates Storage.

 

[floh8]

NFS ist für ne normal ausreichend, aber was ist normal? Es kommt drauf an, wie viele Anwender gleichzeitig zugreifen. iSCSI hat auf jeden Fall mehr IOPS als NFS. Zumal du nicht noch extra Dateisystem Layer dazwischen hast.
Wenn du shared Storage gehen willst, Bau dir doch ein Storage Cluster selber. Da gibts Anleitungen wie du mit 2 Servern und nem Dual Controller JBOD, corosync und Pacemaker einen activ-passiv Cluster bauen kannst. Wenn zfs als Basisdateisystem ein gesetzt wird, kannst du es noch gut für Schreib-Vorgänge tunen oder du nimmst halt full flash. Als Protokoll kannst dann iSCSI für DBs nehmen.
Wenn du es besonders Latenzarm haben willst, kannst du noch RDMA oder NVMEoverTCP (nur NVMEs) implementieren.

 

[Falk R.]

In dem Fall geht deine Empfehlung ja eher auch zu einem zentralen Storage. Allerdings finde ich z.B. NetApp zu closed und zu teuer. Den würde ich dann evtl. mit z.B. TrueNAS selbst bauen.
Wie ist deine Erfahrung mit NFS? Hast du ne grobe Hausnummer, was man an Performance Impact gegenüber lokalem ZFS erwarten kann, was IOps angeht? Ich schätze für ganz normale Datenbanken und VMs ist das völlig ausreichend?

Du hast auf jeden Fall die zusätzlichen Latenzen des Netzwerks und den Overhead von NFS. In der Regel ist das kein Problem, ich nutze aber auch gern Latenzarme Netzwerke mit 25GBit+ und wenn du deinem NAS, NVMEs spendierst, sollte da kein User meckern.

Wenn du da ein TrueNAS dahinter hängst, wie baust du dir denn da deine Redundanz auf?

 

[Ingo S]

Du hast auf jeden Fall die zusätzlichen Latenzen des Netzwerks und den Overhead von NFS. In der Regel ist das kein Problem, ich nutze aber auch gern Latenzarme Netzwerke mit 25GBit+ und wenn du deinem NAS, NVMEs spendierst, sollte da kein User meckern.

Ja, wir werden dafür einen 2x oder 4x redundanten 25Gbit Uplink zum NAS nutzen. Der Storage wird auf jeden Fall mit SSDs gebaut. Es ist noch nicht ganz raus, ob NVME oder SAS. Ich hatte auch kurz dran gedacht, ob NVMEoF nicht auch was wäre. Ich finde aber nicht raus, ob das dann ebenfalls wie ein großer verteilter Speicher funktioniert, oder ob man das wie bei iSCSI dann auch partitioniert die Partitionen bestimmten Hosts als "Gerät" zuordnet und dann das Filesystem "quasi lokal" einrichtet. Aber ich glaube, das ist eh nichts für uns. Wäre vermutlich overkill.

Wenn du da ein TrueNAS dahinter hängst, wie baust du dir denn da deine Redundanz auf?

Ich habe mir dieses Detail noch nicht genau angeguckt. Es muss nicht zwingend TrueNAS sein. Ich war aber davon ausgegangen, dass man mit TrueNAS auch remote replication gemütlich über die GUI bauen kann. Gemacht hab ich das aber bisher noch nie.
Mir fallen aber zwei Möglichkeiten ein die Redundanz umzusetzen.

1. Via ZFS send/receive, wie du schon vorgeschlagen hast, jede Minute oder 30s oder whatever. Das würde uns immer noch vor Datenverlust bei Ausfall eines PVE Nodes bewahren, aber im Zweifel zum Verlust von 1min Daten zwischen Storage1 und Storage2 führen, wenn Storage 1 ausfällt. Das ist ein kleines bisschen besser, als dein Vorschlag 1
2. Ich könnte Storage 2 via iSCSI (grusel) oder NVMEoF/TCP an den Storage1 hängen und den kompletten Storage 2 zu einem live Mirror von Storage1 machen. Das käme aber mit einer performance penalty bei Schreibvorgängen daher. Da müsste ich sehen, wie groß der ist und wie man bei Ausfall von Storage1 dann Storage2 live nutzbar bekommt. Ist ja dann ein iSCSI oder NVMEoF Target und kein ZFS System.

Aber so ist das immer, überall Kompromisse

Für das Failover hatte ich auch gerade eine Idee.
iSCSI Targets an mehrere Server zu binden ist natürlich eine doofe Idee, außer man möchte Datensalat produzieren. Aber ich könnte die gleiche LUN ja auch lokal read-only einbinden und via NFS exportieren.
Bei Ausfall von Storage1 würde ich das NFS dann writeable schalten. Dann sind zwar alle VMs erstmal offline, lassen sich aber über den NFS Storage wieder starten, wenn man die config der VMs angepasst hat. Die Anpassung dürfte mit sed recht schnell gehen.
Das ist natürlich nur was für den absoluten Desaster Fall, bei einem physischen Hardware defekt auf Storage1.

 

[Falk R.]

Ja, wir werden dafür einen 2x oder 4x redundanten 25Gbit Uplink zum NAS nutzen. Der Storage wird auf jeden Fall mit SSDs gebaut. Es ist noch nicht ganz raus, ob NVME oder SAS. Ich hatte auch kurz dran gedacht, ob NVMEoF nicht auch was wäre. Ich finde aber nicht raus, ob das dann ebenfalls wie ein großer verteilter Speicher funktioniert, oder ob man das wie bei iSCSI dann auch partitioniert die Partitionen bestimmten Hosts als "Gerät" zuordnet und dann das Filesystem "quasi lokal" einrichtet. Aber ich glaube, das ist eh nichts für uns. Wäre vermutlich overkill.

NVMe over TCP kannst du ganz genau so wie iSCSI nutzen, ist aber performanter und das Multipathing ist einfacher.
Da arbeitest du dann wieder mit LVM Volumes, außer du willst dich in das ocfs Rabbithole begeben.

Ich habe mir dieses Detail noch nicht genau angeguckt. Es muss nicht zwingend TrueNAS sein. Ich war aber davon ausgegangen, dass man mit TrueNAS auch remote replication gemütlich über die GUI bauen kann. Gemacht hab ich das aber bisher noch nie.
Mir fallen aber zwei Möglichkeiten ein die Redundanz umzusetzen.

Da sind wir wieder bei Replikation und Asynchron.
Ich habe damit noch nicht gearbeitet, aber Open-E JovianDSS soll auch synchrone Spiegel und ZFS over iSCSI können.

 

[Ingo S]

Dann würde ich wohl tatsächlich NVME bevorzugen, sofern uns das gegenüber SAS dann nicht ein Vermögen extra kostet. Das muss sich dann bei der Marktanalyse zeigen. ocfs Rabbithole? Ich falle immer in solche Rabbitholes... Oh weia
Aber ich hab gerade gesehen, das ist Oracle. Nope... Nopedinope

Letztendlich stehen Ausfallsicherheit/Redundanz und Performance auf verschiedenen Seiten des Kompromisses, den man finden muss.
Ich hab mir gerade das JovianDSS angesehen und es scheint von den Features her genau das zu sein, was ich suche, nur in fertig und besser.
Nur: Der Preis... Uff... der Sprengt unser Budget definitiv.

Proxmox unterstützt allerdings zfs over iSCSI und DAS!!! sieht interessant aus, auf jeden Fall für die Anbindung des Storage an Proxmox.

Bleibt dann die Frage, wie ich die Redundanz mit dem zweiten Storage Server tatsächlich umsetze. Das ist jedenfalls echt kein einfaches Unterfangen.

Mir gefällt die Idee sehr, auf Storage1 vdevs im 3 Mirror Mode zu bauen, bei dem eine der drei SSDs ein iSCSI oder NVMEoF Target ist. Damit würde ich ein bisschen Kosteneffektiver sein, statt das Storage2 ein kompletter Klon von Storage1 ist. Letzteres wäre mit 4facher Redundanz n bisschen heftig. In Ceph fahren wir zur Zeit ne Size von 3/2

Ich habs (auch für mich) mal aufgezeichnet:

 

[Falk R.]

Dann würde ich wohl tatsächlich NVME bevorzugen, sofern uns das gegenüber SAS dann nicht ein Vermögen extra kostet. Das muss sich dann bei der Marktanalyse zeigen. ocfs Rabbithole? Ich falle immer in solche Rabbitholes... Oh weia
Aber ich hab gerade gesehen, das ist Oracle. Nope... Nopedinope

Wenn du nicht bei DELL oder HPE kaufst, sind NVMe deutlich günstiger als SAS. Wenn du tipps für gute Preise brauchst, ticker mich einfach persönlich an.
P.S. ich verkaufe nix, aber ich weiß wo man gute Hardware bekommt.

Letztendlich stehen Ausfallsicherheit/Redundanz und Performance auf verschiedenen Seiten des Kompromisses, den man finden muss.
Ich hab mir gerade das JovianDSS angesehen und es scheint von den Features her genau das zu sein, was ich suche, nur in fertig und besser.
Nur: Der Preis... Uff... der Sprengt unser Budget definitiv.

Ja, das ist oft das Problem. Ich glaube das ist auch der Grund warum man die Lösung nicht so oft sieht.

Proxmox unterstützt allerdings zfs over iSCSI und DAS!!! sieht interessant aus, auf jeden Fall für die Anbindung des Storage an Proxmox.

Aber Vorsicht, es gibt 3 verschiedene Implementationen von ZFS over iSCSI. Da musst du wohl tiefer in das rabbithole rein.

Bleibt dann die Frage, wie ich die Redundanz mit dem zweiten Storage Server tatsächlich umsetze. Das ist jedenfalls echt kein einfaches Unterfangen.

Mir gefällt die Idee sehr, auf Storage1 vdevs im 3 Mirror Mode zu bauen, bei dem eine der drei SSDs ein iSCSI oder NVMEoF Target ist. Damit würde ich ein bisschen Kosteneffektiver sein, statt das Storage2 ein kompletter Klon von Storage1 ist. Letzteres wäre mit 4facher Redundanz n bisschen heftig. In Ceph fahren wir zur Zeit ne Size von 3/2

Ich habs (auch für mich) mal aufgezeichnet:
View attachment 83009

Sieht nett aus, aber nimm lieber die Read Intensive NVMe. Du schaffst es eh nicht die 5 Jahre lang jeden Tag einmal komplett neu zu beschreiben.
Ich nutze die MU NVMe nur für Special Devices, da dort die Schreiblast höher ist.

 

[Ingo S]

Haha ja, IT ist voll mit Rabbitholes. Darum mag ich den Job so gern. Ich habe gerade nen ganz netten Guide gefunden, wie das mit ZFS over iSCSI und Proxmox funktioniert: https://blog.haschek.at/2023/zfs-over-iscsi-in-proxmox.html
Also LIO it is...

Die 3.2TB SSDs habe ich jetzt durch 7.68TB ersetzt. Wir brauchen ca 15TB usable Storage direkt beim Umzug. Deshalb habe ich den Storage jetzt so umgebaut, dass wir mit 3 vdevs auf 20TB kommen. Die 7.68er scheinen auch insgesamt günstiger pro TB zu sein.
So haben wir etwas Luft und können später in dem 24 Disk System auf bis zu 55TB erweitern, falls das nötig werden sollte

Funfact bzgl. Schreiblast: Wir haben auf unserem Ceph ERHEBLICH mehr writes als reads. Ich habe bis heute nicht rausgefunden, warum das so ist.

Vielleicht ist das eine Eigenheit von Ceph, irgend eine Art IO amplification oder so, keine Ahnung.
Aber du hast Recht, bisher haben wir noch keine Einzige der SSDs im SSD Pool kaputt geschrieben. Es reichen daher wohl tatsächlich die 1DWPD SSDs.

Ich danke dir erstmal für dein Feedback. Das war sehr hilfreich.

Wenn ich mal nen ruhigen Tag hier habe oder so, schreibe ich vll mal einen kompletten Guide für das Setup, dass wir hier dann fahren.

 

[Falk R.]

Haha ja, IT ist voll mit Rabbitholes. Darum mag ich den Job so gern. Ich habe gerade nen ganz netten Guide gefunden, wie das mit ZFS over iSCSI und Proxmox funktioniert: https://blog.haschek.at/2023/zfs-over-iscsi-in-proxmox.html
Also LIO it is...

Die 3.2TB SSDs habe ich jetzt durch 7.68TB ersetzt. Wir brauchen ca 15TB usable Storage direkt beim Umzug. Deshalb habe ich den Storage jetzt so umgebaut, dass wir mit 3 vdevs auf 20TB kommen. Die 7.68er scheinen auch insgesamt günstiger pro TB zu sein.
So haben wir etwas Luft und können später in dem 24 Disk System auf bis zu 55TB erweitern, falls das nötig werden sollte

Funfact bzgl. Schreiblast: Wir haben auf unserem Ceph ERHEBLICH mehr writes als reads. Ich habe bis heute nicht rausgefunden, warum das so ist.
View attachment 83041

Das ist nicht nur bei euch so, sondern seit vielen Jahren auf den meisten Servern.
Das Grundrauschen besteht oft aus kleinen Writes für Logs und ein paar Nutzerdaten. Abrufen tut der Nutzer aber oft Daten welche noch im RAM gecached sind.
Sobald aber Last kommt, die nicht nur aus Grundrauschen besteht, dreht sich das ganze ganz schnell wieder. Gerade eine große Auswertung in einer Datenbank erzeugt sehr Massive Reads. Die Performance der NVMe brauchst du ja auch nicht unbedingt für das Grundrauschen, sondern die Peakleistung bei den Leistungshungrigen Operationen.
Aus genau diesen Gründen passt Ceph oft auch für die meisten Datenbanksysteme, weil wenn writes kommen sind die seltenst so massiv, das ein NVMe Ceph da Probleme bekommt. Reads bekommt Ceph ja auch sehr gut abgefackelt. Bei meinen Kunden sind die einzigen Datenbanken, welche nicht Ceph geeignet sind, eh nicht virtualisiert wie z.B. SAP oder im Krankenhaus Orbis. Da wird dann oft mit DB mitteln (HANA oder Oracle) eine Replikation / Log Shipping auf einen Sekundärserver gemacht, wo ich auch öfters NVMe einfach im mdraid Mirror fahre.

Bevor du dich da in irgendwelchen Rabbitholes vertiefst, check mal lieber welche Last ihr wirklich habt und wenn Systeme zu bestimmten Zeiten am Limit sind, einmal genau schauen welche Komponente da am Limit ist.

Vielleicht ist das eine Eigenheit von Ceph, irgend eine Art IO amplification oder so, keine Ahnung.
Aber du hast Recht, bisher haben wir noch keine Einzige der SSDs im SSD Pool kaputt geschrieben. Es reichen daher wohl tatsächlich die 1DWPD SSDs.

Ich danke dir erstmal für dein Feedback. Das war sehr hilfreich.

Wenn ich mal nen ruhigen Tag hier habe oder so, schreibe ich vll mal einen kompletten Guide für das Setup, dass wir hier dann fahren.

Ich schreibe keine aufwändigen Anleitungen. Mein Credo ist KISS (Keep It Simple & Solid).
Oft bringt es mehr sich die alte Umgebung genau anzuschauen um die echten Bottlenecks zu finden, statt ein overengineered Setup aufzufahren.
P.S. oft soll das Storage bei der Virtualisierung bremsen, aber bei 80% aller Kunden mit diesem "Problem" stelle ich nachher fest, dass allein die CPU Überbuchung das System bremst und das Storage sich langweilt.

 

[Ingo S]

Bevor du dich da in irgendwelchen Rabbitholes vertiefst, check mal lieber welche Last ihr wirklich habt und wenn Systeme zu bestimmten Zeiten am Limit sind, einmal genau schauen welche Komponente da am Limit ist.

Ich schreibe keine aufwändigen Anleitungen. Mein Credo ist KISS (Keep It Simple & Solid).
Oft bringt es mehr sich die alte Umgebung genau anzuschauen um die echten Bottlenecks zu finden, statt ein overengineered Setup aufzufahren.
P.S. oft soll das Storage bei der Virtualisierung bremsen, aber bei 80% aller Kunden mit diesem "Problem" stelle ich nachher fest, dass allein die CPU Überbuchung das System bremst und das Storage sich langweilt.

Bei uns ist es eine Kombination aus beidem. Unser Ceph Main Storage besteht aus HDDs. Da kommen wir mit 32 parallelen 4k small reads auf ca 1500-1800iops bei 30 Platten. Das kommt hin mit dem was ich erwarten würde.
Beim SSD Pool hab ich noch nie mehr als 6000iops gesehen. Aber unser ganzer Servercluster ist eh schwerst modernisierungsbedürftig. Da laufen noch alte Xeon E5 2650 v4 mit 24/48 Threads und 2,2GHz. Die ziehen heute einfach keine Wurst mehr vom Brot. Das ganze Setup war auch ursprünglich gar nicht für den hyperconverged Betrieb angeschafft sondern wurde nachträglich umgebaut.

Das Tagesmaximum auf einem unserer 32 Kern Nodes (ja die sind gemischt) sieht dann so aus:

CPU Last ist noch relativ OK, das geht schlimmer, aber IO delay in der Spitze von 10% sagt für mich, es ist eher der Storage. Ich meine nicht die beiden Nachts, da läuft das Backup. Mitten am Nachmittag gab es auch nochmal n Peak. Und so n Grundrauschen von 2% IO delay finde ich auch ein bisschen hoch. Ich würde den eigentlich immer unter 1% erwarten, im normalen Betrieb.
Ich hab da keine Vergleichswerte, aber normalerweise merkt man es den VMs deutlich an, sobald IO delay "sichtbar" wird.

Unser wichtigster Server fürs Kassensystem ließ sich z.B. überhaupt gar nicht darauf betreiben. Deshalb läuft der als Übergangslösung erstmal allein auf einem Ryzen 9 7950 mit SAS SSD Storage im RAID6. Das rennt jetzt erstmal wie nichts gutes.
Zeitnah muss das aber jetzt einmal auf homogene, moderne Beine gestellt werden. Wir brauchen im Grunde einen kompletten IT Overhaul. Da sind wir auch schon dran.
Aber 2 Mitarbeiter für 140 Arbeitsplätze und eine komplexe Infrastruktur mit eigenem kleinen Datacenter, das ist nicht so ideal.

Mir hilft Anleitungen und/oder Pläne schreiben immer beim Denken. Meistens erkenne ich dann design flaws und brain farts. Und wenn das dann fertig ist, ist die Dokumenation auch fast schon fertig.

 

[Falk R.]

CPU Last ist noch relativ OK, das geht schlimmer, aber IO delay in der Spitze von 10% sagt für mich, es ist eher der Storage. Ich meine nicht die beiden Nachts, da läuft das Backup. Mitten am Nachmittag gab es auch nochmal n Peak. Und so n Grundrauschen von 2% IO delay finde ich auch ein bisschen hoch. Ich würde den eigentlich immer unter 1% erwarten, im normalen Betrieb.
Ich hab da keine Vergleichswerte, aber normalerweise merkt man es den VMs deutlich an, sobald IO delay "sichtbar" wird.

CPU Last ist nie ein Problem. Du kannst aber auch bei 20% Last die CPU schon so überbuchen, dass du extreme Latenzen auf den CPUs hast.
Das dein IO Delay so hoch ist, ist schon ein Warnzeichen. In meiner Testumgebung habe ich Peaks bis 3%, aber bei den Produktiven Clustern meiner Kunden sehe ich in der Regel nie mehr als 1% Delay.
Check mal beim Benchmark oder wenn es gefühlt nicht optimal läuft:
cat /proc/pressure/cpu
cat /proc/pressure/io

Unser wichtigster Server fürs Kassensystem ließ sich z.B. überhaupt gar nicht darauf betreiben. Deshalb läuft der als Übergangslösung erstmal allein auf einem Ryzen 9 7950 mit SAS SSD Storage im RAID6. Das rennt jetzt erstmal wie nichts gutes.
Zeitnah muss das aber jetzt einmal auf homogene, moderne Beine gestellt werden. Wir brauchen im Grunde einen kompletten IT Overhaul. Da sind wir auch schon dran.
Aber 2 Mitarbeiter für 140 Arbeitsplätze und eine komplexe Infrastruktur mit eigenem kleinen Datacenter, das ist nicht so ideal.

Mir hilft Anleitungen und/oder Pläne schreiben immer beim Denken. Meistens erkenne ich dann design flaws und brain farts. Und wenn das dann fertig ist, ist die Dokumenation auch fast schon fertig.

Ich glaube auch das Kassensystem könntest du mit Ceph betreiben, wenn du das System modern aufstellst.