Bei einem unserer Kunden war der Wartungsvertrag für die NetApp VTL abgelaufen. Eine Verlängerung wäre unverhältnismäßig teuer gewesen. Außerdem war die Kapazität des Systems auch schon an seine Grenzen gestoßen. Da der Großteil der Daten des Kunden auf NetApp Primary Systemen lag oder darauf umgezogen werden sollte, viel die Entscheidung für eine Ablösung auf eine Kombination von 2 NetApp Nearstore Systemen und Advanced File Devices mit einer Bandsicherung für Langzeitsicherungen.

Auf die beiden Nearstore Systeme, die sich an 2 unterschiedlichen Standorten befinden, werden die Sicherungen der Oracle und VMware ESX Backups, sowie die auf den NetApp befindlichen Nutzerdaten mittels des NetApp Produktes SnapVault auf die erste NetApp gesichert. Diese Backup Volumes werden zyklisch mit dem Produkt SnapMirror auf die 2'te Nearstore in einen entfernten Standort gespiegelt. Da der Kunde schon seit einiger Zeit unsere Backup-Lösungen SBint-O und SBint-VM einsetzt, konnte die Sicherung der Oracle Datenbanken und der VMware-ESX-Datastores weiterhin mit NetWorker gestartet und überwacht werden. Die anfallenden Oracle-Archivelog Dateien werden mit SBint-O vom Primary Storage auf die erste Nearstore verdrängt. Jetzt fehlte nur noch eine entsprechende Integration der auf NetApp gehosteten Benutzerdaten. Hierfür gab es jedoch auch bereits eine Lösung unserer SBint-Backup-Tools. Denn auch hierfür kann man mit Hilfe eines NetWorker-Clients und einer zugehörigen NetWorker-Gruppe die Sicherung eines NetApp Volumes von einem Storage-System zum zweiten starten und überwachen. Selbstverständlich werden auch diese Sicherungen in unserer SBint-WWW-Oberfläche visualisiert (siehe auch hier).

Was jetzt noch fehlte, waren eine integrierte Sicherungslösung ganzer virtueller Filer-Umgebungen, sowie eine einfache Möglichkeit die benötigten Volumes und SnapVault- bzw. SnapMirror-Beziehungen automatisiert anzulegen. Jeder virtuelle Filer besitzt mehrere NetApp-Volumes. Diese sollten auf den sekundären Systemen alle die gleiche Aufbewahrungsfristen erhalten. Hierfür wurde unsere SBint-Backup-Lösung kurzerhand um eine entsprechende Funktion erweitert. Ein neuer Parameter in der Konfigurationsdatei definiert welche primären NetApp-Volumes auf einem gemeinsamen sekundären Ziel-Volume gesichert werden sollen. Das Sicherungskommando startet entsprechend bei einer durch NetWorker getriggerten Sicherung den SnapVault-Abgleich aller definierten Volumes auf ein gemeinsames Ziel-Volume. Nach der erfolgreichen Übertragung aller Volumes wird auf dem Nearstore-Volume ein gemeinsamer Snapshot erzeugt, der von unserer Backup-Integration nach der definierten Retentionzeit auch wieder entfernt wird. Jetzt fehlte nur noch ein komfortables Tool, dass die auf den Nearstores benötigten Volumes automatisiert anlegt und die für die Sicherung benötigten Snapshot-Beziehungen konfiguriert. Entstanden ist ein kleines Programm, dass im nächsten Blog beschrieben wird.

Ende 2011 konnten wir die von uns betreuten Backup-Tools bei ihrem Einsatz für Microsoft-Produkte im direkten Vergleich bewerten: EMC NetWorker NMM 2.3, NetApp SnapManager in jeweils aktueller Version und Microsoft DPM 2010. Als eine erste Erkenntnis läßt sich festhalten, dass keines der Tools sich dergestalt hervorhebt, dass es uneingeschränkt zu empfehlen oder abzuraten wäre. Je nach zu sichernden Daten (MS Exchange, MS SQL, Sharepoint, MS DPM, Hyper-V, Systembackup) hat jedes Tool eigene Stärken und Schwächen.

