[Datengrab] HardwareRaid 5+HS oder ZFS mit RAIDZ2

Begonnen von chris1284, 14 Juli 2017, 21:03:49

Vorheriges Thema - Nächstes Thema

chris1284

Hallo ihr lieben,

ich habe mal wieder Überlegungen zu meinem Server.
Aktuell fahre ich den HP Microserver Gen8 mit HP 410 Raidcontroller (256MB cache Battery Backed). Am Raid sind 4x2tb im RAID5 mit Hotspare (also 3,5GB nutzbar und es kann eine Platte ausfallen). System  (debian mit samba-share, ftp-server, ha-bridge, fhem, plex) liegt auf einer SSD am intern SATA Controller. Performance ist gut, Ausfallsicherheit geht so (hatte einen Plattenausfall und der Rebuild mit hoher Prio dauerte sehr lange, in der Zeit ist man ungeschützt).

Ich finde FreeNAS recht interessant. Hier würde ich RAIDZ2 (RAID6) fahren => 2 Platten könnten aufallen und wenn 1 ausfällt ist man auch beim rebuild sicher. Der RAID-Controller konnte rau (weniger wärme, slot wäre frei und ZFS mit Hardware-RAID ist wohl sinnfrei da Freenas so den Ausfall einer HDD nicht mitbekommt). 8GB Ram sollten genug sein. Zudem bietet FreeNAS einen Hypervisor, so könnte ich einzelen"Dienste" in VMs auslagern (FHEM zb). RAID6 kann der HP 410 nur mit extra Lizenz :( was ich mit ZFS dann kompensierne könnte.

was haltet ihr davon? Bedenken?

micomat

Alles sauber verschluesselt zusaetzlich in irgend einer Cloud saven :) So mach ich das. Dann bin ich auch Gegen Hochwasser/Brand gefeit.
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

kaputt

#2
ZFS ohne ECC und USV kann furchtbar in die Hose gehen.
Es gibt immer noch die 80% Regel, Dedup mit weniger als 16 GB Ram fast nicht machbar (falls du darauf spekulierst).
Hast du dir schon mal BTRFS angeschaut?
Was heißt "der Rebuild mit hoher Prio dauerte sehr lange"?
Gruß aus L.E.
Uwe

Bei U/Linux hilfreich aber nicht nötig, bei Windows nötig aber nicht hilfreich!
Rechtschreibfehler sind beabsichtigt und Ausdruck meiner Persönlichkeit

chris1284

#3
der Server hat Nicht gepufferten ECCund hängt an einer usv  ;)
Dedub ist erstmal keine Anforderung. warum braucht dedub unter linux/freenas soviel ram? unter server 2012r2 läuft das so nebenbei außerhalb der "geschäfftszeiten" mit wenigetr als 12gb problemlos.
ZitatWas heißt "der Rebuild mit hoher Prio dauerte sehr lange"?
12h ca. (man kann im controller einstellen welche priorität der rebuild hat)


debian wie gehabt und zfs wäre auch eine option.  btrfs werde ich mir nochmal ansehen (mein letzter status war das es noch beta statidum hatte ~2015 und funktionen wie raid5/6 nicht sauber liefen), wäre ja auch eine option für debian (so müsste man sich nicht an freenas binden)

chris1284

offensichtlich hat sich nicht viel geändert. btrfs ist soweit ich lese keine option (im aktuelln debian wiki gehts ei den warnungen direkt mit "Do not use raid5 or raid6 profiles. " los).
wirklich gute erfahrungsberichte liest man nicht.

zfs ist auch nur unter freebsd wirklich bedenkenlos einsetzbar (mit ecc ram) soweit ich lese. viele nutzen ubuntu mit zfs on linux was wohl aber nicht so stabil, performant uns zuverlässig wie unter freebsd ist.
nach vielem lesen würde ich nu nehr zu freebsd (noch nie selbst genutzt) auf ssd tendieren, zfs mit den 4x2tb hdds im raidz2. samab, fhem, plex je in einer eigenen jail-umgebung mit ihrem speichern auf dem zfs pool (jails find ich sehr interessant). rsync fürs backup (wie gehabt wöchentlich abwechselnd auch 2 2bay-nas)+ ggf. snapshots.

chris1284

