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.

Proxmox Setup