Login
Login-Name Passwort


 
Newsletter
Werbung

So, 21. Juni 2009, 00:00

High Availability Computer Center (hacc-) - Update, Teil 2

Teil 2: Steuerknoten und Arbeitsknoten

Weiter mit den Steuerknoten

Der erste Boot des Arbeitsknotens, dessen Image erstellt wurde, kann nun theoretisch erfolgen. Es fehlt noch:

  • das Einrichten von DHCP für das Übermitteln der Boot-Parameter
  • das Einrichten der PXE-Boot-Records
  • TFTP für das Übermitteln von Kernel und Initrd
  • Werkzeuge für das Management (das Schalten der Knoten, ...)

Angestoßen werden soll der Boot über die Steuerknoten, die sich gegenseitig ersetzen sollen. Deshalb werden alle folgenden Aktionen für die Steuerknoten an beiden Steuerknoten gemeinsam ausgeführt.

Über den Nutzer Nagios erfolgt das Management der Knoten. Deshalb ist es sinnvoll, den Nutzer nagios von Hand anzulegen und ihm überall die gleiche UID zuzuordnen (später auch auf den Arbeitsknoten). Diesem Nutzer die bash zuzuordnen, erscheint außerdem sinnvoll, ebenso wie die Einrichtung eines Home-Directorys (siehe Liste: Nutzer nagios). Zum einen wird ein Home-Directory für das Ablegen der SSH-Keys benötigt. Zum anderen sollen unter diesem Nutzer normale Kommandos möglich sein, beispielsweise für den Test. Ansonsten würde der Nutzer nagios bei der Installation von Nagios automatisch angelegt werden, ohne Home-Directory und ohne Bash-Shell.

Liste: Nutzer nagios

# groupadd -g 9000 nagios
# useradd -u 9000 -g nagios -d /var/spool/nagios -c 'Nagios-Admin' -s /bin/bash nagios
# mkdir /var/spool/nagios && chown nagios: /var/spool/nagios
# passwd nagios
...
# su - nagios
> mkdir .ssh
> cd .ssh
> ssh-keygen -t das
...
> scp id_dsa.pub hac2-cn1:.ssh/authorized_keys
...

Dann können die Pakete nagios2, dnsmasq, dhcpd3-server und syslinux sowie alle abhängigen Pakete installiert werden.

Über den Nutzer nagios soll das Management der Arbeitsknoten gesteuert werden. Deshalb muss dieser Nutzer Eigentümer des Verzeichnisses /data/vol_root/hac2_root werden, weil über diesen Nutzer in diesem Verzeichnis die Links für den Boot und die PXE-Boot-Records geschrieben werden.

Folgende Kommandokette ist als Nutzer nagios abzuarbeiten:

cd /data/vol_root/hac2_root && mkdir tftpdir && mkdir \
tftpdir/pxelinux.cfg && mkdir XXX

Desweiteren soll der Nagios-User auch die Steuerknoten selbst stoppen und neu booten sowie auf die anderen Knoten zugreifen können. Der Zugriff soll per SSH erfolgen. Sinnvoll ist es, dafür die Keys zu generieren und an den jeweils anderen Steuerknoten zu bringen (und später auch auf die Arbeitsknoten, Siehe Liste: Nutzer nagios). Per visudo wird dem Nutzer nagios init 6 und init 0 erlaubt:

User_Alias NAGIOS = nagios
Cmnd_Alias REBOOT = /sbin/init 6
Cmnd_Alias HALT = /sbin/init 0
NAGIOS ALL=(ALL) NOPASSWD: REBOOT
NAGIOS ALL=(ALL) NOPASSWD: HALT

Dann erfolgt das Erstellen der Definitionen für dnsmasq. Dazu werden folgende Anpassungen vorgenommen:

/etc/dnsmasq.conf

domain-needed
bogus-priv
interface=lo
interface=eth0
interface=bond0
no-dhcp-interface=bond0
expand-hosts
domain=dresden.de
server=<DNS Server>
enable-tftp
tftp-root=/data/vol_root/tftpdir
log-queries
log-dhcp

Die Arbeitsknoten sollen dann später auf das mit dnsmasq auf den Steuerknoten angelegte DNS zugreifen.

Die Datei /etc/hosts sollte die Definition des gesamten hacc-Netzes enthalten, die Adressen der Switches und vor allem die externen Adressen.

Dnsmasq selbst liefert auch den TFTP-Dienst für das Booten. Ich habe es nur nicht dazu überlisten können, auch DHCP zu liefern. Deshalb habe ich dafür auf das entsprechende Paket dhcp3-server zurück gegriffen.

Konfiguration des neuen hacc- mit Python

Es wurden einige, in Python geschriebene Hilfsmittel erstellt, die zur Kommunikation mit dem Management Blade dienen und den physischen Zustand der Knoten testen und schalten.

Das Script /usr/local/bin/hac2.py definiert die logischen und physischen Knoten. Unter einem logischen Knoten versteht man dabei ein abarbeitungsfähiges NFS-Image. Ein physischer Knoten ist ein Blade-Server.

Die Python-Skripte sind weitgehend selbsterklärend (siehe Kasten Doc-Beispiel). Trotzdem sollen an entsprechender Stelle Erläuterungen eingebaut werden.

Doc-Beispiel

/usr/local/bin# /usr/bin/python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
&#91;GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)&#93; on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import hac2
>>> help(hac2)
Help on module hac2:
NAME
 hac2
FILE
 /usr/local/bin/hac2.py
DESCRIPTION
 Beschreibung der Konstanten von hac2
 Bei Abarbeitung:
 Ueberpruefen der Korrektheit der Definitionen
 und
 Anlegen von Files hosts.txt und dhcpd.txt im aktuellen Verzeichnis.
 dhcpd.txt als Ersatz fuer: /etc/dhcp3/dhcpd.conf
 hosts.txt als Ergaenzung fuer: /etc/hosts
DATA
...
<ctrl>d
/usr/local/bin# epydoc --pdf --output /root/Test/ MBCmd.py
-> Dokumentation in /root/Test

Auf den Management-Blades der beiden BX600-S3 wurde der Nutzer nagios als normaler Nutzer mit den folgenden Rechten angelegt:

  • alle Blades auswählen
  • System Administrator

Mit dem Skript /usr/local/bin/MBCmd.py kann die Funktionsfähigkeit des Schaltens der Blade-Server getestet werden. Doch zunächst wird das Gesamtsystem definiert. Das erfolgt mit dem Skript /usr/local/bin/hac2.py.

Die einzelnen Bestandteile (siehe Skript /usr/local/bin/hac2.py) des hacc werden mit Hilfe von Python-Konstanten definiert. Die Konstanten mb1 und mb2 beschreiben die Steuer-Blades der beiden BX600-S3 Systeme. Mit ihnen werden die einzelnen Blade-Server geschaltet, aber auch überwacht.

Die Konstanten n_... beschreiben die einzelnen physischen Knoten. Die angegebene IP-Adresse wird für das interne Interface beim Booten benutzt. Der Eintrag blade bezeichnet den Namen des Blade-Servers im Management-Blade der BX600-S3.

Alle Blade-Server werden zusammengefasst als nodes (alle Blade-Server), pxenodes (alle per PXE bootbaren Blade-Server) und us_nodes_mb{1/2} (jeweils alle PXE Blade-Server jeder BX600). Mit cn0 und cn1 werden die Steuerknoten definiert, die nicht per PXE gebootet werden und mit der Konstanten control zusammengefasst werden.

Die Images werden ebenfalls einzeln definiert und unter der Konstanten images zusammengefasst.

Im Hauptteil (__main__) werden die Definitionen syntaktisch geprüft. Weiterhin wird jeder Knoten bei Abarbeitung des __main__-Teiles per Mamagement-Blade-Kommando geprüft. Das Ergebnis wird auf die Standard-Ausgabe ausgegeben.

Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung