Bisher war es recht schwierig die ESX Server selbst zu inventarisieren. Natürlich konnte man den Agent in die Server-Umgebung installieren, aber mit Version 4.5 wird es diese nicht mehr geben, sondern nur noch den ESXi. Hier setzt nun fusioninventory-esx an. Dieses Tool verbindet sich über die API zum ESX-Server , holt sich dort die notwendigen Daten und schreibt eine .ocs-Datei, welche man mit dem FusinInventory-Injector in den OCS Server importieren kann:


fusioninventory-esx --host $HOSTNAME -u $BENUTZER --password $PASSWORD \ --directory /var/lib/fusioninventory-agent/
fusioninventory-injector -v -r -d /var/lib/fusioninventory-agent/ \ --url http://admin:admin@localhost/ocsinventory


Obiges sollte selbsterklärend sein. Interessantes Detail ist -r -d beim Injektor. Ersteres löscht erfolgreich importierte .ocs-Dateien und -d liest alle im angegeben Verzeichnis – eine schöne Erleichterung fürs Scripten.

Wer ein fertiges Paket für Redhat/Centos sucht wird beim Remi Repo fündig. Installation via yum –enablerepo=remi install perl-FusionInventory-Agent-Task-ESX – was will man mehr.

# tune2fs -O ^has_journal /dev/sysvg/root
# e2fsck -fn /dev/sysvg/root
# e2fsck -fy /dev/sysvg/root
# tune2fs -j /dev/sysvg/root
# mount -t ext3 /dev/sysvg/root /mnt/

Vom Ablauf her: man löscht erst das Journal, checkt dann das FS ohne Veränderungen. Wenn das OK ist lässt man die Änderungen durchlaufen, erstellt ein neues Journal und muss letztlich einmal das FS mounten. Der letzte Punkt ist wichtig, ohne ihn sind alle vorherigen Schritte nichtig und man darf von vorn beginnen.

n00b-Disclaimer: So etwas macht man nur aus einem Rettungs-System, wie z.B. grml oder dem Rescue-Mode von Redhat/CentOS, heraus. Die entsprechenden Dateisysteme dürfen nicht gemoutet sein.

• Fakenamegenerator
• Tabbed Console für Windows
• How to Convert RHEL 5 to CentOS 5
• SSHFS und globaler Namespace
• System Administrator Interview Cheat Sheet

Der Login-Dialog:

Verzeichnis-Übersicht:

Von dem was ich bis jetzt gesehen habe, ist das eine ausserordentliche gute Lösung, auch wenn es sich nicht (wie gehofft) mit einen ifolder-Server kombinieren läßt.

Schaut man über die Lebenszeit eines Systems, sind 3 Jahre eine verdammt kurze Zeit. Projektierung, Anschaffung, Test, Betrieb und das Ausphasen verschlingen doch etliche Zeit. Ist zu diesen Zeitpunkt die Distribution schon ein Jahr veröffentlicht verschlimmert sich die Sache sogar noch. Debian mit seinen bisherigen Lebenszyklen war daher für mich das erste Enterprise-Linux, auch wenn die Länge nicht immer geplant war, sondern sich durch Unzulänglichkeiten oder dem Erwachsenwerden der Organisation begründeten.

Man braucht also einen guten Kompromiss für den Lebenszyklus einer Distribution. Wenn 3 Jahre zu kurz sind, denke ich, kann man mit 5 Jahren gut leben. So hat man die Gewissheit auch noch mitten im Lebenszyklus einer Distribution nicht auf ein totes Pferd zu setzen. Diese lange Zeit stellt aber auch die Distribution vor Probleme, denn die Hardware ändert sich in dieser Zeitspanne dramatisch. Das war schon immer ein wunder Punkt von Debian, welches sich aber durch den Einsatz der Backports stark gebessert hat.

Wie es mit dem LTS von Ubuntu ausschaut wird sich auf Dauer zeigen. Im Moment sieht es so aus, das sie einen Haufen Software für Stabil erklärt haben und das für die nächsten 5 Jahre nicht ändern wollen. In Konsequenz bedeutet dieser Umstand schon heute, das Ubuntu Dapper LTS für langfristige Projekte Tod ist. Man stelle sich ein Projekt vor, das in ein, zwei Jahren erweitert werden muss. Die heutige Hardware ist nicht mehr lieferbar und installieren lässt sich Dapper LTS auch nicht mehr. Klar kann man nun zu Frickeln anfangen, aber das pflegen eigener Pakete kann ganz schön aufwändig sein.

Einen wirklich guten Kompromiss zwischen Lebenszyklus und Aktualität was Hardware-Treiber angeht liefert im Moment Redhat resp. CentOS. Selbst CentOS 4 kann man heute noch in Projekten ohne Bedenken einsetzen, da Redhat mit Version 4 bis ins Jahr 2012 plant. Neue Hardware trotz 2.6.9er-Kernel? Kein Problem!

Schaut man über den Tellerrand zu Solaris sieht die Situation noch besser aus. Nächstes Jahr fängt, nach über 10 Jahren, Solaris 8 an auszulaufen. Die Schmerzen die es hinterläßt sind aber erträglicher als die Schmerzen die ein Wechsel der Version unter Linux verursachen kann, besonders wenn man viel selbstgeschriebene oder gekaufte Software einsetzt. Bedeutet eine neue Version der Linux Distribution vielfach neue Software, kann man die alte unter Solaris dank der garantierten Binärkompatibilität weiter einsetzen. Das Solaris dafür an anderen Ecken stinkt macht die Wahl einer Umgebung nicht einfacher.

Beispiel Bind unter Redhat/CentOS: Man installiert bind mit yum install bind, man startet es mit service named start, die Konfiguration liegt in /var/named. Unter Debian liegt die Konfiguration, egal ob Bind8 oder Bind9 unter /etc/bind, man installiert mit apt-get install bind(9) und startet mit /etc/init.d/bind(9). Dieses /var/named erinnert mich immer an bind4-Zeiten *schauder*

Oder Apache: Das Debian Konstrukt mit sites-available und sites-enabled ist simpel und effektiv, bei Redhat gibt es soetwas nicht. Dort heisst der Apache-Prozess auch httpd und nicht apache(2) wie bei Debian. Genau das gleiche Spiel bei der Installation: yum install httpd gegen apt-get install apache(2). Alles voll krass logisch und durchdacht.

Ich könnte jetzt wieder über die Netzwerk-Konfiguration lästern, aber das möchte ich nicht nochmal wiederholen.

Dabei gibt es hierfür keinen Grund, denn in der IT wird auch nur mit Wasser gekocht und das beste Mittel gegen Ehrfurcht und Berührungsängste ist es immer noch sich damit auseinander zu setzen.

Wer also einen Einstieg haben möchte kann recht problemlos mit dem Redhat Cluster beginnen, welches es auch von CentOS gibt. Besondere Hardware ist nicht nötig, das folgende Beispiel, auf Basis von CentOS 4.6, läuft zum Beispiel in einem VMWare Server.

Los gehts

Zum Starten benötigt man also zwei CentOS 4.x Installationen in der Minimal-Installation. Zuerst muss man das CSGFS-Repository auf beiden hinzufügen:

root@zap:~# cat /etc/yum.repos.d/CentOS-csgfs.repo
[csgfs]
name=CentOS-4 - CSGFS
baseurl=http://mirror.centos.org/centos/$releasever/csgfs/$basearch/
gpgcheck=1
enabled=1

Nach einem yum check-update kann die benötigte Software installiert werden:

yum install rgmanager system-config-cluster ccsd magma magma-plugins cman cman-kernel dlm dlm-kernel fence gulm iddev

Bevor es nun ans Cluster selbst geht, muss die Namesauflösung stimmen. Am besten man trägt die IP-Adressen der Cluster-Knoten und deren Hostnamen in die /etc/hosts ein. Ist eine Cluster-IP im Einsatz auch diese mit Hostnamen eintragen.

Funktionsweise

Der Redhat 4 Cluster besteht im Prinzip aus drei Teilen:

• cman – Der Cluster-Manager. Macht via Heartbeat eine Überwachung, ob alle Knoten da sind
• fenced – Verhindert das eine Rescource mehrfach benutzt wird. Dazu später mehr
• rgmanager – Der Service-Manager. Verwaltet die Rescourcen im Cluster

Alle drei werden über die XML-Datei /etc/cluster/cluster.conf gesteuert, welche man mit dem GUI system-config-cluster erstellen kann. Mit ihm ist es möglich die Cluster-Nodes, das Fencing, Cluster-Resourcen und letztlich die Cluster-Services zu definieren. Zusätzlich verfügt es noch über recht einfache Möglichkeiten das laufende Cluster zu überwachen und zu steuern. Im Alltag ist es allerdings nicht immmer brauchbar, da es manchmal nicht-validierenden XML-Code erzeugt oder es nicht möglich ist einen Cluster-Schwenk damit zu initiieren.

Konfiguration

Startet man system-config-cluster zu erstenmal wird man darauf hingewiesen, das der Cluster noch keine Konfiguration hat und ob man nicht eine Neue erstellen möchte. Folgt man dem, landet man in einem Fenster zu Konfiguration des Cluster-Managers. Ist man Unerfahren reicht es einfach Ok zu klicken, für die Fortgeschrittenen der Hinweis, das es keine Quorum-Disk benötigt um einen Redhat-Cluster zu betreiben. Wer es unbedingt möchte findet hier eine Anleitung.

Nun kann man die Cluster-Knoten hinzufügen. Dazu genügt es auf Cluster Nodes zu klicken, dann unten rechts Add a Cluster Node und im folgenden Feld den Hostnamen des Knotens anzugeben. Angaben zum Quorum kann man sich sparen.

Bild 1

Fencing

Einer der Knackpunkte beim Redhat Cluster ist das Fencing. Ein leicht beschönigender Name wie ich finde, das Linux-HA Projekt nennt eine ähnliche Funktionalität treffender Stonith (Shot the other node in the head) und genau das macht auch das Fencing im Redhat Cluster: Es verhindert das sich ein oder mehrere Knoten um eine Rescource prügeln und damit Datensalat erzeugen. Dabei geht es mitunter rabiat zu, indem einfach der betreffende Knoten abgeschaltet wird.

Welche Fence Device Typen es gibt und wie man sie konfiguriert findet man hier . Dabei dürften die schaltbaren Powerleisten von APC und WTI, sowie das Abschalten per OpenIPMI die am einfachsten zu nutzenden Devices sein. Letzteres ist bei neueren Server-Systemen, wie z.B. Sun X4200, schon oft vorhanden. Für das Beispiel hier reicht das Manual Fencing, welches logischerweise nicht für den produktiven Einsatz gedacht ist.

Ist nun für jeden Cluster-Knoten ein Fence Device erstellt muss es den betreffenden Knoten zugeordnet werden. Dazu geht man auf den betreffenden Knoten und klickt Manage Fencing for this Node, dann Add a new Fence Level und wählt den Level aus. Klickt man Add a Fence to this Level öffnet sich ein Fenster mit einem Dropdown-Menü, aus dem man das Fence-Device auswählen kann. Wichtig: Man ordnet jedem Server sein eigenes Fence-Device zu. Alles andere führt zu Tod und Chaos.

Failover Domänen

Beim Erstellen einer Failover-Domäne gibt es nicht viel zu beachten, ausser man gibt ihr einen Namen und ordnet beide Knoten zu. Natürlich ist dieses Feature sehr viel mächtiger, denn das Redhat Cluster ermöglicht nicht nur zwei Knoten-Cluster, sondern quasi eine unbegrenzte Anzahl von Knoten. Die Failover-Domäne gibt in solchen Fällen vor wohin, also auf welche Knoten, ein Cluster Service wandern kann.

Rescourcen

Nun wird es langsam spannend, denn spätestens jetzt muss man sich Gedanken über die Dienste im Cluster und woher sie kommen Gedanken machen. Links sieht man, welche Möglichkeiten vorgegeben sind. Spannend sind sie sicherlich alle, wobei Script natürlich die mächtigste Option ist, weil man hier tun und lassen kann was man will. Einige haben auch implizierte Abhängigkeiten, wie z.B. der Typ Filesystem. Hierzu muss das Device an allen Knoten sichtbar sein, ob es sich dabei um eine SAN-LUN (Multipathing ist dabei kein Problem) handelt oder Shared-SCSI (benutzt jemand noch soetwas?!) ist dabei zweitranging. Um beim Beispiel zu bleiben nehmen wir mal das einfachste, die IP-Adresse und tragen dort die geplante Adresse ein.

Initialisieren des Clusters

Damit ist ein wichtiger Teil abgeschlossen, denn nun kann man diese Konfiguration abspeichern und die Cluster-Dienste starten:

service ccsd start
service fenced start
service rgmanager start

Dabei lohnt es sich das Syslog im Auge zu behalten, denn dieses ist sehr auskunftsfreudig und zudem gut lesbar:

clnode1 kernel: CMAN 2.6.9-50.2.0.6 (built Nov  3 2007 07:57:09) installed
clnode1 kernel: NET: Registered protocol family 30
clnode1 kernel: DLM 2.6.9-46.16.0.12 (built Nov 13 2007 07:54:37) installed
clnode1 kernel: CMAN: Waiting to join or form a Linux-cluster
clnode1 kernel: CMAN: forming a new cluster
clnode1 kernel: CMAN: quorum regained, resuming activity
clnode1 ccsd[2809]: Cluster is quorate.  Allowing connections.
clnode1 cman: startup succeeded
clnode1 lock_gulmd: no <gulm> section detected in /etc/cluster/cluster.conf succeeded
clnode1 fenced: startup succeeded
clnode1 clurgmgrd[3157]: <notice> Resource Group Manager Starting
clnode1 clurgmgrd[3157]: <info> Loading Service Data
clnode1 clurgmgrd[3157]: <info> Services Initialized
clnode1 clurgmgrd[3157]: <info> Logged in SG "usrm::manager"
clnode1 clurgmgrd[3157]: <info> Magma Event: Membership Change
clnode1 clurgmgrd[3157]: <info> State change: Local UP
clnode1 rgmanager: Starten von clurgmgrd succeeded
clnode1 clurgmgrd[3157]: <notice> Starting stopped service web
clnode1 clurgmgrd: [3157]: <info> Adding IPv4 address 192.168.0.200 to eth0
clnode1 clurgmgrd[3157]: <notice> Service web started

Damit funktioniert der erste Cluster-Knoten. Nun noch die /etc/cluster/cluster.conf auf den anderen Knoten kopieren und die Dienste starten. Im Syslog sieht man es so:

clnode1 clurgmgrd[3157]: <info> Magma Event: Membership Change
clnode1 clurgmgrd[3157]: <info> State change: clnode2 UP

Startet man nun system-config-cluster sieht man einen zweiten Reiter (siehe Bild 1) für das Cluster Management. Änderungen an der Cluster Konfiguration sind nun über den Send to Cluster Button oben rechts möglich.

Cluster Services

Nun fügt sich alles zusammen, denn aus den Einzelteilen der Resourcen kann man sich einen Cluster Service zusammenbauen. Dazu klickt man auf Create a Service und gibt ihn einen Namen. Dann den Service-Namen auswählen, dann Edit Service Properties und man landet im Service Management (Bild 2).

Bild 2

Rechts oben die Failover-Domäne für diesen Dienst auswählen und darunter, wenn man möchte, die Recovery Policy. Im unteren Drittel geht es nun um die Rescourcen. Die erste Reihe entspricht der bereits bekannten Resourcen Konfiguration. Man könnte sich hiermit seine Dienste zusammenstellen, sie hätten aber keinerlei Abhängigkeiten zueinander. Die Dienste würden in loser Reihenfolge gestartet werden und bei Problemen könnte es ein ziemliches Durcheinander geben. In Bild 2 sieht man einen Cluster Dienst mit Abhängigkeiten. Zuerst die IP-Adresse, dann das File System und dann der Apache-Server. Erreicht wird dies durch klicken von Add a Shared Rescource to this Service und der Auswahl der Rescource im folgenden Fenster. Anschließend wählt man diese Rescource aus und klickt auf Attach a Shared Recource to this Selection. Genauso verfährt man beim letzten Service.

Unser Beispiel beschränkt sich ja nur auf eine IP-Adresse, also einmal Add a Shared Rescource to this Service, auswählen – fertig. Nach dem Abschicken der Konfiguration mit Send to Cluster sieht man im Cluster Management den Dienst starten. Fertig ist der Cluster Dienst (siehe Bild 3)

Bild 3

Cluster Management

Nun läuft er also. Allerdings sind die Informationen in system-config-cluster etwas dürftig und Scripten für eine Überwachung lässt es sich auch nicht. Da hilft zum einen clustat:

[root@clnode1 ~]# clustat
Member Status: Quorate

  Member Name                              Status
  ------ ----                              ------
  clnode1                                  Online, Local, rgmanager
  clnode2                                  Online, rgmanager

  Service Name         Owner (Last)                   State
  ------- ----         ----- ------                   -----
  web                  clnode1                        started

Zum anderen gibt es clusvcadm, welches den Cluster Management Teil der GUI beherrscht und auch den Cluster-Schwenk auf den zweiten Node:

clusvcadm -r web -m clnode2

Und die IP-Adresse? Tja, die sieht man nicht mit ifconfig, dafür benötigt es ip addr list.

Links

Zum Abschluß noch zwei weiterführende Links:

Red Hat Cluster Suite: Configuring and Managing a Cluster
Redhat FAQ

[root@zapbrannigan ~]# system-config-cluster
Traceback (most recent call last):
  File "/usr/sbin/system-config-cluster", line 52, in ?
    from ConfigTab import ConfigTab
  File "/usr/share/system-config-cluster/ConfigTab.py", line 27, in ?
    from ConfigTabController import ConfigTabController
  File "/usr/share/system-config-cluster/ConfigTabController.py", line 35, in ?
    from FaildomController import FaildomController
  File "/usr/share/system-config-cluster/FaildomController.py", line 213
    if val == "Yes" or val == "yes" or val="1":
                                          ^
SyntaxError: invalid syntax

Dafür gibt es natürlich auch einen Bug-Report. Am besten finde ich die letzte Zeile:

Looking for qa ack…please.

Die spannende Frage ist doch: wo war die Qualitäts-Sicherung vor Auslieferung des kaputten Programmes?

1. Man benötigt grundsätzlich eine Subscription, um irgendetwas von Redhat zu bekommen, seien es Sicherheitsupdates oder Hilfe bei Problemen. Wenn man eine hat, ist es gleichgültig ob man RHEL4 oder RHEL5 betreibt.
• Basic – Zugriff auf Patche, Upgrades und Websupport. Reaktionszeit: 2 Werktage
• Standard – Zugriff auf Patche, Upgrades, Telefon- und Websupport (12×5). Reaktionszeit: Je nach Schwere von 1 bis 4 Stunden
• Premium – Zugriff auf Patche, Upgrades, Telefon- und Websupport (24×7). Reaktionszeit: Je nach Schwere von 1 bis 4 Stunden

Die Supportform Basic ist nicht für die RHEL5 Advanced-Platform erhältlich.

2. Mit Socket oder Sockeln sind wirklich Prozessor-Sockel gemeint (ob bestückt oder nicht ist egal). Cores (Dual- oder Quadcores werden nicht mitgezählt
3. Bei der RHEL5 Advanced Platform sind Cluster-Manager und GFS ClusterFS enthalten

Die Preise findet man im Redhat-Shop.