[Sammelthread] ZFS Stammtisch

In einem Pool kann man keine 3TB durch eine 2 TB ersetzen. Was geht ist eine Platte aus dem Mirror entfernen (Pool degraded aber funktionsfähig). Dann die SSD rein und darauf den neuen Pool anlegen und Dateisysteme darauf replizieren. Anschließend den degraded Mirrorpart auch herausnehmen/ Pool export oder destroy, die zweite SSD dafür rein und einen Mirror mit der ersten SSD erstellen (napp-it Disk > Add).
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich habe noch den Perc mit den SSDs eingebaut und versuche es über den datamover. Sollte doch auch so funktionieren, oder?

Wenn das adäquat läuft, kann ich dann den alten Pool zerstören, die Platten sowie den zweiten Controller entfernen und die SSDs an die freien Ports vom ersten Controller hängen?

Danke für die Unterstützung!
 
Zuletzt bearbeitet:
hallo zusammen,
kurze frage zum ZFS Filesystem. Ich möchte FreeNAS nutzen und will dazu passende Hardware kaufen. Ich hab mittlerweile gelernt, dass man nicht genug RAM haben kann und dieser ECC sein sollte. Nun aber zur CPU, das wird evtl ein INTEL Xeon, nur weiss ich noch nicht welcher es werden soll.

Generelle Frage:
Besser eine CPU mit vielen Kernen oder lieber höheren Takt? Also lieber 10 Kerne mit 2,3GHz oder besser 6 Kerne mit 3,4Ghz?
 
Ich habe noch den Perc mit den SSDs eingebaut und versuche es über den datamover. Sollte doch auch so funktionieren, oder?

Wenn das adäquat läuft, kann ich dann den alten Pool zerstören, die Platten sowie den zweiten Controller entfernen und die SSDs an die freien Ports vom ersten Controller hängen?

Danke für die Unterstützung!

Um Daten von ZFS zu ZFS zu kopieren ist Replication das Mittel der Wahl da dies viele ZFS Eigenschaften erhält, ACL kann (gut Datamover kann das auch) und unerreicht schnell ist (Data Streaming, kein Filecopy)

Einfach einen Replikationsjob anlegen und starten. Ist viel schneller konfiguriert als Datamover
 
Ich habe zwei Solaris 11.3 Server, die sich mit Napp-IT händisch gesteuert replizieren. Das funzt soweit seit 3 Jahren ohne Auffälligkeiten.
Die Server nutzen jeweils Mallanox Connect X2 10g NICS und eine MTU von 9000. Die Clients saugen im Schnitt mit 600 mb/s , da der Pool nicht der schnellste ist.
Aus dem RAM Cache dann auch mal deutlich mehr.
Allerdings replizieren sich die Server, warum auch immer, seit kurzem nur noch sehr langsam., ( Siehe Bild )
Anfangs dachte ich, das käme durch die vermehrt zu replizierenden keinen Dateien, die von DaVinci Resolve erstellt werden. Ein testweise erstelltes ISO mit 15Gb brachte aber die gleichen Ergebnisse.
Gerade wo ich jetzt schreibe, kommt mir die Idee, dass ich den Pool, auf den repliziert wird, mal auf Geschwindigkeit testen könnte....

Sonst jemand eine Idee ?

Danke

_xymos.
 

Anhänge

  • Replikation.png
    Replikation.png
    13,5 KB · Aufrufe: 273
Ich würde erst mal schauen, ob Netzwerk und Pool vernünftige Werte liefern
- iperf Test
- Pool > Benchmark (testet sequentiell und random mit/ohne sync)

Zur Fehlersuche kann man auch prüfen ob der Pool fast voll ist (langsam) oder ob es Auffälligkeiten in den Logs gibt, die auf eine schwache Platte hinweisen (oder iostat während der Replikation beobachten. Alle Platte sollten gleiche wait% oder busy% haben). Ist eine Platte deutlich schlechter als die anderen, tauschen bzw mit einem low level tool Herstellertool testen.
 
Ich benötige nochmal Hilfe.

