Login
Login-Name Passwort


 
Newsletter
Werbung

So, 15. Februar 2009, 00:00

Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 10

Optimierungen und Einrichtung von Heartbeat mit CRM

In diesem Artikel wird der hochverfügbare Server auf den neuesten Stand gebracht. Software-Updates und Optimierungen sorgen für bessere Leistung, und die schon lange angestrebte Umstellung auf den Cluster Resource Manager (CRM) von Heartbeat wird vollzogen.

Einleitung

Dies ist Teil 10 des Workshops »Virtueller hochverfügbarer Linux-Server«. Die weiteren Teile finden Sie über das Inhaltsverzeichnis.

Die erste Hälfte dieses Artikels befasst sich mit Software-Updates und Optimierungen. Diese sind optional und können ggf. auch später durchgeführt werden. Das zweite Hälfte beschreibt die Umstellung von Heartbeat auf CRM. Beide Kapitel bieten »Gelegenheit«, die Server wieder einmal herunterzufahren, was man nutzen kann, um die Hardware der Server zu warten und zu entstauben. Auch das muss gelegentlich einmal sein.

Optimierung des Systems

Bevor wir zum Hauptthema des Artikels kommen, wollen wir einige Optimierungen vorstellen, die im Lauf der Zeit durchgeführt wurden. Eine erste Maßnahme ist die Aktualisierung auf den neuesten Kernel (momentan 2.6.28.5). Sowohl die Hosts als auch die virtuellen Maschinen sollten auf diese Version aktualisiert werden. Gleichzeitig sollte man auch die neueste Version von DRBD zum Einsatz bringen (momentan 8.2.7) und KVM auf Version 83 aktualisieren.

Kernel

Beim Compilieren des Kernels für die VMs sollte man darauf achten, dass die »dynticks« eingeschaltet sind (zu finden unter Processor type and featuresTickless System (Dynamic Ticks) in der Konfiguration). Mit dieser Option sinkt der CPU-Verbrauch von KVM drastisch, damit kann KVM erstmals in der Leistung mit Xen und OpenVZ mithalten.

Desweiteren sollte man im VM-Kernel die virtuellen Gerätetreiber auswählen, zu finden unter VirtualizationPCI driver for virtio devices. Dass dieser Punkt noch als EXPERIMENTAL gekennzeichnet ist, liegt wohl eher daran, dass sich das API noch ändern könnte, als dass Probleme auftreten könnten. Danach kann man unter Device DriversBlock devicesVirtio block driver den Blockgerätetreiber und unter Device DriversNetwork device supportVirtio network driver den Netzwerktreiber auswählen.

Während man den Netzwerktreiber als Modul compilieren kann, muss der Blockgerätetreiber fest eincompiliert werden. Denn gewöhnlich sind die Initial Ramdisks der Distributionen noch nicht darauf eingerichtet, eine solche Festplatte zu erkennen. Der Treiber kann daher nicht als Modul nachgeladen werden, sondern muss beim Booten schon vorhanden sein.

Partitionen und Dateisysteme

Bei der Einrichtung des Servers hatte ich mich dazu entschlossen, die in LVM eingebaute Striping-Funktionalität zu nutzen. Dies scheint nicht die erwartete Leistung zu bringen. Im Nachhinein wäre es wohl besser gewesen, die Festplatten zunächst zu einem RAID 0 zu bündeln und darauf dann ein LVM-System zu legen. Auf diesem LVM legt man dann Partitionen an genau wie bisher, die dann mit DRBD auf beide Server gespiegelt werden. Eine Änderung der vorhandenen Installation wäre aber komplex und wurde daher bisher nicht durchgeführt.

In den Partitionen hatte ich Dateien angelegt, die als Image für die Virtuellen Maschinen (VMs) dienen. Es wäre auch möglich gewesen, die Partitionen direkt als Image zur Verfügung zu stellen. Es muss momentan offen bleiben, ob dies einen Geschwindigkeitsvorteil gebracht hätte, aber die Verwaltung wäre wohl etwas einfacher.

