[Sammelthread] ZFS Stammtisch

apcupsd selber compilieren mit usb Support?

Guter Vorschlag nur hab ich so etwas noch nie gemacht und hab auch keinen Plan wie/was ich da machen muss. Ich bin da :stupid:

Kann das sein, dass bisher alle Server auf OmniOS-Basis keine Shutdown-Software-UPS haben? Wie sichern denn dann die admins diese Server gegen Stromausfälle ab?

Ich hab in der email Liste aus 2016 was bezüglich USB-UPS gefunden und da wurde eine solche Unterstützung nicht realisiert, allerdings funzte da auch noch nicht USB bei Omnios. Mit r151022 ist aber jetzt USB3 Unterstützung dabei.
@gea siehst du eine Möglichkeit NUT als Extension in deinem napp-it umzusetzen?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich habe ein ZFS-RAIDz1 aus 3 HDDs.
Man kann ja ein weites RAIDz1 erstellen und dies zusammenführen - wie geht das nachträglich genau?
Kann ich auch ein RAIDZ1 aus 4 HDDs und/oder größere HDDs zu einem RAIDZ1 aus 3HDDs hinzufügen?
Kann ich auch ein RaidZ2 und ein RAIDz1 zusammenfassen?
 
Dem Pool ein weiteres VDEV hinzufügen.
Ja
Ja, bringt aber nix, da der Redundanzlevel des Pools bei Raidz1 bleibt = 1 beliebige (!!) HDD kann ausfallen!
(Die Wahrscheinlichkeit, daß in einem bereits Degradeten Raidz1 eine weitere HDD ausfällt ist ungleich höher, als daß 2 HDDs im Raidz2 VDEV ausfallen)
 
Zuletzt bearbeitet:
danke euch :)

@Digi-Quick: So viel ich weiß, kann pro vdev eine HDD ausfallen?

@layerbreak: c2t2d0... bei Linux gegen /dev/sdd etc ersetzen?
 
danke euch :)

@Digi-Quick: So viel ich weiß, kann pro vdev eine HDD ausfallen?

@layerbreak: c2t2d0... bei Linux gegen /dev/sdd etc ersetzen?

Bei raidz1 darf maximal 1 HDD gleichzeitig ausfallen, bei raidz2 2, raidz3 3.
# zpool add tank raidz c2t2d0 c2t3d0 c2t4d0
# zpool status tank
pool: tank
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rzpool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
c1t0d0 ONLINE 0 0 0
c1t2d0 ONLINE 0 0 0
c1t3d0 ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
c2t2d0 ONLINE 0 0 0
c2t3d0 ONLINE 0 0 0
c2t4d0 ONLINE 0 0 0
Ganz ehrlich, ich weis jetzt nicht, ob pro pool bei raidz1 eine HDD ausfallen darf oder eine HDD je in raidz1-0 und eine in raidz1-1 :hail:

Bei Linux kenn ich mich überhaupt nicht aus, geh aber davon aus, dass der Befehl so sein sollte:
# zpool add tank raidz1 /dev/sda /dev/sdb /dev/sdc

So nebenbei:
Warum tust du dir nicht gleich ein richtiges Solarish her?
Schau dir
OmniOSce oder
Openindiana mal an.
 
Zuletzt bearbeitet:
Wenn zwei raidz1 zusammengefügt werden, darf meines wissens nach pro raidz1 eine HDD ausfallen.

Warum kein solarish:
- ich nutze ZFS auf Proxmox
- ich bin froh mittlerweile mit linux recht gut fertig zu werden :fresse:
Nixht falsch verstehen, angedchaut hatte ich es mir, aber ich komme mit linux besser klar :-)
Wenn ich meinen Fileserver mal von Mergerfs und Snapraid umstellen müsste, würde ich da glaube ich auf freenas setzen mit zfs, obwohl ich da keinen ECC habe. Oder auch hier ZOL.
 
Pro Raidz1 VDEV in einem Pool darf 1 HDD ausfallen, Die Aussage stimmt!

Das ändert aber nichts an der Aussage, daß Pro Pool nur eine beliebige(!!!) HDD ausfallen darf, Der Ausfall einer zweiten HDD kann den Pool zerstören, und das gilt solange ein Raidz1 oder Mirror VDEV im Pool ist - es darf natürlich kein Stripeset im Pool sein, weil dann gar kein Redunzlevel mehr für den Pool besteht

Es hätte folglich keinen Sinn in einem Pool mehrer Raidz2/3 VDEVs zu haben, wenn ein Raidz1 dabei ist, der niedrigste Redundanzlevel aller beteiligten VDEVs im Pool entspricht dem Redundanzlevel des Pools, er wird uahc in keiner Weise erhöht.

5 Mirror in einem Pool macht man aus Performancegründen, heißt aber nicht das 5 HDDs ausfallen dürfen, es darf auch hier nur eine beliebige(!!!) HDD ausfallen

- - - Updated - - -

Wenn ich meinen Fileserver mal von Mergerfs und Snapraid umstellen müsste, würde ich da glaube ich auf freenas setzen mit zfs, obwohl ich da keinen ECC habe.
Das liegt dann aber an deiner Hardware!!
 
Zuletzt bearbeitet:
ZFS erstellt einen Datenpool der aus einem oder mehreren vdevs besteht. Die Daten werden über die vdevs verteilt. Das ist ähnlich zu einem Raid-0 das die Daten über Platten verteilt. Der Vorteil ist klar. Je meht vdevs desto mehr Kapazität und desto höhere sequentielle Perfomance. Ähnlich wie bei Raid-0 aus Platten führt aber der Ausfall eines vdevs zum Totalverlust des Pools.

Ein vdev ist so zu sehenwie ein herkömmliches Raid-1/5/6. Ein Pool aus zwei Z1-vdevs ist also zu sehen wie ein Raid-50. Prinzipiell geht ein vdev auch aus einer Platte, das ist aber recht sinnfrei da das vdev keine Redundanz hat.

Ein ZFS Pool kann aus beliebigen vdevs gebaut werden. Die Wahrscheinlichkeit eines Pool-Verlusts ist damit die Addition der Ausfallwahrscheinlichkeiten der einzelnen vdevs. Wenn der Pool aus unterschiedlich zuverlässigen vdevs besteht, hat man schnell einen Pool der so zuverlässig ist wie das schwächste vdev. Dies und auch das Verhältnis Anzahl Platten/Gesamtkapazität legt nahe, lieber einen Pool aus gleichen vdevs neu zu erstellen als "krumme" Sachen zu machen.
 
Das liegt dann aber an deiner Hardware!!

das habe ich ja auch nie bestritten :hmm: und in meinem Fileserver, wo hauptsächlich wenige, große und kaum veränderte Dateien liegen, benötige ich kein ECC.

@gea: also lieber RAIDZ1 auflösen, zwei HDDs hinzuholen und auf RAIDZ2 setzen?
 
Ich glaub, das kann man recht einfach zusammenfassen:
Wenn Du eher Kapazität und große Files (Video z.B.) und wenige IOPS gleichzeitig brauchst: RAIDZ2.
Wenn Du Datenbanken mit viel Random-Zugriff hast: mehrere Vdevs aus Mirror-Pärchen da dann IOPS gefragt sind.

Daher hab ich 3 Pools auf meinem Storage:
- 1*Raidz2 aus 6 HDDs (=>groß, sequentiell schnell, wenig Zufallszugriff)
- 1*Mirror aus 2 Sata-SSD a 480GB (=>für VMs, z.B. auch WSUS)
- 1*Single Pool aus 960 Evo (derzeit experimentell für Datenbanken).

Langfristig sollen aus beiden SSD-Pools einer werden, dann als Mirror 2*NVME oder Raidz1 aus 3*NVME werden (sobald ich ein Board mit genug Lanes hab und die NVME-Preise etwas runter kommen). Solange ZoL kein Trim kann, auf ESXI+BSD-Basis; solange bleibt Proxmox bei mir im Experimentier-Status.
 
Zuletzt bearbeitet:
was ich als großen Nachteil von ZFS empfinde (neben der fehlenden TRIM-Unterstützung) ist, dass man nicht einfach den Pool erweitern kann. Das ist das schöne an MergerFS + Snapraid. Platz voll? Einfach weitere HDD hinzu und fertig.

Die fehlende TRIM-Unterstützung ist natürlich mist. Aktuell läuft mein Proxmox mit den VMs selber auf einem ZFS-RAID1 aus zwei SSDs. Überlege, ob ich da nicht einfach nur eine einzelne SSD mit ext4 nutze und die andere SSD als Cache für das RAIDZ1 hinzufüge. Hatte ursprünglich mit dem Gedanken gespielt Proxmox auf einen USB-Stick zu installieren, aber das würde dieser nicht lange überleben :fresse:
 
Solarish und BSD haben kein Trim-Problem mit ZFS; die könnens. Drum werd ich mir evtl. auch noch bhyve als Virtualisierer anschauen. Momentan bin ich da, abgesehen von bissl rumspielen, ausschliesslich mit ESXI unterwegs.
 
Zuletzt bearbeitet:
Ja, das ist klar, dass die das können. Da ich aber eher ein Linux-Kind bin was Server angeht, bleibe ich lieber da :)

BTRFS ist ja auch ganz nett, aber hier funktioniert RAID5/6 nicht gut... :fresse:
 
Naja. Solaris ist jetzt nicht sooooo weit weg von Linux - wie auch als Unix. Ist für mich eher wie eine andere Distribution. ;) Nur halt irgendwie ausgereifter/konsequenter bzw. feiner abgestimmt. :d

Und einerseits mit MergerFS und Snapraid rumdoktern, gleichzeitig ZFS haben wollen und dann doch wegen fehlendem Trim-Support und Linux-Fable die "richtige" Lösung ablehnen... gibt halt nicht DIE Lösung für Dich. Willst du ein sauberes, sicheres, netzwerkorientiertes (File)System ohne Frickelei? Nimmste Solaris, haste Ruhe. Willste Linux, musste frickeln und haste kein "vollwertiges" ZFS, keine vollintegriertes SMB/Cifs, NFS, iSCSI und kein voll funktionsfähiges Napp-It. Einen Tod musst Du leider sterben. Habe auch mit Linux-ZFS für meinen Fileserver angefangen. Dann Solaris und bis auf weiteres "Never going back".

Nur für File-serving natürlich. Andere Dienste, andere Lösung. Aber immerhin eine Baustelle, um die ich mich gedanklich/konzeptionell auf Jahre nicht mehr kümmern muss. Zur Not zieht der Pool irgendwann in ein Gehäuse für 16HDDs um und dann ist wieder für Jahre Ruhe. Oder ich migrier zwischendurch von einem Pool aus 4TB HDDs irgendwann auf 8TB Disks. Dank Replikation sowas von simpel...

Ja. Sorry. Fanboi hier. :)
 
Extrem positiv ist, dass es so schnell ein OmniOS als Community Edition gibt, insbesondere dass es bereits ein erstes Update gibt. Auch ist es sehr positiv, dass OmniOS CE von mehreren Firmen getragen wird, die OmniOS selbst in größerem Umfang einsetzen. Das läßt eine konstante Weiterentwicklung erwarten ähnlich wie es bisher der Fall war. Da stand aber nur eine Firma (OmniTi) dahinter.

Für die Zukunft würde ich mir eine engere Abstimmung mit dem Schwesterprojekt OpenIndiana wünschen, damit nicht alles vom Erstellen der Distribution mit allen Tools, den Updates und Patches, über die Pflege einer Website, Downloadmirrors, Wiki und was es sonst noch an Aufgaben gibt, doppelt gemacht wird. Dazu sind die Projekte viel zu ähnlich, in ihrer jeweiligen Basisausführung nahezu identisch. Schliesslich haben Illumos Community Projekte bei weitem nicht soviel Manpower wie beispielsweise Debian oder Ubuntu als "einander ähnliche" Distributionen.

@gea: Ich verfolge intensiv die Fortschritte bei OmniOS Community Edition und bin weiterhin begeistert wie es da voran geht. Mittlerweile habe ich meine Systeme auf die Stable von OmniOSce umgestellt. Worauf setzt Du nun zukünftig, OI oder OmniOSce? Oder beides?
 
@gea: Ich verfolge intensiv die Fortschritte bei OmniOS Community Edition und bin weiterhin begeistert wie es da voran geht. Mittlerweile habe ich meine Systeme auf die Stable von OmniOSce umgestellt. Worauf setzt Du nun zukünftig, OI oder OmniOSce? Oder beides?

Ich unterstütze wie seit Jahren beide und werde das weiter so halten.
Wenn es bei OmniOSce so wie bisher mit den regelmäßigen Stables weitergeht, werde ich da als Hauptplattform neben Solaris bleiben.
 
Macht es Sinn das OS+Datenbank von einer eigenen Cloud (hier: Nextcloud) auf einer SSD zu packen, während die Daten auf einem RAIDZ1 liegen? Oder ist die Performance übers Internet davon nicht beeinflusst? Es geht mir primär um Seitenaufbau der Nextcloud-GUI und auch der Vorschau von Bildern. Würde es eher Sinn machen, alles auf dem RaidZ1 zu packen und etwas von der SSD als Cache hinzuzufügen?
 
Zuletzt bearbeitet:
So einen langsamen Pool kannst du gar nicht haben, dass dein Upload den auslastest ;)
 
Ich betreibe auch eine Nextcloud (und davor ownCloud) .... falls du keine Uni bist und mehrere 10k Nutzer bedienen willst, spielt der Storage an sich nur zweite Geige. Die Wuppdizität holst du mit Tuning am Browser/Datenbank/Cache raus...

PHP7.0 mit opcache + memcache (ich nutz Redis) und eine ordentliche eingestellte MariaDB sind die Faktoren, die da helfen. Das ZFS (oder jeglicher anderer Storage da drunter) spielen nur die 2. Geige.

- - - Updated - - -

Letztes Offtopic dazu ;) Nextcloud Tuning
 
Danke dir :)

Ich will mein ZFS RAID1 Mirror gerne auflösen und würde gerne eine SSD erstmal als "Backup" liegen lassen, falls ich doch wieder zurück will. Wie mache ich das am besten? Einfach abklemmen oder zfs detach oder was?
 

@gea
funktioniert der split-Befehl auch wenn es mehrere vdev's sind? Wird dann ein neuer pool gebildet aus je einer HDD von jedem vdev?

# zpool split pool_ripley pool_neu

Code:
# zpool status pool_ripley
  pool: pool_ripley
 state: ONLINE
  scan: scrub repaired 0 in 11h26m with 0 errors on Tue Jul 18 10:25:37 2017
config:

        NAME                       STATE     READ WRITE CKSUM
        pool_ripley                ONLINE       0     0     0
          mirror-0                 ONLINE       0     0     0
            c1t5000CCA22BC16BC5d0  ONLINE       0     0     0
            c1t5000CCA22BF5B9DEd0  ONLINE       0     0     0
          mirror-1                 ONLINE       0     0     0
            c1t5000CCA22BC8D31Ad0  ONLINE       0     0     0
            c1t5000CCA22BF612C4d0  ONLINE       0     0     0
          mirror-2                 ONLINE       0     0     0
            c1t5000CCA22BC8AA67d0  ONLINE       0     0     0
            c1t5000CCA22BEDD925d0  ONLINE       0     0     0
          mirror-3                 ONLINE       0     0     0
            c1t5000CCA22BC6C23Bd0  ONLINE       0     0     0
            c1t5000CCA22BF5D269d0  ONLINE       0     0     0
          mirror-4                 ONLINE       0     0     0
            c1t5000CCA22BEEBEAAd0  ONLINE       0     0     0
            c1t5000CCA22BF7A76Cd0  ONLINE       0     0     0
          mirror-5                 ONLINE       0     0     0
            c1t5000CCA22BC8ACCDd0  ONLINE       0     0     0
            c1t5000CCA22BF611EAd0  ONLINE       0     0     0
          mirror-6                 ONLINE       0     0     0
            c1t5000CCA22BC18D61d0  ONLINE       0     0     0
            c1t5000CCA22BEF5192d0  ONLINE       0     0     0
          mirror-7                 ONLINE       0     0     0
            c1t5000CCA22BC6B9E7d0  ONLINE       0     0     0
            c1t5000CCA22BF60100d0  ONLINE       0     0     0
          mirror-8                 ONLINE       0     0     0
            c1t5000CCA22BC7EAC9d0  ONLINE       0     0     0
            c1t5000CCA22BC8A445d0  ONLINE       0     0     0
          mirror-9                 ONLINE       0     0     0
            c1t5000CCA22BC5B3ACd0  ONLINE       0     0     0
            c1t5000CCA22BEEC212d0  ONLINE       0     0     0
          mirror-10                ONLINE       0     0     0
            c1t5000CCA22BEF5185d0  ONLINE       0     0     0
            c1t5000CCA22BF596E5d0  ONLINE       0     0     0
        spares
          c1t5000CCA22BF601D1d0    AVAIL
 
Zuletzt bearbeitet:
Interessante Idee mit Raid-10 Pools.
Wird aber nicht funktionieren. Ziel ist das Aufsplitten eines einfachen n-way Mirrors mit einem vdev.
 
Also irgendwie verwirrt mich die Aussage von Digi-Quick.

5 Mirror in einem Pool macht man aus Performancegründen, heißt aber nicht das 5 HDDs ausfallen dürfen, es darf auch hier nur eine beliebige(!!!) HDD ausfallen

Warum soll das stimmen ? Wenn ich einen Pool wie Layerbreak habe, ist doch jedes Stripe doppelt vorhanden (mirror), also darf doch eigentlich pro mirror eine HDD ausfallen..?
In meiner Test VM (Ubuntu ZoL), funktionert das jedenfalls.. 2 Mirror in einem Pool - aber daran sollte ja die Menge der mirrors nichts ändern ?
 
Zuletzt bearbeitet:
Die Aussage dass nur eine beliebige Platte ausfallen darf ist schon korrekt.
Es darf aber pro mirror nur eine Platte ausfallen ohne dass Daten verloren sind. Prinzipiell darf aber in jedem Mirror eine Platte ausfallen.

Das ist dann ein Fall für Statistiker, wie wahrscheinlich zwei Plattenausfälle sind die beide im gleichen vdev auftreten (Pool verloren).
 
Nach erneutem lesen und auch wegen deinem Post, habe ich es verstanden wie es gemeint war.
Irgendwie klar, dass wenn eine ausgefallen ist, das nun keine beliebige mehr ausfallen darf - könnte ja somit die andere aus dem gleichen mirror sein.
Deswegen war "eine beliebige HDD" auch hervorgehoben.
 
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