Archiv für März 2010

Das massenhafte Installieren von Debian-Maschinen lässt sich mit Hilfe von Preseeding und Netboot vereinfachen. Friedrich Weber hat in seinem Schülerpraktikum hier bei uns den entsprechenden Prozess gelernt - und in einem Howto fest gehalten.

Man stelle sich die folgende Situation vor: plötzlich finden sich einige zehn bis zwanzig fabrikneue Notebooks und eine wunderbare Idee, was man mit ihnen anstellen könnte: ein deutschsprachiges Debian installieren und das Ganze nach den eigenen Wünschen anpassen. Allerdings wird sofort klar, dass es nicht den geringsten Spaß macht, auf jedem Notebook manuell die Debian-Installation und -Konfiguration vorzunehmen. An dieser Stelle kommt Debian Preseed ins Spiel.

Das Konzept ist einfach und einleuchtend: Der normale Debian-Installer stellt während der Installation eine Reihe Fragen (zu Sprache, Partitionierung, Paketen, Bootloader etc.). Über Preseed kann man nun zu jeder zu stellenden Frage eine Antwort vorgeben. Nur Fragen, für die man nicht schon über Preseed eine Antwort vorgibt, stellt der Debian-Installer überhaupt noch. Im Idealfall werden nun nur noch am Anfang der Installation einige Fragen angezeigt, deren Antworten sich von Zielsystem zu Zielsystem unterscheiden und die der Administrator manuell abhandeln muss - nachdem diese beantwortet wurden, kann die Installation unbeaufsichtigt ablaufen.

Preseed arbeitet mit einer sehr einfach aufgebauten Konfigurationsdatei: der preseed.cfg. Sie beinhaltet, wie oben beschrieben, Antworten auf Fragen während der Installation, und das im debconf-Format. Eine solche Datei besteht aus mehreren Zeilen, von denen jede Zeile eine debconf-Konfigurationsoption - eine Antwort auf eine Frage - festlegt, zum Beispiel so:

    d-i debian-installer/locale	string de_DE.UTF-8

Diese Zeile beinhaltet als erstes Element den Namen des Paketes, das konfiguriert wird (d-i ist hier eine Kurzform für debian-installer), als zweites Element den Namen der Option, die gesetzt wird, als drittes Element den Typ der Option (hier string, eine Zeichenkette), und der Rest ist der Wert der Option. Mit diesem Beispiel wird also die Sprache auf deutsch mit UTF-8-Kodierung gesetzt.

Solche Zeilen kann man sich selbst zusammenbasteln, einfacher geht es aber mit dem Tool debconf-get-selections: Dieses Kommando gibt schlicht und einfach alle Optionen aus, die lokal gesetzt wurden. Aus der Ausgabe können die gewünschten Einstellungen herausgefischt, gegebenenfalls angepasst und in die preseed.cfg kopiert werden.

Hier ein Beispiel einer solchen preseed.cfg:

    d-i debian-installer/locale string de_DE.UTF-8
    d-i debian-installer/keymap select de-latin1
    d-i console-keymaps-at/keymap select de
    d-i languagechooser/language-name-fb select German
    d-i countrychooser/country-name select Germany
    d-i console-setup/layoutcode string de_DE

    d-i clock-setup/utc boolean true
    d-i time/zone string Europe/Berlin
    d-i clock-setup/ntp boolean true
    d-i clock-setup/ntp-server string ntp1

    tasksel tasksel/first multiselect standard, desktop, gnome-desktop, laptop
    d-i pkgsel/include string openssh-client vim less rsync

Mit diesen Optionen werden Spracheinstellungen und Zeitzone gesetzt, außerdem zu installierende Tasks und Pakete ausgewählt.
Vollkommen unbeaufsichtigt wird diese Installation nicht ablaufen, aber ein Anfang ist es auf jeden Fall.

Nun stellt sich die Frage, woher Preseed eigentlich seine Konfigurationsdatei bezieht. Grundsätzlich ist es möglich, Preseed mit CD- und DVD-Images oder USB-Sticks zu nutzen. Wesentlich komfortabler ist es aber, ein Debian-netboot-Image zu benutzen, also einen Installer, der über das Netzwerk gestartet wird und bei dieser Gelegenheit auch seine Preseed-Konfiguration beziehen kann. Dieses Booten über Netzwerk wird mit PXE realisiert und setzt ein System voraus, das von Netzwerkkarte booten kann.

Zunächst wird das System angewiesen, von der Netzwerkkarte zu booten. Dafür fordert es von einem DHCP-Server per Broadcast eine IP-Adresse an. Dieser DHCP-Server übermittelt aber nicht nur eine passende IP, sondern auch die IP eines sogenannten Bootservers. Ein Bootserver ist ein TFTP-Server, der einen Bootloader bereitstellt, mit dem der Administrator den gewünschten Debian-Installer auswählt. Gleichzeitig kann dem Debian-Installer hier über Boot-Optionen mitgeteilt werden, dass er Preseed benutzen soll und wo er die Preseed-Konfiguration finden kann. Hier ein Ausschnitt der PXELINUX-Konfigurationsdatei pxelinux.cfg/default:

    label i386
        kernel debian-installer/i386/linux
        append vga=normal initrd=debian-installer/i386/initrd.gz netcfg/choose_interface=eth0 domain=example.com locale=de_DE debian-installer/country=DE debian-installer/language=de debian-installer/keymap=de-latin1-nodeadkeys console-keymaps-at/keymap=de-latin1-nodeadkeys auto-install/enable=false preseed/url=http://$server/preseed.cfg DEBCONF_DEBUG=5 -- quiet 

Wenn der User also i386 eintippt, wird der Kernel debian-installer/i386/linux (zu finden auf dem TFTP-Server) heruntergeladen und gestartet, diesem werden außerdem eine ganze Menge Bootoptionen mit auf den Weg gegeben. Der Debian-Installer erlaubt das Angeben von debconf-Optionen als Bootparameter. Das ist sehr praktisch, denn dem Installer muss irgendwie mitgeteilt werden, wo die Preseed-Konfiguration im Netzwerk zu finden (preseed/url) ist. Damit er diese Preseed-Konfiguration herunterladen kann, muss er allerdings auch ins Netzwerk eingebunden sein. Dafür werden ihm die nötigen Optionen übergeben (die Option für den Hostnamen wurde hier bewusst ausgelassen, denn jedes Zielsystem hat natürlich einen anderen Hostname). auto-install/enable würde die Spracheinstellungen verzögern, sodass sie erst nach der Netzwerkkonfiguration gestellt würden, damit diese Einstellungen ebenfalls aus der preseed.cfg gelesen werden könnten. Das ist hier nicht notwendig, denn die Spracheinstellungen werden ebenfalls als Kerneloptionen übergeben, um zu gewährleisten, dass auch die Netzwerkkonfiguration deutschsprachig ist.

Die vorgestellten Beispiele und Konfigurationsauszüge sind natürlich sehr allgemein gehalten und stark gekürzt. Trotzdem sollte dieser Blog-Post eine Einführung in das Preseed-Konzept in Verbindung mit netboot geboten haben. Abschließend noch eine vollständigere Fassung der preseed.cfg:

    d-i debian-installer/locale string de_DE.UTF-8
    d-i debian-installer/keymap select de-latin1
    d-i console-keymaps-at/keymap select de
    d-i languagechooser/language-name-fb select German
    d-i countrychooser/country-name select Germany
    d-i console-setup/layoutcode string de_DE

    # Netzwerk
    d-i netcfg/choose_interface select auto
    d-i netcfg/get_hostname string debian
    d-i netcfg/get_domain string example.com

    # Paketmirror
    d-i mirror/protocol string http
    d-i mirror/country string manual
    d-i mirror/http/hostname string debian.example.com
    d-i mirror/http/directory string /debian
    d-i mirror/http/proxy string
    d-i mirror/suite string lenny

    # Zeitzone
    d-i clock-setup/utc boolean true
    d-i time/zone string Europe/Berlin
    d-i clock-setup/ntp boolean true
    d-i clock-setup/ntp-server string ntp.example.com

    # Root-Account
    d-i passwd/make-user boolean false
    d-i passwd/root-password password geheimespasswort
    d-i passwd/root-password-again password geheimespasswort

    # Weitere APT-Optionen
    d-i apt-setup/non-free boolean false
    d-i apt-setup/contrib boolean false
    d-i apt-setup/security-updates boolean true

    d-i apt-setup/local0/source boolean false
    d-i apt-setup/local1/source boolean false
    d-i apt-setup/local2/source boolean false

    # Tasks
    tasksel tasksel/first multiselect standard, desktop
    d-i pkgsel/include string openssh-client vim less rsync
    d-i pkgsel/upgrade select safe-upgrade

    # Popularity-Contest
    popularity-contest popularity-contest/participate boolean true

    # Kommando, das nach der Installation ausgeführt wird. `in-target` bedeutet, dass das folgende
    # Kommando in der installierten Umgebung ausgeführt wird, nicht in der Installationsumgebung.
    # Hier wird http://$server/skript.sh nach /tmp heruntergeladen, ausführbar gemacht und ausgeführt.
    d-i preseed/late_command string in-target wget -P /tmp/ http://$server/skript.sh; in-target chmod +x /tmp/skript.sh; in-target /tmp/skript.sh

Alle Howtos dieses Blogs werden auch als Kategorie Howto samt eigenem Feed angeboten - und falls ihr nach Support und Services für Debian sucht, seit ihr bei uns ebenfalls richtig.

Nvidia hat bekannt gegeben, dass der freie nv-Treiber nicht mehr länger unterstützt wird. Beginnend mit den soeben neu veröffentlichten Fermi-Grafikkarten werden zukünftige Karten von Nvidia nicht mehr mit dem Treiber nv funktionieren.

Ursprünglich war der nv-Treiber von Nvidia entwickelt worden, um auf aktueller Hardware eine brauchbare 2D-Performance zu erlangen. 3D-Unterstützung war dort von vornherein weder gewollt noch geplant gewesen, und wurde auch nie angegangen. Nutzer mit 3D-Ansprüchen wurden schon immer auf den proprietären Treiber von Nvidia verwiesen.

Für die Zukunft sollen nun alle Nutzer den proprietären Treiber verwenden - für eine erste Installation unter Linux sei der Vesa-Treiber ausreichend, so Nvidia in einem Statement. Da der nv-Treiber kaum mehr biete als der Vesa-Treiber, sei dies in Ordnung.

Dabei geht die Bekanntgabe in keinster Weise auf den mittlerweile recht weit fortgeschrittenen Treiber nouveau ein, der vor einigen Wochen in den Kernel aufgenommen wurde und daher standardmäßig bei zukünftigen Distributionen für Nvidia-Karten zum Einsatz kommen wird. Denn dieser Treiber bietet neben 2D- auch 3D-Funktionen, es war bereits absehbar, dass dieser den nv-Treiber mittelfristig überflüssig machen würde.

Unter diesem Gesichtspunkt ist die Ankündigung daher wenig überraschend. Es wäre aber wünschenswert gewesen, hätte Nvidia seine Open-Source-Ankündigungen auf den neuen Treiber nouveau verlegt, statt sie vollständig einzustellen. Bisher sieht es damit leider nicht so aus, als würde sich die forcedeth-Geschichte im Grafik-Bereich wiederholen.

Alle Blog-Artikel zum Thema X11 werden auch als Kategorie X11 samt eigenem Feed angeboten - und falls ihr nach Support und Services für Linux sucht, seit ihr bei uns ebenfalls richtig.

Die PostgreSQL-Entwickler haben die aktuellen stabilen Versionszweige 8.4, 8.2, 8.1, 8.0 und 7.4 mit neuen Updates versorgt.

Die PostgreSQL Community hat neue Versionen der aktuellen stabilen Zweige veröffentlicht. Dies aktualisiert diese auf die Versionen 8.4.3, 8.3.10, 8.2.16, 8.1.20 und 8.0.24 sowie 7.4.28.

Upgrades können ohne Dump/Restore der Datenbanken innerhalb eines Zweiges durchgeführt werden. Neben einigen kleineren Fehlerkorrekturen beheben diese Aktualisierungen unter anderem:

• Neuer Konfigurationsparameter ssl_renegotiation_limit. Dies erlaubt das Setzen der Menge an Daten, die über eine Datenbankverbindung übertragen werden darf, bevor die SSL-Verbindung neu ausgehandelt wird. Einige ältere OpenSSL-Versionen können einen Fix für das Sicherheitsleck (CVE-2009-3555) enthalten, die in diesem Fall zu Abbrüchen der Datenbankverbindung führen können, so dass dies mit Setzen des Parameters auf 0 abgeschaltet werden kann.
• Beheben eines Deadlocks bei Neustart des Datenbankserver
• Bessere Fehlerbehandlung bei Neuladen des Relcache
• Abstürze beim Recovern von Subtransaktionen wurden behoben
• Fix für mögliche Indexkorrumpierung bei GiST-Indexe, sowie Datenverlust bei GIN-Indexe

Es wird empfohlen, beim nächsten Wartungsfenster auf die neueste jeweilige Minor-Version des eingesetzten stabilen Zweiges zu wechseln. Detaillierte Informationen über die einzelnen Fixes können über die Releasenotes der Projektseite eingesehen werden.

Alle Blog-Artikel zum Thema PostgreSQL werden auch als Kategorie PostgreSQL samt eigenem Feed angeboten - und falls ihr nach Support und Services für PostgreSQL sucht, seit ihr bei uns ebenfalls richtig.

Die Resonanz auf die Vorstellung der Open Source Support Card war immens. Im Folgenden listen wir die wichtigsten Reaktionen der Presse und das Feedback der Community auf.

Die gestern erfolgte Vorstellung der Open Source Support Card wurde von einem großen Presse-Echo begleitet - alle großen Nachrichtenportale haben darüber berichtet, und die Berichte waren sehr positiv. Das ist ein deutliches Zeichen dafür, dass Linux-Support für viele Business-Kunden ein interessantes und wichtiges Thema ist - und dass unser Angebot etwas wirklich neues ist - wir lassen "einen frischen Frühlingswind" durch den Markt fegen, wie die Pressemitteilung so schön sagte.

Hier die bisher gefundenen Artikel im deutschsprachigen Raum - bitte hinterlasst Kommentare, wenn wir was übersehen haben:

• Heise - Linux-Support à la carte


• Golem - Linux Support Card: Prepaid-Karte für Linux-Hilfe


• Linux-Magazin - Linux-Support auf Guthabenkarte (Dort waren wir auch Top-Thema im Newsletter.)


• Pro-Linux - Credativ startet die Linux Support Card


• Winfuture - Linux-Support gibt es nun auch per Prepaid-Karte


• OSZine - credativ veröffentlicht die Open Source Support Card (Achtung: bei OSZine arbeiten wir selbst ehrenamtlich viel als Autor mit!)

Aber auch die Reaktionen in diversen Foren waren interessant zu lesen: die Preise, aber auch unser Open Source Support Center (OOSC), unsere Open Source Support Referenzen und unsere Firma an sich wurden ausführlichst besprochen. Diese sehr umfangreichen Diskussionen zeigen ebenfalls, dass wir mit dem Angebot den Puls der Zeit und den Nerv vieler Linux-Admins im professionellen Umfeld getroffen haben.

Für uns alle war es ein dementsprechend bestärkender Tag, und wir sind zufrieden in den Feierabend gegangen. Wir danken für das umfangreiche Feedback, und stehen für Fragen immer gerne zur Verfügung - auch hier im Blog. Allerdings werden wir nicht verraten, welches Thema die nächste Open Source Support Card abdeckt. Ihr könnt ja mal raten. ;-)

Alle Blog-Artikel zu unserer Firma werden auch als Kategorie credativ samt eigenem Feed angeboten.

Ab sofort bietet credativ die Open Source Support Card an. Mit ihr kann Open Source Support für klar umrissene Themen ohne Vertragsbindung eingekauft werden - zu einem festen Preis.

Nach langer Vorbereitungszeit ist es jetzt so weit: ab heute bieten wir mit der Open Source Support Card unseren gewohnten Service auf eine neue, einfachere Art an: Themen-bezogen, im Vorfeld bezahlt und mit festem Kontingent.

Mit der Open Source Support Card haben die Kunden den Vorteil einer absoluten Kostenkontrolle, und es entfällt die für einige Kunden hinderliche Bindung an einen Vertrag - die Karte wird als normales Produkt erworben! Das kann insbesondere in der Rechnungsführung größerer Unternehmen praktisch sein, nicht zu Unrecht wird sich der ein oder andere Leser an die "Prepaid"-Modelle im Mobilfunkbereich erinnert fühlen. Die Presse-Mitteilung gibt eine ganz gute Übersicht der Vorteile und Bedingungen der Karte:

• Open Source Support für ein klar umrissenes Thema
• Themenbezogener Support für alle Desktops und Server des Unternehmens
• Knackiger Preis: 890 Euro
• Volle Kostenkontrolle
• Support per Telefon, E-Mail und Remote
• Hilfe in englischer oder deutscher Sprache
• KEINE Abhängigkeit von Zahl der Nutzer, CPUs oder ähnlichem
• KEINE Vertragsbindung, sondern einfache Bestell-Abwicklung
• KEIN Call-Center - direkter Support durch uns
• Die Supporteinheiten können für folgende Dienstleistungen genutzt werden:
• Administration
• Installation (Remote)
• Beratung

Dabei wird der Support auf die credativ-typische Art und Weise geliefert: unabhängig von der Zahl der CPUs, Nutzer oder DB-Einträge, wie auch bei unseren klassischen Verträgen. Support-Einheiten, die mit der Open Source Support Card erworben werden, können für alle vorhandenen Rechner genutzt werden, unternehmensweit. Geleistet wird der Support - selbstverständlich - von unserem Open Source Support Center: dort gibt es keine FAQ-Schleifen oder lästige Diskussionen mit nicht-technischem Personal. Wir sind Linux-Spezialisten und Open-Source-Experten, die allesamt selbst in diversen Projekten aktiv sind - regelmäßigen Lesern dieses Blogs dürfte das aber eh klar sein. ;-)

Für die Community ist das Angebot in so fern interessant, dass der Einsatz freier Distributionen jetzt attraktiver wird. Denn das Preisangebot von unter 1000 Euro dürfte den Anbietern kommerzieller Distributionen einiges an Kopfzerbrechen bereiten, und nicht wenige Firmen können sich jetzt einen Umstieg hin zu Debian oder CentOS ernsthaft überlegen. Die Karte ist sogar so angelegt, dass auch Reseller sie verkaufen können - mit etwas Glück könnt ihr demnächst neben dem Debian-Server auch gleich den Support in den Warenkorb klicken.

Aktuell steht die Support Card in Deutschland für die Distributionen Debian und CentOS zur Verfügung. Weitere Projekte und andere Open-Source-Software werden folgen, genauso wie die Verfügbarkeit in den USA, Großbritannien und Kanada. Wenn ihr weitere Fragen oder vielleicht auch Wünsche habt, hinterlasst bitte Kommentare - wir haben viel Arbeit in dieses Projekt gesteckt, und sind sehr auf die Reaktion unserer Kunden, aber auch der Community selbst, gespannt.

Der OOM-Killer kann auf stark ausgelasteten Maschinen für böse Überraschungen sorgen: Prozesse werden plötzlich und unerwartet beendet. Dieses Verhalten lässt sich aber mit Kernel-Bord-Mitteln sehr genau beeinflussen.

Administratoren auf Linuxmaschinen mit hoher RAM-Nutzung erleben oft eine Begegnung der unheimlichen Art: den Linux OOM-Killer (OOM = Out Of Memory). Der Administrator findet in diesem Szenario eine "abgestürzte" PostgreSQL-Instanz vor, im Serverlog finden sich dann einer oder meist mehrere Einträge der Form

Out of Memory: Killed process PID (Prozessname)

Doch was genau steckt dahinter?

Virtueller Speicher und Overcommit

Virtueller Speicher in Linuxsystemen wird auf vielfältige Weise adressiert: RAM, mmap(), Swap oder Shared Memory, um ein paar Beispiele zu nennen. Es ist möglich, durch das sogenannte Overcommit-Verhalten bei Allokieren von Speicher mehr Ressourcen anzufordern, als tatsächlich im System aktuell vorhanden ist. In solchen Situationen spricht man von einer OOM-Situation, das System hat alle Ressourcen aufgebraucht und ist nicht mehr in der Lage, mehr virtuellen Speicher zu adressieren. Hier wird der OOM-Killer aktiv, der Prozesse nach festgelegten Kriterien auswählt und diese terminiert, um dem System ein wenig Luft zu verschaffen. Dieses Verhalten ist insbesondere für Datenbanksysteme zu berücksichtigen, die nicht auf dedizierter Hardware laufen. Der OOM-Killer bevorzugt in solchen Umgebungen häufig PostgreSQL, da als Kandidaten zum Terminieren solche Prozesse ausgewählt werden, die mit aggressiver Speichernutzung auffallen. Da der OOM-Killer den gesamten Adressraum aller Kinder inklusive Shared Memory in Summe sieht, erkennt man recht schnell, dass PostgreSQL auf jeden Fall weit oben in der Liste der Kandidaten auftauchen wird.
Wie stark der zur Verfügung stehende Speicher genutzt wird, findet man am schnellsten über das /proc-Filesystem heraus:

$ grep Commit /proc/meminfo 
CommitLimit:    376176 kB
Committed_AS:   265476 kB

In diesem Beispiel sind aktuell als Obergrenze 376176 kB(CommitLimit) an Speichernutzung möglich, zugewiesen wurden 265476 kB (Committed_AS). Nähert sich CommitLimit sehr stark an Committed_AS an oder übersteigt diesen sogar, dann ist der Einsatz des OOM-Killers wahrscheinlich.

Der Linux-Kernel stellt einige Schnittstellen zur Verfügung, die das Verhalten des OOM-Killers gegenüber PostgreSQL beeinflusst.

Overcommit abschalten

Die radikalste Methode ist, Overcommit generell im Kernel abzuschalten. Allerdings kommt dies nur für dedizierte Datenbanksysteme in Frage, auf denen PostgreSQL exklusiv läuft. Das Overcommit-Verhalten lässt sich in modernen 2.6ern Kernel in drei Kategorien mit dem Parameter

vm.overcommit_memory = 0

konfigurieren. Die einzelnen Kategorien hierbei sind:

• 0: Vorsichtiges Overcommitverhalten. Während gemäßigte Allokierungen erlaubt sind, werden extrem große Allokierungen, die zu übermäßigem Overcommit führen, abgelehnt. In diesem Modus kann root auch mehr Speicher allokieren als ein unprivilegierter Benutzer. Dieser Modus ist auch die Standardeinstellung des Kernels.
• 1: Overcommit unterliegt keinen Einschränkungen
• 2: Schaltet Overcommitverhalten ab. Generell bedeutet dies, dass der maximale allokierbare tatsächliche Adressraum nicht größer werden kann, als swap + ein konfigurierbarer Anteil an Prozent des physkalischen RAM.

Der Anteil des physikalischen RAM bei Modus 2 wird über den zusätzlichen Parameter

vm.overcommit_ratio = 50

kontrolliert.

Während vm.overcommit_memory=1 für Spezialanwendungen interessant sein könnte, wird es im Praxiseinsatz eher zum Einsatz für die Parameterwerte 0 oder 2 kommen. Wird Overcommit über vm.overcommit_memory=2 abgeschaltet, so wird ein Prozess (in Abhängigkeit von vm_overcommit_ratio) sofort eine "Out Of Memory"-Bedingung beim Allokieren von Speicher erhalten. Abhängig von der Distribution sollte man die Einstellungen permanent in die Datei /etc/sysctl.conf speichern, so dass diese auch nach einem Neustart des Systems aktiv sind:

$ echo "vm.overcommit_memory=2 >> /etc/sysctl.conf
$ echo "vm.overcommit_ratio=60 >> /etc/sysctl.conf
$ sysctl -p /etc/sysctl.conf

Die Änderungen wirken sich sofort auf den virtuellen Speicher aus, man kann dies erneut durch Abrufen von /proc/meminfo überprüfen:

$ grep Commit /proc/meminfo 
CommitLimit:    401440 kB
Committed_AS:   266456 kB

Die Maschine verfügt über 249848 kB Swap und 252656 kB physikalischen RAM. Nach der Formel Swap + vm.overcommit_ratio * RAM ergibt dies ein CommitLimit von 401440 kB.

OOM-Killer auf Prozessebene konfigurieren

Ist PostgreSQL nicht auf einem dedizierten Server installiert und wird mit einer speicherhungrigen Middleware (bspw. JBoss- oder Tomcat-Installation) auf demselben System betrieben, so ist es wünschenswert, Overcommit-Verhalten zwar zu erlauben, im Falle einer "Out Of Memory"-Situation aber PostgreSQL vom OOM-Killer auszunehmen. Seit Kernel 2.6.11 bietet Linux daher ein Interface an, um den OOM-Score eines Prozesses zu tunen, so dass dieser vom OOM-Killer weniger oder stärker berücksichtigt wird. Dies erlaubt ein sehr feinfühliges Einstellen des Systems auf die Speicherbedürfnisse einzelner Prozesse. Die Konfiguration wird über eine Datei im /proc-Filesystem des Kernel vorgenommen, beispielsweise hier für den PostgreSQL-Hauptprozess unter Debian (0 ist die Standardeinstellung für Prozesse):

