NIM, ein Tool zur Installation von Software, birgt einen unerwarteten Schatz:

Backup und Recovery mit NIM

Ein vielfach unterschätztes Werkzeug, das im Umfeld von IBM AIX-Servern zum Backup eingesetzt werden kann, ist das Network Installation Management (NIM). NIM ist ein Server-Client-basiertes Tool. Es dient der Installation von Software-Quellen auf AIX-Systemen. Diese Quellen können zum einen aus den bekannten AIX-Software-Paketen gebildet werden und Updates, wie Technologie-Level und Service Packs, beinhalten. Zum anderen können die Quellen aber auch aus System-Backups (mksysb) oder vollständigen, installierbaren LPP-Sourcen bestehen. Mit ihnen ist es möglich, ein System komplett neu aufzubauen oder wiederherzustellen.

Die NIM-Architektur

NIM-Operationen können zentral vom Master aus angestoßen (Push-Modus mit dem Befehl nim) oder vom einzelnen Client aus angefordert werden (Pull-Modus mit dem Befehl nimclient). Der Benutzer root des Client- Systems kann somit auch ohne administrativen Zugriff auf den NIM-Master Software-Installationen auf dem eigenen System auslösen.

Die NIM-Landschaft besteht mindestens aus einem Master und einem Client. Die NIM-Umgebung definiert sich über das Netzwerk, in dem sich die verwalteten Maschinen befinden. Ein physisches Netzwerk kann allerdings von mehreren NIM-Umgebungen verwendet werden, ebenso wie ein NIM-Master mehrere Netzwerke bedienen kann, sofern eine Route zu ihnen existiert. Eine spezifische Maschine ist jedoch immer nur Mitglied einer NIM-Umgebung.

NIM-Klassen

Die einzelnen Bestandteile von NIM werden innerhalb einer objektorientierten Technologie verwaltet und wie viele andere Konfigurationsdaten von AIX in der ODM abgelegt. Die NIM-Objekte unterteilen sich in vier Klassen:

• Maschinen
• Netzwerke
• Ressourcen
• Gruppen

In der Klasse der Maschinen sind die Objekte Master und Standalone interessant. Während das Objekt Master selbsterklärend ist, repräsentiert Standalone die Objekte der NIM-Clients als Rechner, die über eigene Speichersysteme verfügen und ein Betriebssystem hochfahren können.

Das einzelne Objekt dieser Klasse ist der NIM-Client mit seinen Eigenschaften wie Hostname, Typ, Kommunikationsweg, CPUID und verschiedenen Zustandsdaten. In der Klasse der Netzwerke werden diese nach ihrer physischen Ausprägung als Ethernet, Token Ring oder anderen unterschieden. Als Eigenschaften dieses Objektes gelten die Netzadresse, die Netzmaske und Gateways in das betreffende Netz. In der Klasse der Gruppen können Maschinen oder Ressourcen zusammengefasst werden.

NIM-Ressourcen

Die wichtigste Klasse ist die der Ressourcen, da sie die Gesamtheit der installierbaren Software, Hilfsmittel und Steuerungsskripte enthält.

Ein zentrales Objekt ist das der LPP-Sourcen. Eine LPP-Source ist ein Depot von AIXFilesets, z. B. den Installations-Filesets im backup file format (bff), die beispielsweise aus dem Inhalt einer AIX-Installations-DVD gebildet werden können. Natürlich kann Software weggelassen (Sprachunterstützungen etc.) oder hinzugefügt (weitere Treiber) werden. Diese Software kann ein System komplett installieren und besitzt somit das simages-Flag.

Mit den zur Aktualisierung des Betriebssystemstands bei IBM herunterladbaren Technologie-Leveln und Service Packs werden zwar auch LPP-Sourcen gebildet, sie besitzen jedoch nicht das simages-Flag. Insofern ist es mit ihnen nicht möglich, ein System neu aufzusetzen.

Besitzt eine LPP-Source das simages-Flag, wird aus ihr eine nächste Ressourcenart, der SPOT, gebildet. Dieser "shared object product tree" ist vereinfacht ausgedrückt ein /usr- Dateisystem. Bei der Betriebsysteminstallation wird es per NFS bereitgestellt und auf dem Client eingehängt. Daraus bedient er sich der benötigten Programme, Treiber, Libraries und Skripte. Bei der Bildung eines SPOT werden die bff-Dateien aus der LPP-Source in das /usr-Verzeichnis des SPOT installiert. Der SPOT hat dadurch die Eigenschaft, dass er einem Betriebssystemstand entspricht. Dieser kann aber jederzeit durch Einspielen von Technologie-Leveln und Service Packs aktualisiert werden.

Wird ein System gemeinsam mit SPOT und LPP-Source neu installiert, muss der SPOT eine mindestens ebenso hohe Version aufweisen, wie die dazugehörigen LPP-Sourcen. Allgemeiner gilt auch, dass der Software-Stand des Betriebsystems des NIM-Masters höher oder gleich der von ihm verwalteten Ressourcen sein muss.

Das mksysb als Backup-Medium

Um nun der Funktion eines Backup-Servers näher zu kommen, gibt es die Ressource mksysb. In ihr sind die rootvg-Backups einzelner Clients zusammengefasst, die mit dem Befehl mksysb angelegt wurden. Da es sich um mksysb auf einem nicht startbaren Medium handelt, besitzen sie kein Boot Image.

Als ersten Schritt in einem Backup-Konzept gilt es nun, regelmäßig ein mksysb eines NIM-Clients zu erstellen und auf dem NIMServer zu speichern. Dies kann natürlich vom NIM-Master aus gesteuert geschehen, z. B. per NFS. In einem Kundenprojekt wurde hierzu der nicht-berechtigte Benutzer nimadm auf den Master und alle Clients verteilt. Dieser ruft über sudo das Backup-Skript auf, in dem das Backup-Verzeichnis des NIM-Master per NFS eingehängt wird, ein neues mksysb geschrieben und bei Erfolg das alte gelöscht wird. Eine entsprechende Protokollierung und Benachrichtigung beendet das Skript.

nim -o define -t mksysb -a server=master -a location=/export/
images/mksysb_testclient -a source=testclient -a mk_image=yes
mksysb_testclient

...
CONSOLE = /dev/lft0
INSTALL_METHOD = overwrite
PROMPT = no
BOSINST_LANG = en_US
CULTURAL_CONVENTION = en_US
MESSAGES = en_US
KEYBOARD = en_US
HDISKNAME = hdisk0
...

/export/aix53/lppsource

/export/aix53/spot

/export/images

/tftpboot

nim -o bos_inst -t mksysb -a source=master -a spot=Spotname
-a lppsource=Lppsourcename
    -a mksysb=mksysbname -a bosinst_data=bosinst_dataname -a
accept_licenses=yes
    -a no_nim_client=no -a set_bootlist=no
    Clientname

Die mksysb-Datei ist jetzt aber noch kein NIM-Objekt. Um zu vermeiden, aus jeder Datei ein neues Objekt anzulegen, wird an dieser Stelle mit symbolischen Links gearbeitet. Der Link wird als Ressource definiert und verweist auf die jeweils zu verwendende mksysb-Datei. Eine mksysb-Ressource kann auch direkt auf dem NIM-Server definiert werden (siehe Abbildung 1).

Smitty ausdrücklich erlaubt

Eine mksysb-Datei mit dem Namen mksysb_testclient würde damit unter dem Verzeichnis /export/images vom Client testclient gezogen und unter dem Namen mksysb_testclient als Ressource definiert werden. Hier wird ein Grundmuster von NIM deutlich, Objekte unter einem Namen (und nie direkt) anzusprechen. Aufgrund der allgemein sehr langen Kommandos kann auch der Smitty benutzt werden. Mit smitty nim ⇨ Perform NIM administration Tasks ⇨ Manage Resources ⇨ Define a resource: "mksysb" (smitty fast path: smitty nim_mkres ⇨ mksysb) wird die Eingabemaske für die Parameter erreicht.

bosinst_data ist eine weitere NIM-Ressource. Sie ist eine Konfigurationsdatei, die bei der Installation des Basisbetriebssystems benutzt werden kann. Ein Template für diese Datei ist auf jedem Server vorhanden. Die Minimalausstattung für eine nichtinteraktive Installation von Software zeigt Abbildung 2.

Die hier verwendeten Steueranweisungen besagen: löse eine Neuinstallation aus (überschreibe), frage nicht nach (kein Prompt) und installiere die Software auf hdisk0. Natürlich gibt es noch weitere NIM-Ressourcen, die aber nicht notwendig für das weitere Verständnis sind.

Vorraussetzungen auf dem NIM-Master

Zum Aufbau des NIM-Masters wird das Paket bos.sysmgt.nim.master auf dem ausgesuchten System installiert. Die Vorraussetzungen sind genügend Speicherplatz und eine gute Netzwerkanbindung. Die Software- Quellen benötigen pro unterstützter AIX-Version in der Regel zwar nicht mehr als 12 GB. Sollen aber die Backups der Clients gesichert werden, so ist pro Client mit weiteren 5 GB zu rechnen. Für die Speicherorte (hier für das Beispiel AIX 5.3) sind eigene, logische Datenträger anzulegen (siehe Abbildung 3).

Für jede Plattform gibt es eigene Boot Images, die im Schnitt 10 - 12 MB groß sind. Da sie ansonsten in "/" aufbewahrt würden, gibt es für sie einen eigenen logischen Datenträger.

Sind die Laufwerke eingerichtet, kann der NIM-Server mit nimconfig initialisiert und erste Software-Quellen als NIM-Objekte eingerichtet werden. Aufgrund des singulären Charakters kann dies auch über den Smitty geschehen (smitty nimconfig bzw. smitty nim_mkres_inst). Hier müssen die AIX-Installationsmedien griffbereit liegen.

Ist der Master mit LPP-Source und SPOT ausgestattet, wird noch die Definition eines Netzwerks (smitty nim_mknet) und der Clients (smitty nim_mkmac) benötigt. Anhand der Definitionen des Clients wird später entschieden, welcher Kernel beim Hochfahren über das Netzwerk Verwendung findet.

Vorraussetzungen auf den NIM-Clients

Um vom NIM-Master eine Operation auf dem Client auslösen zu können, muss dieser in die Umgebung integriert und das Paket bos.sysmgt.nim.client installiert sein. Das Client-Paket muss in der Version gleich oder niedriger als das Master-Paket sein. Mit niminit -a name=Clientname -a master=Mastername -a platform=chrp -a pif_name =en0 -a connect=nimsh (oder smitty niminit) wird der Client in der Datei /etc/niminfo konfiguriert und beim Master angemeldet. Dieser Schritt entfällt, wenn der Server über NIM komplett neu installiert wird.

Ab diesem Zeitpunkt sind Push- oder Pull-Operationen möglich. Die Kommunikation läuft hierbei über den NIM-Service Handler (nimsh), der eine "leichte" Verschlüsselung und Authentifizierung über System-IDs bietet. Ansonsten bleiben als Alternativen, entweder das unsichere Protokoll rsh zu benutzen oder nimsh in Kerberos einzubinden.

Ablauf einer Rücksicherung

Alle Zutaten zu einer Rücksicherung sind nun vorhanden: ein NIM-Master mit den bereitliegenden Backups, Ressourcen und Definitionen. Was muss im Fall einer Rücksicherung getan werden? Wir setzen voraus, dass das System nicht mehr starttbar ist, die Platten aus der rootvg defekt waren und ausgetauscht wurden. Zuerst gilt es, die vorhandenen Ressourcen dem Client zur Verfügung zu stellen (zu "allokieren"). Den recht komplexen Befehl hierfür zeigt Abbildung 4.

Mit smitty nim_bosinst:"mksysb" wird innerhalb des Managementwerkzeugs die Eingabemaske für alle Parameter erreicht. Damit werden die Ressourcen zur Benutzung durch den Client freigeschaltet und die entsprechenden NFS-Freigaben eingerichtet. Im Verzeichnis /tftpboot wird der entsprechende Boot Kernel bereitgelegt und der bootp-Daemon so konfiguriert, dass er den Kernel bei Anfrage durch den Client über das tftp-Protokoll überträgt.

Der Client muss jetzt nur noch diesen Request aussenden. Im Fall einer laufenden Maschine würde einfach die Boot-Liste mit dem Befehl bootlist zum Hochfahren über Netzwerk konfiguriert und ein Reboot ausgeführt. Das System ist aber nach dem Ausfall nicht erreichbar. Wir benötigen einen Zugang zur Systemkonsole.

Das Client-System wird in das SMS-Menü gebootet. Im RIPL-Menü werden, falls nicht schon vorhanden, die Netzwerkparameter, die eigene IP-Adresse, die NIM-Master-IP, die Netzwerkmaske und das Gateway eingetragen. Im SMS werden unter Punkt 5 das Boot Device und das Netzwerk ausgewählt.

Der NIM-Client schickt anschließend einen Boot Request zum NIM-Master, der mit Rücksendung eines Kernels beantwortet wird. Der Kernel startet und hängt über NFS den SPOT nach /usr. Die Prozesse zur Neueinrichtung der rootvg und das Zurückspielen des Backup beginnen. Nach dem abschließenden Reboot steht der Client wieder zur Verfügung.

Diese Prozedur kann nicht nur zur Rücksicherung von NIM-Clients benutzt werden, sondern auch zum Klonen. Eine aufwändige Konfiguration des Clients wird hier vereinfacht.

Weitere Möglichkeiten des Backups

Eine weitere, sehr bequeme Backup-Methode stellt der Befehl alt_disk_install (seit AIX 5.3 alt_disk_copy) dar, der im Paket bos.alt_disk_install.rte enthalten ist. Hierzu wird die doppelte Anzahl der vorhandenen Boot-Platten benötigt. Liegt die rootvg auf hdisk0 und hdisk1 und hat die freien Platten hdisk2 und hdisk3 zur Verfügung, lässt sich die rootvg mit dem Befehl alt_disk_install -C -B -n hdisk2 hdisk3 online auf diese Platten klonen. Die Option -C erstellt den Klon, -B verhindert die automatische Umsetzung der Boot-Liste und -n belässt das "neue" System als NIM-Client.

Während des Kopiervorgangs ist diese Datenträgergruppe namens altinst_rootvg mit ihren Dateisystemen online, wird danach aber geschlossen. Der Befehl bootlist -m normal hdisk2 hdisk3 und ein anschließender Reboot können diese Platten als rootvg aktivieren. Die alte rootvg steht dann noch unter dem Namen old_rootvg (offline) zur Verfügung, kann allerdings auch wieder aktiviert werden. Ein Backup-Konzept auf diese Art und Weise umschließt demnach eine regelmäßige Löschung der altinst_rootvg (alt_disk_install -X) mit anschließender Neuerstellung auf nächtlicher oder wöchentlicher Basis. Der Vorteil ist, dass das Betriebsystem nach dem Reboot sofort zur Verfügung steht und nicht zeitaufwändig restauriert werden muss.

Vereinfachung von Betriebssystemmigrationen und -updates

Eine Verbindung der Technologien von NIM und alt_inst_install bietet der Befehl nimadm (NIM Alternate Disk Manager). Während alt_disk_install dafür sorgt, dass die Daten von der rootvg auf die altinst_rootvg transferiert werden, kann NIM gleichzeitig die Software aktualisieren, d. h. ein Update oder eine Migration durchführen. Das System bleibt dabei online. Die aktualisierte altinst_rootvg kann dann zu einem späteren Zeitpunkt hochgefahren werden. Das Altsystem steht danach noch als Fallback zur Verfügung.

Die Downtime wird so auf die Dauer des Reboot minimiert. Das sind bei den Partitionen auf POWER5/6-Systemen nur noch wenige Minuten. Im Falle einer gespiegelten rootvg ist dabei nicht das Vorhandensein von 4 Platten notwendig. Da IBM noch immer keine Migrationen von gespiegelten rootvgs unterstützt, kann der Spiegel aufgebrochen und die freiwerdende Platte als altinst_rootvg benutzt werden. Voraussetzung für den Aufbau einer alternativen rootvg ist jedoch, dass der Client in eine funktionsfähige NIM-Umgebung eingebunden ist.

Fazit

IBM AIX bietet seit vielen Jahren innerhalb seines Standardinstallationsumfangs ohne Extrakosten einige Schätze in punkto Systeminstallation, -backup und -recovery, die noch nicht überall "geborgen" wurden. Zwar erhöht sich durch die Einführung von NIM der Verwaltungsaufwand, jedoch bringt die erhöhte Flexibilität und die Fähigkeit der Automation von Prozessen eine Erhöhung der Effizienz in der Installation schon ab wenigen angeschlossenen Client-Systemen.

Dr. Uwe Bechthold (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen