XEN Bridge und VIF verschlucken Änderungen der MTU Size
Das Gemeine an diesem Problem ist, dass es anscheinend von verschiedenen Rahmenbedingungen ausgelöst wird und sich weder im Oracle VM Manager noch innerhalb der virtuellen Maschinen finden lässt. Nur wenn man direkt auf den Oracle VM Servern selbst sucht, wird man fündig.
Performance Probleme mit NFS und dNFS und Jumbo Frames
Aufmerksam wird man darauf erst, wenn man in Performance Themen innerhalb der Oracle VMs läuft, sofern diese auf NFS liegen (egal ob man dNFS nutzt oder nicht) und man Jumbo Frames (MTU Size > 1500) nutzt. Aufgefallen ist es erstmals, als wir bei einem Kunden mit Oracle 12.1.0.1, dNFS und MTU=9000 festgestellt haben, dass alle Verarbeitungen, die I/O machen, extrem langsam waren. Beispielsweise hat der IMPDP statt der erwarteten 1-2 Stunden fast 20 Stunden benötigt. Das gleiche gilt für die Verarbeitungen innerhalb der Datenbank.
Analyse mittels I/O Calibrate
Da wir bei dem Kunden ein I/O Calibrate von einem physischen Server auf eine Test Datenbank gemacht haben, waren uns die Performance Eckdaten der Storage sehr gut bekannt:
Vom physischen Server, Test-Datenbank ca. 3GB (was kann die Storage aus dem Cache liefern):
Max. IOPS von über 51.400
Max. Latency von: 2ms
Vom physischen Server, Test-Datenbank ca. 850GB (was liefern die vorhandenen HDDs):
Max. IOPS von über 5.000
Max. Latency von: 11ms
Ein I/O Calibrate von der virtuellen Maschine brachte folgende Werte (stark schwankend bei mehreren Versuchen):
Max. IOPS einige 100 bis maximal knapp 800
Max. Latency zwischen: 16ms und 22ms
Damit war klar, es muss sich um ein Thema im Infrastrukturbereich (der beginnt ab der virtuellen Netzwerkkarte in der virtuellen Maschine) handeln. Da wir für die I/O Calibrate Messungen vom physischen Server einen Server verwendeten, der im Anschluss für die OVM Installation herangezogen wurde, konnten wir eine Fehlkonfiguration der physischen Infrastruktur (Storage und Switches) ausschließen.
Check innerhalb von Oracle VM Manager
Die Suche haben wir im Oracle VM Manager gestartet, doch hier war die MTU Size von 9000 in allen Definitionen und Einstellungen korrekt hinterlegt.
Check innerhalb der virtuellen Maschine
Wenn man mittels ifconfig ethX nachgesehen hat, war auch hier die MTU Size von 9000 korrekt konfiguriert.
Check auf den Oracle VM Servern
Auch der Check von ifconfig bondX zeigte nichts verdächtiges - die MTU Size war auch hier korrekt gesetzt. Wenn man allerdings weiter sucht welche XEN Bridges und VIPs genutzt werden, wird man fündig,
Welche XEN Bridges sind definiert und welche VMs laufen darauf:
brctl show
bridge name bridge id STP enabled interfaces
0a2e0000 8000.002655de686a no bond0.46
vif5.0
103cbb3923 8000.90e2ba69f954 no bond2.146
vif5.1
1095eb207c 8000.002655de6869 no bond1.147
In diesem Environment werden die beiden VLANs 146 und 147 mit Jumbo Frames verwendet - somit sind die beiden Bridges 103cbb3923 und 1095eb207c relevant.
ifconfig 103cbb3923
103cbb3923 Link encap:Ethernet HWaddr 90:E2:BA:69:F9:54
inet addr:10.146.1.44 Bcast:10.146.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:55845564 errors:0 dropped:37 overruns:0 frame:0
TX packets:69356232 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:175421045611 (163.3 GiB) TX bytes:57128717292 (53.2 GiB)
ifconfig vif5.1
vif5.1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:49 errors:0 dropped:0 overruns:0 frame:0
TX packets:191 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:3444 (3.3 KiB) TX bytes:13187 (12.8 KiB)
Damit hatten wir die Übeltäter gefunden. Sowohl die Bridge als auch das von der Bridge abhängige VIF haben nur eine MTU Size von 1500 (dem Default). Das bedeutet, dass jedes Netzwerkpaket der virtuellen Maschine bei der Übergabe an die VIF (virtuelle IP Interface) aus einem großen Paket mehrere kleine Pakete machen muss.
kurzfristige Workarounds
Da das Problem nicht auf jedem Oracle VM Server auftritt - anscheinend ist es abhängig von Hardware Treibern für die Netzwerkkarten,... es ist aber egal ob man mit Oracle VM 3.3 neu installiert oder ein bestehendes (korrekt mit Jumbo Frames laufendes) Oracle VM 3.2 System upgraded - macht es die Lösung / Behebung komplizierter.
Die Workaround über den Oracle VM Manager
Wenn man alle VMs von dem betreffenden Server weg verschiebt, die MTU Einstellungen (Vorsicht an 2 Stellen!) auf 1500 zurück setzt und anschließend wieder auf 9000 ändert, wird die Bridge in den meisten Fällen korrekt konfiguriert. Spätestens nach 2 Versuchen waren wir immer erfolgreich. Sobald die MTU einmal korrekt angezeigt wird, stimmt diese auch nach einem - über den Oracle VM Manager initiierten - Neustart des Oracle VM Servers.
Die Workaround über die Konsole - wenn man den Server nicht von den VMs frei bekommt
Hier gibt es mehrere Möglichkeiten - folgende haben wir getestet:
Manuelles Einstellen der MTU auf den Interfaces (muss man leider jedes mal machen, wenn der OVM Server oder eine VM neu startet)
ip link set 103cbb3923 mtu 9000
ip link set vif5.1 mtu 9000
Der Weg über "ip link set" ist Quick & Dirty - er funktioniert sofort, aber nach einem Restart des OVM Servers oder der VM sind die Einstellungen verloren. Daher sollte man diesen Weg nur dann beschreiten, wenn man SOFORT eine Lösung benötigt und keine Zeit für eine Rekonfiguration hat.
Der zweite Weg ist ebenfalls nicht empfehlenswert, da der nächste Xen Patch diesen potentiell wieder zerstört. Man kann in /etc/xen/scripts/ in den Files vif-bridge und vif-switch einbauen, dass die MTU für die benötigten bridges immer auf den benötigten Wert gesetzt wird. VORSICHT nicht für alle! Es wird immer Bridges geben, die ohne Jumbo Frames konfiguriert sein sollen. Bitte einen Restart des Servers nicht vergessen!
Sobald die Bridges die korrekten MTUs haben, kann man die VIFs entsprechend umsetzen - eine Anleitung findet man hier: wiki.xen.org unter Enabling Jumbo Frames.
Die Lösung
Die einzige wirklich auf Dauer praktikable Lösung ist ein Hack des für das Bridge Interface zuständige Script. Allerdings muss man nach jedem Upgrade/Patch verifizieren ob man den Hack/Patch erneut einbauen muss.
Solange es vom Hersteller keine entsprechende Korrektur (Patch) gibt, haben wir folgenden Hack Scripts erfolgreich implementiert. Die Umsetzung muss auf jedem OVM Server erfolgen.
Auf den OVM Servern vom Skript /etc/xen/scripts/vif-bridge eine Sicherheitskopie erstellen
cp /etc/xen/scripts/vif-bridge /etc/xen/scripts/vif-bridge.ori
Ein zusätzliches Skript (in unserem Fall haben wir es /root/fixbrmtu.sh genannt) anlegen
In der Variable BRIDGES_TO_FIX müssen Sie die jeweiligen Bridge Interfaces auf dem OVM Server eintragen, wo die MTU Size auf 9000 gesetzt werden soll.
vi /root/fixbrmtu.sh
#!/bin/bash
BRIDGES_TO_FIX="103cbb3923 1095eb207c"
typeset -i rc=0
for BTF in $BRIDGES_TO_FIX
do
for ITF in $(ls /sys/class/net/$BTF/brif 2>/dev/null)
do
ip link set "$ITF" mtu 9000
rc=rc+$?
done
((rc == 0)) && ip link set "$BTF" mtu 9000
done
Einbauen des Hacks in das vif-bridge Script
Interessanterweise ist dafür im Script vif-bridge der Platz sogar schon vorgesehen. Suchen Sie im File nach "call_hooks vif post" und fügen Sie die folgenden Zeilen ein:
vi /etc/xen/scripts/vif-bridge
...
call_hooks vif post
# diese Zeilen einfuegen # dbm hack start /root/fixbrmtu.sh # dbm hack end
log debug "Successful vif-bridge $command for $dev, bridge $bridge."
if [ "$type_if" = vif -a "$command" = "online" ]
then
success
fi