ESXI 6.5 u1, XPenology, lancache-machine on HP Microserver Gen8 - Probleme

[Fischje]

Ich habe am Wochenende mal länger damit zugebracht meinen MicroServer (1265L und 8 gb Ram) samt ESXI 6.5 hp u1 Image zu bestücken und dann folgende Schritte druchgeführt:

1. m1015 auf it mode dran
2. an den sata5 eine ssd als datenspeicher für den esxi
3. xpenology als vm auf die ssd installiert und den m1015 durchgereicht
4. in xpenology (dsm) ein raid 5 mit btrfs mit 4 platten erstellt
5. eine nfs freigabe erstellt
6. die nfs-freigabe dann auf dem esxi host eingebunden als 2. datenspeicher.
7. Dann habe ich eine Debian VM mit 6 TB Platte auf dem 2. (NFS-)Datenspeicher erstellt.
8. Auf der habe ich nen lanache Server eingerichtet. das ist im grunde genommen eine vm die als dns Server fungiert und bestimme abfragen umleitet an sich selbst und mit nginx dann aus nem Cache bedient. so kann man einmal geladene Daten z.b. bei großen updates von spielen oder deren Installationen im lan schneller verteilen. das war zumindest der plan

Nachdem alles fertig war und ich meine DNS Setup zu Hause darauf zeigen lassen habe funktionierte es erstmal problemlos. Nach 1-2 Stunden bzw. ich glaube ich hab auch nochmal rebootet habe ich jetzt aber ganz große Performance Probleme. Teilweise habe ich beim dns-auflösen aus der vm heraus sogar timeouts. die vm bricht auch total zusammen und wird langsam. Wie und an welchen stellen ich messen soll weiss ich ehrlich gesagt nicht. Jedenfalls konnte ich unter meiner StorageVM (Xpenology) sehen das die Auslastung auf dem dort angezeigten Raid permanent auf 100% war.

Meine Frage:
Soll ich eine andere Storage VM hochziehen um die Performance zu verbessern? Geht da noch was? Ich habe xpenology eigentlich nur genommen wegen der einfachen Bedienbarkeit und dieser CloudStation Sache, die ich noch nirgendwo so einfach bei anderen gesehen hab. Evtl. könnte ich das auch separat lösen oder nur ne mini vm auf der ssd dafür erzeugen, aber erstmal frage ich mich ob es nicht mit xpenology geht.

oder liegt es evtl. noch an einer falschkonfiguration? ich kenne mich eherlich gesagt überhaupt nicht mit diesen ganzen write Cache Geschichten aus. Gibt's da was, das ich auf der storage vm prüfen sollte? oder auf der Debian vm?

Habe folgende Ideen dazu, die ich gerne teilen möchte. Vielleicht kann mir jemand schon was beantworten?

• Ist btrfs das Problem bei dieser Konfiguration? die vm hat 4 GB ram - vielleicht zu wenig für btrfs?
• wie reiche ich die nfs freigabe möglichst störungsfrei an allen physichen Adaptern vorbei an den esxi durch?
• die Debian vm selber liegt ja auch auf dem datenspeicher - ist das vielleicht ungünstig? muss ich da was an den writecache config ändern? (wobei ich das total abwägig finde, da dort im grunde genommen nur unbound und der nginx laufen)
• ich lese immer wieder von gea's napp-it. da hätte ich dann etwas Einschränkungen was meine cloudstation angeht, aber würde der tausch mehr Leistung bringen bei dem Setup?
• hab mal was gelesen, dass das ESXI 6.5 hp u1 Image Performance Probleme haben sollte. weiss aber nicht ob es da um den internen b120i ging oder was. ich finde den Artikel leider auch nicht mehr. hier jemand eine Idee was ich gemeint haben könnte?

Ist das RAID denn healthy? Wenn bei dem Reboot die VM nicht heruntergefahren war und aktuell ein Rebuild läuft, wäre das vielleicht eine Erklärung.

also es findet kein rebuild statt.

 

[Fischje]

liege jetzt bei 14-17 MB/s das ist aber immer noch zu langsam fürn raid 5 oder ?

 

[MicroCane]

Setz doch mal eine Windows VM auf und teste mit Crystalbenchmark die Raid-Performance.
IOPs und Seq-Datenrate wären interessant.

Ich hab einen Dell T20 mit Xpenology Storage-VM mit 2x 850 Evo 500GB Raid1 und 2x 3TB WD Red Raid1.
Das meiste liegt auf den SSDs, ein paar wenige Sachen auf den HDDs.
Die HDD Performance ist (natürlich) bedeutend schlechter, aber immer noch voll ausreichend.

Die VM läuft bei mit schon mit 2GB RAM sehr sauber, alles darüber wird natürlich als Cache genutzt, daher hat sie aktuell 6GB.

 

[Fischje]

ein raid aus ssd fällt bei mir auf grund finanzieller defizite leider aus, da kommen nämlich insgesamt schnell 5 TB daten zusammen.

habe jetzt die vm auf ner ssd laufen und nur das dateienverzeichnis dieser anwendung auf die storage vm gemountet. damit hab ich jetzt ungefähr 30 MB/s.

 

[MicroCane]

Synology bietet auch SSD-Cache.
Da würden sich schon 2 x 128gb anbieten. (Es werden 2 SSDs für Read- und Write-Cache benötigt. Mit einer SSD klappt nur Read-Cache)

 

[Fischje]

ja hatte ich auch im System hängen. die bremsten wohl das ganze mehr aus als das sie es beschleunigten.

hab mal mit bonnie++ gemessen:

bonnie++ -d /verzeichnisdesnfsshare -s 2048 -r 1024 -u 0

ohne
Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
lancache         2G  1281  99 348948  28 141729  13  1601  91 367303  17  1528   8
Latency             11255us   26273us     895ms     136ms     306ms   62028us
Version  1.97       ------Sequential Create------ --------Random Create--------
lancache            -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  5247  21 +++++ +++ 10123  18  5003  16 +++++ +++ 10314  17
Latency             15987us   10753us   38507us   18013us    6525us   33315us


mit
Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
lancache         2G  1266  99 298782  20 135952  12  1635  99 365870  16  1606   7
Latency              8023us     143ms     608ms    7922us     313ms     194ms
Version  1.97       ------Sequential Create------ --------Random Create--------
lancache            -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  4717  18 +++++ +++  9429  18  4434  15 +++++ +++  9818  17
Latency             95571us   58609us   78963us   18021us     277us   22115us

 

[Fischje]

Ich muss hier doch nochmal fragen, weil ich einfach zu doof bin, was vernünftiges aus meiner kiste zu erstellen.

Der Microserver Gen 8 steht zur Verfügung. Ein Xeon 1265L auch. Habe mittlerweile auf 16 GB Ram aufgerüstet.
Was soll da drauf laufen: Ein Debian als mein "lancache" und am liebsten ein DSM aka "xpenology".

es gibt im grunde genommen mehrere Optionen - mein Problem war und ist immer noch die lese und schreibperformance der verschiedenen konstelattionen. möchte natürlich die beste Performance haben.

1. Debian Baremetall.
a) b120i als "fake hw"-raidcontroller mit den platten als raid10, am 5 port dann eine ssd als raid0 selbst, wo's os drauf ist.
b) alle platten am meinem m1015 im it mode und versuchen das ganze System unter zfs laufen zu lassen. hab ich noch nie versucht, und keine Ahnung wie ich das am besten gestalte. habe hier 3 platten a 6 TB und eine 5 TB platte + 4 120gb ssds. brauche dann auf jeden fall unter dem Debian eine vm (was nutzt man da, kvm?, docker?, lxc?, ...?) für mein xpenology mit ca 3 TB platz. Das wäre meines erachtens noch die sicherste und sauberste lösung - WENN es denn performant den rest erledigen würde. vielleicht könnte mir jemand das Szenario mal erläutern...

