How to install, configure and integrate NetApp SnapManager SQL in OnCommand

In diesem Artikel möchte ich euch die Einrichtung von NetApp SnapManager SQL näher bringen. Ebenso wird in diesem Artikel die Integration in NetApp OnCommand erläutert, damit automatisiert über eine Protection Policy nach einem erfolgreichen lokalen Backup automatisiert ein SnapVault auf eine Secondary NetApp getriggert wird.

Folgende Konfigurationsschritte werden beschrieben:

1. Anlegen einer Protection Policy in OnCommand
2. Installation SnapManager SQL
3. Initial Wizard SnapManager SQL
4. Konfiguration des OnCommand Datasets für SnapManager SQL
5. Anlegen eines Full Backup Jobs im SnapManager SQL

Folgende Voraussetzungen müssen erfüllt sein:

1. SnapDrive ist bereits installiert und konfiguriert
2. LUNs sind nach Best Practice konfiguriert und in einer passenden Volume/Qtree Struktur, die von SMSQL / OnCommand supportet wird
3. SQL ist installiert und die Datenbanken vorhanden
4. OnCommand User / AD User ist angelegt und passend konfiguriert für das Zusammenspiel OnCommand Core / SnapDrive / SMSQL
5. im OnCommand Core sind bereits die Storages integriert, eine Secondary Provisioning Policy, sowie Secondary Ressource Pools konfiguriert

Verwendete Umgebung:

1. virtualisierter SQL Server 2008 R2 / keine Availability Groups o.ä., geschützt durch VMware HA
2. Anbindung der LUNs per SnapDrive 7.0.x per ISCSI
3. OnCommand Core 5.x auf separatem Server
4. SnapManager SQL soll auf dem gleichen Server installiert und konfiguriert werden

Here we goooo 😉

 

1. Anlegen einer Protection Policy in OnCommand

• am OnCommand Server über die Management Console mit dem eingerichteten User anmelden

• eine neue „Remote Backups Only“ Protection Policy anlegen, in der nur die Vorhaltezeit auf Secondary Site konfiguriert wird (lokale Snapshots und Vorhaltezeit, sowie Transport zu Secondary werden im SMSQL konfiguriert)

• Protection Policy ist angelegt, wird später in der Initialen SMSQL Konfiguration in Schritt 3 benötigt

 

2. Installation SnapManager SQL

• An“docken“ von SnapDrive an den OnCommand Core Server mit dem Serviceuser

• Neustart der SnapDrive Dienste und prüfen der Anbindung an OnCommand

 

• Anstarten der SMSQL Installation

• Eingabe des Lizenzkeys, Auswahl des Installationsverzeichnisses

• SMSQL mit dem entsprechenden Diensteuser konfigurieren

• dem Diensteuser über SQL Management Studio Login Berechtigung, sowie die „sysadmin“ Rolle geben

• SnapDrive ist mit OnCommand Core „verdrahtet“, SMSQL ist installiert, User hat Berechtigungen im SQL

 

3. Initial Wizard SnapManager SQL

• SnapManager SQL Management Console starten

• zu sichernden SQL hinzufügen

• First Time Wizard startet

• Verification Server und entsprechenden Mountpoint angeben (nach erfolgreichem Backup wird Snapshot dorthin gemountet und Datenbank / Logs gecheckt / verified)

• Datenbanken / FileGroups usw. für Migration auswählen (wir haben im Beispiel die Struktur bereits optimal angelegt, somit wird keine Migration benötigt – Next)

• Konfiguration eines SnapInfo Folders für alle Datenbanken

• SnapInfo LUN ist auch bereits vorbereitet / vorhanden und wird einfach nur ausgewählt

• Auswahl, welche Datenbank im OnCommand per Protection Policy gesnapvaultet werden soll und Auswahl der Protection Policy aus Schritt 1

• da wir keine Availability Group o.ä. verwenden, benötigen wir kein Logfile Share

• weitere Einstellungen bei benötigter Datenbankmigration (können wir ebenfalls auf „default“ lassen, da wir bereits die passende LUN / Volume / Qtree Struktur angelegt haben – siehe Voraussetzungen)

• Konfiguration der Abhängigkeit zum iSCSI Dienst

• Konfiguration der Mailbenachrichtigung

• Abschluss des initialen Setups

• Verification, SnapInfo und Mailbenachrichtigung sind konfiguriert, OnCommand Core Dataset wird automatisch im Hintergrund vom SMSQL angelegt

 

4. Konfiguration des OnCommand Datasets für SnapManager SQL

• im OnCommand wurde das Dataset für den SMSQL automatisch angelegt und mit der Protection Policy verknüpft. Es ist jedoch noch keine Secondary Provisioning Policy, sowie ein entsprechender Ressource Pool zugewiesen, auf den die SnapVault Backups laufen sollen
• „Edit“ des Datasets

• Hinzufügen der Secondary Provisioning Policy, sowie des Secondary Ressourcepools

• die Volumes werden automatisch auf dem Secondary System von OnCommand nach angegebenem Namensschema deployed, die SnapVault Beziehung aufgebaut und der initiale Abgleich durchgeführt
• der OnCommand Part ist somit abgeschlossen

 

5. Anlegen eines Full Backup Jobs im SnapManager SQL (optional Log Backup Job)

• im SMSQL definieren wir in den folgenden Schritten ein Full Backup der Systemdatenbanken, sowie der eigentlichen Datenbank. Dazu starten wir unter „Backup“ den „Backup Wizard“ nachdem wir die zu sichernden Datenbanken ausgewählt haben

• Backup Wizard startet

• Datenbanken auswählen

• Back up databases and transaction logs

• weiter mit den ausgewählten Datenbanken

• wir wollen ein „Full Backup“ (in diesem Beispiel wird dieses Full Backup dann später gescheduled auf 13.00 und 22.00 Uhr täglich)

• das Backup lassen wir in die lokale „Daily“ Retention laufen (Ziel dieses Beispiels: Wir machen jeden Tag lokal 2 Snapshots um 13.00 und 22.00 Uhr und heben diese 7 Tage lang auf der Primärseite auf. In diesem Beispiel gibt es keine Weekly Schedules, nur eine Daily Schedule)

• nach einem erfolgreichen Full Backup soll direkt auch ein Transaction Log Backup laufen

• Backup Retention von 7 Tagen einstellen, sowie Up-to-the-minute Restores von der Primärseite sollen 7 Tage rückwärts möglich sein. Alles was älter ist, wird herausrotiert und gelöscht

• nach dem Full Backup soll direkt der „verify“ des Backups erfolgen (somit täglich 2x – nach erfolgreichem Full Backup 13.00 und 22.00 Uhr)

• nach dem Full Backup auf Primärseite, soll direkt ein Transport des Backups auf die Secondary Site per OnCommand gestartet werden (somit ebenfalls 2x am Tag – 13.00 und 22.00 Uhr) und mit der „Daily“ Retention versehen werden (somit 1 Woche Vorhaltezeit auf Secondary – siehe Protection Policy aus Schritt 1)

• Weitere Backup Einstellungen (alle Retentions der Primärseite auf 7 Tage)

• Abschluss der Konfiguration und Übergabe in den SQL Job Manager

• Anpassen des Jobnamens, sowie des Owners (auf den entsprechenden Serviceuser)

• im Beispiel legen wir für den Job 2 Schedules an, die täglich laufen. Eine um 13.00 Uhr und eine um 22.00 Uhr.

• And that’s it. Über den SMSQL Job Manager wird somit täglich um 13.00 und um 22.00 Uhr ein Full Backup des SQL auf der Primärseite getriggert mit „Daily“ Retention (somit 7 Tage rückwärts auf Primärseite), direkt im Anschluss wird sowohl automatisch ein Logfile Backup auf der Primärseite durchgeführt (gleiche Retention), als auch ein Verify. Ebenfalls wird die SnapVault Beziehung direkt im Anschluss aktualisiert und mit der Retention aus der Protection Policy im OnCommand versehen (somit ebenfalls 7 Tage rückwärts auf Sekundärseite)

• optional können weitere Backupschedules eingerichtet werden bzw. die Retention Times angepasst werden (z.B. weitere Full Backups mit „Weekly“ Retentions, auf Secondary mehrere Wochen aufheben o.ä.)

• in den folgenden Schritten möchte ich noch eine Ergänzung zu den Fullbackups um 13.00 und 22.00 Uhr aufzeigen: Jede Stunde von 14.00 – 21.00 Uhr, sowie von 23.00 – 12.00 Uhr wird auf der Primärseite ein Logfile Backup getriggert (vorher muss SMSQL Backup Wizard mit Auswahl „Log“ Backup durchgeklickt werden – keine Screenshots in diesem Artikel)

 

– I wish I could be a Virtual Machine –

 

Benjamin Ulsamer

Senior Consultant & Trainer

teamix GmbH