Hochverfügbarkeit mit AlwaysOn für die SSISDB

Hochverfügbarkeit mit AlwaysOn für die SSISDB
Stefan Grigat, 13.06.2015
Speaker Bio
Stefan Grigat
 BI-Consultant bei ORAYLIS GmbH
 MCSE & MCSA für SQL Server 2008 und 2012/2014
 Über 8 Jahre praktische Anwendung des SQL Servers
 Entwicklung und Betrieb von SQL Server 2000 – 2014
 Blog: http://blog.oraylis.de/author/sgrigat/
2
ORAYLIS Überblick
 Spezialist für Big Data und Business Intelligence-Lösungen
 Gegründet 1999
 70 Mitarbeiter
 Full-Service Business Intelligence
 Plan -> Build -> Run
 ORAYLIS ist Top BI Partner von Microsoft
 Outstanding HP and Microsoft Frontline Partner of the Year 2012 (Data Management)
 Black Belt Partner
 APS Premium Partner
 Shortlist Partner Microsoft Consulting Services (MCS)
 Silber Partner von Tableau Software
Agenda
Hochverfügbarkeit
AlwaysOn
Besonderheit SSISDB
SQL Agent Jobs für Wiederanlauf nach Failover
Ziele der Hochverfügbarkeit
 System bleibt nutzbar, auch bei Ausfall einzelner Komponenten
 Vermeidet „Single Point of Failures“
(Hdd, Strom, Netzwerk, Rechenzentrum)
 Service Level Agreements (SLA) können eingehalten werden
Gemäß dem Anwenderwunsch:
Das System steht immer und ohne Unterbrechung zur Verfügung
und zwar Ende-zu-Ende.
5
Abgrenzung Hochverfügbarkeit und DesasterRecovery
 Ein Desaster Recovery beinhaltet immer den Einsatz eines alternativen Standorts
 Das System muss mit kleinst-möglichem Datenverlust, ggf. aber nicht sofort, wieder nutzbar
gemacht werden.
 Eine Hochverfügbarkeitslösung deckt den Ausfall einzelner, abgesicherter Komponenten ab, ein
Desaster-Recovery stellt den Dienst auch nach einem GAU und dem Ausfall vieler Komponenten
wieder zur Verfügung.
 Hochverfügbarkeitslösungen sichern einen Service mit technischen Mitteln ab
 Desaster-Recovery-Lösungen sichern viele Services ggf. auch mit organisatorischen Mitteln ab
 Hochverfügbarkeitslösungen können (müssen aber nicht) auch als Desaster-Recovery-Lösung
