[Sammelthread] ZFS Stammtisch

ja, da hakts halt bei mir gedanklich. wenn die vm's auf dem esxi ruhig laufen, z.b. ein webserver, gehen dann die platten in der storage vm schlafen?... wird das über den arbeitsspeicher kompensiert oder so?


(Entschuldigt bitte so ein doofes Nachgefrage)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Platten für VM-Storage werden zu 99.9% nicht in der Lage sein runterzufahren, sofern du nicht die VMs irgendwie speziell darauf trimmst, nur aus dem RAM zu laufen.
 
hmm. vielleicht muss ich mir überlegen die webserver sachen irgendwie doch nicht aus dem storage zu bedienen. ist halt nur blöd für so kram wie online-fotogalerie oder owncloud und sowas.
 
Wenn du die HDDs per VT-D / Passthrough durch mappst, kannst du die auch von der VM schlafen legen lassen.
Vorausgesetzt der Controller supported das natürlich

Die Raid-Software muss den sleep Modus kontrollieren.
Der Kontroller muss das bei Hardware Raid unterstützrn.

Bei einem HBA und Software Raid/ ZFS muss das OS den Sleep-Modus steuern. OmniOS kann das zwar, ich glaube aber nicht, dass ESXi und die VMs begeistert sind, wenn der Storage plötzlich weg ist.

Wenn man kein extra Script benutzt, gibt es staggered spinup bei dem das Aufwachen bis zu einer Minute dauert. Ich halte das daher für wenig sinnvoll. Wenn dann eher einen kleinen high-speed SSD Pool (24/7) und einen Pool als Filer und für Backup mit sleep.
 
Bei einem HBA und Software Raid/ ZFS muss das OS den Sleep-Modus steuern. OmniOS kann das zwar, ich glaube aber nicht, dass ESXi und die VMs begeistert sind, wenn der Storage plötzlich weg ist.

Beim Sleep ist doch der Storage nicht weg. Er wacht halt nur direkt wieder auf bzw. ist nie lange genug idle, um überhaupt zu schlafen.
 
Beim Sleep ist doch der Storage nicht weg. Er wacht halt nur direkt wieder auf bzw. ist nie lange genug idle, um überhaupt zu schlafen.

Hängt von der Schnelligkeit und der Anzahl der Platten ab
Wenn der NFS datastore zu lange braucht um wieder verfügbar zu sein, wird ESXi ihn offline setzen.
 
Gibt es irgendwas was man wissen/beachten muss bei NFS Shares bei OmniOS? Ich möchte dass ein Raspberry Pi auf den Server zugreifen kann per NFS. Reiner Lesezugriff, es soll nix verändert werden können.

Bislang hab ich noch nie was mit NFS gemacht. Welche Version besitzt OmniOS 3 oder 4? 4 Soll ja auch ACL können, sind das dann die gleichen die auch für SMB verwendet werden oder gibt es da dann zwei parallele Liste, eine für SMB und eine für NFS ?
 
OmniOS unterstützt NFS 3 und 4.0

Ich würde erst mal einfach alles auf default lassen (everyone@=modify) und NFS auf on stellen
und in den sharing parametern so etwas wie ro=@192.168.1.0/24 (tatsächliches Subnet einsetzen) benutzen.

Hintergrund
NFS3 kennt weder Authentifizierung noch Authorisierung (Permissions).
Alles geht auf good will Basis aufgrund der IP und der Unix uid

NFS4 kann Authentifizierung und unterstützt nfs4 ACL (ähnlich ntfs ACL).
Die Unix Permissions sind eine Untermenge der ACL Fähigkeiten aber ohne ACL Vererbung.
Daher wird die auch gelöscht wenn man traditionelle Unix Permissions setzt.
ACL und Unix Permissions sind also keine zwei Listen. Das sind Dateiattribute,
hat also nix mit dem Sharing Protokoll zu tun.

Falls Authentifizierung nötig ist, würde ich aber eher auf SMB setzen,
 