Habe gestern einen Autoscrub Job gestartet und heute spätnachmittags wurde die erste Platte als removed im Pool angezeigt. Daraufhin habe ich bei allen Drives, welche online waren, einen Smarttest durchgeführt, welcher auch in Ordnung war. Nach einiger Zeit meldete sich die erste Platte als online zurück und ein resilvering startete. Jetzt wird auf einmal die zweite Platte als removed angezeigt, welche vorher beim Smarttest einwandfrei war. Die erste removed Platte hat jetzt auch einwandfreie Smartwerte...

napp-it schmeisst die ganze Zeit "SYNCHRONIZE CACHE command failed" aus.

So sieht die Smart-Übersicht nun aus:

Bildschirmfoto 2020-02-03 um 20.40.14.png
 
Wenn mehrere Platten kommen und gehen würde ich den Rechner herunterfahren und die Steckkontakte (Sata, SAS, Power, Steckkarten) auf festen Sitz prüfen.
 
Habe alle VMs runtergefahren und napp-it neugestartet, seitdem bleiben die Platten. Habe allerdings auch omniOS upgedatet.

Heute habe ich mich mit den ACLs beschäftigt. Ich habe eine ZFS-Filesystem, wo reset-acl absolut nicht funktioniert. Habe rumgetestet und möchte nun die ACLs zurücksetzen. Aber es wird nur user:root geschrieben, obwohl ich modify.recursiv wähle. Das Filesystem ist wirklich wichtig, wie kann ich es beheben? Habe schon jeden Ordner einzeln gemacht, aber es geht immer wieder in diesen Zustand zurück.

Bildschirmfoto 2020-02-04 um 22.57.31.png


Wie lautet der cmd-Befehl, dann könte man mal schauen was schief läuft...
 
Napp-it führt folgende Befehle bei recursivem everyone=modify (+ root=full) aus

Code:
/bin/chmod -r A=user:root:full_set:file_inherit/dir_inherit:allow Pfad
/bin/chmod -r A1+everyone@:modify_set:file_inherit/dir_inherit:allow Pfad


Alternativ:
Von Windows per SMB als root anmelden und von da Rechte setzen oder rücksetzen.
Lediglich deny Rechte darf man von Windows nicht setzen, da Windows zuerst deny dann allow beachtet, während Solaris wie bei einer Firewall die Rechte in ihrer Reihenfolge durchgeht und beachtet.
 
Ich habe nun auf das aktuelle OmniOS032 upgedatet und nun steht folgendes bei den Pools:

Bildschirmfoto 2020-02-06 um 20.38.17.png


Kann ich "zpool upgrade" bedenkenlos durchführen?
 
Sofern Du den Pool nicht in älteren Versionen verwenden willst: ja. Willst du mit der älteren Version kompatibel bleiben: nicht machen.

Es werden bei OpenZFS permanent Features nachgerüstet/erweitert. Die Meldung sagt nur, dass das aktuelle OS halt nicht alle Features nutzt, weil der Pool eine ältere Version hat.
Der Pool braucht man eigentlich aus meiner Sicht nur upgraden, wenn man diese Features auch nutzen will.
 
Ea stehen vor allem folgende Features nach einem Pool Upgrade
unter dem neuen OmniOS zur Verfügung:

- ZFS Verschlüssellung
- special vdevs
 
Seit dem Upgrade auf OmniOS v11 r151032l funktioniert TLS Mail leider nicht mehr.

Bildschirmfoto 2020-02-08 um 11.42.43.png

Wenn ich per CPAN versuche, IO::Socket::SSL nach zu installieren, kommt folgender Fehler:

Bildschirmfoto 2020-02-08 um 11.44.06.png

Passiert bei napp-it 18.12 und 19.10.

Perl ist folgende Version installiert:

Bildschirmfoto 2020-02-08 um 11.45.19.png
 
Hallo zusammen,

@gea

Eine Frage zu dem smb lock/unlock Feature aus deinem Napp-it.

Kann man es auch so einsetzten, dass ich ein share von meinem PC in Solaris/Napp-it mounte inkl. einer definierten Datei (ohne inhalt, oder zumindest ohne Kennwort) und sobald Solaris/Napp-it diese Datei nicht mehr findet (z.B herunterfahren des PC) verschlüsselte Filesysteme locked ?

Also ohne auto unlock und mit einer Datei die das Kennwort nicht enthält.



Gruß Lucky
 
