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.

ifconfig vifname alias ip-address

also

ifconfig vif0 alias 192.168.5.100 netmaks 255.255.255.0

Nicht vergessen darf man, diese Zeile auch in die rc Konfigurationdatei auf dem File einzutragen, damit die Änderung auch einen Reboot übersteht.

options telnet.enable off

Telnet deaktivieren.

Filer A (FAS250) ist langsam voll. 1 Volume muss auf einen anderen Filer verschoben werden

Lösung:

Snapmirror! Ganz einfach.

Auf Filer A muss ich Filer B zuerst für Snapmirror “berechtigen”

options snapmirror.access host=filerB

Dann erstelle ich auf Filer B das Volume

vol create data1 aggr0 250g

Das Volume stelle ich dann auf restricted

vol restrict data1

Dann starte ich den Snapmirror (immer noch auf filerB)

snapmirror initialize -S filerA:data1 filerB:data1

Ich erstelle keinen Schedule, da ich die Daten ja nur einmal rüberkopieren muss (ok, zweimal für den Sync am Schluss)

Überwachen kann ich den Snapmirror status mit

snapmirror status

Snapmirror is on.
Source                Destination           State          Lag        Status
filerA:data1        filerB:data1        Uninitialized  -          Transferring  (32 GB done)

Dann einfach warten bis initial Snapmirror durch ist. Während dieser Zeit ist das Volume auf dem Source Filer natürlich online und kann weiterhin gebraucht werden. Nach dem der inital Snapmirror durch ist stelle ich sicher, dass auf dem Volume nicht mehr gearbeitet wird. Z.b. in dem ich den CIFS Share entferne oder die iSCSI Sessions terminiere. In meinem Falle ist es ein CIFS Share, der entfernt wird. Danach mache ich ein letztes Update mit (auf filerB):

snapmirror update -S filerA:data1 filerB:data1

Danach kann ich das Ursprungsvolume auf filerA offline setzen:

vol offline data1

Dann den snapmirror “brechen” (auf filerB):

snapmirror break data1

Da ich den Snapmirror nicht mehr mit dem ursprünglichen Volume resyncen will (das werde ich nahher löschen) und ich vielleicht das Volume in Zukunft vergrössern will setze ich das fs_size_fixed Flag auf off (filerB):

vol options data1 fs_size_fixed off

Nun muss ich nur noch eventuelle CIFS shares, NFS exports oder iSCSI targets neu erstellen. Das alte Volume kann ich dann löschen.

Falls das Volume sehr gross ist und ein initial mirror sehr lange geht (z.B. mehrere Stunden oder Tage), dann kann man natürlich vor dem letzten Update noch mehrere snapmirror updates fahren, während das ursprüngliche Volume immer noch weiterläuft. Dadurch wird der Lag (d.h. der Zeitliche Abstand, um den der Mirror dem Original hinterher hinkt) immer kleiner, so dass ein letzter snapmirror update am Schluss nur noch Sekunden oder ein paar Minuten dauert, anstelle von Stunden.

dfm host diag filerA.local

C:\>dfm host diag filerA.local

Network Connectivity
IP Address             192.168.0.100
Network                None
DNS Aliases            filerA.local
DNS Addresses          192.168.0.100
SNMP Version in Use    SNMPv1
SNMPv1                 Failed: Timeout (Unknown error)
SNMP Community         public

eingeben (anstelle von filerA.local natürlich euren Hostnamen für den Filer). Dann sieht man sofort was nicht geht. Meistens ist der Zugriff via SNMP nicht möglich, weil z.B. SNMP nicht aktiviert ist. Das kann man auf dem Filer folgendermassen prüfen:

filerA> options snmp
snmp.access                  legacy
snmp.enable                  off

Hier sieht man, dass snmp nicht aktiv ist.

filerA> options snmp.enable on

Dies aktiviert snmp, was man auch überprüfen kann

filerA> options snmp
snmp.access                  legacy
snmp.enable                  on

Nun sollte ein hinzufügen klappen.

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.

Zuerst schalten wir NDMP mit ndmpd on ein. Danach können wir mit ndmpd status sehen, dass NDMP auch wirklich läuft:

Nun stellen wir noch ein, dass wir mittels Username und Passwort auf NDMP zugreifen wollen:

Wir müssen sicherstellen, dass NDMP Version 4 verwendet wird:

Falls dies noch nicht der Fall ist können wir dies explizit setzen:

Nun können wir den Filer als NDMP Host hinzufügen. Dazu gehen wir in der BackupExec Konsole auf Tools -> Device and Media Operations -> Add NDMP Server

Im neu erscheinenden Fenster geben wir den Hostname oder IP des NetApp Filers an und den Account mit dem BackupExec sich verbinden soll:

Das war’s auch schon. Nun können wir bei Backups oder Backup Selection Lists den NetApp Filer auswählen und Volumes, Qtrees oder einzelne Files sichern:

Ich hatte das Problem, dass ich bei einem R200er Filer einen neuen NFS Eintrag ins exports file geschrieben habe. Das ganze von einem Windows Client aus, c$\etc\exports geholt und mit einem vernünftigen Editor (so von wegen Unix <-> Windows mode), sprich Notepad++, den Eintrag eingefügt, gespeichert und auf dem Filer

exportfs -a

ausgeführt. Der NFS export wurde aber nicht angezeigt. Nach einer Weile hab ich dann das Problem gefunden:

Am Schluss der letzten Zeile muss unbedigt eine neue Zeile (LF) eingefügt werden, sonst wird der letzte Eintrag ignoriert.

Steht sicherlich irgendwo in der Dokumentation. Wusst ich jetzt aber nicht mehr und hat mich 1h gekostet.

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.

• 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.