2. esxi als baremetall.
a) xpenology drauf und raid5 auf der vm aus den durchgereichten platten an dem m1015 erstellt. nfs freigabe an
aa)esxi als datastore. darauf dann die debian-vm erstellt. Performance reicht definitiv nicht.
ab)debian-vm auf ne ssd als datastore installiert und dort die nfs-freigabe erhalten. Performance etwas besser, aber auch nie über 20 MB/s. Absolut ungenügend.
b) b120i raid10 erstellt und esxi das als datastore zur verfügung gestellt. beide vm's drauf. laufen beide, aber definitv zu langsam. Habe bei Übertragungen über das netz dann nur um die 40MB's gehabt.

3. xpenology baremetall installiert
wollte mit dem dort integrierten virtual machine Manager (vmm) dann eine Debian vm aufsetzen. die startet nicht mal vernünftig. gibt aber diverse berichte, dass es noch zu unstable wäre, das zu nutzen. kann ich jetzt also auch beerdigen.

 

[konfetti]

Hast Du schon mal ein anderes Storagesystem, z.B. NAS4Free in betracht gezogen?
ich vermute, der B120i ist ohne BBU ggf. ein Problem - aber der M1015 könnte ja im IT-Mode die Disks direkt an das OS weitergeben - für NAS4Free reicht dann auch ein 4/8GB Stick fürs OS.
Mit den Disks die durchgereicht werden einen ZFS-Pool einrichten und die Performance nochmal testen - skaliert aber mit dem RAM.

ich hab in meinem "neuen" Filer jetzt 96GB ECC RAM, dafür keine SSDs - aktuell noch 8x 320GB 5400er Disks - werden demnächst entweder 8x 2TB oder 4x 4TB - alles 2.5"...
aktuell Schaffe ich damit ~ 108MB/s vom Filer auf meinen PC (256GB Intenso SSD) beim kopieren von 6GB DVD-Images (Ubuntu/Windows...)

 

[Ceiber3]

Meine Erfahrung mit Xpenology als VM ist das die schreib und lese raten unterirdisch schlecht sind. Jedenfalls waren die das bei mir.
Wenn man es von USB Stick bootet ist alles i.o.

 

[Largrande]

Ich mein mich daran zu erinnern daß es bei Esxi Problem mit dem Treiber für den Controller gab und man explizit einen alten Treiber einspielen musste damit die Schreibraten vernünftig sind. Das sollte Ihrgendwo im G8 Microserver Thred stehen.

 

[ClearEyetemAA55]

Wenn Xpenology baremetall, dann VMs lieber mit Virtualbox

Virtualbox on DSM 6.1 - Page 2 - Synology Forum

 

[Fischje]

Hast Du schon mal ein anderes Storagesystem, z.B. NAS4Free in betracht gezogen?
...
aktuell Schaffe ich damit ~ 108MB/s vom Filer auf meinen PC (256GB Intenso SSD) beim kopieren von 6GB DVD-Images (Ubuntu/Windows...)

ja das Problem hatte ich mit meinen filern, egal ob nas4free, xpenology, oder unraid oder wie sie auch alle heissen nie. Nur halt wenn es eine stroage vm ist, die noch noch für andere vms da sein soll. dann wird's kritisch.

Ich mein mich daran zu erinnern daß es bei Esxi Problem mit dem Treiber für den Controller gab und man explizit einen alten Treiber einspielen musste damit die Schreibraten vernünftig sind. Das sollte Ihrgendwo im G8 Microserver Thred stehen.

ja das hab ich auch schon hinter mir. bis ESXI-Custom Image 6.5 u1 besteht das Problem. danach ist sogar der treiber mit der versionsnr 102 besser unter u1 gelaufen.

Wenn Xpenology baremetall, dann VMs lieber mit Virtualbox

Virtualbox on DSM 6.1 - Page 2 - Synology Forum

hab ich noch nicht probiert. was sagt denn die Performance übers Netzwerk auf so ne vm?

 

[gea]

Viele Wege führen nach Rom, wenn man allerdings virtualisieren möchte ist zu beachten

- ESXi möchte immer syncron und ohne Cache schreiben. Grund ist dass ESXi keine Kontrolle über die VM Dateisysteme hat. Bei denen gibt es ständig abhängige Schreibaktionen wie 1. Daten aktualisierem und 2. Metadaten aktualisieren. Stürzt da ein System ab, ist das Dateisystem korrupt. Syncrones Schreiben ohne Cache ist zwar sicher aber sehr langsam. Verbessern kann man das durch einen lokalen ESXi Raidcontroller mit Cache + BBU/Flashsicherung. Bei einem lokalen Datastore bleibt aber der Datenpfad viruuelle Platte > virtueller Treiber > ESXi Dateisystem > ESXi Treiber > Platte. Auch nicht gerade die schnellste Variante

Fazit: ESXi virtuelle Platten sind sicher aber langsam. Ausreichend für einen Applikationsserver, ungenügend für einen Filer.


Der Ausweg besteht darin einen Filer zu virtualisieren nicht jedoch das Storage. Man reicht dabei den Controller samt Platten an eine Storage VM damit die mit eigenen Treibern direkt auf das Storage kann. Die Performance ist dabei kaum schlechter als bei einem Barebonesystem mit gleichviel RAM. Wenn der Filer CopyOnWrite kann (btrfs, ReFS, ZFS) gibt es auch kein korruptes Dateisystem beim Crash. Wenn man also nur einen Filer will, verhält sich das von der Sicherheit bei jedem Storage OS exakt wie ein Bareboneserver.

Wenn man ESXi einsetzt, möchte man aber gerne den Storage für VMs nutzen. Selbst wenn das Storage z.B. ZFS ist, hat man wieder das Problem dass man diesen als NFS oder iSCSI bereitstellt und ESXi wieder syncron schreiben möchte/muss. Die Performance ist dabei auch wieder sehr schlecht. Ausweg ist entweder sync abzuschalten (unsicher), ein Hardwareraid mit Cache/BBU zu nehmen (hat dann aber wieder das Write Hole Problem=Gefahr eines korrupten Raid beim Crash) oder im Falle von ZFS zwar mit einem großen schnellen Ram Schreibcache zu arbeiten diesen aber über eine schnelle Slog Platte abzusichern (z.B. Intel Optane). Damit bekommt man dann schnelles und sicheres Schreiben. Dies gibt es aber nur bei ZFS, nicht z.B. bei btrfs (Xpenology).

Fazit
Ein schneller virtualisierter Filer mit Windows (ntfs/Refs) oder Xpenology (btrfs) ist möglich aber langsam wenn man sicheres Schreiben braucht/möchte. Der Grund warum ich hier immer ZFS bevorzuge. Damit erhalten auch VMs mit alten Dateisystemen die darunterliegenden ZFS Sicherheitsoptionen. Inwieweit z.B. Xpenology als Anwendunsserver entweder mit ZFS Storage als Backend z.B. als vdisk oder via NFS/ iSCSI zusammenarbeitet kann ich nicht sagen

 

[Opticum]

man könnte bei Xpenology ja auch den Controller durchreichen, ob es dann ZFS oder BTRFS ist, ist ja relativ. Beides kann CopyOnWrite, Snapshots usw.

 

[besterino]

Das Thema von Gea bzw. ESXi ist hier aber „sichere hohe Performance“ und damit dIe Frage, wie man Sync umgehen kann. Das wird allein mit ZFS und BTRS eben nicht gehen, sondern du brauchst einfach hardwareseitig einen rasant flotten non-RAM (nicht volatilen) Schreib-Cache wie eben eine Optane und ein Setup, was den eben auch genau dafür nutzen kann. Ich schätz jetzt mal, das kann XPE-/Synology so nicht?

 

[fdiskc2000]

... hardwareseitig einen rasant flotten non-RAM (nicht volatilen) Schreib-Cache wie eben eine Optane und ein Setup, was den eben auch genau dafür nutzen kann. Ich schätz jetzt mal, das kann XPE-/Synology so nicht?

Doch geht (zumindest bei den originalen). Muss halt was mit Powerloss sein und dann als Lese-Cache und Schreib-Cache der Diskgruppe zuweisen. Der Cache kann auch im Raid1 laufen. Ob nun eine Optane unterstützt wird bezweifle ich, aber was ala SM863 geht. Ist halt immer eine Frage der freien Bays und des Geldes.

Wie gut das dann aber bei der inoffiziellen Version läuft und was an Hardware unterstützt wird ist dann immer die Frage. Da fängt für mich dann eher die Spielerei an.

 

[gea]

Bei Synology habe ich immer den Eindruck "Geht alles, kann alles und überhaupt hat es die meisten Funktionen überhaupt."

Wenn es aber um harte Sicherheitsfeatures und deren Umsetzung geht wird es meist sehr schwammig. Meist habe ich den Eindruck das das im Pflichtenheft weiter hinten stand, egal ob es um sicheren ECC Ram geht oder um die Frage wie gut es funktionieren kann, Linux Raid auf btrfs Devices zu machen. Btrfs erkennt dann den Fehler, kann ihn aber nicht reparieren weil keinen Zugriff auf das Raid hat. Linux Raid weiss wiederum nichts von Prüfsummen. Synology scheint beides zu koordinieren. Dazu wie gut/sicher das funktioniert habe ich wenig gelesen. Auch nicht zur Frage wie eine Synology die Raid-Consistenz beim Stromausfall garantieren will (Raid Write Hole Problem, "Write hole" phenomenon in RAID5, RAID6, RAID1, and other arrays.)

Mt dem Schreibcache ist es ähnlich. Schreibvorgänge sollen da zuerst auf die SSD gehen und dann wenn es etwas ruhiger wird oder die SSD voller wird auf auf die Platten. Immer wird dabei ausschliesslich ein Performancegewinn betont. Kennt jemand Aussagen wie sich das bei Stromausfall beim Schreiben (Client->SSD oder SSD->Platte) verhält, insbesondere da ja noch Platten und OS caches beteiligt sind. Sind da immer alle commited writes tatsächlich sicher? Da brauchts sehr viel Urvertrauen wenn man das auf ein Level mit einem Hardwareraidcontroller+Cache/BBU oder gar ZFS+Slog stellen möchte.

Für einen Mediafiler sicher kein Problem, für kritische Datenbanken oder VM Storage aber schon. Da scheint mir eine Synology am wenigsten bis garnicht geeignet.

 

[Fischje]

tja, aufgrund meiner mangelnden kenntnisse mit solaris bin ich jetzt doch erstmal bei nem HW-Raid gelandet, unter esxi. ich hab es sowohl als vm und baremetall nicht geschafft aus den zfs raids (hatte 2 platten im stripe und 2 im mirror) vernünftige lesegeschwindigkeiten zu erreichen. mit dem hw raid 10 bin ich besser unterwegs.
einzige was mich daran stört ist das ich die platten nicht schlafen legen kann. dabei gehts zum einen um energieverbrauch, aber zum anderen hab ich schiss da sie wirklich 24/7 rennen.

 

[gea]

ESXi local Datastore und Sleep schließen sich eigentlich aus. ESXi ist dafür nicht gemacht

Das ginge nur wenn man z.B. einen 24/7 Datastore für VMs hätte und die Platten für einen Filer per pass-through exklusiv an eine Storage VM gibt und die die Platten schlafen schickt.

ps
wie war denn die Leseperformance?

ESXi ist zwar kein High-Performance sondern ein High Security Filesystem das durch die Extra Prüfsummen viel mehr Daten schreiben/ Lesen muss und wegen CopyOnWrite zwar Crashsicher ist aber dafür erheblich mehr Fragmentation hat. Auch verteilt ZFS die Daten über ein Raid so dass die effektive Performance nie die sequentielle Performance einer Platte erreicht sondern immer die iops eine Rolle spielen.

erwartete Performance z.B. mit "Green Platten" (5900 rpm) im Raid-0

Platten
iops: ca 50 je Platte: zusammen 100 iops (da ZFS die Platten direkt anspricht)
zum Vergleich, eine SSD hat 5k-100k und eine Intel Optane 500k iops

seq: ca 150 MB/s per Platte: zusammen also 300 MB/s

mit wenig RAM (1-3 GB):
Hier wirken eher die wenigen iops: die Leseperformance kann teils dramatisch einbrechen da für jeden io selbst die Metadaten gelesen werden müssen. Ich hatte mit einer einzelnen WD green schonmal einen Einbruch auf 3 MB/s.

Erwartet: 50-100 MB/s

mit mehr RAM (6-8GB)
Hier werden zumindest die Metadaten gecacht die man ja auch beim Schreiben braucht.

Erwartet: ca 200 MB/s je nach workload.
Teileweise werden ja 80-90% aller Lesevorgänge aus dem RAM bedient.

Der Performance Schlüssel für ZFS bei langsamen Platten ist damit RAM.
Hätte man Intel Optane, wäre das weniger kritisch.

Schreiben:
ZFS Sync ausschalten (Das sichert den Ram-Schreibcache ähnlich Cache+BBU beim Hardwareraid)

Das hat übrigens nichts mit Solaris zu tun. Das betrifft alle ZFS Plattformen (und teile auch btrfs/ReFS da die ähnlich arbeiteten. Die begrenzen die Sicherheitsfeatures aber aus Performancegründen teils auf Metadaten und lassen die eigentlichen Daten ungeschützt). Solaris hat allenfalls den Vorteil dass es mit wenig RAM besser zurechtkommt da die ZFS interne Speicherverwaltung immer noch auf Solaris baut.

 

[kopfpilot]

@Fischje: Ich verwende ein Setup wie Du und nutze Deine Punkt 1-4 auch genauso (und das gleich auf 2 Systemen).
Ich hab je 4x WD RED dran, was nicht umbedingt die schnellsten Platten sind.

Nur verwende ich XPE nicht als NFS-Datastore, sondern nehme eine SSD als vmdk-Datastore.

Was mich wundert ist deine Übertragungsrate. Hmm, vielleicht aber auch nicht... Ich habe auf beiden Systemen dauerhafte Schreib-/Leseraten von ~100MB/s, wenn ich Daten über CIFS draufkopiere (vom Laptop über LAN oder von einem NAS auf das andere). Wenn ich mehrere parallele Lesende-Zugriffe habe und einen schreibenden, dann geht der auch schon mal auf Werte zwischen 60-80MB/s. Wohlgemerkt: einen Schreibzugriff.

Allerdings verwende ich nicht das HP Image, sondern das Vanila Image. Das HP Image habe ich unter 5.5 und 6.0 probiert: es war unbenutzbar. Mag sein, dass es mitlerweile gefixed ist, aber ich wüsste nicht was mir fehlt. Deshalb bleib ich beim Vanila-Image.

 

[Fischje]

@kopfpilot. also das problemwar ja das die debian vm, die auch auf meiner ssd lag bis zu 4 tb an daten beherbergen muss. die wolte ich natürlich auf den hdd pool betreiben. und genau da ist mein engpass.

 

[ClearEyetemAA55]

hab ich noch nicht probiert. was sagt denn die Performance übers Netzwerk auf so ne vm?

Da kann ich Garnichts in Zahlen fundiertes zu beisteuern. Und habe aktuell auch kein Xpenology Baremetall laufen, um zu belegen. Mein Rat zu VB statt VMM entsprach eher dem Eindruck von VMM, W10 und VB, W10. Aber letztlich ist VMM auf der DS eben noch recht neu, wohingegen VB wirklich viel Entwicklung erfahren hat.