MS Exchange 2019 Cluster - crashes am Laufenden Band

[Shiba86]

Hallo PROXMOX User,
ich möchte hier gerne mal mein Leid klagen....

Zielsetzung:
Exchange Cluster mit ca. 12.000 Postfächern und 12 Datenbanken mit je 1TB Kapazität
- dreifache Redundanz, dh. insgesamt 4 Server mit je 1 aktive DB und 3 passive DBs

Pro Server 6 Cores auf 2 Sockets, 128 GB RAM, je 25 virtuelle Laufwerke (1x OS = 500 GB, 12x DB = je 1TB, 12x Logs = je 200GB)

Uns stehen 7 PROXMOX Nodes zur Verfügung:
64 x AMD EPYC 7302 16-Core Processor (2 Sockets)
512 GB RAM
Ceph Storage mit 91 SSDs mit je 7.68TB (Micron 5210 ION 7.68TB, SATA (MTFDDAK7T6QDE-2AV1ZAB))
40 Gigabit Anbindung

Aktuell handelt es sich um eine Teststellung mit ca. 30 Postfächern. D.h. so gut wie kein Last. Ceph langweilt sich...
Nun verhält es sich so, dass die Server regelmäßig die gemounteten Laufwerke verlieren.

Im Windows Log werden folgende Errors und Warnings generiert (exemplarisch):

Event ID 129, vioscsi
Ein Zurücksetzen auf Gerät "\Device\RaidPort0" wurde ausgegeben.

Event ID 159, ExchangeStorageDBAt
'16.11.2021 08:18:53' the Exchange store database 'MBX02' copy on this server timed out on one or more Hung IOs. For more details about the failure, consult the Event log on the server for other storage and "ExchangeStoreDb" events.

EventID 532, ESE
Information Store - MBX02 (16268,R,0,15.02.0986.009) MBX02: Eine Anforderung zum Lesen aus der Datei "C:\MountPoints\LOG\MBX02\E0000000F1C.log" bei Offset 790528 (0x00000000000c1000) für 258048 (0x0003f000) Bytes wurde 244 Sekunde(n) lang nicht abgeschlossen. Dieses Problem wird wahrscheinlich durch fehlerhafte Hardware verursacht. Wenden Sie sich an den Hardwarelieferanten, um Hilfe bei der Problemdiagnose zu erhalten.

EventID 498, ESE
msexchangerepl (7208,G,0,15.02.0986.009) Fehler beim Versuch, Datei "C:\MountPoints\DB\MBX04\mbx04.edb" für den Lesezugriff zu öffnen, mit Systemfehler 32 (0x00000020): "Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. ". Fehler -1032 (0xfffffbf8) bei der Operation zum Öffnen von Dateien.

Nach wenigen Minuten, stellen die VMs Ihren Dienst ein, verlieren die Laufwerke und reagieren nicht mehr (kein shutdown möglich).

Der PROXMOX Support war bisher wenig hilfreich... uns wurde nahegelegt statt der je 25 Laufwerke, je ein großes Laufwerk zu erstellen.

Hat jemand ähnliche Erfahrungen gemacht oder hat in dieser Konstellation Expertise?

Über eure Erfahrungswerte würde ich mich sehr freuen....


Danke und Gruß!

 

[dylanw]

Hallo,

Bei einer so großen Anzahl von Laufwerken ist es durchaus möglich, dass das Problem in der neuen io_uring-Schnittstelle [1] liegt.
Könnten Sie versuchen, 'Native AIO' anstelle von io_uring für jede der Festplatten zu verwenden. Das geht am einfachsten, indem Sie aio=native an das Ende jedes Laufwerks in der Konfiguration der VMs (/etc/pve/qemu-server/<vmid>.conf) anhängen, z.B.,

scsi0: <storage_id>:<vm-disk>,backup=0,cache=writeback,discard=on,size=32G,aio=native
scsi1: <storage_id>:<vm-disk>,backup=0,cache=writeback,discard=on,size=32G,aio=native
...

[1] https://kernel.dk/io_uring.pdf

 

[Falk R.]

Hi,
ich habe ähnlich große VMs unter vSphere am laufen. Da haben wir 4 virtuelle SCSI Adapter (Paravirtuell) angelegt und die Disks darauf verteilt.
Soweit funktioniert das ganz gut, außer bei Snapshots hat der ESXi mit so vielen und großen Laufwerken echt Probleme.
bei anderen Kunden haben ich virtuelle Fileserver mit einer 50TB virtuellen Disk, das macht gar keine Probleme. Andere VMs mit viele kleinen vDisks machen auch nicht so viel Stress, es ist ganz einfach diese Kostellation, die jeden Hypervisor an die Grenzen bringt.

Ich hab keine Ahnung ob man bei Proxmox ebenfalls mehrere VirtIO SCSI Controller in eine VM bauen kann. Bei vSphere ist das die Lösung für das Handling mit vielen großen Disks.

Zum Thema Exchange, ja da möchte man gern jedes Postfach auf einer eigenen Disk haben, aber aus Performancegründen muss man das meistens nicht. Das dein Filesystem Korrupt geht ist auch eher unwahrscheinlich.
Ich haben beim Kunden einen Exchange DAG Cluster mit einer 20TB und einer 2TB Disk. Da liegen auf der großen alle Datenbanken und auf der 2TB alle Logs. Bei ca. 5500-6000 Usern merkt man da keinen Unterschied zum alten Exchange mit ganz vielen Disks. Das Handling ist aber deutlich einfacher.

Gruß Falk

 

[Shiba86]

Hallo dylanw, dein Tip hat leider keine Besserung ergeben :/ trotzdem Danke für die Info.

Hallo SkyDiver79, danke für deine Erfahrungen.

Unser alter Exchange Cluster läuft unter vSpehre. Jedoch nur mit je 13 virtuellen Disks pro Server mit je einem virtuellen Controller (LSI Logic SAS). Das Storage liegt auf einem EMC SAN (VNX5400+ VNX 5200). Dieses Konstrukt läuft sauber und performant.


Ich sehe das Problem beim virtuellen PROXMOX Controller (VirtIO SCSI). Dieser schafft es vermutlich nicht, alle parallelen Schreibarbeiten sauber über alle virtuellen Laufwerke (25 Stk. pro VM) zu betreiben (komplexe DB, aktive Sync).

Wir hätten gerne auf "VirtIO SCSI Single" geswitcht. Jedoch crasht die gesamte VM, wenn man mehr wie 20 virtuelle Laufwerke in diesem Modus mounted bzw. an der VM initialisiert.


Wir werden zunächst die Anzahl der Laufwerke auf unter <20 Stk. reduzieren, dann auf "VirtIO SCSI Single" umschalten, IO thread auf den Laufwerken aktivieren und schauen wie es sich dann verhält.

 

[itNGO]

Hi,
bei der Dimension vermute ich doch, das ihr eine entsprechende Enterprise-Subscription erworben habt? Da müsste euch der Proxmox-Support doch direkt helfen können?

Das scheint mir sonst schon etwas "heiss" wenn das live geht?

Ansonsten würde ich auch empfehlen nicht mehr wie 15 virtuelle Disks pro VM.

 

[itNGO]

Hi,
evtl. wäre eine Option noch die VMs sowohl mit VirtIO Block als auch mit SCSI zu konfigurieren und die Disks entsprechend gleichmässig auf die beiden virtuellen Controller zu verteilen. Ggf. die Bootdisk noch an einen SATA-Controller.

Keine Ahnung ob das Zweckmässig ist, aber es sollte die Diskload innerhalb von Proxmox besser verteilen.