aufgebaut sein
6
Hochverfügbarkeitslösungen des SQL Servers
Seit Version
Automatischer Failover
Lizenz (SQL 2014)
Datenredundanz
Mindest-Anzahl Instanzen
Absicherung gegen
Secondary Lesezugriff
möglich
Anzahl
Systemdatenbanken
(User/Job-Management)
Datenstände synchron
Einschränkungen
Log Shipping
2000
Nein
Standard
Mirroring
2005
Ja/Nein
Standard
Ja
2
Ausfall X
Datenbank(en)
inkl. deren Storage
Ja
3/2
Ausfall X
Datenbank(en)
inkl. deren Storage
Ja
Nein
2
(mehrfach und
manuell)
Nein
Kein Schutz der
gesamten Instanz
Kein Schutz der
Systemdatenbanken
Clustering
2005
Ja
Standard
(max.2 Server)
Nein
2
Ausfall 1 SQL
Instanz
Storage muss
erhalten bleiben
Nein
2
1
(mehrfach und
(nur einmalig)
manuell)
Ja
N/A
Kein Schutz der Kein Schutz gegen
gesamten Instanz Ausfall des Storage
Kein Schutz der
Systemdatenbanken
Always-On
2012
Ja
Enterprise
Ja
2
Ausfall X
Datenbank(en)
inkl. deren Storage
Ja
2
(mehrfach und
manuell)
Ja
Kein Schutz der
gesamten Instanz
Kein Schutz der
Systemdatenbanken
7
Architektur AlwaysOn
Virtual Cluster
Name:SQLAlwaysOn01
IP: 192.168.182.104
Client
192.168.182.021
AlwaysOn-Db-Connect
Name:VSqlServer
IP:192.168.182.110
Public
192.168.182.0/24
DomainController
Name: Win12DomainController
IP 192.168.182.101
Heartbeat
192.168.181.0/24
Primary DB Server
Name: SqlServer01
IP: 192.168.182.102
Secondary DB Server
Name: SqlServer02
IP: 192.168.182.103
8
Two-Phase Commit
Client
Public
192.168.182.0/24
Primary DB Server
Secondary DB Server
3. Execute Tran
5. Execute Tran
4. Send Commit
9
Technische Voraussetzungen für AlwaysON
 SQL-Server zu einem Windows-Cluster verbunden (Shared Quorum Disk optional)
 Port 5022 in der Firewall geöffnet für die „Heartbeat“-Kommunikation des SQL-Dienste
 Der selbe SQL Server Service Account in allen Instanzen
 Alle beteiligten SQL Server Instanzen müssen mit der selben Collation installiert sein
 Datenbanken müssen im Full-Recovery-Mode laufen
 No AutoClose, No Read-Only, No System-Database, No Single-User
 FileShare für Backup/Restore beim Aufbau
 https://msdn.microsoft.com/en-us/library/ff878487.aspx
10
Demo
Aufbau AlwaysOn für eine User-Datenbank
11
Wiederanlauf eines SSIS-Pakets
 Grundsätzlich besitzen beide/alle Instanzen lauffähige Kopien der SSIS-Pakete
 ABER: Nur eine der beteiligten Instanzen besitzt die Read/Write-Rechte
 Und: Wo im Ablauf muss nach einem Abbruch wieder gestartet werden?
1. Möglichkeit: Eigenes Tracking mit Status-Tabellen der Verarbeitungsschritte
 Woher weiß die zweite Seite, dass das Paket nicht noch mitten im Data-Flow-Task ist
 Menschliche Fehler möglich (Nachts, unerwarteter Failover, Status-Tabelle ggf.
anpassen, Job auf der richtigen Seite starten…)
2. Möglichkeit: Checkpoint Datei auf gemeinsamem Share
+ Share ist für den Aufbau von AlwaysOn bereits vorhanden
+ Nur ein Job/Prozess bekommt den Lock auf die CheckPoint-Datei
+ Leicht erweiterbar, bei wachsender ETL-Strecke
12
Demo
Wiederanlauf ETL-Paket mit Checkpoint-Datei
13
SSISDB
SSIS Catalog
 Eingeführt mit SQL Server 2012
 „quasi“ Systemdatenbank
 Enthält die SSIS-Pakete, Konfigurationen, Logs, Berechtigungen
 Stellt Views und Tabellen über die Inhalte abfragbar per SQL bereit

https://msdn.microsoft.com/de-de/library/hh479588.aspx
14
Demo
Create SSIS-Catalog, Enable AlwaysOn für die
SSISDB
15
Master-Key Fehler?!
16
Verschlüsselungshierarchie
17
Demo
Was passierte beim Anlegen des SSIS-Catalog?
18
DynamicManagementViews für AlwaysON
19
DynamicManagementViews für AlwaysON
20
Demo
Failover-Erkennung und Wiederanlauf
21
Weiterführende Links
 Technische Hochverfügbarkeits-SQL-Server Lösungen:
 https://msdn.microsoft.com/de-de/library/ms190202.aspx
 SSIS-Catalog
 https://msdn.microsoft.com/de-de/library/hh479588.aspx
 AlwaysOn
 https://technet.microsoft.com/de-de/sqlserver/gg490638.aspx
 ORAYLIS
 http://http://www.oraylis.de/home
 http://blog.oraylis.de/author/sgrigat/
22
Fragen?
23