Get-VM | Sort Name | Get-Snapshot |
Where { $_.Name.Length -gt 0 } |
Select VM,Name,Description,Created

Das kann man natürlich auch auf ein Datacenter einschränken

Get-Datacenter -Name "Datacenter Name" | Get-VM |
Sort Name | Get-Snapshot |
Where { $_.Name.Length -gt 0 } |
Select VM,Name,Description,Created

Oder auf einen Cluster

Get-Cluster -Name "Cluster Name" | Get-VM |
Sort Name | Get-Snapshot |
Where { $_.Name.Length -gt 0 } |
Select VM,Name,Description,Created

Die Lösung ist simple. Einfach im vSphere Client einen neuen Snapshot z.B. test erstellen. Danach wird auch der andere angezeigt, dann kann ich wieder alle Löschen. Da ist er momentan auch dran. Seit über 1h.

Muss noch schauen ob das ein bekanntes Problem ist. Und ob das gleiche auch via command line, z.b. mit PowerCLI passiert.

amsfas21> df -s
Filesystem                used      saved       %saved
/vol/vmware_data01/   68863864  303083528          81%

Da bin ich doch baff. Mal sehen. Hab schon ca. 20 VMs auf den neuen FAS2020 migriert. Mal sehen wie es aussieht wenn ich alle Server drüben hab.

Zuerst muss natürlich immer eine Verbindung zu einem VMWare/Virtual Center/vCenter Server hergestellt werden. Das geht mit

Connect-VIServer

Dann fragt er die Angaben interaktiv ab oder mit

Connect-ViServer -Server vcserver01 -User admin -Password supersecret

gehts auch via Command Line.

Nun habe ich einen Server (Server01) denn ich im laufenden Betrieb via Storage vMotion auf den Datastore dsNew verschieben will. Das geht mit

Get-VM Server01 | Move-VM -Datastore (Get-Datastore dsNew)

Das wars auch schon. Das geht natürlich auch übers GUI aber wenn wir z.B. alle VMs vom Datastore dsOld zum neuen Datastore verschieben wollen, dann kann das durchaus ein rechtes geklicke werden. Mit PowerCLI geht das ganz einfach:

Get-VM -Datastore dsOld | Move-VM -Datastore (Get-Datastore dsNew)

So können auch Dutzende von VMs schnell und einfach migriert werden.

Nach der Installation muss nur noch ein Konfigurationfile erstellt werden. Ein einfaches Konfigurationsfile sieht folgendermassen aus:

backup
vcip=VCHost
vcuser=vibe
vcpasswd=secret
sauser=vibe
sapasswd=supersecret
dsset=vmware_volume:172.30.129.100
verbose

Hier mache ich ein Backup, vcip ist die IP oder Hostname des Virtual Centers. Danach folgen der Virtual Center User und sein Passwort. sauser ist der Username der für den Login auf dem Netapp Filer verwendet werden. sapasswort sein Passwort. Mittels dsset sage ich VIBE, dass es von allen VMs, die mind. eine Disk auf dem vmware_volume (NetApp Volume) haben einen VMWare Snapshot macht, danach einen NetApp Snapshot des Volumes. Am Schluss werden die VMWare Snapshots wieder entfernt. Wenn wir dies in ein Textfile vibe-backup.cfg speichern können wir mit

vibe --config vibe-backup.cfg

den Backup Prozess starten. Falls das Volume noch gemirrored wird, können wir dies mit:

vibe --config vibe-backup.cfg --updatemir --miruser remoteuser --mirpasswd supersecret

machen. Dann wird nach dem Snapshot der Snapmirror vorgang auch noch mitgestartet.

In der Zwischenzeit gabs von NetApp eine Warning, dass bei abgestelltem NFS Locking Datenverlust möglich sein. Major Issue!!! (KB Artikel). Also entweder einfrierende VMs oder möglicher Datenverlust. Glücklicherweise gabs von VMWare dann einen Patch. Hier das Vorgehen:

1. Upgrade der VMWare Hosts auf ESX 3.5 Update 1 oder höher
2. Installation des Patches ESX350-200808401-BG
3. NFS locking aktivieren (esxcfg-advcfg -s 0 /NFS/LockDisable)
4. prefvmx.consolidateDeleteNFSLocks = “TRUE” in /etc/vmware/config einfügen

Wir haben zum Glück keine Probleme mit dem abgestellten NFS Locking gehabt. Bei uns läuft jetzt Update 03 seit einiger Zeit ohne Probleme auf den meisten Hosts.

Dies kann mit vimsh gesetzt werden. Nun hat sich die Syntax bei ESX 3.5 geändert:

ESX 3.0.x:

Mit

esxcfg-vswitch –l 

das entsprechende Interface und die dazugehörige Portgruppen-Nummer suchen:
Hier im Bild ist es die Portgruppe mit der Nummer 6.

Dann mit

vimsh -n -e "/hostsvc/vmotion/vnic_set portgroup#"

VMotion aktivieren. In diesem Falle ist es

vimsh -n -e "/hostsvc/vmotion/vnic_set portgroup6"

ESX 3.5.x:

Hier gehts mit

vimsh -n -e "/hostsvc/vmotion/vnic_set vmk#"

Wobei hier die Nummer des VMKernel Ports benutzt wird. Falls nur ein VMkernel Port vorhanden ist ist dies 0, sonst die entsprechende Nummer gemäss der Sortierung von VMWare. Bei unseren Servern haben wir nur eine VMKernel Portgroup, also

vimsh -n -e "/hostsvc/vmotion/vnic_set vmk0"

• Cold Backup
  Hier werden die VMs runtergefahren und dann ein Snapshot erstellt
• Warm Backup
  Die Snapshots werden in Koordination mit VMWare erstellt, damit die Daten konsistent sind.
• Hot backup
  Erstellen der Snapshots auf dem Storage Systeme ohne Koordination mit VMWare

“Cold backup” kommt für uns nicht in Frage. Die VMs runterzufahren und dann zu backup ist nicht praktikabel.

“Hot backup” ist relativ heikel. Es soll zwar Leute geben, die alle Stunde ein Storage Snapshot erstellen und dann argumentieren, dass die Möglichkeit besteht, das ein paar dieser Snapshots inkonsistent sind, aber bei 24 Snapshots im Tag mind. 1 “guter” Snapshot vorhanden sein müsste. Rein rechnerisch. Genau das müsste ist mir aber etwas zu wenig sicher. Falls die dritte Lösung zu komplex oder zu langsam wäre, könnte dies eventuell in Betracht gezogen werden. Sonst eher nicht. Müsste ist mir einfach zu wenig.

Beim “Warm backup” werden die VMs zuerst in einen spezielle “Backup Mode” gesetzt und dann wird der Storage Snapshot erstellt. Mit VMWare ist dieser Vorgang zumindest in der Theorie relativ simpel. Als erstes wird ein VMWare Snapshot erstellt. Dadurch wird sichergestellt, dass auf der VMDK der virtuellen Maschine keine I/O Operationen mehr durchgeführt werden. Diese werden in eine neue Datei geschrieben (wegen dem VMWare Snapshot). Danach kann ein Snapshot auf dem NetApp Storage erstellt werden. Dieser ist konsistent. Am Schluss wir der VMWare Snapshot wieder gelöscht und alle I/O Operationen werden wieder auf die originale VMDK Datei geschrieben. Von NetApp gibts auch ein Script dafür (PDF, Seite 39). Leider löscht dieses alle bestehenden VMWare Snapshots, da es vmware-cmd verwendet. Da wir VMWare Snapshots auch für Testserver benutzten, um die Entwickler zu unterstützen ist dies ein Problem. Ich habe ein kleines Script geschrieben, dass das Perl API von VMWare benutzt und dadurch nur den spezifischen Snapshot löscht. Das Script verbindet sich mit Virtual Center und erstellt nur von den VMs einen Snapshot, die auf einem spezifischen Datastore liegen. Nun ist der ganze Backup Vorgang sehr einfach:

1. VMWare Snapshot mit Script erstellen (stellt sicher, dass keine I/O Operationen auf der VMDK sind)
2. NetApp Snapshot
3. VMWare Snapshot mit Script löschen

Somit können wir konsistente Backups im laufenden Betrieb erstellen. Bei 14 virtuellen Maschinen auf einem ESX Host (Dell PowerEdge 2950 mit 16GB RAM) geht der ganze Vorgang rund 27 Sekunden. Dadurch dass wir NetApp Snapshots fürs eigentliche Backup verwenden, werden nur Deltas gespeichert. Für Desaster Recovery werden diese Snapshots mit Bordmitteln an den zweiten Standort in Zürich und nach Köln gespiegelt.

Das Script (Script für VMWare Snapshots) hat folgende Parameter:

• -datacenter Der Name des Datacenter, in dem die ESX Hosts sind. Muss angegeben werden.
• -datastore Name des Datastore, der gesichert wird. Muss angegeben werden.
• -action {create|delete} Sollen Snapshots erstellt (create) oder gelöscht (delete) werden? Muss angegeben werden..
• -verbose {0|1} Standard ist 0, bei 1 werden noch weitere Infos ausgegeben.
• -snapshotname Standard ist ITOP_NetApp_Snapshot. Dieser Name wird für den Snapshot verwendet. Alle Snapshots mit diesem Namen werden bei der Action delete gelöscht.

• Weiterhin jeden virtuellen Server mit Backup Exec Agent sichern
• Mit VMWare Consolidated Backup (VCB) die Server auf Tape sichern
• Die Server direkt auf dem Storage System mit Snapshots zu sichern

Den Backup Exec Agent weiterverwenden ist gelinde gesagt suboptimal. Der ESX Host wird stark belastet, der Backup Vorgang ist langsam, das Backup Fenster ist kaum einzuhalten.

VMWare bietet mit VCB die Möglichkeit die VM Daten zu sichern, ohne das der ESX Host belastet wird. Dazu muss auf einem weiteren Windows Server VCB installiert werden. Dieser Server muss (Shared) Zugriff auf die Daten haben, die auf dem SAN liegen. Danach wird auf dem ESX Host ein VMWare Snapshot der Virtuellen Maschine gemacht. Der VCB Host kann dann ein konsistentes Backup ziehen. Danach wird der VMWare Snapshot wieder commited. Hier wird zwar der ESX Host nicht belastet, aber die Backup dauern weiterhin lange (da auf Tape) und das commiten des VMWare Snapshots kann bei belasteten Servern einiges an Zeit in Anspruch nehmen.

Da die virtualisierten Server nun vollständig auf dem NetApp Storage liegen, bietet sich die dritte Möglichkeit an. NetApp hat ein Feature (Snapshots) bei dem ein incremental Backup eines Volumes gemacht werden kann. Dieser Vorgang dauert nur Sekunden (normalerweise 2-5sec) und hat keinerlei Performance Impact auf den ESX Host. Auch hier müssen wir entsprechende VMWare Snapshots erstellen, bevor wir mit NetApp Snapshots ein konsistentes Backup ziehen können (Ziemlich verwirrend, da beide Hersteller den Begriff Snapshot verwenden). Auch hier müssen wir den VMWare Snapshot am Schluss wieder löschen und die Änderungen commiten, aber da der Backup Vorgang nur Sekunden gedauert hat, ist der Umfang hier relativ gering.

Für uns war somit die Wahl klar. Wir implementieren die Backups mit Snapshots auf dem NetApp Storage.

In einem weiteren Artikel werde ich die Schritte und Scripts für die Snapshots erläutern.