Bereitstellung Speicher ESXi über eigene VM

[Cluster_]

Hallo,

ich spiele momentan mit folgender Überlegung und hätte gerne etwas Input über Eure Erfahrungen und/oder Denkanregungen.

1 Host (single) - 8 x 8TB SATA + 8x512 GB SSD - Angebunden über zwei verschiedene HBAs
VMWare as Hypervisor - Startet von RAID 10 (4x512 GB) - Enthält 1 Speicherbereitstellungs VM mit FreeNAS welche per RDM auf den 8x8 TB HBA zugreift und damit ein RAID-Z2/3 + zweites 4x512 GB SSD als Cache per NFS(oder iSCSI) für den eigenen VMWare Host bereitstellt.
Die anderen Server-VMs liegen nur mit ihrer vmx und unter Umständen der System vmdk auf dem ersten 4x512 SSDs. Die Datenspeicher selber werden von der ersten VM bereitsgestellt welches über einen internen VMXNET3 10GBs NIC angebunden ist.
Vom Starten und Herunterfahren her (automatismus) müsste es ja praktisch gehen
VMWare ESXi Host statet -> autostart FreeNAS -> wait -> autostart andere VM . Beim Herunterfahren genau umgekehrt.
Sollte wiedererwarten der FreeNAS Speicher noch nicht im ESXi gemoutet worden sein, würde der Host das Hochfahren der VM aufgrund fehlender Platte in der vmx Konfiguration ja sowieso verweigern.

Hat jemand von Euch so etwas schon ausprobiert und Erfahrungen? Auch bezüglich Performance Blockdevice vs NFS.

Hintergrund ist die Integritätsprüfung im ZFS welche ja über "normale" HardwareRaid Controller nicht bereitgestellt wird. Die Prüfung der Integrität der Daten erfolgt hier ja NUR wenn ein Device Probleme an den HBA meldet. ZFS hingegen bei jeder Datenübertragung.

Gruß & Dank im Voraus
Thomas

 

[underclocker2k4]

1 Host (single) - 8 x 8TB SATA + 8x512 GB SSD
VMWare as Hypervisor - Startet von RAID 10 (4x512 GB) - Enthält 1 Speicherbereitstellungs VM mit FreeNAS welche per RDM auf den 8x8 TB HBA zugreift

Wenn das nur Spieldaten sind, bei denen ein, zu jeder Zeit auftretender, Datenverlust keine Auswirkungen hat, dann kann man das so machen. Andernfalls nutzt man dazu einen HBA, den man direkt den ZFS-Host weiterleitet.

ZFS hingegen bei jeder Datenübertragung.

Das kann ZFS nur sicherstellen, wenn es direkten Zugriff auf das Laufwerk hat. Dies ist aber bei RDM und sonstigen Faxen nicht der Fall. Es hängt überall der Hypervisor dazwischen, der ZFS seiner Arbeitsgrundlage enthebt.
Wenn so ein RDM-Konstrukt, kannst du auf ZFS auch fast verzichten.

Schau dir nochmal an, dir RDM funktioniert und was bei ZFS state of the art ist, auch in Bezug auf einen abstrahierten Filestore.

 

[Cluster_]

Wenn das nur Spieldaten sind, bei denen ein, zu jeder Zeit auftretender, Datenverlust keine Auswirkungen hat, dann kann man das so machen. Andernfalls nutzt man dazu einen HBA, den man direkt den ZFS-Host weiterleitet.

Das kann ZFS nur sicherstellen, wenn es direkten Zugriff auf das Laufwerk hat. Dies ist aber bei RDM und sonstigen Faxen nicht der Fall. Es hängt überall der Hypervisor dazwischen, der ZFS seiner Arbeitsgrundlage enthebt.
Wenn so ein RDM-Konstrukt, kannst du auf ZFS auch fast verzichten.

Schau dir nochmal an, dir RDM funktioniert und was bei ZFS state of the art ist, auch in Bezug auf einen abstrahierten Filestore.

Ahh ok, Dann habe ich das falsch verstanden.
Das heißt, dass das obige Konstrukt per VMDirectPath-i/o-passthrough des ersten 8x8TB HBAs laufen sollte oder?

​

 

[underclocker2k4]

Das wäre der präferierte Weg.

EDIT:
Das hängt auch vom Rest ab. Vorzugweise kann die HW das, einen dedizierten ZFS "tauglichen" HBA brauchste dann auch.
Ist im Zweifel also auch ein Kostenthema.
Allerdings ist ein solcher virtualisierter Aufbau einem nativen Aufbau fast gleichzusetzen. In Bezug auf den Driveaccess ist der das auf jeden Fall.
Das heißt auch, dass du das Zeug auch verschieben kannst und mit dem Configfile restoren kannst.

 

[Cluster_]

Das wäre der präferierte Weg.

EDIT:
Das hängt auch vom Rest ab. Vorzugweise kann die HW das, einen dedizierten ZFS "tauglichen" HBA brauchste dann auch.
Ist im Zweifel also auch ein Kostenthema.
Allerdings ist ein solcher virtualisierter Aufbau einem nativen Aufbau fast gleichzusetzen. In Bezug auf den Driveaccess ist der das auf jeden Fall.
Das heißt auch, dass du das Zeug auch verschieben kannst und mit dem Configfile restoren kannst.

Bleibt dann noch das Thema mit der Übertragungsrate des dann bereitgestellten Filestore. Sprich NFS / iSCSI , Durchsatz, etc.

P.S. Gedacht hatte ich an einen LSI 3800 oder einen HP P 420 für die zwei SSD Arrays und einen LSI 9361-8i für die 8x8 TB

 

[Trambahner]

Hardware-Raidcontroller wie der 9361-8i sind ein "no go" für ZFS. Immer nur dumme HBAs nehmen, die nix als einfache Ports ohne jeglichen Cache und ohne jegliche Logik bieten.
=> Controller mit SAS 3008, 3408, 3416 Chipsatz sind Goldstandard.

> z.b. einen 9400-16i nehmen, der hat 16 Ports, und den 9400-16i durchreichen an die VM. Dann hast Du 16 Ports in der VM für ZFS-Disks. Dort die HDD und SSDs dran und dann einfach zwei Pools aus HDD und SSD erstellen.
ESXI draufinstallieren und booten tust Du am besten von einer USB-Disk oder einer kleinen SSD vom Onboard-Sata. Eventuell noch eine Scratch-Disk für Images oder temporären Kram als einfachen Datastore,, den Rest komplett dann auf die von ZFS zurückgereichten Shares.

 

[Cluster_]

Hardware-Raidcontroller wie der 9361-8i sind ein "no go" für ZFS. Immer nur dumme HBAs nehmen, die nix als einfache Ports ohne jeglichen Cache und ohne jegliche Logik bieten.

> z.b. einen 9400-16i nehmen, der hat 16 Ports, und den 9400-16i durchreichen an die VM. Dort die HDD und SSDs dran und dann einfach zwei Pools aus HDD und SSD erstellen.
ESXI draufinstallieren und booten tust Du am besten von einer USB-Disk oder einer kleinen SSD vom Onboard-Sata.

Ahhh ok. Dann wäre der 9361 a) rausgeschmissenens Geld und b) ein Stück zusätzliche Logik die mit ZFS möglicherweise ... ungünstig zusammenarbeitet - Besser das

für das Booten stimmt das natürlich, für den ESXi und das FreeNAS image brauche ich ja nicht viel, da könnte ich dann sogar ein 32gb SuperDOM nehmen

 

[asche77]

LSI 2008, 2308 oder 3008, siehe Liste hier:

LSI RAID Controller and HBA Complete Listing Plus OEM Models

Below is a list of all known LSI SAS devices from the SAS1068 chipset to the very latest not yet publicly available SAS3xxx series. Devices with links have been released and official website technical info/support. Quite a few devices with no links are devices that may have been going to be...

forums.servethehome.com

 

[Trambahner]

Der 2008 reicht für HDD, für SSD-Arrays wird er eher zu langsam und: er hat nur PCIE Gen2 !

2008: PCIe Gen2x8 , SAS 6G und Sata 6G , 8 Port
2308: PCIe Gen3x8, SAS 6G und Sata 6G , 8 Port
3008: PCIe Gen3x8, SAS 12G und Sata 6G , 8 Port
3408: PCIe Gen3x8, SAS 12G und Sata 6G und NVME PCIe gen3.0 (NVME via spezifische Kabel) , 8 Port (je 4 Ports können für 1 NVME genutzt werden)
3416: PCIe Gen3x8, SAS 12G und Sata 6G und NVME PCIe gen3.0 (NVME via spezifische Kabel) , 16 Port (je 4 Ports können für 1 NVME genutzt werden)
3500er Serie ist dann PCIe Gen4.

In dieser aufsteigenden Reihenfolge ist natürlich auch die mögliche IOPS-Performance der Chips.

 

[andrer250282]

Der P420 ist ein Hardware RAID Controller und dadurch für das Vorhaben völlig ungeeignet - oder sollen die SSD Arrays kein ZFS sein?

 

[Cluster_]

Praktischerweise könnte ich den P420 (den habe ich hier noch zu liegen) ein 4x512 gb SSD Raid10 als ESXi + Datastore 1 verwenden und einen z.B. 9400-16i mit directpath und 4x512 SSD + 2x(4*8TB) HDD für das FreeNAS RaidZ System welches dann per VMNic an den Host angebunden ist.

 

[Trambahner]

Du brauchst keinen dicken ESXI SSD-Raid-Datastore. > Alles auf die ZFS-Pools legen.

Auf den lokalen Datastore nur ESXI zum Booten und die Storage-VM. Rest von den Pools. D.h. mit dem P420 also maximal ein Raid1 aus 2 SSDs dafür. Oder eben einen lokalen Datastore für temporären Kram oder Images. Alles was VMs dann betrifft: aufs ZFS damit.

Wichtig: Wenn Du NFS als Datastore nimmst: ESXI nutzt sync writes auf NFS Datastores. D.h. Consumer-SSDs werden Dir schnell miese Performance einbringen.

 

[Cluster_]

Du brauchst keinen dicken ESXI SSD-Raid-Datastore. > Alles auf die ZFS-Pools legen.

Auf den lokalen Datastore nur ESXI zum Booten und die Storage-VM. Rest von den Pools. D.h. mit dem P420 also maximal ein Raid1 aus 2 SSDs dafür.

Da bin ich mir eben nicht sicher, wie funktioniert das mit den registrierten VMs unter ESXi wenn die auf einem gemounteten Storage liegen?
Bis jetzt hatte ich immer nur mit Storages gearbeitet, die entweder lokal oder per FiberChannel angebunden waren.

 

[Trambahner]

ESXI aufsetzen, Controller durchreichen in neue Storage VM, Storage-VM aufsetzen+einrichten, Pools erstellen und Shares erstellen und freigeben.
NFS Share dann von der Storage-VM einbinden als Datastore. Wie bei nem eigenen Fileserver. NFS wird beim Starten sich nachdem die Storage-VM oben ist, nach kurzer Zeit selbst wieder verbinden. Zumindest bei mir so.
ISCSI verbindet sich nicht automatisch, wenn es beim Start nicht online war. > Vorteil NFS hier für solche Setups.
ISCSI hat natürlich andere Vorteile.

Vorteil dieses Setups mit ZFS: Zu kannst ja NFS und ISCSI parallel aus der gleichen VM auf den gleichen Zpools bedienen.

 

[Cluster_]

Ok, bedeutet also. Die registrieten VMs sind logisch im ESXi immer Vorhanden und können auch in autostart/stop berücksichtigt werden. Man muss halt sicherstellen, dass der entsprechende Storage dann auch beim ansprechen der VM vorhanden ist. Korrekt?

 

[Trambahner]

yup. autostart musste halt ausreichend zeitvorlauf einstellen. Ob das ereignisgesteuert geht: k.a. Bei mir ist alles via timing.

Solang der NFS nicht oben ist, werden die VMs als "unbekannt" als Name und Fehler angezeigt, sobald ESXI die NFS-Verbindung wiederhergestellt hat, gehen die registrierten VMs. Btw, die vmx files liegen da dann logischerweise auch am ZFS Store.

Als SSD: Nimm gute Datacenter-SSDs (Sata oder SAS) , alternativ Datacenter PCIe-SSDs . Diese kannste ja auch als PCIe-Gerät durchreichen. Ist aber manchmal je nach Hardware bisserl zickig oder bedarf manuellem editieren der passthru.map . Ich hab z.b. zwei PM9A3 8TB durchgereicht an die Storage-VM und dort draus nen Mirror-Pool erstellt.

Statt FreeNAS kannste natürlich auch andere Unixoide mit ZFS nehmen, FreeBSD original oder Xigmanas . Die sind nicht "so fett" wie FreeNas. Oder OmniOS und NappIT als GUI dafür.
FreeBSD ist meiner Erfahrung nach aber generell nicht so toll was NVME-Durchsatz betrifft; maxed out bei mir bei so 2,5Gbyte/s per Device (obwohl PCIe gen4x4 angebunden direkt an der CPU).


Gibt hier einige User im Forum, die so ein All-in-one Setup betreiben.

 

[Cluster_]

yup. autostart musste halt ausreichend zeitvorlauf einstellen. Ob das ereignisgesteuert geht: k.a. Bei mir ist alles via timing.

Scripten lässt sich alles

 

[besterino]

Ein Weg: Storage-VM mit ESXi Autostart beim physischen Booten starten und dann per Script nach Booten der VM als quasi letzte Maßnahme von dort aus per SSH die anderen VMs hochfahren. So kommt der Befehl zumindest nicht, bevor die Storage-VM oben ist.