mittlerweile habe ich nach vielem lesen im netz die umstellung gewagt und nun 4x2tb nicht mehr im hw raid5 mit hotspare am laufen sondern als zfs pool.
der pool ist aus 2 mirror zu je 2 platten aufgebaut, performance ist sehr gut, komprimierung aktiv, ~12W weniger stromverbrauch und es können 2 platten ausfallen ohne dass das system steht.

beim lesen in unterschiedlichen quellen muss man feststellen dass es viele mythen bezüglich zfs gibt was zb ecc speicher pflicht und bit flipping angeht oder andere spezielle hardwarevoraussetzungen (wie seht viel ram, dicke cpu, usv). bei vielen fehlern / hilfesuchenden ist oft nicht zfs das problem sondern der user (falsche planung, falsche befehle genutzt um zb den pool zu erweitern)

b4r7

Habe auch einen HP Microserver gen8 mit einem LSI SAS Controller.

Ich nutze damit seit bald 4 Jahren Freenas.

Intel Xeon 1230v2
16GB ECC unbuffered RAM
4x 4TB HDDs im Raidz2 als Datenpool
2x 265GB SSDs im Mirror als meine Jail/VM Platten.

Die SSDs habe ich drinnen das die HDDs nicht wegen den kleinsten Datenzugriffen Hochspinnen müssen.

Alles an einer entsprechend dimensionierten USV.

Ich nutze die Jails seit beginn an und bin echt begeistert. Ich habe dort Plex, Sabnzbd, resiliosync, s3cmd und einen Nginx Reverseproxy. Hatte bisher niemals performance Probleme. Ich wollte irgendwann auch mein FHEM dort rein ziehen, hier scheitert es aber an einem CUN oder ähnlichem. Habe bisher nur einen CUL. Der Server steht durch 3 dicke Betonwände, in einem anderen Brandabschnitt, in meinem Kellerabteil.

Was manchmal echt ärgerlich ist, ist die Tatsache das es Freebsd ist und dort dann doch ein wenig was anders abläuft als in einem "gewöhnlichen" Linux.

Backups mache ich zZ noch verschlüsselt richtung Amazon S3. Ich habe aber einen Feature Request im Bugtracker von Freenas eingereicht damit Amazon Glacier integriert wird. Der wurde angenommen und soll zum nächsten Release auch implementiert werden.

Alles in allem kann ich sagen das Freenas eine echt feine und vor allem zuverlässige Geschichte ist.

Zitat von: chris1284 am 20 August 2017, 17:00:02

mittlerweile habe ich nach vielem lesen im netz die umstellung gewagt und nun 4x2tb nicht mehr im hw raid5 mit hotspare am laufen sondern als zfs pool.
der pool ist aus 2 mirror zu je 2 platten aufgebaut, performance ist sehr gut, komprimierung aktiv, ~12W weniger stromverbrauch und es können 2 platten ausfallen ohne dass das system steht.

beim lesen in unterschiedlichen quellen muss man feststellen dass es viele mythen bezüglich zfs gibt was zb ecc speicher pflicht und bit flipping angeht oder andere spezielle hardwarevoraussetzungen (wie seht viel ram, dicke cpu, usv). bei vielen fehlern / hilfesuchenden ist oft nicht zfs das problem sondern der user (falsche planung, falsche befehle genutzt um zb den pool zu erweitern)


Ich würde mich allein wegen dem Support schon an die Hardware Requirements halten. Ich kann hier aber nicht Bewerten ob es Mythen sind oder nicht. Ich war bisher immer innerhalb der Vorgaben.
FHEM auf Debian VM (FreeNAS bhyve)
HMUart + ZME-UZB1 über RPi2/ser2net

drdownload

Ich verwende mergerfs für pooling + snapraid für parity. Ist im Gegensatz zu allem anderen Datei und nicht Block-basierend.

Hat den Vorteil, dass wenn eine Platte ausfällt die Daten auf den anderen Platten ganz normal lesbar sind und der Rebuild aus der Partiy mit der neuen Platte passiert. Wenn ich 2 parity verwende überlege ich auch einen Plattenausfall während rebuild-
CUL 868 Slow-RF (FS20 Aktoren, Sender, FHT8V), CUL 868 (WMBUS-Empfang), Jeelink (PCA301), WS3600 (WH3080 über USB-Basis), Bewässerung mit ESP-Easy und Proplanta, RFXTRX433 Home-Easy Empfang und Senden, Oregon TH, WS001 TH), Blackbean IR, Mopidy-Snapcast MR Audio, Kodi, Forum-LED-Controller,

chris1284

#8
Zitat von: Eddi.B am 08 September 2017, 15:26:10
Ich würde mich allein wegen dem Support schon an die Hardware Requirements halten. Ich kann hier aber nicht Bewerten ob es Mythen sind oder nicht. Ich war bisher immer innerhalb der Vorgaben.

das ist es ja gerade. es gibt keine wirklichen hart festgelegten für zfs an sich. kein wort von usv's, ecc wird empfohlen ist aber nicht notwendig (die gefahr von bitflips ist ist nicht höher nur weil man zfs nutzt und der efekt ist bei anderen dateisystemen der selbe. man muss halt entscheidne wie sicher man seine daten ablegen will), 2gb ram reichen völlig aus, für mehr features muss mehr ram rein. selbst freenas empfielt nur 8gb ram, sagt aber nichts zu minimimalanforderungen und erwähnt auch keine usv in den offiziellen dokumentationen. fakt ist halt das sich zfs den speicher gönnt der frei ist. wenn man nur 2gb hat und das system 600mb belegt zieht den rest halt zfs bis ein anderes program ram haben will, dann gibt zfs welchen ab (wie es halt mit anderer software unter linux auch läuft). ich hatte bei mir mal einen rigel raus genommen und mit 4 statt 8gb merk man keinen unterschied.

genau wegen der eigenheiten von freebsd habe ich es auf debian gemacht (freenas war eh keine option). ich hatte mir testweise ein freebsd in einer vm installiert, das war schon was ganz anderes als das gewohnte debian. grundsätzlich sollte aber alles auch auf freebsd laufen was auf linux läuft. raidzX war nach ausführlichem lesen der docu zu zfs und forenbeiträgen keine option mehr da es schwer erweiterbar ist bzw kostspielig erweiterbar

b4r7

ja soweit stimmt das auch. Mir war in dem Fall wichtig das es läuft. klar kann ich mich einfach an ein Debian hocken Platten mounten und dann irgendeine Softwareraid Lösung nutzen. Bei Freenas war es eine Mischung aus Sicherheit und Freiheit sie mich dazu bewogen hat. Grundsätzlich gefiel mir auch die Idee von Jails statt VMs weil die dann doch nicht so Ressourcenhungrig waren. Schade das es NOCH keine bzw. wieder keine Docker Unterstütztung gibt. Damit ist man letztendlich unabhängig vom FreeBSD und kann im Fall eines Systemwechsel die Container überall anders betreiben... Aber das sind alles Themen über die man teilweise extrem streiten kann x) Was ich schon an Diskussionen mit meinen Kollegen deshalb hatte x)

Gesendet von meinem SM-G930F mit Tapatalk

FHEM auf Debian VM (FreeNAS bhyve)
HMUart + ZME-UZB1 über RPi2/ser2net

chris1284

genau die nicht vorhanden freiheit war der grund bei mir ein debian (oder original freebsd) zu nehmen und nicht freenas. mit docker und ähnlichen lösungen, gerade für fhem oder plex wollte ich mich auch noch maöl beschäftigen wenn es denn zeit gäbe  ;D

b4r7

#11
Zitat von: chris1284 am 09 September 2017, 21:24:47
genau die nicht vorhanden freiheit war der grund bei mir ein debian (oder original freebsd) zu nehmen und nicht freenas. mit docker und ähnlichen lösungen, gerade für fhem oder plex wollte ich mich auch noch maöl beschäftigen wenn es denn zeit gäbe  ;D

Naja. Freiheit haste schon... immerhin kannst du im Gegensatz zu einer NAS immer noch unter root arbeiten (was du nicht solltest x)

Auf der anderen Seite hast du Leute die sicherstellen (bzw. es zumindest probieren) das Updates usw. dein Filesystem nicht zerballern... Klar gibts Backups... es ist aber trotzdem mega ärgerlich wenn zB. wegen einem Update nichts mehr funktioniert.
FHEM auf Debian VM (FreeNAS bhyve)
HMUart + ZME-UZB1 über RPi2/ser2net