Die Nachfolgeversionen der openSuse 11.0 brachten zahlreiche Verbesserungen. Insbesondere die Version 11.4 lief im Servereinsatz im Verbund mit Xen und DRBD sehr stabil. Umso größer war die Enttäuschung, dass die openSuse 12.2 im Verbund mit Xen und DRBD massive Probleme beim Servereinsatz zeigte. Out of the Box ist diese Version für unsere Zwecke völlig unbrauchbar. Dies sind die Probleme:
Nach dem Start der ersten DomU lassen sich häufig keine weiteren
Gastsysteme starten. Der folgende Versuch bricht nach einigen Sekunden mit
Fehler ab. Im Log findet sich folgender Fehler: "Error: Device /dev/xvdz
(vbd) could not be disconnected." Manchmal taucht der Fehler auch erst
nach dem Start einiger Gastmaschinen auf. Die Versuche diesen Zustand zu
korrigieren waren frustran. Die Dom0 muss rebootet werden. Ursache ist
vermutlich ein timing Problem.
Lösung: Als quick-fix kann in der Datei /usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py
nach der Zeile "blcfg = bootloader(blexec, fn, ..." ein
"time.sleep(1)" eingefügt werden. Seither gibt es keine
Bootprobleme mehr.
Insbesondere unter Last kann die Dom0 nach einiger Zeit
langsam werden und bleibt letztendlich stehen. Als Problem vermuten wir
"verlorene" Interrupts bei IO-Operationen auf dem Raid-Controller mit
der Folge, dass die Systemfestplatte der Dom0 nicht mehr erreichbar ist. Die
Gastsysteme mit eigenen Volumes sind nicht automatisch mitbetroffen. Der
irqbalancer, der die Interrupts kontinuierlich verteilen sollte,
funktioniert unter openSuse 12.2 mit Xen nicht.
Lösung: Verschieben der Interrupts für den Raid-Controller von der ersten
CPU auf den nächsten realen CPU-Kern. Dazu können in der /etc/init.d/boot.local
die folgenden Zeilen eingefügt werden:
# Um hohen Daten-Durchsatz bei DRBD zu garantieren, müssen folgende
# Schritte durchgeführt werden.
# Die IRQs der Raid-Adapter von LSI oder ARECA werden sicherheitshalber
# von der die Netzwewrk IRQs abarbeitenden CPU getrennt und z.B.
# auf CPU 4 gemappt. Damit ist die IO-Last auf 2 CPUs verteilt.
# Beim Booten sorgt der Bootparameter "elevator=noop" zusätzlich dafür, dass
# die Raid-CPU die Organisation der Lese- und Schreibzugriffe übernimmt.
#
IRQ=`/usr/bin/cat /proc/interrupts | /usr/bin/awk -F: '/arcmsr/ { printf("%d ",$1)}'`; for i in $IRQ; do /usr/bin/echo "04" > /proc/irq/$i/smp_affinity; done
IRQ=`/usr/bin/cat /proc/interrupts | /usr/bin/awk -F: '/megasas/ { printf("%d ",$1)}'`; for i in $IRQ; do /usr/bin/echo "04" > /proc/irq/$i/smp_affinity; done
#
# Die ersten 3 CPUs werden der DOM0 fest zugeordnet.
#
for i in `/usr/bin/seq 0 3`; do /usr/sbin/xl -f vcpu-pin 0 $i $i ; done
Die erste Zeile ist für ARECA-Controller, die zweite für LSI-Controller.
Damit die ersten Kerne unabhängig von der Belastung durch die Gastsysteme
bleiben, werden Sie in der letzten Zeile den ersten virtuellen Kernen der
Dom0 fest zugeordnet. Mit dieser Konfiguration konnten wir auf allen Servern
einen stabilen Betrieb realisieren.
Um die Gastsysteme besser auf die vorhandenen virtuellen CPUs zu verteilen,
kann man sich mit: "xm vcpu-list" die aktuelle Verteilung und den
CPU-Verbrauch ansehen. Mit dem Befehl "xm vcpu-pin domainname all 4-7" kann
man Xen veranlassen, der Domain VCPUs reale CPUs im Bereich 4-7 zuzuordnen. Damit kann
man das Gesamtsystem im Betrieb optimieren. Sollte Xen Gastsystemen die CPUs
zugeordnet haben, die in der Dom0 mit der Abarbeitung von Interrupts
beschäftigt sind, so sollte man dem Gastsystem andere CPUs zuordnen.
Beim Booten kann man der Dom0 schon feste (z.B. die ersten 4) CPUs zuordnen.
Das kann im Betrieb zu Problemen führen. So konnten wir mehrfach
beobachten, dass netback Prozesse 100% CPU Last verursachten. Sobald die
Dom0 auf alle CPUs zugreifen konnte, ging die Last auf fast 0%
zurück.
Das Betriebssystem versucht die Zugriffe auf die Festplatte zu optimieren. Dazu sortiert es die angeforderten IO-Zugriffe um. Standardmäßig ist das CFQ (complete fair scheduling) aktiviert. Dies ist bei schnellen Raid Sytemen oder bei einer ssd kontraproduktiv. Der raid-Controller kann das viel besser erledigen. Um CFQ komplett auszuschalten, muss der noop scheduler aktiviert werden. Das kann beim Booten durch den Bootparameter "elevator=noop" geschehen. Als Ergebnis stieg der Durchsatz z.B. beim resync unter DRBD um 50%.