$ cat /proc/$(cat /var/run/postgresql/8.4-main.pid)/oom_adj
0

Die erlaubten Werte sind von -17 bis +15, negative Werte verringern die Affinität des Prozesses gegenüber den OOM-Killer, positive Werte erhöhen diese. -17 schaltet den OOM-Killer für den jeweiligen Prozess komplett ab. Die Einstellung wird vom Parent an etwaige Kindprozesse weitervererbt. Da PostgreSQL sich für eine Datenbankverbindung forked, reicht es, diese Einstellung dem PostgreSQL-Hauptprozess mitzugeben:

$ echo -17 >> /proc/$(cat /var/run/postgresql/8.4-main.pid)/oom_adj
$ psql -q postgres
test=# SELECT pg_backend_pid();
 pg_backend_pid 
----------------
           3429
(1 Zeile)

test=# 
[1]+  Stopped                 psql -q test
$ cat /proc/3429/oom_adj
-17

Der Nachteil dieser Methode ist, dass dies nun für alle Kindprozesse des PostgreSQL-Hauptprozesses gilt, was eventuell vom DBA nicht mehr gewünscht ist. Beispielsweise möchte man zwar gerne die PostgreSQl-Systemprozesse wie Background Writer oder Autovacuum vor dem OOM-Killer schützen, nicht jedoch normale Datenbankverbindungen.

Das Setzen von /proc/PID/oom_adj erfordert jedoch einen privilegierten Benutzer, so dass man am Besten die Einstellung direkt im Startskript der PostgreSQL-Datenbank vornimmt.

Erweiterungen in PostgreSQL 9.0

PostgreSQL 9.0 wird hinsichtlich der Zusammenarbeit mit dem /proc-Interface ebenfalls einige Neuerungen mitbringen. Zum einen wurde das im Quelltext mitgelieferte Linux-Startskript dahingehend erweitert, zum anderen bietet das Backend nun auch Unterstützung, falls man die /proc-Einstellungen eben nicht an normale Datenbankverbindungen weitervererben möchte. Hierzu kann der PostgreSQL-Server mit dem Makro LINUX_OOM_ADJ=0 kompiliert werden, beispielsweise:

$ ./configure CC="ccache gcc" CFLAGS="-DLINUX_OOM_ADJ=0"

Diese Methode schützt dann die PostgreSQL-Systemprozesse effektiv, erlaubt aber dem OOM-Killer etwaige Amoklaufende Backends trotzdem zu terminieren.

Alternativen

Eine alternative Lösung gibt es auch in Form eines Kernelpatches. Dies ergänzt das /proc-Filesystem um eine Liste an Prozessnamen, die explizit vom OOM-Killer nicht berücksichtigt werden dürfen. Da dies jedoch eine inoffizielle Erweiterung des Kernels ist, muss man seinen eigenen Kernel damit pflegen, auch ist diese Erweiterung bei weitem nicht so flexibel wie das Interface über oom_adj. Des weiteren sind Prozessnamen relativ ungeeignet, um spezifische Prozesse eindeutig zu identifizieren (z.B. Java- oder Perlbasierte Prozesse).

Zusammenfassung

Der Linuxkernel bietet mittlerweile umfassende Möglichkeiten, die Speichernutzung von Prozessen an das Memory Management des Kernels anzupassen. Die flexibelste Lösung stellt das /proc-Filesystem mit dem oom_adj-Interface dar. PostgreSQL 9.0 ergänzt dies durch weitere Maßnahmen. Dedizierte Datenbanksysteme können vom Administrator dahingehend angepasst werden, gar kein Overcommit des virtuellen Speichers zuzulassen, hier muss jedoch sorgfältig abgewogen werden, welche Anforderungen die PostgreSQL-Instanz an die VM des Kernels stellt.

Alle Blog-Artikel zum Thema PostgreSQL werden auch als Kategorie PostgreSQL samt eigenem Feed angeboten - und falls ihr nach Support und Services für PostgreSQL sucht, seit ihr bei uns ebenfalls richtig.

Nach der Einführung in RHCS geht es jetzt ins Eingemachte: die Installation von RHCS unter Debian, um einzelne KVM-Gäste als Dienst anzubieten.

Die Hintergründe von RHCS haben wir bereits erklärt. Die konkrete Umsetzung wird am Beispiel zweier Hosts mit einem Shared Storage erklärt, die als Service verschiedene KVM-Gäste anbieten.

Installation der Nodes

In diesem Setup sind die Nodes die Maschinen, auf denen KVM läuft. Jeder darauf laufende KVM-Gast ist wiederum ein über RHCS verwalteter Dienst. Bei der Installation der KVM-Hosts ist auf mehrere Punkte zu achten:

• /tmp/ und /var/ sollten auf verschiedenen Partitionen liegen, das verbessert die Performance.
• Es sollten Debian-Backports genutzt werden, insbesondere für die Kernel.
• Alle IP-Adressen sollten via DNS in beide Richtungen auflösbar oder in /etc/hosts eingetragen sein.
• Der Hostname darf nicht auf 127.0.0.1 zeigen, das führt zu Problemen mit dem Cluster Management System CMAN.
• /etc/hosts/ und /etc/resolv.conf sollte auf allen Nodes gleich sein.
• ssh-Keys sollten auf allen Nodes passwortlos für root bestehen und auf alle anderen Nodes verteilt werden.
• Aus Performance-Gründen ist es besser, den aktuellesten stabilen Kernel zu installieren. Allerdings lässt linux-image-2.6.32-bpo.2-amd64 die Gast-Kernel >= 2.6.30 crashen, ein Patch ist aber verfügbar, siehe #573071.
• Die Netzwerk-Geräte sollten für einen guten Überblick klar benannt sein - zum Beispiel rhcs-backbone und external anstatt eth0 und eth1.

Einrichtung des Shared Storage

Ein zentrales Element des RHCS ist das Shared Sotrage, auf das die Nodes gemeinsame zugreifen. In diesem Beispiel nehmen wir einen "normalen" Rechner, und installieren auf diesem ein iSCSI-Target:

apt-get install iscsitarget iscsitarget-source 
echo 'ISCSITARGET_ENABLE=true' > /etc/default/iscsitarget
m-a a-i iscsitarget

Hier ist zu beachten, dass das iscsi-Target korrekt bauen muss, siehe auch #566740. Eingerichtet wird die Maschine, welche das Shared Storage bereit stellt, via /etc/ietd.conf:

IncomingUser discovery_in YourSecurePwd1
OutgoingUser discovery_out YourSecurePwd2
Target YOURMACHINE:clvm1
       IncomingUser node_in YourSecurePwd1
       OutgoingUser node_out YourSecurePwd2
       Lun 0 Path=/dev/sdx1,Type=blockio

Auf den Nodes muss das Target korrekt angesprochen werden. Dies wird in der /etc/iscsi/iscsid.conf definiert:

discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = discovery_in
discovery.sendtargets.auth.password = YourSecurePwd1
discovery.sendtargets.auth.username_in = discovery_out
discovery.sendtargets.auth.password_in = YourSecurePwd2
node.startup = automatic
node.session.auth.authmethod = CHAP
node.session.auth.username = node_in
node.session.auth.password = YourSecurePwd1
node.session.auth.username_in = node_out
node.session.auth.password_in = YourSecurePwd2

Gestartet wird der Dienst mit /etc/init.d/open-iscsi start. Vorhandene Targets werden mit den folgenden Befehlen gesucht, gelöscht oder hinzugefügt:

# discovering the targets
iscsiadm -m discovery -t st -p YOURMACHINE -P 1
# deleting target on wrong interface
iscsiadm -m node -p 192.168.0.100:3260,1 -o delete
# opening the portal
iscsiadm -m node --targetname "iqn.2010-03.YOURMACHINE:clvm1" --portal "YOURMACHINE:3260" --

VM setup

Die virtuellen Maschinen werden via KVM bereit gestellt. Dafür muss zuerst die passende Software installiert werden:

apt-get install linux-image-2.6.32-bpo.2-amd64 kvm libvirt-bin virtinst -t lenny-backports

