Umstellung von nas4free auf napp-it AiO

[AliManali]

Hi

Ich habe bei meinem Server vor einiger Zeit einen DELL Perc H310 eingebaut, auch sonst wurde einiges geändert (von X79 zu C612). Auf X79 hatte ich noch FreeNAS im Einsatz. Seit dem Wechsel zu C612 habe ich leider nur noch 32GB RAM, was mich zu einem Wechsel auf NAS4free zwang. Im Moment ist also der HBA per VT-d an NAS4free weiter gereicht. An dem Controller hängt eine 2TB SSD mit den VM's, und eine 6TB WD Gold als NAS. Die SSD wurde per NFS am ESXi eingehängt. Das läuft auch. Die SSD ist zusätzlich per SMB im LAN erreichbar, allerdings muss ich im Moment die Rechte per SSH vergeben, um wenigstens lesenden Zugriff auf die Files zu bekommen.

Siehe auch folgenden Fred:

Zugriff auf VM NFS Share per SMB - VMware-Forum

Nun wollte ich gerne auf napp it wechseln. Stellt sich die Frage, ob das sinnvoll ist mit nur max. 6GB RAM, einer 2TB SSD und einer 6 TB HDD. Deduplication, Snapshots und so nen Gedöns brauche ich im Moment nicht.

Dann wollte ich die napp it Software mal testen. Laut der Seite würd wohl am ehesten die napp-it ToGo VM in Frage kommen? So was ich gesehen habe, brauch ich da um das zu testen aber einen HBA und VT-d? Geht das nicht auch mit VMDK's, so wie bei anderen NAS Systemen? Mein aktuelles Storage möchte ich für erste Tests nicht missbrauchen. Es würde irgendwo in meinem "Puff" noch nen DELL PERC H200 rumliegen im Notfall, aber wenn das rein virtuell geht, würd ich das vorziehen.

Gruss und Danke!

 

[gea]

Um das ESXi Template zu testen braucht man weder einen HBA noch vt-d. Man kann auch einen Pool auf virtuellen Platten anlegen. Wenn es aber produktiv wird, kommt man nur mit RDM oder einem HBA und pass-through an die Performance eines reinen Hardware Storageservers heran.

Mit einem SAS HBA (ohne pass-through) kann man aber prima einzelne SAS oder Sata Platten per RDM bereitstellen (ESXi: Platten hinzufügen > raw Platte, ohne Console Hacks)

 

[AliManali]

Hi

Ja, bin es gerade mit 3 VMDK's am testen. Was mich bislang von napp-it abgehalten hat, ist dass es offensichtlich nur englisch dokumentiert ist. Ist das Deine Website?

Sieht schon mal gut aus. Muss aber erst mal alle Daten die am HBA hängen sichern. Aber theoretisch könnte ich wohl die ZFS Pools von NAS4free einfach wieder importieren? Habe ich beim Wechsel von FreeNAS auf NAS4free auch so gemacht.

 

[gea]

Die Pools sind zwischen Open-ZFS prinzipiell austauschbar. Probleme mit der Partitionierung kann es geben wenn nicht die ganze Platte für ZFS verwendet wurde. Dann geht aber einfach der Import nicht.

Und ja, napp-it.org ist meine Website.
Prinzipiell ist napp-it mehrsprachig angelegt. Die Dokumentation und die Primärsprache ist aber Englisch. Liegt einfach daran dass Solaris ein kommerzielles OS ist, das in Deutschland weit weniger genutzt wird als in USA oder anderen europäischen Ländern. Bis vor kurzem waren bei weitem die meisten User aus den Staaten oder anderen europäischen Ländern. Liegt auch daran dass Solaris, OpenSolaris und dann die freien Solaris Forks im Heimbereich bis vor kurzen viel viel weniger genutzt wurden als z.B. Free-BSD und natürlich Linux - trotz überlegener ZFS Integration und Features.

 

[AliManali]

Hi

Ja danke. Habe mir das mal angesehen, und scheint auch nicht viel komplizierter zu sein, als mit meinen aktuellen NAS VMs. Der MC unter SSH ist ja mal zu geil. Erinnert mich irgendwie an Norton Commander unter DOS. Kannte ich noch nicht bislang.

Ich sicher dann mal alles von den 2 Platten, und wag mich mal dran. Aber nicht mehr heute.

Ne, auf den beiden Produktivplatten die migriert werden sollen, ist je einfach jeweils eine grosse ZFS Partition vorhanden. Das hatte schon beim Wechsel von FreeNAS zu NAS4free relativ problemlos geklappt.

Ich habe dann vielleicht mal noch ein paar Fragen bzgl. Rechte, die von vSphere per NFS vergeben werden (siehe vmware forum thread aus #1). Aber erst mal testen, dann.

 

[gea]

SMB erfordert eine Anmeldung und kann den Zugriff aufgrund der Nutzer einschränken (Authentifizierung und Authorisierung). Sun hatte beides in NFS3 nicht vorgesehen. Das Netzwerk-Dateisystem NFS ist für sichere Netze gedacht. Zugriffsbeschränkungen bei NFS sind nur über die Client IP möglich. Der Zugriff eines NFS clients erfolgt je nach System mit der uid des clients oder als nobody.

Am einfachsten löst man das Problem wenn man NFS und SMB aktiviert und dann die ACL auf everyone@=modify stellt. Damit hat NFS und SMB Zugriff. Aktiviert man SMB später. setzt man ACL rekursive auf diese Einstellung zurück. OmniOS erweitert aclmode auf die ZFS Eigenschaft restricted. Das hindert NFS daran, Rechte zu ändern. Kann man für das Dateisystem auch aktivieren.

Braucht man Sicherheit so nutzt man neben dem LAN ein weiteres sicheres Netz Management/SAN und legt da ESXi Management und napp-it/NFS mit einer eigenen Instanz (oder nutzt eine Firewall) ohne LAN Zugriff. Eine weitere napp-it Instanz für Filerdienste erhält dann eine zweite vnic mit Zugriff ins geschützte Netzt.

 

[AliManali]

Braucht man Sicherheit so nutzt man neben dem LAN ein weiteres sicheres Netz Management/SAN und legt da ESXi Management und napp-it/NFS mit einer eigenen Instanz (oder nutzt eine Firewall) ohne LAN Zugriff. Eine weitere napp-it Instanz für Filerdienste erhält dann eine zweite vnic mit Zugriff ins geschützte Netzt.

Hi

Danke für Deine Hilfe!

So ein Management Netzwerk wollte ich schon vor Jahren mal einrichten. Das wär dann als zusätzliches vLAN auf dem DMZ Port geplant gewesen; für den Zugriff auf die Firewall, die Switches und dem vmkernel von vSphere. Im Moment hängt das einfach im LAN, neu auch noch mit IPMI und den beiden Filer. Spielt bei mir eigentlich keine grosse Rolle, der ganze Plunder läuft eh seit Jahren im Laborbetrieb. Gescheitert ist es damals an meinem Switch, welcher das Feature nicht unterstützt hat, wenn ich mich recht erinnere. Da hat mir ein Zyxel Profi mal per Teamviewer einen Tag lang geholfen.

Ich hatte das aber schon noch im Hinterkopf mit dem Managment Netz, seit ich die beiden virtuellen NAS habe. Ich dachte mir da schon, dass ich das NAS für NFS auf einen separaten vSwitch lege, welcher an (vorläufig) gar keinem Gateway hängt. Mir reicht es eigentlich schon, wenn ich die VM's irgendwie auf die Platte sichern kann. Und das sichern werd ich wohl gleich per SSH und MC machen.

Ich habe grosse Angst vor nem Verschlüsselungstrojaner auf meinem Haupt Desktop. Der könnte mir gewaltig einen Strich durch die Rechnung machen mit all seinen eingehängten Netzlaufwerken. Weil wenn ich ehrlich bin, ein 2. offline Backup gibt es bei mir nicht. Es handelt sich um gut 30 VM's. Der super GAU wär jetzt nichts existenzbedrohendes, trotzdem steckt viel Arbeit dahinter.

 

[AliManali]

Hi

Habe die wichtigen Daten, bzw. die VM's auf meinen Desktop gesichert. Dann den HBA von nas4free enfernt, und in einer neuen napp-it VM wieder hinzu gefügt.

Leider gibt napp-it auf der Konsole dauernd Fehlermeldungen aus. Importieren konnte ich die ZFS Volumes trotzdem. Was heisst das jetzt für mich konkret, bevor ich weiter mache?

 

[gea]

Das Importieren des Pools scheint geklappt zu haben. (Pool statt Volume). Es scheint dennoch ein Problem mit der BSD Partitionierung zu geben der dafür sorgt, dass das ZFS Label nicht gelesen werden kann. Da das doppelt vorliegt hat es wohl dennoch geklappt. Wenn es ein Backup gibt würde ich wohl den Pool neu anlegen.

ps
Wenn man in Putty in den Settings Window > Translation den Zeichensatz auf ISO 8859 West Europe stellt, so macht der mc schöne Rahmen statt xxx.

Zu Ransomware
Dafür macht man ZFS Snaps. Die sind readonly und können im Gegensatz zu Windows Shadow Copies auch mit Windows Adminrechten von einem Trojaner nicht gelöscht oder verschlüsselt werden.

 

[AliManali]

Wenn es ein Backup gibt würde ich wohl den Pool neu anlegen.

D.h.? Muss ich da die Backups vom Desktop wieder einspielen? Bezieht sich der Fehler an der Konsole auf die SSD oder die HDD? Backups vom Desktop wieder einspielen, habe ich irgendwie keine Lust. Da ist auch kein ECC Speicher in meinem Desktop.

Ich habe jetzt per mc schon fast alle VM's auf die ESXi 6 TB Platte gesichert. Das geht ja super schnell

Mit den Fehlern von der Konsole kann ich auf jeden Fall nix anfangen...

 

[AliManali]

Hi

Ich habe jetzt die SSD nochmals komplett gesichert, den Pool zerstört, und ein neues ZFS Volume erstellt. Dann alle VM's wieder auf die SSD kopiert. Jetzt ist der Fehler an der Konsole weg.

Leider hatte ich den NFS Server noch auf aus, als ich den Pool erstellt hatte. Wenn ich jetzt einen neuen Pool erstelle, dann kann ich unter ZFS Filesystems NFS aktivieren. Aber bei meinem bestehenden Pool ist das Feld inaktiv. (siehe Screenshots)

Wie kriege ich jetzt bei dem bestehenden Pool (EVO_2TB) NFS aktiviert?

 

[gea]

Was bitte ist ein ZFS Volume?
Auf einem Pool kann man auch keine Pools erstellen, sondern Dateisysteme (manche sagen auch Dataset dazu). ZFS wird kompliziert wenn man die Bestandteile nicht sauber benennt .

Ansonsten sollte man den Pool selber nicht freigeben. Ich habe das in napp-it auch gesperrt. Der Pool ist der Ort auf dem man Dateisysteme anlegt bzw Vorgaben für Dateisysteme festlegt, sonst nichts.

Also einfach ein Dateisystem z.B. mit dem Namen nfs anlegen und das per SMB und NFS freigeben (und die Dateien per mc verschieben, dauert etwas da zwischen Dateisystemen ein move=copy+delete ist)

 

[AliManali]

Hi

Ja danke! Ich konnte das Dataset jetzt erstellen und habe das auch erfolgreich per NFS 3 in vSphere gemountet. Dann habe ich mit mc eine Test VM in das Verzeichnis kopiert.

Wenn ich jetzt in vSphere die VM registriere, geht das schon mal. Beim starten des Gasts kommt dann aber:

 (VMDB) -45: Failed to connect to peer process.

Weisst Du gerade, an was das liegt?

 

[AliManali]

Das scheint wohl ein Berechtigungsproblem zu sein. Wenn ich die VM's über SSH (Midnight Commander) einspiele, dann muss ich Snapshots und die vmx Datei mit chmod konfigurieren. Die wichtigsten vm's laufen wieder, allerdings hatte ich da einfach gebastelt, bis die wieder funktionierten. bzw. ich habe dann einfach die benötigten Dateien mit chmod 777 versehen.

Wie würde das von Anfang an richtig gemacht? Das einspielen der Backups via SSH?

 

[gea]

Es gibt da kein richtig.

Es ist halt so, wenn root die Dateien per mc kopiert, dann gehören die root und NFS kann als user nobody nicht darauf zugreifen ohne dass man die Dateirechte ändert. Kann man mit chmod machen oder in napp-it über Dateisysteme > ACL on Folder. Unterhalb des Fensters in dem die Rechte gezeigt werden gibts ein reset ACL mit der Option reset rekursiv auf everyone@=modify.

Man sollte allenfalls wissen, dass sich SMB anders verhält und dass Solaris damit mit nfs4 ACL arbeiten möchte statt mit klassischen Unix Permissions. Diese Variante der ACL verhält sich in etwa wie Windows mit seinen ntfs ACL. Der wesentliche Unterschied zu Unix Permissions liegt in der feineren Ausgestaltung der Rechte und in der Rechtevererbung.

Wenn man beispielsweise die ACL Rechte des nfs Dateisystems auf everyone@ mit Vererbung auf Dateien und Ordner setzt und dann etwas per SMB einkopiert (auch als root) so bleibt everyone erhalten und NFS kann darauf zugreifen.

Setzt man dann allerdings per chmod eine Unix permission z.B. per chmod 777 so wird die Vererbung gelöscht da die alten Unix Permissions das nicht können. Verhindern kann man das mit der ZFS Eigenschaft aclmode=discard.

Anonsten einfach Rechte neu setzen wenn root ein Backup einspielt.
Solaris ACL Model - Oracle Solaris 11.1 Administration: ZFS File Systems
Oracle Solaris 11.1 Information Library (Deutsch) Updated: 2014-02-28

 

[AliManali]

Hi ja danke! Aber ich habe da je länger, je mehr Fragezeichen.

Angenommen mein VM Dataset hat jetzt schon mal die richtigen Rechte (so weit bin ich noch nicht). Kann ich die Daten dann nicht mit samt den Rechten auf meine Backup Platte sichern, bzw. die vms wieder mit den korrekten Rechten zurück spielen? Oder kann ich irgendwie den vm Dataset, bzw. die NFS Freigabe so konfigurieren, dass die Daten gleich die richtigen Rechte haben?

> wenn nein, kann ich da nen Batch File im vm Verzeichnis ausführen, wo irgend was wie "bei Extension x setze Recht y" drin steht?
> gibt es elegantere Lösungen als das kopieren per mc?

 

[gea]

> gibt es elegantere Lösungen als das kopieren per mc?

Die eleganteste Lösung ist praktisch immer die einfachste Lösung.

Wenn napp-it ein Dateisystem anlegt und per NFS freigibt passt ja alles. ESXi kann sich darauf austoben und man kann mit einem beliebigen Verfahren wie cp, mc, rsync, SMB oder Replikation die Daten wegsichern. Das Problem tritt ja erst auf wenn root neue Daten zurückkopiert. Die gehören root und man muss ESXi erlauben darauf zuzugreifen. Kommt selten vor, man muss das eh manuell machen und ein ACL reset ist trivial per napp-it möglich.

Man könnte jetzt zwar die Daten mit Rechten wegkopieren und zurücksichern, z.B. rsync kann das - macht alles aber eher komplizierter als eleganter.

Besser wäre es nur SMB zu benutzen. Per default ist ja ACL mit Vererbung mit everyone@=modify aktiviert. Wenn man dann nur per SMB was zurückkopiert kann ESXi darauf zugreifen. Außerdem kann man mit SMB und Windows vorherige Version auch auf die ZFS Snaps zugreifen und die Snaps sind ja die wichtigste und erste Sicherung der Daten. Restore von Extern ist nur für den Disasterfall (Rechner abgebrannt, Pool kaputt/restore, Server geklaut). Ansonst stellt man eine VM aus einem Snap wieder her entweder per zurücksetzen auf eine Vorversion, per ZFS Clone oder Copy aus dem Snap.

Praktisch jeder macht externes Backup/Restore mit ZFS Replikation. Das hält zwei Dateisysteme mit allen Eigenschaften syncron, nimmt offene Dateien mit und kann selbst bei einem High-Load Petabyte Server die Dateisysteme auch übers Netz mit einer Minute Versatz syncron halten.

Wenn man aber aus dem replizierten Dateisystem nur einzelne Dateien zurückkopiert und nicht das Dateisystem wiederherstellt, muss man die Rechte dennoch wieder beachten.

 

[AliManali]

Läuft so weit mal. Als nächstes steht dann das sichere management Netz an.

Super Coni! tyvm