[Kaufberatung] Strategiefrage für semi-prof. Server-Infrastruktur (SOHO)

[Elioth]

(Hinweis vornweg: es geht zunächst nur um die grds. Auslegung, nicht um technische Detail-Lösungen der einzelnen Anforderungen, das würde vermutlich den Rahmen eines Threads sprengen und außerdem gibt es dazu ja wirklich hilfreiche Threads hier im Forum)

Hallo,

ich bin derzeit dabei, mir für Zuhause eine SOHO Arbeitsumgebung für ein vortuelles Team aufzubauen.

nachdem ich nun diverse Modelle von AIO Lösungen im Forum gelesen habe, stellt sich mir mehr und mehr die Frage, ob meine (zugegeben etwas eingerostete) Architektur-Idee nicht an meinem Ziel vorbeischießt.

Nun ist die Zeit, in der ich noch Serverlandschaften bis zum Rechenzentrum entworfen habe cirka 18 Jahre vorbei, die Technik jedoch hat sich ganz offensichtlich erheblich weiterentwickelt und viele Paradigmen von "damals" sind heute schlicht überholt (und ich damit wohl leider auch )

Dennoch möchte ich mir eine Arbeitsumgebung für mich und ein größtenteils "virtuelles" Team von max. 10 Leuten schaffen, um zukünftig wieder vermehrt unabhängig von Lokation und Zeit zusammenarbeiten zu können an sowohl technischen als auch betriebswirtschaftlichen Themen/Projekten.
Die private Datenhaltung mischt sich dabei ein wenig rein (wie unten schwer zu übersehen...).

Ausgangssituation:
Einfamilienhaus mit 2 separaten Arbeitszimmern (SOHO), Wohnzimmer, Gigabit-Verkabelung im Haus, Serverschrank und Platz im Keller
(Internetanbindung ist Lokationsbedingt eher schlecht bei 20-30Mbit down und ca 10Mbit up - ja das ist LTE, jedoch ohne Drossel)

zur grds. Anforderung:
- Fileserver/NAS (Datenmenge vermutlich um ca. 10 TB)
für maximal 10 Dialoguser, lokal und per VPN
für aufgenommene Videos (SAT-Aufnahmen aus der VU, Websession-Mitschnitte, Video-Surveillance, eigene Videos)
für sowie ggf. die Daten unten stehender Applikationen

- Archiv-System (Hotplug SATA, um Medien zu tauschen?) oder was gibt es für den SOHO Bereich, um preiswert Datensicherung zu betreiben, Bandsysteme sind vermutlich nicht mehr das Übliche? Für Dokumente (ca 1TB) und Entwicklungen (??) sollte eine (für Datenrost unempfindliche) Lösung für langfristige Ablage (5-10 Jahre) her.
Von den ca 10 TB (siehe oben) sind vermutlich 5 TB Daten, bei denen eine gelegentliche Sicherung ausreicht (gekaufte Musik, Filme, E-Books etc.)
für das Backup könnte ich mir vorstellen, von den anderen Servern Snap's auf das NAS zu machen und dieses wiederum auf ein Archivsystem (ebenfalls NAS?) mit SATA-Platten zu sichern

- SQL-Server (PosgreSQL)

- 3-4 produktive TomCat Applikationen (z.B. Atlassian Confluence/Jira) mit Proxy nach "draussen" (Apache proxy und SSL) (jede davon benötigt etwa 2GB an RAM)

- LAMPP für den Test von Web-Solutions (E-Shop, CMS, eigene Solutions): eventuell mit Containern, um möglichst unkompliziert auf ein Produktivsystem in der Cloud releasen zu können?

- ERP-System

- Hausautomation/-kommunikation (Heizungs-Steruerung, Türsprechsystem etc.)


Da hier völlig artfremde Anwendungsgebiete nebeneinander stehen, will ich eine möglichst gute Kapselung erreichen
Auf der anderen Seite sollen Rechenleistung, Speicher sowie Storage möglichst effizient genutzt werden und nicht brachliegen Die Systeme werden kaum bis keine gleichzeitige Nutzung erfahren, da sie im wesentlichen zu Laborzwecken aufgesetzt werden.

Zunächst fiel mein Auge "aus Gewohnheit" auf eine VM-Lösung (EsXi) und so auch recht schnell auf Gea's (NAPP-IT) AIO-Systeme mit VM's und Storage(VM) auf einem Gerät.
Andererseits stellt sich mir die Frage, ob das für meine Zwecke nicht overengineered wäre und ob eine 2 Server Lösung sich eventuell als skalierbarer darstellen könnte:
- NAS (z.B. HP-Mikroserver Gen8)
- Datenbanken + Applikationsserver (VM oder Docker oder???) Ablage der Daten ggf im NAS

ggf auch eine Mischung aus wenigen VM's und Container-Lösungen innerhalb einer der VM's?

Ich denke, dass die Anforderung in ähnlicher Weise bei einigen von Euch schon zu Lösungen geführt hat und würde gern von Euch Anregungen erhalten, bzw. in Erfahrungsaustausch treten, welche Vor- und Nachteile die verschiedenen Systemarchitekturen auch abseits von VM's und Bare-Metal haben, bevor ich mich mit unausgegorenen Anforderungen an einen Dienstleister wende.

Danach kann ich mich an die Systemskalierung machen und aus den hervorragenden Hilfe-Threads hier im Forum Hardware-Ideen zusammenstellen.

Danke im Voraus für jede Anregung.

 

[Luckysh0t]

So "overengineered" würde ich Gea's AiO Konzept gar nicht sehen in dem Fall.
Mit den entsprechenden Pools (HDD und SSD) je nach Zweck.
Zumal die HW ja durchaus Flexibel ist, wenn man sich das Handbuch von Gea durchliest.

Vlt. noch einen zweiten als direktes Backup (Bare Metal OmniOS/Napp-it?) und ggf Offsite Backup der Daten und gut.

Gerade ZFS würde den Daten ganz gut tun.


Aber das wäre nur meine Grundidee, andere könnten hier bessere Konzepte haben.

Die Frage ist eher wäre das AiO Konzept für diese Zwecke geeignet ? Lab vs. Produktiv.
Das dürfte Gea deutlich besser beantworten können - ggf. auch andere.

 

[Elioth]

Danke Lucky für ein erstes Feedback,

"overengineered" ist möglicherweise auch nicht ganz treffend von mir gewählt gewesen. Mich quält eher die Frage, ob für meinen Einsatzzweck das/ein AIO nicht zu komplex würde und zwei dedizierte Systeme für Storage und Applikationen eventuell besser skalieren würden.

Ein Online-Backup/Mirror ist - glaube ich - nicht nötig, da ein Ausfall von mehreren Stunden oder gar 1-2 Tagen derzeit nicht kritisch ist. Lediglich der Datenverlust als solches muss sicher verhindert sein, daher würde ich auf ein Spiegelsystem - zunächst - aus Kostengründen verzichten.
Edit: Oder meintest Du eventuell einfach ein zweites (anderes) Napp, um darüber dediziert Backups zu fahren? Dann hatte ich das ev. zunächstmissverstanden.

Offsite Backup klingt gut, da so auch Brand oder Diebstahl einigermaßen abgesichert wären. Da meine Datenleitungen eher schmalbrüstig sind, stellt sich hier die Frage nach einer geeigneten Strategie (Medien extern lagern und regelmäßig tauschen?)

ZFS wäre definitiv auf meiner Wishlist, da in Zusammenhang mit der richtigen Hardware ZFS scheinbar sehr gut Datenkorruption mindern kann.

 

[CaptainBlack]

Hallo,

ich würde alles, was produktiv genutzt wird, um zum Unternehmenserfolg beiträgt, in die Cloud legen. Hier würde sich bspw. Microsoft anbieten:
Preise – Cloudspeicher | Microsoft Azure

Ich würde nichts, was nach außen geöffnet ist und geshared werden soll mit LTE oder einem Privatkundenanschluss anbinden. Genauso die Applikationen, die nach außen erreichbar sein sollen - hier würde ich auf klassisches Hosting setzen. Auch hier gibt es eine Vielzahl von Anbietern.

Für Heimautomatisierung die Spielwiese zu Hause würde ich weiterhin auf ESX, Proxmox, oder Microsoft als Hypervisor setzen und auf einen separaten Fileserver. Von dem Fileserver ggf. kritische Daten per cron in die Cloud speichern lassen, nach Bedarf mit Verschlüsselung. Ggf. eine zweite Box bei einem Freund/Freundin/Elternteil aufstellen und hierauf sichern.

Auch aus Sicherheitsgründen macht es nicht unbedingt Sinn, das Heimnetz zu öffnen, wenn das nicht sein muss. Ich würde versuchen, hier die berufliche Nutzung von der privaten Nutzung zu trennen.

 

[gea]

Danke Lucky für ein erstes Feedback,

"overengineered" ist möglicherweise auch nicht ganz treffend von mir gewählt gewesen. Mich quält eher die Frage, ob für meinen Einsatzzweck das/ein AIO nicht zu komplex würde und zwei dedizierte Systeme für Storage und Applikationen eventuell besser skalieren würden.

.

AiO hat eine sehr geringe Komplexität wenn man auf ESXi setzt. Installation und Betrieb bedeutet lediglich ein .ova Template zu importieren und die benötigten Storagedienste NFS, SMB oder iSCSI zu aktivieren. Das Komplexeste sind Hardwarevorraussetzungen wie vt-d und ein dedizierter Storagecontroller/HBA.

CPU Performance ist mit aktueller Hardware kaum ein Theme. Die zusätzliche Storage VM dürfte da kaum ins Gewicht fallen. RAM mäßig sieht das anders aus. ZFS wird mit mehr RAM schneller (=readcache). Ein virtualisiertes Storage sit aber fast genauso schnell wie ein Extra Server wenn beide den gleichen RAM haben.

 

[besterino]

Werfe mal das Beste aus beiden Konzepten in den Ring: 2x Metall mit 2x ESXi mit 2x Storage VMs. Eine Kiste als Main-Filer mit dem performance Pool und eher privaten (nicht so performance hungrigen) VMs, die andere Kiste ebenfalls mit einer Storge-VM - diese aber nur für Backup) und dafür den Haupt-VMs. Beide verbunden über 10gbit hast du durch die Verteilung auf 2 Systeme zumindest für SOHO Use auch keine spürbaren Nachteile dadurch das VM und Mainstorage auf unterschiedlichen Systemen liegen. Mit Solarish+Nappit jeweils in den Storage VMs hast Du Dein Storage sauber und mit Replikation auch direkt ein vernünftiges Backup inkl. Snaps und Versionierung.

Die beiden Kisten kannst du dann eben auch auf Wunsch nach Haupteinsatztweck auslegen (Rechenpower+RAM vs Storage-Platz).

Bin mit meiner so konzipierten Lösung dazu eigentlich ganz happy: mein Mainfiler ist ein "alter" E3v1 mit 32 GB (davon 16GB für die Storage VM) und nen Haufen Platten/SSDs auf dem so billo VMs laufen, der Main-VMHost ist ein aktueller E3v5 mit 64GB und genau einer SSD für OS (und Storage VM) sowie einer dicken Archive HDD für eben das Backup.

 

[tbol]

Die grundsätzliche Frage, die sich mir stellt, ist die inwiefern der TE bereit selbst Hand anzulegen. Oder auch: Appliance vs Eigenbau

 

[Elioth]

Hallo,

danke für Eure Kommentare.

@Black:
Ja, die produktiven Systeme sollten auch in die Cloud, Azure oder Amazon, da bin ich noch nicht sicher. Ursprünglich wollte ich die Vorversion für interne Tests und Setup lokal liegen lassen aber im Grunde hast Du Recht - das macht auf einer Endkundenleitung keinen rechten Sinn. Somit reduziert sicher die Last auf dem System schon mal nicht unwesentlich. Dennoch würde ich gern di.e Systeme zum vorab Evaluieren durch mich selbst zunächst lokal laufen lassen.
Ich bin leider lange aus dem Thema raus und muss mich insbesondere in Cloud-Virtualisierung und dessen neue Möglichkeiten sowie verschiedene Anbieter erst einlesen. Sehr gut gefallen hat mir allerdings TurnKey Hub, vor allem weil mir die gewitzte Nutzung von Spaces mit Docker ganz gut gefallen könnte.

Am wichtigsten ist es mir ehrlich gesagt, dass ich lokal ein System gekapselt aufsetzen kann und es anschließend in eine geeignete Cloud-Umgebung zu schubbsen vermag. An Turnkey gefällt mir die DAU-fähige Administration. Vielleicht gibt es aber von Euch bessere Vorschläge.