Als Dateisystem hatte ich sowohl auf den Hosts als auch in den VMs xfs gewählt. Das ist nach wie vor eine gute Wahl, allerdings lässt sich die Geschwindigkeit optimieren, indem man schon beim Anlegen der Dateisysteme die Option -l size=64m verwendet. Diese setzt die Log-Größe auf 64 MB. In sehr kleinen VMs muss man sich mit 32 MB begnügen oder ganz darauf verzichten. Beim Mounten kann man die Optionen noatime,nodiratime,attr2,logbufs=8 verwenden, um die Geschwindigkeit weiter zu verbessern.

Virtio

Unter dem Schlagwort »virtio« firmieren verschiedene Treiber, die spezielle virtuelle Geräte in einer VM ansteuern. Dass diese Methode schneller ist, als ein reales Gerät zu simulieren, dürfte einleuchten. Wir beschränken uns für heute auf virtuelle Netzwerk- und Blockgeräte.

Wir ersetzen die emulierte Netzwerkkarte rtl8139 durch virtio, indem wir - nach Installation des neuen Kernels - in die Datei /etc/modules die Treiber virtio_net und virtio_pci eintragen. In der Startdatei /etc/kvm/[vm] ersetzen wir die Option -net nic,macaddr=66:66:66:66:66:00,model=rtl8139 durch -net nic,macaddr=66:66:66:66:66:00,model=virtio. Beim nächsten Start der VM sollte die virtuelle Schnittstelle aktiv sein.

Ähnlich ist die Vorgehensweise beim Blockgerätetreiber. Hier müssen wir uns im Klaren sein, dass sich der Gerätename der virtuellen Festplatte von sda auf vda ändern wird (auch mehr als eine Festplatte ist möglich, die Bezeichnung ist dann vdb usw.). Wenn man in /etc/fstab mit Labels oder UUIDs gearbeitet hat, ist man aus dem Schneider, da sich dann nichts ändert. In der Startdatei /etc/kvm/[vm] ist auf jeden Fall eine Anpassung nötig. Die Option -hda /mnt/vm100/vm100.image wird durch -drive file=/mnt/vm100/vm100.image,if=virtio,boot=on ersetzt, und die Option -append "root=/dev/sda1 ro" ändert sich zu -append "root=/dev/vda1 ro".

Eine erste Geschwindigkeitsmessung der virtuellen Festplatte zeigt für virtio fast durchweg große Geschwindigkeitsvorteile. Lediglich beim sequenziellen Schreiben war der Durchsatz aus ungeklärten Gründen niedrig. Die Ergebnisse schwankten allerdings in jedem Testlauf erheblich, obwohl die VM die einzige auf dem Server war.

Die erste Messung wurde noch mit Linux 2.6.26.3 als Host-Kernel und KVM 82 durchgeführt. Die VM mit virtio hatte Kernel 2.6.28. Die letzte der drei Messsungen fand unter einem Host mit Linux 2.6.28.5 statt. Tests mit dd bestätigten die Messung im Wesentlichen.

Ohne virtio

/usr/sbin/bonnie++ -s 512m:256k -n 128k:0:1999:1 -f -q
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
krakatau 512M:256k 34652 21 9513 14 25233 31 102.3 17
 ------Sequential Create------ --------Random Create--------
 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
 files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
 128 815 24 20565 66 869 15 706 18 15759 68 265 5

Mit virtio

bonnie++ -s 512m:256k -n 128k:0:1999:1 -f -q
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
vm100 512M:256k 8541 10 16348 27 40613 62 168.4 32
 ------Sequential Create------ --------Random Create--------
 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
 files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
 128 1796 41 165854 89 3173 54 1458 46 10627 75 1753 29
Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung