Shared LVM gewünscht: FC-SAN?

S

sgw

Active Member
Proxmox Subscriber
Apr 5, 2024
226
50
33
www.oops.co.at
Sorry, wenn ich noch nicht das Forum durchsucht habe .. ich bin bei einem Kunden (da gibt es einen längeren Thread) recht zufrieden mit Shared LVM auf einem FC-SAN.
Dort war die Hardware schon da, und ich musste keine Hardware-Auswahl treffen.

Jetzt darf ich bei einem anderen Kunden from scratch konzipieren, bin schon relativ weit mit meiner Skizze für 2 Nodes mit jeweils local storage. Ich wollte denen in Phase 1 den Einstieg in die Virtualisierung leichter und günstiger machen. Heute aber waren die Geschäftsführer sehr offen für HA .. mit Shared Storage. Gut! Jetzt soll ich neu anbieten und ich frage mich und hiermit Euch:

Welches Konzept ist da der beste Mix aus Kosten und Erweiterbarkeit? Ich denke an ein FC-SAN, ausgelegt für 3x2 Kanälen FC (Phase 1: 2 Nodes dran), und darauf dann Shared LVM.

So hab ich das bei dem anderen Kunden. Aber evtl ist FC gar nicht gescheit, und es gibt eine einfachere und günstigere Variante?

Danke für jegliche Tips oder Links, sorry, wenn ich eine FAQ stelle, ich werde natürlich auch selbst noch etwas weiter suchen, wäre aber für ein paar flotte Ja/Neins dankbar.
 
FC ist nicht falsch, aber wenn ihr eh komplett neu kauft, ist FC für zwei Nodes meist der teuerste Weg (HBAs, zwei Switches, Optiken, oft noch Lizenzen). Mit 25G Ethernet und iSCSI oder NVMe/TCP landest du beim gleichen Shared LVM und sparst deutlich. Bei zwei Nodes kannst du das SAN je nach Modell sogar direkt anstöpseln ohne Switch dazwischen. Wenn du FC schon kennst und beim Kunden Ersatzteile und Know-how vorhanden sind, spricht aber auch nichts dagegen.

Wichtiger sind aber zwei andere Punkte: bei 2 Nodes brauchst du zwingend ein QDevice als dritten Quorum-Teilnehmer, sonst geht dir der Cluster aus, wenn ein Node ausfällt. Reicht ein kleiner Rechner oder eine VM woanders im Haus. Und das SAN ist dann dein neuer SPOF, also mindestens Dual-Controller und redundante Pfade, sonst hast du statt HA auf Node-Ebene eben ein Risiko auf Storage-Ebene.

Thema Snapshots bei Shared LVM (thick) würde ich vorher mit dem Kunden klären, seit PVE 9 gibt's da ja die Unterstützung, aber ich hab das produktiv noch nicht im Dauerbetrieb, würde ich also testen bevor du es zusicherst. Und als günstige Zwischenstufe, falls das Storage-Budget kippt: 2 Nodes mit lokalem ZFS plus pvesr-Replikation und QDevice. Kein echtes HA, RPO ist dein Replikationsintervall (typisch 15 min), kostet aber nur Platten und du kannst Shared Storage später immer noch nachrüsten. Was darf's denn beim RPO sein, muss das wirklich Null sein?
 
  • Like
Reactions: ThoSo and Johannes S
Beim Kunden sind weder Ersatzteile noch Knowhow vorhanden :)
Denen geht es ja genau darum, dass die VMs ohne (viel) Unterbrechung weiter laufen, auch wenn ich grad nicht erreichbar bin.

Ich neige zu 25G und iscsi ...

QDevice: danke für den Reminder, ist mir bewusst. 3. Device im LAN machbar, habe mehrere Debian-Server etc / das wird schon.

Snapshots auf shared LVM: beim Bestandskunden war das zu Anfang so: "brauchen wir nicht, kein Problem", und dann wollten sie es innerhalb von 2 Wochen doch ;) Dort nutzen wir das seitdem, ohne Probleme (irgendein Häkchen muss gesetzt sein, das müsste ich nachschlagen).

Von den Kosten her bedeutet es ja eine Art Verlagerung: ich brauche in den Nodes keinen großen Storage-Controller mehr, keinen Platten-Käfig für zB 16 Slots, keinen extra Kabelsatz. Das Geld dafür kann dann ins SAN und die benötigten Steckkarten wandern ...

Als Orientierung: für die Nodes planen wir, refurbished Server einzusetzen, mit neuen SSDs drin. Dh. auch beim SAN ist refurbished eine Option ...

(Ich schaffe auch ein NAS für Backups an, aber schon klar, so eine Hardware ist nichts für produktives Shared Storage)

Danke @Bu66as für die flotte erste Antwort!
 
Bu66as said:
FC ist nicht falsch, aber wenn ihr eh komplett neu kauft, ist FC für zwei Nodes meist der teuerste Weg (HBAs, zwei Switches, Optiken, oft noch Lizenzen). Mit 25G Ethernet und iSCSI oder NVMe/TCP landest du beim gleichen Shared LVM und sparst deutlich. Bei zwei Nodes kannst du das SAN je nach Modell sogar direkt anstöpseln ohne Switch dazwischen.
Click to expand...
Die meistens FC-SANs, die ich in der letzten Zeit verkauft habe sind bereits mit 4 FC-Ports pro Kontroller ausgestattet und man kann es direkt verkabeln - wie im Beispiel mit iSCSI auch. Switch benötigt man dabei nicht. Da FC hier meist mit 32 Gb daherkommt ist es bei wahrscheinlich höheren Kosten aber auch schneller als 25 Gb. Im Endeffekt musst du genau ausrechnen was dann günstiger ist. Je nach Tagespreisen kann es mal das eine und mal das andere sein. Ob iSCSI oder FC macht hier keinen technologisch keinen Unterschied, da beides dann Inselnetze sind und technisch beide als LVM zur Verfügung gestellt werden.

Rechne dir alternativ zu 2 Nodes + SAN auch mal 3 Nodes mit CEPH aus. Je nach Redundanzlevel der Platten im SANs kann das u.U. vergleichbar im Preis sein und damit hast du anständiges HA mit mehr Redundanzen, bessere Lesegeschwindigkeit UND Features wie Thin Provisioning , Snapshots und Komprimierung. Das steht und fällt aber damit was du genau willst. Alles ist leider nicht so leicht rauszufinden und ein sehr kundenwünschenorientieres Problem.

sgw said:
Ich schaffe auch ein NAS für Backups an, aber schon klar, so eine Hardware ist nichts für produktives Shared Storage)
Click to expand...
Das wäre dann auch dein Ort für das QDevice.
 
  • Like
Reactions: ThoSo, Johannes S and Bu66as
Refurbished bei den Nodes ist fein, beim SAN würd ich's mir gut überlegen. Das Ding ist dein einziger SPOF und beim Kunden kann keiner was tauschen. Wenn refurb, dann nur mit laufendem Ersatzteil-/Supportvertrag und einem Modell, das noch Firmware bekommt. Ein Controller-Defekt ohne Ersatzteil ist echt nicht lustig, wenn du gerade nicht erreichbar bist.

Das Häkchen, das du suchst, ist snapshot-as-volume-chain am Storage, also pvesm set <storage> --snapshot-as-volume-chain 1.

Ceph lohnt sich preislich durchzurechnen, aber denk beim Vergleich auch an den Betrieb. Kein Know-how beim Kunden und du nicht immer greifbar: ein Dual-Controller-SAN mit iSCSI ist halt langweilig und wartungsarm, Ceph will betreut werden (Upgrades, OSD-Tausch, Recovery wenn ein Node fehlt).

Eine Sache würd ich mit den GFs noch klären: HA heisst, die VMs werden nach dem Fencing auf dem anderen Node neu gestartet, also ein paar Minuten weg plus Bootzeit. Reicht für "ohne viel Unterbrechung" meistens locker, aber das sagt man besser vorher als hinterher.
 
  • Like
Reactions: ThoSo, Johannes S and fireon
@LnxBil danke!

@Bu66as Das war auch mein Gedanke: SAN lieber neu, weil wichtig. Und auch, weil das SAN dann länger in Betrieb bleiben soll, während man dann die refurbished Nodes Schritt für Schritt ersetzt etc. (vielleicht dann in 1-2 Jahren auch mal neu gekaufte Nodes. Jetzt geht es mal um Einführung Virtualisierung, Ablösung physische Kisten)

Das Häkchen sagt mir nix, aber vielleicht, weil wir das damals eher im GUI gesetzt haben? Lange nicht angesehen, der dortige "junior admin" (nennen wir ihn so) ist soweit zufrieden.

Ceph: lieber nein. So langweilig und robust wie möglich, exakt.

Etwas konkreter: dh. ich brauche pro Node 1-2 x 25Gb NIC drin? Und in Stufe 1 (2 Nodes, 1 SAN) kann ich evtl direkt anschließen? Hast Du da ein konkretes Beispiel für so ein Gerät? Ahja, allzu viel Storage brauchen wir erstmal gar nicht. Für Phase1 komme ich mit 5-8 TB netto locker durch. Dies nur am Rande.

Failover-Info an GFs: ja, guter Punkt. Evtl hab ich denen heute gesagt, das geht ohne Unterbrechung ;-) *hust*
 
  • Like
Reactions: Johannes S and ThoSo
Du schießt in meinen Augen mit Kanonen auf Spatzen. Du hast zwei PVEs und kommst mit unter 10TB aus.
Selbst wenn ein Knoten in deinem genügend redundanten PVE-Cluster spontan ausfällt, dann stehst du, im Sinne von HA, im Regen. PVE-Cluster können das einfach nicht.
Wenn du nun einen zentralen Netzspeicher einrichtest, der tatsächlich HA bietet, ist das teuer und erfordert dann dort Knowhow. Dein PVE-Cluster kann aber immer noch kein HA will aber trotzdem verwaltet werden.
Statte lieber jeden Node mit:
  • rattenschnellen (+25GB) für dedizierte Datenverkehr Netzwerkschnittstellen aus.
  • installiere zusätzlich mindestens einen PBS, auf dem du in passender Frequenz Sicherungen ablegst. Bei <10TB Nutzdaten reicht dort eine 4TB NVME.
  • Kommuniziere, dass ein Restore eines 5TB-"Monsters" eben 10min dauern kann.
  • Letzeres kannst du sogar mit schnöden bash-Scripten automatisieren.
  • Schon bist du alle Probleme, die ein Cluster durchaus mitbringt, los.
Das Angebot seitens Proxmox, durch "Clustering" günstig in Richtung HA zu rücken, ist schelmisch bis Schlangenöl.
 
Last edited:
Dass PVE-Cluster kein HA können, ist mir zu pauschal. Node fällt aus, wird gefenced, Gäste starten auf dem verbliebenen Node neu. Das läuft bei mir seit Jahren. Was es nicht ist: Fault Tolerance im VMware-FT-Sinn, also unterbrechungsfrei. Steht aber oben schon. Restore aus dem PBS ist Handarbeit und dauert länger, je nach Größe, und genau das will @sgw ja loswerden für die Zeiten in denen er nicht erreichbar ist. PBS braucht er trotzdem, aber als Backup, nicht als HA-Ersatz.

@sgw zu deinen Fragen: 2x 25G pro Node fürs Storage, also ein Pfad auf Controller A, einer auf Controller B, dann mit Multipath drüber. Corosync gehört auf eine eigene Leitung, nicht mit ins Storage-Netz, sonst flappt dir das Quorum wenn das SAN mal Last hat. Zweiter Corosync-Ring übers normale LAN ist schnell mitgenommen und hat mir schon mal den Cluster gerettet.

Direktanschluss ohne Switch geht bei den üblichen Dual-Controller-Einsteiger-Arrays problemlos, die haben meist 4 Ports pro Controller, da hängst du zwei Nodes locker dran und hast noch Luft für den dritten. Konkrete Modelle kann ich dir nicht empfehlen, die Preise ändern sich eh ständig. Bei 5-8 TB netto bist du bei sowas aber preislich gut dabei. Wichtig: Dual-Controller, aktueller Support und Servicevertrag vor Ort mit anständiger Reaktionszeit.
 
  • Like
Reactions: ThoSo and Johannes S
TErxleben said:
  • Letzeres kannst du sogar mit schnöden bash-Scripten automatisieren
