[Sammelthread] ZFS Stammtisch

Hallo alle,

in welcher Reihenfolge löscht man eigentlich am besten die Snapshots, wenn man alle löschen
und die Platten nicht allzulange rödeln lassen will? Zuerst die ältesten oder soll man mit dem
neuesten anfangen oder ist es egal?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich habe mich mal an das ESXi 6 ran getraut - Update von 5.5.

Passthrough von LSI Controllern + USB Geräten wie Dongles und Festplatten funktioniert problemlos, ansonsten ist das System bis jetzt unauffällig und flott wie vorher.

Vsphere Client reagiert schneller als zuvor unter 5.5. Zu USB3 kann ich mangels Hardware nichts sagen...
Ansonsten wird bei meinem Mainboard jetzt auch der zweite NIC out of the box erkannt.

OmniOS läuft soweit auch stabil, habe aber noch alte VMWare Tools / OS Installation und virtuelle Intel NICs laufen, da VMXNET3 bei mir noch nie richtig ging. NFS bei mir stabil mit e1000. Werde auch den Fileserver neu aufsetzen, sobald die neue OmniOS Version raus ist.

- - - Updated - - -

@gea:

Mar 27
Include an ESXi hot-memory snap in every ZFS snap working with ESXi6

Was ist denn da neu/anders als vorher bzw. als es bei 5.5 war?
 
Zuletzt bearbeitet:
@gea:

Mar 27
Include an ESXi hot-memory snap in every ZFS snap working with ESXi6

Was ist denn da neu/anders als vorher bzw. als es bei 5.5 war?

Ein Kunde hatte nach der Umstellung auf ESXi 6 Probleme beim Einlesen der VM-Liste mit langen Annotations die Zeilenumbrüche enthielten. Ich habe jedoch nicht überprüft inwieweit das Problem bei 5.5 auch schon bestand.
 
Hallo alle,

in welcher Reihenfolge löscht man eigentlich am besten die Snapshots, wenn man alle löschen
und die Platten nicht allzulange rödeln lassen will? Zuerst die ältesten oder soll man mit dem
neuesten anfangen oder ist es egal?

Egal, die Daten sind ohne Zeitbezug über die Platten verteilt.
 
Moin,

Omnios r151014 ist draußen und gleichzeitig ist r151010 auf EOL gesetzt.

U.a. hat es auch open-vm-tools 9.4.0 in r151014 geschafft, leider nicht die Aktuelle 9.10.0. Wie es jetzt mit ESXi6.0 aussieht - keine Ahnung; eigentlich empfiehlt VMWare nicht mehr die VMWare-Tools zu benutzen, sondern die open-vm-tools.
Wie bekommt man die 9.10.0 in OmniOS??

Dan McDonald empfiehlt u.a. "FOLLOW THE UPGRADE INSTRUCTIONS CAREFULLY" hier in seiner eMail.
 
Zuletzt bearbeitet:
Achtung, wer einen all-in-one auf Basis ESXi betreibt, sollte beachten, dass momentan bei der neuen ESXi-Version 6.0 noch keine Backups mit der 'Veeam 8.0' und auch nicht mit 'Veeam Backup and FastSCP 3.03' gehen.

Quelle: ESXi Hilfethread und hier.
 
@layerbreak: Danke für den Hinweis, ich habe gleich zum testen mal ein Update gemacht, läuft bisher alles problemlos. Leider gibst in OmniOS noch keinen NFS v4.1 Support, daher wird weiterhin der Datastore mit NFS v3 angebunden.

Zum Thema open-vm-tools, geht das theoretisch so:

wget http://pfad-zu-den-tools
tar -xzvf open-vm-tools-9.10.0-2476743.tar.gz
cd open-vm-tools-9.10.0-2476743
./configure
make
make install

Ich glaube aber nicht, dass alles was benötigt wird zum selber bauen in OmniOS schon an Board ist. Müsste man mal bei Gelegenheit durchchecken...
 
@automatenraum

Ich hab jetzt mal bei Veeam die Webseite mir näher angeschaut. Dort gibt es kein Free-Tool, welches mit ESXi free funktioniert - nur das alte Backup and FastSCP 3.03 aus 2010. Alle Anderen setzen mindestens Essential voraus.

Bist du dir mit OmniOS NFS v3 sicher, hat OmniOS nicht schon 4.0 onboard? NFS v4.1 das sicherlich nicht, eventl. wirds im Herbst 2015 damit was.
siehe hier

Ich glaube, dass die v9.10.0 zwingend benötigt werden, da VMWare offensichtlich an der 6.0 so einiges verändert hat.
Zum Thema kompilieren, kenn ich mich definitiv überhaupt nicht aus.
Haste nicht Lust, das Versuchskaninchen zu spielen und es auf deinem Testgerät zu versuchen? :bigok:
 
Zuletzt bearbeitet:
Es kann schon sein, dass OmniOS jetzt v4 hat, nutzt aber nichts, da ESXi 6 zwingend 4.1 voraussetzt, sonst wird mit v3 connected. Würde bei manchen Setups sicherlich mehr Performance bringen, aber warten wir dann mal das Ende des Jahres ab.

Ich habe bei mir zur Zeit ganz einfach die VMWare Tools von ESXi 6 auf OmniOS installiert, läuft bei mir alles wie es soll, nutze allerdings keine VMXNET3 Netzwerkadapter. Die OpenTools, kann ich die Tage mal versuchen zu kompilieren, kann aber nicht versprechen, wann ich mal dazu komme. Ist aber ja generell kein Problem schnell mal eine VM aufzusetzen und das zu testen, weiss nur nicht ob und wo man alle Pakete herbekommt, die man braucht.
 
Gestern habe ich bei meiner ESXi 6 Installation bemerkt, dass bei der Replikation meines VMPools auf den Backup Pool die Verbindung zum NFS Datastore verloren ging. Ich hoffe das war nur ein Zufall und ich werde das weiter beobachten, ansonsten wäre NFS mal wieder instabil bei der neuen Version, naja ich habe ja noch ein Backup von der 5.5 hier liegen und bin notfalls in 10 Minuten wieder auf dem alten Stand.

Edit: Ich sehe gerade das war gar nicht die Replikation sondern beim Snap des VMPools passiert in Verbindung mit ESXi HotSnaps, naja wie auch immer werde das weiter im Auge behalten.
 
Zuletzt bearbeitet:
Moin,
gestern hab ich mich auch an die ESXi6 Installation gewagt und wollte die Verbindung zwischen ESXi und VSAN beschleunigen. Ich hab mich mal an diesem Tut orientiert.

Leider gelingt es mir nicht, dass ESXi den NFS-datastore einbindet.

Regular data traffic to outside clients/servers will be on:
virtual machine port group: "VM Network" - with OmniOS ip address set to 192.168.2.210
ESXi VMKernel Port - Management Network - IP address 192.168.2.200

Storage traffic will be on a new vSwitch on IP address in range:
192.168.20.1 - 192.168.20.254
with virtual machine port group: "storagenet"
with OmniOS ip address set to 192.168.20.15
ESXi VMKernel Port - "VMKernel-storagenet" - IP address 192.168.20.220

Wo definiere ich die address range für den storage traffic?
Was mich stutzig macht, ist dass bei mir der Gateway des Kernels 192.168.2.1 lautet.
 
Im einfachsten Fall hat man in ESXi nur einen virtuellen Switch vSwitch0 an dem sowohl die externe Netzwerkkarte, alle VMs und das ESXi Management Netz (vSphere) angebunden sind.

In OmniOS hat man dann zwei vnics die beide an diesem Switch angebunden sind, eine für napp-it Web-management und eine als vmxnet 3 und eventuellen Optionen wie z.B. Jumboframes für Storage.

ESXi muss jetzt im gleichen Adressbereich arbeiten also z.B. ESXi 192.169.20.200, napp-it Management 192.168.20.201 und OmniOS vmxnet3 unter 192.168.20.202

Wenn man unter OmniOS jetzt NFS freigibt z.B. pool/nfs so muss der in ESXi als 192.168.20.202/pool/nfs eingebunden werden. (Einstellungen wie Jumboframes müssen passen, am besten mit 1500 anfangen und wenn es läuft z.B. mit 9000 tunen)
 
Zuletzt bearbeitet:
Ich bin bei mir hier auf das typische Henne-Ei Problem gestoßen. :wall: :kotz:

AIO ist die erste VM, welche auf dem ESXi gestartet wird, danach kommen alle anderen VMs, die auf dem AIO-NFS-datastore liegen. Die Zweite ist mein UTM-Gateway. UTM stellt u.a. DHCP, Internet und Firewall zur Verfügung.
ESXi kann jetzt den NFS-datastore nicht einbinden, wenn unterschiedliche Adressbereiche genutzt werden.

Also die UTM auf den ESXi-datastore verschoben, Diese zuerst gestartet, dann AIO und alles funktioniert.
 
Zuletzt bearbeitet:
Für Dienste, die sogar für den ESXi essentiell sind (DNS, NTP, ggf. DHCP, logging), würde ich in jedem Fall eine separate Box hinstellen, AIO hin oder her.

Bei mir ist das ein altes ALIX.
 
ESXI 6 oder/und Ugrade auf neue OmniOS Version bei mir nicht stabil, bin jetzt wieder zurück auf meinem Backup.

Ich werde weitere Tests wohl erst wieder Mitte/Ende des Jahres starten, dieser HickHack mit ESXi und Stabilitätsproblemen, geht mir allmählich auf den Kecks, daher ist meine Motivation für weitere Tests erstmal auf Null und ich bleibe bei meiner stabilen Installation.
 
ESXI 6 oder/und Ugrade auf neue OmniOS Version bei mir nicht stabil, bin jetzt wieder zurück auf meinem Backup.

Ich werde weitere Tests wohl erst wieder Mitte/Ende des Jahres starten, dieser HickHack mit ESXi und Stabilitätsproblemen, geht mir allmählich auf den Kecks, daher ist meine Motivation für weitere Tests erstmal auf Null und ich bleibe bei meiner stabilen Installation.

Es wäre schon wichtig zu wissen, was nicht stabil lief

- Hardware (MB, Nic, HBA)
- welche VMware tools
- vnic (e1000/vmxnet3)
- Datastore lokal/NFS/iSCSI
- Beschreibung des Problems
 
Supermicro X9SCM-F, LSI 9201-16i, LSI 9200-8e
VMWare Tools, die im aktuellen Build von ESXi an Board sind, mit der Info welche Version das genau ist kann ich nicht dienen.
VNIC e1000
Datastore per NFS
Verbindung zum Datastore geht immer wieder verloren und ist instabil

- - - Updated - - -

Wie gesagt, ich bin für weitere Tests erst einmal für das nächste halbe Jahr raus, soll VMWare erst einmal wieder einen vernünftig funktionierenden Build auf die Beine stellen, solange fahre ich weiter den letzten 5.5 Build.
 
Supermicro X9SCM-F, LSI 9201-16i, LSI 9200-8e
VMWare Tools, die im aktuellen Build von ESXi an Board sind, mit der Info welche Version das genau ist kann ich nicht dienen.
VNIC e1000
Datastore per NFS
Verbindung zum Datastore geht immer wieder verloren und ist instabil

Wichtig ist nur, dass andere wissen wo eventuell Probleme auftauchen.

Auf der OmniOS Mailing Liste vom 6.4 ( The OmniOS-discuss Archives ) gab es auch einen Bericht dass (nur einzelne) VMs nach einem Update unter 5.5U2 auf 151014 auf einem NFS datastore nicht mehr liefen.

Klar ist der erste der updated derjenige der die Fehler findet aber irgendwer muss anfangen.
 
Zuletzt bearbeitet:
Das habe ich mir als einziges noch vorgenommen zu testen, bin gerade Update auf 151014 unter 5.5 am machen, das werde ich die nächsten Tage dann laufen lassen. Falls es am OmniOS Update gelegen hat werde ich hier wieder berichten, dann gehts wieder zurück aufs Backup.
 
Danke,

bei zertified Hardware/ Software nimmt einem Dell, HP oder Oracle die Arbeit ab
- da heisst es oft dann aber auch bloss: not supported
 
Zuletzt bearbeitet:
Wie ist das eigentlich mit einem ZFS singledrive. Hat dieses die selben vorzüge wie ein ZFS raidz. Also Checksum, write-holes usw.?
 
Normalerweise habe ich ja eine 1:1 kopie außerhalb des Servers das hatte bis jetzt bereicht.
Ich weiß halt nur nicht ob ich mich an ein raidz oder raidz2 trauen soll weil diese ja nicht gerade für ihre schreibperformance bekannt sind^^ und wenn ich mal wieder ein paar videos von der Familie hochlade habe ich keine lust mit 40-50MB/sek herrum zu eiern.

Momentan bin ich halt noch am testen in einer komplett virtuellen Umgebung mit virtuellen Festplatten die ich dem ZFS zuweise. Wenn ich dem napp-it eine virtuelle Festplatte in Form einer SSD geben dann ist die Geschwindigkeit gut. Mache ich es mit einer normalen HDD bricht die Geschwindigkeit gnadenlos ein. Denke zwar das es an der virtuellen HDD ist die ich der napp-it VM geben liegt. Im wirklichen Betrieb würde die VM einen HBA durchgereicht bekommen werden so das ich glaube das die Geschwindigkeit steigen sollte. Ich hab nur keine lust für 1000€ Platten zu kaufen und dann zu merken es ist mir zu langsam^^
 
Zuletzt bearbeitet:
Vielleicht ist auch ein einfacher ZFS Mirror eine Option, da werden einfach die Platten gespiegelt, Performance ist gleich wie bei einer Single Disk.
Ich habe bei mir ein RAIDZ2 über sechs WD Red Platten am laufen, Geschwindigkeit sind 360 bis 420 MB/s lesend und schreibend, da eiert also nix rum :)
 
Das hört sich doch ganz gut an. Dann sind meine "Ängste" in bezug auf die Geschwindigkeit wohl unberechtig und wohl den aktuellen Umständen geschuldet. In dem Fall würde ich ein raidz2 vorziehen und meine Backup Strategie ändern. Ist dein ZFS auf einer virtuellen oder physikalischen Umgebung?
 
Also so wie ich nur das ich ESXi 6.0. nutze und zum testen keinen 2. HBA habe zum durchreichen^^
welche Netzwerkkarte hast du am laufen wenn du 360 - 420MB/sek kopierst
 
ZFS Pools aus single Disks macht man eigentlich nur, wenn man das ZFS Dateisystem ohne ZFS Echtzeit Raid machen möchte (zusammen z.B. mit einer Backuplösung wie Snapraid). Typische Anwendung: Mediaserver @home.

Die Performance dabei ist dabei immer = 1 disk

Ansonsten skaliert bei ZFS die Performance mit den Platten und zwar:

bei einem Pool aus einem Mirror
- seqentielle Leseperformance: 2 x disks
- sequentielle Schreibperformance: 1 x disk
- iops Lesen: 2 x disks
- iops Schreiben: 1 x disks

bei einem Pool aus einem Raid 10 Mirror (zwei vdevs)
- seqentielle Leseperformance: 4 x disks
- sequentielle Schreibperformance: 2 x disk
- iops Lesen: 4 x disks
- iops Schreiben: 2 x disks

entsprechend bei mehr mirrors

bei einem Pool aus einem Raid-Z vdev (1-3)
- seqentielle Leseperformance: n x datadisks (ohne Redundanz)
- sequentielle Schreibperformance: n x datadisk
- iops Lesen: 1 x disk
- iops Schreiben: 1 x disk

Die geringe iops Zahl liegt daran, dass für jede Schreib-Leseaktion
alle Platten positioniert werden müssen.

bei einem Pool aus zwei Raid-Z 1-3, (2 vdevs)
- seqentielle Leseperformance: n x datadisks (beider vdevs, ohne Redundanz)
- sequentielle Schreibperformance: n x datadisk
- iops Lesen: 2 x disk
- iops Schreiben: 2 x disk

entsprechend bei mehr Raid-Z vdevs

Das zeigt, dass ZFS sehr gut mit den Platten skaliert und dass Multi-Mirror Pools
vor allem dann genommen werden, wenn iops wichtig ist, also Datenbanken
oder ESXi datastores mit normalen Platten.


Mehrere GB/s Datenraten mit Raid-Z sind somit prinzipiell und sequentiell kein Problem.
Sync Write, bei dem es auf iops ankommt, ist aber mit Raid-Z deutlich langsamer
sofern man kein separates schnelles Logdevice (z.B. Intel 3700-100 oder Winkom SLX 8-32) hat
 
Zuletzt bearbeitet:
bei einem Pool ais zwei Raid-Z 1-3, (2 vdevs)
- seqentielle Leseperformance: n x datadisks (ohne Redundanz)
- sequentielle Schreibperformance: n x datadisk
- iops Lesen: 2 x disk
- iops Schreiben: 2 x disk

entsprechend bei mehr Raid-Z vdevs

Da sind die raidz's doch gestrippt oder ? Ist das zum verleichen wie ein Raid 50 oder 60?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh