Homeserver als NAS Ersatz

Das heisst: 2x Adaptec mini SAS HD x4 (SFF-8643) auf 4x SATA (SFF-8448)
6x an die HDDs
1x an das Wechselding
und einer bleibt frei!

Noch eine grundsätzliche Frage zur Virtualisierung. Ich kannte bis dato nur ESXi. Ist das die erste Wahl oder wäre z. B. Virtual Box von Oracle besser geeignet. Ich denke diese Entscheidung ist essentiell, alle anderen darauf gepackten VM's kann man dann ja testen - z. B. FreeNAS vs. OMV ...
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Virtualbox braucht ein darunter liegendes OS, ist also eher in Betracht zu ziehen, wenn Virtualisierung eine willkommene „Nebensache“ ist und nicht der primäre Einsatzzweck des Metalls.

Wenn da eine 24/7 Storage-VM laufen soll, wäre ich persönlich in jedem Fall bei einem Typ-1 Hypervisor wie eben ESXi, Hyper-V, Proxmox, Xen & Co.
 
Zuletzt bearbeitet:
Die Aussage trifft für ZFS nur bedingt zu, da man hier i.d.R. die LZ4 Kompression auf dem Pool einschaltet und dadurch ist der "Verschnitt" nicht mehr ganz so klar kalkulierbar wie bei einem klassischem Raid.
Ist mir selbstverständlich bewusst. Drum schrieb ich auch nur vorsichtiger "nicht ideal" statt "unbedingt zu vermeiden".
 
Jetzt habe ich noch eine Frage zum Thema Kerne- und Speicherzuweisung in dem System.

Aufbau:

ESXi
VM1: FreeNAS oder OMV
VM2: pfSense (FreeBSD)
VM3: Debian

Da ich ja jeder VM die Anzahl der Kerne und RAM zuweisen muss, meine Frage: Wie würdet Ihr das Verteilen? Ich habe dann 4 (8) Kerne und 16 GB RAM.

Danke nochmals.

Thomas
 
Das ist so schwer zu sagen, wenn man nicht weiß, was das Debian machen soll und wie viel Last durch die Firewall bzw. OMV geht.

Tendenziell würde ich mit 1 Kern / 2GB RAM für pfsense und debian starten und dann mal beobachten was die Auslastung unter ESXI bei den VMs so zeigt.
 
Kann ich dann alle verbleibenden Kerne/RAM (6 Cores/12 GB) der VM mit FreeNAS oder OVM zuweisen oder muss ich für die ESXi auch etwas zurückhalten?

Bei dieser Gelegenheit: Ist ESXi die erste Wahl für mein Vorhaben?
 
Kann ich dann alle verbleibenden Kerne/RAM (6 Cores/12 GB) der VM mit FreeNAS oder OVM zuweisen oder muss ich für die ESXi auch etwas zurückhalten?

Würde ca. 2GB RAM gedanklich für ESXi „übriglassen“. Bei den Cores ist es so, dass der - wenn ich das richtig im Kopf habe - die eh in der Grundeinstellung nicht 1:1 zuweist, interessant wird das wohl erst, wenn die (alle) VMs am Anschlag sind.

Bei dieser Gelegenheit: Ist ESXi die erste Wahl für mein Vorhaben?

Kann ich nicht sagen. Im Vergleich zu Hyper-V aber ja. :)
 
Die Hardware habe ich jetzt zusammen, wird noch heute bestellt. Nochmals VIELEN DANK für Eure Hilfe. Tolles Forum, tolle Leute da - super professionell (und geduldig)!

Jetzt kommt der nächste Punkt - die Software. Meine Recherche hat mich mehr verunsichert ...

Ich hätte gerne:

  • Einen Fileserver (als NAS Ersatz) mit zusätzlichen Anwendungen wie z. B. rSync, Mediaserver (Twonky, Minim), Syncronisation mit diversen Clouds (Dropbox, OneDrive, Amazon), Resilio (OVM oder FreeNAS - wobei ich mittlerweile zu OVM tendiere) - anfangs war für mich klar, ZFS muss her, mittlerweile bin ich mir da nicht mehr so sicher;
  • pfSense, derzeit auf einer eigenen Hardware;
  • debian mit UniFi Controller Software und ein paar anderen Anwendungen - nichts Großes;
  • vielleicht noch ein Ubuntu zum "Herumprobieren".
Meine Idee war es, ESXi als Basis zu nehmen und 4 VM's (FreeNAS oder OVM, pfsense, debian und ubuntu) aufzusetzen. Ich bin mir da jetzt nicht mehr so sicher ob das die ideale Vorgangsweise ist. Daher meine Frage an Euch, wie würdet Ihr das mit dieser Hardware lösen? ESXi als Virtualisierer? Und, ist ZFS als Dateisystem in diesem Fall ein Vorteil.

Beste Grüße
Thomas
 
ESXi hat den Vorteil dass es als Type-1 Virtualisierer extrem wenig Resourcen verbraucht und die beste Unterstützung für beliebige Systeme (BSD, Linux, OSX, Solarish, Windows) bietet. Storagemäßig ist es nicht so toll und "advanced Features wie HA" kostet.

ZFS als Dateisystem halte ich immer "von Vorteil" wenn es um Crashsicherheit, Datensicherheit oder Snaps/Versionierung geht. Da kommt nichts ran. Den Performancenachteil zu "alten Dateisystemen" muss man mit mehr RAM ausgleichen.

Wenn man allerdings zu dem Storagedienst (den man immer braucht) andere Dienste hinzufügen möchte wirds speziell. Die machen das Gesamtsystem instabil oder brauchen intensiv Support. Das ist ja auch der Grund warum Synology so erfolgreich ist. Deren Storage ist als Storagesystem allenfalls mittelmäßig. Die supporten aber die ganzen Extras exzellent. Bei anderen Systemen muss man das eher selbst machen. Solarish beispielsweise bietet das eher nicht ist aber als reines ZFS Storage das Maß der Dinge.

Ich bevorzuge eher stabiles "Storage Only" und lagere Extra Services auf VMs aus. Wenn die mal nicht tun dann bleibt das Storage online.
 
"Storage Only" ... wenn ich richtig verstehe, wäre das z. B. OMV als "Basissystem" oder auch Solaris?
Wie löse ich dann die VM's?

Zum Thema ZFS ... Wenn ich ohnehin ein Backup all meiner Daten habe spielen die Vorteile von ZFS eine eher untergeordnete Rolle?! Dann wäre EXT4 auf Grund des Rcoucenbedarfs evtl. doch die bessere Wahl?
 
OMV/Linux ist was ZFS angeht eher nicht erste Wahl.
Neben Solarish als Ursprung von ZFS (meine erste Wahl) würde ich allenfalls ZFS auf BSD nehmen.

Für VMs kann man entweder ein OS wählen das VMs unterstützt wie FreeNAS, Debian/Proxmox oder OmniOS mit Linux Zonen. Ich bevorzuge aber eher Virtualisierung unterhalb der Gastsysteme (ESXi, Xen) als Virtualisierung in einem Full-Featured OS z.B. via Container, Jails, KVM, oder Zonen. Virtualisierung on Top als ausführbares Programm wie z.B. Vitualbox ist eh was Performance oder Stabilität angeht Gaga.

Zu ext oder anderen "alten" Dateisystemen
Resourcenbedarf ist eines, Datensicherheit was anders. Da spielen btrfs, ReFS oder das Vorbild ZFS in einer ganz anderen Liga. Würde man nur auf Resourcenbedarf Wert legen müßte man FAT nehmen. Ein Crash beim Schreiben und das FS ist kaputt. ZFS bietet dagegen Versionierung und ist fast "unkaputtbar"
 
Zuletzt bearbeitet:
Nur als kleine Ergänzung: man kann halt prima mit einer Solarish-VM die Basis für all diese anderen Dinge legen. Du gibst dann einfach die entsprechenden Bereiche auf dem Storage (auch) der VM frei (z.B. NFS für Linux, CIFS/SMB für Windows), in der dann die Zusatzdienste wie Plexiglas, Own/Nextcloud und was weiß ich laufen. Diesen Diensten ist es regelmäßig ziemlich Wurscht, ob die zugrunde liegenden Daten „im gleichen OS“ oder irgendwo im Netz liegen.
 
Nochmal zu ZFS

Es gab mal eine Firma die hatte die meisten Domains in Deutschland gehostet - auf Servern der damals führenden Firma Sun. Dann gabs einen Crash und es dauerte eine Woche (mehrere offline fschk) um manche Daten wiederherzustellen und den Rest abzuschreiben.

Strato-Panne: "Wir machen die reinste Hölle durch" - SPIEGEL ONLINE

Kurz danach wurde bekannt dass Sun an einem neuen crashsicheren Dateisystem ZFS arbeitet um sowas in Zukunft zu vermeiden!
 
Ein wenig zu kompliziert für mich ...

Das heißt eine gute Lösung wäre an ESXI (oder Xen) als Basis und darauf Solaris als VM (um ZFS zu nutzen)?
 
Für mich ist das zumindest die Kombination "bester Virtualisierer" mit "bestem Storage" für Lau
 
Auf Basis Eurer Tipps und Recherche könnte das System nun so aussehen:

ESXi als Basis System (2 Cores/4 GB RAM)
* VM1: Napp-it als Storage Solution mit ZFS, Raid Z2 (4 Cores/8 GB RAM)
* VM2: pfSense als FW Solution (1 Core/2 GB RAM)
* VM3: debian mit GUI für das andere Zeugs (1 Core/2 GB RAM)

Klingt das sinnvoll? Hat auf den ersten Blick jedes Ding ausreichend Performance?
 
Sorry, hier Kurzzeitgedächtnis gepaart mit Faulheit: welche Hardware ist denn jetzt im Zulauf und was ist das „andere Zeugs“ in VM3? Plex mit Transkodierung oder sowas? Dann reicht das nicht. :d

Ich würd da vor allem RAM-seitig jedenfalls nicht mit 16GB ins Rennen gehen - auch wenn‘s rechnerisch gerade reicht. Oder wenn dann mit einem einzigen 16er Modul, um dann noch aufs Maximum des Boards gehen zu können (nehme mal an, Basis ist‘n 1151er Mainboard).
 
Code:
Mainboard		Supermicro X11SSL-CF retail (MBD-X11SSL-CF-O)
Prozessor		Intel Xeon E3-1230 v6, 4x 3.50GHz, boxed (BX80677E31230V6)
RAM			2x Kingston ValueRAM Server Premier DIMM 8GB, DDR4-2400, CL17-17-17, ECC (KVR24E17S8/8MA)
SSD			Intel SSD 540s 120GB, SATA (SSDSC2KW120H6X1)
Cooler		        Noctua NH-L12S
Case			19" Server Gehäuse 4HE / 4U - IPC-E420 - Frontaccess / 35,5cm
Power		        be quiet! Straight Power 10 400W ATX 2.4 (E10-400W/BN230)
SAS Cable		2x Adaptec mini SAS HD x4 (SFF-8643) auf 4x SATA (SFF-8448) Kabel, 0.8m (2279800-R)
Wechselrahmen	        RaidSonic Icy Box IB-176SSK-B (17001)
Netzwerkkarte	        HP 331FLR, 4x 1000Base-T, PCIe x4 (629135-B21)
HDD Seagate 	        6x IronWolf NAS HDD 4TB, SATA 6Gb/s (ST4000VN008)

Ist jetzt bestellt. Nichts, was ich nich noch ändern könnte. Auf der VM3 sollte tatsächlich einiges laufen, was unter Napp-it nicht läuft: UniFi Controller, Resilio (Bit Torrent Sync), diverses Syncs (Amazon Drive, OneDrive, Dropbox, WebDAV Cloud), Minim Server und evtl. ein Plex (wobei Serviio als Alternative auf Napp-it laufen sollte und dann nicht auf die VM3 müsste). Im wesentlichen laufen diese Anwendungen jetzt auf meinem QNAP mit deutlich weniger RAM und einem alten Marvell. Zu weinig RAM?

Reicht die RAM/Core Zuordnung für Napp-it?
 
Zuletzt bearbeitet:
Das X11 kann ja 64 GB und hat 4 Memory Slots. Man kann also jederzeit aufrüsten.

Von der RAM Zuteilung ist das soweit als Start ganz ok.
Ich würde eventuell der napp-it VM weniger Cores geben und das eher gleichmäßig teilen. ESXi verteilt CPU Leistung ganz gut. Idealerweise gibt man nur soviel Cores wie physicalisch oder als HT vorhanden. Das erleichtert ESXi die Arbeit. Verteilung also eher 2:1:1

Ich halte Storage immer minimalistisch. Storage braucht man immer und ohne Abhängigkeiten läuft das viel stabiler und die Storage VM muss nicht gesichert werden. Raucht die Bootplatte ab, einfach ESXi neu installieren, napp-it per ova importieren und die VMs registrieren. Dauert wenige Minuten ohne Komplikation. Installiert man auf der Storage VM alles Mögliche wird das kompliziert erneut aufzusetzen und man muss sich unnötig Gedanken um Backup und Disaster Recovery machen.

bzw
Wozu 6 Nics anstatt eine Nic mit mit beliebig veilen vlans and einem vlan fähigen Switch?
Wenn schon mehr dann würde ich eher auf 10G gehen.
 
Zuletzt bearbeitet:
Ich könnte die Bestellung mal auf 2x 16 GM RAM ändern - damit bin ich sicher besser bedient.

Betreffend der Core Verteilung dachte ich, dass ZFS recourcenhungrig ist und daher habe ich mehr Cores vorgesehen.

Die Aufteilung könnte dann so aussehen:

ESXi als Basis System (2 Cores/4 GB RAM)
* VM1: Napp-it als Storage Solution mit ZFS, Raid Z2 (2 Cores/16 GB RAM)
* VM2: pfSense als FW Solution (1 Core/4 GB RAM)
* VM3: debian mit GUI für das andere Zeugs (2 Cores/4 GB RAM)
* VM4: evtl. für eine weiter Linux Installation zum Testen (1 Core/4 GB RAM)

Zur Idee mit den 6 NICs: Der Server sollte meine pfSense Hardware ersetzen, aktuell habe ich dort auch 6 NICs (WAN, LAN1, LAN2 LAN_GUEST, der Rest ist frei). Ich finde das insoferne gut, da die Netze physisch getrennt sind. 10G sehe ich mangels Clients bei mir für noch nicht so sinnvoll.
 
Wenn Du nicht gerade exzessiv verschlüsselst oder Deduplication benutzt, braucht die Storage-VM für die reinen Fileserver-„Dienste“ eigentlich nicht wirklich viele Ressourcen.

RAM hilft dieser VM als Cache, wobei mir allerdings nicht abschließend klar ist, in welchen Szenarien das wirklich was bringt.

Ich habe noch im Hinterkopf, dass Cache eben primär bei wiederholten Zugriffen auf gleiche Daten hilft - liegt „zu viel“ Zeit dazwischen, bringt’s halt ggf. nichts. Gleiches gilt dann wohl auch, wenn die Zugriffe nicht gut vorhersehbar sind, also „read ahead“ nicht geht. Oder bei Deduplication eben um die entsprechenden Tabellen (nicht die Rohdaten selbst) im schnellen Zugriff zu halten.

Caching ist je nach Workload aber eine Wissenschaft für sich, da stecke ich nicht tief genug drin um über „größerer Cache erhöht die Chancen, das es was bringt“ hinaus was beizusteuern. ;)
 
Zur Idee mit den 6 NICs: Der Server sollte meine pfSense Hardware ersetzen, aktuell habe ich dort auch 6 NICs (WAN, LAN1, LAN2 LAN_GUEST, der Rest ist frei). Ich finde das insoferne gut, da die Netze physisch getrennt sind. 10G sehe ich mangels Clients bei mir für noch nicht so sinnvoll.

Kann man so machen.
Ich würde eher eine 10G Netzwerkkarte nutzen (das X11 gibts auch für wenig mehr und 10G onboard) und daran einen vlan fähigen 10G Switch anschliessen und dort die Netze portbasiert aufteilen. Die sind zwischenzeitlich mit 2 x 10G recht günstig zu haben.

Darauf dann die 6 Netze portbasiert anlegen und zum ESXi als tagged vlan führen. Für jede vnic kann man dann in ESXi festlegen mit welchem Vlan das verbunden ist.

In der Summe deutlich schneller und viel einfacher zu managen.

Wenn man vlan 1 separat läßt und die automatische Vlan Erkennung deaktiviert ist das fast so sicher wie physikalisch getrennte Netze. Für Angriffe muss man Zugriff physikalisch Zugang zum LAN haben und wenn man das hat gibt es viele Angriffsmöglichkeiten. Selbst im professionellen Umfeld läuft heute nahezu immer alles über vlans. At Home gibt es eigentlich keinen Grund für physikalisch getrennte Netze zumal man dann auch physikalisch getrennte Switche bräuchte um diese Sicherheit zu halten.

vgl Ten top threats to VLAN security - Redscan
 
Soweit ist mal alles zusammengeschraubt und läuft. Nochmal vielen Dank für Eure Unterstützung.

Leider ist die SSD nicht gekommen und ist offensichtlich kurzfristig auch nicht zu bekommen. Ich möchte auch nicht mehr warten! Bestellt hatte ich eine Intel 840s 120 GB. Welche schnelle SSD könnt Ihr mir als Alternative (120-180 GB) in dieser Preisklasse oder günstiger empfehlen?

Danke! Thomas
 
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