Das Angebot seitens Proxmox, durch "Clustering" günstig in Richtung HA zu rücken, ist schelmisch bis Schlangenöl.
Click to expand...
Also manchmal frage ich mich bei deinen Posts hier schon, warum du Proxmox überhaupt verwendest. Ich meine, warum setzt du dann nicht einfach Debian auf, installierst QEMU und verwaltest alles mit Bash-Skripten, wenn Proxmox soviel falsch macht und/oder Schlangenöl verkauft? :p
 
Last edited:
  • Like
Reactions: DarthVaddi, ThoSo and Johannes S
Ohne jetzt über HA philosophieren zu wollen, bedeutet es für mich immer unterbrechungsfrei.
Sobald es Unterbrechungen gibt, bin ich zuverlässiger und schneller mit minimaler, simpler Bashlogik unterwegs.
Ganz ohne den Nickligkeiten, die ein Cluster mit sich bringt.
 
Joa, und ich bin kein Experte zum Thema, aber wenn man das will, macht man das wohl am besten nicht auf Hypervisorebene, sondern mit Microservices ala K8s etc. Halt blöd wenn man Windows nutzt, aber Windows ist ja von sich aus schon nicht unterbrechungsfrei von daher alles halb so wild, würde ich sagen. :p
 
  • Like
Reactions: ThoSo, Johannes S and Bu66as
proxuser77 said:
Also manchmal frage ich mich bei deinen Posts hier schon, warum du Proxmox überhaupt verwendest. Ich meine, warum setzt du dann nicht einfach Debian auf, installierst QEMU und verwaltest alles mit Bash-Skripten, wenn Proxmox soviel falsch macht und/oder Schlangenöl verkauft? :p
Click to expand...
Als erstes schätze ich die kompakte GUI von PVE zu sehr, als das ich das nur per CLI abfideln möchte. Zweitens, wie willst du denn mit zwei Nodes einen Cluster aufziehen? Komme mir bitte nicht mit schwindeligen QDevices.
Drittens, wann hast du denn das letzte Mal einen Clusternode hart ausgeschaltet und die Zeit gemessen, wann die betroffenen VMs wieder verfügbar waren? Viertens, welche HW muss denn da im Hintergrund werkeln, um einen Cluster einigermaßen sinnvoll betreiben zu können?
Gerade bei zwei Nodes, verwende ich lieber einen identischen als Failovernode, der mit ca. 100 Zeilen Batchscript die Funktionalität in kürzester Zeit (<3min) wieder herstellt.
Ganz sogar ohne 25GB+ Technik im Hintergrund.
 
Last edited:
proxuser77 said:
Joa, und ich bin kein Experte zum Thema, aber wenn man das will, macht man das wohl am besten nicht auf Hypervisorebene, sondern mit Microservices ala K8s etc. Halt blöd wenn man Windows nutzt, aber Windows ist ja von sich aus schon nicht unterbrechungsfrei von daher alles halb so wild, würde ich sagen. :p
Click to expand...
Wer kommt auch schon bloß auf die abstruse Idee, Windows zu virtualisieren?
 
Wäre es vielleicht möglich wieder auf das Anliegen des OP zurückzukommen? Seine Kunden sind weder die Ersten noch die Letzten, für deren Usecase die "Lightvariante" der Hochverfügbarkeit ausreicht, die können das schon selbst entscheiden.

Ich hätte ja noch evaluiert, ob die Variante ZFS-Replikation ok ist ( spart Geld beim Storage, dafür minimalist Datenverlust, je bach Usecase no-go oder vertretbar).

Zum qdevice/pbs: Das würde ich dann wie von Aaron beschrieben einrichten:

aaron

Post in thread '2 Node HA Cluster'

What I maintain personally, are 2 powerful AMD EPYC nodes that run the infrastructure. The 3rd server is far less powerful in terms of CPU and memory and is using cheaper but quite a bit larger SSDs to be used as PBS for that 2-node cluster and also to remote sync another small PVE / PBS combo on the other side of the country.

On that 3rd machine I installed PVE first and PBS on top. PBS is the main functionality for that machine. On the PVE side, for now, the only guest is the qdevice container. That PBS server is there anyway, and using PVE on that one as well helps to keep using the...
  • Like

