Storage

[Jan Novak]

Hallo,

wir haben in der Firma 6 "bare Metal" Server stehen, jeder mit seinem
eigenem Storage und Gigabit Netzwerkkarten. Auf allen Servern läuft
ProxmoxVE. Die Nodes sind zu einem Cluster verbunden.

Mir kam jetzt die Idee, die Platten der einzelnen Server in ein
entsprechendes Gehäuse zu bauen und dort mit einem schnellen
Board/CPU/(genügend) RAM und passenden Raid Kontroller(n) als Storage
die Servern wieder zurück zu geben.
Abgesehen davon, dass allein die Kosten für obiges Konstrukt schon
beträchtlich sein werden, ist meine Frage, mit welcher Schnittstelle man
den jeweiligen Servern die (iscsi-) Storages vermittelt, welche
ausreichend schnell genug sind und den aktuellen technischen Stand
entsprechen. Ich sage dies deswegen, weil wir im Betrieb auch noch alte
10GB Netzwerkkarten liegen haben, welche aber nicht ohne weiteres vom
Proxmox (debian) unterstützt werden. Diese Karten gibts mittlerweile
auch für n' paar cent bei Ebay zu kaufen.
Natürlich könnte man auch vorhandene, dedizierte Gigabit Netzwerkkarten
benutzen, aber ich befürchte, dass dies zu langsam sein würde.


Jan

[Ulli Horlacher]

Jan Novak <rep...@gmail.com> wrote:

> wir haben in der Firma 6 "bare Metal" Server stehen, jeder mit seinem
> eigenem Storage und Gigabit Netzwerkkarten. Auf allen Servern läuft
> ProxmoxVE. Die Nodes sind zu einem Cluster verbunden.
>
> Mir kam jetzt die Idee, die Platten der einzelnen Server in ein
> entsprechendes Gehäuse zu bauen und dort mit einem schnellen
> Board/CPU/(genügend) RAM und passenden Raid Kontroller(n) als Storage
> die Servern wieder zurück zu geben.

Was versprichst du dir davon?
Langweile-Bekaempfung? :-)

> Natürlich könnte man auch vorhandene, dedizierte Gigabit Netzwerkkarten
> benutzen, aber ich befürchte, dass dies zu langsam sein würde.

Wenn dir max 100 MB/s ausreichen...

Mit Magnet-Festplatten im RAID5 kommst du auf 600-1000 MB/s, mit SSDs
nochmal drastisch schneller.



--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Tim Ritberg]

Am 26.05.21 um 12:16 schrieb Jan Novak:

> Hallo,
>
> wir haben in der Firma 6 "bare Metal" Server stehen, jeder mit seinem
> eigenem Storage und Gigabit Netzwerkkarten. Auf allen Servern läuft
> ProxmoxVE. Die Nodes sind zu einem Cluster verbunden.
>
> Mir kam jetzt die Idee, die Platten der einzelnen Server in ein
> entsprechendes Gehäuse zu bauen und dort mit einem schnellen
> Board/CPU/(genügend) RAM und passenden Raid Kontroller(n) als Storage
> die Servern wieder zurück zu geben.

Raidcontrollern habe ich schon lange abgeschworen.
Wir benutzen das SW-Raid 1 von Linux. SSDs sind auch nicht mehr so
teuer, dazu noch eine NIC mit 10Gbit, fertig.

Tim

[Jan Novak]

Am 26.05.21 um 12:47 schrieb Ulli Horlacher:

> Jan Novak <rep...@gmail.com> wrote:
>
>> wir haben in der Firma 6 "bare Metal" Server stehen, jeder mit seinem
>> eigenem Storage und Gigabit Netzwerkkarten. Auf allen Servern läuft
>> ProxmoxVE. Die Nodes sind zu einem Cluster verbunden.
>>
>> Mir kam jetzt die Idee, die Platten der einzelnen Server in ein
>> entsprechendes Gehäuse zu bauen und dort mit einem schnellen
>> Board/CPU/(genügend) RAM und passenden Raid Kontroller(n) als Storage
>> die Servern wieder zurück zu geben.
>
> Was versprichst du dir davon?
> Langweile-Bekaempfung? :-)

Die Frage ist nicht ernst gemeint, oder?
Wenn du die Vorzüge eines geteilten Storages für die Server nicht
kennst, dann brauchen wir nicht weiter zu sprechen.
Ich bin mir aber zu 99%sicher, dass du sie kennst :-)

>> Natürlich könnte man auch vorhandene, dedizierte Gigabit Netzwerkkarten
>> benutzen, aber ich befürchte, dass dies zu langsam sein würde.
>
> Wenn dir max 100 MB/s ausreichen...
>
> Mit Magnet-Festplatten im RAID5 kommst du auf 600-1000 MB/s, mit SSDs
> nochmal drastisch schneller.

Soweit so klar. Daher ja auch meine (korrekte) Annahme, dass ich nativ
mindestens 6mal schneller wäre, als das Gigabit hergibt.
Insofern stellte sich mir ja die Frage, "mit welcher Schnittstelle man
den jeweiligen Servern die (iscsi-) Storages vermittelt" ... (und was
dafür notwendig ist)


Jan

[Ulli Horlacher]

Jan Novak <rep...@gmail.com> wrote:
> Am 26.05.21 um 12:47 schrieb Ulli Horlacher:

> >> Mir kam jetzt die Idee, die Platten der einzelnen Server in ein
> >> entsprechendes Gehäuse zu bauen und dort mit einem schnellen
> >> Board/CPU/(genügend) RAM und passenden Raid Kontroller(n) als Storage
> >> die Servern wieder zurück zu geben.
> >
> > Was versprichst du dir davon?
> > Langweile-Bekaempfung? :-)
>
> Die Frage ist nicht ernst gemeint, oder?

Klardoch.

> Wenn du die Vorzüge eines geteilten Storages für die Server nicht
> kennst, dann brauchen wir nicht weiter zu sprechen.

Wie willst du denn den Storage "teilen"?
Halbe-Halbe?
Welchen Vorteil versprichst du dir davon?

> Insofern stellte sich mir ja die Frage, "mit welcher Schnittstelle man
> den jeweiligen Servern die (iscsi-) Storages vermittelt" ... (und was
> dafür notwendig ist)

Du hast das eigentliche Problem immer noch nicht erkannt.
Es ist NICHT die Geschwindigkeit!
Kommst du nicht selber drauf?
WIE willst du denn auf die Daten zugreifen?

[Jan Novak]

Am 26.05.21 um 12:54 schrieb Tim Ritberg:

>> wir haben in der Firma 6 "bare Metal" Server stehen, jeder mit seinem
>> eigenem Storage und Gigabit Netzwerkkarten. Auf allen Servern läuft
>> ProxmoxVE. Die Nodes sind zu einem Cluster verbunden.
>>
>> Mir kam jetzt die Idee, die Platten der einzelnen Server in ein
>> entsprechendes Gehäuse zu bauen und dort mit einem schnellen
>> Board/CPU/(genügend) RAM und passenden Raid Kontroller(n) als Storage
>> die Servern wieder zurück zu geben.

> Raidcontrollern habe ich schon lange abgeschworen.

naja, auf ein Mainboard wirst du kaum 20-24 Platten bekommen.
Generell nutzen wir auch keine Raid Kontroller, sofern sie nicht in dem
Server schon dabei waren ;-)

> Wir benutzen das SW-Raid 1 von Linux. SSDs sind auch nicht mehr so
> teuer, dazu noch eine NIC mit 10Gbit, fertig.

Auf dem "Storage" Server würden sowieso SSD's als Cache fungieren (zfs
Filesystem) und darüber hinaus möglicherweise sogar ein eigener SSD
Bereich - sofern man diesen und den drehenden Storage ordentlich an die
Server bekommt.
10GB Ethernet...das soll ja auch über Kupfer mit RJ45 gehen. Da die
Strecke zwischen Storage und Server nur wenige Centimeter betragen, wäre
das wohl kein Problem.

Jan

[Jan Novak]

Am 26.05.21 um 14:45 schrieb Ulli Horlacher:

> WIE willst du denn auf die Daten zugreifen?

iSCSI ...

Jan

[Tim Ritberg]

Am 26.05.21 um 14:46 schrieb Jan Novak:

>> Raidcontrollern habe ich schon lange abgeschworen.
>
> naja, auf ein Mainboard wirst du kaum 20-24 Platten bekommen.
> Generell nutzen wir auch keine Raid Kontroller, sofern sie nicht in dem
> Server schon dabei waren ;-)

Du hattest nicht gesagt, wie viel Daten zu lagern willst.

> ...

> 10GB Ethernet...das soll ja auch über Kupfer mit RJ45 gehen. Da die
> Strecke zwischen Storage und Server nur wenige Centimeter betragen, wäre
> das wohl kein Problem.

Da haben wir die Asus XG-C100C.

Tim

[Ulli Horlacher]

Mit welchen Befehlen?
Selbergeschnitzte block-level commands?

Ich glaube immer noch nicht, dass du das EIGENTLICHE Problem verstanden hast.
Du hast da ein Software- und kein Hardware-Problem!

[Jan Novak]

Am 26.05.21 um 14:53 schrieb Tim Ritberg:

>>> Raidcontrollern habe ich schon lange abgeschworen.
>>
>> naja, auf ein Mainboard wirst du kaum 20-24 Platten bekommen.
>> Generell nutzen wir auch keine Raid Kontroller, sofern sie nicht in
>> dem Server schon dabei waren ;-)
> Du hattest nicht gesagt, wie viel Daten zu lagern willst.

ja... viele Platten. Alle >4TB.
Wir haben sehr viele Produktionsdaten. Das ist ja der Grund meiner
Überlegung. Auf dem einen Server ist noch Platz, da brauche ich ihn aber
nicht und auf dem anderen ist keiner mehr, wo er gebraucht wird.

Und dann das ständige hin und her replizieren ... würde alles entfallen.
Genau genommen reichen alle Platten sogar für 2 Storage Systeme. Da
könnten wir eines sogar in einen anderen Brandabschnitt stellen und es
als Replikat des Ersten nutzen, oder als reines Backup.
Sehr verführerisch dieser Gedanke ;-)

>> 10GB Ethernet...das soll ja auch über Kupfer mit RJ45 gehen. Da die
>> Strecke zwischen Storage und Server nur wenige Centimeter betragen,
>> wäre das wohl kein Problem.
> Da haben wir die Asus XG-C100C.

Ah... sehr schön. Hab gerade mal geschaut. Gibts für unter 100€ und voll
abwärtskompatibel. Klingt gut.
Also letztendlich cat7 Kabel und standard Topologie. Dazu noch einen
10GB Switch und das wars... Das klingt erstmal recht einfach.

Gibts da noch irgendwelche bekannten Stolpersteine, an welche noch
gedacht werden sollte?

Jan

[Jan Novak]

Am 26.05.21 um 15:14 schrieb Ulli Horlacher:

> Jan Novak <rep...@gmail.com> wrote:
>> Am 26.05.21 um 14:45 schrieb Ulli Horlacher:
>>
>>> WIE willst du denn auf die Daten zugreifen?
>>
>> iSCSI ...
>
> Mit welchen Befehlen?
> Selbergeschnitzte block-level commands?

> Ich glaube immer noch nicht, dass du das EIGENTLICHE Problem verstanden hast.
> Du hast da ein Software- und kein Hardware-Problem!

Genau genommen habe ich weder ein Soft- noch Hardware Problem :-)

Kennst du proxmoxVE? Wenn nicht, dann guggst du hier:
https://pve.proxmox.com/wiki/Storage:_ZFS_over_iSCSI

Das haben wir bereits im Einsatz. Völlig problemlose Geschichte.

Aber hey, das war nicht meine Frage in diesem Thread, sondern die
Verwirklichung der Anbindung (der Hardware) des Storages an die Server.

Tim hat da ja bereits einen guten Tipp gegeben.


Jan

[Ulli Horlacher]

