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).