[Sammelthread] ZFS Stammtisch

Insgesamt bevorzuge ich dennoch unter Solarish den in ZFS eingebauten SMB Server.
Zum Vergrößern anklicken....
Zumindest im Kontext von macOS kann ich diese Aussage nicht nachvollziehen.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich habe hier eine heterogene Mac/Windows Active Directory Umgebung mit mehreren Hundert Usern, ca 60% Macusern mit mehreren Storage und Backupsystemen je in der Größenordnung 20-150 TB. Alle "offiziellen" Daten liegen auf zentralem ZFS Storage, gesichert mit mehreren Backups (ZFS Replikation) und Snaps.

Lokal, meist auf Macbooks liegen Daten-Kopien oder private Daten.
Time Machine Backup des lokalen Rechners auf einen zentralen SMB Server ist nicht gefordert (machen die User meist auf eine lokale USB Platte - wenn überhaupt). Wenn das mal essentiell werden sollte, würde ich über SAMBA nachdenken (oder iSCSI nehmen oder einen OSX Server virtualisieren)
 
OK, verstehe.

TimeMachine sehe ich eher als ein netter Nebeneffekt. Wichtiger finde ich z.B. folgendes:
"The module enables alternate data streams (ADS) [...] Having shares with ADS support enabled for OS X client is worthwhile because it resembles the behaviour of Apple's own SMB server implementation and it avoids certain severe performance degradations caused by Samba's case sensitivity semantics."
vfs_fruit

Dabei muss man wohl folgendes beachten:
"Be careful when mixing shares with and without vfs_fruit. OS X clients negotiate SMB2 AAPL protocol extensions on the first tcon, so mixing shares with and without fruit will globally disable AAPL if the first tcon is without fruit."

Bei so Fertig-Lösung wie FreeNAS und OMV würde ich dann erwarten, dass bei offizieller Unterstützung dies verhindert wird oder es einen Warnhinweis gibt.
 
gea schrieb:
ZFS vCluster

Ich bin gerade dabei meine Z-Raid ZFS Cluster in a Box Lösung fertig zu entwickeln.

Die herkömmliche Lösung ist ein Cluster in a Box bei der sich zwei Server einen gemeinsamen Pool von Multipath SAS Platten teilen. Von SuperMicro gibt es dazu Gehäuse für zwei Mainboards und multipath SAS Platten. Ein Server greift auf die Platten zu und gibt Dienste wie NFS oder SMB frei. Zur Wartung oder im Fehlerfall kann man auf den zweiten Server umschalten der dann die Platten/den Pool übernimmt und die Dienste bereitstellt. Eine gängige Software dazu ist RSF-1 von high-availability.

Diese Lösung ist üblicherweise sehr teuer und sehr kompliziert. Sie erlaubt aber hochverfügbare Speicherlösungen bei bestmöglicher Performance. Meine Lösung basiert auf dem gleichen Konzept, virtualisiert aber den Cluster unter ESXi (Lizenz egal) und nutzt die Möglichkeiten von ESXi RAW Platten zwischen VMs zu sharen. Damit geht diese Lösung auch mit Sata Platten. Auch genügt ein Server statt der vorherigen zwei.

Setup siehe http://www.napp-it.org/doc/downloads/z-raid.pdf

Wer`s testen möchte, es ist als Preview in der 18.02pre free (freier Download)


Anhang anzeigen 449165
Zum Vergrößern anklicken....


vCluster Beta2 ist fertig (napp-it 18.12g dev)

Current state:
Manueller Failover geht mit NFS und SMB
Mit SMB werden angemeldete lokale User und AD User beim Failover unterstützt.

Todo
auto-failover (on tests)

vCluster kommt in napp-it Pro (Jan 2019)
 
Spannend! Muss aber mal gucken, ob ich dafür eine Testumgebung aufgesetzt bekomme.
 
Falls ich von meinem liebgewonnenen Solaris 11.x weg gehe, weil mein HBA (9305-24i) einfach nicht unterstützt wird - welches Solarish nimmt man denn jetzt am besten als Basis (insb. als Unterbau für Nappit)?

Illumos? Wenn ich das richtig mitbekommen habe, ist OmniOS doch auch auf dem Weg der Einstellung, oder?

Oder ist FreeBSD gleich gut geeignet, dann ggf. als Nas4Free bzw. freeNAS? Ich hätte an der Stelle schon wieder gern ein minimalistisches System, aber mit dem Komfort von Comstar, SMB/NFS usw. als ZFS-Eigenschaften bzw. aus einer Oberfläche...
 
Zuletzt bearbeitet:
Ich würde jetzt nicht das OS nach der Hardware aussuchen sondern umgekehrt.

Illumos (der freie Solaris Fork) unterstützt die 9305 jedenfalls. Die gängigsten Illumos Distributionen sind u.a. Delphix, NexentaStor, OmniOS, OpenIndiana und SmartOS (gehört Samsung). Kommerziellen Support gibt es bei Nexenta und früher bei OmniTi für OmniOS. OmniTi hat das aber eingestellt. Seitdem gibt es OmniOS CE (community edition) inzwischen mit der 4. Folgeversion (aktuell 151028 stable, Nov 2018). Die bieten sogar wieder kommerziellen Support so wie früher OmniTi. Hinter OmniOS ce stehen im wesentlichen eine schweizerische und eine englische Firma mit Hosting der Infrastruktur an der ETH Zürich. also ein europäischen Projekt (Brexit naja lassen wir UK dabei)

OmniOS Community Edition

Mit Solaris und der 9305 gäbe es noch die Version ESXi All-In-One.
ESXi sollte die unterstützen und kann die angeschlosenen Platten per RDM weiterreichen. Das nutze ich auch gerade bei meinem ZFS vCluster.
 
Zuletzt bearbeitet:
Vielleicht probiere ich das mal. Eigentlich läuft meine Kiste ja tadellos.

Aber nun wollte ich meinen Mainserver auf all-Flash umstellen und mit 16+ SSDs an dem alten H200 hab ich irgendwie Sorgen, dass der mit dem Expander bremst. Mit dem 9305-24i könnte ich halt alle Geräte ohne Expander direkt an den HBA hängen, der auch bei der SSD-Unterstützung weiter vorne ist als der alte Dell.

Mit RDM hab ich damals (vor 2 Jahren) mal Daten verloren... das war aber SATA, ZoL und auch bei der sonstigen Hardware nicht wirklich vergleichbar - hab aber trotzdem Bauchschmerzen. ;)
 
Mit einem SAS Controller unterstützt ESXi direkt physical Raw Disk Mapping (VM Eigenschaften > Disk hinzufügen > RAW disk). Lediglich Console Hacking via Sata Controller ist problematisch.
 
Ich bin immer noch am benchen und hab mir dafür die nappit gui von filebench um ein Feld zur Angabe eines relativen Pfades erweitert. Vielleicht kann das ja jemand gebrauchen:

/var/web-gui/data/napp-it/zfsos/06_Pools/20_Benchmark=-lin/02_filebench/action.pl
Code: 
use strict;         # check for proper code

###############
sub my_action {
###############     build actions according to this template

  my ($out,$var);  # declare all your variables as local or you will get errors

  # menue actions
  ###############


  ###############################################
  # part 1: do function, if question is answered
  ##############################################
  #&print_hash(%in);


   # header
    print "<script language='javascript'>document.getElementById('hl').innerHTML='FileBench'</script>\n";

  ##############################
  # or create a form to ask user
  ##############################
      my $pools=$zfs{'datapools'};
      $pools=~s/\t/,/g;

       # last value
       my $r=$pools;
       my @p=split(/,/,$r);
       $r="";
       foreach my $p (@p) {
              if (-f "/$p/filebench.log") {
                  $t=`cat /$p/filebench.log`;
                  if ($t=~/IO Summary/) { $r.="$t\n"; }
              }
       }
       if ($r =~/IO Summary/s) {
              $r=~s/,/\t/g; $r=~s/  +/ /g;
              print &list2table($r);
              print "<br><br>";
       }



      # sete executable on new setups
      &exe("usr/bin/chmod 755 /var/web-gui/data/tools/filebench/filebench");

print <<EoF;
<b>Filebench:</b><hr>
For special longrunning benchmarks run /var/web-gui/data/tools/filebench/filebench manually at console.
You should also disable Monitoring (Top-Menu Mon).<br>If you want to avoid cache effects, set cache to none in menu pools.
<br>

EoF

       &ask('begin');
       &ask('select_pool','Test Pool',$pools,$in{'select_pool'});
       &ask('value_relpath','Relative path',$in{'value_relpath'});

       #get workload
       my @d=&get_dir("/var/web-gui/data/tools/filebench/workloads/");
       $var="";
       foreach my $d (@d) {
         if ($d=~/\.f$/) {  $var.="$d,";}
       }
       $var=~s/,+$//;

       if ($in{'select_load'} eq "") { $in{'select_load'}='fileserver.f'; }

       &ask('select_load','Workload',$var,$in{'select_load'});
       &ask('select_run','Run in s','30,60,90,120',$in{'select_run'});
       &ask('end');

    if (($in{'answered'}) && ($in{'submit_ok'} eq "submit")) {      # question was answered
       &my_function;       # do it
    }

} #/ my_action



######################
sub my_function {
#######################

    #no log
    &log_end;

    my $r=`ps axw`;
    if ($r=~/filebench/) {
      print "<br><br>a filebench is running, please wait for results.";
      return;
    }

    # create profile
    `cp /var/web-gui/data/tools/filebench/workloads/$in{'select_load'} /tmp/filebench.prof`;

    # header
    print "<script language='javascript'>document.getElementById('hl').innerHTML='FileBench result $in{'select_pool'}'</script>\n";

    # opt delete /pool/filebench.tst
    if (-d "/$in{'select_pool'}/filebench.tst") {
      `sudo rm -r /$in{'select_pool'}/filebench.tst > /dev/null`;
    }

    # create testfolder
    mkdir ("/$in{'select_pool'}/$in{'value_relpath'}filebench.tst");

    # add dir
    `echo \'set \$dir=/$in{'select_pool'}/$in{'value_relpath'}filebench.tst\' >> /tmp/filebench.prof`;
    # add run
    `echo \'run $in{'select_run'}\' >> /tmp/filebench.prof`;

    print "<br><br><b>Results for $in{'select_load'}, please wait $in{'select_run'} s until restarting tests..</b><hr><pre>start filebench..\n";

    $r= `sudo /var/web-gui/data/tools/filebench/filebench -f /tmp/filebench.prof`;
    my $t=$r;
    $t=~s/IO Summary: /<br><br>IO Summary: <hr>/s;

    print "$t<br>ok.</pre>";

    # save last result
    $r=~s/.*IO Summary: /Last IO Summary for pool $in{'select_pool'}, $in{'select_load'}, $in{'select_run'} s:/s;
    $r=~s/\n.*//s;
    $r=~s/\n/ /gs;
    $r=~s/:*Shutting.*//s;


    `sudo touch /$in{'select_pool'}/filebench.log`; `sudo chmod 666 /$in{'select_pool'}/filebench.log`;
    `echo \'$r\' > /$in{'select_pool'}/filebench.log`;

    #del testfiles
    `sudo rm -r /$in{'select_pool'}/$in{'value_relpath'}filebench.tst 2>&1 > /dev/null`;

    return;
}


###############################################
#end of my script, do not delete the line below
1;

Ist etwas krude, der Pfad muss entweder leer sein um direkt im Pool zu benchen oder ein relativer Pfad sein, der auf / endet. Es gibt keine Validierungen auf dem Feld. Sieht dann so aus:
Screenshot.PNG
 
Fein, freut mch immer wenn jemand selber Anpassungen vornehmen kann.
 
Ich bin heute über Folgendes gestolpert:

Windows legt in meinen SMB-Freigaben (OmniOS mit napp-it) munter die berühmte Thumbs.db an. Mit dem Nebeneffekt, dass sich das Änderungsdatum des darüber liegenden Ordners auf den jeweiligen Zeitpunkt ändert. Das möchte ich gerne unterbinden, aber am liebsten serverseitig. Bei meinem alten QNAP hatte ich das Problem nicht, aber dort läuft auch kein Solaris.

Hab im Netz etwas über "veto files" gefunden. Könnte das die Lösung sein und gibt es so etwas auch bei Solaris SMB?
 
Das ist eine SAMBA Einstellung.
Der kernelbasierte SMB Server von Solaris kennt das nicht. (Dazu müsste man SAMBA instalieren und nutzen).

Alternative: Clientseitig abschalten
 
Nicht den Windows Explorer nutzen, nutze z.B. den FreeCommander XE da werden keine Thumbs.db bei den OmniOS Freigaben angelegt.
 
