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-000017

SMSQL-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

Senior Consultant & Trainer

teamix GmbH

Benjamin Ulsamer

Benjamin Ulsamer ist seit Januar 2011 für die Firma Proact Deutschland GmbH tätig. Er startete als Senior Consultant & Trainer und war Teamlead im Bereich Virtualisierung. Im Oktober 2015 wurde er zum Manager Professional Services Region South ernannt. Seit Juni 2017 ist er verantwortlich für die IT-Ausbildung. In den Jahren 2015, 2016 und 2017 hat er für sein Engagement bzgl. Blogging & Wissensvermittlung von VMware die Auszeichnung zum vExpert erhalten. Seit 2021 ist er zudem mit verantwortlich für das Marketing von Proact.

 
Kommentare

Hallo und Danke für die anschauliche Beschreibung. Eine kurzes Beispiel für einen restore (inkl. Kombination aus vollbackup und logs) würde den Artikel komplettieren.

Würde mich freuen, Danke!

Hinterlassen Sie einen Kommentar an Thomas