Oder falls man das das NAS OS des Vendors nutzen will: PBS und qdevice als unterschiedliche VMs oder container aufsetzen.
Also: PBS und qdevice voneinander isolieren, weil man sonst vom Cluster Schreibzugriff auf die Backups hat.
 
Last edited:
  • Like
Reactions: proxuser77, sgw, ThoSo and 2 others
Den Link-Aufbau fahr ich ähnlich, aber beim Schreibzugriff würd ich differenzieren: corosync-qnetd ist kein Cluster-Mitglied, das Ding lauscht auf 5403 und zählt Stimmen, mehr nicht. Kein Zugriff auf /etc/pve, keiner auf die Datastores. Ein qnetd direkt auf der PBS-Kiste ist also nicht wirklich gefährlich, und ein extra Container dafür ist eher Kosmetik.

Was aus meiner Sicht wirklich zählt, wenn PBS und Quorum auf einem Blech liegen: die Backups gegen den Cluster absichern. Pro Node ein eigenes Token mit DatastoreBackup und sonst nichts, Prune und GC laufen als Jobs auf dem PBS selbst, nicht über die keep-*-Werte im PVE-Job. Dann kann ein übernommener Node schreiben, aber nicht löschen. Und wenn irgendwann Budget für ein zweites Ziel da ist: das soll die Snapshots per Sync-Job ziehen, nicht pushen.

@sgw, falls das NAS auch den PBS macht, würde ich vorher kurz schauen was für Hardware da drin steckt. PBS mag Datastores auf SSD, auf Rost mit vielen kleinen Chunks wird vor allem GC und Verify zäh.
 
  • Like
Reactions: ThoSo and Johannes S
Standardmäßig kommt man nach Hinzufügen des qdevice per school mut root-Rechten aufs qdevice. Wenn da auch die Backups liegen: Gute Nacht
 
Root-SSH braucht's nur einmal beim Setup, pvecm qdevice setup schiebt darüber die Certs rüber und richtet den qnetd ein. Danach kannst du root-Login wieder dichtmachen, im Betrieb läuft nur noch der qnetd auf 5403 und der will kein SSH mehr. Das ist eher ein Setup-Schritt als ein Dauerzustand.

Wenn dir das trotzdem zu nah dran ist, nimm halt den Weg über einen kleinen CT auf der Kiste wie oben verlinkt, dann liegen die Certs im Gast statt auf dem Host. Kostet nix ausser ein bisschen RAM, seh ich kein Problem damit. Mir persönlich wärs bei so einem Setup egal, solange nach dem Aufsetzen PermitRootLogin wieder zu ist.
 
  • Like
Reactions: Johannes S
  • Like
Reactions: UdoB and Bu66as
Guten Morgen allen hier, na, das löst ja einige Diskussion aus :) Gut für mich!

Ich hab Eure letzten Beiträge und Meinungen überflogen, muss aber noch im Detail drüber gehen.

PBS hab ich natürlich sowieso eingeplant, als VM auf einem Node, mit Storage 1 auf einem NAS (HDDs, ja, ich weiß, aber ich muss ein wenig haushalten mit dem Budget. Bei einem anderen Kunden fahre ich das auch so. Ja, GC slow, aber es tut ...) und es wird zusätzlich noch ein Bacula-Backup deployed (das macht dann eher die Ebene der Backups aus diversen Servern raus. Steht hier jetzt nicht zur Diskussion.)

Als Quorum Device denke ich daran, das auf einen physischen Server dazu zu packen, den es bereits gibt. Der ist dann auch in einem anderen Raum/Brandabschnitt/Stromkreis etc

Nachdem der Bedarf an Volumen nicht besonders groß ist, muss auch das Storage nicht Dutzende Slots haben.

Ich werfe mal in den Raum: HPE MSA2040? Würde sowas passen? OK, das hat 24 Bays (brauch ich nie. Vermutlich starten wir mit 4 SSDs.) und ist alt/refurbished, aber vom Prinzip her würde das klappen für iscsi, korrekt? Ich nenne das, weil ich solche Dinger per FC bei 2 anderen Kunden in Betrieb habe (ja, das ist jetzt refurbished. Ich sammle nur mal Eckdaten und Verständnis, erstelle eine Liste von Komponenten etc)

