Probleme mit MegaRAID SAS 8708EM2 / ZFS over iSCSI

[Sourcenux]

Hallo zusammen,

wir betreiben einen Proxmox-Cluster mit 4 Nodes (1x Storage Proxmox 6.0-15 und 3x Nodes mit Proxmox 6.0.12). Der Storage nutzt ein mdadm-RAID10 über 8x2TB SM883 SSDs, um darüber via LIO ein iSCSI-Device für ZFS over iSCSI bereitzustellen.

Wir virtualisieren aktuell bestehende, sehr alte Serversysteme auf Debian 6/7/8-Basis. Da insbesondere die Debian 6 Systeme nach dem Kopieren der Daten (mittels dd) keine Festplatte finden, verwenden wir bei diesen VMs den Proxmox SCSI-Controller "MegaRAID SAS 8708EM2". Wir haben nun das Problem, dass uns regelmäßig die Dateisysteme in den betroffenen VMs kaputt gehen.

Beispiel:

VM erstellen, MegaRAID SAS 8708EM2 nehmen und eine 80GB Platte auf dem ZFS over iSCSI erstellen
Debian 6.0.9 aus einem offiziellen ISO installieren
VM neustarten.
Nach dem ersten Boot finden sich im syslog direkt IO-Errors, woraufhin das Root-Dateisystem readonly gemountet wird:



Nach einem weiteren reboot wird man in die initramfs-Shell gedroppt, weil das Dateisystem beschädigt ist. Nach einer Reparatur und erneutem Reboot tritt dieser Fehler wieder auf. Wenn von der betroffenen VM ein Live-Klon angelegt wird, tritt dies ebenso auf und sorgt für massenhaft IO-Errors im Syslog der betroffenen VM. Das Abbrechen des Klon-Vorgangs sorgt dafür, dass in der VM keine weiteren IO-Errors mehr auftreten (allerdings lassen sich abgebrochene, halb fertige VMs nicht löschen, weil diese im Zustand locked sind...). Das Problem tritt unabhängig vom Node auf dem die VM läuft auf.

Auf dem Storage tritt beim Klonen der folgende Fehler sehr häufig (>10x / Sekunde) auf:

Feb  5 12:36:51 storage kernel: [6087586.856619] Unsupported SA: 0x12
Feb  5 12:36:51 storage kernel: [6087586.857684] Unsupported SA: 0x12
Feb  5 12:36:51 storage kernel: [6087586.858832] Unsupported SA: 0x12
Feb  5 12:36:51 storage kernel: [6087586.862018] Unsupported SA: 0x12
Feb  5 12:36:51 storage kernel: [6087586.866763] Unsupported SA: 0x12
Feb  5 12:36:51 storage kernel: [6087586.873705] Unsupported SA: 0x12
Feb  5 12:36:51 storage kernel: [6087586.876670] Unsupported SA: 0x12

Der Zustand des md-raid10 ist OK:

md1 : active raid10 sda1[0] sdd1[3] sdh1[7] sdc1[2] sdf1[5] sde1[4] sdg1[6] sdb1[1]
      7479934976 blocks super 1.2 512K chunks 2 near-copies [8/8] [UUUUUUUU]
      bitmap: 21/56 pages [84KB], 65536KB chunk

Die SMART-Werte der im Storage genutzten SSDs sind auch allesamt i.O (keine Reallocated Sektoren, Smart-Health: OK). Die anderen VMs mit VirtIO-Controller verhalten sich unauffällig.

Habt ihr Ideen, woran das liegen könnte?

 

[wolfgang]

Hallo,

Wir Unterstützen MD Raid nicht.
Da wir in der Vergangenheit immer wieder solche Probleme hatten.

 

[Sourcenux]

Hallo,

und wie soll dann das Device für das iSCSI-Volume bereitgestellt werden? ZFS kommt an der Stelle ja nicht infrage.

 

[getcom]

Wir betreiben ein ähnliches System, allerdings mit LSI HBA SAS 9305-24i. Der erste Cluster Knoten ist ebenfalls in der Regel nur Storage und iSCSI Target, es sei denn man muss mal eine VM "Zwischenparken".

Es gibt einen hddpool mit acht Spiegeln und einen ssdpool mit vier Spiegeln. Jeder Pool hat gespiegelte Optanes als log device.
Die Cluster-Knoten haben alle je zwei 10Gbit Ethernet devices und hängen via LACP an je unterschiedlichen Cisco Switchen.

Das Storage-Netzwerk ist Infiniband ConnectX-3 im Multipath setup.
LIO target ist als iSER über RDMA über Infiniband konfiguriert. Das iSER Setup ist nach Mellanox Doku aufgesetzt.
Das sollte eigentlich alles nach best practice sein.
Wir erhalten aber ebenfalls bei Copy oder Snapshot jobs genau die gleiche Meldungsflut "Unsupported SA: 0x12" im syslog des iSCSI targets.

Laufen zur gleichen Zeit mehr als ein Snapshot oder werden zusätzlich noch große Datenmengen zwischen VMs kopiert, kommt es ebenfalls zu Buffer I/O Fehlern auf den VMs. Dabei ist das unrelevant, in welchem Pool die Platten liegen. Es betrifft dann immer alle VMs eines Cluster-Knotens

Hat dazu jemand eine Idee hat, was es mit dem Fehler "Unsupported SA: 0x12" auf sich haben könnte?
Aus der Kernel Doku werde ich nicht richtig schlau.

Auf einem anderen Cluster mit iSCSI over Infiniband ohne iSER hatten wir ähnliche Probleme mit Buffer I/O Fehlern, was wir duch Umstellung von connected mode auf datagram mode und einer MTU von 4092 auf der Infiniband-Seite hin bekommen haben. Aber das hier ist iSER und lauf Doku ist der connected Mode der empfohlene Weg.

 

[Sourcenux]

Ich habe die Vermutung, dass das ein Bug in qemu-img ist: https://sourceforge.net/p/scst/mailman/message/35242474/

Bisher haben wir dafür keine Lösung gefunden. Der einzige Ausweg ist für uns aktuell die Migration auf anderen Storage (vermutlich NFS + qcow2-Files oder Ceph).

 

[getcom]

Genau das wollten wir nicht. Die Performance unseres Setups ist erstaunlich, da kommt NFS oder Ceph nicht mit.

Aktuell schaffen drei VMs auf drei Clusterknoten verteilt im Schreibtest bei 4M Blöcken im GB Bereich und bei 4K-Blöcken immer noch über 500MB/s mit aktuell 30 VMs als "Nachbarn".
Hier ist das genauer beschrieben: https://www.ixsystems.com/community/threads/building-compiling-freenas-with-ofed-iser-support.79130/

Die VMs reagieren extrem performant. Da sind auch W10 und W2k16 Server dabei mit MS SQL DBs, Galera Cluster, Webserver, UCS.
Die brauchen alle die iSER Storage-Performance.

Unser letztes größeres Setup mit iSCSI Target lief unter FreeNAS, das an das Proxmox Cluster über freenas-proxmox transparent angebunden wurde.
Das hätte dann ebenfalls Fehler melden müssen, tut es aber nicht. Das läuft nun seit 1 1/4 Jahren völlig geschmeidig, fehlerfrei und performant.
Es kommt aber eben noch nicht an iSER Performance ran. Hätte FreeNAS/TrueNAS bereits eine funktionierende iSER Konfiguration zu bieten, hätten wir gar nicht auf ein anderes Storage gewechselt. ZFS unter FreeNAS ist immer noch ein wenig näher dran am Original, wobei das sich mittlerweile mit OpenZFS relativiert hat.
Geht es rein nur um iSCSI und ZFS, könnt ihr das gerne mal testen mit FreeNAS.

Wir tendieren hier aktuell eher in die Richtung, Snapshots der iSCSI Blockdevices zu erstellen für Backups, also auf ZFS Ebene, und die dann weg zu sichern.
Snapshot-Kopien erzeugen dann einfach neue LUNs. Das sollte recht einfach unktionieren.

Was auf jeden Fall nicht gut ist, wenn man keine Daten verlieren möchte, ist ein Hard- oder Software-RAID-System in Zusammenhang mit ZFS zu verwenden. ZFS MUSS zwingend direkten Zugriff auf die Platten haben. Da kommen nur SAS HBAs in Betracht, wie z.B. die SAS 9305 Serie von Broadcom.

 

[Sourcenux]

Da kommen nur SAS HBAs in Betracht, wie z.B. die SAS 9305 Serie von Broadcom.

Yap. In dem Server ist auch ein HBA verbaut. Der "MegaRAID SAS 8708em2" ist ein Virtueller Controller Festplattencontroller, den man VMs in Proxmox zuweisen kann (Wir haben einige sehr alte Debian 6 VMs, die mit in Verbindung mit anderen Controllern nicht booten wollen).

 

[getcom]

Ah, ok, das habe ich auf den ersten Blick anders verstanden.