Jan Novak <rep...@gmail.com> wrote:
> Am 26.05.21 um 15:14 schrieb Ulli Horlacher:
> > Jan Novak <rep...@gmail.com> wrote:
> >> Am 26.05.21 um 14:45 schrieb Ulli Horlacher:
> >>
> >>> WIE willst du denn auf die Daten zugreifen?
> >>
> >> iSCSI ...
> >
> > Mit welchen Befehlen?
> > Selbergeschnitzte block-level commands?
>
> > Ich glaube immer noch nicht, dass du das EIGENTLICHE Problem verstanden hast.
> > Du hast da ein Software- und kein Hardware-Problem!
>
> Genau genommen habe ich weder ein Soft- noch Hardware Problem :-)
>
> Kennst du proxmoxVE? Wenn nicht, dann guggst du hier:
> https://pve.proxmox.com/wiki/Storage:_ZFS_over_iSCSI
>
> Das haben wir bereits im Einsatz. Völlig problemlose Geschichte.

Du kennst wohl ZFS nicht.
Das ist KEIN Cluster-faehiges Filesystem!
Wenn du damit von 2 hosts auf dasselbe filesystem zugreifst ist das SOFORT
nicht reparierbar kaputt.
Kids, don't try this at home!

> Aber hey, das war nicht meine Frage in diesem Thread, sondern die
> Verwirklichung der Anbindung (der Hardware) des Storages an die Server.

Du kannst meine Warnung ignorieren. Dein Problem, nicht meins.

[Kay Martinen]

Am 26.05.21 um 15:14 schrieb Ulli Horlacher:

> Jan Novak <rep...@gmail.com> wrote:
>> Am 26.05.21 um 14:45 schrieb Ulli Horlacher:
>>
>>> WIE willst du denn auf die Daten zugreifen?
>>
>> iSCSI ...
>
> Mit welchen Befehlen?
> Selbergeschnitzte block-level commands?
>
> Ich glaube immer noch nicht, dass du das EIGENTLICHE Problem verstanden hast.
> Du hast da ein Software- und kein Hardware-Problem!

Hmm, Proxmox bietet neben den "üblichen" verdächtigen wie nfs, smb und
iscsi m.W. noch CEPH als Cluster-storage an. Damit kenne ich mich
allerdings auch nicht aus weil ich es hier zu hause nicht brauche. Ich
hole mir die ISOs und sichere die Snapshots via nfs auf meinem Fileserver.

[Nach guck unter "storage") Ach was noch geht ist zfs, zfs over iscsi,
clusterFS, cephFS (oben schon genannt oder?) und rbd(was wohl zu Ceph
gehört). Und neuerdings... "proxmox Backup Server" :-)

Da wäre jetzt die nächste Frage ob er ein komplettes Redundantes Ceph
Storage aufbauen wollte - mit nur einem zentralen Plattenserver oder ein
SAN mit FC-SW und ensprechendem Gedöns.

Und das mit den schon vorhandenen Datenplatten? Mal 2?

Kay

--
Posted via leafnode

[Jan Novak]

Am 26.05.21 um 16:09 schrieb Ulli Horlacher:

>> Das haben wir bereits im Einsatz. Völlig problemlose Geschichte.
>
> Du kennst wohl ZFS nicht.
> Das ist KEIN Cluster-faehiges Filesystem!
> Wenn du damit von 2 hosts auf dasselbe filesystem zugreifst ist das SOFORT
> nicht reparierbar kaputt.
> Kids, don't try this at home!

Beruhige doch mal....
Das haben wir doch auch gar nicht vor.

>> Aber hey, das war nicht meine Frage in diesem Thread, sondern die
>> Verwirklichung der Anbindung (der Hardware) des Storages an die Server.
>
> Du kannst meine Warnung ignorieren. Dein Problem, nicht meins.

Egal was du mir rätst oder sagst, es bleibt _immer_ mein Problem ;-)
Mir kommt es ja fast vor, als würdest du dich in der Haftung für deine
Aussage sehen. Das hier ist nur eine Userforum mit "Meinungen". Ob die
korrekt sind oder nicht, ist letztendlich egal.
Schön dass du dir aber darüber Gedanken machst (ernst gemeint).

Jan

[Tim Ritberg]

Am 26.05.21 um 15:46 schrieb Jan Novak:

>> Da haben wir die Asus XG-C100C.
>
> Ah... sehr schön. Hab gerade mal geschaut. Gibts für unter 100€ und voll
> abwärtskompatibel. Klingt gut.
> Also letztendlich cat7 Kabel und standard Topologie. Dazu noch einen
> 10GB Switch und das wars... Das klingt erstmal recht einfach.
>
> Gibts da noch irgendwelche bekannten Stolpersteine, an welche noch
> gedacht werden sollte?

Hm, die Doku rät dazu, die Nic mit ethtool auf 10G zu zwingen.

Bisher habe ich zwei Karten ohne Switch im Betrieb, direkt mit cat7-Kabel.


Tim

[Jan Novak]

Am 26.05.21 um 16:04 schrieb Kay Martinen:

> Da wäre jetzt die nächste Frage ob er ein komplettes Redundantes Ceph
> Storage aufbauen wollte - mit nur einem zentralen Plattenserver oder ein
> SAN mit FC-SW und ensprechendem Gedöns.

wohl eher letzteres.

>
> Und das mit den schon vorhandenen Datenplatten? Mal 2?

ja... vielleicht.
Es geht ja in meiner Frage um die theoretische Realisierung.
Noch ist nichts gemacht und in Stein gegossen. Es geht um Ideen und
Möglichkeiten.

Jan

[Jan Novak]

Am 26.05.21 um 16:31 schrieb Tim Ritberg:

Das war auch meine erste Idee. Einfach mehrere Karten einbauen: genau
genommen brauche ich 6 externe Anschlüsse. Vermutlich gibts solche
Karten auch als Duale. Dann bräuchten wir 3 Stück plus Raid Controller.

Ein Karte mit Switch bremst das ganze vermutlich ein wenig aus,
andererseits würde das geplante Server-Mainboard eh nicht 6 * 10Gb plus
Raid Kontroller und die ganzen Platten schaffen, insofern also doch über
einen Switch... oh ohh... das alles wird wohl das (noch nicht
vorhandene) Budget sprengen ;-)

Jan

[Kay Martinen]

Am 26.05.21 um 15:53 schrieb Jan Novak:

> Am 26.05.21 um 15:14 schrieb Ulli Horlacher:
>> Jan Novak <rep...@gmail.com> wrote:
>>> Am 26.05.21 um 14:45 schrieb Ulli Horlacher:
>>>
>>>> WIE willst du denn auf die Daten zugreifen?
>>>
>>> iSCSI ...
>>
>> Mit welchen Befehlen?
>> Selbergeschnitzte block-level commands?
>
>> Ich glaube immer noch nicht, dass du das EIGENTLICHE Problem
>> verstanden hast.
>> Du hast da ein Software- und kein Hardware-Problem!
>
> Genau genommen habe ich weder ein Soft- noch Hardware Problem :-)

Öhm, hab ich dich richtig verstanden? Du willst die Datenplatten aus 6
Servern zentralisieren und diesen nur noch Platten mit dem OS lassen?
Und aus diesen 6 mal X Platten willst du *EINEN* Zentralen Server (oder
Zwei wg. Redundanz) bauen die mit höchstgeschwindigkeit variabel
zuschneidbare Blockdevices an die 6 Server liefern?

Hmmm, du hast ein HW und SW Problem. :-)

> Kennst du proxmoxVE? Wenn nicht, dann guggst du hier:
> https://pve.proxmox.com/wiki/Storage:_ZFS_over_iSCSI

zfs over iscsi hast du anfangs nicht erwähnt.

> Aber hey, das war nicht meine Frage in diesem Thread, sondern die
> Verwirklichung der Anbindung (der Hardware) des Storages an die Server.
>
> Tim hat da ja bereits einen guten Tipp gegeben.

Da lese ich auch von deiner Idee eine 2. Brandabschnitts und auslagerung
(von einem der 2 Storage-Server?) dahin.

Was ist denn das eigentliche Problem wenn du schon einen Cluster aus 6
PVE Nodes laufen hast?

Das eine Live-Migration einer VM zum anderen Node zu lange dauert? Dann
hilft vielleicht schon das Netzwerk zwischen den Nodes schneller zu
machen. Und den Switch dazwischen auch.

Oder ist es nur das ein node zu wenig, der andere zu viel Platz frei hat
und das nicht gemittelt werden kann (auch nicht durch migration von
VMs?) Dann helfen vielleicht eher größere Platten in den Servern. Kann
man sukzessive ausbauen, erst den der zu wenig platz hat und dann die
anderen. Methoden ein Raid durch Größere Platten zu vergrößern
existieren ja.

IMHO: Disk 1 Wechseln, rebuild, Disk 2 Wechseln, Rebuild. Dateisystem
vergrößeren.

Aber "irgendeine" art von Speichernetzwerk das auf "irgendeine" Art
blockdaten liefern soll... ich glaube das wird immer langsamer sein als
eine Lokale Platte. Aber es zieht eine Zusätzliche Ebene an komplexität
in das ganze Setup. Das sollte man wohl gut Planen.

N.B. Wenn du 2 idente Server an verschiedenen Orten hast die EINEN
storage bilden, dann brauchst du auch schnelle Verbindungen zwischen
diesen Beiden Orten damit die In Sync bleiben können. Und zusätzlich
dazu die Anbindung deiner eigentlichen Server. Und alles Redundant. D.h.
mind. 2 Schnelle Leitungen (ideal: auf verschiedenen Wegen) zwischen den
Storage-Teilen und von jedem dieser Teile 2 oder mehr leitungen zu
deinen VM-Servern.

Wie viel "Kabel" liegt denn schon - und wohin? ;)

N.B. Wenn du 2 oder mehr (Storage A, Storage B und VM-Server?)
verschiedene Orten verbindest kommt m.E. nur noch Glasfaser in Frage.
Sonst handelst du dir evtl. auch noch Elektrische Masse- oder
Schleifen-Probleme ein die sogar deine ganze Anlage vernichten könnten
(Blitz, Induktion, Stromkreis-verschleppung)

[Ulli Horlacher]

Jan Novak <rep...@gmail.com> wrote:
> Am 26.05.21 um 16:09 schrieb Ulli Horlacher:
> >> Das haben wir bereits im Einsatz. Völlig problemlose Geschichte.
> >
> > Du kennst wohl ZFS nicht.
> > Das ist KEIN Cluster-faehiges Filesystem!
> > Wenn du damit von 2 hosts auf dasselbe filesystem zugreifst ist das SOFORT
> > nicht reparierbar kaputt.
> > Kids, don't try this at home!
>
> Beruhige doch mal....
> Das haben wir doch auch gar nicht vor.

Wenn du kein shared storage machen willst, verstehe ich nicht, warum du
ueberhaupt die Platten in einen fileserver umbauen willst.

Was versprichst du dir davon?

Basteltrieb ausleben?

[Kay Martinen]

Am 26.05.21 um 16:09 schrieb Ulli Horlacher:

> Jan Novak <rep...@gmail.com> wrote:
>> Am 26.05.21 um 15:14 schrieb Ulli Horlacher:
>>> Jan Novak <rep...@gmail.com> wrote:
>>>> Am 26.05.21 um 14:45 schrieb Ulli Horlacher:
>>>>
>>>>> WIE willst du denn auf die Daten zugreifen?
>>>>
>>>> iSCSI ...
>>>
>>> Mit welchen Befehlen?
>>> Selbergeschnitzte block-level commands?
>>
>>> Ich glaube immer noch nicht, dass du das EIGENTLICHE Problem verstanden hast.
>>> Du hast da ein Software- und kein Hardware-Problem!
>>
>> Genau genommen habe ich weder ein Soft- noch Hardware Problem :-)
>>
>> Kennst du proxmoxVE? Wenn nicht, dann guggst du hier:
>> https://pve.proxmox.com/wiki/Storage:_ZFS_over_iSCSI
>>
>> Das haben wir bereits im Einsatz. Völlig problemlose Geschichte.
>
> Du kennst wohl ZFS nicht.
> Das ist KEIN Cluster-faehiges Filesystem!
> Wenn du damit von 2 hosts auf dasselbe filesystem zugreifst ist das SOFORT
> nicht reparierbar kaputt.

Vielleicht meint er ja ZFS AUF iscsi. Ist ISCSI nicht die möglichkeit
ein Blockdevice via Netzwerk-Technik an ein anderes Gerät zu
exportieren? Ich kenne es selbst nicht, hörte aber das man auf dem
storage-host oder iscsi-target volumes anlegen könnte die man auch
entsprechend zuschneiden kann (nicht an datenträgergrenzen gebunden?).
Ob man die Größe aber on-the-fly ändern kann...K.A.

Wäre dann also zfs vom VM-Server via iscsi zu einem volume des storage.
Ist vermutlich laienhaft falsch vormuliert. Hoffe du weißt dennoch was
ich meine.

[Ulli Horlacher]

Kay Martinen <use...@martinen.de> wrote:

> >> Kennst du proxmoxVE? Wenn nicht, dann guggst du hier:
> >> https://pve.proxmox.com/wiki/Storage:_ZFS_over_iSCSI
> >>
> >> Das haben wir bereits im Einsatz. Völlig problemlose Geschichte.
> >
> > Du kennst wohl ZFS nicht.
> > Das ist KEIN Cluster-faehiges Filesystem!
> > Wenn du damit von 2 hosts auf dasselbe filesystem zugreifst ist das SOFORT
> > nicht reparierbar kaputt.
>
> Vielleicht meint er ja ZFS AUF iscsi.

Das hab ich schon so verstanden.
Nur funktioniert das NICHT im Cluster!
ZFS via iscsi-export geht immer nur an EINEN node.
Damit gewinnt man aber nichts gegenueber ZFS auf lokalen Platten.
Ausser man setzt serverseitig so was wie Netapp ein.
Dann geht zwar immer noch kein Cluster-Betrieb, aber dafuer wirds dann
RICHTIG teuer :-)

[Kay Martinen]

Am 26.05.21 um 16:37 schrieb Jan Novak:

K.I.S.S. = Keep it Simple Stupid. ;)

"einfach" größere Platten einbauen. Oder spielt da evtl. eine
Management-Bewilligung mit hinein die excessives Buzzwort-Bingo erfordert?

Dann lüg einfach Blockchain und Crypto dazu, gewürzt mit etwas "KI"
vielleicht noch. ;-) [Ich glaub FeFe lesen färbt langsam ab...]

Klappt nich wenn dort Technisch versierte sitzen - wenn es das gibt? Die
meisten sind wohl eher Technisch-versehrt(e = Invalide) wie man so hört.

BTW. Du weißt das man eine VM auch auf eine andere Art verschieben kann
oder? Bei mir die einzig mögliche da ich keinen Cluster nutze. Ich
stoppe die VM, mache ein Backup (Snapshotmode Stop) davon via nfs auf
meinen Fileserver und dann gehe ich zum anderen Node und hole mir dieses
Backup nach dort hin zurück. Man muß nur mit der VM-ID aufpassen damit
man sich beim automatischen Backup nicht eine bestehende Sicherung mit
der Falschen VMID überschreibt.

[Tim Ritberg]

Am 26.05.21 um 16:37 schrieb Jan Novak:

>> Bisher habe ich zwei Karten ohne Switch im Betrieb, direkt mit
>> cat7-Kabel.
>
> Das war auch meine erste Idee. Einfach mehrere Karten einbauen: genau
> genommen brauche ich 6 externe Anschlüsse. Vermutlich gibts solche
> Karten auch als Duale. Dann bräuchten wir 3 Stück plus Raid Controller.

Ich empfehle dir die Boards von SuperMicro, die haben schon 2x 10Gb
onboard, mal mit Sata oder SAS:
https://www.supermicro.com/en/products/motherboards?pro=processor%3D8443

Wir werden allerdings bald Switche mit 10Gb anschaffen.

Tom

[Kay Martinen]

Am 26.05.21 um 16:55 schrieb Ulli Horlacher:

> Kay Martinen <use...@martinen.de> wrote:
>
>>>> Kennst du proxmoxVE? Wenn nicht, dann guggst du hier:
>>>> https://pve.proxmox.com/wiki/Storage:_ZFS_over_iSCSI
>>>>
>>>> Das haben wir bereits im Einsatz. Völlig problemlose Geschichte.
>>>
>>> Du kennst wohl ZFS nicht.
>>> Das ist KEIN Cluster-faehiges Filesystem!
>>> Wenn du damit von 2 hosts auf dasselbe filesystem zugreifst ist das SOFORT
>>> nicht reparierbar kaputt.
>>
>> Vielleicht meint er ja ZFS AUF iscsi.
>
> Das hab ich schon so verstanden.
> Nur funktioniert das NICHT im Cluster!
> ZFS via iscsi-export geht immer nur an EINEN node.

Aha. Und, kann ein iscsi-host nicht mehrere Volumes haben? Aber
vielleich nahm ich auch nur irrtümlich an das er jedem node ein eigenes
Volume (nach seinem größen-gusto) zuschieben will. Volume1=node1,
volume2=node2 u.s.w. Ich mag nicht recht glauben das iscsi; besser: der
host der es implementiert; das nicht könnte. Und das zfs auf ISCSI
müsste dann wohl auch lokal sein - auf dem jeweiligen vm-host, oder? Das
ist dann zwar nicht Cluster aber so würde es doch gehen oder nicht?


Ich hab auf meinem ProxMox mal versehentlich eine VM angelegt und den
falschen Storage gewählt. Ich wunderte mich dann das ich auf beiden
Nodes eine vm-600 datei sehe - die ist via nfs auf dem Fileserver
gelandet und blieb auch dort. ;-)

Glücklicherweise kann man sie einfach verschieben. Aber die VM darin
lief eigentlich nicht besonders viel langsamer trotz remote image :)
Vom anderen Node aus hätte ich sie aber nicht ein zweites mal starten
können (Migration, Cluster?) denn dem fehlte ja die VM-Definition.

> Damit gewinnt man aber nichts gegenueber ZFS auf lokalen Platten.

Glaube ich dir. Wozu LAN dazwischen schieben wenn's lokal sicher
schneller ginge. Und ich frage mich bei obigem auch wo dann die "1 GB
RAM pro 1TB Plattenplatz" von ZFS erforderlich würden, auf dem VM-Host
oder dem Storage-server. Ich denke ersteres den iscsi ist doch nur der
transport.

> Ausser man setzt serverseitig so was wie Netapp ein.

Blöd gewählter Name finde ich. Da denkt "man" doch eher an eine
Netzwerk-App für ein Schlaufon. :-) Ja, ich hab davon gehört, und das es
"speziell" ist.

> Dann geht zwar immer noch kein Cluster-Betrieb, aber dafuer wirds dann
> RICHTIG teuer :-)

Netapp sind *Nicht* Clusterfähig? Ernsthaft? Warum sind die dann
eigentlich so teuer? Das ist ja ein schöner Mist.

[Jan Novak]

Am 26.05.21 um 16:35 schrieb Kay Martinen:

> zfs over iscsi hast du anfangs nicht erwähnt.

Stimmt.

> Oder ist es nur das ein node zu wenig, der andere zu viel Platz frei hat
> und das nicht gemittelt werden kann (auch nicht durch migration von
> VMs?)

Genau das. Und auch die Repliziererrei hätte dann ein Ende.

> Dann helfen vielleicht eher größere Platten in den Servern. Kann
> man sukzessive ausbauen, erst den der zu wenig platz hat und dann die
> anderen. Methoden ein Raid durch Größere Platten zu vergrößern
> existieren ja.

Korrekt - un dauch genutzt. Dennoch ist das müßig und umständlich,
ständig die Platten zu erweitern. Abgesehend avon, dass die vorhandene
Hardware (Raid controller) kein Hotswap ermöglichen, bzw. nicht so, wie
es nötig wäre.

> Aber "irgendeine" art von Speichernetzwerk das auf "irgendeine" Art
> blockdaten liefern soll... ich glaube das wird immer langsamer sein als
> eine Lokale Platte.

Das mag sein. Obwohl es im Moment mit den Platten kein echtes
performance Problem gibt. Und mit der Zahl der Platten (Raid5 z.B.)
steigt auch idie IO Rate, was mit ~12 PLatten also auch Vorteile bringt.

> Aber es zieht eine Zusätzliche Ebene an komplexität
> in das ganze Setup. Das sollte man wohl gut Planen.

Das ist tatsächlich ein guter Grund, den es zu beachten gibt.

> Wie viel "Kabel" liegt denn schon - und wohin? ;)

viele, sehr viele CAT7 (aber kein Glasfaser) :-)
Das 2. Storage wäre "nur" ein live Backup des ersten und müsste nicht
über die gleiche Geschwindigkeit erreichbar sein, sofern die Zeit
ausreicht, alles synchron zu halten. Aber das ist ja jetzt auch schon
der Fall.


Jan

[Jan Novak]

Am 26.05.21 um 17:36 schrieb Kay Martinen:

>> Das hab ich schon so verstanden.
>> Nur funktioniert das NICHT im Cluster!
>> ZFS via iscsi-export geht immer nur an EINEN node.
>
> Aha. Und, kann ein iscsi-host nicht mehrere Volumes haben? Aber
> vielleich nahm ich auch nur irrtümlich an das er jedem node ein eigenes
> Volume (nach seinem größen-gusto) zuschieben will. Volume1=node1,
> volume2=node2 u.s.w. Ich mag nicht recht glauben das iscsi; besser: der
> host der es implementiert; das nicht könnte. Und das zfs auf ISCSI
> müsste dann wohl auch lokal sein - auf dem jeweiligen vm-host, oder? Das
> ist dann zwar nicht Cluster aber so würde es doch gehen oder nicht?

Genau so ist der Plan ...


Jan

[Jan Novak]

Am 26.05.21 um 17:12 schrieb Kay Martinen:

> K.I.S.S. = Keep it Simple Stupid. ;)

da ist was dran... zugegebermaßen.

> Klappt nich wenn dort Technisch versierte sitzen - wenn es das gibt? Die
> meisten sind wohl eher Technisch-versehrt(e = Invalide) wie man so hört.

:-)))

> BTW. Du weißt das man eine VM auch auf eine andere Art verschieben kann
> oder?

Klar. Mit dem Cluster ist das ja kein Problem. Sind 2 Klicks.
Notfalls in der Console nen Snapshot erstellen und manuell verschieben.
Keine große Sache.

> Bei mir die einzig mögliche da ich keinen Cluster nutze. Ich
> stoppe die VM, mache ein Backup (Snapshotmode Stop) davon via nfs auf
> meinen Fileserver und dann gehe ich zum anderen Node und hole mir dieses
> Backup nach dort hin zurück. Man muß nur mit der VM-ID aufpassen damit
> man sich beim automatischen Backup nicht eine bestehende Sicherung mit
> der Falschen VMID überschreibt.

Korrekt. Das Problem haben wir aber nicht. Alle storages sind ZFS,
selbst das Backup. Alle VM's gibts (durch das Cluster) nur ein mal.
Das passt soweit.

Jan

[Jan Novak]

Am 26.05.21 um 17:39 schrieb Tim Ritberg:

>>> Bisher habe ich zwei Karten ohne Switch im Betrieb, direkt mit
>>> cat7-Kabel.
>>
>> Das war auch meine erste Idee. Einfach mehrere Karten einbauen: genau
>> genommen brauche ich 6 externe Anschlüsse. Vermutlich gibts solche
>> Karten auch als Duale. Dann bräuchten wir 3 Stück plus Raid Controller.
> Ich empfehle dir die Boards von SuperMicro, die haben schon 2x 10Gb
> onboard, mal mit Sata oder SAS:
> https://www.supermicro.com/en/products/motherboards?pro=processor%3D8443

Ich meine, dass 3 von 6 Servern auch ein Supermicro Board im Gehäuse
haben. Die sind ja scheinbar recht verbreitet.

> Wir werden allerdings bald Switche mit 10Gb anschaffen.

Ja, ich denke, darauf läuft es mittel- bis langfristig hinaus.

Jan

[Ulli Horlacher]

Kay Martinen <use...@martinen.de> wrote:

> > ZFS via iscsi-export geht immer nur an EINEN node.
>
> Aha. Und, kann ein iscsi-host nicht mehrere Volumes haben?

Ich seh hier immer noch keinen Vorteil. WARUM sollte man das machen?
Ausser man will durch versehentliche Fehlkonfiguration ALLE Daten verlieren.
Das geht schneller als man denkt. Ein falscher mount und das wars. BTDT :-}

> > Ausser man setzt serverseitig so was wie Netapp ein.
>
> Blöd gewählter Name finde ich. Da denkt "man" doch eher an eine
> Netzwerk-App für ein Schlaufon. :-)

Netapp war vor den Streicheltelefonen da.
Und IOS von Cisco war Jahrzehnte vor Apples iOS da.
Aber manche glauben ja Bill Gates haette das Internet erfunden.

> > Dann geht zwar immer noch kein Cluster-Betrieb, aber dafuer wirds dann
> > RICHTIG teuer :-)
>
> Netapp sind *Nicht* Clusterfähig?

ZFS ist *NICHT* cluster-faehig. Niemals. Egal, welche Transportschicht
und welche Server-Storage-Hardware man dafuer verwendet.
Das wurde beim Design von ZFS voellig uebersehen. 30 Jahre nachdem so was
bereits Industrie-Standard war. Aber man guckt halt selten ueber seinen
Tellerrrand. Da koennte einem ja schwindlig werden.

> Warum sind die dann eigentlich so teuer?

Redundanz. Ausfallsicherheit. Snapshots. Service. Krawatten-Kompabilitaet.

[Kay Martinen]

Am 26.05.21 um 17:45 schrieb Jan Novak:

Ups. Ich...hab's... erraten? Das war so nicht geplant, das hat sich
zufällig so ergeben. :-)

SCNR

Also, eigentlich nur ein "Bunch of Disks" an einem Ort aus dem du jedem
Host seinen eigenen Teil davon zuschieben willst.

Deine 6 PVE Nodes laufen aber im Cluster-Setup? Oder auch das nicht?
Ich hab die Ceph integration irgendwie als eng mit cluster verknüpft in
erinnerung. Wäre das nicht die erste Wahl wenn es um extenen Storage
ginge. Zumindest nehme ich an das der Storage-Server dann auch mit den
Clusternodes mit spielen würde.

[Diedrich Ehlerding]

Kay Martinen meinte:

> Da wäre jetzt die nächste Frage ob er ein komplettes Redundantes Ceph
> Storage aufbauen wollte - mit nur einem zentralen Plattenserver oder
> ein SAN mit FC-SW und ensprechendem Gedöns.

Ein kompletter Ceph-Cluster besteht sinnvollerweise minimaol aus ca. 7
Daten-Servern, jeder mit erlichen Platten, und einigen Monitor-servern.
Sowas braucht man nur bei zeimlich großen Installationen, und bevor man
sowas produktiv einsetzt, sollte man sich eine Zeitlang damit
beschäftigt haben.

--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Kay Martinen]

Am 26.05.21 um 16:31 schrieb Diedrich Ehlerding:

> Kay Martinen meinte:
>
>> Da wäre jetzt die nächste Frage ob er ein komplettes Redundantes Ceph
>> Storage aufbauen wollte - mit nur einem zentralen Plattenserver oder
>> ein SAN mit FC-SW und ensprechendem Gedöns.
>
> Ein kompletter Ceph-Cluster besteht sinnvollerweise minimaol aus ca. 7
> Daten-Servern, jeder mit erlichen Platten, und einigen Monitor-servern.
> Sowas braucht man nur bei zeimlich großen Installationen, und bevor man
> sowas produktiv einsetzt, sollte man sich eine Zeitlang damit
> beschäftigt haben.

Guter Einwand, ich dachte das ginge bei PVE ab mindestens 2 Nodes die
das dann auch noch mit erledigen könnten. Das war dann ja wohl eher nix.

Hab ich evtl. auch mit deren Clustering der PVE Nodes verwechselt oder
in einen Topf geschmissen. Mein Fehler. Ich hoffe Jan weiß es genauer.

Wie auch immer. Ich brauch das hier @home eh nicht. Und wenn mein 2.
Node noch laufen würde hab ich irgendwann mal dran gedacht die beiden
miteinander zu verbinden (PVE-Cluster) evtl. mit einem Raspi dazu (es
soll gehen den als qourum-server her zu nehmen -> corosync?) Aber nur um
live-migration nutzen zu können... ???

Netzteil-inspektion fällig... Es fällt ja auch immer der
nicht-redundante aus. ;-)

[Tim Ritberg]

Am 26.05.21 um 17:51 schrieb Jan Novak:

>
> Ich meine, dass 3 von 6 Servern auch ein Supermicro Board im Gehäuse
> haben. Die sind ja scheinbar recht verbreitet.

Kaufe ich nur für die Arbeit, seit etwa 4 Jahren. Recht günstig und hat
brauchbares IPMI.

Tim

[Jan Novak]

Am 26.05.21 um 19:22 schrieb Tim Ritberg:

Stimmt. Bis darauf, dass di das mit Java verwirklichen (wenigstens die,
die wir hier im Einsatz haben.

Jan

[Diedrich Ehlerding]

Kay Martinen meinte:

>> Ein kompletter Ceph-Cluster besteht sinnvollerweise minimal aus ca.
>> 7 Daten-Servern, jeder mit etlichen Platten, und einigen

>> Monitor-servern. Sowas braucht man nur bei zeimlich großen
>> Installationen, und bevor man sowas produktiv einsetzt, sollte man
>> sich eine Zeitlang damit beschäftigt haben.
>
> Guter Einwand, ich dachte das ginge bei PVE ab mindestens 2 Nodes die
> das dann auch noch mit erledigen könnten.

Nun ja, "Im Prinzip ja" wäre da die richtige Antwort, man bekommt die
ceph-Dienste auf so etwas dazu, dass sie laufen. Man bekommt ceph auf
kleinen Konfiguratio9nen zum laufenb, im Zweifel als VMs in einem
Notebook. Ich habe auch mal zum Kennenlernen ein ceph auf drei
Uraltservern mit je vier Platten in Gang gebracht.

Aber damit hat man erstens nicht die Funktionalität, für die ceph
gedacht ist Zum Beispiel erasure code, also eine Verallgemeinerung von
Raid5 und Raid 6, auf viele Server und deren Platten mit Sicherheit vor
Ausfall eines ganzen Knotens. Die Idee von ceph ist: billige Platten,
kein Raiodcontroller, Daten über viele Server replizieren; normalerweise
mit replication=3 (d.h. die Daten liegen auf drei Platten, die auf drei
server verteilt sind; auch wenn einer davon ausfällt, hat man noch
Redundanz, und die braucht man bei billigen großen Platten auch). Dafür
braucht man eigentlich mindestens 4 Server (denn man will ja, dass bei
Ausfall einer Maschine die Redundanz wieder hergestellt werden kann -
wer weiß, wie schnell man eine Ersatzmaschine bekommt). Und in so einer
Konfiguration hat man netto nur 1/4 der Bruttokapazität (wenn man mit
replication 3 und Platzreserve für den K-Fall eines Servers arbeitet).
Reale ceph-Cluster laufen meist mit Erasurecode, weil jedem
Kostenstelleniunhaber die dreifache Redundanz plus Kapazitätsreserve
seelischen Schmerz bereitet - aber für eine etws plattensparsamere
Konfiguration von Erasurecode 4+2, also sowas Ähnliches wie Raid6,
braucht man 6 Server und einen als Reserve. (Man /kann/ bei ceph und
erasure code die Redundanz ins Aschgraue treiben, wenn mans denn
braucht; ich kenne einen realen Fall, wo wg. Standortredundanz 20 Server
plus Monitore und Gateways auf 2 Standorte verteilt wurden und dann die
Daten auf EC 7+11 (!), also 11 Parityplatten für 7 Datenplatten,
gespeichert wurden; das überlebte dann (für die ceph-Clients
unterbrechungtsfrei) tatsächlich den Ausfall eines ganzen Standorts und
hatte am überlebenden Standort immer noch Redundanz gegen Plattenfehler
und den ausfall eines ganzen Servers). Wie gesagt: ceph ist was für
große Installationen; o.g. war eher noch klein und hatte netto dann ca.
800 TB Nutzkapazität.

Und zweitens schrieb ich "produktiv einsetzen". Dafür schlägt ceph.com
sowas vor wie: Monitore auf drei dedizierten servervn, nicht mit den
Plattenb mischen; Gateways für cephfs ioder iscsi auf dedizierten
Servern, auf den ceph-Knoten /nur/ die ceph-Funkjtionalität, nicht noch
zusätzlich zB proxmox, ... Wie gesagt: etwas für große Umgebungen.

Mit VMs auf dem Notebook (mit viel RAM) kann man das Ganze kennenlernen.
Wenn mans aber produktiv einsetzen will, ist sowas wie "3 kleine Server
mit je 4 Platten" nicht das Gelbe vom Ei.

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Kay Martinen <use...@martinen.de> wrote:
>
>> > ZFS via iscsi-export geht immer nur an EINEN node.
>>
>> Aha. Und, kann ein iscsi-host nicht mehrere Volumes haben?
>
>Ich seh hier immer noch keinen Vorteil. WARUM sollte man das machen?

VMs von einem Host auf den anderen migrieren ohne die Daten
umzukopieren. Wenn Dein VMware Cluster Vmotion beherrscht: Genau das
meint Jan. Nur halt nicht mit VMware, sondern mit Proxmox.


--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Ulli Horlacher]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:

> ceph ist was für große Installationen; o.g. war eher noch klein und hatte
> netto dann ca. 800 TB Nutzkapazität.

Ist CephFS denn wie NFS multi-mount-faehig, also kann man gleichzeitig von
mehreren Clients aus drauf (schreibend!) zugreifen?

Das fuehrt bei klassischen UNIX filesystemen sofort zur Zerstoerung, ZFS
inklusive.

AFS konnte das, ist aber laengst Geschichte und DFS kam niemals zum
Durchbruch wegen Lizenz-Murks.

[Jan Novak]

Am 27.05.21 um 09:43 schrieb Diedrich Ehlerding:

... (sehr interessanter Beitrag)

>
> Mit VMs auf dem Notebook (mit viel RAM) kann man das Ganze kennenlernen.
> Wenn mans aber produktiv einsetzen will, ist sowas wie "3 kleine Server
> mit je 4 Platten" nicht das Gelbe vom Ei.

Mit ceph habe ich mich auch noch nie beschäftigt und habe nur sehr
rudimentäre Infos.
Aber dein Beitrag kling nach "mehr" :-)

Wir haben aktuell 5 Proxmox Server und es werden 2 weitere dazu kommen.
Alle Server haben völlig verschiedene Platten und Kapazitäten (das ist
ja mein Problem).

Das gesamte Storage glatt zu bügeln, wäre wirklich eine große
Erleichterung. Ich muss mal irgendwo ein Test-Szenario aufbauen und
damit spielen.

Jan

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >Kay Martinen <use...@martinen.de> wrote:
> >
> >> > ZFS via iscsi-export geht immer nur an EINEN node.
> >>
> >> Aha. Und, kann ein iscsi-host nicht mehrere Volumes haben?
> >
> >Ich seh hier immer noch keinen Vorteil. WARUM sollte man das machen?
>
> VMs von einem Host auf den anderen migrieren ohne die Daten
> umzukopieren.

Bei so einer Aktion hab ich durch eine mount race condition ein Multi-TB
ZFS volume vernichtet.

[Tim Ritberg]

Am 27.05.21 um 07:18 schrieb Jan Novak:

> Stimmt. Bis darauf, dass di das mit Java verwirklichen (wenigstens die,
> die wir hier im Einsatz haben.
>
> Jan

Ach schon lange html5.

Tim

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> >Kay Martinen <use...@martinen.de> wrote:
>> >
>> >> > ZFS via iscsi-export geht immer nur an EINEN node.
>> >>
>> >> Aha. Und, kann ein iscsi-host nicht mehrere Volumes haben?
>> >
>> >Ich seh hier immer noch keinen Vorteil. WARUM sollte man das machen?
>>
>> VMs von einem Host auf den anderen migrieren ohne die Daten
>> umzukopieren.
>
>Bei so einer Aktion hab ich durch eine mount race condition ein Multi-TB
>ZFS volume vernichtet.

In VMware ist das enterprise-grade technologie. Es wurde noch niemand
gefeuert weil er es benutzt hat.

Und dass ZFS um Größenordnungen zickiger ist als NTFS und ext4 ist
bekannt.

[Diedrich Ehlerding]

Jan Novak meinte:

> Mit ceph habe ich mich auch noch nie beschäftigt und habe nur sehr
> rudimentäre Infos.
> Aber dein Beitrag kling nach "mehr" :-)

Ich will deine Euphorie nicht dämpfen ... ja, ceph ist eine geile Idee,
aber bedenke:

a) es ist was für sehr große Installationen. Der typische Einsatzfall
ist: Speichern von "binary large objects", also sowas wie gecannte
Dokuemnte, Fotos, Videos, ...; es kann aber eben auch block devices und
Files liefern. Ich kenne es auch als Sicherungsziel (TSM kann zB auf
ceph zugreifen und seine Daten da reinpusten, das ist dann ein Konzept
"Sicherung auf billigen Platten statt auf Bändern")

b) es dauert einige Zeit, sich da reinzuarbeiten und die Konzepte zu
verstehen. Mehr Zeit als man als Amateur üblicherweise hat. Und man muss
die Konzepte wirklich verstehen, sonst läuft man in die Irre.

[Diedrich Ehlerding]

Ulli Horlacher meinte:

> Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>
>> ceph ist was für große Installationen; o.g. war eher noch klein und
>> hatte netto dann ca. 800 TB Nutzkapazität.
>
> Ist CephFS denn wie NFS multi-mount-faehig, also kann man gleichzeitig
> von mehreren Clients aus drauf (schreibend!) zugreifen?

Ja. cephfs ist ein posix-konformes Netzwerk-Filesystem und funktioniert
in puncto shared Zugriff von mehreren Hosts ähnlich wie nfs (nur dass
die Daten eben bei entsprechender Konfiguration des ceph-Clusters
hochgradig redundant sind, ggf auch standortübergreifend).

ceph kann ggf aber auch virtuelle Platten hinausreichen; erwähnt wurde
ja, dass proxmox ceph-rbd ("rados block device") bedienen kann. Ich
kenne proxmox nicht, vermute aber, dass man dann der VM so eine rbd-
Platte über librbd zuweisen kann (d.h. dass dann die VM eine virtuelle
scsi-Platte sieht). Auch darüber könnte man also einen gemeinsamen
speicher für viele VMs aufbauen; Voraussetzung ist dann, dass der
Virtualisierer solche Platten über librbd an die VM durchreihen kann.
Ich habe mal Demo-Installationen von openstack gesehen, als
Virtualisierer war da kvm in Gang. Alternative wäre auch Zugriff über
iscsi, d.h. so eine rbd-Platte über ein iscsi-Gateway direkt an Windows-
VMs zu hängen; auch darüber bekommt man einen shared Zugriff mehrerer
(Virtualisierungs-)Server auf den ceph-Cluster hin. Wenn man unbedingt
will, auch einen Cluster aus mehreren viortuellen Maschinen mit Zugriff
auf dieselbe virtuelle Platte.

[Diedrich Ehlerding]

Marc Haber meinte:

>>> VMs von einem Host auf den anderen migrieren ohne die Daten
>>> umzukopieren.
>>
>>Bei so einer Aktion hab ich durch eine mount race condition ein
>>Multi-TB ZFS volume vernichtet.
>
> In VMware ist das enterprise-grade technologie. Es wurde noch niemand
> gefeuert weil er es benutzt hat.
>
> Und dass ZFS um Größenordnungen zickiger ist als NTFS und ext4 ist
> bekannt.

Wobei man ehrlicherweise zugeben muss: wenn man ein ntfs versehentlich
an mehreren Hosts gleichzeitig mountet, ist die Wahrscheinlichkeit für
gehäkelten Datenrhabarber auch nicht Null.

VMWare hat mit seinem vmfs in der Tat ein hared Filesystem für mehrere
ESX-server, die über iscsi oder über Fibrechannel an von mehreren Hoists
gleichzeitig zugreifbare Blockdevices ranko0mmen. Aber wenn man wie im
Fall iscsi übers Netz gehen müsste - warum nimmt man dann nicht gleich
nfs?

[Kay Martinen]

Am 27.05.21 um 07:18 schrieb Jan Novak:

Alte Boards deren BMC/Web altes Java haben will?

Ich hab hier Proliants der Gen 4 deren ILO Web ansich gut im Browser
läuft. Aber wenn man die Remote Konsole oder Remote Media verwenden will
braucht man antikes jre 1.3.

Ein Gen.5 ist da nur "etwas" moderner. Aber mein kram hier ist ja auch
steinalt.

Gleiches trifft auf Cisco Catalyst 29xx und 65xx zu. Nur da läuft
überhaupt nichts Konfigurierendes ohne entsprechend "rustikales" Java
auf dem Browsenden PC.

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:

> >Bei so einer Aktion hab ich durch eine mount race condition ein Multi-TB
> >ZFS volume vernichtet.
>
> In VMware ist das enterprise-grade technologie. Es wurde noch niemand
> gefeuert weil er es benutzt hat.
>
> Und dass ZFS um Größenordnungen zickiger ist als NTFS und ext4 ist
> bekannt.

ext4 geht genauso schnell kaputt wie ZFS bei multi-mount.
NTFS hab ich nicht im Eisatz.

[Marc Haber]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>Marc Haber meinte:
>
>>>> VMs von einem Host auf den anderen migrieren ohne die Daten
>>>> umzukopieren.
>>>
>>>Bei so einer Aktion hab ich durch eine mount race condition ein
>>>Multi-TB ZFS volume vernichtet.
>>
>> In VMware ist das enterprise-grade technologie. Es wurde noch niemand
>> gefeuert weil er es benutzt hat.
>>
>> Und dass ZFS um Größenordnungen zickiger ist als NTFS und ext4 ist
>> bekannt.
>
>Wobei man ehrlicherweise zugeben muss: wenn man ein ntfs versehentlich
>an mehreren Hosts gleichzeitig mountet, ist die Wahrscheinlichkeit für
>gehäkelten Datenrhabarber auch nicht Null.

Ich beschrieb oben Vmotion. Dabei wird die VM auf einem Host
angehalten, dann der State auf den neuen Host migriert und die Vm dort
dan wieder gestartet. Es gibt keinen Zeitpunkt, bei dem die VMs auf
beiden Hosts gleichzeitig laufen KÖNNTE.

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>
>> >Bei so einer Aktion hab ich durch eine mount race condition ein Multi-TB
>> >ZFS volume vernichtet.
>>
>> In VMware ist das enterprise-grade technologie. Es wurde noch niemand
>> gefeuert weil er es benutzt hat.
>>
>> Und dass ZFS um Größenordnungen zickiger ist als NTFS und ext4 ist
>> bekannt.
>
>ext4 geht genauso schnell kaputt wie ZFS bei multi-mount.

Multimount kommt bei Vmotion nicht vor.

[Kay Martinen]

Am 26.05.21 um 18:09 schrieb Ulli Horlacher:

> Kay Martinen <use...@martinen.de> wrote:
>
>>> ZFS via iscsi-export geht immer nur an EINEN node.
>>
>> Aha. Und, kann ein iscsi-host nicht mehrere Volumes haben?
>
> Ich seh hier immer noch keinen Vorteil. WARUM sollte man das machen?

Schrieb ich das nicht beispielhaft? Damit Host 1 ein "volume 1" auf
einem Zentralen; aber redundant speichernden Server mounten kann. Und
host 2 dann ein "Volume 2". Also jeder bekommt seinen eigenen storage,
nur eben extern und jeder so viel wie er braucht.

Gut, kann man auch mit anderen protokollen machen aber er hat nun mal
iscsi ins gespräch geworfen. Und meine Frage ist eben: Kann ein Server
der iscsi anbietet (und IMHO target genannt wird) nur EINE
Partition/Volume/Speichersegment an genau EINEN Host abgeben, oder kann
er 2 oder mehr solcher Speicher-Einheiten an mehr als einen Host abgeben
- zeitgleich?!

Ich rede NICHT von EINEM Volume das multiple gemountet werden soll!

So weit ich das verstand geht es ihm vor allem um die ausnivellierung
der unterschiedlichen Speicherkapazitäten seiner VM-Server.

Er redet da zwar auch von replizierung (nicht Backup oder Snapshots) was
ich nicht recht verstehe. Aber ich nehme an das es dabei um
Sicherungskopien laufender VMs geht. Die kann man auch auf einen
externen aber host-exklusiven Speicher auslagern.

Und wenn es doch um was anderes geht kann man das IMHO notfalls auch auf
ein nfs-share speichern und es dann vom anderen host aus lesen. Also
auch kein gemeinsamer R/W zugriff auf einen speicher. Dort wäre er aber
prinzipiell möglich und sollte vermieden werden - durch den Operator.

Ob das bei PVE automatisiert liefe weiß ich grad nicht. Bei
Backup/Snapshots gehts!

Und m.W. ist einer der Vorzüge eines Cluster-Setups von Proxmox Nodes
das man eine Live-migration machen kann. Dabei wird die VM auf den
anderen Server kopiert und [vermutung] auf dem alten gestoppt während
sie auf dem neuen an der gleichen stelle weiter macht.

Aber was erzähle ich dir das, lt. deinem Footer wirst du das wohl
wissen. Oder benutzt man im TIK so was nicht?

> Ausser man will durch versehentliche Fehlkonfiguration ALLE Daten verlieren.
> Das geht schneller als man denkt. Ein falscher mount und das wars. BTDT :-}

Glaub ich dir. Ich hab damals unter DOS und OS/2 meine erfahrungen
gesammelt mit LAN-Freigaben, share.exe und das es keine gute idee ist
eine Datei zum schreiben offen zu haben die von anderen auch beschrieben
werden kann. Glücklicherweise war das nur mein FTN-Mailbox System das
auf filesharing und filelocking eingerichtet war. Und meist eh null-byte
semaphoren (in eine RAMdisk) knallte damit aktionen ausgelöst werden.
Die liefen bei mir allerdings nur auf einem Server und die
mailer-clients hielten dann eh die füße still bis der job erledigt war.

[Ulli Horlacher]

Kay Martinen <use...@martinen.de> wrote:
> Am 26.05.21 um 18:09 schrieb Ulli Horlacher:
> > Kay Martinen <use...@martinen.de> wrote:
> >
> >>> ZFS via iscsi-export geht immer nur an EINEN node.
> >>
> >> Aha. Und, kann ein iscsi-host nicht mehrere Volumes haben?
> >
> > Ich seh hier immer noch keinen Vorteil. WARUM sollte man das machen?
>
> Schrieb ich das nicht beispielhaft? Damit Host 1 ein "volume 1" auf
> einem Zentralen; aber redundant speichernden Server mounten kann. Und
> host 2 dann ein "Volume 2". Also jeder bekommt seinen eigenen storage,
> nur eben extern und jeder so viel wie er braucht.

Und wo ist nun der Vorteil gegenueber lokalem Volume?
Ich seh das immer noch nicht.
Wenn du glaubst du koenntest so dynamisch Speicherplatz umverteilen: das
fuehrt mit selbstgestrickter Software in die Katastrophe.
Die Frage ist nicht ob, sondern wann :-)

> Gut, kann man auch mit anderen protokollen machen aber er hat nun mal
> iscsi ins gespräch geworfen. Und meine Frage ist eben: Kann ein Server
> der iscsi anbietet (und IMHO target genannt wird) nur EINE
> Partition/Volume/Speichersegment an genau EINEN Host abgeben, oder kann
> er 2 oder mehr solcher Speicher-Einheiten an mehr als einen Host abgeben
> - zeitgleich?!

Klar geht das.

> Ich rede NICHT von EINEM Volume das multiple gemountet werden soll!

Das ist doch Fehlkonfiguration aber SCHNELL erreicht!
Und dann hast du zerstoerte Filesysteme.
So was geht GANZ SCHNELL.

> Und m.W. ist einer der Vorzüge eines Cluster-Setups von Proxmox Nodes
> das man eine Live-migration machen kann. Dabei wird die VM auf den
> anderen Server kopiert und [vermutung] auf dem alten gestoppt während
> sie auf dem neuen an der gleichen stelle weiter macht.

Dazu braucht man aber keinen zentralen Storage.

> Aber was erzähle ich dir das, lt. deinem Footer wirst du das wohl
> wissen. Oder benutzt man im TIK so was nicht?

Wir setzen (produktiv) ausschliesslich VMware auf Netapp mit NFS ein.

[Jan Novak]

Am 27.05.21 um 10:57 schrieb Diedrich Ehlerding:

> Jan Novak meinte:
>
>> Mit ceph habe ich mich auch noch nie beschäftigt und habe nur sehr
>> rudimentäre Infos.
>> Aber dein Beitrag kling nach "mehr" :-)
>
> Ich will deine Euphorie nicht dämpfen ... ja, ceph ist eine geile Idee,
> aber bedenke:
>
> a) es ist was für sehr große Installationen. Der typische Einsatzfall
> ist: Speichern von "binary large objects", also sowas wie gecannte
> Dokuemnte, Fotos, Videos, ...; es kann aber eben auch block devices und
> Files liefern.

VM Partitionen wäre unser Anwendungsfall.
Ob als Block Device, oder File Store ist nur eine Frage des Handlings.

> b) es dauert einige Zeit, sich da reinzuarbeiten und die Konzepte zu
> verstehen. Mehr Zeit als man als Amateur üblicherweise hat.

Ich bin doch ein Profi ;-)

> Und man muss
> die Konzepte wirklich verstehen, sonst läuft man in die Irre.

_Das_ ist doch fast überall so. Halbwissen ist mehr als gefährlich!

Jan

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Wenn du glaubst du koenntest so dynamisch Speicherplatz umverteilen: das
>fuehrt mit selbstgestrickter Software in die Katastrophe.

Proxmox ist keine selbstgestrickte Software. Es ist zwar nicht so
ausgefeilt wie VMware, aber dass es eine VM von einem Host auf einen
anderen schieben kann traue ich ihm jetzt schon zu.

Und _DAS_ war die Aufgabe.

Schade dass Du es Dir nicht vorstellen kannst, es ist millionenfach im
Einsatz. Vielleicht nicht in Deiner Welt, aber es gibt eine Welt
jenseits Deines Tellerrands.

>> Aber was erzähle ich dir das, lt. deinem Footer wirst du das wohl
>> wissen. Oder benutzt man im TIK so was nicht?
>
>Wir setzen (produktiv) ausschliesslich VMware auf Netapp mit NFS ein.

Und auf dem NFS-Server liegen vmdk-Dateien. Und was genau passiert,
wenn man zwei VMS startet, die beide dasselbe vmdk einhängen?

Exakt dasselbe passiert wenn man die Images per iSCSI an den Host
heranholt.

Grüße
Marc

[Diedrich Ehlerding]

Ulli Horlacher meinte:

> Und wo ist nun der Vorteil gegenueber lokalem Volume?

Dass man ein Gastsystem entweder auf diesem oder auf jenem
Virtualisierungshost starten kann (also Lastverteilung auf die CPUn und
den Hauptspeicher).

Dass man einen gemeinsamen großen Topf an speicher hat, aus dem man die
virtuellen Platten schnitzt, und nicht im schlimmsten Fall einen Server,
der noch CPU- und Speicherreserven hat, aber auf den lokalen Platten
keinen Platz, und umgekehrt einen anderen, der zwar noch Platz af seinen
Platten hat, aber zuwenig Speicher.

[Diedrich Ehlerding]

Marc Haber meinte:

>>>>Bei so einer Aktion hab ich durch eine mount race condition ein
>>>>Multi-TB ZFS volume vernichtet.
>>>
>>> In VMware ist das enterprise-grade technologie. Es wurde noch
>>> niemand gefeuert weil er es benutzt hat.
>>>
>>> Und dass ZFS um Größenordnungen zickiger ist als NTFS und ext4 ist
>>> bekannt.
>>
>>Wobei man ehrlicherweise zugeben muss: wenn man ein ntfs versehentlich
>>an mehreren Hosts gleichzeitig mountet, ist die Wahrscheinlichkeit für
>>gehäkelten Datenrhabarber auch nicht Null.
>
> Ich beschrieb oben Vmotion. Dabei wird die VM auf einem Host
> angehalten, dann der State auf den neuen Host migriert und die Vm dort
> dan wieder gestartet. Es gibt keinen Zeitpunkt, bei dem die VMs auf
> beiden Hosts gleichzeitig laufen KÖNNTE.

Ja, du hast das geschrieben, aber darum gings gar nicht. Dein Vorposter
schrieb von einem anderen Szenario, nämlich von mehrfach-Mount desselben
zfs. Und deshalb geht dein Vergleich von zfs und ntwfs hier in die Irre.
Wenn du ein ntfs oder ext4 an mehreren Hosts gleichzeitig mountest (und
die entsprechenden Warnungen ignorierst), gehen die ebenso kaputt wie
ein zfs.

Dass vmfs im Gegensatz zu oben genannten Filesystemen ein /shared/
Filesystem, ein Clusterfilesystem ist (zur Aufnahme von u.a. vmdks, die
dann aber in der Tat jeweils nur an einem ESX-Host von einem Gast
betrieben werden), das also gleichzeitig von mehreren ESX-servern
betrieben wir, hatte ich ja schon geschrieben, nur hast du es
anscheinend überlesen. Und genau darum gehts bei vmotion und ähnlichen
Techniken (kvm kann sowas wohl auch): dass beide Virtualisierer Zugriff
auf den Storage haben müssen, auf dem die virtuelle Platte(n) des
Gastsystems liegen.

Und das kann man in ESX eben auf Blockdevice-Ebene haben (durch ein
shared Filesystem). Meinetwegen mag da jemand auch ein ocfs2 in Gang
setzen. Für die Größenordnung, die wir hier diskutieren, scheint mir
aber ein nfs-Server als shared storage am sinnvollsten zu sein.

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >Wenn du glaubst du koenntest so dynamisch Speicherplatz umverteilen: das
> >fuehrt mit selbstgestrickter Software in die Katastrophe.
>
> Proxmox ist keine selbstgestrickte Software. Es ist zwar nicht so
> ausgefeilt wie VMware, aber dass es eine VM von einem Host auf einen
> anderen schieben kann traue ich ihm jetzt schon zu.

Wir diskutieren hier ueber iscsi-Export an mehrere nodes. Das hat erstmal
mit Proxmox GAR NIX zu tun. Ueber Proxmox habe ich gar nichts geschrieben,
zumal ich das auch nie eingesetzt habe. Ich kenn das nur aus Beschreibungen.

> >Wir setzen (produktiv) ausschliesslich VMware auf Netapp mit NFS ein.
>
> Und auf dem NFS-Server liegen vmdk-Dateien. Und was genau passiert,
> wenn man zwei VMS startet, die beide dasselbe vmdk einhängen?

vsphere laesst das nicht zu.

[Ulli Horlacher]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:

> > Und wo ist nun der Vorteil gegenueber lokalem Volume?
>
> Dass man ein Gastsystem entweder auf diesem oder auf jenem
> Virtualisierungshost starten kann (also Lastverteilung auf die CPUn und
> den Hauptspeicher).

Dann muessen aber beide hosts das Volume gemountet haben. Das geht mit
keinem klassischen Linux filesystem auf block-device-Ebene.

[Tim Ritberg]

Am 28.05.21 um 10:57 schrieb Ulli Horlacher:

> Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>
>>> Und wo ist nun der Vorteil gegenueber lokalem Volume?
>>
>> Dass man ein Gastsystem entweder auf diesem oder auf jenem
>> Virtualisierungshost starten kann (also Lastverteilung auf die CPUn und
>> den Hauptspeicher).
>
> Dann muessen aber beide hosts das Volume gemountet haben. Das geht mit
> keinem klassischen Linux filesystem auf block-device-Ebene.

Also ich kann prima mit Xen eine VM von Server A zu B verschieben,
während das läuft. Storage ist bei uns ein NFS-Server.

Tim

[Diedrich Ehlerding]

Ulli Horlacher meinte:

>> Dass man ein Gastsystem entweder auf diesem oder auf jenem
>> Virtualisierungshost starten kann (also Lastverteilung auf die CPUn
>> und den Hauptspeicher).
>
> Dann muessen aber beide hosts das Volume gemountet haben. Das geht mit
> keinem klassischen Linux filesystem auf block-device-Ebene.

Wenn man vmware und vmfs nicht verwenden will, sondern alles
handstricken will: ocfs2 kann das beispielsweise. Man könnte auch
darüber nachdenken, lvm (in der Variante clvm) einzusetzen und lvm-
Volumes als virtuelle Platten zu verwenden.

Aber genau deshalb, weil das nur mit bestimmten (wenigen) Blockdevice-
Mechanismen geht, nimmt man sinnvollerweise im kleinen hausgemachten
Umfeld ohne ESX (<duck> oder HyperV mit cluster shared volumes, HyperV
kann das nämlich auch </duck>) zB einen nfs-server

[Kay Martinen]

Am 28.05.21 um 08:59 schrieb Jan Novak:

> Am 27.05.21 um 10:57 schrieb Diedrich Ehlerding:
>> Jan Novak meinte:
>>
>>> Mit ceph habe ich mich auch noch nie beschäftigt und habe nur sehr
>>> rudimentäre Infos.
>>> Aber dein Beitrag kling nach "mehr" :-)
>>
>> Ich will deine Euphorie nicht dämpfen ... ja, ceph ist eine geile Idee,
>> aber  bedenke:
>>
>> a) es ist was für sehr große Installationen. Der typische Einsatzfall
>> ist: Speichern von "binary large objects", also sowas wie gecannte
>> Dokuemnte, Fotos, Videos, ...; es kann aber eben auch block devices und
>> Files liefern.

VM-Images sind auch BLOBs. Steckt halt nur ein Dateisystem im container.

> VM Partitionen wäre unser Anwendungsfall.
> Ob als Block Device, oder File Store ist nur eine Frage des Handlings.

Was spricht dann eigentlich gegen einen schnell angebundenen nfs-server
mit platz für all eure VMs? Das nicht ausgeschlossen werden kann das
eine VM auch mal auf zwei hosts hoch läuft und es dann datei-konfetti
regnet - wie ulli meinte? Ich dachte PVE würde das verhindern... was ich
mangels cluster nicht prüfen kann.

>> b) es dauert einige Zeit, sich da reinzuarbeiten und die Konzepte zu
>> verstehen. Mehr Zeit als man als Amateur üblicherweise hat.
>
> Ich bin doch ein Profi ;-)

? Aha! Also, ich nicht! :-)

>> Und man muss
>> die Konzepte wirklich verstehen, sonst läuft man in die Irre.
>
>
> _Das_ ist doch fast überall so. Halbwissen ist mehr als gefährlich!

Schönen dank das du mir Gefährlichkeit attestierst - weil ich von ceph
u.a. so herzlich wenig ahnung hab. ;-)

[Warum muß ich grad an "Sledge Hammer" denken] :)

[Kay Martinen]

Am 28.05.21 um 09:46 schrieb Diedrich Ehlerding:

> Marc Haber meinte:
>
>>>>> Bei so einer Aktion hab ich durch eine mount race condition ein
>>>>> Multi-TB ZFS volume vernichtet.
>>>>
>>>> In VMware ist das enterprise-grade technologie. Es wurde noch
>>>> niemand gefeuert weil er es benutzt hat.
>>>>
>>>> Und dass ZFS um Größenordnungen zickiger ist als NTFS und ext4 ist
>>>> bekannt.
>>>
>>> Wobei man ehrlicherweise zugeben muss: wenn man ein ntfs versehentlich
>>> an mehreren Hosts gleichzeitig mountet, ist die Wahrscheinlichkeit für
>>> gehäkelten Datenrhabarber auch nicht Null.
>>
>> Ich beschrieb oben Vmotion. Dabei wird die VM auf einem Host
>> angehalten, dann der State auf den neuen Host migriert und die Vm dort
>> dan wieder gestartet. Es gibt keinen Zeitpunkt, bei dem die VMs auf
>> beiden Hosts gleichzeitig laufen KÖNNTE.
>
> Ja, du hast das geschrieben, aber darum gings gar nicht. Dein Vorposter
> schrieb von einem anderen Szenario, nämlich von mehrfach-Mount desselben
> zfs. Und deshalb geht dein Vergleich von zfs und ntwfs hier in die Irre.

Ich weiß nicht woher du das raus liest. Ich hab das so nicht
geschrieben, Marc m.W. auch nicht und was Jan da genau meinte scheint
mir bestenfalls unklar. Und sowohl Diedrich als auch Marc bezogen sich
ja auf vsphere und vmotion.

> anscheinend überlesen. Und genau darum gehts bei vmotion und ähnlichen
> Techniken (kvm kann sowas wohl auch): dass beide Virtualisierer Zugriff
> auf den Storage haben müssen, auf dem die virtuelle Platte(n) des
> Gastsystems liegen.

ACK. EINEN Storage müssen sie gemeinsam haben. Aber es spricht doch
nichts dagegen wenn jeder Host auch noch eigenen Storage für sich hat.
GGf. um einen grundbestand an festen VMs Initial vom gemeinsamen storage
auf den lokalen zu legen und den gemeinsamen nur für volatiles zu nutzen.

Hast du diese Annahme vielleicht übergangen?

> setzen. Für die Größenordnung, die wir hier diskutieren, scheint mir
> aber ein nfs-Server als shared storage am sinnvollsten zu sein.

Dito.

[Tim Ritberg]

Am 28.05.21 um 14:06 schrieb Kay Martinen:

> Was spricht dann eigentlich gegen einen schnell angebundenen nfs-server
> mit platz für all eure VMs? Das nicht ausgeschlossen werden kann das
> eine VM auch mal auf zwei hosts hoch läuft und es dann datei-konfetti
> regnet - wie ulli meinte? Ich dachte PVE würde das verhindern... was ich
> mangels cluster nicht prüfen kann.

Sowas habe ich für Xen.
Leider prüft Xen "clusterweit" nicht, welche VM läuft. Musste ich ein
Script schreiben und eine Statusdatei auf dem NFS-Server ablegen.

Tim

[Marc Haber]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>Ja, du hast das geschrieben, aber darum gings gar nicht. Dein Vorposter
>schrieb von einem anderen Szenario, nämlich von mehrfach-Mount desselben
>zfs.

Das habe ich so nicht verstanden.

Framstag wollte wissen, warum man ein Blockdevice an mehrere Hosts
exportieren möchte. Ich antwortete mit dem für mich natürlichen
Usecase, der zugleich in meiner Welt den bei weitem überwiegenden
Anteil der Verwendungen darstellt.

>Und das kann man in ESX eben auf Blockdevice-Ebene haben (durch ein
>shared Filesystem).

Wenn Du das als Filesystem sehen möchtest, gerne.

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:

>> >Wir setzen (produktiv) ausschliesslich VMware auf Netapp mit NFS ein.
>>
>> Und auf dem NFS-Server liegen vmdk-Dateien. Und was genau passiert,
>> wenn man zwei VMS startet, die beide dasselbe vmdk einhängen?
>
>vsphere laesst das nicht zu.

Dasselbe passiert bei iscsi.

[Diedrich Ehlerding]

Kay Martinen meinte:

>> Ja, du hast das geschrieben, aber darum gings gar nicht. Dein
>> Vorposter schrieb von einem anderen Szenario, nämlich von
>> mehrfach-Mount desselben zfs. Und deshalb geht dein Vergleich von zfs
>> und ntwfs hier in die Irre.
>
>
> Ich weiß nicht woher du das raus liest.

Aus Ulki Horlachers Beitrag, MID
<s8nkav$ai7$1...@news2.informatik.uni-stuttgart.de>, ich zitiere mal:

| > VMs von einem Host auf den anderen migrieren ohne die Daten
| > umzukopieren.
|

| Bei so einer Aktion hab ich durch eine mount race condition ein
| Multi-TB ZFS volume vernichtet.

Marc hatte auf Ulli Horlacher geantwortet, und ich auf Marc. Gemeint war
also mit "Vorposter" Ulli Horlacher.

> ACK. EINEN Storage müssen sie gemeinsam haben. Aber es spricht doch
> nichts dagegen wenn jeder Host auch noch eigenen Storage für sich hat.
> GGf. um einen grundbestand an festen VMs Initial vom gemeinsamen
> storage auf den lokalen zu legen und den gemeinsamen nur für volatiles
> zu nutzen.

Wenn die Virtualisierer eh ne eigene große Bootplatte haben,
meinetwegen, obwohl man damit eben die betreffenden VMs auf diesen
Server festnagelt. Aus Flexibilitätsgründen würde ich immer dafür
pläödiern, shared Storage für *alle* VMs zu benutzen.

Im VM-Ware-Umfeld werden Server für ESXi von manchen Herstellern
optional nur mit einer Flashkarte (mit vorinstalliertem ESXi), ohne
lokale Platten, ausgeliefert.

[Diedrich Ehlerding]

Marc Haber meinte:

> Framstag wollte wissen, warum man ein Blockdevice an mehrere Hosts
> exportieren möchte. Ich antwortete mit dem für mich natürlichen
> Usecase, der zugleich in meiner Welt den bei weitem überwiegenden
> Anteil der Verwendungen darstellt.

Ja, über den usecase "vmotion" sind wir uns ja völlig einig - dafür
bedarf es eines shared storage. Entweder eben über nfs (oder cephfs,
oder cifs im HyperV-Umfld), oder über irgendeinen Mechanismus, der einen
gleichzeiotigen Zugriff mehrerer Hosts (in diesem Fall mehrerer
Virtualisierungshost) auf dasselbe Blockdevice erlaubt. Oder ggf. auch
über iscsi, wenn man jede virtuelle Platte durch ein iscsi-Device
abbilden will (und der Virtualisierer das dann beherrscht).

>>Und das kann man in ESX eben auf Blockdevice-Ebene haben (durch ein
>>shared Filesystem).
>
> Wenn Du das als Filesystem sehen möchtest, gerne.

Was ist vmfs denn deiner Ansicht nach? Im vmfs liegfen typischerweise
nicht nur die virtuellen Platten, sondern auch die Metadaten der VMs
(früher hießen die mal "vmx-Dateien", wie sie heute heißen, weiß ich
nicht mehr), also die Beschreibung der virtuellen Hardware,
Speichergröße, CPU-Typ, MAC-Adressen usw. usf.

[Marc Haber]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>Marc Haber meinte:
>> Framstag wollte wissen, warum man ein Blockdevice an mehrere Hosts
>> exportieren möchte. Ich antwortete mit dem für mich natürlichen
>> Usecase, der zugleich in meiner Welt den bei weitem überwiegenden
>> Anteil der Verwendungen darstellt.
>
>Ja, über den usecase "vmotion" sind wir uns ja völlig einig - dafür
>bedarf es eines shared storage. Entweder eben über nfs (oder cephfs,
>oder cifs im HyperV-Umfld), oder über irgendeinen Mechanismus, der einen
>gleichzeiotigen Zugriff mehrerer Hosts (in diesem Fall mehrerer
>Virtualisierungshost) auf dasselbe Blockdevice erlaubt. Oder ggf. auch
>über iscsi, wenn man jede virtuelle Platte durch ein iscsi-Device
>abbilden will (und der Virtualisierer das dann beherrscht).

Ich kenne das eigentlich nur mit Fibre Channel und iSCSI. Benutzt habe
ich auch schon VMware-Cluster mit per NFS zugeführter Storage, selbst
gebaut habe ich es nur mit Fibre Channel und ein Testcluster mit
iSCSI, beides ist über zehn Jahre her.

>> Wenn Du das als Filesystem sehen möchtest, gerne.
>
>Was ist vmfs denn deiner Ansicht nach?

Das ist eine sehr gute Frage. Zu lange her. Rudimentär wie ein
Filesystem aussehen tut es.

Grüße
Marc

[Jan Novak]

Am 28.05.21 um 14:06 schrieb Kay Martinen:

> Was spricht dann eigentlich gegen einen schnell angebundenen nfs-server
> mit platz für all eure VMs? Das nicht ausgeschlossen werden kann das
> eine VM auch mal auf zwei hosts hoch läuft und es dann datei-konfetti
> regnet - wie ulli meinte? Ich dachte PVE würde das verhindern... was ich
> mangels cluster nicht prüfen kann.

Das kann ausgeschlossen werden.
Zu NFS habe ich kein großes Vertrauen mehr. Wenn es läuft, läuft es gut,
leider läuft es aber nicht immer - gerade im Zusammenhang mit zfs, was
ja quasi einen Container um den nfs-kernel-server bindet.

>>> b) es dauert einige Zeit, sich da reinzuarbeiten und die Konzepte zu
>>> verstehen. Mehr Zeit als man als Amateur üblicherweise hat.
>>
>> Ich bin doch ein Profi ;-)
>
> ? Aha! Also, ich nicht! :-)

:-) (ich doch auch nicht)

>> _Das_ ist doch fast überall so. Halbwissen ist mehr als gefährlich!
>
> Schönen dank das du mir Gefährlichkeit attestierst - weil ich von ceph
> u.a. so herzlich wenig ahnung hab. ;-)

Dann haben wir wohl beide den gleichen Stand - aber Gefährlichkeit habe
ich dir nicht attestiert... ;-)

Jan

[Jan Novak]

Am 27.05.21 um 23:22 schrieb Kay Martinen:

> So weit ich das verstand geht es ihm vor allem um die ausnivellierung
> der unterschiedlichen Speicherkapazitäten seiner VM-Server.

Korrekt.

> Er redet da zwar auch von replizierung (nicht Backup oder Snapshots) was
> ich nicht recht verstehe. Aber ich nehme an das es dabei um
> Sicherungskopien laufender VMs geht. Die kann man auch auf einen
> externen aber host-exklusiven Speicher auslagern.

Das replizieren entfällt mit einem zentralen Server komplett.
Sicherunge, Snapshost und alles andere würde über das Storage selbst
gemacht.

> Und m.W. ist einer der Vorzüge eines Cluster-Setups von Proxmox Nodes
> das man eine Live-migration machen kann. Dabei wird die VM auf den
> anderen Server kopiert und [vermutung] auf dem alten gestoppt während
> sie auf dem neuen an der gleichen stelle weiter macht.

korrekt, Wenn aber das storage für alle VM's gleich ist, ist eine Live
migration quasi nur noch ein und ausschalten der VM


Jan

[Kay Martinen]

Am 31.05.21 um 09:38 schrieb Jan Novak:

> Am 28.05.21 um 14:06 schrieb Kay Martinen:
>> Was spricht dann eigentlich gegen einen schnell angebundenen nfs-server
>> mit platz für all eure VMs? Das nicht ausgeschlossen werden kann das
>> eine VM auch mal auf zwei hosts hoch läuft und es dann datei-konfetti
>> regnet - wie ulli meinte? Ich dachte PVE würde das verhindern... was ich
>> mangels cluster nicht prüfen kann.
>
> Das kann ausgeschlossen werden.
> Zu NFS habe ich kein großes Vertrauen mehr. Wenn es läuft, läuft es gut,
> leider läuft es aber nicht immer - gerade im Zusammenhang mit zfs, was
> ja quasi einen Container um den nfs-kernel-server bindet.

??? Container "um" nfs-kernel-server??? Ich hab nirgends erwähnt das du
den nfs-server virtualisieren sollst! ZFS on NFS wirkt auch irgendwie
wiedersinnig.

Aber gut, wenn du ZFS willst und deswegen NFS ausschließt ist das dein
Use-case. Ich lagere dort keine VMs, nur ISO, Dumps und Snapshots und da
hab ich bisher keine Probleme bemerkt.

Außer gelegentlichen paketverlust-meldungen von netdata auf der bridge
wenn der PVE sein Backup macht...

>>>> b) es dauert einige Zeit, sich da reinzuarbeiten und die Konzepte zu
>>>> verstehen. Mehr Zeit als man als Amateur üblicherweise hat.
>>>
>>> Ich bin doch ein Profi ;-)
>>
>> ? Aha! Also, ich nicht! :-)
>
> :-) (ich doch auch nicht)

Huuuch!? :-)

>>> _Das_ ist doch fast überall so. Halbwissen ist mehr als gefährlich!
>>
>> Schönen dank das du mir Gefährlichkeit attestierst - weil ich von ceph
>> u.a. so herzlich wenig ahnung hab. ;-)
>
> Dann haben wir wohl beide den gleichen Stand - aber Gefährlichkeit habe
> ich dir nicht attestiert... ;-)

Implizit, my Dear. Implizit.

Halbwissen <> Profi + Halbwissen=Gefährlich
------------------------------------------- == Gefährlich!
Halbwissen (ist doppelt, streichen wir raus)

Ach ja. Willkommen im Club der "Gefährlichen". Du Storage-Desperado :-)

BTW. Was ist mit ZFS nur lokal und reinem NFS zum externen Server.
Hattest du damit schon Probleme?

[Jan Novak]

Am 31.05.21 um 14:54 schrieb Kay Martinen:

> ??? Container "um" nfs-kernel-server??? Ich hab nirgends erwähnt das du
> den nfs-server virtualisieren sollst! ZFS on NFS wirkt auch irgendwie
> wiedersinnig.
>
> Aber gut, wenn du ZFS willst und deswegen NFS ausschließt ist das dein
> Use-case. Ich lagere dort keine VMs, nur ISO, Dumps und Snapshots und da
> hab ich bisher keine Probleme bemerkt.

zfs bringt einen wrapper für den nfs Server mit. Das heisst, die
Verwaltung der NFS Freigaben übernimmt zfs. Die /etc/expots ist (immer)
leer. ZFS verwaltet alles - verlangt aber einen installieren
nfs-kernel-server.
Es ist schon mehrfach passiert, dass Freigaben auf einmal nur noch "ro"
sind. Nach einem "re-raed" der zfs / nfs Konfiguration gings dann
wieder. Das ist in der Produlktion ein "no go"

> Ach ja. Willkommen im Club der "Gefährlichen". Du Storage-Desperado :-)

;-)

> BTW. Was ist mit ZFS nur lokal und reinem NFS zum externen Server.
> Hattest du damit schon Probleme?

hmmm... nicht getestet, da die nfs Freigaben immer vom zfs Filesystem
stammten und wegen obigem Problem nicht weiter verfolgt.

NFS hat aber einen Mangel: die User / Gruppen sind u.U. nicht synchron.
Die Proxmox Server haben "keine" ldap/ad Anbindung. Somit aus
Verwaltungssicht nicht optimal.


Jan

[Kay Martinen]

Am 31.05.21 um 15:28 schrieb Jan Novak:

> Am 31.05.21 um 14:54 schrieb Kay Martinen:
>> ??? Container "um" nfs-kernel-server??? Ich hab nirgends erwähnt das du
>> den nfs-server virtualisieren sollst! ZFS on NFS wirkt auch irgendwie
>> wiedersinnig.
>>
>> Aber gut, wenn du ZFS willst und deswegen NFS ausschließt ist das dein
>> Use-case. Ich lagere dort keine VMs, nur ISO, Dumps und Snapshots und da
>> hab ich bisher keine Probleme bemerkt.
>
> zfs bringt einen wrapper für den nfs Server mit. Das heisst, die
> Verwaltung der NFS Freigaben übernimmt zfs. Die /etc/expots ist (immer)
> leer. ZFS verwaltet alles - verlangt aber einen installieren
> nfs-kernel-server.

Klingt übergriffig von zfs. Ich hab das bisher immer umgangen und
deshalb angenommen man könnte die Blockgeräte des Servers selbst mit zfs
"bespielen" und deren Aufteilung (Units, Chunk, partition, Volume oder
was sonst) dann simpel per nfs exportieren. Also nicht!

Jetzt ahne ich auch warum ZFS on Linux für manche ein Problem darstellt.
Ähm, der userspace nfs-server ist dann wohl auch kein Work-around.
[Nachschau] 2 GB Limit und keine dateisperren klingt nicht so prall. Vom
erwartbaren Durchsatz (user vs. kernel-space) mal ganz abgesehen.

> Es ist schon mehrfach passiert, dass Freigaben auf einmal nur noch "ro"
> sind. Nach einem "re-raed" der zfs / nfs Konfiguration gings dann
> wieder. Das ist in der Produlktion ein "no go"

Wenn da die vm-images drauf laufen, absolut ja!

>> BTW. Was ist mit ZFS nur lokal und reinem NFS zum externen Server.
>> Hattest du damit schon Probleme?
>
> hmmm... nicht getestet, da die nfs Freigaben immer vom zfs Filesystem
> stammten und wegen obigem Problem nicht weiter verfolgt.

Tja. Wie ich nebenan las willst du die images auf zentraler Freigabe.
Dann ist das obige auch keine lösung.

> NFS hat aber einen Mangel: die User / Gruppen sind u.U. nicht synchron.

Hmm. Hier auch nicht. Bei mir zählt das aber wohl nicht weil keine
images sondern nur backups (RW Weekly) und ISOs (RO) auf nfs liegen.

> Die Proxmox Server haben "keine" ldap/ad Anbindung. Somit aus
> Verwaltungssicht nicht optimal.

UID/GID oder all_squash reicht nicht - wenn es ein reines
Speichernetzwerk ist das nur an die PVE Nodes geht?

[Kay Martinen]

Am 31.05.21 um 22:10 schrieb Marcus Jodorf:
> Jan Novak <rep...@gmail.com> schrieb:

>
>> Am 27.05.21 um 23:22 schrieb Kay Martinen:
>>> So weit ich das verstand geht es ihm vor allem um die ausnivellierung
>>> der unterschiedlichen Speicherkapazitäten seiner VM-Server.
>>
>> Korrekt.
>

> Was Du dabei vielleicht noch als Nachteil im Hinterkopf haben solltest:
> Du baust Dir damit natürlich nebenbei auch einen single point of
> failure.
> Falls der Storageserver abraucht (und vielleicht auch noch gleich die
> Platten mit abfackelt), dann stehen alle Server erst mal komplett.
> Daß mußt man dann entsprechend mit einplanen.

Er hatte weiter oben eingeworfen das er mit den Vorhandenen Platten auch
2 Server bestücken könnte - und ggf. auch will. An einem 2. Ort in
anderem Brandabschnitt. Allerdings müssen die dann ja wieder miteinander
Synchronisiert sein und bleiben. Sonst ist da doch nix mit HA oder?

Wie macht man das bei storage-servern? Replizierung, wie?

Das jeder die gleiche Plattenkapazität haben muß ist klar. Und das da
entweder ZFS oder ein RAID pro Gerät ist auch. Aber womit hält man den
Reserve Server auf dem Stand des Haupt-gerätes? Und geht das überhaupt
mit ZFS on iscsi (wie er plant)?

[Jan Novak]

Am 31.05.21 um 23:44 schrieb Kay Martinen:

> Das jeder die gleiche Plattenkapazität haben muß ist klar.

Nicht unbedingt.

> Und das da
> entweder ZFS oder ein RAID pro Gerät ist auch. Aber womit hält man den
> Reserve Server auf dem Stand des Haupt-gerätes? Und geht das überhaupt
> mit ZFS on iscsi (wie er plant)?

Mit den Snapshots, welche minütlich, theoretisch auch in noch kürzeren
Intervallen gemacht werden können, geht das sehr gut.
Natürlich muss die Bandbreite für das Übertragen ausreichend sein, sonst
läuft das Backup dem Live Storage hinterher, aber abgesehen davon
funktioniert diese Art des Backups für uns seit Jahren perfekt.

Auch muss das Backup nur "genügend" Platz haben. In unserem Szenario
spielt es keine Rolle wie groß das Live Storage ist.

Es gibt ganz wenige VM's, wo Snapshot in weniger als 60min gemacht
werden (zur Kernarbeitszeit). Die meisten müssen nur täglich gesynct
werden. Somit haben wir im "worst case" einen Gap von max. ~70min je
nach VM was für uns völlig ausreichend ist.


Jan

[Jan Novak]

Am 31.05.21 um 16:03 schrieb Kay Martinen:

>> Die Proxmox Server haben "keine" ldap/ad Anbindung. Somit aus
>> Verwaltungssicht nicht optimal.
>
> UID/GID oder all_squash reicht nicht - wenn es ein reines
> Speichernetzwerk ist das nur an die PVE Nodes geht?

Hmmmm... doch, das würde es wohl.
Darüber muss ich mir nochmal Gedanken machen. Wir haben einen (Test-)
ldap Server (einen Container), aber den nutzt quasi keiner (ausser mir
;-) )... Proxmox selbst hat eine gute ldap integration.
Mal schauen, wo die Reise generell hin geht. Die User/Group rights sind
dann eher noch das kleinere Problem.

Jan

[Sven Hartge]

Jan Novak <rep...@gmail.com> wrote:
> Am 31.05.21 um 14:54 schrieb Kay Martinen:

>> ??? Container "um" nfs-kernel-server??? Ich hab nirgends erwähnt das
>> du den nfs-server virtualisieren sollst! ZFS on NFS wirkt auch
>> irgendwie wiedersinnig.
>>
>> Aber gut, wenn du ZFS willst und deswegen NFS ausschließt ist das
>> dein Use-case. Ich lagere dort keine VMs, nur ISO, Dumps und
>> Snapshots und da hab ich bisher keine Probleme bemerkt.

> zfs bringt einen wrapper für den nfs Server mit. Das heisst, die
> Verwaltung der NFS Freigaben übernimmt zfs. Die /etc/expots ist
> (immer) leer. ZFS verwaltet alles - verlangt aber einen installieren
> nfs-kernel-server.

Wer macht denn das?

Jeden, den ich kenne oder von dem ich gelesen habe, das er NFS mit ZFS
nutzt ignoriert den eingebauten Murks, der noch von Solaris übrig ist
und macht NFS klassisch via /etc/exports.

S°

--
Sigmentation fault. Core dumped.

[Jan Novak]

Am 01.06.21 um 12:34 schrieb Sven Hartge:

>> zfs bringt einen wrapper für den nfs Server mit. Das heisst, die
>> Verwaltung der NFS Freigaben übernimmt zfs. Die /etc/expots ist
>> (immer) leer. ZFS verwaltet alles - verlangt aber einen installieren
>> nfs-kernel-server.
>
> Wer macht denn das?
>
> Jeden, den ich kenne oder von dem ich gelesen habe, das er NFS mit ZFS
> nutzt ignoriert den eingebauten Murks, der noch von Solaris übrig ist
> und macht NFS klassisch via /etc/exports.

Kann ich verstehen und .... wir niutzen ihn auch nicht mehr.
Anfangs war ich der Meinung, dass es eventuell Vorteile birgt, das
vorhandene ZFS die ganze Hirarchie verwalten zu lassen. Dem ist aber aus
meiner Erfahrung tatsächlich nicht so.

Jan

[Tim Ritberg]

Am 01.06.21 um 12:34 schrieb Sven Hartge:

>

> Wer macht denn das?
>
> Jeden, den ich kenne oder von dem ich gelesen habe, das er NFS mit ZFS
> nutzt ignoriert den eingebauten Murks, der noch von Solaris übrig ist
> und macht NFS klassisch via /etc/exports.
>

ACK. <- NFS4 pur mit ext4.

Tim

[Sven Hartge]

Ich weiß nur, das die ZFS-Integration bei größeren Setups mit vielen
Datasets und Freigaben recht schnell extrem lahm wird, wenn man die
Exports verändern will und dann gerne einmal den kompletten Datenverkehr
lockt, während der Prozress im Hintergrund ackert.

Wenn man das klassisch macht, hat man das Problem nicht.

[Hermann Riemann]

Am 01.06.21 um 13:21 schrieb Jan Novak:

> Kann ich verstehen und .... wir nutzen ihn auch nicht mehr.

> Anfangs war ich der Meinung, dass es eventuell Vorteile birgt, das
> vorhandene ZFS die ganze Hirarchie verwalten zu lassen. Dem ist aber aus
> meiner Erfahrung tatsächlich nicht so.

Ich erinnere mich daran, dass ich mal ein anderes Dateisystem als
ext* ( + spezial DOS für boot) verwendet habe.
Vielleicht war es ZFS.

Ergebnis war, das einige Verzeichnisse (Ordner) nicht auf der hardware
( Festplatte bzw. SSD ) automatisch angelegt wurde,
auf der ich das jeweilige haben wollte

Hermann
der ZFS & Co vermeidet.


--
http://www.hermann-riemann.de