Zuletzt bearbeitet:
Es ist keine Authentifizierung nötig, es kann jeder Zugriff haben, allerdings soll es nur lesender Zugriff sein. Das sollte sich doch auch mit NFS einfach lösen lassen oder? Aber der Schreibschutz unter Nappit ist ebenso keine Lösung weil über SMB der Zugriff doch wieder auch schreibend sein soll.
Ich würde erst mal einfach alles auf default lassen (everyone@=modify) und NFS auf on stellen
und in den sharing parametern so etwas wie ro=@192.168.1.0/24 (tatsächliches Subnet einsetzen) benutzen.
nein, everyone=modify ist nicht hinnehmbar, hab keine Lust drauf dass Daten ausversehen oder beabsichtigt gelöst werden können. Nen extra Subnetz wäre auch keine tolle Lösung da auch andere Dinge noch erreichbar sein sollen über das RPi dann.

ACL und Unix Permissions sind also keine zwei Listen. Das sind Dateiattribute,
hat also nix mit dem Sharing Protokoll zu tun.
Also sind die ACLs unter NFSv4 und SMB gleich.

Falls Authentifizierung nötig ist, würde ich aber eher auf SMB setzen,
Was spricht gegen NFSv4 wenn damit auch Authentifizierung möglich ist? Immerhin ist es nativ unter Unix.
SMB macht nur Sinn bei Windows oder Apple Geräten, wieso sollten aber zwei unix Geräte im Netzwerk jetzt SMB statt NFS nutzen?
 
Zuletzt bearbeitet:
Was spricht gegen NFSv4 wenn damit auch Authentifizierung möglich ist? Immerhin ist es nativ unter Unix.
SMB macht nur Sinn bei Windows oder Apple Geräten, wieso sollten aber zwei unix Geräte im Netzwerk jetzt SMB statt NFS nutzen?

Prinzipiell spricht nichts dagegen.

SMB kann halt mehr, ist auf allen Plattformen verfügbar und wird auch immer schneller.
Auch ist NFS nicht so verbreitet und irgendwie auf jeder Plattform anders.

Es ist nicht soo schlecht, wenn nur eine Firma (M$) festlegt, wie es funktionieren soll -
Zumal es mit SAMBA und Solaris CIFS auch unter X gut unterstützt wird.
 
An die ARM Fraktion hier im ZFS Chat, gibt es denn schon brauchbare ARM Systeme, die 64Bit und wenigstens 4GB RAM haben? Abgesehen davon sollte es auch SATA geben. Vielmals ist das bei ARM nur über USB gelöst. Wie sieht der aktuelle Stand mit ZFS in diesem Bereich aus? Nicht falsch verstehen, ich würde mich sehr freuen, wenn sich etwas in dieser Richtung tut.

- - - Updated - - -

SMB kann halt mehr, ist auf allen Plattformen verfügbar und wird auch immer schneller.
Auch ist NFS nicht so verbreitet und irgendwie auf jeder Plattform anders.

Sehe ich auch so, ich habe derzeit 250 VM's auf zwei NFS Share's liegen und habe einen sehr guten Durchsatz. Viele werden von den Großen Storage Anbietern massiv in Richtung FC oder iSCSI getrieben, nur damit Sie nicht mehr davon los kommen. Ich kann mir auch SMB3.x als Alternative zu NFS vorstellen. Was mich etwas ärgert nicht an ZFS selbst ist, dass es gerade im Solaris auch BSD ewig braucht, bis sich nur eine Kleinigkeit bewegt. Ich nutze ZFS seit ca. 6 Jahren im Firmenumfeld, aber weder Sun/Oracle noch Nexenta schaffen es endlich mal eine vernünftige Unterstützung für VMware oder auch VSS Snapshot bereit zu stellen. Auf SMB 2.x habe ich bei Sun/Oracle 3 Jahre warten müssen.

Meine Traum wäre, ZFS wird mal so umprogrammiert, dass es keiner Lizenzregel mehr entspricht und in allen Unix-Betriebssystemen auch als Root-Dateisystem zur Verfügung gestellt würde. Könnte man BTRFS und HammerFS einstampfen und ZFS gemeinsam weiter entwickeln. Vielen ist bis heute das Potential von ZFS nicht klar und mich kotzen viele Webseiten an, wo schlicht nur Murks über ZFS geschrieben wurde. Wenn ich mich nicht täusche ist BTRFS von Oracle und HammerFS auf derzeit ein BSD Variante beschränkt.
 
Naja ändert aber aktuell nichts dadran dass nfs weniger Ressourcen benötigt auf dem raspberry Pi. So wie ich das sehe kann man Verzeichnisse mit "ro" statt "rw" auch schreibgeschützt freigeben unter omnios
 
Eine Frage zu den Pool Informationen auf disks. Vor ca. 3 Jahren hatte ich zum Test einen großen RAIDZ1 Pool (tank) angelegt um Erfahrungen mit Resilvering, Performance, Ausfall von Platten im Betrieb etc zu sammeln. Anschließend habe ich dann den Pool umkonfiguriert und als neuen MIRROR Pool (tank) mit den gleichen Platten aufgesetzt. Die Anforderung war hier hohe Datensicherheit. Dieser Pool lief dann bis letzten Sonntag mit einer uptime von über 1000 Tagen. Am Sonntag war dann ein langer Stromausfall und nach dem Neustart war der Pool nicht da. Alle Platten waren aber verfügbar. Nach absetzen den Befehls 'zpool import tank' kam folgende Meldung:

cannot import 'tank': more than one matching pool
import by numeric ID instead


Da ich vermutlich damals vergessen habe den pool sauber zu löschen (kein zpool destroy tank) sind die alten Signaturen noch auf den Platten. Dann habe ich mit dem Befehl 'zpool import' folgende Ausgabe bekommen (siehe unten). Anschließend habe ich mit 'zpool import <ID>' den MIRROR Pool tank wieder aktiviert. Ich frage mich nun, wie kann ich die veralteten Pool-Signaturen auf den disks entfernen, damit beim nächste Neustart alles glatt geht?


root@solaris:~# zpool import
pool: tank
id: 8520255467175395573
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:

tank ONLINE
mirror-0 ONLINE
c0t50014EE655B71EE8d0 ONLINE
c0t50014EE057B1DE40d0 ONLINE
c0t50014EE655B54205d0 ONLINE
mirror-1 ONLINE
c0t50014EE655B2590Cd0 ONLINE
c0t50014EE6AAC0AA52d0 ONLINE
c0t50014EE0AD087E2Cd0 ONLINE
mirror-2 ONLINE
c0t50014EE6ABF3055Ed0 ONLINE
c0t50014EE655B53E25d0 ONLINE
c0t50014EE600619215d0 ONLINE
mirror-3 ONLINE
c0t50014EE0AD084300d0 ONLINE
c0t50014EE057B3140Bd0 ONLINE
c0t50014EE6569FF5A5d0 ONLINE
mirror-4 ONLINE
c0t50014EE0ACFBD6C0d0 ONLINE
c0t50014EE6005FA53Ad0 ONLINE
c0t50014EE0025EB1EAd0 ONLINE
spares
c0t50014EE655B571BCd0
c0t50014EE655B752D5d0
c0t50014EE05806450Bd0

pool: tank
id: 12462861670191217554
state: UNAVAIL
status: The pool was last accessed by another system.
action: The pool cannot be imported due to damaged devices or data.
see: http://www.sun.com/msg/ZFS-8000-EY
config:

tank UNAVAIL insufficient replicas
raidz1-0 UNAVAIL insufficient replicas
c0t50014EE0ACFBD6C0d0 ONLINE
c0t50014EE0AD087E2Cd0 ONLINE
c0t50014EE0AD0796FFd0 UNAVAIL cannot open
c0t50014EE0AD0858E5d0 ONLINE
c0t50014EE0AD08948Ed0 ONLINE
c0t50014EE0AD084300d0 ONLINE
c0t50014EE6AAC0AA52d0 ONLINE
c0t50014EE0025CE877d0 UNAVAIL cannot open
c0t50014EE0025D2F2Bd0 ONLINE
c0t50014EE0025EB1EAd0 ONLINE
c0t50014EE057B1DE40d0 ONLINE
c0t50014EE057B2F6FCd0 ONLINE
c0t50014EE057B2F158d0 ONLINE
c0t50014EE057B3FD8Cd0 ONLINE
c0t50014EE057B3140Bd0 ONLINE
raidz1-1 DEGRADED
c0t50014EE655B38D18d0 ONLINE
c0t50014EE655B53E25d0 ONLINE
c0t50014EE655B71EE8d0 ONLINE
c0t50014EE655B571BCd0 ONLINE
c0t50014EE655B632A7d0 ONLINE
c0t50014EE655B752D5d0 ONLINE
spare-6 ONLINE
c0t50014EE655B2590Cd0 ONLINE
c0t50014EE600619215d0 ONLINE
c0t50014EE655B4030Ad0 ONLINE
c0t50014EE655B5508Dd0 UNAVAIL cannot open
c0t50014EE655B54205d0 ONLINE
c0t50014EE6005FA53Ad0 ONLINE
c0t50014EE6005FC470d0 ONLINE
c0t50014EE60061D906d0 ONLINE
c0t50014EE600612A5Cd0 ONLINE
spare-14 DEGRADED
c0t50014EE6006103B1d0 OFFLINE
c0t50014EE00250EF2Bd0 ONLINE
 
Zuletzt bearbeitet:
Ich denke, dass keine Aktion nötig ist, da die Poolinformationen jetzt wieder in der Datei /etc/zfs/zpool.cache gespeichert sind.

Ich vermute mal, das diese Datei bei dem Absturz beschädigt wurde und der Pool daher neu importiert werden musste. Dabei werden alle Platten eingelesen. Die Notwendigkeit, den Pool dann anhand der Pool Id statt des Namens zu importieren, ist dann ein normaler Vorgang falls mehrere frühere Pools mit gleichem Namen entdeckt werden. Ich vermute, dass die Informationen für den älteren Pool auf den Spare Platten gefunden wurde.
 
Ich denke, dass keine Aktion nötig ist, da die Poolinformationen jetzt wieder in der Datei /etc/zfs/zpool.cache gespeichert sind.

Ich vermute mal, das diese Datei bei dem Absturz beschädigt wurde und der Pool daher neu importiert werden musste. Dabei werden alle Platten eingelesen. Die Notwendigkeit, den Pool dann anhand der Pool Id statt des Namens zu importieren, ist dann ein normaler Vorgang falls mehrere frühere Pools mit gleichem Namen entdeckt werden. Ich vermute, dass die Informationen für den älteren Pool auf den Spare Platten gefunden wurde.

Danke Deines Hinweises habe ich noch mal genauer auf die Anlage geschaut. Da es fast drei Jahre her war, hatte ich übersehen, dass ich damals noch 5 Platten als cold standby in den Shelfs hatte. Auf einer dieser Platten war eine alte Signatur des alten Pools tank. Ich habe dann einen temp-pool mit zpool tank_tmp create -f disk1 disk2 disk3 disk4 disk5 angelegt und diesen anschließend mit zpool destroy tank_tmp wieder gelöscht. Nun liefert der Befehl zpool import keine Auffälligkeiten mehr.

Besten Dank!
 
Gutes Argument dafür, immer seine Platten (möglichst komplett) zu nullen, bevor man sie (mit welchem FS auch immer) initialisiert.
 
Hat einer von euch schon erfahrungen mit NVME+ZFS gesammelt, wenn ja mit welchem OS?
Für die Open Solaris varienaten scheint es ja am treiber zu scheitern...
 
Hat einer von euch schon erfahrungen mit NVME+ZFS gesammelt, wenn ja mit welchem OS?
Für die Open Solaris varienaten scheint es ja am treiber zu scheitern...


Soweit ich weiss ist NVME noch auf keinem Illumos-basierendem System vorhanden.

So wie es scheint gab es schon 2013/2014 Versuche NVME in Illumos zu implementieren.
Siehe Illumos Ticket

Ansonsten wurde das Thema in diversen Mailing-Listen schon erfragt, siehe:
Ominos-April-2015-Mailing-List (ziemlich weit unten)

illumos-developer-List-2014

Scheint so als würde Nexenta an irgendwas arbeiten. Hoffe die pushen das dann auch zu illumos.
 
Zuletzt bearbeitet:
Ein paar Nexenta Blog posts zu dem Thema hatte ich auch schon gelesen.
Angeblich ist ja ab Kernel Version 3.3 oder sowas für Linux NVME unterstützung dabei.
Vielleicht hat da ja schon wer Erfahrung mit.
ZFS on Linux soll aber in den letzten Jahren auch gut zugelegt haben auch wenn mir die Solaris ZFS implementationen bisher immer etwas besser gefallen haben.
 
@Fr@ddy, sei vorsichtig bei Debian 8 und ZFS, ich habe auf zwei Unterschiedlichen Systemen jeweils Pools intern zerschossen. Damit meine ich, Debian 8 hat einfach Mist geschrieben. Teste sowas vorher intensiv durch.
 
Wie hast Du das Mistschreiben denn bemerkt? Ich hab ZFS unter Ubuntu laufen, bisher sind mir aber noch keine Fehler aufgefallen.
 
Wie hast Du das Mistschreiben denn bemerkt? Ich hab ZFS unter Ubuntu laufen, bisher sind mir aber noch keine Fehler aufgefallen.

Ich habe sowohl einen Shuttle PC, diesen nutze ich gerne zum Testen von ZFS orientierten Systemen. Primär nutze ich ZFS unter Sabayon Linux, dann natürlich auch PCBSD und Mac OS X (Apple), beruflich habe ich noch Sun und Nexenta. Als ich nach dem Erscheinen von Debian 8 ZFS installierte, wunderte ich mich nur, dass übertragene Daten "zfs send zfs recv" von einem vorhandenen Pool nicht vollständig schienen (Größenunterschiede). Als ich diesen Pool-Inhalt dann Dateiorientiert lesen wollte, kam es zu Lesefehlern unterschiedlicher Art. Hier muss man wissen, dass die gleiche Platte vor Debian 8 keine Fehler zeigte. Wenn es ja nur ein sporadischer Fehler gewesen wäre, hätte ich mir gedacht die Platte hat eine Macke. Aber es waren von ca. 10 Datasets 3 Pools fehlerhaft.

So etwas habe ich wirklich noch bei keinem anderen OS so gesehen. Ich möchte Debian nicht schlecht machen, empfehle aber vorsichtig bei Debian 8 zu sein oder ggf. bei Debian 7 zu bleiben. Ein Kollege von mir nutzt Debian 7 mit ZFS und ist sehr zufrieden. Wenn es bei Dir mit Ubuntu gut läuft, schön!

- - - Updated - - -

Ich habe zwei Fragen, wonach ich schon ewig suche.

1) Welche der Solaris Varianten haben schon SMB2 im Kernel? Denke hier besonders an OmniOS und finde dazu nichts.
2) OminOS oder anderes Solaris System mit Napp-IT oder FreeNAS (ggf. andere) mit FreeBSD als Unterbau?

Mein Problem Punkt 2) Ich würde schon gerne in Richtung FreeBSD und ggf. sogar Linux gehen, aber ich sehe weniger ZFS Unterstützung wie z.B. automatische Umschaltung auf Spareplatte oder auch Dinge wie "zfs set shareiscsi, sharenfs oder sharesmb" im Kernel. Bei FreeNAS soll die Oberfläche nicht synchron zu ZFS sein, meine damit direkte ZFS Änderungen werden nicht in FreeNAS berücksichtigt.

Wäre schön darüber mal etwas zu sprechen. Schließlich drängen uns die Hersteller besonders im Firmenumfeld mehr und mehr Richtung Volumen orientierter Lizenzierung. Davon möchte ich weg!
 
1) Welche der Solaris Varianten haben schon SMB2 im Kernel? Denke hier besonders an OmniOS und finde dazu nichts.
2) OminOS oder anderes Solaris System mit Napp-IT oder FreeNAS (ggf. andere) mit FreeBSD als Unterbau?

Mein Problem Punkt 2) Ich würde schon gerne in Richtung FreeBSD und ggf. sogar Linux gehen, aber ich sehe weniger ZFS Unterstützung wie z.B. automatische Umschaltung auf Spareplatte oder auch Dinge wie "zfs set shareiscsi, sharenfs oder sharesmb" im Kernel. Bei FreeNAS soll die Oberfläche nicht synchron zu ZFS sein, meine damit direkte ZFS Änderungen werden nicht in FreeNAS berücksichtigt.

1.
SMB2 und höher gibt es mit dem Solaris CIFS Server derzeit nur bei NexentaStor.
Nexenta/ Gordon Ross ist aber dabei, dass in Illumos zu integrieren. Es wird dann z.B. auch in OI/ OmniOS bereitstehen illumos day 2014 SMB2. Ich erwarte das noch dieses Jahr.

Natütlich könnte man unter Solaris und Illumos auch SAMBA4 einsetzen.

2.
In manchen Storage Sachen ist Solaris nach wie vor führend.
zfs set shareiscsi ist aber obsolet und wird bei Solaris durch das neuere und viel schnellere Comstar Framework ersetzt

http://docs.oracle.com/cd/E23824_01/html/821-1459/fmvcd.html


update:
Das neue Solaris 11.3 hat auch SMB 2.1
 
Zuletzt bearbeitet:
@gea, Danke für deine schnelle Antwort. Ich versuche möglichst viel über NFS und SMB abzuwickeln.

iSCSI ist zwar notwendig, aber ich versuche es zu vermeiden, wo es geht. Ich finde den Verschnitt (Speicherverschwendung bei iSCSI schlimm). Bei Netapp habe ich das mal durchgespielt, bei 100% Brutto Platten kommt man auf weniger als 30% Netto Platten Nutzkapazität. Hier ist vieles dem Konzept LUN in LUN in LUN ... geschuldet. Zudem rudert man bei Werkzeugen wie z.B. Veeam wieder Richtung NFS. Fast Recovery für VMware VM's sowie SQL Server, Exchange Server Backups, Active Directory werden einfacher durch NFS. Direkte NFS Sicherungen der VMware Snapshots sollen auch bald möglich sein.
 
@gea, Danke für deine schnelle Antwort. Ich versuche möglichst viel über NFS und SMB abzuwickeln.

iSCSI ist zwar notwendig, aber ich versuche es zu vermeiden, wo es geht. Ich finde den Verschnitt (Speicherverschwendung bei iSCSI schlimm). Bei Netapp habe ich das mal durchgespielt, bei 100% Brutto Platten kommt man auf weniger als 30% Netto Platten Nutzkapazität. Hier ist vieles dem Konzept LUN in LUN in LUN ... geschuldet. Zudem rudert man bei Werkzeugen wie z.B. Veeam wieder Richtung NFS. Fast Recovery für VMware VM's sowie SQL Server, Exchange Server Backups, Active Directory werden einfacher durch NFS. Direkte NFS Sicherungen der VMware Snapshots sollen auch bald möglich sein.


Bei iSCSI mit Comstar wird ein ZFS Volume (ZFS Dateisystem) als LUN bereitgestellt. Weitere LUNs basieren auf eigenen ZFS Volumes. Die Summe aller LUNs muss halt kleiner sein als die Pool Kapazität. Eine Speicherverschwendung sehe ich dabei nicht.

Ich nutze für ESXi aber auch ausschließlich NFS. Das ist genauso schnell wie iSCSI, viel einfach zu warten und zu sichern. Man kann auch einfach parallel per SMB darauf zugreifen um per Windows "vorherige Version" etwas wiederherzustellen oder eine VM manuell zu sichern oder zu clonen.

iSCSI ist dann interessant, wenn man eigene Dateisysteme braucht (z.B. ntfs, ext4) oder HA Lösungen machen möchte (z.B. Storagehead oder Client auf zwei Storagenodes in Raid-1 per iSCSI) oder einfach sehr große Kapazitäten braucht. (Storagehead mit ZFS Raid über iSCSI Storagenodes)


wg ESXi Backup
Ich mache das so:
- ESXi Hot-Snap anlegen (inkl Memory State)
- ZFS Snap anlegen (enthält ESXi Hotsnap)
- ESXi Snap löschen
- ZFS Dateisystem (enthält ESXi Hotsnap) per inkrementeller ZFS Replikation wegsichern

Ich habe die Funktion in napp-it Free integriert.
Das geht übrigens auch mit ESXi free da es nicht auf der ESXi API basiert.
 
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