ZFS über iSCSI über Infiniband ConnectX-2 HCAs mit FreeNAS und Integration in Proxmox
Wenn Proxmox im Cluster laufen soll, benötigt es ein shared storage. Das kann NFS sein oder besser iSCSI. Für Performance ist letztendlich entscheidend das Layout des Storage-Pools und eine möglichst latenzarme Anbindung. Fiberchannel oder Infiniband sind hier die Kandidaten der Wahl. Letzteres hat allerdings die Nase vorn, wenn es um Bandbreite geht und es ist ausgereift, da es im High-Perfomance-Computing schon sehr lange im Einsatz ist. Infiniband kennen wir zudem aus dem HP POD Supercomputing Projekt bei Airbus (damals die Nr.10 auf top500.org).
Da die Auswahl an Storage-Systemen mit Infiniband-Unterstützung dünn und im bezahlbaren Bereich quasi nicht vorhanden ist, haben wir beschlossen, selbst ein Storage zu entwickeln.
Als Hardware-Basis für Storage, Virtualisierungsplattform und Backup dienen unsere bewährten getcom Superserver Green-IT-Serie der Generation 7 & 8, Voltaire Infiniband Grid Director 4036E und Cisco Switche aus der SG550X Serie.
Alle Server (Storage und Cluster-Knoten) sind mit je zwei Intel XEONs 3,2GHz und 256GB ECC RAM bestückt und laufen auf aktuellen Supermicro Boards. Für den Netzwerkstack haben alle Server neben IPMI und Dual 10GbE je eine Dual Infiniband und eine Intel X710 SFP+ Karte mit an Bord. Die Betriebssysteme laufen auf gespiegelten Intel DC SSDs. Auf dem Storage-Server ist dazu auf der Rückseite ein hotplugfähiges 2,5″ Dual Bay integriert.
Das Herzstück des I/O-Systems für Storage- & Backup-Systeme, speziell geflashte HCAs, Dual SFP+ Ethernet 10GbE, Dual Infiniband 40Gbit mit gespiegelten PCIe NAND Flash Modulen, garantiert ordentlichen Durchsatz bei minimaler Latenz:
Die Frage nach dem Filesystem hat sich schnell beantwortet: ZFS soll es sein.
Die Vorteile sind:
- schnelle Rebuildzeit (resilver), da nur die belegten Blöcke übertragen werden
- schnelle Pool-Initialisierung, auch 140TB sind in wenigen Minuten initialisiert
- die Datenintegrität ist bei ZFS immer garantiert, d.h. ein Block wird so ausgeliefert, wie er gespeichert wurde
- einfache Poolerweiterung durch größere Ersatz-Platten
- einfacher Pool-Import inklusive ACLs, Snaphots, etc., der Platten auf neuer Hardware, wenn ZFS Version gleich oder größer ist auf dem Zielsystem bei unrelevanter Plattenfolge
Aktuelle ZFS basierte Systeme, die geeignet sind, sind FreeNAS 11.2 oder OmniOSce in Verbindung mit Napp-IT.
OmniOSce/Napp-IT ist im Grunde ein Abkömmling von Solaris Version 10 => OpenSolaris => illumos / OpenIndiana und damit ein direkter Nachfahre vom Unix System V. Da es unter FreeNAS/FreeBSD einige Überraschungen in Verbindung mit HA, Infiniband und iSCSI gab, werden wir uns bei Gelegenheit OmniOSce und Napp-IT in einer eigenen Analyse näher ansehen. Die PoC-Hardware dazu steht schon bereit. Mehr dazu in einem der nächsten Blogs.
Da FreeNAS nun über OpenZFS und auch über Mellanox Infiniband Treiber verfügt, gehen wir es an.
FreeNAS Setup
Die Installation wird als erledigt vorausgesetzt. Wir haben lediglich die beiden Intel Datacenter SSDs als Spiegel für die Installation ausgewählt. Wichtig ist, dass im BIOS auf UEFI umgestellt ist vor der Installation. Anschließend ist der Hostname zu vergeben, die beiden SFP+ Ports zu lagg0 (LACP), die beiden internen 10GbE Ports zu lagg1 (LACP) zusammen zu schalten. Mehr ist hier erst einmal nicht zu tun. Auf Cisco-Seite müssen innerhalb des Stacks auf den Core und den Management Switchen ebenfalls die entsprechend verwendeten Ports unter Link Aggregation zu einem lagg zusammen geschaltet werden. Für die Stack-Implementierung ist je Switch die Cisco Tesla Hybrid Firmware in der aktuellen Version zu flashen, wenn sich verschiedene Typen im Stack befinden sollen.
ZFS
Ein Blick auf das OpenZFS, welches FreeNAS mitbringt, verrät uns, dass es nah dran ist am aktuellen Oracle ZFS, die fehlende Verschlüsselung fällt auf, womit wir aber erst mal leben können:
root@freenas1[~]# zpool upgrade -v
This system supports ZFS pool feature flags.
The following features are supported:
FEAT DESCRIPTION
-------------------------------------------------------------
async_destroy (read-only compatible)
Destroy filesystems asynchronously.
empty_bpobj (read-only compatible)
Snapshots use less space.
lz4_compress
LZ4 compression algorithm support.
multi_vdev_crash_dump
Crash dumps to multiple vdev pools.
spacemap_histogram (read-only compatible)
Spacemaps maintain space histograms.
enabled_txg (read-only compatible)
Record txg at which a feature is enabled
hole_birth
Retain hole birth txg for more precise zfs send
extensible_dataset
Enhanced dataset functionality, used by other features.
embedded_data
Blocks which compress very well use even less space.
bookmarks (read-only compatible)
"zfs bookmark" command
filesystem_limits (read-only compatible)
Filesystem and snapshot limits.
large_blocks
Support for blocks larger than 128KB.
sha512
SHA-512/256 hash algorithm.
skein
Skein hash algorithm.
device_removal
Top-level vdevs can be removed, reducing logical pool size.
obsolete_counts (read-only compatible)
Reduce memory used by removed devices when their blocks are freed or remapped.
zpool_checkpoint (read-only compatible)
Pool state can be checkpointed, allowing rewind later.
The following legacy versions are also supported:
VER DESCRIPTION
--- --------------------------------------------------------
1 Initial ZFS version
2 Ditto blocks (replicated metadata)
3 Hot spares and double parity RAID-Z
4 zpool history
5 Compression using the gzip algorithm
6 bootfs pool property
7 Separate intent log devices
8 Delegated administration
9 refquota and refreservation properties
10 Cache devices
11 Improved scrub performance
12 Snapshot properties
13 snapused property
14 passthrough-x aclinherit
15 user/group space accounting
16 stmf property support
17 Triple-parity RAID-Z
18 Snapshot user holds
19 Log device removal
20 Compression using zle (zero-length encoding)
21 Deduplication
22 Received properties
23 Slim ZIL
24 System attributes
25 Improved scrub stats
26 Improved snapshot deletion performance
27 Improved snapshot creation performance
28 Multiple vdev replacements
For more information on a particular version, including supported releases,
see the ZFS Administration Guide.
root@freenas1[~]
Infiniband
Testweise manuelles Laden der Module für Infiniband unter FreeNAS/FreeBSD:
root@freenas1[~]# kldload mlx4 kldload: can't load mlx4: module already loaded or in kernel root@freenas1[~]# kldload mlx4ib root@freenas1[~]# kldload ipoib root@freenas1[~]
Das aktiviert schon einmal die Karten, die uns mit Aufleuchten der orangen und grünen LEDs signalisieren, dass die Treiber geladen und die Karten einsatzbereit sind.
Das permanente Laden erfolgt in FreeBSD über die /boot/loader.conf.local.
Anders als unter FreeBSD wird allerdings die local Datei bei Updates oder Änderungen in den Tuneables (loader) gnadenlos überschrieben. FreeNAS ist eine Appliance und somit muss man Änderungen immer über die GUI vornehmen. Das gilt für alle Appliances, nebenbei auch für pfSense. Die loader Config darf deshalb nicht manuell editiert werden, da sie vom System früher oder später überschrieben werden wird.
Die korrekte Vorgehensweise ist über die GUI => System => Tunables => Add zu gehen und die entsprechenden Werte für die beiden loader einzutragen.
Nach dem Speichern finden wir unsere loader an gewohnter Stelle wieder:
root@freenas1[~]# cat /boot/loader.conf.local mlx4ib_load="YES" # Be sure that Kernel modul Melloanox 4 Infiniband will be loaded ipoib_load="YES" # Be sure that Kernel modul IP over Infiniband will be loaded kernel="kernel" module_path="/boot/kernel;/boot/modules;/usr/local/modules" kern.cam.ctl.ha_id=0 root@freenas1[~]
Unter FreeBSD/FreeNAS kann für IP über Infiniband keine der bekannten Loadbalancer Methoden, wie Round Robin oder LACP verwendet werden. Da wir aber iSCSI für die Virtualisierungshosts, bzw. für das Proxmox-Cluster und den VMs einsetzen möchten, ist zwingend für die Erhöhung des Durchsatzes und für die Ausfallsicherheit zu sorgen.
Damit sind wir auch gleich schon beim Thema Multipath angelangt:
Multipath
Etwas Theorie dazu, wenn es lieber mehr sein darf:
Für Multipath ist je Netzwerk Gerät eine IP aus einem eigenen Subnet zu verwenden. Da wir die Infiniband-Netze weder routen, noch für andere Zwecke, außer latenzarm iSCSI zur Verfügung stellen wollen, verwenden wir neue Subnetze, außerhalb der bisher verwendeten.
In unserem Fall 10.20.24.0/24 für ib0 und 10.20.25.0/24 für ib1. Falls zwei HCAs mit je zwei Ports eingesetzt werden, werden analog vier eigene Subnetze benötigt.
Bei FreeBSD ist der Infiniband Treiber standardmäßig auf connected mode (CM) aktiv, was bedeutet, dass TCP/IP zum Einsatz kommt. Dafür ist normalerweise die MTU auf 65520 einzustellen auf Server- und Client-Seite (Proxmox), um den maximalen Durchsatz zu ermöglichen.
Mit diesen Werten hatten wir allerdings Probleme auf der Client-Seite mit SCSI-Kernel-Fehler-Meldungen. Durch heran tasten haben wir eine MTU von 40950 als zuverlässig ermittelt. Die Ursache ist aktuell nicht ganz klar. Wir vermuten Buffer-Probleme innerhalb der Treiber-Implementierung. Das könnte der Grund sein, weshalb Mellanox die ConnectX-2 Karten nicht für FreeBSD frei gegeben hatte. Wir wollen im Zuge des OmniOSce PoC-Projektes vorher auch noch ConnectX-3 Karten unter FreeBSD testen. Möglicherweise erledigt sich das damit auch schon. Mehr dazu, wenn wir die spezifischen Tests abgeschlossen haben. Aktuell genügt uns das Setup, wie es ist, da wir insgesamt mit vier virtuellen Testmaschinen beim Performance-Test auf einen Gesamtdurchsatz von über. 3.000 MB/s kommen, was dem ermittelten maximalen Wert von 3.134 MB/s der gespiegelten Intel Optane SSDs bereits sehr nahe kommt. Faktisch geht nicht mehr viel raus zu holen.
Das Setup der Infiniband-Karte ib0 sieht damit folgendermaßen aus:
Analog dazu ist ib1 einzurichten.
Pool Setup
Für Performance ist ein RAID-Z Pool ungeeignet. Zum einen wird bei einem Rebuild dann von allen Platten gelesen, was die Performance extrem nach unten zieht, zum anderen zum anderen sind die Schreib-/Lesewerte damit nicht befriedigent.
Es ist daher dringend empfohlen, VDEVs aus je zwei gespiegelten Platten (Mirroring) zu einem Pool zusammen zu schalten. In unserem Setup sind das 16 HGST 10TB HE2 SAS3 Platten, also 8 VDEVs mit je zwei Platten im Spiegelverbund plus die zwei Intel Optanes zu einem Spiegel verbundenen VDEV als SLOG.
Der Pool hat als Sync-Methode „Standard“, „lz4“ als Kompression, der Share Type ist „Unix“, Atime ist „off“, Deduplication ist „off“, der Rest bleibt Default:
Im Pool werden dann drei Datasets benötigt, wobei die ersten beiden via NFS frei gegeben werden:
- Proxmox-ISO-Images
- Proxmox-Snapshots
- iSCSI
NFS Sharing
FreeNAS GUI => Sharing => Unix (NFS) Shares
Je Dataset Proxmox-* ist ein Share anzulegen mit aktiviertem All Dirs und mit den IPs der Proxmox-Cluster-Knoten aus dem SFP+ lagg0 Subnetz:
iSCSI Multipath Setup
Target Global Configuration
FreeNAS GUI => Sharing => Block (iSCSI) => Target Global Configuration:
Basename = iqn.2019-05.de.getcom.freenas1
Pool Availble Space Threshold (%) = 75
Portals
FreeNAS GUI => Sharing => Block (iSCSI) => Portals
Je Infiniband Subnet, bzw. IP, ist ein Portal zu erstellen.
Initiators
FreeNAS GUI => Sharing => Block (iSCSI) => Initiators
Es wird ein Initator benötigt, zuerst einmal ohne Einschränkung (ALL/ALL):
Authorized Access
FreeNAS GUI => Sharing => Block (iSCSI) => Authorized Access.
Keine Einschränkungen, das kann später geändert werden, wird aber nicht wirklich benötigt, da iSCSI nur auf den von Außen nicht erreichbaren Infiniband Subnetzen aktiv ist.
Targets
FreeNAS GUI => Sharing => Block (iSCSI) => Targets
Hier ist jetzt ein Target anzulegen. Der Name wird klein geschrieben und ist hier frei wählbar, kann also proxmox, proxmox0, iscsi oder wie in unserem Fall iscsi-target0 heißen. Dem Target sind beide Portal Group IDs „1“ + „2“ und die Initiator Group ID „1“ zuzuweisen:
Extents
FreeNAS GUI => Sharing => Block (iSCSI) => Extents
Wie im Screenshot ersichtlich, entsprechend die Werte auswählen:
Associated Targets
FreeNAS GUI => Sharing => Block (iSCSI) => Associated Targets
Wie im Screenshot ersichtlich, entsprechend auswählen:
Damit ist das iSCSI Setup abgeschlossen.
Aktivierung des iSCSI und NFS Services
FreeNAS GUI => Services => iSCSI
FreeNAS GUI => Services => NFS
Start Automatically muss ausgewählt werden und den Schalter dann nach rechts ziehen:
Damit ist das Setup auf der FreeNAS Seite abgeschlossen.