In Ordnung, nur für dieses Feature werde ich den Solaris SMB-Server nicht gegen SAMBA eintauschen. ;)

Ich wusste gar nicht, dass Thumbs.db seit Vista ohnehin nur noch für Netwerkfreigaben genutzt wird. Dann ist das Deaktivieren ja halb so schlimm.
 
Ich habe es eben nochmal auf einem Test-Dataset probiert, ZFS-Snaps durch Previous version wiederherzustellen. Das war problemlos möglich.
Ich gehe daher davon aus, da ich die Pools schon zweimal nach einer Napp-it-Neuinstallation importiert hatte (der ESXI-Stick mochte es nicht, auch noch einen Datastore für Napp-it drauf zu haben und hat den innerhalb einer Woche reproduzierbar zerschossen), gehe ich davon aus, dass dabei irgendwo was schief wiederhergestellt wurde.
Ich werde die Datasets neu anlegen und die Daten mit ZFS send rüberschieben.

Edit: War zumindest für "flache Shares" Error in Layer 8, Vorherige Versionen von Dateien werden nur angezeigt, wenn sich tatsächlich etwas geändert hat.
 
Zuletzt bearbeitet:
TRIM bei SSDs:

Ich verwende je eine Samsung SSD850pro (SATA) und 960pro (NVMe), die an meine Napp-it VM (Omnios) durchgereicht sind und jeweils als Basic-ZFS-Pool als Ablage für meine VMs dienen. Auf beiden SSDs habe ich nach jeweils wenigen Wochen Betrieb unterirdische Schreibleistungen. Nach anfänglich mehreren Hundert MB/s (vermutlich RAM Cache) bricht die Schreibrate nach einigen Sekunden auf 20-30 MB/s ein.
Secure-Erase löst das Problem wieder für einige Wochen, doch dann geht das Problem von Neuem los. Regelmäßig einen Secure-Erase zu machen ist aber administrativ nicht wirklich eine Option.
Nach dem, was ich hier lesen konnte gehe ich mal davon aus, dass das mit dem fehlenden Trim-Support zusammenhängt. Wie geht ihr mir der Thematik um? An einigen Stellen wurden Enterprise-Grade SSDs empfohlen, aber ist das Problem damit gelöst oder tritt der Effekt dann anstatt nach 4 Wochen erst nach 8 Wochen ein? Gibt es ggf. andere Möglichkeiten, wie ich das Problem beseitigen oder zumindest mildern kann?
 
Ist denn sync write aktiviert?
Damit bricht die Schreibleistung auch bei SSD stark ein - zumindest bei Desktop SSD.

Dafür gibt es zwei Auswege:
Die erste ist Overprovisioning. Das ist auch eine der Maßnahmen bei Enterprise SSDs. Dabei wird ein Teil der SSD nicht genutzt und steht für das SSD interne Garbage Collection zur Verfügung. Dazu erstellt man z.B. mit hdat2 bei einer neuen oder secure gelöschten SSD eine HPA/Host protected area (10-20% der Kapazität.).

Der zweite Weg ist die kleinen random writes die das Problem sind von der SSD (oder Platten) fernzuhalten. Dazu nutzt man eine Intel Optane (ab 800p) als Slog (ca 20GB) und den Rest optional für VMs, ESXi oder Slog.
 
Tag zusammen,

ich hab da mal ein Problem.
Ausgangssituation:
Napp-it AiO 026 (Solaris) über ESXi 6.7 virtualisiert.
Pool mit NVMe fürs Caching und als Slog (aus Datenspeichern des Hosts durchgereicht) und nem RAID1 über HBA (DELL H310 auf LSI 9211-8i IT-Mode geflasht) im PCI-Passtrough.
Problem:
Nach Reboot des Hostsystems (die Napp-it VM war vorher ordnungsgemäß heruntergefahren und das Hostsystem sogar im Wartungsmodus) erkennt Solaris den HBA als "faulty".
Hab das Teil, auch mit den Platten die daran hängen bereits in einem anderen System getestet. Beides wird problemlos erkannt. Übrigens auch auf dem Hostsystem. Sobald ich es aber an die Napp-it VM durchreiche geht nix.
Das macht die Fehlersuche für mich jetzt unheimlich schwierig. Aber vielleicht hat ja jemand eine Lösung. Ich persönlich kenne mich mit ZFS und Solaris auch fast gar nicht aus. Alles was ich damit mache ist Napp-it betreiben.

Ich bin für jede Hilfe, Idee oder Eingebung dankbar, am Optimalsten natürlich mit einer Möglichkeit den Pool zu erhalten (da sind keine relevanten Daten drauf, aber wer verliert schon gerne seine Mediensammlung?)
 
In Solaris läuft ein Fehlermanagement Dienst fmd im Hintergrund. Der sorgt z.B. für ein automatisches Disk Replace mit einem Hotspare. Erkennt der einen kritischen Hardwarefehler so wird das entsprechende Device geblockt damit keine weiteren Probleme entstehen können.

Wenn man der Ansicht ist das es ein Fehlalarm war oder das Problem beseitigt wurde, kann man den Fehler löschen.

Siehe
napp-it Menü System > Faults > Repair oder
https://docs.oracle.com/cd/E53394_01/html/E54784/clearalert.html

Der Pool selber ist unabhängig und nicht in Gefahr wenn der HBA geblockt wird. Ganz im Gegenteil. Wenn Solaris meint der HBA sei defekt, dient das der Sicherheit des Pools.
 
Herzlichen Dank, läuft alles wieder.
Anscheinend lief da irgendwas in der Kommunikation zwischen Host und VM schief.
Das heißt er suchte nach nem Controller, der gar nicht da war. JEdenfalls nicht an dem PCIe-Slot, an dem er suchte.
Sachen gibts...
 
gea schrieb:
Ist denn sync write aktiviert?
Damit bricht die Schreibleistung auch bei SSD stark ein - zumindest bei Desktop SSD.

Dafür gibt es zwei Auswege:
Die erste ist Overprovisioning. Das ist auch eine der Maßnahmen bei Enterprise SSDs. Dabei wird ein Teil der SSD nicht genutzt und steht für das SSD interne Garbage Collection zur Verfügung. Dazu erstellt man z.B. mit hdat2 bei einer neuen oder secure gelöschten SSD eine HPA/Host protected area (10-20% der Kapazität.).

Der zweite Weg ist die kleinen random writes die das Problem sind von der SSD (oder Platten) fernzuhalten. Dazu nutzt man eine Intel Optane (ab 800p) als Slog (ca 20GB) und den Rest optional für VMs, ESXi oder Slog.
Zum Vergrößern anklicken....

Da mich das Thema auch interessiert; bedeutet dies, dass ZFS mit TRIM nichts anfangen kann und man nur auf Over Provisioning und die Garbage Collection setzen kann?

In einem kleinen 24/7-NAS möchte ich schon vorhandene Samsung SM863a (960 GB) verwenden, die sich für SATA-SSDs recht gut unter Dauerlast schlagen. Im großen sind Optane 905P/480 GB, aber beim NAS habe ich leider keinerlei freie PCIe Lanes mehr (S. 1151/C236), weder CPU noch PCH.
 
JohnnyBGoode schrieb:
Da mich das Thema auch interessiert; bedeutet dies, dass ZFS mit TRIM nichts anfangen kann und man nur auf Over Provisioning und die Garbage Collection setzen kann?
Zum Vergrößern anklicken....
vereinfacht gesagt: ja. ZoL und evtl FreeBSD-ZFS haben zwischenzeitlich eine TRIM/unmap Mechanik eingebaut, illumos-ZFS hat das aber noch nicht

SM863a sind enterprise SSDs, damit sollte das also trotzdem gut gehen ...?

@gea: Kann es sein, dass die "mass delete snapshots" mit Größe 0 (immer noch nicht wieder) richtig arbeitet? Hat mir gerade alle esxi hot snaps gelöscht ...
 
Bereits OpenSolaris hatte Trim für Einzelplatten. Für Raid ist es in Free-BSD, Illumos-Nexenta und Solaris. Illumos-OmniOS und ZoL sind dabei es zu übernehmen. Ich seh das aber so dass Trim umso mehr bringt je schlechter die SSD und auch nur dann wenn man keine dauerhafte Schreiblast hat. Dann kann es sogar ungünstig sein. Für professionelles Storage braucht man daher vor allem gute SSD und weniger Trim. Mit Enterprise SSDs wie Samsung SM oder Intel DC ist das nur noch ein ein geringes Thema, mit Optane gar keins mehr. Bei Dektop SSDs kann man die konstante Schreibleistung mit Overprovisioning verbessern.

ps
Snap mass delete für size=0
sollte mit neuester 18.02 free und 18.12 dev wieder gehen.
 
gea schrieb:
Snap mass delete für size=0
sollte mit neuester 18.02 free und 18.12 dev wieder gehen.
Zum Vergrößern anklicken....
Mit 18.02c free geht es wohl noch nicht: napp-it will da immer nur die ESXi hotsnaps löschen, nicht die sonstigen snaps mit used = 0 (zB manuelle oder durch znapzned erstellte).

Code: 
please wait...
would delete vmstore/VMstorage@daily-1542533994_2018.11.24.23.01.36
1 snapshots would be deleted
go back and unselect simulation to delete them

Die ist aber nicht leer:
Code: 
 vmstore/VMstorage  	   	 vmstore/VMstorage@daily-1542533994_2018.11.24.23.01.36  	 Sat Nov 24 23:02 2018  	 4.25G  	 -  	 85.7G  	 off  	 0  	 -  	 destroy
 
In der Tat.
da ist bei letzten Tests ein Fehler drin geblieben (habe ich im Upload bereits behoben)

In der Datei "/var/web-gui/data/napp-it/zfsos/08_Snaps and clones/03_Mass delete/action.pl" in Zeile 161
muss es heißen (statt eq "0")

if ($r ne "0") {
 
Danke gea. Die "false positives" sind weg. Nur "fremde" snapshots mit Größe 0 löscht er nicht. Da weiss ich aber auch nicht ob (1) das per Design ist und/oder (2) das früher schon so war. Ich kann jedenfalls damit leben ...
 
Ein ZFS Snap ist ein ZFS Snap. In Napp-it kann man lediglich eigene Replikationssnaps (aufgrund des _repli im Namen) überspringen. Eventuell sind die Snaps aber per zfs hold geblockt. Die kann man erst nach einem zfs release löschen.

Im napp-it Snapshot Menü kann man sich die aber anzeigen lassen (Sortieroption auf holded setzen)
 
Zuletzt bearbeitet:
Benutzt hier jemand OmniOS CE mit DHCP-Reservierung per MAC-Adresse an einer Fritzbox?

Ich habe das Problem, dass das OmniOS den Hostnamen nicht im DHCP/DNS der Fritzbox registriert und die OmniOS-Maschine nicht über ihren vollen Namen anpingbar ist. In der Fritzbox erscheint das Gerät als PC-192-168-178-20. Der DNS auf der Fritzbox löst von einem Windows-PC aus "speicher.fritz.box" nicht auf, auch dann nicht, wenn ich in der Fritzbox den Namen des Geräts mit "Speicher" überschreibe. Über den Hostnamen allein (Speicher) funktioniert das aber, warum?
Früher ging das mal! Ich habe leider OmniOS und das FritzOS gleichzeitig aktualisiert und kann somit nicht sagen, wer jetzt Schuld hat.

Interessanterweise habe ich bemerkt, wenn ich das Gerät aus der Fritzbox lösche und danach manuell anhand der MAC-Adresse im DHCP mit der IP 192.168.178.20 und dem Namen "Speicher" reserviere, funktioniert die Namensauflösung des FQDN, solange das OmniOS keinen DHCP-Request an die Fritzbox schickt. Sobald das passiert ist, geht's wieder nicht.

Ich habe auch probiert, das Anfordern des Hostnames beim DHCP-Request zu aktivieren, aber ich komme damit nicht klar. Siehe auch mein Beitrag https://www.hardwareluxx.de/community/f211/omnios-dns-problem-mit-fritzbox-1214120.html
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
880
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
592
sandreas
S
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
532
gea
G
G
[Übersicht] napp-it cs, Web-GUI für fast jeden ZFS Server oder Servergruppen
4 5 6
Antworten
158
Aufrufe
9K
gea
G
AliManali
*erledigt* Perc H310 flashen
Antworten
2
Aufrufe
309
AliManali
AliManali
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