Architekturvorschlag ESXi Free Host mit virtueller ZFS NAS

Lolli123

Enthusiast
Thread Starter
Mitglied seit
01.07.2013
Beiträge
137
Hallo alle zusammen, ich hoffe auf euren Rat für mein neues privates Setup.

Ziel ist es 3 Maschinen durch ein Esxi-free basiertes System zu ersetzen, welches folgende Aufgaben erfüllt:
Diverse VMs (<400GB in Summe), W2K16 AD und Filer (ca 8 TB + Backup), W10, PFense (failover), Xpenology (<1 TB), ..
NAS als Datastorelieferant und für VM Backups

Ich bin mir nur nicht im klaren darüber, wie ich das System aufbauen soll bzw. in welche Teile sich ein Invest lohnt.

Was steht mir aktuell zur Verfügung:
Basissystem ist:
Supermicro X11SPi-TF
Xeon Silver 4108
64 GB Ram
LSI SAS 3008 HBA (IBM M1215 in IT Mode)
LSI SAS 2008 Raidcontroller (IBM M1215 mit Originalsetup)
Intel i350 T2

Als Platten habe ich:
2 mal HGST Ultrastar 7K6 6TB HDD SATA
3 mal Western Digital Red 4 TB
1 mal Seagate Ironwolf Nas 4 TB
2 mal Micron 5200 Max SSDs (Sata, 480 GB)
1 mal Micron 5100 Max SSDs (Sata, 240 GB)
1 mal Samsung 970 Pro (NVME, 512 GB)

In einem Backupserver habe ich noch eine kleine SSD und 2 Western Digital Red 6 TB verbaut (Xeon 1271 v3 in einem Supermicroboard und 32 GB Ram).

Der Hardwareswitch unterstützt 10G bzw. Link Aggregation aus 2 x 1GB. USV ist vorhanden aber kein redundantes Netzteil.

Aktuell tendiere ich in die Richtung:
ESXI from Stick
Storage VM (Freenas oder Xigmanas) und Scratch Dateien auf die 240 GB SSD
Alle anderen Sata Devices über HBA an Storage VM
ESXI bekommt von der Storage-VM über iSCSI die Datastores (zB: Mirror SSDs für VMs, Spinning Disks als redundanter Storage (Mirror aus 2 mal 6 TB, Raid-Z1 aus 3 mal 4 TB).
Platten und Controller die nicht benötigt werden fliegen raus.

Als Alternative könnte ich den Raidcontroller verwenden um den Datastore für die VMs aus den beiden 480 GB SSDs im Raid 1 zu bauen.

Was macht aus eurer Erfahrung heraus Sinn bzw. in was sollte ich noch investieren (zB: Optane als Cache, Mehr Ram oder andere Platten)?

Lg

Lolli
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hardwäremäßig hast Du da doch eine solide Basis. Optane & Co. würde ich erst in Erwägung ziehen, wenn Du im Betrieb auf Limits stößt. Ich hab ja quasi die gleiche Basis (siehe Signatur) und mir reicht das bisher locker. Nur die Storage-VM mit glaub 8 Kernen ist bei heavy IO mal knapp bei 100% CPU-Last. AD dürfte sich im Homeuse eh nur langweilen.

Ich würde Storage an ESXi nicht über iSCSI zurück geben, sondern über NFS: die iSCSI-Volumes sind - notgedrungen - beim Start des ESXi-Hosts ja nicht verfügbar und das führt nach meiner Erinnerung dazu, dass die dann nach dem Booten der Storage-VM manuell wieder eingehängt bzw. online gesetzt werden müssen. Mit NFS musst Du nicht nach jedem Booten manuell eingreifen, da erkennt ESXi automatisch nach einiger Zeit, dass das Share wieder zur Verfügung steht.

Musst ggf. mal die Zeit checken, falls Du VMs automatisch Booten willst, die auf den NFS-Shares liegen.

Ansonsten würde ich in der Tat grds. so viele Laufwerke wie möglich an den 3008 hängen und die Storage-VM das verwalten lassen. Die kann z.B. iSCSI-Shares an die Windows-VMs geben (und kann dann den Umweg über VMDKs auf NFS-Shares sparen). Wie du die dann genau konfigurierst ist eine Frage des Geschmacks bzw. der Performancewünsche, insb. ob man SDDs lieber als Cache zusammen mit HDDs oder lieber einen reinen SSD-Pool nimmt. Ich persönlich nehme als VM-Storage lieber „SSD-only“ und für alles andere - insb. was über das physische Netz „raus“ von dem All-in-one muss - dann eben „HDD-only“.

Mit deinen 480ern in einem SSD-only Mirror-Pool solltest Du z.B. locker genug Speicherplatz für die von Dir angedachten VMs haben. Die bisherigen 8TB im Windows-Server würde ich dann in die Storage-VM umlagern und am besten dort nativ verwalten, zur Not als iSCSI- oder SMB-Share an den Windows-Server geben.

- - - Updated - - -

Korrektur: meine Storage-VM hat nur 4 Kerne bekommen. :)
 
Guter Einwand mit NFS vs iSCSI.

In dem Fall fliegt dann der 2. Raidcontroller raus und ich installiere die Storage VM auf die 240er SSD.
Offen ist dann noch wie ich die Platten verwende. Ich tendiere zu zwei Pools (2x 6TB Mirror und 3 x 4TB Raid-Z1) da ich ungern verschiedene Plattentypen und Größen mischen möchte.

Danke für deine Antwort.
 
Ich würde das wohl auch so machen. Oder Du holst Dir noch eine 6TB - in der Größe tut ein Mirror mir gefühlt immer so weh, da man ja 50% Speicherplatz verbrennt. :d

Wenn man will, kann man auch noch individuelle Wege gehen, um die Ausfallsicherheit zu erhöhen: ich hab z.B. ESXi 2 SSDs gegeben, für meine Storage VM zwei virtuelle VMDKs verteilt auf beide SSDs eingerichtet und dann auch mein OS in der Storage-VM selbst „gemirrored“. Bei Solaris kann man netterweise recht einfach auch nachträglich nach Installation die root-Partition (rpool) spiegeln. Ich vertrau da Solaris mehr als irgendsonem Chipsatz-RAID und so brauch ich keinen extra Raid-Controller. Zusätzlich kann ich noch das OS ZFS-snapshotten. Herz, was willst Du mehr? ;)

Geht bestimmt auch oder ähnlich mit anderen OS.

Auch können das natürlich völlig verschieden große SSDs sein, ohne Speicherplatz zu verschenken: den Rest kann man ja in ESXi z.B. für nicht so wichtige VMs als Boot-Space oder ggf. mit dem gleichen Prinzip im Mirror als Cache (wieder 2 VMDKs auf beiden SSDs - write Cache würde ich immer spiegeln!) für die Storage-VM hernehmen. Klar verliert man wohl etwas Speed im Vergleich zu durchgereichten Datenträgern, aber flotter als nur HDD ist das immer noch allemal.
 
Zuletzt bearbeitet:
Prinzipiell folgt das meinem AiO Ansatz den ich seit 10 Jahren propagiere,
siehe https://napp-it.org/doc/downloads/napp-in-one.pdf

Aufbau idealerweise
ESXi Boot und Datastore für Storage VM: Sata z.B, Micron 5100
alternativ einen Hardware-Mirror aus den 2 x 5100 mit dem LSI 2008

Als Storage VM: idealerweise eine minimalistische ZFS appliance mit möglichst wenig Speicherverbrauch
Ich bevorzuge OmniOS Community Edition. Das ist ein Solaris fork. Dafür wurde ZFS entwickelt und es hat den geringsten Overhead und Speicherverbrauch, dazu den native multithreaded SMB Server mit Windows ntfs artigen ACL. Auch ist in OmniOS ab v151031 (und in openindiana Community-driven illumos Distribution, einem OpenSolaris Fork) bereits native ZFS Verschlüssellung und die neuesten ZFS Features wir System-Snapshots und removable vdevs enthalten. Wenn Free-BSD das Basis OS sein sollte, dann eher XigmaNAS als FreeNAS.

Die Storage VM übernimmt die komplette Storageverwaltung und nur das. Idealerweise keine weiteren Dienste (die die Stabilität beeinträchtigen können) und stellt Storage via FC/iSCSI, NFS oder SMB bereit. Für ESXi ist NFS3 ideal.


ZFS mäßig erstellt man zwei Datenpools.
Pool-1 für VMs aus einem ZFS Mirror aus den 5200
Da die 5200 recht schnell sind und powerloss protection haben, genügt es vorraussichtlich einfach sync zu aktivieren um sowohl einen schnellen wie sicheren datastore zu haben.

Pool-2 für Backup und als Filer z.B. Raid-Z2 ais den 6 Platten (genutzt als 6 x 4TB, 16 TB nutzbar).
Bei gelegenheit die 4 TB durch 6TB HGST/WD ersetzen und doe 4 TB als Backup nutzen

oder 4 x 6TB als Z2/mirror (oder noch 2 6TB Platten kaufen für einen 6 x Z2 Pool mit 24TB Nutzkapazität)
und die 4TB Platten in das Backup NAS. Für ZFS Filer und Backup würde ich aus Performancegründen sync deaktivieren.

alternativ
2 Datenppols aus Platten (Daten/Backup und Backup mit Entnahme der Platten nach Backup). Z1 würde ich vermeiden.

Wenn das Backup NAS auch ZFS kann, nutzt man ZFS Replikation zur Sicherung
Die 970 Evo hat im Server nichts zu suchen, gut für den Desktop
 
Zuletzt bearbeitet:
Wenn man will, kann man auch noch individuelle Wege gehen, um die Ausfallsicherheit zu erhöhen: ich hab z.B. ESXi 2 SSDs gegeben, für meine Storage VM zwei virtuelle VMDKs verteilt auf beide SSDs eingerichtet und dann auch mein OS in der Storage-VM selbst „gemirrored“.

Jup. Testweise habe ich das gestern mit Freenas durchgespielt und ja bei den 6 TB Platten ist 50% Verlust schlecht fürs Karma. ;)
 
@gea: danke für den Input.

Ich werde noch etwas herumtüfteln müssen aber das Grundsetup steht damit schon mal. ;)
 
Zuletzt bearbeitet:
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