Bei der Einrichtung der Bridge für die Gäste muss darauf geachtet werden, dass der Bridge-Name für alle Nodes gleich sein muss. Auch die libvirt-Konfiguration muss gleich sein, es ist daher hilfreich, auf git und vergleichbare Techniken zurück zu greifen. Danach können die Gäste mit

virt-install -n <NAME> -r 256 --vcpus=1 --disk path=/dev/vg_cluster#/<LV> \
  -c /root/debian-<VERSION>-amd64-netinst.iso --vnc --noautoconsole --os-type linux \
  --os-variant debianLenny --accelerate --network=bridge:bridge0 --hvm -k de

installiert und mit virt-viewer -c qemu+ssh://:/system angesehen werden.

RHCS setup

Der nächste Schritt ist das Aufsetzen von RHCS selbst - dafür müssen in erster Instanz die Programme installiert und aufgerufen werden: apt-get install redhat-cluster-suite. Die dadurch bereit gestellten NFS-Dienste werden aber nicht gebraucht:

invoke-rc.d nfs-kernel-server stop
invoke-rc.d nfs-common stop
invoke-rc.d portmap stop
update-rc.d -f nfs-kernel-server remove
update-rc.d -f nfs-common remove
update-rc.d -f portmap remove

Ein anderes Problem ist, dass das Programm system-config-cluster nicht unter Lenny zur Verfügung steht. Es wurde von credativ-Mitarbeiter Philipp Hübner paketiert und ist in Debian erst ab Squeeze enthalten.
Durch einen Backport kann system-config-cluster aber auch auf Lenny genutzt werden:

wget --no-check-certificate https://www.credativ.com/~phu/lenny-backports/system-config-cluster/system-config-cluster_1.0.53-1_all.deb
dpkg -i system-config-cluster_1.0.53-1_all.deb
apt-get -f install
apt-get install xauth

Damit LVM Locking Cluster-weit funktioniert, muss in der /etc/lvm/lvm.conf im Abschnitt global eine Anpassung vorgenommen werden:

 locking_type = 3

Falls wie empfohlen ein neuerer Kernel eingesetzt wird, liegt das Modul lock_dlm nicht mehr vor. Daher muss das Init-Script von CMAN angepasst werden, die Zeile modprobe lock_dlm 2>&1 || return 1 muss auskommentiert werden. Außerdem unterstützt RHCS 2 nur XEN, für libvirt-Unterstützung muss der Ressource Handler vm.sh geladen werden - er liegt für Debian Squeeze bereit:

wget --no-check-certificate https:///www.credativ.com/~phu/vm.sh -O /usr/share/cluster/vm.sh
chmod +x /usr/share/cluster/vm.sh

RHCS selbst wird gestartet mittels

/etc/init.d/cman start
/etc/init.d/clvm start
/etc/init.d/rgmanager start

Fencing

Fencing beschreibt das automatisierte Neutralisieren von Nodes, die nicht mehr reagieren. Wir setzen in unserem Beispiel dafür eine per Netz steuerbare Steckdose ein, NETIO-230A. Es liegt bisher kein fence agent für dieses Gerät vor, aber mit Hilfe der verfügbaren Python-Bibliothek kann ohne Weiteres ein solcher geschrieben werden.

Abschließende Worte

Dieses Howto zeigt, dass das Einrichten von RHCS unter Debian mit einfachen Schritten möglich ist - wenn auch je nach Einsatz weitere Anpassungen vorgenommen werden müssen. Dabei helfen wir übrigens gerne - Open Source Hochverfügbarkeits-Lösungen gehören zu unseren Spezialitäten, und Services und Support bei KVM-Virtualisierung ist unser Alltagsgeschäft.

Der Text-Editor vim bietet viele Möglichkeiten für Automatismen. Im folgenden Artikel wird das automatische Einfügen von Textbausteinen vorgestellt.

Sehr häufig schreibt man beim Programmieren oder beim Administrieren immer wieder die gleichen Code-Teile. Dabei kann der Editor vim schon beim Anlegen von Dateien erkennen, um was für einen Datei-Typ es sich handelt, und entsprechende Textbausteine bereit stellen. Dies kann durch die Datei .vim/plugin/autoinsert.vim realisiert werden, die zum Beispiel wie folgt aussieht:

if has("autocmd")
augroup autoinsert
  au!
  autocmd BufNewFile *.c call s:Template("c")
  autocmd BufNewFile Makefile call s:Template("make")
  autocmd BufNewFile makefile call s:Template("make-simple")
augroup END
endif

function s:Template(argument)
        if (a:argument == "help")
                echo "Currently availible templates:"
                echo " c                - Plain C Template"
                echo " make             - Makefile Template"
                echo " make-simple      - Simple Variant of the Makefile Template"
        else
                " First delete all in the current buffer
                %d

                " The Makefile variants
                if (a:argument == "make")
                        0r ~/.vim/skeletons/template.make
                        set ft=make
                elseif (a:argument == "make-simple")
                        0r ~/.vim/skeletons/template.make_simple
                        set ft=make
                elseif (a:argument == "make-simple-cpp")
                        0r ~/.vim/skeletons/template.make_simple_cpp
                        set ft=make

                " Stuff for plain C
                elseif (a:argument == "c")
                        0r ~/.vim/skeletons/template.c
                        set ft=c
                endif

                silent %!~/.vim/do_header %
        endif
endfunction

command! -nargs=1 Template call s:Template(<f-args>)

Wie zu sehen ist, werden in den Zeilen 21-35 diverse Templates aufgerufen, die wiederum die Textbausteine beinhalten. Das Template für make_simple, ~/.vim/skeletons/template.make_simple fügt zum Beispiel die üblichen Compiler-Flags zum Bauen von C/C++-Programmen mit dem gcc ein:

CC := gcc
CFLAGS := -Wall -pedantic -O3
LDFLAGS :=

PROG := main
OBJS := main.o

all: $(PROG)

$(PROG): $(OBJS)
        $(CC) $(LDFLAGS) -o $@ $^

clean:
        rm -rf $(PROG) $(OBJS)

.PHONY: all clean

Das folgende Template ~/.vim/skeletons/template.c mit Textbausteinen für Dateien mit der Endung .c fügt neben dem obligatorischen GPL-Header auch ein C-Code-Gerüst ein:

/*
 * %%FILENAME%% - description
 *
 * Copyright (C) %%YEAR%% %%AUTHOR%%
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2, or (at your option)
 * any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
 */

#include <stdio.h>

int
main (int argc, char **argv)
{
  return 0;
}

/**This must remain at the end of the file.**********
 * vim600:set sw=2 ts=8 fdm=marker fmr=«««,»»»:     *
 * vim600:set cindent cinoptions={1s,>2s,^-1s,n-1s: *
 ****************************************************/

Die im Code vorkommenden Variablen wie %%FILENAME%% oder auch %%AUTHOR%% können ebenfalls automatisch beim Aufruf durch ein kleines Shell-Skript ersetzt werden: das Skript ~/.vim/do_header, aufgerufen mit dem Dateinamen als Übergabewert, ermittelt über die glibc-Funktion getent bzw. aus der /etc/passwd den Namen des Autors und setzt diesen ein. Auch andere Variablen werden mit üblichen GNU-Tools ermittelt, wie das folgende Listing zeigt:

#!/usr/bin/env zsh

if which getent > /dev/null; then
        REALNAME=$(getent passwd $USER|awk -F : '{print $5}' | awk -F , '{print $1}')
else
        REALNAME=$(grep $USER /etc/passwd|awk -F : '{print $5}' | awk -F , '{print $1}')
        if which nidump > /dev/null && [ -z "$REALNAME" ]; then
                REALNAME=$(nidump passwd / | grep $USER|awk -F : '{print $8}')
        fi
fi
DATE=$(date)
YEAR=$(date +%Y)
FILENAME=$(echo $1 | sed 's/[^/]*\///')
FILE=$(echo $FILENAME | sed 's/\..*//')
FILEBIG=$(echo $FILE | tr '[:lower:]' '[:upper:]')
sed     "s/%%AUTHOR%%/$REALNAME/g;
        s/%%DATE%%/$DATE/g;
        s/%%YEAR%%/$YEAR/g;
        s/%%FILENAME%%/$FILENAME/g;
        s/%%FILE%%/$FILE/g;
        s/%%FILEBIG%%/$FILEBIG/g;"

Neben den hier gezeigten Beispielen können auch Templates für andere Programmiersprachen oder generell Datei-Typen erstellt werden, die Möglichkeiten sind fast endlos.

Dieses Howto zeigt nur eine kleine Auswahl der möglichen Automatismen des Editors vim, welche die tägliche Arbeit eines Admins erheblich erleichtern. Alle weiteren Howtos dieses Blogs werden als Kategorie Howtos samt eigenem Feed angeboten - falls ihr tiefer gehende Support- oder Service-Leistungen für GNU-Tools oder Linux allgemein sucht, seit ihr bei uns ebenfalls richtig.

Heutige Digitalkameras speichern zusätzlich zu den Bild-Daten noch weitere Meta-Daten im Exif-Standard - unter Anderem, wie die Kamera gedreht war, als das Bild aufgenommen wurde. Bild-Anzeige-Programme nutzen diese Informationen aber nur teilweise - einige drehen die Bilder in der Anzeige korrekt, andere nicht, so dass das Verhalten inkonsistent und für den Nutzer nicht vorhersehbar ist.

Dem Problem kann mit dem Programm exiftran begegnet werden: es dreht alle Bilder eines Verzeichnisses korrekt und löscht danach die entsprechende Exif-Information. Und es kann wirklich einfach für Massenverarbeitung genutzt werden:

# apt-get install exiftran
$ find -print0 | xargs -0 exifautotran

Bei anderen Distributionen heißt das Paket eventuell anders, Fedora z.B. liefert es als fbida aus.

Lighttpd ist ein Webserver mit einer schnell wachsenden Nutzerbasis. Dieses Howto zeigt, wie bei Lighttpd Redirects auf Basis der Spracheinstellung des Nutzers im Browser erstellt werden.

Während des Wechsels unserer Blog-Software auf Movable Type wurde die Entscheidung getroffen, die Begrüßungsseite je nach Sprache des besuchenden Browsers entweder auf deutsch oder auf englisch anzuzeigen. Da Movable Type statische HTML-Seiten generiert, sollte dabei kein Workaround mit z.B. cgi-Skripten zum Tragen kommen.

Als Webserver wird bei der Maschine Lighttpd genutzt. Lighttpd kann das mächtige Modul mod_magnet einbinden, das eine Lösung für Sprach-Problematik bietet: mod_magnet kann Lua-Skripte ausführen, die nahezu alle Aspekte der Behandlung einer Anfrage ändern können. Die Anfragen an http://blog.credativ.com/ werden mit dem folgenden Lua-Schnipsel entsprechend umgeschrieben:

lighty.env["uri.path"] = "/en/index.html"
lang = lighty.request['Accept-Language']
if (lang) then
        if (string.sub(lang,1,2) == 'de') then
                lighty.env["uri.path"] = "/de/index.html"
        end
end
lighty.env["physical.rel-path"] = lighty.env["uri.path"]
lighty.env["physical.path"] = lighty.env["physical.doc-root"] .. lighty.env["physical.rel-path"]

In der Lighttpd-Konfiguration muss mod_magnet angeschaltet sein. Damit alle Anfragen für "/" entsprechend bearbeitet werden, muss außerdem folgender Schnipsel in der Konfiguration auftauchen:

$HTTP["url"] =~ "^/$" {
	magnet.attract-physical-path-to = ( "/path/to/your/script.lua" )
}

mod_magnet cached dabei das kompilierte Skript und führt es im Kern von Lighttpd aus, es sollte also keinen nennenswerten Einfluss auf die Auslieferungszeit von Webseiten haben.

Schreibt einen Kommentar, wenn Ihr Fragen dazu habt. Für professionelle Unterstützung und Beratung bei Lighttpd auf Geschäftsebene stehen wir wie üblich auch mit unserem Open Source Support Center bereit.

Wie soeben bekannt wurde, hat die Khronos-Gruppe die Versionen 3.3 und 4.0 der 2D und 3D-API OpenGL veröffentlicht. Insbesondere die Version 4.0 ist unerwartet.

Nachdem OpenGL sich zwischen den Jahren 2004 und 2008 kaum bewegte, ja fast schon tot gesagt wurde und immer weiter hinter den Konkurrenten DirectX zurück fiel, konzentriert sich die dafür verantwortliche Khronos-Gruppe seit Mitte 2008 wieder verstärkt auf die Fortentwicklung der Spezifikation: 2008 wurde die Version 3.0 veröffentlicht, 2009 folgten 3.1 und 3.2. Für diese Tage war die Version 3.3 erwartet worden, doch wurde heute neben 3.3 auch die Version 4.0 der überraschten Öffentlichkeit präsentiert.

Laut der Khronos-Gruppe bietet OpenGL 4.0 eine API, um auch modernste Hardware zu unterstützen - dies positioniert die neue API indirekt als Konkurrent zu DirectX11, das bisher neueste Hardware besser ansprechen konnte als das auf etwas ältere Hardware ausgelegte OpenGL 3.x. Dies konnte im Sinne der Unterstützung eher mit DirectX10 verglichen werden kann. Auch weist die Pressemitteilung explizit darauf hin, dass dieses Release insbesondere auf die Ansprüche der Entwickler angepasst ist und eine einfachere Entwicklung von Programmen ermöglichen soll.

Die neue API kommt aber erst zum Tragen, wenn sie auch implementiert wird: AMD und NVIDIA werden beide in der Pressemitteilung zitiert mit den Worten, dass sie bald die neue API unterstützen werden. Da NVIDIA und ATI in ihren Treibern für Linux und Windows weitestgehend den gleichen OpenGL-Stack verwenden, wird die OpenGL-4.0-Unterstützung damit auch bald unter Linux Einzug halten. Länger dauern wird es aber bei freien Linux-Treiber von Grafikkarten: die freie OpenGL-Implementierung Mesa3D bietet bisher nicht mal eine erste OpenGL-3.x-Unterstützung. Doch auch hier bewegt sich viel: während in der Vergangenheit teilweise Monate nichts von dem Projekt zu hören war, gibt es mittlerweile monatlich neue Versionen und Bugfix-Releases.

Wir von credativ wünschen uns transparentere Prozesse bei der Khronos-Gruppe, begrüßen aber natürlich das neue Release - immerhin sind Support und Service rund um Open Source unser Tagesgeschäft, und OpenGL ist ein wichtiger Bestandteil der Open-Source-Welt.

In der Serie "PostgreSQL Optimizer Bits" werden Strategien und Besonderheiten des PostgreSQL Optimizers vorgestellt. Heute beschäftigt sich die Serie mit dem Feature Join Removal des Optimizers in der kommenden Version 9.0.

Nachdem im letzten Beitrag unserer Serie Semi und Anti Joins besprochen wurden, setzen wir uns heute mit Join Removal auseinander. Join Removal ist eine Optimierungsstrategie des Optimizers, die Tabellen der rechten Seite in LEFT JOINs aus der Join-Evaluierung ausschließen kann, wenn keine Spalten aus dieser Tabelle in der Ergebnismenge qualifiziert wurden und die rechte Seite des LEFT JOINs eindeutig ist, so dass hierdurch keine weiteren Tupel hinzukommen. Dies macht auch erforderlich, dass mindestens ein UNIQUE CONSTRAINT existiert, der beide Seiten entsprechend eindeutig qualifiziert wie gefordert.

Betrachten wir folgendes kleines Beispiel mit zwei Tabellen a und b, wobei b Detaildatensätze verknüpft mit a enthält.

EXPLAIN SELECT 
   a.name 
FROM 
   a LEFT JOIN b ON (b.id = a.id) 
WHERE 
   a.name LIKE 'M%';

Diese Query selektiert aus einem LEFT JOIN den Namen einer Person aus der Relation a. Man erkennt schnell, dass der LEFT JOIN auf die Relation b in diesem Fall nutzlos ist, wenn die verknüpften Felder a.id und b.id eindeutig sind. In diesem Fall würde auch bei Auftreten eines verknüpften Tupels kein weiteres Tupel erzeugt werden. In PostgreSQL 8.4 wird dennoch der Join ausformuliert:

Nested Loop Left Join  (cost=0.00..9.33 rows=1 width=6)
   ->  Seq Scan on a  (cost=0.00..1.05 rows=1 width=10)
         Filter: (name ~~ 'M%'::text)
   ->  Index Scan using b_pkey on b  (cost=0.00..8.27 rows=1 width=4)
         Index Cond: (b.id = a.id)

In PostgreSQL 9.0alpha4 hingegen wird der Join eliminiert: dadurch vereinfacht sich der Plan wie folgt:

Seq Scan on b  (cost=0.00..1.05 rows=1 width=11) (actual time=0.012..0.013 rows=1 loops=1)
   Filter: (name ~~ 'M%'::text)
 Total runtime: 0.045 ms

