Shared LVM gewünscht: FC-SAN?

[sgw]

@Bu66as drei sehr gute Punkte, danke fürs Hinweisen.

SFP+ vs SFP28: danke für den Reminder (Unterschied kenn ich, hatte ich aber nicht im Kopf vorhin beim Schreiben).
Ich such mal nach 2060/2070 ... plus den genannten SSDs.

 

[Falk R.]

Die einfachste Lösung hat noch niemand genannt. Wenn du eh nur einen kleinen Cluster in einem Raum betreibst, nimm einfach SAS.
SAS HBAs kosten fast nix, die SAS Kabel auch nicht und an die einfachen Storages wie MSA bekommst du bis zu 4 Hosts redundant angeschlossen.

Das ist günstig und robust. Du brauchst auch nichts konfigurieren außer Multipath (keine iSCSI Konfig oder IPs).
NVMe over TCP ist deutlich einfacher als iSCSI aber die günstigen Storages können alle noch kein NVMe over TCP.

 

[Johannes S]

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

Das mit dem PBS auf einen Knoten im Cluster finde ich schwierig: Demnach kann ein Angreifer, der den Host übernimmt, dann auch die Backup-VM übernehmen und darüber die Daten löschen. Kann die NAS keine VMs? Würde die VM dann eher dort hosten, dann müssen für verify-jobs o.ä. die Daten auch nicht durch Netzwerks schaufeln. Dass man aus Kostengründen HDDs nimmt, kann ich verstehen, ich würde aber planen bei nächstbester Gelegenheit SSDs als special device hinzuzufügen, damit kann man (auch mit HDDs) das Ganze deutlich beschleunigen.

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

Wofür wird der Server aktuell verwendet und was für Hardware (Storage, CPU, RAM, Netzwerk etc) ist dadrin verbaut? Unter Umständen eignet der sich auch als PBS.

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.

Ich stelle bei sowas die ketzerische Frage, ob da zwei Server mit lokalen Storage nicht eine höhere Ausfallsicherheit als mit einen SAN haben? Bei zwei Knoten kann man dann allerdings nur ZFS-Replikation nehmen, hat also anders als mit Ceph einen minimalen Datenverlust im Fehlerfall. Aber wenn der Storage ausfällt, hat man ja das gleiche Problem. Wieviel kostet die SAN denn, wenn SSDs mit 2000 Euro schon an der Grenze sind?

 

[sgw]

Die einfachste Lösung hat noch niemand genannt. Wenn du eh nur einen kleinen Cluster in einem Raum betreibst, nimm einfach SAS.
SAS HBAs kosten fast nix, die SAS Kabel auch nicht und an die einfachen Storages wie MSA bekommst du bis zu 4 Hosts redundant angeschlossen.

Das ist günstig und robust. Du brauchst auch nichts konfigurieren außer Multipath (keine iSCSI Konfig oder IPs).
NVMe over TCP ist deutlich einfacher als iSCSI aber die günstigen Storages können alle noch kein NVMe over TCP.

Oh! Das klingt aber auch interessant ... damit würden NICs wegfallen, DACs, ... etc

Danke @Falk R. für diesen Vorschlag! Klingt noch besser als iscsi!

Der eine Händler schlug mir grade ein refurbished MSA2050 vor .. das kriege ich mit Vor-Ort-Service angeboten. Und das kann SAS 6 GB/s laut Angaben.

Ein neues MSA muss ich mir erst wo raus suchen, vermutlich gut teuer ... (es muss auch kein MSA sein, no na, ich gehe nur von den mir bekannten Systemen aus).

 

[Falk R.]

Oh! Das klingt aber auch interessant ... damit würden NICs wegfallen, DACs, ... etc

Danke @Falk R. für diesen Vorschlag! Klingt noch besser als iscsi!

Der eine Händler schlug mir grade ein refurbished MSA2050 vor .. das kriege ich mit Vor-Ort-Service angeboten. Und das kann SAS 6 GB/s laut Angaben.

Die kann auf jeden Fall 12 GBit SAS. Aber Vorsicht, es gibt extra SAS Controller und die iSCSI/FC Controller haben nur SAS um weitere Shelfs anzuschließen.

Ein neues MSA muss ich mir erst wo raus suchen, vermutlich gut teuer ... (es muss auch kein MSA sein, no na, ich gehe nur von den mir bekannten Systemen aus).

Bei den üblichen Gebrauchthändlern gibts auch immer wieder SAS Modelle, aber da der Markt recht leer ist, muss man schnell zugreifen, wenn man das passende findet.

 

[sgw]

Das mit dem PBS auf einen Knoten im Cluster finde ich schwierig: Demnach kann ein Angreifer, der den Host übernimmt, dann auch die Backup-VM übernehmen und darüber die Daten löschen. Kann die NAS keine VMs? Würde die VM dann eher dort hosten, dann müssen für verify-jobs o.ä. die Daten auch nicht durch Netzwerks schaufeln. Dass man aus Kostengründen HDDs nimmt, kann ich verstehen, ich würde aber planen bei nächstbester Gelegenheit SSDs als special device hinzuzufügen, damit kann man (auch mit HDDs) das Ganze deutlich beschleunigen.

Das QNAP-NAS TS-453E kann auch VMs. Hab ich noch nie verwendet so, nehme das aber gern als Anregung auf. Detto das mit SSD als special device.
Das NAS ist bereits bestellt, während die Server-Auswahl noch läuft, kann/will ich nämlich das ganze Bacula-Thema schon mal vorbereiten.

Wofür wird der Server aktuell verwendet und was für Hardware (Storage, CPU, RAM, Netzwerk etc) ist dadrin verbaut? Unter Umständen eignet der sich auch als PBS.

Da gibt es ältere Fujitsu-Server, die teils Samba-File-Server sind, teils Samba-Domain-Controller. Alles keine modernen Kisten, alles älter als 5-8 Jahre, sag ich mal. Manche Services wandern dann in neue VMs, da gibt es verschiedene Ansätze und Ideen ... Alles diskutabel, natürlich, aber geht grade etwas von meinem momentanen Todo weg: aktuell muss ich das mit dem Konzept für die 2 PVEs und deren Storage ausarbeiten, anbieten und auf den Weg bringen. Ansonsten blockiert mir das den Rest des ganzen Projekts.

Ich stelle bei sowas die ketzerische Frage, ob da zwei Server mit lokalen Storage nicht eine höhere Ausfallsicherheit als mit einen SAN haben. Bei zwei Knoten kann man dann allerdings nur ZFS-Replikation nehmen, hat also anders als Ceph einen minimalen Datenverlust im Fehlerfall. Aber wenn der Storage ausfällt, hat man ja das gleiche Problem. Wieviel kostet die SAN denn, wenn SSDs mit 2000 Euro schon an der Grenze sind?

Das Thema SPOF werde ich so nicht los, klar.

Der Unterschied, der für den Kunden (und auch mich, zum Teil) attraktiv ist, ist aus meiner Sicht, dass mit dem Shared Storage und HA-Config ohne Eingriff eines Admins die VM(s) flott wieder online sind.

Bei 2 PVEs mit jeweils local storage braucht es Admin-Eingriff, damit eine VM von einem zum anderen Node wandert.

Aber klar: wenn das zentrale Storage zickt, ist es auch wieder schlecht. Ist mir völlig klar.

Gestern war so deren Aussage aus der Hüfte: "Wenn es in etwa 10tsd EUR mehr kostet, machen wir Shared Storage" ...

Bei den Nodes gehen die Kosten ja dadurch runter, beim Storage hoch ... mal schauen.

Und ja, das ist eine Sparlösung, die ich da skizziere, und kein vollprofessionelles Setup auf höchstem Niveau.
Aber eine deutliche Verbesserung gegenüber dem bisherigen Stand, inklusive Verbesserungs-Möglichkeiten in den nächsten Jahren.

 

[Falk R.]

Das QNAP-NAS TS-453E kann auch VMs. Hab ich noch nie verwendet so, nehme das aber gern als Anregung auf. Detto das mit SSD als special device.
Das NAS ist bereits bestellt, während die Server-Auswahl noch läuft, kann/will ich nämlich das ganze Bacula-Thema schon mal vorbereiten.

Nur so als Tipp, ein NAS ist nie erste Wahl für Backups. Wenn es eh da ist, kann man das nutzen, aber sonst hat ein NAS immer zu viele Nachteile.
z.B. zu langsame Updatezyklen, zu viele Dienste die man nicht braucht, oft Blackbox ohne kompletten Systemzugriff und so weiter. Ein kleiner Server mit einem schmalen Linux kostet nicht mehr aber ist deutlich besser anpassbar an die Bedürfnisse.

Da gibt es ältere Fujitsu-Server, die teils Samba-File-Server sind, teils Samba-Domain-Controller. Alles keine modernen Kisten, alles älter als 5-8 Jahre, sag ich mal. Manche Services wandern dann in neue VMs, da gibt es verschiedene Ansätze und Ideen ... Alles diskutabel, natürlich, aber geht grade etwas von meinem momentanen Todo weg: aktuell muss ich das mit dem Konzept für die 2 PVEs und deren Storage ausarbeiten, anbieten und auf den Weg bringen. Ansonsten blockiert mir das den Rest des ganzen Projekts.

Das Thema SPOF werde ich so nicht los, klar.

Der Unterschied, der für den Kunden (und auch mich, zum Teil) attraktiv ist, ist aus meiner Sicht, dass mit dem Shared Storage und HA-Config ohne Eingriff eines Admins die VM(s) flott wieder online sind.

Bei 2 PVEs mit jeweils local storage braucht es Admin-Eingriff, damit eine VM von einem zum anderen Node wandert.

Das ist falsch. Wenn du ZFS Replication nutzt, kannst du ganz normal HA nutzen und die VMs starten automatisch. Natürlich mit einem kleinen Datendelta.
Der kleinste Intervall ist 1 Minute und wenn der Kunde im Falle eines echten Ausfalls mit bis zu 1 Minute Datenverlust leben kann, (was oft im Mittelstand geht) dann hast du eine sehr Robuste und Günstige Lösung.
Live Migration geht damit natürlich auch.

Aber klar: wenn das zentrale Storage zickt, ist es auch wieder schlecht. Ist mir völlig klar.

Gestern war so deren Aussage aus der Hüfte: "Wenn es in etwa 10tsd EUR mehr kostet, machen wir Shared Storage" ...

Oder gar nix mehr und ZFS replika.

Bei den Nodes gehen die Kosten ja dadurch runter, beim Storage hoch ... mal schauen.

Und ja, das ist eine Sparlösung, die ich da skizziere, und kein vollprofessionelles Setup auf höchstem Niveau.
Aber eine deutliche Verbesserung gegenüber dem bisherigen Stand, inklusive Verbesserungs-Möglichkeiten in den nächsten Jahren.

 

[Johannes S]

Das QNAP-NAS TS-453E kann auch VMs. Hab ich noch nie verwendet so, nehme das aber gern als Anregung auf. Detto das mit SSD als special device.
Das NAS ist bereits bestellt, während die Server-Auswahl noch läuft, kann/will ich nämlich das ganze Bacula-Thema schon mal vorbereiten.

Die Bacula-Backups landen also auch auf dem NAS? Kann man so machen, wie ist das offsite-Backup geplant?

Da gibt es ältere Fujitsu-Server, die teils Samba-File-Server sind, teils Samba-Domain-Controller. Alles keine modernen Kisten, alles älter als 5-8 Jahre, sag ich mal. Manche Services wandern dann in neue VMs, da gibt es verschiedene Ansätze und Ideen ... Alles diskutabel, natürlich, aber geht grade etwas von meinem momentanen Todo weg: aktuell muss ich das mit dem Konzept für die 2 PVEs und deren Storage ausarbeiten, anbieten und auf den Weg bringen. Ansonsten blockiert mir das den Rest des ganzen Projekts.

Voll verständlich, war auch nur eine Anregung, wie man die alten Server noch sinnvoll weiterverwenden könnte. Der PBS hat vergleichsweise geringe Hardwareanforderungen (die Empfehlung für SSDs ist da noch der dickste Brocken https://pbs.proxmox.com/docs/installation.html ) und man könnte damit halt die Systeme für mehr nutzen, als nur als Qdevice. Ein anderer Vorteil, den ich bei einer Zweitverwertung als PBS sehe, ist dass du zusätzlich das als zweites Backup in einen anderen Brandabschnitt/Standort nutzen könntest. Sprich: Erstbackup landet auf der NAS, das kombinierte qdevice/PBS pullt sich dann die Backups vom NAS.

Der Unterschied, der für den Kunden (und auch mich, zum Teil) attraktiv ist, ist aus meiner Sicht, dass mit dem Shared Storage und HA-Config ohne Eingriff eines Admins die VM(s) flott wieder online sind.

Das ist mit ZFS-Storage-Replication und HA genauso. Standardmäßig werden die VMs dann halt nur alle 15 Minuten repliziert, das kann aber auf bis zu eine Minute reduziert werden. Vorteil ist dabei natürlich, dass der Storage lokal ist, schneller geht es nicht Und halt alle sonstigen ZFS-Features.
Nachteil ist halt, dass bei einen Fehler (NICHT regulären Wartungen/Migrationen, da gibt es natürlich keinen Datenverlust. Dafür sorgt die Replikation dafür, dass weniger rübermigriert werden muss) es einen kleinen Datenverlust gibt. Je nach Usecase kann das voll ok sein ( Die Proxmox-Webseite hat das Beispiel einer Online-Apotheke: https://www.proxmox.com/de/ueber-uns/ueber-uns/stories/story/farmacia-nova-da-maia-de , Falk hat auch öfter erwähnt, dass er so ein Setup für Kunden fährt, deren Umgebung/Budget Ceph nicht hergibt ) oder eben nicht. Wobei ich bei Anwendungen, wo das ein no-go wäre auch im Einzelfall prüfen würde, ob eine Hochverfügbarkeit auch über die Anwendung realisiert werden kann. Die gängigen SQL-Datenbanken können das im Regelfall. Trotzdem gibt es natürlich Anwendungen, wo auch eine Minute Verlust nicht vertretbar ist, von daher will ich da gar nicht für missionieren ala "Mach das unbedingt", sondern eher als Anregung, was eine Alternative für preissensitive Kunden sein könnte Dein Aktueller scheint da ja wenig Bauchschmerzen zu haben bei folgender Ansage:

Gestern war so deren Aussage aus der Hüfte: "Wenn es in etwa 10tsd EUR mehr kostet, machen wir Shared Storage" ...

Wenn das das Budget ist, würde ich das Geld eher in lokalen Storage auf den Systemen investieren, aber ja das muss man sich überlegen. Vor allen weil zfs am Ende ja auch eine Sparlösung ist, beide Varianten haben ihre trade-offs.

Aber eine deutliche Verbesserung gegenüber dem bisherigen Stand, inklusive Verbesserungs-Möglichkeiten in den nächsten Jahren.

Auf jeden Fall, wobei ich ja eher ein mögliches Upgrade auf Ceph einplanen würde, weil man damit halt schön skalieren kann. Man braucht mehr Storage->Zusätzliche Platten einhängen. Zusätzliche Compute-Resourcen->Ein Knoten mehr. Sprich: Man könnte mit zfs anfangen und dann später die Systeme (sobald man einen dritten Knoten hat) Richtung ceph migrieren. Was natürlich auch geht ist eine Kombination, aber in die Größenordnung (wo das sinnvoll ist) muss man erstmal kommen, eine andere Success Story hat einen Hosting-Provider, die haben ein Setup mit 19 Knoten im HCI-Cluster (also ceph) und zusätzlich shared storage für latenzsensitive Anwendungen: https://www.proxmox.com/de/ueber-uns/ueber-uns/stories/story/horizoniq-de
Aber wann kommt ein typischer Mittelständler schon in diese Größenordnung?
Edit: Während ich das hier geschrieben habe, war Falk schneller als ich, sorry für die Redundanz

 

[sgw]

Nur so als Tipp, ein NAS ist nie erste Wahl für Backups. Wenn es eh da ist, kann man das nutzen, aber sonst hat ein NAS immer zu viele Nachteile.
z.B. zu langsame Updatezyklen, zu viele Dienste die man nicht braucht, oft Blackbox ohne kompletten Systemzugriff und so weiter. Ein kleiner Server mit einem schmalen Linux kostet nicht mehr aber ist deutlich besser anpassbar an die Bedürfnisse.

Guter Punkt, jetzt hab ich halt leider schon bestellt

Das ist falsch. Wenn du ZFS Replication nutzt, kannst du ganz normal HA nutzen und die VMs starten automatisch. Natürlich mit einem kleinen Datendelta.
Der kleinste Intervall ist 1 Minute und wenn der Kunde im Falle eines echten Ausfalls mit bis zu 1 Minute Datenverlust leben kann, (was oft im Mittelstand geht) dann hast du eine sehr Robuste und Günstige Lösung.
Live Migration geht damit natürlich auch.

Oder gar nix mehr und ZFS replika.

Schön langsam schwirrt mir der Kopf. ZFS-Replika verstehe ich so, dass die Server jeweils local storage haben, darauf einen lokalen ZFS-Pool und den repliziert man zB von Node1 auf Node2 ... ? Also kein Shared Storage, kein externes SAS, iscsi, FC ... ?

Ich war bei local storage bislang von "nicht-ZFS" ausgegangen, daher war mir diese Variante noch nicht bewusst gewesen.

Bislang gefiel mir eigentlich das mit dem SAS am Besten. Wobei ich mir mit ZFS-Replication das MSA-Storage erspare .. das hat natürlich auch VIELES für sich. Sehr vieles. Kein Bauchweh mit gebrauchtem SAN und/oder hohem Neupreis.

1 Minute ... wohl akzeptabel. Die Kern-Applikation wird eine VM mit Windows Server sein, mit einem SQL-Server drin ... das ist deren Dreh- und Angelpunkt.
Das läuft seit Jahren auf einem physischen einzelnen Server, mit allem Für und Wider. (dieser Server soll perspektivisch erst in 2027 virtualisiert werden, davor kommen andere Services dran).

Dh. aktuell sind wir so weit von 1 Minute entfernt, wie nur denkmöglich Deswegen ja der ganze Act.

OK, für ZFS lokal geht es also in Richtung HBA ohne RAID-Features, lokale SSDs ... lokale Platten-Slots mit Reserve.
Ich lese das noch nach, aber nur quick: vermutlich setzt man die ZFS-Replication auch auf separaten NICs auf?

Super Input von Euch allen, danke weiterhin!

 

[sgw]

Die Bacula-Backups landen also auch auf dem NAS? Kann man so machen, wie ist das offsite-Backup geplant?

Per S3 und encrypted nach draußen, angemieteter Storage. Mach ich aktuell bereits (Snapshots von neuralgischen Dingen per Kopia), wird nur angepasst (später Bacula direkt, wenn ich soweit bin). Aktuell gibt's auch physische Medien, die ausgelagert werden, das wird aber Zug um Zug verbessert werden.

Voll verständlich, war auch nur eine Anregung, wie man die alten Server noch sinnvoll weiterverwenden könnte. Der PBS hat vergleichsweise geringe Hardwareanforderungen (die Empfehlung für SSDs ist da noch der dickste Brocken https://pbs.proxmox.com/docs/installation.html ) und man könnte damit halt die Systeme für mehr nutzen, als nur als Qdevice. Ein anderer Vorteil, den ich bei einer Zweitverwertung als PBS sehe, ist dass du zusätzlich das als zweites Backup in einen anderen Brandabschnitt/Standort nutzen könntest. Sprich: Erstbackup landet auf der NAS, das kombinierte qdevice/PBS pullt sich dann die Backups vom NAS.

Da denke ich gerne drüber nach. Generell will ich die ältesten Kisten eher los werden ... Perspektivisch wird in 2027 der (im vorigen Posting erwähnte) Applikations-Server frei (wenn deren App virtualisiert wurde), das wäre dann eine relativ starke Hardware mit 2 RAID-Arrays mit je 4 SSDs drin, die dann frei sind. Die sind natürlich nicht mehr neu, aber als Backup-Storage für die Kopie der Kopie ...

Das ist grade alles ein Spiel mit vielen Variablen und Varianten, aber die Idee nehm ich jedenfalls mit.

Was auch relevant ist: ich plane, 2 PVEs zu kaufen/aufzubauen. Rein, weil ich den guten Wind aktuell nutze und die Bereitschaft zur Investition nutze. Und eben aufgrund der refurbished Hardware auf diese Redundanz poche (was gekauft und im Haus ist, muss ich nicht in einem Jahr oder schlimmstenfalls im Notfall neu rausverhandeln ...)

Die Nutzlast, die geplant ist, kann ich sehr wahrscheinlich locker auf einem PVE betreiben. D.h. der PVE2 läuft erst mal mehr oder minder leer mit ... und dort drauf sehe ich bislang eben eine VM mit PBS und eine mit Bacula, weil die Ressourcen locker da sind. Ja, korrekt: selbes Rack, selbes Risiko!

Da bin ich noch völlig offen, aber wie gesagt: Prio 1 ist jetzt das Festlegen der Gestaltung des Clusters (ich nenne das jetzt so, ohne Diskussion darüber, inwieweit der Begriff zutrifft).

Das ist mit ZFS-Storage-Replication und HA genauso. Standardmäßig werden die VMs dann halt nur alle 15 Minuten repliziert, das kann aber auf bis zu eine Minute reduziert werden. Vorteil ist dabei natürlich, dass der Storage lokal ist, schneller geht es nicht Und halt alle sonstigen ZFS-Features.
Nachteil ist halt, dass bei einen Fehler (NICHT regulären Wartungen/Migrationen, da gibt es natürlich keinen Datenverlust. Dafür sorgt die Replikation dafür, dass weniger rübermigriert werden muss) es einen kleinen Datenverlust gibt. Je nach Usecase kann das voll ok sein ( Die Proxmox-Webseite hat das Beispiel einer Online-Apotheke: https://www.proxmox.com/de/ueber-uns/ueber-uns/stories/story/farmacia-nova-da-maia-de , Falk hat auch öfter erwähnt, dass er so ein Setup für Kunden fährt, deren Umgebung/Budget Ceph nicht hergibt ) oder eben nicht. Wobei ich bei Anwendungen, wo das ein no-go wäre auch im Einzelfall prüfen würde, ob eine Hochverfügbarkeit auch über die Anwendung realisiert werden kann. Die gängigen SQL-Datenbanken können das im Regelfall. Trotzdem gibt es natürlich Anwendungen, wo auch eine Minute Verlust nicht vertretbar ist, von daher will ich da gar nicht für missionieren ala "Mach das unbedingt", sondern eher als Anregung, was eine Alternative für preissensitive Kunden sein könnte Dein Aktueller scheint da ja wenig Bauchschmerzen zu haben bei folgender Ansage:

Siehe oben: aktuell eigentlich keine nennenswerte Redundanz.

Wenn das das Budget ist, würde ich das Geld eher in lokalen Storage auf den Systemen investieren, aber ja das muss man sich überlegen. Vor allen weil zfs am Ende ja auch eine Sparlösung ist, beide Varianten haben ihre trade-offs.

Verstehe ich, aber ich freunde mich mit ZFS lokal langsam an ...
trade-off ist unvermeidlich, klar.

Auf jeden Fall, wobei ich ja eher ein mögliches Upgrade auf Ceph einplanen würde, weil man damit halt schön skalieren kann. Man braucht mehr Storage->Zusätzliche Platten einhängen. Zusätzliche Compute-Resourcen->Ein Knoten mehr. Sprich: Man könnte mit zfs anfangen und dann später die Systeme (sobald man einen dritten Knoten hat) Richtung ceph migrieren. Was natürlich auch geht ist eine Kombination, aber in die Größenordnung (wo das sinnvoll ist) muss man erstmal kommen, eine andere Success Story hat einen Hosting-Provider, die haben ein Setup mit 19 Knoten im HCI-Cluster (also ceph) und zusätzlich shared storage für latenzsensitive Anwendungen: https://www.proxmox.com/de/ueber-uns/ueber-uns/stories/story/horizoniq-de
Aber wann kommt ein typischer Mittelständler schon in diese Größenordnung?
Edit: Während ich das hier geschrieben habe, war Falk schneller als ich, sorry für die Redundanz

Ceph spricht mich ad hoc NICHT an, weil ich damit keine Expertise habe und ich nicht noch ein neues Thema rein bringen will.
ZFS hab ich zwar auch nicht aktiv im Einsatz, damit aber mehr Berührungspunkte und Erfahrung.

De facto zählt der Kunde wohl nicht mal wirklich zur Definition von Mittelstand: wir sprechen über aktuell etwa 40 Mitarbeiter, und perspektivisch über 5-10 VMs, die wichtig sein werden. Aber aus deren Sicht sind diese Systeme natürlich essentiell.

thx so far!

 

[sgw]

Ich lese grad nach zur ZFS-Replication. Was mir grad dämmert (gerne Feedback): bedeutet das dann, dass ich Node2 im Normalfall ohne laufende VMs betreibe? Und Node2 den ZFS-Pool quasi eher als read-only behandelt im Normal-Betrieb?

Also kein nutzbares Storage für Node2, außer wenn Node1 down ist? Oder verstehe ich das falsch?

Das wäre natürlich nicht so schön. Danke für Infos dazu.

 

[Johannes S]

Ich lese grad nach zur ZFS-Replication. Was mir grad dämmert (gerne Feedback): bedeutet das dann, dass ich Node2 im Normalfall ohne laufende VMs betreibe? Und Node2 den ZFS-Pool quasi eher als read-only behandelt im Normal-Betrieb?

Das kann man machen, wie man es für richtig hält. Sind beide Systeme gleich leistungsstark, dann bietet es sich natürlich an auch beide gleich auszulasten.
Wenn dagegen der eine Knoten schwächer dimensioniert ist, würde sich natürlich eher anbieten den nur als "Failover" zu nutzen.

Generell braucht es halt für jede so zu replizierende VM auf beiden Knoten genug freien Speicherplatz.

Also kein nutzbares Storage für Node2, außer wenn Node1 down ist? Oder verstehe ich das falsch?

Nö, den Storage kann man nutzen wie man will, für die Replikation muss der aber auf beiden Knoten gleich heißen, mehr dazu:
https://pve.proxmox.com/wiki/Storage_Replication

 

[DarthVaddi]

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.

Servus,

lieber spät als nie. Wir haben hier kürzlich den großen hypervisor mit V am Anfang gegen Proxmox VE nach und nach auf 6 hosts ausgetauscht.
Die vorhandene Hardware FC-SAN haben wir weiter verwendet. Abgesehen davon, dass sie wunderbar funktioniert, darf man nicht vergessen, dass sie ein single point of failure ist. Fällt das SAN aus, ist halt alles tot.

Wenn genug Geld da ist, könnte man noch über gespiegelten Storage nachdenken, aber naja, diese Variante fällt bei der Wirtschaftlichkeit komplett durch

Wenn ich aber die Chance hätte, alles von Grund auf neu zu machen, würde ich vermutlich einen HCI Ansatz wählen, in dem auch mein storage-Ansatz redundant ist.

VG DV

 

[Johannes S]

Per S3 und encrypted nach draußen, angemieteter Storage. Mach ich aktuell bereits (Snapshots von neuralgischen Dingen per Kopia), wird nur angepasst (später Bacula direkt, wenn ich soweit bin). Aktuell gibt's auch physische Medien, die ausgelagert werden, das wird aber Zug um Zug verbessert werden.

PBS hat mittlerweile auch s3 support, bei den man auch lokal unverschlüsselte Backups per push-sync verschlüsseln kann.

 

[sgw]

Das kann man machen, wie man es für richtig hält. Sind beide Systeme gleich leistungsstark, dann bietet es sich natürlich an auch beide gleich auszulasten.
Wenn dagegen der eine Knoten schwächer dimensioniert ist, würde sich natürlich eher anbieten den nur als "Failover" zu nutzen.

Generell braucht es halt für jede so zu replizierende VM auf beiden Knoten genug freien Speicherplatz.

OK; danke. Verstehe ich nun soweit richtig.

Nö, den Storage kann man nutzen wie man will, für die Replikation muss der aber auf beiden Knoten gleich heißen, mehr dazu:
https://pve.proxmox.com/wiki/Storage_Replication

Schon überflogen vorhin, danke.

 

[sgw]

Servus,

lieber spät als nie. Wir haben hier kürzlich den großen hypervisor mit V am Anfang gegen Proxmox VE nach und nach auf 6 hosts ausgetauscht.
Die vorhandene Hardware FC-SAN haben wir weiter verwendet. Abgesehen davon, dass sie wunderbar funktioniert, darf man nicht vergessen, dass sie ein single point of failure ist. Fällt das SAN aus, ist halt alles tot.

Selbe History wie meinem anderen Kunden. Dort auch V.. ersetzt, und das vorhandene FC-Setup samt SAN weiter verwendet, teils mit neuen Platten.
Der Umstand des SPOF ist mir auch dort bewusst ... sag ich denen auch immer wieder mal ...

Wenn genug Geld da ist, könnte man noch über gespiegelten Storage nachdenken, aber naja, diese Variante fällt bei der Wirtschaftlichkeit komplett durch

Wenn ich aber die Chance hätte, alles von Grund auf neu zu machen, würde ich vermutlich einen HCI Ansatz wählen, in dem auch mein storage-Ansatz redundant ist.

Ja. Man türmt alles aufeinander zu Beginn, und dann nagt die Zeit daran ... bis irgendwas kracht

 

[Falk R.]

Schön langsam schwirrt mir der Kopf. ZFS-Replika verstehe ich so, dass die Server jeweils local storage haben, darauf einen lokalen ZFS-Pool und den repliziert man zB von Node1 auf Node2 ... ? Also kein Shared Storage, kein externes SAS, iscsi, FC ... ?

Richtig, alles Einfach.

Ich war bei local storage bislang von "nicht-ZFS" ausgegangen, daher war mir diese Variante noch nicht bewusst gewesen.

Bislang gefiel mir eigentlich das mit dem SAS am Besten. Wobei ich mir mit ZFS-Replication das MSA-Storage erspare .. das hat natürlich auch VIELES für sich. Sehr vieles. Kein Bauchweh mit gebrauchtem SAN und/oder hohem Neupreis.

1 Minute ... wohl akzeptabel. Die Kern-Applikation wird eine VM mit Windows Server sein, mit einem SQL-Server drin ... das ist deren Dreh- und Angelpunkt.
Das läuft seit Jahren auf einem physischen einzelnen Server, mit allem Für und Wider. (dieser Server soll perspektivisch erst in 2027 virtualisiert werden, davor kommen andere Services dran).

Der Server hat derzeit keine gut Verfügbarkeit, die würdest du mit ZFS Replika extrem erhöhen.

Dh. aktuell sind wir so weit von 1 Minute entfernt, wie nur denkmöglich Deswegen ja der ganze Act.

OK, für ZFS lokal geht es also in Richtung HBA ohne RAID-Features, lokale SSDs ... lokale Platten-Slots mit Reserve.
Ich lese das noch nach, aber nur quick: vermutlich setzt man die ZFS-Replication auch auf separaten NICs auf?

Dedizierte NIC kann man machen, mache ich auch gern, denn ein DAC Kabel zwischen den Servern kostet ja nix und das kann ein weiterer Corosync Ring sein.
Ich habe das auch bei einigen Kunden auf 2 Räume aufgeteilt und einfach per LWL direkt verbunden. Das Quorum ist dann in einem Netzwerkverteiler im dritten Brandabschnitt. Geht wunderbar.