Mal wieder ZFS und Hardwarefragen ;)

[minimike]

Hi

Der neue Job fordert mich richtig. Ich muss die Hardware für eine Backuplösung planen und das alles schon ab dem dritten Tag.
Unser Hausdealer ist Thomas Krenn und da habe ich mich in die Hardware verguckt

http://www.thomas-krenn.com/de/produ...36-server.html

Als OS soll FreeBSD oder RHEL 6 drauf. FreeBSD 8.3 ist mir lieber.

Auf der Kiste läuft dann Bacula und PostgreSQL für Bacula. Sowie noch einige Webtools für Bacula damit nicht nur ich sondern auch andere damit umgehen können.

Nun geht es darum das Budget zu optimieren. Sollte ich mir da noch einen extra Raidcontroller kaufen? Da wäre der optionale von LSI bei Krenn.

Und ich habe da noch Highpoint in Errinnerung. Gibt es da einen der 16 Platten mit FreeBSD intern unterstützt? Sowie etwas das 2 SAS 600 Geräte extern ansprechen kann.

bei 16 Platten was wäre besser? Ein HW Raid oder doch besser ZFS weil ich dann writecaching auf den Platten habe?

Bei reinem ZFS ohne HW Raid, was wäre dann die beste Konfiguration Betreff der Redundanz? Vor allem irgendwann könnte ich ja dann online

und ich habe gesehen das die großen Platten ab 2 TB 4K Sektoren haben. Muss ich da bei ZFS noch etwas beachten?

[mark05]

hi

fuer zfs ist kein raidcontroller noetig , eher sogar kontraproduktiv.
wenn du z.b. lsi 9211-i bekommsts , ohne raid firmware, ist es perfekt.

was das aufteilen der platten betrifft wuerde ich bei dem genannten scenario 2 pools
machen .
1x raidz1 fuer bacula
1x ein oder mehere mirrors fuer die db je nach kapazitaet.

insgesamt nur 15 platten verwenden 1x host spare.

wenn du freebsd9 nimmst , habe ich hier laufen , musst du dich um das 4k thema
nicht kuemmern .

holger

[rakso]

Zitat von mark05

wenn du freebsd9 nimmst , habe ich hier laufen , musst du dich um das 4k thema
nicht kuemmern .

holger

wieso nicht?

http://wiki.bsdforen.de/zfs_ashift

[Crest]

Also über den Cache eines RAID Controllers freut sich ZFS natürlich. Beim Lesen ist ZFS allerdings nicht drauf angewiesen, weil es massiv den Arbeitsspeicher als Lesecache benutzt. Beim Schreiben kann der Cache eines RAID Controllers helfen. Zumindestens unter Solaris gab es bestimmte Controller die ZFSs Flushbefehle direkt an die Platten weiter gaben anstatt ihr durch die BBU gesichertes RAM zu verwenden und dennoch das Writecaching der Platten deaktiviert haben. Das merkt man schnell, weil es quälend lahm ist.

Es schadet beim Einsatz von ZFS allerdings das RAID durch den Controller zu erledigen. Damit werden ZFSs Selbstheilungsmöglichkeiten außer Kraft gesetzt, Performancegewinne zunichte gemacht und ZFS zu einem bequemen LVM degradiert.

[kira12]

Hallo,

da das resilvern bei großen Platten viele Stunden dauert würde ich eher ein Raid-z2 wählen, die Hotswap Platte ist dann eher eine Geschmacksfrage?

Gruß ré

[mark05]

Zitat von rakso

wieso nicht?

http://wiki.bsdforen.de/zfs_ashift

weil ich irgendwo in einer release docu von freebs9 gelesen habe das
gpart und der kernel dsa sauber erkennen und verarbeiten.
so wie die neueren distributionen von linux.


holger

p.s. leider finde ich den text nicht mehr

[Crest]

Oh ja GEOM funktioniert in der Theorie wunderbar und gibt brav an ZFS weiter was die Platten ihm vorlügen. In der Praxis muss man leider auch mit FreeBSD 9.0 noch etwas nach helfen.

[solarix]

Zitat von minimike

Hi

Der neue Job fordert mich richtig. Ich muss die Hardware für eine Backuplösung planen und das alles schon ab dem dritten Tag.
Unser Hausdealer ist Thomas Krenn und da habe ich mich in die Hardware verguckt

http://www.thomas-krenn.com/de/produ...36-server.html

Als OS soll FreeBSD oder RHEL 6 drauf. FreeBSD 8.3 ist mir lieber.

Auf der Kiste läuft dann Bacula und PostgreSQL für Bacula. Sowie noch einige Webtools für Bacula damit nicht nur ich sondern auch andere damit umgehen können.

Nun geht es darum das Budget zu optimieren. Sollte ich mir da noch einen extra Raidcontroller kaufen? Da wäre der optionale von LSI bei Krenn.

Und ich habe da noch Highpoint in Errinnerung. Gibt es da einen der 16 Platten mit FreeBSD intern unterstützt? Sowie etwas das 2 SAS 600 Geräte extern ansprechen kann.

bei 16 Platten was wäre besser? Ein HW Raid oder doch besser ZFS weil ich dann writecaching auf den Platten habe?

Bei reinem ZFS ohne HW Raid, was wäre dann die beste Konfiguration Betreff der Redundanz? Vor allem irgendwann könnte ich ja dann online

und ich habe gesehen das die großen Platten ab 2 TB 4K Sektoren haben. Muss ich da bei ZFS noch etwas beachten?

Ganz grundsätzlich... auch wenn Du die Raidfeatures nicht nutzt...... ein LSI Contzroller besser zwei, für den Fall das einer ausfälllt.. tut niemals weh.

Besser wär es aber.... wenn Du dir zwei Disk Shellfs hinstellst... die nicht Serverintern sind... über FC HBA anbinden und den Backup Zpool über die Shellfs spiegeln und dazu pro Shellf mindestens zwei Pfade.

Wenn Du es wirklich professionel machen willst, setzt du die Shellfs auch an zwei unterschiedliche Standorte, nicht ins gleiche Rack!

Wenn es schon Thomas Krenn als Lieferant sein soll... würde ich mir auch ernsthaft überlegen... ob ich nicht ein Nexentastor hinstellen.... damit kannst Du Dir einen Haufen Frickelei sparen.

Das lässt sich dann auch bei Bedarf mit weiteren Shellfs erweitern und ist definitiv keine Frickel sondern eine professionelle Lösung.

[Yamagi]

Zu 4k Sektoren: FreeBSD hat eine "Known to be good"-Liste und versucht mit der und ein wenig Magie zu erkennen, ob die "512 Byte" sagende Platte nicht doch 4k Sektoren hat. Das klappt auch recht gut, aber eben nicht immer.

[Bummibaer]

Hi,
joar, wobei das mit "nicht immer" dann halt in dem Fall wo`s ned klappt Bärenscheiße ist - von daher würde ich IMMER die Werte vorgeben wenn ich se sicher kenne um das Problem oifach zu vermeiden.
Beste Grüße
Bummibär

[minimike]

Danke für eure Tips!

Bei 32 TB a 16 x 2 TB mit ZFS reichen da 8 GB Ram oder sind da 16 GB - 32 GB besser?
Auf dem System laufen nur die beschriebenen Anwendungen. Also nicht wirklich viel. Das einzige was da Dampf braucht ist ZFS.

Warum ich mich gegen einen Raidcontroller entscheiden möchte? In den vergangenen Monaten habe ich bei meinem alten Job zwei ältere Installationen verloren. Der Raidcontroller ist ausgefallen und es hat bis zu vier Tage gedauert die alten Dinger zu organisieren. Einmal hatten wir sogar noch eine Ersatzkarte. Allerdings mit einer älteren Firmware. Dadurch wurde vermutlich der Raid zerballert. Die Server waren länger offline und wir konnten in jedem Fall das Backup einspielen. Trotzdem hatten die Kunden kein Verständniss für die Downtime.

Das Unternehmen wo ich jetzt arbeite wagt gerade den evolutionären Sprung vom Kleinbetrieb zu einem mittelständischen Unternehmen. Und da in Zukunft noch einiges kommt will ich gerne dabei sein. Ich habe die Chance von Grund auf die Zukunft aktiv mitzugestalten. Nicht als Befehlsempfänger sondern als Visionär.

[Bummibaer]

Hi,
wenn dem so ist würde ich mal in Richtung Supermicro schauen. Da gibts das eine oder andere Board wo bärig viel Möglichkeiten hat - z.B. bis zu 256 GB Ram und zwei CPU-Bärlis. Als Storage mit ZFS wäre das wenn Du selbst gestalten willst und nichts Fertiges kaufen sicher derzeit die beste Lösung. Beim RAM gillt der alte Bärengrundsatz: Ram ist durch nichts zu ersetzen außer durch mehr RAM oder schnelleres RAM oder größeres und schnelleres RAM - d.h. viel hilft viel. Also würde ich da nicht gleckern wegen ein paar Euro und oifach mal ordentlich was neistecken. Ich würde hier schon eher zu 64 GB RAM mindestens tendieren, wobei das technisch grundsätzlich mit 16 schon auch geht. Interessanter ist dort eher die Wahl der HD Art / Schnittstelle und des richtigen Controllbären bzw. zwei Controllbären je nachdem ob mer SATA spielt oder mit SAS spielt. Zum vernünftig arbeiten ist die Bestückung mit mehr als einem Controllbären und mit zusätzlichen SSD für Cache und Log und Co und mit viel RAM natürlich eine deutlich bessere Idee. Hier stellt sich natürlich abär auch immer die Frage ob man nicht sofort was gescheites kauft wo fertig ist statt das Rad neu zu erfinden obwohl es das schon gibt in der Hoffnung es würde runder werden.

Insbesondere bei ZFS darauf achten, dass der Controllbär / die Controllbären NICHT mit HW-Raid Modis betrieben werden ! - das geht entweder mit spezieller Firmware darauf oder mit Controllbären wo mer die HDs direct durchschleifen kann ohne HW Raid (wobei Letzteres meist unnötig teuer dann wird). Wichtig ist auch darauf zu achten, dass Firmware Updates der Festplatten durch den Controllbären hindurch möglich sind ! - es nutzt nichts wenn mer schöne Controllbären hat mit ZFS und nette Platten und nicht in der Lage ist bei Firmware Bugs der HDs diese zu aktualisieren.

Klare Empfehlung wenn Du bauen willst:
- 2x SAS2 Controllbären nehmen zu je 8 HD mit SAS2 und 24/7 Freigabe und 64 MB Cache pro HD. Bein den Controllbären auf Firmware ohne HW-Raid Funktion in diesem Fall natürlich dann achten. LSI z.B. mit spezieller Firmware oder Areca mit Direct Access Mode werden hier gerne genommen - wobei LSI preislich günstiger wäre.

- mind. 64 GB RAM-Bären neistecken (z.b. 4 x 16 GB ECC), wobei die Modulgröße natürlich je nach Board pro Slot die maximale sein sollte, das der maximale Aufrüstungszustand möglich ist später ohhne die bisherigen Module tauschen zu müssen.

- mind. Xeonbärlis oder Opteronbären verbauen, da die bissel Wurst au vom Brot ziehen. Wenn koi große CPU Last erwartet wird kann mer hier natürich au eher auf de Stromverbrauch (max TDP) bärig achten.

- mind. zwei Netzteile (redundant) - ausfallen kann immer mal was und ohne Strom läuft bekanntlich bärig garnix.

- Ersatzteile vor Ort bärig vorhalten, welche baugleich sans. Insbesondere bei de Controllbären natürlich wenn mer Firmware Updates z.B. macht die au auf de Ersatzteile entsprechend gleich durchführen, damit das immer auf dem identischen Stand ist. Au wenn es lästig ist abär nur so kanns klappen.

- ZIL Cache / Log usw. möglichst uf SSDs auslagern bärig, da der Durchsatz und die Zugriffszeit bärig deutlich günstiger sans. Hier hat sich in de Praxis Intel und FusionIO bisher ganz gut bewährt. Die Größe hier ist nicht der einzig entscheidende Punkt - bei der Auswahl ist Durchsatz und Zugriffszeit bärig ebenso wichtig.

- alle HD möglichst in HotSwap Rahmen verbauen mit schöne Backplane, damit mer bei Ausfall fix ran kümmts ohne große Probleme und Zeitaufwand. Das kostet nur oi mal Geld und erspart Dir später viel Ärger. Ich kann es nicht oft genug sagen: Jungs/Mädels BESCHRIFTEN !!!!! - oder Controllbären & Backplanes nehmen wo die HDs identifizieren können und optisch signalisieren können - trotzdem BESCHRIFTEN !!!!

- Auf korrekte Kühlung der Komponenten bärig fein achten - zu viel Hitze ist was worauf die garned gut reagieren - se werden es Dir mit langer Haltbarkeit dann danken.

- Den alten Grundbärensatz beachten, das ein Raid noch lange koi Backup ersetzt. Ja ich weiss, das ist klar abär ich höre in letzter Zeit immer wieder von Fällen im Chan wo es koi Backup gab sondern Snapshots und co die dann im Eimer waren.

Gruß Bummibär

[Crest]

Anekdoten weisen darauf hin das SAS Expander sich im Fehlerfall nicht mit SATA Platten vertragen. Solltest du wirklich SATA Platten verbauen wollen dann verzichte auf Backplanes mit SAS Expandern (oder gar SATA Portmultipliern). Solange ein Port pro Platte auf allen Kabel durch gereicht wird dürften keine Expander im Spiel sein. SAS wird gerne als 4 Ports pro Kabel verlegt erst recht außerhalb des Gehäuses. Ich bin mir allerdings nicht sicher ob überhaupt jemand 4HE Gehäuse mit 40+ 3.5" Einschüben ohne Expander günstig anbietet.

[solarix]

Dem Bären kann ich nur zustimmen. Insbesondere was das Thema Neuerfindung des Rades angeht.

Raid ist kein Backup.... alles richtig, g, aber Backup ohne Tape Libraries ist auch kein seriöses Backup sondern Frickelscheiss. Backup nur auf einen einzigen Filer ist ebenfalls grob fahrlässig.. normalerweise sieht man zu das man sowas über Kreuz macht und nicht auf ein Blech. Auch nicht über den gleichen Netzwerk oder SAN Switch.

Backup Infrastruktur kostet Geld, ob mit proprietärer oder nicht proprietärer Software ist völlig wumpe.

[Bummibaer]

Hi,

joar zwecks Backup am besten oifach bärig regelmäßig sichern und das ganze auf einem möglichst zweiten Ziel ablegen, wo nach Möglichkeit sogar an einer anderen Location oder zumindest räumlich getrennt steht. Das Thema Brandbärenschutz sollte man bei wichtigen Daten natürlich auch nicht vernachlässigen, da gerade bei Brandfällen oft nur Backups übärleben die eben an einem anderen Standort waren.

Empfehlung des Bären:
- Backups in gleichen Zeitabständen bärig erstellen
- Datenkonsistenz / Datenintigrität jeweils prüfen ! - z.B. mittels sha1 / sha256 Hash Werten
- korrekte Sicherungsmethoden wählen, je nachdem was zu sichern ist - also z.B. für Datenbanken möglichst einen Dump erzeugen, Files z.B. eher in Archiven oder per Rsync und co ....
- Backups grundsätzlich immer wo extern aufbewahren
- die Methode mit welcher Sie erstellt wurden dokumentieren
- die Software wo verwendet wurde archivieren - damit eine Rücksicherung jederzeit möglich ist
- das hierzu passende OS sichern, damit auch das später immer zur Verfügung steht
- Datenformate / Filesysteme verwenden, welche möglichst dokumentiert sind - um zu gewährleisten das die später auch noch gelesen werden können ( also z.B. KEIN NTFS oder so Unfug !)
- möglichst auch regelmäßig prüfen ob es sich vollständig fehlerfrei zurücksichern lässt
- Methoden verwenden die möglichst mit wenig Aufwand eine Rücksicherung zulassen
- qualitativ gute Datenträger verwenden - kein Billigmist wo ständig Datenfehler produziert
- möglichst auf Storage Libraries setzen, z.B. mit Autoloader (vorzugsweise mit Barcode Methoden auch arbeiten wenn man sehr viele Bänder hat - die Beschriftung alleine ist da nicht immer nur das einzig sinnige Mittel)

Zwecks Expander und Portmultipliern würde ich grundsätzlich sagen "das kommt darauf an" - es gibt da einiges was sehr gut funktioniert abär weniger Durchsatz hat als eine direkte Anbindung pro Port zu je einer HD. Das hängt primär davon ab was man für Hardware hat und in wieweit der Datendurchsatz hier eine Rolle spielt.

Wer auf Nummer Sicher gehen will verzichtet auf solche Dinge einfach ganz und verbindet eine HD jeweils mit einem Port direkt - gerne auch übär Backplanes. Im Zweifel setztz man hier oifach mehrere Controllbären parallel ein - vorzugsweise mit PCIe x8 oder mit PCI-X - je nach Mainboard. Aufpassen ! - wenn man mehr als 2 nutzt da es Fälle gibt wo das technisch zu Problemen führt - also VORHER beim Hersteller informieren wieviele Controllbären der Bärenart jeweils parallel unterstützt werden in einem Brett bzw. in oi OS.

Beste Grüße
Bummibär