Hier eine kurze Übersicht:
Beginnen wir bei beim Backup von Betriebssystemen: MS DPM und EMC Networker bieten hier gleichermassen bequeme und zuverlässige Unterstützung (siehe auch Blogbeitrag "Networker SaveSet ALL mit NMM 2.3"). NetApp bietet die Option, Betriebssysteme mittels "Open Systems SnapVault Agents" zu sichern, unterstützt im Gegensatz zu Microsoft und EMC jedoch kein Bare Metal Recovery.

Microsoft Exchange kann mit allen drei Tools gesichert und wiederhergestellt werden. Hier ist NetApp Snapmanager for Exchange in Kombination mit dem von Kroll Ontrack lizensierten "Single Item Restore" die leistungsfähigste - jedoch auch die kostenintensivste und in der Einrichtung aufwendigste - Lösung. Die auf NetApp-Storage abgelegten Backups können sehr schnell zugänglich gemacht und mit Single Item Restore Elemente wiederhergestellt werden. Bei Microsoft DPM und Networker EMC erfolgt der Restore einzelner Elemente unter Nutzung einer Wiederherstellungsdatenbank - diese muss jedoch erst einmal mit den Daten aus dem Backup gefüllt und anschließend gemountet werden; der notwendige Reparaturvorgang der Datenbank ist in beiden Tools integriert. NetApp und EMC bieten ein graphisches Interface zur Suche nach wiederherzustellenden Einzelelementen - Microsoft nutzt hier die Powershell, was die Daten besser vor unberechtigter Einsichtnahme schützt.

MS SQL: auch für die Sicherung, die Wiederherstellung und das (temporäre) Clonen von MS SQL-Datenbanken liefert NetApp das leistungsfähigste (und teuerste) Tool. Für die Wiederherstellung stehen die Optionen des Restores der Originaldatenbank ebenso wie Restore auf eine neue Datenbank zur Verfügung. Auch MS DPM bietet diese Möglichkeiten - problemlos auch auf andere MS-SQL-Server. NetApp verfügt darüber hinaus über die Möglichkeit des (temporären) Clonens von SQL-Datanbanken in sehr kurzer Zeit. Networker NMM kann derzeit nur die Originaldatenbank wiederherstellen; diese jedoch ebenfalls auf andere MS-SQL-Server (directed recover).

Sharepoint-Backups stellen allgemein hohe Anforderungen. Mit allen drei Tools können solche Backups ausgeführt werden. MS DPM zeichnet sich hierbei dadurch aus, dass die Konfiguration der Backups am Schnellsten ausgeführt werden konnte und darüber hinaus ein Restore einzelner Elemente möglich ist; jedoch nicht einzelner Versionen. Networker bedarf einer etwas aufwendigeren Einrichtung des Backups und verfügt in der Version 2.3 leider nicht mehr über die Möglichkeit des Sicherns und Restores einzelner Elemente wie die NMM-Versionen vor 2.3. NetApp verfügt mit dem SnapManager for Sharepoint (SMSP) auch auf diesem Bereich über die leistungsfähigste Software - leider kann sie nicht uneingeschränkt empfohlen werden. SMSP ist eine Lizenz der entsprechenden AvePoint-Software, was für hohe Qualität des Produktes spricht. Die NetApp-Version dieser Software ist jedoch stark limitiert und erscheint teilweise unbeherrschbar - wenn Fehler auftauchen, sind diese nicht immer zu lokalisieren und abzustellen. Seit einigen Monaten ist die Version 6.1 des SMSP angekündigt, die dann bis zum SMSP per Powershell bedient werden kann und eine bessere Fehlerdiagnose ermöglichen sollte. Die SMSP-Konfiguration ist vergleichsweise aufwendig (es werden dedizierte Backup-Server empfohlen), bietet jedoch neben einem single Item Restore auf Versionsebene auch integrierte Optionen für die Nutzung von SQL-BLOB-Storage sowie die manuelle und automatische Archivierung von Daten auf NetApp-Storage; auch auf über Jahre blockierten SnapLock-Bereichen.

Die weiteren möglichen Backups wurden von uns nicht ausführlich getestet, daher hier nur eine kurze Einschätzung:
MS DPM kann gesichert werden: durch einen zweiten MS DPM oder mittels Networker NMM. Beide Tools bieten diese Unterstützung explizit an. NetApp kann als Storage für den Betrieb des MS DPM mit SAN-Devices Verwendung finden, die dann natürlich auch durch NetApp-Snapshots gesichert werden können. Eine integrierte Unterstützung fehlt jedoch; auch gelang es uns nicht, auf den SnapShot einer als DPM-Disk-Storage genutzten LUN zuzugreifen: diese Datenträger wurden stets als nicht formatiert gemeldet.

Hyper-V-Umgebungen mit ihren VMs können durch alle drei Produkte gesichert und wiederhergestellt werden; NetApp bietet dafür den Snapmanager for Hyper-V seit zwei Jahren in der Version 1.0 an, d.h im Vergleich zum Snapmanager VI mit geringerem Leistungsumfang.
ESX-Umgebungen werden in den Backup-Konzepten sowohl von NetApp als auch von EMC Networker umfassend unterstützt: NetApp liefert den SMVI (SnapManager for Virtual Infrastructure) inzwischen voll integriert als "Virtual Storage Console for VMware vSphere";  Networker bietet die Konfiguration von Clients als VMWare-VM an.

Preisgestaltung und Fazit: Wer NetApp-Storage einsetzt, sollte auch für das Backup der Applikationsdaten auf NetApp-Produkte setzen, deren Preis in diesem Fall kein Hindernis darstellen darf. Networker NMM ist relativ teuer, bietet sich jedoch für heterogene Umgebungen, in denen Networker als zentrales Backup-Tool eingesetzt wird, an und lieferte gut implementierte Features. Microsoft DPM eignet sich nur zur Sicherung von Microsoft-Systemen: die Software beherrscht deren Backups und Restores perfekt, ist relativ preiswert, schnell  konfiguriert und übersichtlich. Sie ist auch als Ergänzung für "teure" Backup-Umgebungen zu empfehlen. MS DPM geht äußerst sparsam mit den Ressourcen um (Backup-Medien; Netzwerk). Microsofts DPM und besonders EMCs NMM zeichnen sich durch ein eindeutiges, einheitliches und "gut in der Hand liegendes" User-Interface aus.

Viel zu lange her, dass ich hier etwas veröffentlicht habe.
Das hat aber nichts damit zu tun, dass es nichts zu berichten gäbe, sondern dass es einfach zu viel zu tun gibt und ich daher keine Zeit gefunden habe, dies hier zu berichten. Nun sitze ich am Flughafen und warte auf den wegen Nebel verschobenen Flug zur NetApp Insight und habe endlich mal Zeit und Luft diese Zeilen zu schreiben ;-)

Wo fangen wir an?
Unser Snapshot-Backup Entwicklung für Oracle und VMware ist an vielen Ecken vorangetrieben worden.

Folgende Erweiterungen wurden für die Oracle-Sicherung auf NetApp implementiert und sind bereits beim Kunden im Einsatz:

• vollautomatische Recover Funktionalität
  • Recover Until Time
  • Vollständiges Recover (Crash Recover)

Durch diese Erweiterung können NSR-ORA-NDMP Kunden auf unser Produkt wechseln ohne Funktionalität zu verlieren. Im Gegenteil: Sie erhalten zusätzliche Funktionalität (SnapVault Support).

Folgende Erweiterungen wurden für die VMware-Sicherungen auf NetApp implemetiert:

• Parallelisierung einiger Funktionen: Dadurch wurde die Sicherungsdauer zum Teil auf ein Viertel der Zeit reduziert!
• Unterstützung von orignären NetApp Snapshots für das Recovery von Einzeldateien. Hierdurch können mehrere Sicherungsstände pro Tag durch den normale NetApp Snapshot Scheduler generiert werden. Diese Snapshot Sicherungen sind zwar nur Crash-Consistent, können aber für das Recovery einzelner Dateien verwendet werden.

Migrationsunterstützung :

Unterstützung von mehreren gleichzeitigen SnapVault Beziehungen.
Sowohl die Oracle-  als auch die VMware- Lösung erkennen und "updaten" jetzt auch mehrere gleichzeitige SnapVault Beziehungen. Hierdurch kann z.B. der secondary Storage auf einem neuen System angelegt werden und sobald beide Nearstore Systeme den gleichen Snapshot-Stand haben (beide haben Snapshots über "n" Wochen), kann die "alte" Nearstore Verbindung aufgelöst werden.

Volume Backup:

Unterstützung von Volume Sicherungen über unsere Snapshot Integration.
Dieses Feature unsere Snapshot-Backup Integration ermöglicht z.B. die Sicherung eines Multistore-Filers (VFiler) auf eine gemeinsames Nearstore Volume zu sichern und dieses für Langzeitsicherungen anschließend auf Band-Medien zu sichern.

Zwischendurch mal wieder eine andere, trotzdem "liebgewordene" ThematiK: Während der Kurse wird ab und an die soft- und hardwaretechnische Seite der Vorbereitung angesprochen. Die Aussage, alle von Microsoft im Laufe der Zeit angebotenen Tools zu diesem Zweck eingesetzt zu haben, bescherte uns folgenden Auftrag:

Mit Einführung neuer Notebooks wurde unser Kurteilnehmer-Kollege damit beauftragt, eine Möglichkeit des Deployments für Windows 7 und je nach Arbeitplatz benötigter Softwarepakete zu finden und umzusetzen. Anfangs nur für die eigene Abteilung mit ca. 200 Notebooks gedacht wurde über Nacht daraus die Aufgabe, das Deployment weltweit umzusetzen: also verschiedene Sprachpakete und Gebietsschemen sowie die Tatsache zu berücksichtigen, dass einige Standorte nur aüßerst schmalbandig ans Firmennetz angebunden sind und nicht über einen Administrator verfügen. Neben Notebooks sollen auch verschiedene Desktop-Konfigurationen ausgerollt werden. Geschätzte Clientanzahl: 1200-1800. Diese werden nicht zeitgleich geliefert und eingerichtet, sondern in Stückzahlen zwischen fünf und 20. An eine spätere Softwareverteilung neuer Produkte und Inventarisierung wurde dabei nur perspektivisch gedacht; Updates werden per WSUS bereitgestellt und die Konfiguration der Oberflächen und Sicherheitseinstellungen erfolgt bereits zur vollsten Zufriedenheit per Gruppenrichtlinien.

Damit war der Auftrag zumindest grob umrissen.

Zwei Tage wurden für die Vor- und Nachbereitung eingeplant und drei weitere Tage, um eine Einweisung vorzunehmen, die Möglichkeiten des MDT (Microsoft Deployment Toolkit) vorzustellen und eine Abgrenzung zu ergänzenden Produkten (WDS, SCCM, USMT, MAP) vorzunehmen. Nach dem Aufbau einer MDT-Umgebung am ersten Tag und der Erfassung des tatsächlichen Bedarfes kamen wir zu der Erkenntnis, dass MDT alle Anforderungen erfüllt. Vorteilhaft ist, dass vom notwendigen Deployment-Server abgesehen keine weiteren Kosten entstehen und die Lösung später um den SCCM erweitert werden kann, der zu relativ moderaten Kosten die Softwareverteilung und Inventarisierung vornehmen kann.

Nachdem am ersten Tag des Workshops eine Deploymentumgebung auf unserem mitgebrachten Testserver eingerichtet und ausprobiert wurde, haben wir am Folgetag den später beim Kunden zu nutzenden Server aufgesetzt. Hierbei wurden schon wichtige Erkenntnisse des ersten Tages eingearbeitet und weitere gewonnen: Der Deployment-Server des Kunden arbeitet mit zwei getrennten Deployment-Shares, die übrigens beide auf NetApp-NAS-Storage abgelegt sind. Das erste Share steht dabei den Mitarbeitern in der Zentrale zur Verfügung, wo auf einer sehr schnellen (ebenfalls auf NetApp betriebenen) VMWare-Umgebung das Einrichten der Grundinstallationen und das Abziehen der später auszurollenden Images erfolgt. Hier können alle benötigten Paketierungen vorab erstellt werden. Als Treiberpaket wird lediglich der Treibersatz für die Virtualisierungsumgebung benötigt. Die Grundinstallation benötigt dabei ca. 8 min; das Abziehen eines fertigen Images je nach Größe ca. 12 bis 30 min. Dazwischen ist noch die Zeit zum Aufspielen der Softwarepakete einzuplanen (z.B. Office 2010 ca. 10 min).

Die auf diese Art und Weise sehr schnell in der Virtualisierungsumgebung erstellten Referenzsysteme werden anschließend in das zweite Share übernommen und hier für das Ausrollen angeboten. Berechtigt ist hier der Personenkreis der für die eigentliche Installation Zuständigen - nur mit Leserechten.

MDT ist hier eine große Hilfe: in den Steuerfiles customersettings.ini und bootstrap.ini des Deploymentshares können sowohl die Infos zum Hinzufügen des Clients zur Domain als auch die Zugriffskennungen zum Zugriff auf das DeploymentShare "unsichtbar" hinterlegt werden. Außerdem lassen sich bestimmte Werte, die für den Bereich immer dieselben sind, vordefinieren. Dies betrifft beispielsweise Tastaturbelegung, Länderkennung, Name/Organisation und lokale Passwörter. Stellt man dem MDT noch eine SQL-Datenbank zur Verfügung, so lassen sich diese Einstellungen standortbezogen (z.B.nach Default Gateway) oder maschinenbezogen (um Treibersätze automatisch zuzuweisen) granular einstellen. Für jeden verwendeten Hardwaretyp wird mittels Treiber-CD sehr schnell ein Satz der benötigten Treiber erstellt. Das Ausrollen der Images erfolgt dann so, dass im Image keine hardware-spezifischen Treiber enthalten sind (entfernt MDT automatisch) und erst im Moment der "Image-Installation" das richtige Treiberpaket hardwarespezifisch angeboten wird. Ähnlich kann mit Sprachpaketen umgegangen werden.

Während unseres Workshops wurden verschiedene Notebooks betankt. Dabei stand ein 100MBps-Netzwerk zur Verfügung. Die Zeiten vom Anstecken des Bootmediums bis zum Abschluss der Installation incl. Verarbeitung aller Gruppenrichtlinien betrugen zwischen 40 und 60 min; auch für die Clients, die neben Office die beim Kunden benötigte Branchensoftware enthielt. Der Installierende muss nur noch den Namen des Zielrechners eingeben und hat einige Dialogfelder mit OK zu bestätigen oder per Auswahlfeld zu ändern. Damit war schon mal ein großes Ziel des Workshops erreicht.

Die Imageentwicklung und -erfassung erfolgt sehr schnell virtuell; das Ausrollen danach auf die Physik: V2P.

Der dritte Tag des Workshops widmete sich vor allem der Frage des Ausrollens in Standorten mit schlechter Netzwerkanbindung. MDT verfügt über die Möglichkeit, Offline-Medien bereitzustellen. Dabei sollten einige Dinge beachtet werden: das ursprüngliche Installationsmedium sollte immer zum Bestandteil des Offline-Images gemacht werden (damit wird das Image größer), alle nicht benötigten Pakete sollten bei Erstellung des Offline-Images deaktiviert werden (um das Image klein zu halten) und die Vorgehensweise der Erstellung eines bootfähigen USB-Laufwerks sollte bekannt sein.

- Schnellanleitung zum Anlegen eines bootfähigen USB-Devices für Windows: Device anstecken -> "diskpart" -> "list disk" zur Ermittlung der Disk-Nummer -> "select disk" [Disk-Nummer] -> "clean" um alle Daten zu löschen -> "create partition primary" -> "active" -> "format fs=ntfs quick" und anschließend den Inhalt des Offline-Installationsmediums auf das USB-Device per "robocopy [Quelle] [Ziel] /mir" oder "xcopy [Quelle] [Ziel] /s /e /f" übertragen; Zielcomputers von USB booten. -

Unsere Offline-Images waren zwischen 8 und 14 GB groß; ist man dabei unvorsichtig, so kommen auch mal über 30 GB zusammen. Das Ausrollen vom USB Device geht schneller als das übers 100 MBps-Netzwerk, es belastet das Netz nicht, benötigt jedoch Netzwerkanbindung, um den Client in die Domain aufzunehmen. Hier wurde entschieden, dass die Kosten für einige 16GB oder 32GB große USB-Sticks aufgebracht werden, um prinzipiell die Nutzung von Offline-Medien zu favorisieren.

Der MDT-Server konfiguriert sich leider nicht ganz von selbst; der Workshop wurde insgesamt als nützlich, effektiv und zielführend eingeschätzt - kein Wunder, hätte ein kurz davor vorgestelltes Drittanbietertool doch eine sechsstellige Summe gekostet bei vergleichsweise komplizierterer Handhabung.