Wenn ich so schaue, werden mich die Enterprise SSDs fürs Storage budget-technisch killen. Ich sehe da 2TB um ~ 2000 EUR aktuell. Ich weiß schon, wenn man was "Großes" will, kostet das auch Geld, dennoch muss ich das Ganze in einem Rahmen halten. Theoretisch kann ich mit wenigen Platten starten und, falls mal wieder die Hardware-Preise sinken sollten, nachstecken. Hmm.

Wie auch immer.

OK, also 2x 25GB NIC pro Node. Einen extra Storage-Switch kann ich mir anfangs sparen? Wenn ich solche Karten suche, finde ich welche mit SFP+ Slots. Dh. ich könnte mit DAC-Cables direkt aufs Storage gehen (in Phase1, solange ich genügend Ports habe dafür. Später mit Node3 braucht es dann wohl den Switch).

Corosync über eine dezidierte 1Gbit/s NIC, klar, habe ich auch bei dem FC-Cluster so gemacht.

Bislang hatte ich ja 2 Nodes mit jeweils 4 local disks angeboten, das bedeutete, die Kisten hatte jeweils einen dicken Storage-Controller drin, plus Plattenkäfig, plus Kabelsatz. Das könnte nun wegfallen, und ich muss jetzt schauen, ob ich dann nicht überhaupt auf einen anderen Basis-Server wechsle, wenn ich diese Features nicht brauche.

Also ein Überarbeiten meines bisherigen Konzepts und Angebots. OK, weil ich natürlich weiß, dass dieses Shared-Storage-Konzept einige Vorteile gegenüber dem bisherigen Plan hat. Alles etwas langwierig, aber es soll ja was möglichst Solides werden für das Geld, das da ist.

Danke für all Eure Beiträge, ich gehe die noch mal genauer durch ... und komme vielleicht noch mit Nachfragen.

Allgemein zur Einordnung: Bei diesem Kunden geht es aktuell um den Einstieg in Virtualisierung. Und damit verbunden die Diskussionen um Ausfallsicherheiten etc. Die wachsen perspektivisch, neue Anforderungen .. sind es aber bislang gewohnt, mit separaten physischen Kisten zu hantieren. Also viel Erklärungsbedarf, und ich muss auch langsam vermitteln, dass auch das Budget anzupassen ist. Als ich die Gespräche dazu begonnen habe, habe ich mit Shared Storage erst gar nicht angefangen, dachte, da werden die sofort abblocken. So gesehen ist es positiv, dass das nun verstanden und geprüft wird.

Aber klar: das ist immer noch eine überschaubare Landschaft von eher wenigen VMs/Servern. Relativ wenig Datenmenge im Vergleich zu anderen, dennoch essentiell für deren Betrieb.

Nochmals danke für Euren Input, weiß ich sehr zu schätzen.
 
Die MSA2040 kann iSCSI, aber nur mit 10G-SFP+, 25G gibt's bei der Generation nicht. Und Firmware/Support sind da längst durch. Für genau das Teil, das am längsten stehen bleiben soll und bei dessen Ausfall alles steht, würd ich das nicht nehmen, auch wenn du die Dinger kennst. Eine 2060/2070 oder was Vergleichbares, dann passt auch 25G.

Beim NIC-Kauf aufpassen: SFP+ ist 10G, 25G ist SFP28. SFP28-Karten laufen abwärtskompatibel mit 10G-DACs, also gleich SFP28 nehmen, dann bist du bei der Array-Auswahl flexibel. Direktanschluss per DAC auf die Controller-Ports läuft, zwei Nodes sind da kein Thema.

Bei den SSD-Preisen schau, ob du mit Read-Intensive statt Mixed-Use hinkommst, bei der Datenmenge und dem Workload macht das preislich einiges aus. Und vorher in die Compatibility-Liste vom Array schauen, die meisten nehmen nur zertifizierte Platten mit eigener Firmware, da kannst du nicht einfach günstige SSDs reinstecken. Nachrüsten würd ich auch vorher durchdenken, eine bestehende Disk Group erweiterst du bei den Dingern nicht mal eben, meist landest du bei einer zweiten Gruppe. Also gleich mit der Zielgröße planen und dann teilbestücken.
 
You must log in or register to reply here.
Top Bottom
Back