Nachdem ich vor einiger Zeit schonmal über das Thema geblogged habe mal eine kleine Aktualisierung. Wobei, es gibt nicht wirklich was zu aktualisieren. Ja, natürlich hat sich a bissl was getan. SnapManager for Hyper-V 1.0 P2 ist verfügbar, hat ein paar Bugfixes gebracht aber im wesentlichen keine neuen Features. Da hängen wir leider noch immer sehr stark dem SMVI hinter her. Der ja einerseits die Integration ins OnCommand geschafft hat (als Host Package) und andererseits auch was die Funktionalität betrifft etwas vorran ist.
Trotzdem will ich heute nicht zuviel wemut verbreiten sondern eher mal wieder auf meine Lieblingsbeschäftigung eingehen. Powershell Spielerein die immer wiedermal zu ganz interessanten Scripten führen und vielleicht auch die Phantasie beflügeln.
Heute am Program – SnapManager for Hyper-V oder besser gesagt, ein Script das sich für alle eignet, die sich den Luxus eines SMHV nicht leisten können und dafür mit etwas manueller Arbeit auskommen wollen. Hier mal das Script:
<#
.Synopsis
Create SnapDrive consistent Snapshots of CSV Volumes spezified on the given cluster
.Notes
Letzte Änderung:
2012-02-12 - Chwi: Script erzeugt
2012-03-25 - ChWi: logging hinzugefügt.
2012-04-02 - ChWi: Eventlogsource und Logname parametrisiert
.Description
Dieses Script verbindet sich per WinRM auf die einzelnen Clusterknoten und versucht dort per Get-NAHostDisk alle verbundenen CSVs zu finden. Diese werden anschliessend per SDCLI auf den Owner Nodes gesnappshotted.
Auf den Clusterknoten muss daher das DataOntap PowerShell Module installiert werden. ( zu finden unter https://communities.netapp.com/community/products_and_solutions/microsoft/powershell) - installieren bedeutet in diesem Fall das der ordner DATAONTAP im Verzeichnis c:\Windows\System32\WindowsPowerShell\V1.0\modules kopiert werden muss.
Weiters ist es notwendig das auf jedem Clusterknoten Snapdrive installiert wird sowie auf dem Server der dieses Script ausführt. (sofern das kein Clusterknoten ist)
.Parameter ClusterName
Name of Cluster to be scanned for snapshots
.Example
SnapCSVVolume -ClusterName HyperVCluster
Create snapshots of all CSV Volumes on the cluster 'HyperVCluster'
.Notes
#>
Param( [Parameter(Mandatory=$true)]
[string]$ClusterName,
[Parameter(Mandatory=$false)]
[string]$EventSource="HyperVBackup",
[Parameter(Mandatory=$false)]
[string]$EventLogName="HATAHET")
$ErrorActionPreference
=
"stop"
<################################
# Eventlog Source anlegen falls noch nicht existiert
################################>
if(![system.Diagnostics.EventLog]::SourceExists($EventSource))
{
$strLog
=
[system.Diagnostics.EventLog]::CreateEventSource($EventSource,$EventLogName)
}
$strLog
=
New-Object
System.Diagnostics.EventLog($EventLogName,".")
$strLog.Source = $EventSource
$strLog.WriteEntry("Backup Starting",
[System.Diagnostics.EventLogEntryType]::Information,
1)
$strLog.WriteEntry("Connecting to cluster "
+ $ClusterName
,
[System.Diagnostics.EventLogEntryType]::Information,
1)
Import-Module
DataOntap
$disks
=
Invoke-Command
-ComputerName
$ClusterName
-ScriptBlock {Import-Module
DataOntap; Get-NaHostDisk
-DataOntap
|
? {$_.hostvolumeiscsv -eq $true }}
$strLog.WriteEntry("Received Disks: "
+ $disks
,
[System.Diagnostics.EventLogEntryType]::Information,
1)
# give the snapshot a name
$SnapName
=
Get-Date
-Format
"yyyyMMdd-HHmmss.ffff"
# create Snapshot of each CSV disk in the list
foreach ($disk
in
$disks)
{
$strLog.WriteEntry("Snapping Disk: "
+ $disk.HostDrivePath +
" auf "
+ $disk.ClusterNode , `
[System.Diagnostics.EventLogEntryType]::Information,
1)
&sdcli.exe
snap
create
-m
$disk.ClusterNode -s $SnapName
-D
$disk.HostDrivePath
$strLog.WriteEntry("Connecting to controller: "
+ $disk.ControllerName ,
[System.Diagnostics.EventLogEntryType]::Information,
1)
# connect to the source controller
Connect-NaController
-Name
$disk.ControllerName |
Out-Null
$strLog.WriteEntry("Connecting to controller: "
+ $disk.ControllerName ,
[System.Diagnostics.EventLogEntryType]::Information,
1)
# search for the last snapshot on the volume
$SnapName
=
Get-NaSnapshot
$disk.ControllerVolumeName |
Sort-Object
-Property
AccessTimeDT
-Descending
|
Select-Object
-First
1
-Property
name
$SnapMirror
=
Get-NaSnapmirror
|
? { $_.sourcelocation -imatch $disk.ControllerVolumeName }
# if there is no snapmirror on this volume, we can ignore this.
if ($SnapMirror
-eq
$null)
{
# if there is no snapmirror connection, just ignore this connection
continue
}
$strLog.WriteEntry("snapmirror relation: "
+ $SnapMirror
,
[System.Diagnostics.EventLogEntryType]::Information,
1)
$SnapMirrorDestinationFiler
= ($SnapMirror.Destination).split(":")[0]
# connect to destination controller for snapmirror update
Connect-NaController
-Name
$SnapMirrorDestinationFiler
|
Out-Null
# update snapmirror
$SnapMirrorConnection
=
Get-NaSnapmirror
|
? { $_.SourceLocation -eq $Snapmirror.SourceLocation }
Invoke-NaSnapmirrorUpdate
-Destination
$SnapMirrorConnection.Destination -Source $SnapMirrorConnection.Source -SourceSnapshot $SnapName
}
$strLog.WriteEntry("Backup finished",
[System.Diagnostics.EventLogEntryType]::Information,
1)
Sollte jemand das File selbst wollen – bitte bei mir melden.
Was macht das Script? Naja, einfach gesagt – es verbindet sich auf einen Hyper-V Cluster (gegeben per Parameter) holt sich von dort alle Cluster Shared Volumes sowie deren aktuelle Owner. Danach macht es SDCLI (SnapDrive Command Line Interface) Aufrufe um auf den jeweiligen Owner diese CSV Volumes zu snapshotten.
Ganz am Ende wird dann noch ein Qtree SnapMirror update gemacht. (AUFPASSEN! QTREE SNAPMIRROR! – Volume Snapmirror funktioniert nicht!!!)
Ich hab das mal für einen Kunden gebaut der einerseits Hyper-V Cluster hatte und sich die SMHV Lizenz einfach nicht leisten wollte, trotzdem aber konsistente Snapshots haben wollte. Wobei Konsistent ist in dem Fall etwas dehnbar, da ja die VMs selbst nicht VSS konsistent sind sondern nur Crash Consistent. Es wird aber zumindest das CSV Filesystem VSS snapped. (durch Snapdrive) ich musst leider auch die Erfahrung machen, das in der Vergangenheit sehr oft genau diese "konsistenz" a bissl a Problem ist. Obwohl per hotfix von MS eigentlich fixed sollte es möglihc sein eine VM mit iSCSI Disken (per Software Initiator) zu snappen, geht aber leider eher meistens ned. Die Existenzberechtigung von so manchem Hotfix lässt sich auf die Tatsache reduzieren das er Hotfix ist... (wie bei so manchem Politiker... aber lassen wir das)
Aber zurück zum Thema, das Script macht noch nahezu keinerlei Errorhandling und das wird zukünftig wohl notwendig werden, aber nur kurz noch was ma dafür braucht. Das aktuelle DataOntap Powershell Toolkit mindestens der Version 1.7 auf jedem Hyper-V Host der beteiligt ist, sowie auf dem Server auf dem das Script läuft. Ebenso ist es notwendig Snapdrive auf den Hyper-V Hosts zu haben bzw. Natürlich auch auf dem Host auf dem das Script dann gestartet / gescheduled wird. Das Schedule selbst ist einfach, da muss man wie immer powershell.exe als programm schedulen und dann –file <script> -parameter... angeben. Dann funktionierts eigentlich recht gut.
Wie immer gilt – Ich übernehme keinerlei HAFTUNG für eventuelle Schäden oder nicht funktionierenden Scripte, gelöschte VMs oder sonstige Probleme die diese Zeilen Code verursachen!
So, das eigentlich interessante ist jetzt aber – sie ham an Snapshot und wollen a single File restoren.. aber WIE? (weil das geht zum Beispiel im SMHV auch nur eher bescheiden)
Recht einfach.
Snapdrive – Snapshot verbinden:
- Laufwerksbuchstabe zuordnen und auf dem Laufwerk das entsprechende VHD File suchen
Mit Attach VHD aus dem Disk Management heraus direkt den Inhalt des VHDs als Disk mounten und schon kann man einzelne Files restoren.
Geht in wenigen Minuten und ist behaupte ich mal recht einfach. Da muss ma kein Virtualisierungsprofi sein.
Um aber hier gleichmal ein paar Fragen abzuschmettern –
Wozu brauch ma dann eigentlich noch den SMHV?
Naja – der hat schon noch ein paar Vorteile, so alles im Bereich von Desaster Recovery und automatisches registrieren von VMs beim Restore.. solche Sachen. Sonst müsste man das ja manuell machen.
Wie gehts weiter? Was kommt als nächstes?
Soweit man aktuell ausblicken kann und Windows Server 8 steht ja im Prinzip vor der Tür und die Ankündigungen dazu sind ja auch "KAUM VORSTELLBAR!" worauf ich jetzt aber ned eingehen will – jeder der Vmware ein wenig kennt, kann sich seinen Teil denken. Wichtig ist mir eher – Hyper-V auf Windows 8 kann jetzt dann endlich nicht nur Block Based Storage sondern auch mit SMB 2.2 direkt auf "Netzwerkshares" VHDs (verzeihung, VHDX) ablegen. Womit wir alles was wir heute über SMHV wissen eigentlich wegwerfen können da es sowieso wieder ganz anders wird.. aber mal schaun.
Bis dahin eine Frage geb ich mit auf den Weg und werd ich in Kürze beantworten:
Jetzt machen wir da Snapshots auf den Volumes, aber wer löscht eigentlich die alten Snapshots?
So Long and thanks for all the fish!
Christoph