Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einführung
2 Virtuelle Maschinen im Unternehmen
3 Virtualisierungssoftware – eine Marktübersicht
4 Auswahl der möglichen virtuellen Maschine
5 Auswahl der richtigen Virtualisierungssoftware
6 Auswahl der richtigen physikalischen Infrastruktur
7 Installation und Update des Wirt-Systems
8 Verwaltung der Virtualisierungssoftware
9 Virtuelle Netzwerke
10 Virtuelle Festplatten
11 Erstellung einer virtuellen Maschine
12 Verwaltung der virtuellen Maschinen
13 VMware VirtualCenter
14 Skriptierung und Programmierung unter VMware und MS Virtual Server
15 Backup, Restore und Disaster Recovery
16 Templates (VM-Vorlagen)
17 Zusatzsoftware
18 Nützliche Adressen im Web
A Clustereinrichtung und Beispielumgebungen
B Kommandozeile und wichtige Dateien
C Häufige Fragen
Stichwort

Download:
- ZIP, ca. 17,5 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
VMware und Microsoft Virtual Server von Dennis Zimmer
Virtuelle Server im professionellen Einsatz
Buch: VMware und Microsoft Virtual Server

VMware und Microsoft Virtual Server
geb., mit CD
612 S., 49,90 Euro
Galileo Computing
ISBN 978-3-89842-701-2
Pfeil 15 Backup, Restore und Disaster Recovery
Pfeil 15.1 Sicherung und Wiederherstellung
Pfeil 15.1.1 Das Gast-System
Pfeil 15.1.2 Das Wirt-System
Pfeil 15.2 Disaster Recovery und Hochverfügbarkeit
Pfeil 15.2.1 Katastrophenfall
Pfeil 15.2.2 Cluster – virtuelle Maschine
Pfeil 15.2.3 Cluster – Wirt-System

15 Backup, Restore und Disaster Recovery

Sicherung und Wiederherstellung der Struktur sind bei der Verwendung virtueller Maschinen zwei wesentliche Aspekte. Aus diesem Grund kann auch das Disaster Recovery im Falle eines Ausfalls vereinfacht werden.

Im Normalfall werden die Servervirtualisierungsprodukte gerade in kleinen und mittelständischen Unternehmungen nicht ausschließlich für Test- und Spielumgebungen genutzt. Deshalb müssen sowohl die virtuellen Maschinen als auch das Wirt-System zur Aufrechterhaltung des Geschäftsbetriebes regelmäßig gesichert werden. Aber keine Sicherung der Welt nutzt etwas, wenn die Rücksicherung nicht sauber oder nur fehlerhaft funktioniert. Ein weiterer Faktor ist die Kompetenz bzw. die gründliche Dokumentation über den gesamten Backupprozess hinweg, die zur Verringerung der Ausfalldauer enorm beiträgt. Übrigens sind deutsche Unternehmen gesetzlich verpflichtet, verschiedene Daten über einen gewissen Zeitraum zu archivieren bzw. Maßnahmen zu ergreifen, die garantieren, dass der Geschäftsbetrieb auch im Katastrophenfall aufrechterhalten werden kann.

Physikalische Systeme stellen jeden Administrator vor eine schwierige Aufgabe, was eine ordentliche und funktionierende Sicherung und vor allem auch Rücksicherung angeht. Durch die Vielzahl von Servern mit unterschiedlicher Hardware und der darauf laufenden Dienste wird dieses Unterfangen noch weiter verkompliziert. Hier bieten Ihnen virtuelle Maschinen deutliche Vereinfachungen, da eine immer gleiche Hardware vorliegt und man mittels Templates recht schnell ein System wiederherstellen kann. Genau mit diesen Templates ist einfach und schnell ein funktionierendes Disaster Recovery für virtuelle Systeme einzurichten. Trotzdem bleibt natürlich immer noch die physikalische Welt übrig, die gesondert behandelt werden muss, wie beispielsweise die Wirt-Systeme oder das Backupsystem an sich.

Neben der Sicherung und Wiederherstellung der Daten ist auch die Ausfallsicherheit ein großes und wichtiges Thema. Besonders bei Systemen, deren Ausfall direkt negative Folgen hat, wie dies beispielsweise bei Mail- oder Fileservern der Fall ist, trägt ein geclustertes System deutlich zur Ausfallsicherung bei. Je nach Virtualisierungssoftware sind verschiedenste Cluster sowohl für das Wirt- als auch das Gast-System möglich. Eine weitverbreitete Alternative ist das Clustern eines physikalischen Systems mit einer VM, die im Fehlerfall für den physikalischen Server alle Dienste übernimmt. Dies ist kostengünstig und sinnvoll, da man bei einem Systemausfall nicht unbedingt die gleiche Performance benötigt und es nur darum geht, die Ausfallzeit zu überbrücken, bis das physikalische System wieder läuft.

Falls Sie im Laufe dieses Kapitels zu zweifeln anfangen, ob Ihre Sicherungsprozesse durchgängig und gewissenhaft geplant wurden bzw. ausgeführt werden, sollten Sie sich unbedingt mit einem Berater in Verbindung setzen oder ein fachkundiges Buch zu diesem Thema lesen. Bedenken Sie, dass Fehler immense Schäden und damit Kosten verursachen können, die Ihr Unternehmen durchaus in Bedrängnis bringen könnten.


Galileo Computing - Zum Seitenanfang

15.1 Sicherung und Wiederherstellung Zur nächsten ÜberschriftZur vorigen Überschrift

Bei der Sicherung kann man unabhängig von der eingesetzten Virtualisierungssoftware zwischen Gast- und Wirt-Systemsicherung, unterscheiden. Während die virtuelle Maschine, was die Sicherung angeht, wie ein physikalisches System funktioniert, kann das Wirt-System ein wenig differenzierter angepackt werden. Um dies zu verdeutlichen, greife ich zu einem in der Praxis durchaus gängigen Beispiel.

Bei Verwendung eines VMware ESX Servers mit der VMotion-Funktionalität befinden sich die Festplattendateien der virtuellen Maschine zwangsweise auf einem SAN Storage. Fällt nun der ESX Server aus, kann man mit ein wenig Aufwand sehr schnell einen neuen Server installieren, da »nur« die Hardware ersetzt werden muss und die Konfiguration des Servers und der virtuellen Maschinen wiederherzustellen ist. Sobald dies geschehen ist, bleibt nur noch, den Zugriff zum SAN Storage und damit zu den Festplattendateien der virtuellen Maschinen herzustellen. Danach ist die Situation wieder geregelt.

Wie Sie sehen, verliert durch die Trennung der Festplattendateien und des Wirt-Systems die Systemwiederherstellung an Komplexität, da auf dem eigentlichen Wirt-System nur die Konfiguration des Wirtes selbst (Netzwerk, RAID, FC-Anbindung) und die Konfigurationsdateien der virtuellen Maschinen (.vmx) abgelegt werden. Selbst die .vmx-Dateien könnten bei entsprechender Dokumentation sehr schnell neu erstellt werden. Das hier der Ausfall der SAN Anbindung bzw. des SAN Storage mit allen Mitteln verhindert werden, brauche ich nicht zu betonen.

Aber selbst wenn keine Trennung der Daten vorliegen würde, haben Sie durch das Wirt-System andere Möglichkeiten, die Daten der virtuellen Maschine zu sichern. Da die VMs auf dem Wirt-System nur aus wenigen relevanten Dateien bestehen, können auch diese sehr einfach und elegant gesichert werden.

Bevor wir uns allerdings mit den eigentlichen Produkten befassen, will ich zunächst auf den Ablauf einer Sicherung bzw. einer Wiederherstellung eines physikalischen Systems eingehen.

Abbildung 15.1 Ablauf vom ungesicherten zum gesicherten Server

Wie Sie Abbildung 15.1 entnehmen können, sind einige sehr wichtige Schritte notwendig, bis ein Server korrekt gesichert wird. Dieses Abbild ist sehr vereinfacht, da gerade der erste Punkt, also die Auswahl der zu sichernden Daten, ein sehr komplexes und schwieriges Unterfangen werden kann. Stellen Sie sich einfach einen Oracle-Datenbankserver vor, dessen Datenbanken gesichert werden sollen. Was haben Sie nun für Möglichkeiten? Beispielsweise können Sie die Daten immer vor der eigentlichen Sicherung per Skript aus der Datenbank exportieren oder die Möglichkeiten eines RMAN-Skriptes quasi über Oracle eigene Mechanismen online sichern. Was nicht funktioniert, wäre die Sicherung der geöffneten Datenbankdateien, ohne eine vorherige Aktion oder Einstellung in Oracle oder der Backupsoftware. An diesem kleinen Beispiel sollte eigentlich schon klar werden, welche Komplexität allein die Datenauswahl in der heute meist sehr heterogenen Welt birgt.

Es besteht auch kein Unterschied zwischen virtuellem und physikalischen Server, vorausgesetzt Sie wollen die Sicherung im Server stattfinden lassen, und demnach nicht über das Wirt-Betriebssystem. Was das genau heißt, werden Sie im Laufe dieses Kapitels erfahren.

Nach erfolgreicher Sicherung kommt jedoch die weit spannendere Angelegenheit: die Rücksicherung. Hier entscheidet sich, ob die Datensicherung selbst und Ihr Datensicherungskonzept korrekt war oder die Sicherung keinen Pfifferling wert ist, da Sie schlichtweg nicht funktioniert hat. Natürlich kann eine solche Situation in der Realität äußerst unangenehm sein, da eine fehlerhafte Sicherung im Falle eines Systemausfalls den Verlust unternehmenskritischer Daten zur Folge hat.

Gerade in der Rücksicherung können je nach System, wie Sie gleich sehen werden, die Stärken einer virtuellen Maschine liegen. Im nächsten Fall gehe ich auf die komplette Rücksicherung ein, die eher ein Disaster Recovery genannt werden kann, weil eine Rücksicherung einzelner Dateien doch recht unspektakulär ist.

Abbildung 15.2 Prozess der Rücksicherung bei Komplettausfall des Systems

Ich denke, es ist auf Anhieb zu sehen, welche Schritte bei einer virtuellen Maschine vereinfacht werden. Da die Hardware immer gleich ist, kann man die Treiberproblematik ignorieren. Bei älteren physikalischen Systemen kann es durchaus passieren, dass nicht mehr die Originalhardware lieferbar ist, was bei einer Rücksicherung durchaus problematisch sein kann. Innerhalb der virtuellen Maschine ändert sich die Hardware auf keinen Fall, daher sind auch keine »Hardwaredefekte« innerhalb der VM möglich. Zudem verläuft die Installation des Betriebssystems und der Servicepacks deutlich schneller, weil alleine die vielen Neustarts im Sekunden- statt im Minutenbereich sich bewegen. Durch Templates kann dieser Prozess noch weiter beschleunigt und sogar teilweise automatisiert werden. Auch Komplexität und Umfang der Dokumentation zur Rücksicherung wird dadurch deutlich verringert, was jedem Administrator zugute kommt. Wenn Sie jemals in der Stresssituation einer Rücksicherung eines durch Hardwaredefekt zerstörten wichtigen Serversystems waren, wissen Sie, wovon ich rede.

Ein letzter wichtiger Aspekt betrifft den Backupserver selbst, da es wenig Sinn macht, eine Bandstation mit der virtuellen Maschine oder dem Wirt-System direkt zu verbinden. Begründet wird dies einmal durch die eingeschränkten Möglichkeiten der Hardwareunterstützung von Bandlaufwerken virtueller Maschinen und der Virtualisierungsserver. Ein weiterer Aspekt ist die Tatsache, dass man aus Performance- und vor allem auch Sicherheitsgründen die Bandlaufwerke nicht an die Virtualisierungsserver koppelt. Weit mehr Sinn macht hier der Aufbau eines eigenen physikalischen Servers, der die Bandstationen bedient und über das Netzwerk die einzelnen Server sichert. Auf die Empfehlung, dass sich das Sicherungssystem nicht im gleichen Gebäude wie der zu sichernde Server und die ausgelagerten Sicherungsmedien befinden sollte, muss ich nicht näher eingehen.


Galileo Computing - Zum Seitenanfang

15.1.1 Das Gast-System Zur nächsten ÜberschriftZur vorigen Überschrift

