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

SMSQL-Install-0000001

SMSQL-Install-0000002

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

SMSQL-Install-0000003 SMSQL-Install-0000004 SMSQL-Install-0000005 SMSQL-Install-0000006 SMSQL-Install-0000007 SMSQL-Install-0000008 SMSQL-Install-0000009 SMSQL-Install-0000010

SMSQL-Install-0000011

  • 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

SMSQL-Install-000003 SMSQL-Install-000004 SMSQL-Install-000005

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

SMSQL-Install-000006 SMSQL-Install-000007 SMSQL-Install-000008 SMSQL-Install-000009

  • Anstarten der SMSQL Installation

SMSQL-Install-000010 SMSQL-Install-000011 SMSQL-Install-000012

  • Eingabe des Lizenzkeys, Auswahl des Installationsverzeichnisses

SMSQL-Install-000014 SMSQL-Install-000015

  • SMSQL mit dem entsprechenden Diensteuser konfigurieren

SMSQL-Install-000016

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

SMSQL-Install-000017SMSQL-Install-000018 SMSQL-Install-000019 SMSQL-Install-000020 SMSQL-Install-000021

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

3. Initial Wizard SnapManager SQL

  • SnapManager SQL Management Console starten

SMSQL-Install-000022

  • zu sichernden SQL hinzufügen

SMSQL-Install-000023 SMSQL-Install-000024 SMSQL-Install-000025

  • First Time Wizard startet

SMSQL-Install-000026 SMSQL-Install-000027

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

SMSQL-Install-000028

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

SMSQL-Install-000029

  • Konfiguration eines SnapInfo Folders für alle Datenbanken

SMSQL-Install-000030

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

SMSQL-Install-000051

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

SMSQL-Install-000052

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

SMSQL-Install-000053

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

SMSQL-Install-000054

  • Konfiguration der Abhängigkeit zum iSCSI Dienst

SMSQL-Install-000055

  • Konfiguration der Mailbenachrichtigung

SMSQL-Install-000056 SMSQL-Install-000057

SMSQL-Install-000058 SMSQL-Install-000059

  • Abschluss des initialen Setups

SMSQL-Install-000060 SMSQL-Install-000061 SMSQL-Install-000062 SMSQL-Install-000063

  • 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

SMSQL-Install-000064

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

SMSQL-Install-000065 SMSQL-Install-000066 SMSQL-Install-000067 SMSQL-Install-000068 SMSQL-Install-000069 SMSQL-Install-000070 SMSQL-Install-000071

  • 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

SMSQL-Install-000072

  • Backup Wizard startet

SMSQL-Install-000073

  • Datenbanken auswählen

SMSQL-Install-000074

  • Back up databases and transaction logs

SMSQL-Install-000075

  • weiter mit den ausgewählten Datenbanken

SMSQL-Install-000076

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

SMSQL-Install-000077

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

SMSQL-Install-000078

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

SMSQL-Install-000079

  • 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

SMSQL-Install-000080

SMSQL-Install-000081

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

SMSQL-Install-000082

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

SMSQL-Install-000083

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

SMSQL-Install-000084 SMSQL-Install-000085 SMSQL-Install-000086 SMSQL-Install-000087 SMSQL-Install-000088

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

SMSQL-Install-000089

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

SMSQL-Install-000099

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

SMSQL-Install-000100

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

SMSQL-Install-000101 SMSQL-Install-000102

– I wish I could be a Virtual Machine –

Benjamin Ulsamer