@besterino:
Ja, das ist ein ziemlich passend klingendes Setup, so hat man Redundanz und trotzdem sind beide Kisten jeweils auf eine Sache spezialisiert. Ich glaub, das Konzept würde ich gern bei mir vorsehen.
@tbol:
Die Frage nach selbst Hand anlegen wird wohl in erster Linie in Folge dieser Diskussion beantwortet. Ich bastele, wenn es notwendig ist - nicht des Bastelns wegen. Bislang kann man wohl schon mit einiger Sicherheit sagen, dass ich keine Slackware aufsetzen werde, sondern bei der Software/OS eher auf gut etablierte und verbreitete Systeme setzen werde, wo ich auf den Lesefundus insbes. hier und in anderen Foren zurückgreifen kann. Bei der Hardware bin ich nicht sicher, allerdings sehe ich schon große Vorteile in einem C236-Mainboard mit einem Xeon drauf und 16GB ECC, da ich so ganz brauchbare Unterbauten haben dürfte. Bei der Storagemenge komme ich vermutlich noch mit 6 SATA-Platten gut hin (wie gesagt max 10TB derzeit vorstellbar). Ich denke da derzeit an 4 6TB WD-Red o.ä., sowie eine SSD, da ich was von SLOG-Device für SSD glesen zu haben meine. Das System kann ich vermutlich auch von einer SD Karte laden, Zugriff auf die Karte im Betrieb ist vermutlich eher selten?

Dazu braucht's vermutlich noch eine Backplane (Icy-Dock 4in3?) und ggf. für den Filer ein Hotplug für eine (e)SATA Platte zum Sichern.
Gehäuse wird vermutlich ein altes Serverghehäuse, welches ich in den 19" Schrank schraube.

Scheinbar abgeraten wurde ja wohl von der Variante, sich irgendne brauchbare Fertig-NAS hinzustellen und zusätzlich eine VM-Kiste, die dann die NAS neben den Desktops als Filer benutzt (also für die DB's und für die Images zb.)

Paar grunds. Entscheidungen:
- ECC, must have - der Mehrpreis ist moderat und ein Server hatte früher "immer" ECC. Heute sind die geschaufelten Datenmengen viel mehr und damit ist ein Error wahrscheinlicher.
- ZFS, scheint derzeit nach meinem Lesestand wohl die "einzig" wirklich saubere Filesystem Variante zu sein, wenn es um zuverlässige aber noch überschaubare Storage geht?
- Bevorzugtes Konzept (aka Gea oder besterino): VMs/Filer auf einem Host-System. Filer benötigt dann ja direkten Plattenzugriff, um damit brauchbar arbeiten zu können.
- Vorzugsweise NICHT EsX(i). Ich kenne es zwar von früher aus dem Rechenzentrums-Betrieb, würde aber vor allem gern was "offenes" ausprobieren, zu dem es auch professionelle Supportpläne gibt. Proxmox ist mir hier aufgefallen, vor allem, weil u.a. Container (leider noch kein Docker) nativ unterstützt werden. Bei ESX geht ja das Durchreichen von Controllern (insbes. LSI2008 u.ä.) ja sehr leicht, wie verhält sich das bei Proxmox oder anderen Alternativen?

Was wäre die wohl sinnvollste Möglichkeit, wenn es neben den Vorzügen von ZFS, was die Zuverlässigkeit anbelangt auch noch eine Erweiterbarkeit des Volumes als nützlich erachtet?

Soweit ich gelesen habe, ergeben sich einige Paradigmen bei ZFS, daher noch mal zum Check als Frage:
- Nutze ECC (sehe ich für einen Filer eh als Pflicht)
- KEINE Hardware-Raids. Das galt aber unter Linux oft wohl auch ohne ZFS?
- wie ich verstanden habe, kann man ein erstelltes ZVol nachträglich nicht erweitern?


Also mal meine Gedanken zusammenfassen:

Büchse:
- Storage 4x6TB SATA (erweiterbar auf 6x6)
- Intel C236 mit 16GB ECC und Xeon 1220 v5 o.ä., solche Mainboards haben Intel-NIC's meist schon onboard
- 450 Watt Netzteil, vorerst nicht redundant (Kosten).
- Gehäuse 19" vorhanden
- SD-Karte, USB Stick o.ä. für Host-System (esx, Proxmox o.ä.)
- SATA-Controller des MB komplett an Filer-VM durchreichen
- 4GB RAM für den Filer (ggf. auch 8GB), Rest(12/8) für zunächst 3 VM's, die im Zweifelsfalle nicht alle gleichzeitig laufen müssen (LAB)
- 2 "VM's" wären reine Tomcat-Applikationen, eine weitere wäre ein PosgreSQL Server, der die beiden bedienen soll. Bei den Tomcat-Apps frage ich mich, ob ich dafür auf eigene VM's verzichten kann und stattdessen mit Containern kapsele?

Datensicherung würde ich gern verschlüsselt in einen Cloudspeicher machen sowie zus. 3 Versionen (2 Folgetage, sowie ein Monats-Backup) auf manuell entnehmbaren zusätzlichen Archiv-HDD's (Gibt es zu HDD'S als Archiv heute noch sinnvolle Alternativen? Früher waren Bänder das Mittel der Wahl für dauerhafte Daten"ablage".) Gibt's andere sinnvollere Backup-Strategien? Videos und Musik würde ich natürlich gern aussen vor lassen, zu denen existiert immer das Original als "Backup". Außerdem sind die nicht wichtig genug. Da jammert höchstens mal die Madame.

- USV: muss nur ausreichen, um die Kiste bei Bedarf automatisch und sicher runterzufahren. Die Idee ist, wenn später das redundante Netzteil im Server ist, dieses nur mit einem Anschluss an die USV zu klemmen, den anderen direkt zu versorgen. Bei AIO ohne Failover kann ich auf USV für den Switch vermutlich erstmal verzichten.

 

[MicroCane]

Was wäre die wohl sinnvollste Möglichkeit, wenn es neben den Vorzügen von ZFS, was die Zuverlässigkeit anbelangt auch noch eine Erweiterbarkeit des Volumes als nützlich erachtet?

Hardware-Raid oder fertiges Storage eines namenhaften Herstellers.

Damit kannst du ein sauberes System aufbauen, hast alles in einer Kiste und auch eine gute Performance. HP-Server wären da meine Empfehlung.

 

[the_pi_man]

Hardware-Raid und ZFS mögen sich aber nicht wirklich... Außerdem ist auch ZFS erweiterbar, aber (im Moment) noch nicht Plattenweise, sondern man steckt eben doch ein weiteres vdev nach und freut sich.

 

[MicroCane]

Ich meinte auch nicht Hardware-Raid und ZFS mischen. Hardware-Raid kann die gleichen Vorzüge mit Checksummen usw. mitbringen.

 

[Digi-Quick]

Bitte Aussage belegen und Controller benennen!

 

[MicroCane]

https://www.hpe.com/h20195/v2/GetPDF.aspx/c04111534.pdf

HP P420

"Dynamic Sector Repairing continually performs background surface scans on the hard disk
drives during inactive periods and automatically remaps bad sectors, ensuring data integrity."

 

[gea]

Ich meinte auch nicht Hardware-Raid und ZFS mischen. Hardware-Raid kann die gleichen Vorzüge mit Checksummen usw. mitbringen.

Ähm - nein: kann Hardwareraid eben nicht.
Dateisystem-Prüfsummen sind Prüfsummen auf den tatsächlichen Daten/ Metadaten und erkennen alle Daten-Veränderungen, auch die die erst durch Kabel, Backplane, Controller oder Treiber entstehen.

Platten-interne Prüfsummen arbeiten z.B. auf Byte-Ebene. Controller Prüfsummen auf Raid-Stripe Ebene. Beide können größere Veränderungen nicht rekennen/ reparieren. Sind nach einem Absturz beim Schreiben oder wegen bitrot z.B. die beiden Hälften eines Mirrors nicht identisch, so kann dieser Fehler auf Controllerebene nicht entdeckt/repariert werden. Der Raidcontroller könnte allenfalls entdecken, dass beide Mirrorhälften unterschiedlich sind, könnte aber nicht feststellen welche Hälfte valide ist. (Nennt sich Write-Hole Problem und entsteht weil im Raid die Platten nacheinander geschrieben werden und es keine Sicherung gibt um teilweise Updates zu verhindern, erst CopyOnWrite Dateisysteme machen das möglich)

Sicheres atomares Schreiben muss im Dateisystem angelegt sein. Transaktionssicherheit ist durch den Controller nur rudimentär zu gewährleisten (Controller mit Cache und BBU).

Das können erst ZFS oder btrfs und ReFS wenn man da Daten-Prüfsummen zusätzlich aktiviert.

 

[underclocker2k4]

@Cane
Man muss sich das Thema Prüfsumme wie im Osi-Modell vorstellen. Letztendlich kann nur der Anwender bewerten, ob die Daten korrekt sind. Alle Ebenen bis runter auf das einzelne phys. Bit können allenfalls für sich und die Ebenen darunter die Konsistenz bewerten. Alles was von oben kommt, sieht für diese Ebene korrekt aus, weil sie es eben nicht besser weiß.

ZFS und Co ist eben der "Versuch" diesen Effekt näher zum Anwender zu tragen.

Daher ist deine Interpretation der HP-Aussage falsch. Wenn dem Controller (beabsichtigt oder unbeabsichtigt) in der kompletten Kommunikationsstruktur irgendjemand sagt, er soll aus der 1 eine 0 machen, dann tut er das. Für ihn ist das korrekt und er wird das auch so auf die Platten packen. Im Umkehrschluss bedeutet das auch, dass er bei einem Scan auch denkt, alles OK, habe ich ja gemacht.
Diese Hardwarechecks sind quasi OSI-Layer 1 und nur für dieses ist das orrekt. Da aber heutige PCs 1000 Abstraktionsebenen besitzen, ist das in letzter Konsequenz inkorrekt.
Wenn du selber die Daten direkt auf die Platte packst, du alle Ebene umgehen würdest, dann wäre deine Aussage inkl. der HP Doku korrekt.
Da das aber heute keiner mehr macht/kann, muss das weiter oben stattfinden.

Wer sich mit hochintegrativen und persistenten Ethernetkommunikationen beschäftigt, wird irgendwann feststellen, dass es eigentlich reicht, wenn der Layer 7 eine Checksumme baut und nur diese noch relevant ist. (mit entsprechenden Reaktionsszenarien)
Dann können alle anderen Checksummen unten komplett entfallen und die Welt ist wieder schön. Wer aber oben nicht prüft, der wird nicht feststellen, dass auf dem Weg von halb unten bis nach ganz oben was kaputtgegangen ist.

 

[MicroCane]

Ah, klingt natürlich verständlich.
Die Frage ist natürlich in wie weit der Privatanwender oder kleine Unternehmer solche Strukturen braucht. Andererseits, wenn die Einrichtung relativ einfach ist, spricht natürlich nichts dagegen.

 

[besterino]

Meine Erkenntnis: wenn man sich einmal in ZFS/Solraish reingebissen hat, will man nichts anderes mehr. Replikation, snaps (Windows "kompatibel" mit vorheriger Version"), SMB, NFS, iSCSI (mit Comstar), Kompression und/oder Verschlüsselung nach Wunsch auf Pool- oder Dateisystem-Ebene bis hin zu Dedup (wer's braucht und es sich "leisten" kann), alles an Board ohne blödes Gefrickel in Konfig-Dateien und Inkonsistenzen zwischen den einzelnen Diensten/Features... wer nur Nas braucht, hat da eine sehr mächtige allzweckwaffe.

 

[Elioth]

Da das ganze wieder so ein wenig in Raid-Philosophie schwingt, zitiere ich mich hier doch kurz mal selbst:

Archiv-System (Hotplug SATA, um Medien zu tauschen?) oder was gibt es für den SOHO Bereich, um preiswert Datensicherung zu betreiben, Bandsysteme sind vermutlich nicht mehr das Übliche? Für Dokumente (ca 1TB) und Entwicklungen (??) sollte eine (für Datenrost unempfindliche) Lösung für langfristige Ablage (5-10 Jahre) her.

ein Ausfall von mehreren Stunden oder gar 1-2 Tagen derzeit nicht kritisch ist. Lediglich der Datenverlust als solches muss sicher verhindert sein, daher würde ich auf ein Spiegelsystem - zunächst - aus Kostengründen verzichten.
Edit: Oder meintest Du eventuell einfach ein zweites (anderes) Napp, um darüber dediziert Backups zu fahren? Dann hatte ich das ev. zunächst missverstanden.

Offsite Backup klingt gut, da so auch Brand oder Diebstahl einigermaßen abgesichert wären. Da meine Datenleitungen eher schmalbrüstig sind, stellt sich hier die Frage nach einer geeigneten Strategie (Medien extern lagern und regelmäßig tauschen?)

ZFS wäre definitiv auf meiner Wishlist, da in Zusammenhang mit der richtigen Hardware ZFS scheinbar sehr gut Datenkorruption mindern kann.

Datensicherung würde ich gern verschlüsselt in einen Cloudspeicher machen sowie zus. 3 Versionen (2 Folgetage, sowie ein Monats-Backup) auf manuell entnehmbaren zusätzlichen Archiv-HDD's (Gibt es zu HDD'S als Archiv heute noch sinnvolle Alternativen? Früher waren Bänder das Mittel der Wahl für dauerhafte Daten"ablage".) Gibt's andere sinnvollere Backup-Strategien?

@Datensicherung:
Hier steht also der Fokus, zum einen Maschinenkonfigurationen und -zustände als wiederherstellbare Snaps anfertigen und lagern zu können, auf der anderen Seite, Business-Dokumente (Office, Zeichnungen, Codes etc.) sicher und zuverlässig wiederzubeschaffen.
(Hier habe ich inzwischen bei Amazon Glacier interessante Optionen als Offsite Ziel gefunden.)

@RAID:
RAID sehe ich definitiv nicht als geeignete Strategie für Datensicherheit, sondern (im gewerblichen Umfeld) als Schutz vor Geräteausfall (Online-Redundanz). Da diese für mein Szenario zu vernachlässigen ist, jedoch die Wiederbeschaffbarkeit und der Schutz meiner Daten eher sehr wichtig ist, sehe ich momentan noch keine besonders schlagkräftigen Argumente für ein RAID in meiner Lösung. Korrigiert mich, wenn es Aspekte FÜR Raid an dieser Stelle gibt. Das Thema BBU ist dabei für mich irrelevant, da ich zum einen für den Preis eines HW-Controller MIT BBU ne ganze USV kaufen kann und ohnehin selbst eine BBU nicht alle Probleme beim Stromausfall löst.

@ZFS:
ZFS wiederum hat einen Ruf, Schreibfehler gut zu verhindern (zumindest sagt man ihr das nach) und das scheint ja auch einer der Premiumaspekte FÜR den Einsatz von ZFS zu sein. Ich frage mich insofern, ob ich nicht selbst unter ZFS auf den Einsatz eines RaidZ verzichte und stattdessen ein JBOD ähnliches Konstrukt ohne Redundanz aber dennoch der Möglichkeit sinnvoller Snaps existiert.

Leider ist es mir in vergangenen Jahren zwar selten aber dennoch zu oft vorgekommen, dass aus einem wieder eingespielten Backup anschließend 4-5 Dateien nicht lesbar waren und nur teilweise ohne Verluste wieder hergestellt werden konnten. (Hierbei war oft hinterher nicht mehr 100% feststellbar, wann und wo die Korruption der Datei wirklich aufgetreten ist) Bei hunderttausenden Dateien erscheint das lapidar, nicht jedoch, wenn es DIE entscheidende Datei ist, die man gerade benötigt. Hier half dann oft nur noch die Recovery der Datei aus anderen Backup-Versionen (was dann zur Folge hatte, nicht immer das aktuellste Backup zu haben). Noch schlimmer ist die Situation, wenn man an einer vermeintlich lesbaren Datei weiterarbeitet und erst nach Monaten stellt sich heraus, dass ein kompletter Abschnitt der Datei doch korrupt war. Und an der Stelle scheint zumindest die Solaris Gemeinde wenigstens das Problem verstanden zu haben.

Der andere Aspekt dieses Threads, NAS und VM-Ho(r)st zusammenzulegen, ist genaugenommen eine ganz andere Diskussion und dazu haben ja z.B. Gea, Black und Besterino schon ein paar Hinweise gegeben. Mich interessieren an dieser Stelle natürlich Hinweise, ob und in wie weit quelloffene Alternativen zu ESXi (wie z.B. Proxmox) da angebracht wären, wenn es denn eine AIO Lösung (NAS+Host für VM's und Container) sein soll

Zum Thema Denkanstoß Verteilung produktive Landschaft und LAB hat mir Gottseidank Black ganz am Anfang einen Schuß vor den Bug gegeben und mich zum Denken angeregt

 

[Digi-Quick]

@ZFS:
ZFS wiederum hat einen Ruf, Schreibfehler gut zu verhindern (zumindest sagt man ihr das nach) und das scheint ja auch einer der Premiumaspekte FÜR den Einsatz von ZFS zu sein. Ich frage mich insofern, ob ich nicht selbst unter ZFS auf den Einsatz eines RaidZ verzichte und stattdessen ein JBOD ähnliches Konstrukt ohne Redundanz aber dennoch der Möglichkeit sinnvoller Snaps existiert.

Um ZFS in "voller Pracht" geniessen zu können braucht es Redundanz (Also Mirror oder Raidzx). Ohne Redundanz verlierst du die Eigenschaft der Selbstheilung, Du bekommst dann nur die Meldung Dazei xyz ist korrupt.

 

[Elioth]

Danke Digi-Quick.

Die Antwort leuchtet ein und gibt mir den nötigen Input. Bei 4-6 Platten, wäre da ein Z1 anratenswert? Wie gesagt, den grds. Schaden bei Ausfall von Platten sehe ich unkritisch, ist keine 24/7 Server-Lösung, wo Ausfall nunmal sofort Geld kostet.

 

[besterino]

Das ist so nicht ganz richtig. Man kann ZFS zumindest unter Solarish m.W. auch dazu bringen, auf einem Pool ohne "Redundanz auf Disk-Level" - also z.B. Pool aus nur 1 HDD - glaub Daten und/oder die Metadaten/Checksums 2x abzulegen. Hilft aber eben dann auch nur bei partiellen Ausfällen z.B. auf Sektorebene und ist damit nur zweite Wahl. Ist die Platte richtig platt, hilfts halt gar nicht mehr.

100% kenn ich mich da aber auch nicht aus, selbst noch nie ausprobiert.

 

[Digi-Quick]

Ob die Prüfsumme nun 1, 2 oder 10 mal vorhanden ist spielt keine Rolle. Die Daten sind ohne Redundanz nicht rekonstruierbar, die entsprechende Datei ist korrupt.

Ja, Raidz1 würde ich unter den gegeben Vorbedingungen in Sachen Verfügbarkeit als Ausreichend ansehen, wenn das Backup sicher (!) wiederherstellbar ist. Ein Backup auf genau einem Datenträger ist nicht sicher wiederherstellbar - nach Murphy fällt dieser genau dann aus, wenn er gebraucht wird.

 

[Elioth]

Also benötige ich vornehmlich Plattenredundanz, um die "Selbstheilung" bei ZFS auf Blockebene oder Dateiebene zu ermöglichen(?). Dann sollten vermutlich einfache Redundanzen ausreichen, um das zu erreichen?
Also der Platteneffizienz wegen dann RAIDZ1 mit 5 Platten? oder lieber einen Spiegel mit 6 Platten (Raid10 - wie hiesse das dann eigentlich unter ZFS oder ist das da einfach nur ein Stripe-Pool über Mirror VDEVs?)?
Wie gesagt, Platten-Totalausfall, der ja zum Crash führen dürfte, ist für mich (derzeit) unerheblich, da hier dann eh das Backup greifen muss. Ich will nur Datei- oder Block-Beschädigung vermeiden/reparieren. Alles wirklich Produktive läge ja eh langfristig in der Cloud und ist dort vor Hardware-Problemen besser gesichert, als ich es je könnte.

Wichtig ist mir, dass die Daten auf dem NAS beim Speichern möglichst nicht beschädigt werden können und dort auch unbeschädigt bleiben. Ein kompletter Plattenausfall ist unkritisch, da ich das ja merke und dann ein Backup habe. Blöd sind schleichende Fehler, nach 12 Monaten machst eine Datei wieder auf und ätsch, Datei beschädigt. Das will ich verringern - unter NTFS kam mir das noch zu oft vor, ECC war damals in den Büchsen schon drin, Gelagert wurde auf RAID5 oder RAID1+0. Leider kam es dann (selten) vor, dass ein Dateifehler es bis auf die DAT-Bänder geschafft hatte.

Backup wird auf Platten geschubbst (3 Versionen = heute, gestern, letzte Woche)
Zusätzlich will ich das Ganze in Glacier ablegen, wo ich die Wahrscheinlichkeit für Data-Korruption noch kleiner ansehe. Überlegen muss ich mir hier noch, wie ich möglichst komfortabel direkt beim Backup zu Glacier verschlüssele.
Zusätzlich sollen Dokumente/Quellcodes noch 1/Monat irgendwie optisch gesichert werden (Band/dvd oä.). Damit sollte eine verhältnismäßig hohe Wiederherstellbarkeit gewährleistet sein.

als Laie würde ich sowas mit Rsync machen. Ist das der richtige Ansatz?

Zu sichern wären natürlich zunächst mal die Daten-Laufwerke. Da sind natürlich alle Dokumente (Office, PDF, Bilder, HTML) also alles gut komprimierbarer Kram.
DB-Server + DB's, "produktive" VM's gehören mMn. gesichert wie die o.g. Dokumente.

Filme/Musik, Steam-Backups sollen nicht extern gesichert werden, sondern sollen wenn möglich nur auf eine einzelne Archiv-Platte (viel Datenmenge mit wenig Nutzwert, außerdem gibt es im Regal noch das Original, eine aufgenommene Serie wird zeitversetzt geguckt und dann gelöscht).

Von den ca. 3-4 Client-Betriebssystemen (Desktop-PC's mit Windows oder Linux sollen nur die Systempartitionen gesichert werden, installierte Spiele sind nicht sicherungswürdig, da neu installierbar (Werden per order de mufti auf Extra-Partition installiert). Mit der Systempartition sind m.E. die Apps schon mitgesichert, da ebenfalls i.d.R unter Win auf C:\Program Files installiert.



Da ich es immer vermieden habe, mich in Basis-Details einzumischen (diese Leute wissen i.d.R. besser, was zu tun ist), jedoch die Investitionen zu entscheiden hatte, gibt mir mein berufl. Hintergrund leider auch nur oberflächliches Know-How zu diesen Themen. Nun brauch ich das leider für mich privat, da ich meine eigene Umgebung jahrelang sträflich vernachlässigt habe. Außerdem mag ich ein paar private Projekte vorantreiben, wobei ich eben jende Datenbanken sowie VM's zunächst lokal benötige - nach ersten Schritten "zuhause" kommen die dann in die Cloud, damit mehrere Leute daran rumfrickeln können. Zu dem Zeitpunkt kommen dann eh neue Fragen auf mich zu, da sich insbes. neue Herausforderungen der Einbruch-Sicherheit dabei ergeben. Aber Zukunfts-Musike momentan.

 

[Elioth]

noch paar Fragen in Bezug auf das Thema Virtualisierung:

1. Wenn es nur Fileserver/Storage wäre: Würdet Ihr dennoch virtualisieren oder dann lieber Baremetal?
pro Virtualisierung spräche vermutlich leichtere Portierbarkeit, sowie Skalierung?

2. Angenommen, ich gehe in Richtung des NAPP-Modells
Hypervisor (durchgereichte Platten-Controller, HBA)?
Storage-VM (greift über VT-D auf den durchgereichten HBA)?
Storage VM System (zb VMDK) liegt auf extra Platte (nicht durchgereicht)?
Storage VM LAN über internen vSwitch?
andere VM's greifen per (iSCSI, NFS?) auf die Storage VM Volumes zu?
andere VM Systeme liegen selbst auch auf den Storage VM Volumes?

3. Benötige ich für die Verschlüsselung der Online-backups in Richtung Glacier eine AES-Ni "fähige" CPU? Ein Xeon 1230 v5 kann das vermutlich eh

Habt Ihr Erfahrungen mit Alternativen zu ESXi gemacht? Speziell an Best und Gea: Was ist an ESXi das Killer-Argument, es quelloffenen Lösungen vorzuziehen?
Wie sieht es speziell mit ProxMox aus? Ich reite darauf rum, da mich insbes. Container sehr interessieren. Container kann ich vermutlich aber ggf. auch in einer Linux VM mittels Docker realisieren.

 

[ludwinator]

Ich würde da ja bedenkenlos zu Smartos greifen und mir das ganze HBA durchreichen etc sparen.
Windows mit KVM virtualisieren, CIFS, Linux und Docker in einzelnen Zonen. Hardware optimal genutzt.
Ergibt optimale Hardwareausnutzung, ZFS für Backup und Redundanz. ZFS Crypto ist nicht mehr weit, dann ist das auch noch dabei.
Einziger Nachteil: keine GUI, aber auch keine kastrierte Software wie ESXi.

 

[gea]

Ob die Prüfsumme nun 1, 2 oder 10 mal vorhanden ist spielt keine Rolle. Die Daten sind ohne Redundanz nicht rekonstruierbar, die entsprechende Datei ist korrupt.

Ja, Raidz1 würde ich unter den gegeben Vorbedingungen in Sachen Verfügbarkeit als Ausreichend ansehen, wenn das Backup sicher (!) wiederherstellbar ist. Ein Backup auf genau einem Datenträger ist nicht sicher wiederherstellbar - nach Murphy fällt dieser genau dann aus, wenn er gebraucht wird.

ZFS schreibt normalerweise einmal die Daten und zweimal die Matadaten. Ein defekter Sektor auf einer Platte führt damit zu einer defekten Datei aber zu keiner korrupten Struktur.

Mit der ZFS Eigenschaft copies=2 schreibt ZFS die Daten doppelt und die Metadaten vierfach pro Platte. Selbst bei einem defekten Sektor kann ZFS auch die Daten einer einzelnen Platte rekonstruieren.

Nachteil: Halbe Kapazität und ein Plattenausfall und alles ist weg.
Besser ist schon Redundanz auf Poolebene (Raid 1/Z)

- - - Updated - - -

noch paar Fragen in Bezug auf das Thema Virtualisierung:

1. Wenn es nur Fileserver/Storage wäre: Würdet Ihr dennoch virtualisieren oder dann lieber Baremetal?
pro Virtualisierung spräche vermutlich leichtere Portierbarkeit, sowie Skalierung?

2. Angenommen, ich gehe in Richtung des NAPP-Modells
Hypervisor (durchgereichte Platten-Controller, HBA)?
Storage-VM (greift über VT-D auf den durchgereichten HBA)?
Storage VM System (zb VMDK) liegt auf extra Platte (nicht durchgereicht)?
Storage VM LAN über internen vSwitch?
andere VM's greifen per (iSCSI, NFS?) auf die Storage VM Volumes zu?
andere VM Systeme liegen selbst auch auf den Storage VM Volumes?

3. Benötige ich für die Verschlüsselung der Online-backups in Richtung Glacier eine AES-Ni "fähige" CPU? Ein Xeon 1230 v5 kann das vermutlich eh

Habt Ihr Erfahrungen mit Alternativen zu ESXi gemacht? Speziell an Best und Gea: Was ist an ESXi das Killer-Argument, es quelloffenen Lösungen vorzuziehen?
Wie sieht es speziell mit ProxMox aus? Ich reite darauf rum, da mich insbes. Container sehr interessieren. Container kann ich vermutlich aber ggf. auch in einer Linux VM mittels Docker realisieren.

1. keine Virtualisierung, dann Baremetal.
ESXi braucht selber minimal CPU und ca 2 GB RAM. Auch ist eine virtuelle nic, selbst vom Kaliber einer vmxnet3s langsemer als eine echte nic

2.
Storage VM liegt auf lokalem vmfs datastore (z.B. ESXi Sata Bootplatte)
HBA + Disks per pass-through an Storage VM
ZFS Dateisystem als NFS Share -> ESXi Storage für andere VMs, SMB für copy/move/clone/Vorherige Version=Snaps
LAN zum Storage über vmxnet3s vnic/vswitch oder optional pass-through

3.
ok

4.
Hauptvorteil ESXi
- Vollvirtualsiserung mit schnellern Treibern (Tools, Grafik, vnic) für praktisch jedes OS
- best of all wenn es um pass-through geht
- geringstes Overhead, schnellstes Restore, kein Full Feauture OS, eher eine Firmware
- Man kann eine "große Storage Appliance" nehmen und nicht nur das ZFS Dateisystem per CLI
z.B. unter BSD FreeNAS/Nas4Freeoder unter Solarish NexentaStor, Oracle Solaris, OmniOS, OI opt. letztere mit napp-it

Für Linux Container dann entweder ein Linux auf ESXi oder LX Container unter OmniOS

 

[Elioth]

Ich würde da ja bedenkenlos zu Smartos greifen und mir das ganze HBA durchreichen etc sparen.
Windows mit KVM virtualisieren, CIFS, Linux und Docker in einzelnen Zonen. Hardware optimal genutzt.
Ergibt optimale Hardwareausnutzung, ZFS für Backup und Redundanz. ZFS Crypto ist nicht mehr weit, dann ist das auch noch dabei.
Einziger Nachteil: keine GUI, aber auch keine kastrierte Software wie ESXi.

Hi,

SmartOS war mir bislang nicht auf dem Schirm. Enthielte hier sogar Docker als Bonus. Übrigens habe ich keine Absicht, Windows zu virtualisieren, mir geht es nach wie vor um PC-Unixoide (Linux, Sol, BSD) und ggf. mal mobile Emulatoren für LAB-Usage. In erster Linie als Entwicklungsumgebung.

Was mir an ZFS noch besonders wichtig ist, ist das Durchreichen der autom. Snapshots an die SMB-Funktionen "prev versions" auf File-Ebene (damit man auch einzelne Files jederzeit rückrollen kann). FreeNas kann das z.B. von Haus aus.

Die Gui ist mir nicht ganz so wichtig (zumal die CLI eine weitere Fehlerquelle ausschliessen kann). Wichtiger ist mir die zuverlässige Umsetzung eben jener Standard-Features und ein gewisser Schutz vor eigener Dämlichkeit durch zumindest grundlegende Plausi-Checks bei Commands. Ideal ist natürlich, wenn ich HTML-Gui habe und alternativ jederzeit die CLI nutzen KANN Manchen GUI's schränken das leider ein, bzw. sind inkompatibel mit CLI-Einstellungen.

Fazit: Ich werd mich zumindest mal bei den Joyent Leuten umsehen und ein paar Artikel dazu lesen. Eventuell kommt das meiner Vorstellung bislang am nahesten (Filer, der gleichzeitig Hypervisor und Container-Server sein kann ohne Bedarf an Kilckibunti. Zumal man sich notfalls einfache Admin-Oberflächen bei ner sauberen CLI, sowie strukturierten Files (z.b. JSON) für einfache Arbeiten fix selbst gestrickt hat.

- - - Updated - - -

@Gea:

Ich weiß, in Schwaben sagt man "net gemeckert ist lob genug". Aber dennoch muss ich das mal in Deine und stellvertretend natürlich auch in Richtung vieler anderer fleißiger Poster hier loswerden:

Die Hilfe/Infos, die ich hier zu diversen Themen (und eben diesem hier im Speziellen) bereits bekommen habe, sind einfach beeindruckend. Ich weiß den hohen Aufwand, den Ihr betreibt, um Euer Wissen mit anderen Wissbegierigen zu teilen (!) sehr zu schätzen und möchte ganz expliziz mal DANKE dafür sagen und hoffe, mich in geeigneter Form mal revanchieren zu können.

Herzlichen Dank an Euch!

 

[Elioth]

Inzwischen bin ich etwas weiter gekommen und hab in einer freien Kaffeepause heute mal ein wenig über die Hardware nachgedacht.

Zunächst mal steht klar, dass es FreeNAS on BareMetal werden soll, der gleichzeitig als kleiner Docker-Host dienen soll. (Alternativ steht da noch SmartOS im Raum...) Für die Docker-Gäste wird der FreeNAS dann den Plattenspeicher als NFS oder iSCSI stellen. Für die Windows-Clients im Arbeitszimmer dann vermutlich direkt über die ZFS Eigenschaften (im FreeNAS brauchte es glaub ich kein SAMBA)
Offsite Backups gehen verschlüsselt in die Cloud (voraussichtlich Amazon oder Azure)
Für lokale Backups schwanke ich zwischen Festplatte beim Nachbarn und Server bei der Familie 800km entfernt.

Zur Hardware hab ich mir 2 Optionen überlegt.

1. Fertiger Gebrauchtserver aus dem Entry-Segment: Fujitsu RX300 S6 // 2x Xeon E5620, 48 GB RAM, gibt es für schwankend etwa 200 Euro ohne Platten. Dazu ein paar WD RED und aus die Maus.
2. Selbstgebastelter Kram: aus dieser Liste (enthält einige Alternativen) Homeserver Preisvergleich Geizhals Deutschland

nun kostet der Fujistu gerade mal 200 Euro. Leider sind mir weder Stromhunger noch ein Leistungs-Vergleich zu heutiger Xeon Genration (E3-1220 V6) wirklich klar. Als Vorteil beim Fujitsu sehe ich die hohe Erweiterbarkeit beim Speicher an (300+ GB) und dir recht gute Ersatzteilsituation (derzeit noch). Reg ECC ür den Fujitsu gibt es etwas günstiger, als die DDR4 ECC für die Selbstbauversion.

Was meint Ihr, welche Option ist nachhaltiger/sinnvoller? Für die 200 Euro gibt es ansonsten eher einen HP Microserver, der vermutlich etwas weniger verbraucht. Bei der Selbstbauoption kostet soviel schon der Prozessor. Ist der Fujitsu rausgeschmissenes Geld und ein Stromfresser oder ist der eine brauchbare Alternative auch heute noch?

Für's Ganze wäre dann noch eine Online oder zumindest Smart USV von Nöten. Was wäre da zu empfehlen? Sind die APC noch Stand der Dinge? Das Ding soll nur sauberes Runterfahren ermöglichen. Die USV würde also den Server sowie einen 3COM Switch puffern. Beim Server käme ein Netzteil an die USV, das andere als Standby direkt ans Netz.
Alles Längerfristige müsste sowieso ein Dieselaggregat übernehmen, denn was nutzt ein bestromter Server ohne Strom an den Clients? Internet ist zudem bei Stromausfall eh weg.

 

[Elioth]

Inzwischen bin ich etwas weiter gekommen und hab in einer freien Kaffeepause heute mal ein wenig über die Hardware nachgedacht.

Zunächst mal steht klar, dass es FreeNAS on BareMetal werden soll, der gleichzeitig als kleiner Docker-Host dienen soll. (Alternativ steht da noch SmartOS im Raum...) Für die Docker-Gäste wird der FreeNAS dann den Plattenspeicher als NFS oder iSCSI stellen. Für die Windows-Clients im Arbeitszimmer dann vermutlich direkt über die ZFS Eigenschaften (im FreeNAS brauchte es glaub ich kein SAMBA)
Offsite Backups gehen verschlüsselt in die Cloud (voraussichtlich Amazon oder Azure)
Für lokale Backups schwanke ich zwischen Festplatte beim Nachbarn und Server bei der Familie 800km entfernt.

Zur Hardware hab ich mir 2 Optionen überlegt.

1. Fertiger Gebrauchtserver aus dem Entry-Segment: Fujitsu RX300 S6 // 2x Xeon E5620, 48 GB RAM, gibt es für schwankend etwa 200 Euro ohne Platten. Dazu ein paar WD RED und aus die Maus.
2. Selbstgebastelter Kram: aus dieser Liste (enthält einige Alternativen) Homeserver Preisvergleich Geizhals Deutschland

nun kostet der Fujistu gerade mal 200 Euro. Leider sind mir weder Stromhunger noch ein Leistungs-Vergleich zu heutiger Xeon Genration (E3-1220 V6) wirklich klar. Als Vorteil beim Fujitsu sehe ich die hohe Erweiterbarkeit beim Speicher an (300+ GB) und dir recht gute Ersatzteilsituation (derzeit noch). Reg ECC ür den Fujitsu gibt es etwas günstiger, als die DDR4 ECC für die Selbstbauversion.

Was meint Ihr, welche Option ist nachhaltiger/sinnvoller? Für die 200 Euro gibt es ansonsten eher einen HP Microserver, der vermutlich etwas weniger verbraucht. Bei der Selbstbauoption kostet soviel schon der Prozessor. Ist der Fujitsu rausgeschmissenes Geld und ein Stromfresser oder ist der eine brauchbare Alternative auch heute noch?

Für's Ganze wäre dann noch eine Online oder zumindest Smart USV von Nöten. Was wäre da zu empfehlen? Sind die APC noch Stand der Dinge? Das Ding soll nur sauberes Runterfahren ermöglichen. Die USV würde also den Server sowie einen 3COM Switch puffern. Beim Server käme ein Netzteil an die USV, das andere als Standby direkt ans Netz.
Alles Längerfristige müsste sowieso ein Dieselaggregat übernehmen, denn was nutzt ein bestromter Server ohne Strom an den Clients? Internet ist zudem bei Stromausfall eh weg.

 

[Digi-Quick]

zum RX300:
Nach heutigen Maßstäben ist das Teil wohl eher als Heizung anzusehen, zumal reg. RAM zusätzlich deutlich stromhungriger ist, als Unbuffered ECC-DIMM.
Von der Rechenleistung her dürfte ein single e3-1220 v6 das Dual-CPU System insgesamt auch einholen, wenn nicht sogar überholen - ausgenommen sind vieleicht Anwendungsszenarien, die eher mit vielen Cores als mit Takt skalieren.

Rechenbeispiel:
50 Watt Mehrverbrauch bei 24/7 Betrieb - wobei 50 Watt eher zu wenig sei dürften - bei 2 CPUs und RDIMM dürfte der Mehrverbrauch ggü. einem aktuellem single CPU System mit UDIMM (oder LRDIMM) deutlich höher liegen.
0,05 KW * 24h/Tag * 365 Tage * 0,3 €/KWh = ca- 130 € Mehrkosten/Jahr >> das wären in 5 Jahren 650 €



Zu deinem Warenkorb:
Du solltest dich schon entsheiden, ob du viele HDD Einbauplätze haben willst oder nicht, die Differenz von 6 zu 24 ist doch recht heftig.
Bei https://www.xcase.co.uk/ gibt es eine recht grosse Auswahl an 19" Gehäusen, die deutlich preiswerter sind als gerade Supermicro.

Bedenke: jeder zusätzliche HDD Einbauplatz kostet Geld.
6-10 HDD-Einbauplätze (je nach Chipsatz und Mainboard) kann das Mainboard anbinden,
Darüberhinaus ist eigentlich immer ein zusätzlicher Controller erforderlich (kann auch schon auf dem Mainboard integriert sein)

Wenn du schon mit viel RAM liebäugelst, solltest du wenn schon denn schon gleich auf So2011-3 gehen da kannst du auf RRDIMM oder LRDIMM ausweichen, wenn dir die maximal 128GB UDIMM nicht reichen - und auch dass ist schon doppelt so viel wie bei So1151:
z.B.
CPU
Intel Xeon E5-1620 v4, 4x 3.50GHz, boxed Preisvergleich Geizhals Deutschland
Mainboard_
Fujitsu D3348-B Preisvergleich Geizhals Deutschland
bis 256 GB RDIMM/LRDIMM
Supermicro X10SRL-F retail Preisvergleich Geizhals Deutschland
bis 256 GB RDIMM / 512 GB LRDIMM