Söderlein (Ähnlichkeiten mit politischen Personen sind ungewollt und rein zufällig in Betracht des späten Abends
):
Test mehr oder weniger erfolgreich, hat einiges klargestellt, aber noch mehr Fragen aufgebracht. Hier nun der Bericht (wäre eine Super Blog-Eintrag, aber wer braucht schon nen Blog, wos doch das vmware-forum gibt
):
(Das ganze ist etwas länger, rentiert sich aber zum Lesen, am Ende gibt’s was zu gewinnen!)
Testziel: -m hotadd für vcbMounter ausprobieren
Testaufbau: 4*ESX 3.5.0 ohne Patsches, also mit Stand von vor fast nem Jahr. Verteilt in zwei DRS/HA-Cluster a zwei ESX. Alle ESX haben Zugriff auf die gleichen zwei FC-SAN-VMFS-Datastores.
Was man braucht:
- Eine zu sichernde VM (hier mit Namen "demo1"): W2k3, mit ein paar Beispiel-daten
- eine W2k3-VM, die als VCB-"Proxy"-VM dient (hier mit Namen "vcbtesta", mit VCB 1.5 installiert (janz frisch runtergeladen)
- eine Helper-VM (laut der 15 Zeilen offizieller Doku
) mit Namen "vcbtesta(VCB-HELPER)" (Klammern im VM-Namen, immer super!). Ohne virtuelle Platte, ohne OS, ohne alles!:?:
Dann geht’s los:
2* putty auf den ESX, ins Verzeichnis der zu sichernden VM demo1, mit
watch --interval=1 'ls -ahl'
beobachten, was los ist
zweiter putty im Verzeichnis vom vcbtesta, bzw. der Helper-VM (um rauszukriegen, für was die überhaupt da ist)
In der VCB-Proxy-VM wird in der Kommandozeile das Backup gestartet, mit:
vcbMounter -h mein-vc-server -u lieblingsadmin -p wieimmer -a:name demo1 -r c:\backuptarjet -t fullvm -m hotadd
(alles wie sonst, nur der letze Parameter is neu)
Dann geht’s ans beobachten im VC.
Erst wird ein Snapshot für demo1 erstellt (soweit so gut, das war zu erwarten)
Dann wird ein "Create Linked Clone" für demo1 erstellt (OHA, das ward noch nie dar im VC)
Dann folgen ein paar "Reconfigure VM"-Tasks für den vcbtesta
Das Backup läuft durch (Anzeige wie beim "normalen" VCB)
Am Ende wieder ein paar Reconfigure-Tasks und der Snapshot für demo1 wird gelöscht.
Lief auf anhieb durch, ich hab im Backuptarjet-Verzeichnis ein Full-Backup der VM.
Beim Näheren Betrachen passiert folgendes:
Der vcbMounter stößt übers VC den Snapshot für die zusichernde VM an. Dann erstellt er im Verzeichnis der VCB-HELPER-VM einen linked-clone (sieht man auf der kommandozeile recht schön die Deltas)
.
diese Delta-Datei wird dann in den vcbtesta gemountet als zusätzliche Platte (hot-add, is ja möglich), und der vcbMounter IN der VM kann auf die Daten der demo1-Platte zugreifen.
Das sieht man sogar, wenn man schnell ist, in der Datenträgerverwaltung in der vcb-VM…
Am Ende des Backups wird die gemountete Delta-Platte wieder aus der vcb-VM entfernt!!!
Dieser HOT-REMOVE ist sonst eigentlich nicht möglich!!!
Dann wird der linked-clone gelöscht, und der Snapshot der zu sichernden VM wieder commitet.
Klingt eigentlich ganz logisch, macht automatisch das, was sonst über viiiiel Handarbeit schon möglich gewesen wäre (mit Ausnahme des HOT-REMOVE).
Beim Nachdenken während des Backups kommen folgende Vorteile dieser Variante:
- Ich brauch keinen W2k3-Backup-Proxy physikalisch, der auf meine VMFS-LUNs zugreifen kann (da sollen schon so manche partitionen durch unvorsichtiges Initialisieren ins Nirvana verschwunden sein…)
- Das ganze funktioniert auch, wenn die beteiligten VMs auf verschiedenen ESX laufen (hab ich ausprobiert). Sie brauchen nur alle Zugriff auf die VMFS-Partition. Damit kann ich die Backup-Last vom produktiv-ESX nehmen, wie beim "herkömmlichen" VCB-auch.
- Wenn ich als Backup-Ziel in der vcb-VM ein RDM nehme, ist das eine super-Architektur für ein 2disk-2tape-Backup in zwei Stufen….
- Performance: Konnt ich nicht wirklich testen, bei mir ist das Storage selbst der Bottleneck gewesen. Aber da die platte direkt in die Backup-VM gemountet wird, geht nix übers Netz, gelesen wird direkt von der VMFS-Partition.
Die Fragen, die aufkamen:
- ich bekam nen Fehler, wenn die zu sichernde VM platten auf verschiedenen Datastores hatte (super, da sind wir wieder back bei VCB 1.0.x…
)
- RDMs funktionieren wie erwartet, bei virtual Mode klappts, beim physikal Mode natürlich nicht.
- Wie wird die Helper-VM identifiziert, nach VM-Name, oder geht’s nur um das Verzeichnis im Datastore?
- Warum brauchts überhaupt die Helper-VM, die wird nie gestartet während des Vorgangs? (ich tippe mal, die brauchts, um über die API die linked-clones anzulegen)
- Seit wann gibt’s linked-clones auf dem ESX (vom labmanager mal abgesehen)?
- Seit wann gibt’s hot-removable virtuelle Platten (geht über den Client manuell gar nicht)?
- Was ist ein geeignetes Ziel fürs Backup (wieder in ne virtuelle Platte der vcb-VM macht recht wenig sinn)?
Bei der letzen Überlegung wird der Gedanke an Tape-laufwerke/libraries, die man in die VCB-VM-mounted, wieder aktuell! Und wenn man an NPIV denkt, wenn in Zukunft die VCB-VM über nen virtuellen HBA direkt ne FC-Library ansprechen kann, das zaubert einem doch ein Lächeln ins geplagte Backup-Planer-Gesicht.
Dass dabei alles übers SAN geht, und gar keine Netzwerkverbindung im Spiel ist, zieht die Mundwinkel bis zum Ohrläppchen
Genug geträumt, zurück zum Heute:
Wie zur Hölle schaffts der vcbMounter, übers VC einen "Create Linked Clone"-Task anzustoßen????
Wer mir da die entsprechende API-Funktion nennen kann, dem spendier ich im Februar auf der VMworld-Europe-Party in Cannes ein (oder gerne auch zwei) Bier(e) !!
(gerne auch Wein, franz. Bier ist verständlicherweise nicht jedermanns Geschmack
)
So, dass war wohl der längste meiner Beiträge hier im Forum, bis jetzt! Wenn ich dazukomm, gibt’s dazu irgendwann noch ein Screencast-Video. In der Hoffnung, dass es bald mehr Erfahrungsberichte und Dokumentation seitens VMware dazu gibt. Die Idee erscheint auf jeden Fall sehr vielversprechend….
Viele Grüße, und nen schönen verbleibenden Restabend noch!
Jörg
