openSuse 12.2

Infos für den professionellen Servereinsatz mit Xen und DRBD

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:

  1. 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.

  2. 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%. 

Hinweise für openSuse 11.0

XEN.

DRBD Partition definieren

ISCSI Aktivieren


Autor: Dr. G. Quade e-mail: quade@uni-bonn.de
Letzte Änderung: Monday, 12-Nov-2012 16:40:20 CET