Der Optimizer kann an dieser Stelle nur die linke Seite berücksichtigen und daher die Relation b komplett aus dem Join eliminieren. Interessant wird diese Optimierungsmöglichkeit bei Verknüpfungen mit vielen LEFT JOINs (bspw. a LEFT JOIN b LEFT JOIN c LEFT JOIN d ...), wo mehrere Relationen aufgrund der Zusammensetzung der Abfrage aus dem Join entfernt werden können. Dadurch verbessern sich auch die Möglichkeiten des Optimizers, der weniger Tabellen bei der Optimierung der Verknüpfungspfade berücksichtigen muss. Auch für Views ist diese Optimierungsmöglichkeit interessant, da nicht qualifizierte Spalten aus der zugrundeliegenden Definition des Views eliminiert werden und daher implizit zu derartigen Abfragen führen können.

So weit zum aktuellen Artikel der Serie, der nächste wird bald folgen. Alle Blog-Artikel zum Thema PostgresQL werden auch als Kategorie PostgreSQL samt eigenem Feed angeboten - und falls ihr nach Support und Services für PostgreSQL sucht, seit ihr bei uns ebenfalls richtig.

Phoronix hat seine Test-Suite genutzt, um den Speicher- und Stromverbrauch verschiedener aktueller Desktops zu vergleichen. Die ermittelten Ergebnisse müssen aber differenziert betrachtet werden.

Der "Power & Memory Usage"-Test wurde durchgeführt, um zu ermitteln, ob LXDE und XFCE ressourcenschonender sind als Gnome und KDE. Dabei kam auf den ersten Blick heraus, dass KDE besonders viel Speicher und Strom verbraucht. Die Desktops wurden dazu in ihrer Standard-Installation auf Ubuntu getestet. Die Werte sind aber mit Vorsicht zu betrachten.

So ist zum Beispiel das Messen des Speicherverhaltens von Applikationen nicht-trivial, exakte Messungen erfordern eine Menge Aufwand. Hintergrund ist unter Anderem, dass viele Applikationen sich den Speicher teilen - gerade bei KDE wird das massiv genutzt. Nur die wenigsten Programme können diesen geteilten Speicherverbrauch sauber auseinander rechnen. "top" und "free" sind zum Beispiel wertlos unter diesen Gesichtspunkten, wenn überhaupt sollte bei so etwas eher "exmap" genutzt werden. Eine genaue Analyse mit Hintergründen findet sich hier.

Aber selbst wenn der Speicher korrekt gemessen wird, muss immer noch geprüft werden, was eigentlich den Speicher belegt: wenn ein Desktop wie Gnome oder KDE viel Speicher belegt beim Start, heißt das vor allen Dingen, dass sie umfangreiche Bilbiotheken laden, die eine Menge bieten - und von anderen Programmen genutzt werden können. Das führt zum Beispiel schnell dazu, dass beim Test einer Speicherauslastung mit mehreren Programmen eine Desktop-Umgebung kaum mehr Speicher braucht, während der Verbrauch anderer Umgebungen in die Höhe schnellt.

Doch selbst wenn diese Punkte berücksichtigt werden, muss beachtet werden, was die Desktops in dem Moment bereit stellen: KDE und auch Gnome werden in heutigen Versionen meist mit standardmäßig aktivierter Indizierung und Verschlagwortung von Dateien installiert, die zwischendurch mal anspringt, mal pausiert. Das kann Ergebnisse massiv verfälschen, wenn es nicht berücksichtigt wird. Auch sind meist Desktop-Effekte aktiviert - dass diese beiden Funktionen nicht ohne Einfluss auf den Verbrauch bleiben, versteht sich von selbst.

Ein Vergleich mit einem Desktop mit deutlich weniger Funktionen ist daher sinnfrei - sonst könnte man auch einen ausgeschalteten Rechner mit einbeziehen, der natürlich der Sieger wäre.

Die Zahlen des genannten Phoronix-Tests sind daher leider nicht zu gebrauchen.

Allgemein kann die Phoronix-Test-Suite bestimmt genutzt werden, um Daten zu ermitteln oder Trends zu erkennen. Das erfordert aber in jedem Fall klar definierte Rahmenbedingungen, eine detaillierte Auseinandersetzung mit den verglichenen Objekten und deren Fähigkeiten und eine wissenschaftliche Analyse der ermittelten Daten. Bei diesem Test fehlt das aber - leider.

Unser Blog wurde im Laufe der letzten Tage auf eine neue Software, Movable Type, umgestellt. Neben einigen technischen Vorteilen ermöglicht die neue Blog-Engine insbesondere eine bessere Ansicht der verschiedenen Sprachen.

credativ ist ein international agierendes Unternehmen mit Mitarbeitern verschiedener Nationalitäten. Dies zeigte sich insbesondere, als nach den ersten Experimenten mit einem Firmen-Blog sowohl Artikel in englisch als auch in deutsch eingetragen wurden. Als diese dann auch noch übersetzt wurden, wurde die Seite immer unübersichtlicher.

Um diesem Problem gerecht zu werden, wurde ein neuer Workflow entwickelt - der aber nur unzureichend von der zu dem Zeitpunkt genutzte Engine Wordpress umgesetzt werden konnte. Nach einer kurzen Evaluation wurde daher beschlossen, das intern ebenfalls gut bekannte Movable Type einzusetzen, das das Einrichten zweier Blog-Instanzen mit zentraler Verwaltung nebeneinander auf einer Domain und ohne große Konfiguration ermöglicht.

Für unsere Leser bedeutet dies, dass sich die Adresse des Blogs, blog.credativ.com erst mal nicht ändert. Es gibt aber jetzt eine Unterseite pro Sprache:

• blog.credativ.com/de für deutsche Artikel


• blog.credativ.com/en für englische Artikel

Durch die Unterverzeichnisse ergeben sich nun auch Themen-bezogene Feeds, die einsprachig sind - die lästigen Doppel-Einträge gehören damit der Vergangenheit an.

Wir wünschen allen Lesern viel Spaß auf der neuen Seite. :-)

Natürlich gilt wie immer: sollten Sie Support für Movable Type, Wordpress oder eine Migration brauchen, helfen wir Ihnen natürlich gerne!

Der Werkzeugkasten eines System-Administrators sollte immer mit effektiven Werkzeugen gefüllt sein. Heute stellen wir das Paket sysstat vor.

Das Paket sysstat ist eine Sammlung von Kommandozeilen-Programmen, die dem Systemadministrator einen schnellen Überblick über die Leistungsfähigkeit des Systems verschaffen. In ihrer Arbeitsweise sind sie ein Frontend zu den Daten des Linux-Kernels, und können dementsprechend nur Daten ausgeben, die der Kernel selbst kennt - sie sammeln keine Daten darüber hinaus!

iostat

iostat liefert vor allen Dingen Status-Informationen über den Datendurchsatz der Festplatten, angeschlossener NFS-Laufwerke und aller CPUs. Ist ein System im Leistungsverhalten auffällig, kann iostat verwendet werden, um z.B. IO-Waits zu identifizieren.

Linux 2.6.31-19-generic (mymachine)         04.03.2010      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          11,82    0,29    3,44    1,25    0,00   83,20

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               9,39       161,19       168,44    4264806    4456696

Die zur Verfügung stehenden Optionen sind dabei umfangreich, die Wichtigsten dienen vor allen Dingen der Feststellung für spezialisierte Ausgaben:

-d

Anzeige nur der Festplatten-Daten.

-c

Anzeige der reinen CPU-Daten.

-p

Anzeige der IO-Daten je Partition.

-n

Anzeige der NFS-IO-Daten.

-x

Erweiterte Anzeige der Festplatten-Daten.

-t $NUM1

Gibt an, nach wie vielen Sekunden die Anzeige aktualisiert werden soll.

mpstat

Das Werkzeug mpstat dient der genaueren Analyse der Prozessor-Auslastung - ohne weitere Option wird eine Standard-Übersicht gezeigt, die an die Ausgabe von iostat erinnert.

Linux 2.6.31-19-generic (mymachine)         04.03.2010      _x86_64_        (2 CPU)

17:01:52     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
17:01:52     all   11,96    0,29    3,26    1,23    0,10    0,11    0,00    0,00   83,06

Im Gegensatz zu iostat wird hier aber direkt schon die Arbeit mit aufgelistet, die der Prozessor an Soft- und Hardware-Interrupts verrichtet. Mit der Option -A wird die Ausgabe erweitert: die Statistiken werden pro Prozessor angezeigt, außerdem werden die Interrupts pro Sekunde pro Prozessor angezeigt.Eine Zahl $NUM hinter dem Befehl lässt diesen als Prozess laufen, und aktualisiert die Anzeige alle $NUM Sekunden.

pidstat

pidstat hilft bei der Analyse einzelner Prozesse - während der Aufruf ohne Optionen noch eine Liste aller Prozesse anzeigt, hilft die Option -C bei der Spezifizierung der zu untersuchenden Tasks:

Linux 2.6.31-19-generic (mymachine)         04.03.2010      _x86_64_        (2 CPU)

17:02:32          PID    %usr %system  %guest    %CPU   CPU  Command
17:02:32            1    0,00    0,00    0,00    0,00     1  init
17:02:32         2888    0,00    0,00    0,00    0,00     0  start_kdeinit
17:02:32         2889    0,00    0,00    0,00    0,00     0  kdeinit4

Mit der zusätzlichen Option -d werden I/O-Statistiken zu den Prozessen angezeigt. Mit -p kann die PID definiert werden statt des Prozess-Namens, -r verschafft einen Überblick über die Speicherauslastung. Eine Zahl $NUM hinter dem Befehl lässt diesen als Prozess laufen, und aktualisiert die Anzeige alle $NUM Sekunden.

sar

Die bisher vorgestellten Informationen geben jeweils nur einen Schnappschuss der Systemleistung wieder, echtes Status-Logging findet hier aber nicht statt. Dafür ist das Programm sar mit seinen Helfer-Programmen verantwortlich: es nimmt via Cron-Job alle 10 Minuten verschiedene Leistungsdaten des Systems auf, und sichert diese. Ein einfacher Aufruf gibt eine erste Idee des Performance-Verhaltens:

Linux 2.6.31-19-generic (mymachine)         04.03.2010      _x86_64_        (2 CPU)

09:30:30          LINUX RESTART

09:35:02        CPU     %user     %nice   %system   %iowait    %steal     %idle
09:45:01        all     17,38      1,02      5,10      3,87      0,00     72,63
09:55:01        all     11,90      0,27      2,86      0,75      0,00     84,23
10:05:01        all     10,20      3,52      3,46      2,55      0,00     80,27
10:15:02        all     12,96      0,32      3,18      0,65      0,00     82,89
10:25:01        all      7,94      0,18      3,17      2,42      0,00     86,30
10:35:01        all     12,41      0,89      4,55      0,56      0,00     81,60
10:45:02        all      8,97      0,09      3,51      0,89      0,00     86,55

Der Abruf aller Informationen mit sar -A sprengt aber leicht jede Bildschirmgröße. Die unterschiedlichen Einzel-Optionen sind zu zahlreich, um sie hier detailliert aufzulisten, einen Überblick gibt die Man-Page.

Ich schaue mir derzeit den Browser rekonq an, ein auf WebKit basierender KDE-Browser, der von Einigen als der zukünftige neue Standardbrowser für KDE gehandelt wird. Ob es dazu kommt oder nicht, sei dahin gestellt, der Browser lässt sich in der derzeitigen Version 0.4 Beta aber schon recht gut nutzen: Kwallet-Integration, Addblock, Plugin-Support, etc.

Problematisch ist aber im derzeitigen git-checkout der Umgang mit den Favoriten auf der about:favorites-Seite: diese können zwar gelöscht, aber nicht ohne weitere neu erstellt werden. Die Favoriten können aber auch mit einem Eintrag in der Datei $HOME/.kde/share/config/rekonqrc definiert werden: der Abschnitt "NewTabPage" definiert diese. Dabei werden sowohl die URLs wie auch die Kommentare unter den Vorschauen mit Kommata getrennt:

[NewTabPage]
previewNames=http://www.heise.de,http://www.spiegel.de,http://www.tagesschau.de,,,,,
previewUrls=heise.de,spiegel.de,tagesschau.de,,,,,

An solchen Stellen zeigt sich, dass rekonq immer noch diverse Probleme hat, und noch reifen muss. Er hat aber zur Zeit eine Menge Potential, sich einen festen Platz in KDE zu erarbeiten.

Die Red Hat Cluster Suite bietet ein Framework, in dessen Rahmen zwei oder mehr Rechner eine Aufgabe erledigen. Der folgende Artikel stellt die Grundlagen der Suite unter der Perspektive des Dienste-Failovers vor.

Der Einsatz von Linux in unternehmenskritischen Umgebungen gehört zu unserem Tagesgeschäft. Dementsprechend ist der Anspruch an die Verfügbarkeit von Linux-Servern und darauf aufsetzenden Diensten sehr hoch. Um eine Ausfallsicherheit bzw. ein Fallback zu gewährleisten, bietet sich unter Anderem der Einsatz der Red Hat Cluster Suite (RHCS) an: diese ermöglicht es, ein Cluster von Rechnern aufzusetzen, die alle die gleiche Arbeit erledigen, bzw. den gleichen Dienst vorhalten. Fällt der Rechner aus, auf dem der Dienst gerade aktiv ist, wird der Dienst auf einem anderen Rechner gestartet.

Zentrale Elemente des RHCS

RHCS besteht aus mehreren Schlüssel-Komponenten:

• Cluster-Infrastruktur
• Hochverfügbarkeits-Dienste-Management
• Werkzeuge für die Cluster-Administration
• Linux Virtual Server-Routing

Die Cluster-Infrastruktur beinhaltet all die Kernkomponenten, die für den Aufbau und den Betrieb eines Clusters bestehend aus mehreren Nodes notwendig sind. Diese Komponenten verwalten die Integration von Nodes, das Abschalten ausgefallener Nodes (Fencing), replizieren die Konfiguration und so weiter.

Wenn der Cluster konfiguriert wurde, ist der nächste Schritt das Einrichten des Hochverfügbarkeits-Dienste-Managements: wenn ein Cluster einen Dienst hoch-verfügbar anbieten soll, so läuft dieser aktiv auf einer Node. Fällt diese aus, gibt es einen Failover auf eine andere Node. Die Konfiguration dieses Failovers, also des entsprechenden Dienstes so wie dazugehöriger Skripte zum Starten, die Priorität der Failover-Nodes und die notwendigen Ressourcen werden im Hochverfügbarkeits-Dienste-Management definiert.

Die Cluster-Administrations-Werkzeuge sind weniger eine notwendige Kernkomponente, als vielmehr benutzerfreundliche Schnittstellen zu den oben genannten Arbeiten: GUIs, Web-Oberflächen und Programme zur Status-Verfolgung der Nodes.

Auch das Linux Virtual Server-Routing ist nicht zwingend für den Cluster-Betrieb, auch wenn die RHCS-Dokumentation es als Kernkomponente auflistet: es dient als Load-Balancer auf IP-Ebene, und leitet den Verkehr um, falls eine Node ausfällt.

Neben diesen RHCS-Komponenten kann das System auf weitere Dienste zurückgreifen, sofern sie vorhanden sind: ein globales Dateisystem wie GFS und ein Cluster Logical Volume Manager helfen beim Einbinden von Block-Devices via Netzwerk und vereinfachen so den Umgang mit Shared Storage.

Hardware eines RHCS-Clusters

Um einen RHCS-Cluster inital aufzubauen werden mehrere Maschinen benötigt:

1. Shared Storage wie z.B. iSCSI oder Fibre Channel.
2. Für jeden Node eine Methode, um diese vom Netz vollständig zu trennen (Fencing), z.B. eine via Netzwerk an/abschaltbare Steckdose
3. Mindestens zwei Nodes mit Netzwerkkarte.
4. Ein Switch.

Wichtig ist, dass das Shared Storage dabei nicht auf einer der Nodes läuft. Außerdem beschreibt die hier aufgelistete Konfiguration nur das absolut notwendige Minimum an Hardware-Konfiguration - bei einem größeren Cluster wären deutlich mehr Nodes denkbar.

Fazit

Die RHCS bietet ein gut durchdachtes Framework zum Management von Clustern, insbesondere in zur Bereitstellung von Dienste-Failovern. Mit einfachen Mitteln und Standard-Hardware kann so ein kritischer Teil der IT-Infrastruktur gesichert und hoch verfügbar gemacht werden.Zwar impliziert das R in RHCS, dass diese Methode vor allen Dingen auf Red-Hat-Maschinen läuft, dem ist aber nicht so - mehr dazu die nächsten Tage.