EMC NetWorker Agent in VMware vCenter Server Appliance 5.5 installieren

Beim Einsatz eines virtuellen vCenter Servers ist es besonders wichtig, ein funktionierendes Backup zu haben. Fällt der vCenter Server aus, kann die virtuelle Systemlandschaft nicht mehr vollständig administriert und überwacht werden.

Bei konventionellen Microsoft Windows Servern mit installiertem VMware vCenter Server gestaltet sich die Einrichtung eines Backups deutlich einfacher, da ein vollwertiges Betriebssystem verwendet wird. Wird jedoch die VMware vCenter Server Appliance verwendet gestaltet sich die Einrichtung eines konventionellen Backups schwieriger. Das System verfügt i.d.R. nicht über vorinstallierte Backup-Agenten, da davon ausgegangen wird, dass ein „agentless“ Backup für virtuelle Maschinen verwendet wird.

Nicht jedes Unternehmen verfügt schon über eine Backup-Lösung, die „agentless“ Backups ermöglicht. Fehlt eine solche Funktion fehlt auch erstmal das Backup, was für produktive Umgebungen unvorteilhaft ist. Wird beispielsweise EMC NetWorker nicht in der neuesten Version verwendet, gibt es diese Funktion nicht.

Die vCSA basiert auf SUSE Linux Enterprise Server 11 SP2 und kann demnach – sofern entsprechend paketierte Software vorliegt – auch über RPM-Pakete erweitert werden. Entgegen anderer virtuellen Appliances, die ich schon gesehen habe, wird dem Administration bei der vCSA kein Root-Passwort vorenthalten. Es ist also prinzipiell möglich, noch benötigte Software nachzuinstallieren. Prinzipiell wird das jedoch nicht vom VMware-Support abgedeckt.

Installation von EMC NetWorker

EMC liefert NetWorker für RPM-basierte Linux-Distributionen in Form eines generischen RPMs aus. Dieses Software-Paket ist also u.a. mit Red Hat Enterprise Linux und SUSE Linux Enterprise Server kompatibel – es eignet sich daher auch zur Installation in der vCSA.

Im Bezug auf EMC NetWorker gilt es jedoch noch einige Software-Abhängigkeiten aufzulösen. Die folgenden Pakete müssen noch nachinstalliert werden (je nach verwendeter NetWorker-Version variiert diese Liste ggf.):

  • libcap1*.x86_64.rpm
  • libstdc++33*.x86_64.rpm
  • ksh-93u*.x86_64.rpm

Und woher bekommt man diese Pakete? Prinzipiell benötigt man für den Download von Software-Paketen für SLES eine gültige Subscription. SUSE bietet jedoch auch Testversionen der hauseigenen Enterprise-Produkte an – u.a. auch SLES: [klick mich!]

Besitzer der vSphere Standard oder einer höheren Edition hatten im Rahmen des „SUSE Linux Enterprise Server for VMware“-Programms ohenhin Anspruch auf kostenlose Produktpatches und -updates (bis zum 25.07.2014, siehe auch hier). Es wird lediglich eine Registrierung der gekauften ESXi-Seriennummer bei SUSE benötigt. Anschließend wird ein Aktivierungscode generiert, welcher während der Installation eingeben kann, um Produktupdates freizuschalten: [klick mich!]

Nach einer kurzen Registrierung kann man eine Testversion inklusive 60 Tage kostenlosem Update-Support herunterladen. Prinzipiell benötigt man nur die erste der beiden DVDs, hier befinden sich im Unterordner „suse/x86_64“ die benötigten RPM-Pakete. Idealerweise lädt man nicht das neueste SLES-Release SP3 sondern SP2 herunter, da die vCSA auf diesem Release basiert.

Für die Installation des EMC NetWorker Agenten reichen i.d.R. die Pakete lgtoman und lgtoclient. Die von der DVD extrahierten RPM-Pakete werden über SSH/SCP auf die vCSA übertragen und anschließend samt Agent installiert:

# zypper localinstall lib*.rpm ksh*.rpm lgtoclnt*.rpm lgtoman*.rpm

Service-Konfiguration

Bevor NetWorker das erste Mal gestartet wird, ist es wichtig, die notwendige Ordnerstruktur und eine Liste der berechtigen Backupserver zu erstellen. Wird NetWorker gestartet, ohne, dass diese Informationen vorliegen, funktioniert der Backup-Agent nicht und muss ggf. neu installiert werden (da die fehlerhaften Einstellungen zwischengespeichert werden).

# mkdir -p /nsr/res
# echo "backupserver.fqdn.loc" > /nsr/res/servers
# chmod -R 755 /nsr/*
# chkconfig rpcbind on
# chkconfig networker on
# service networker start
starting NetWorker daemons:
 nsrexecd

Die Dienste rpcbind und networker sollten aktiv sein, damit das Erstellen von Backups funktioniert:

# service rpcbind status
Checking for service rpcbind                              running
# service networker status
+--o nsrexecd (PID)

Backup-Skripte

In vielen Firmen gilt der Defacto-Standard des wöchentlichen Offline-Backups, meistens am Wochenende. So werden Maschinen oft täglich „online“ gesichert – also ohne, dass Anwendungsdienste gestoppt werden. Das hat natürlich zur Folge, dass nicht alle Nutzdaten konsistent gesichert werden, da manche Daten (z.B. Datenbank-Dateien) noch in Verwendung sind. Diese Daten werden im Offline-Backup gesichert.

Zur Steuerung des Offline-Backups werden bei der Verwendung von EMC NetWorker i.d.R. Shell-Skripte erstellt. Ein Skript wird vor Ausführung des Backup-Jobs ausgeführt, ein anderes wird nach Ausführung des Jobs ausgeführt.

Bei der Erstellung der Backups habe ich mich an den folgenden VMware KB-Artikeln orientiert:

Meine Skripte sehen wie folgt aus:

# vi /opt/start_offline_backup.sh
#!/bin/sh
service vmware-vpxd stop
service vmware-inventoryservice stop
/opt/vmware/vpostgres/1.0/bin/pg_dump INSTANCE -U USER -Fp -c > /tmp/VCDBackUp
/usr/lib/vmware-vpx/inventoryservice/scripts/backup.sh -file /tmp/InventoryServiceDB.DB

ESC ZZ

# vi /opt/stop_offline_backup.sh
#!/bin/sh
service vmware-vpxd start
service vmware-inventoryservice start

ESC ZZ

# chmod +x /opt/st*_offline_backup.sh

Die Variablen INSTANCE und USER müssen angepasst werden – die dazugehörigen Werte finden sich in der Konfigurationsdatei /etc/vmware-vpx/embedded_db.cfg. Es muss auch überprüft werden, ob das Dateisystem /tmp über ausreichend Speicherkapazität für die Backups verfügt.

Abschließend möchte ich noch mals anmerken, dass das beschriebene Vorgehen zwar funktioniert, jedoch nicht vom VMware-Support abgedeckt wird. Bevor ein Support-Fall eröffnet wird (oder Appliance-Updates installiert werden!), empfiehlt es sich also die vorgenommenen Anpassungen rückgängig zu machen.

2 Kommentare Schreibe einen Kommentar

  1. Hallo, es geht auch einfacher…. da hier in einer großen Umgebung auch Networker zum Einsatz kommt… ein kleiner Denkanstoß.
    Am besten man legt mittels createrepo
    createrepo /srv/legatoclient/sles11/x86_64/ x86_64
    ein eigenes Networker Repo auf dem hoffentlich vorhandenen zentralen Installierver an. „Moschtet“ dort die Pakete lgtoclnt lgtoman und lgtonmda an. Den lgtonmda braucht man falls auch Datenbanken gesichert werden müssen. Hängt das Repo dann zypper addrepo -t YUM http://meinsinstallserver/legatoclient/ legatoclient

    Spart viel Zeit und Nerven. Allerdings sollte man der Backupjodler Fraktion das ganze auch nahe bringen da nach meinen Erfahrungen die Kollegen immer noch wild RPM’s durch die Gegend kopieren und sich ärgern wenn die Abhängigkeiten wieder mal fehlen. 😉

  2. Ach ja noch ein kurzer Nachtrag…. es sollte eigentlich nicht notwendig sein /nsr/res händisch anlegen zu müssen. Normalerweise macht der Networker das „Out of the Box“. Auf die /nsr/res/servers kann man auch verzichten, solange beim Kunden DNS nicht erst im nächsten Jahrtausend erfunden wird. 😉 Lohnenswerter ist es eher die /etc/hosts auf dem Networker Server zu pflegen und die Networker Server und Storage Nodes auch sauber in der /etc/hosts auf der Clientseite einzutragen. Networker ist sowieso manchmal zickig und die /nsr/res/servers kann auch bei vermeintlich falschen Einträgen schon mal zur Verwirrung des Clients beitragen.

Schreibe einen Kommentar