Da innerhalb der virtuellen Maschine ein ganz normales Betriebssystem installiert ist, kann es genau wie ein physikalisches System auch gesichert werden. Prinzipiell können Sie entweder »direkt« Bandlaufwerke über ein generic SCSI Device anschließen oder einen Backup-Agenten im Betriebssystem installieren, der über das Netzwerk an einen Backupserver gekoppelt ist. Bei Verwendung des VMware ESX Servers mit lokaler Bandstation muss das Bandlaufwerk über die SCSI-Schnittstelle am Wirt-System angeschlossen und für die virtuellen Maschinen freigegeben werden. Dies können Sie entweder über die MUI oder über das Kommandozeilentool vmkpcidivy –i machen.

Abbildung 15.3 Installation des IBM Tivoli Backup-Agenten innerhalb einer virtuellen Maschine

Bei einer IBM Tivoli-Umgebung würde das z. B. so aussehen, dass einfach der TSM Backup-Agent innerhalb der virtuellen Maschine installiert (Abbildung 15.3) und konfiguriert (Abbildung 15.4) wird. Danach kann die Datensicherung ganz normal über die Funktionen der Sicherungssoftware ablaufen.

Abbildung 15.4 Konfiguration des IBM Tivoli Backup-Agenten innerhalb der virtuellen Maschine

Ebenso wie die Sicherung kann auch die Rücksicherung so erfolgen, wie Sie es von physikalischen Systemen her gewohnt sind. Nur beim Komplettausfall der Datenlaufwerke oder einem Crash der Systempartition kann mit der virtuellen Maschine ein wenig besser umgegangen werden, bzw. die Wiederherstellung kann unter Umständen schneller ablaufen, da sich die Rebootzeiten deutlich verkürzen. Auch Aufgaben wie z. B. die RAID-Konfiguration, die bei einem physikalischen System fast immer anfallen, können bei einer VM vernachlässigt werden.

Was sind aber nun die Vorteile einer Sicherung innerhalb der virtuellen Maschine?

  • keine Unterscheidung zwischen virtuellen und physikalischen Systemen
  • keine Einschränkungen für Backupsoftware, solange Sie das Gast-Betriebssystem unterstützt
  • Möglichkeit zur Sicherung und Rücksicherung auf Dateiebene möglich
  • inkrementell Sicherung möglich, d. h., es werden nur veränderte Dateien gesichert, was das Sicherungsvolumen gegenüber einer Vollsicherung deutlich verringert

Nachteile

  • Keine Nutzung der auf dem Wirt-System konsolidierten Dateien (Festplattendateien + Konfigurationsdatei) einer virtuellen Maschine möglich. Beim Beispiel einer VM auf einem VMware GSX Server mit zwei Festplatten im Normalzustand, müssten nur drei Dateien zwingend gesichert werden (vm.vmx, vm-disk1.vmdk, vm-disk2.vmdk), was eine sehr schnelle Sicherung und Wiederherstellung zur Folge hat.
  • Keine Nutzung verschiedener Modi einer virtuellen Maschine möglich, wie beispielsweise Suspend, Resume oder Snapshots.
  • Eine Rücksicherung ist nur in eine laufende virtuelle Maschine möglich.
  • Der Netzwerkverkehr steigt proportional durch die Sicherung über Sicherungsagenten, kann aber über die zeitliche Verschiebung der einzelnen Sicherungen relativiert werden.

Galileo Computing - Zum Seitenanfang

15.1.2 Das Wirt-System topZur vorigen Überschrift

Über das Wirt-System können nun weitere Sicherungsprozesse ablaufen, da es als Basis für die virtuellen Maschinen dient und eine Art Datenkonsolidierung betrieben wird. Nicht nur die Daten einer virtuellen Maschine, sondern alle Konfigurationsdaten des Wirt-Systems sollten gesichert werden, obwohl man einen Wirt im Normalfall relativ schnell auch ohne Sicherung rekonstruieren kann, vorausgesetzt die VM-Daten stehen zur Verfügung.

Virtuelle Maschinen

Wie schon in Abschnitt 15.1.1, Das Gast-System, erwähnt, kann man auch über das Wirt-System die virtuellen Maschinen sichern und gegebenenfalls wiederherstellen. Dies kann je nach Virtualisierungssoftware sogar zur Laufzeit geschehen. Wenn Sie die virtuelle Maschine vorher ausschalten, können die entsprechenden Dateien problemlos gesichert werden. Falls Sie nicht mehr genau wissen, aus welchen Dateien eine virtuelle Maschine besteht, lesen Sie dies bitte in Kapitel 11, Erstellung einer virtuellen Maschine, nochmals nach.

Im laufenden Zustand wird es schon problematischer, weil dann auf die virtuellen Festplatten zugegriffen wird. Außer bei VMware ESX bleibt Ihnen nur die Wahl zwischen Abschalten oder Suspendieren (Save State unter Virtual Server) der virtuellen Maschine vor der Sicherung. Dies kann manuell, mittels Skript aber auch automatisch geschehen.

for machine in $(vmware-cmd -l); do echo working on $machine
export START=$(date +%s)
vmware-cmd -v $machine start
export STOP=$(date +%s)
let TIMETOOK=$STOP-$START
echo $machine done starting after $TIMETOOK seconds
done

In diesem Skript, das aus dem VMware Forum der VCommunity stammt, werden alle virtuellen Maschinen eines VMware GSX (Linux) gestartet, und die jeweils verstrichene Zeit wird ausgegeben. Um dieses Skript zu vervollständigen, müsste vor dem Starten ein suspend oder stop an die VMs gesendet und dann müssten die .vmdk-Dateien kopiert werden. Ebenso, nur mit anderen Befehlen und zu kopierenden Dateien, läuft dies auch unter Microsoft Virtual Server ab. Skripte dazu finden Sie über Google, die Community-Webseiten und auch auf der beiliegenden CD.

VMware ESX bietet eine Besonderheit, nämlich das Sichern von Festplattendateien während der Laufzeit. Dieses so genannte »Hot Backup« wird mit Hilfe eines REDO Logs realisiert. Da beim Anlegen eines REDO Logs die Originalfestplattendatei zum Lesen freigeben wird, kann Sie auch gesichert werden. Nach der Sicherung wird das REDO Log einfach wieder mit der Festplattendatei zusammengeführt. Mit mehreren REDO Logs könnte man auch verschiedene Stände sichern. VMware liefert auch schon direkt zwei Skripte namens VMsnap.pl und VMres.pl mit, die zur Sicherung und Wiederherstellung dienen. Ein weiteres sehr interessantes Perl-Skript, das hinsichtlich der Sicherungsfunktionen kaum noch Wünsche offen lässt, finden Sie auf der Webseite http://www.vmts.net. Außerdem gibt es noch weitere Programme von Drittanbietern, die Sie in Kapitel 17, Zusatzsoftware, nachlesen können.

Um Ihnen die Verwendung des REDO Logs zum Hot Backup, also der Sicherung der laufenden virtuelle Maschine noch etwas genauer zu erläutern, schauen wir uns die Schritte des VMsnap.pl-Skriptes von VMware einmal näher an.


Tabelle 15.1 Funktionsweise des VMsnap.pl Skriptes

Ablauf Festplattendateizugriff

Ausgangspunkt

disk.dsk ← Aktiv (kein Zugriff)

1. REDO Log aktivieren

disk.dsk ← konsistenter Zustand (Lesen)

disk.dsk.REDO ← Aktiv (kein Zugriff)

Sicherung disk.dsk

disk.dsk ← konsistenter Zustand (Lesen) wird mittels vmkfstools exportiert

disk.dsk.REDO ← Aktiv (kein Zugriff)

2. REDO Log aktivieren

disk.dsk ← konsistenter Zustand (Lesen)

disk.dsk.REDO ← konsistenter Zustand (Lesen)

disk.dsk.REDO.REDO ← Aktiv (kein Zugriff)

1. REDO Log schreiben

disk.dsk ← konsistenter Zustand (Lesen)

disk.dsk.REDO.REDO ← Aktiv (kein Zugriff)

2. REDO Log schreiben

disk.dsk ← Aktiv (kein Zugriff)


Da beim Zurückschreiben des letzten REDO Logs auf die Originalfestplatte diese zwingend angehalten werden muss, kann es je nach Größe des REDO Logs zu einem Ausfall der virtuellen Maschine kommen. Daher wird das zweite REDO Log angelegt, um die Datenmenge, die während der Backupprozedur aufkommt, zu verringern und damit ein schnelles Zurückschreiben im laufenden Betrieb zu ermöglichen. Mittels des zweiten REDO Logs, das nur kurzen Bestand hat und daher sehr klein ist, fällt das Pausieren der Festplatte nicht ins Gewicht und die VM läuft weiter.

Sie müssen allerdings beachten, dass nach Sicherung und Rücksicherung einer laufenden VM die VM in einem Zustand ist, in dem sie auch nach einem Stromausfall wäre. Warum? Ganz einfach, es werden die Daten der Festplatte zum Zeitpunkt X gesichert. Alle Informationen, die das Betriebssystem im Hauptspeicher hält werden nicht berücksichtigt. Wenn man diesen Stand nun zurückspielt, sind nur die Informationen der Festplatte, aber nicht die des Hauptspeichers vorhanden, was dem Zustand nach einem harten Ausschalten gleichkommt.

Ganz gleich, welches Produkt Sie verwenden, überprüfen Sie die Serverleistung während des Kopierprozesses. Durch die entstehende I/O-Last auf dem Wirt-System beim Kopieren der virtuellen Festplattendateien können alle laufenden virtuellen Maschinen beeinträchtigt werden. Falls das der Fall ist, sollten Sie sich überlegen, die Festplattendateien direkt über das Netzwerk per FTP oder SCP auf einen anderen Server zur Sicherung zu kopieren.

Im Folgenden sind die Vor- und Nachteile der Sicherung der kompletten virtuellen Maschine (Konfiguration- und Festplattendateien) über das Wirt-System einander gegenübergestellt:

Vorteile:

  • Sehr einfache Sicherung und Wiederherstellung möglich, da die virtuellen Maschinen nur aus wenigen Dateien bestehen.
  • Die virtuellen Maschinen können problemlos auf einem anderen Wirt-System wiederhergestellt werden.
  • Durch die wenigen großen Dateien ist eine sehr schnelle Sicherung/Rücksicherung möglich, da in einem Stream gesichert/wiederhergestellt werden kann.
  • Es kann problemlos der Zustand der VM zu einem bestimmten Zeitpunkt zurückgesichert werden, beispielsweise vor dem gerade eingespielten Servicepack.
  • Es können mehrere Systemstände vorgehalten werden, die bei Bedarf zurückgespielt werden.
  • Sicherungen können als Templates für neue virtuelle Maschinen dienen.
  • äußerst nützlich für Disaster Recovery

Nachteile:

  • Keine Sicherung/Rücksicherung auf Dateiebene innerhalb der virtuellen Maschine möglich.
  • Unterscheidung zwischen physikalischen und virtuellen Systemen bei der Sicherung/Rücksicherung, dadurch Erhöhung der Komplexität für die Administratoren
  • Beim Einsatz von VMware ESX ist es nicht mit jeder Backupsoftware möglich, Dateien im VMFS zu sichern.

Übrigens spricht außer dem erhöhten Bedarf an Speicherplatz und Netzwerkverkehr nichts gegen die Verwendung beider Maßnahmen zur Sicherung virtueller Maschinen. Dadurch stehen Ihnen im Fehlerfall alle Möglichkeiten offen, um schnellstmöglich einen funktionierenden Zustand wiederherstellen zu können.


TIPP
Falls Sie im Besitz eines SAN Storage sind, in dem alle Festplattendateien der virtuellen Maschinen liegen, können Sie auch die Funktionen des SAN selbst nutzen. Diese Funktion, meist »SAN Image« genannt, kann die entsprechenden LUNs mit sehr hoher Geschwindigkeit zu einem vorgegebenen Zeitpunkt mittels Snapshot sichern. Einzige Ausnahme: Wenn Sie VMFS Spanning verwenden, können Sie von diesem Mechanismus zur Zeit keinen Gebrauch machen.

VMware GSX

Da VMware GSX auf einem Microsoft Windows- oder Linux-Betriebssystem aufsetzt, kann dieser auch wie gewohnt gesichert werden. Grundsätzlich wird jede Backupsoftware unterstützt, die durch das Wirt-Betriebssystem Unterstützung findet. Besonderes Augenmerk gilt natürlich der Konfiguration, die bei einer Standardinstallation im Programmverzeichnis VMware zu finden ist. Die Konfigurationsdateien der virtuellen Maschinen befinden sich im Normalfall im gleichen Verzeichnis wie die Festplattendateien und können darüber auch gesichert werden.

Microsoft Virtual Server

Microsoft Virtual Server unterscheidet sich nur durch die fehlende Unterstützung des Linux-Betriebssystemes als Wirt, daher kann jede, auf Microsoft Windows basierende Backupsoftware verwendet werden. Auch hier befinden sich die Konfigurationsdateien der virtuellen Maschinen im gleichen Verzeichnis wie die Festplattendateien, falls deren Lage nicht manuell verändert wurde. Bei einer Standardinstallation befindet sich alles für Virtual Server relevante innerhalb des Programmverzeichnisses Microsoft Virtual Server, %AllUsersProfile%\Anwendungsdaten\Microsoft\Virtual Server und %AllUsersProfile%\Anwendungsdaten\Microsoft\Virtual Server Webapp.

VMware ESX

Der VMware ESX Server kann ganz normal wie ein Linux-System entweder über eine lokal angeschlossene Bandstation oder über unterstützte Backupsoftware gesichert werden. Falls eine lokale Bandstation verwendet wird, muss sie der Service Console zugeordnet worden sein (sharing zwischen Service Console und VMkernel ist nicht möglich), was auch nach der Installation über die MUI oder mit dem Befehl vmkpcidivy –i geschehen kann. Falls es Sie interessiert, welche Backupsoftware unterstützt wird, finden Sie über die URL http://www.vmware.com/pdf/esx_backup_guide.pdf eine aktuelle Liste der Produkte. Bedenken Sie, dass die Konfigurationsdateien der virtuellen Maschinen je nachdem, ob die MUI oder das VirtualCenter verwendet wird, entweder im Homeverzeichnis des anlegenden Benutzers (bei Root wäre es /root/vmware) oder im /home/vmware-Verzeichnis zu finden sind.

Unter Umständen muss die Sicherungssoftware angepasst werden, damit sie VMFS-Partitionen verwenden kann. Allerdings ist diese danach in der Lage, die darauf liegenden Dateien direkt zu sichern und wiederherzustellen. Falls Sie Probleme mit Ihrer Sicherungssoftware haben, kann ich Ihnen nur nahe legen, einen Blick in die Knowledge Base oder das Community-Forum zu werfen, weil dort sehr viele Tipps und Informationen zu finden sind. Wie eine solche Anpassung aussieht, will ich Ihnen anhand des Tivoli Storage Managers kurz demonstrieren. Diese Software können Sie an Ihre Umgebung angepasst direkt verwenden. Folgende Änderung müsste in der Datei dsm.sys vorgenommen werden, die Sie unter /opt/tivoli/tsm/client/ba/bin finden:

SErvername ESX01  ß Name des lokalen Systems unter Tivoli
COMMmethod     TCPip
TCPPort     1500
TCPServeraddress  TSM_IP  ß IP Addresse des Tivoli Servers
passwordaccess   generate
MAKESPARSEFILE NO
LARGECOM yes
VIRTUALM /vmfs
TXNB 26500

Nach einem erneuten Start der Tivoli-Dienste, sind alle VMFS-Partitionen sichtbar, und es kann auf sie zugegriffen werden. Der Zugriffsschutz auf die Festplattendateien durch den VMkernel bei einer laufenden virtuellen Maschine können Sie trotzdem nicht umgehen. Es bleibt Ihnen auch hier nur die Wahl einer Offline-Sicherung oder einer Sicherung über das REDO Log.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Aktuelle Bücher von
  Dennis Zimmer
Zum Katalog: VMware ESX 3.5 Automatisierung, Befehle, Scripting





 VMware ESX 3.5
 Automatisierung,
 Befehle, Scripting


Zum Katalog: VMware Infrastructure 4





 VMware
 Infrastructure 4


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchtipps
Zum Katalog: Xen Das umfassende Handbuch






 Xen
 Das umfassende
 Handbuch


Zum Katalog: Windows Server 2008






 Windows Server 2008


Zum Katalog: Office SharePoint Server






 Office SharePoint
 Server


Zum Katalog: Exchange Server 2007






 Exchange Server 2007


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu GNU/Linux


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2005
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de