Seit dem Upgrade auf OmniOS v11 r151032l funktioniert TLS Mail leider nicht mehr.

TLS Unterstützung muss das OS bereitstellen, hat mit der napp-it Version nichts zu tun. TLS/SSL ist aber was kritisches da ständig neue Versionen von OpenSSL kommen und es nann gerne zu Inkompatibilitäten kommt bis die Perl Module nachziehen. Ich hatte nach Updates (besonders bei Versionen vor 028) auf aktuelles OmniOS auch schonmal Probleme. Ich habe dann 151032 neu intstalliert. Da hatte ich bisher noch kein Problem. Es gibt aber ein OpenSSL Update mit 151032h, https://github.com/omniosorg/omnios-build/blob/r151032/doc/ReleaseNotes.md - ich muss das aber selbst noch testen.

update:
Bei einem Update von einem älteren OmniOS mit Compiler gcc48 kann es passieren, dass kein Compiler mehr installiert ist, da gcc48 nicht mehr unterstützt wird. Dann einen neuen Compiler wie gcc7 installieren (pkg install gcc7) oder wget napp-it installer nochmal laufen lassen.

Beitrag automatisch zusammengeführt:

Hallo zusammen,

@gea

Eine Frage zu dem smb lock/unlock Feature aus deinem Napp-it.

Kann man es auch so einsetzten, dass ich ein share von meinem PC in Solaris/Napp-it mounte inkl. einer definierten Datei (ohne inhalt, oder zumindest ohne Kennwort) und sobald Solaris/Napp-it diese Datei nicht mehr findet (z.B herunterfahren des PC) verschlüsselte Filesysteme locked ?

Also ohne auto unlock und mit einer Datei die das Kennwort nicht enthält.
Gruß Lucky

Aktuell legt Windows eine Lock/Unlock Steuerdatei auf eine SMB Freigabe um ein Dateisystem zu ent/verschlüsseln. Damit das wie angesprochen funktionieren könnte, müsste Solaris eine SMB Freigabe von Windows mounten (oder per Ping prüfen) ob Windows noch an ist.

Dafür ist das unlock Feature nicht ausgelegt. Erreichen könnte man sowas mit einem "other Job" und einem Script das bei einem unlocked Dateisystem per Ping prüft ob ein Client noch an ist. Als general use Feature bei einem Multiuser Filer nicht so ein Thema.

ps
Das SMB Lock/Unlock/Autolock Feature wird gerade überarbeitet und kommt dann auch für OmniOS (nächste Pro Version 20.x) zusammen mit webbasierten Keys, optional gesplittet auf zwei Webserver und HA Keyserver für größere Installationen.
 
Zuletzt bearbeitet:
Ok.Mit dem Ping habe ich schon probiert mir ein script zu "schreiben".Aber da bin ich nicht wirklich firm.

Bash:
#!/bin/sh
ping 192.168.1.140 ;  echo $?
 
if [ ergebnis aus $?  was 1 ist, bei nicht erreichbarkeit ]
then
    zfs key -u Ironwolf/Backup
else
 "goto" gibt es ja hier nicht, was wäre hier eine möglichkeit ? reapeat, continue ?

Ich stecke jetzt hier fest. Wie bekomme ich den Errorlevel als Variable genutzt für den "if" Punkt + beendigung des Scripts und wie wiederhole ich das Script solte die Bedingung nicht erfüllt werden.
 
Perl wäre einfacher und mächtiger als Shellscript.
Sowas in der Art.

Code:
!#/usr/bin/perl
my ($r,$p);

$r=`zfs get -H -o value keystatus Ironwolf/Backup`;  # unlocked?
chomp($r);

if ($r eq "available") {                             # filesystem unlocked
  $p=`ping 192.168.1.140 1`;       
  chomp($p);

  if (!($p=~/alive/))  {
    `zfs key -u Ironwolf/Backup`;
  }
}
exit;
 
Zuletzt bearbeitet:
napp-it v20.x

Ich habe eine Vorab Version von napp-it 19.12 noncommercial und v20.01 Pro hochgeladen
um die neuen Features von Solaris und OmniOS/ OpenIndiana zu unterstützen.

- ZFS encryption mit web/filebased keys, einen http/https Keyserver mit HA Option,
Keysplit für zwei Speicherorte, automount nach Reboot und User lock/unlock via SMB
http://napp-it.org/doc/downloads/zfs_encryption.pdf

- special vdevs

- trim

- force ashift when adding a vdev

- protection against accidentially adding a basic vdev to a pool

mehr (alle Features from 19.dev)
 
Sehr sehr fein! Muss ich mal die Tage ausprobieren - hab auch einen Anwendungsfall, wo's gar nicht sicher genug sein kann. ;)
 
napp-it v20.x

Ich habe eine Vorab Version von napp-it 19.12 noncommercial und v20.01 Pro hochgeladen
um die neuen Features von Solaris und OmniOS/ OpenIndiana zu unterstützen.

This is cool. Danke gea.

An sich ist ZFS mit napp-it ja recht langweilig. Set and forget. Aber auf Encryption wartete ich schon ein bissl. Für die Backup-Festplatten ist das Ganze im "manuellen" Modus auch gut mit "Key auf und zu" handlebar. Bei festen Shares fürs Heim war das bislang etwas umständlich. Insbesondere nach einem Reboot. Deine Lösung habe ich in der PDF kurz überflogen. Ich denke ich verstehe das Prinzip ... macht Sinn ... ich werde es nach den Winterferien ausprobieren (y)

Und für alle Anderen 8-)

So, wie napp-it gepflegt wird und mit dem OS mit wächst - und in diesem Fall einen großen Schritt nach vorne macht - und so, wie gea hier ständig völlig unaufgeregt und mit profundem Wissen hilft (auch zum wiederholten Male zum selben Thema), kann ich nur noch einmal auf die Home-Lizenz von ihm verweisen. Das Geld ist mehr als gut angelegt und aus meiner Sicht ein probates Dankeschön.

Cheers
 
Das geht ja schnell. Ich habe bereits Rückmeldungen zur neuen Version 20. In dieser Version werte ich nicht nur den Plattenzustand per Smart Tests aus (ok/failed) sondern analysiere einzelne Smart Parameter die man als Anhaltspunkte für künftige Probleme sehen kann. Bei Überschreiten einer Schwelle wird eine "Problem" Meldung in der Plattenübersicht angezeigt. Es kam jetzt sofort die Frage auf, ob die Platten defekt seien.

Nein: Defekt sind sie (noch) nicht.

Ich würde aber sagen, in einem kritischen Produktivsystem würde ich die Platten tauschen, sie können aber auch noch jahrelang halten. At home/Lab könnte man die Meldung eher ignorieren.

Abschalten kann man die Hintergrund Smart Checks im Menü Services > ACC

vgl
 
Zuletzt bearbeitet:
Solltest du das in dein Napp it integrieren können, könnte man damit ja "einfach" ein offsite Backup gezielter Datasets (oder wie auch sonst realiserte Quellen) zu amazon S3 Glacier machen und dank verschlüsselung auch "sicherer".

Sollte es soooo "einfach" sein - ich hab leicht reden, ich muss es ja nicht entwickeln ;)


Aber spannend allemal.
 
Wir haben eine größere minio Installation als Archiv für Veeam. Nicht ganz so Rund wie Ceph, tut aber soweit recht unauffällig seinen Dienst.
 
Ich frickel' gerade mal wieder mit ZFS herum, diesmal mit OmniOS (als VM unter ESXi 6.7U3b) und habe das Problem, dass mir alle meine NVMe SSDs als "removed" angezeigt werden. In der Konsole mit "format" werden sie aber angezeigt - allerdings mit "drive type unknown".

Wie bekomme ich die SSDs nutzbar?
 
Man kann jetzt zwei Sachen machen.
- Platten mit einem CLI Befehl einbinden. Danach haben Sie ein Label und werden normal angezeigt oder
- Napp-it updaten (die aktuelle Version zeigt Platten auch ohne Label)
 
Nappit sollte eigentlich aktuell sein - hab die VM frisch manuell aufgesetzt und nappit per wget installiert...?

Unter FreeNAS kann ich mit den SSDs auch keinen Pool erstellen. Unter Win10 allerdings problemlos (striped) und auch benchen.

Wie mach ich das denn am besten per CLI? Format?
 
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