Hochverfügbarkeit mit AlwaysOn für die SSISDB. Stefan Grigat,

Größe: px

Ab Seite anzeigen:

Download "Hochverfügbarkeit mit AlwaysOn für die SSISDB. Stefan Grigat,"

Gert Haupt
vor 6 Jahren
Abrufe

1 Hochverfügbarkeit mit AlwaysOn für die SSISDB Stefan Grigat,

2 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 Blog: 2

ORAYLIS Überblick Spezialist für Big Data

3 ORAYLIS Überblick Spezialist für Big Data und Business Intelligence-Lösungen Gegründet 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

4 Agenda Hochverfügbarkeit AlwaysOn Besonderheit SSISDB SQL Agent Jobs für Wiederanlauf nach Failover

5 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

6 Abgrenzung Hochverfügbarkeit und Desaster- Recovery 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

7 Hochverfügbarkeitslösungen des SQL Servers Log Shipping Mirroring Clustering Always-On Seit Version Automatischer Failover Nein Ja/Nein Ja Ja Lizenz (SQL 2014) Standard Standard Standard Enterprise (max.2 Server) Datenredundanz Ja Ja Nein Ja Mindest-Anzahl Instanzen 2 3/2 2 2 Absicherung gegen Ausfall X Datenbank(en) inkl. deren Storage Ausfall X Datenbank(en) inkl. deren Storage Ausfall 1 SQL Instanz Storage muss erhalten bleiben Ausfall X Datenbank(en) inkl. deren Storage Secondary Lesezugriff Ja Nein Nein Ja möglich Anzahl Systemdatenbanken (User/Job-Management) 2 (mehrfach und manuell) 2 (mehrfach und manuell) 1 (nur einmalig) 2 (mehrfach und manuell) Datenstände synchron Nein Ja N/A Ja Einschränkungen Kein Schutz der Kein Schutz der Kein Schutz gegen Kein Schutz der gesamten Instanz Kein Schutz der Systemdatenbanken gesamten Instanz Ausfall des Storage Kein Schutz der Systemdatenbanken gesamten Instanz Kein Schutz der Systemdatenbanken 7

8 Architektur AlwaysOn Virtual Cluster Name:SQLAlwaysOn01 IP: AlwaysOn-Db-Connect Name:VSqlServer IP: Client Public /24 Primary DB Server Name: SqlServer01 IP: Heartbeat /24 Secondary DB Server Name: SqlServer02 IP: DomainController Name: Win12DomainController IP

9 Two-Phase Commit Client Public /24 Primary DB Server Secondary DB Server 5. Execute Tran 3. Execute Tran 4. Send Commit 9

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

11 Demo Aufbau AlwaysOn für eine User-Datenbank 11

12 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

13 Demo Wiederanlauf ETL-Paket mit Checkpoint-Datei 13

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

15 Demo Create SSIS-Catalog, Enable AlwaysOn für die SSISDB 15

16 Master-Key Fehler?! 16

17 Verschlüsselungshierarchie 17

18 Demo Was passierte beim Anlegen des SSIS-Catalog? 18

19 DynamicManagementViews für AlwaysON 19

20 DynamicManagementViews für AlwaysON 20

21 Demo Failover-Erkennung und Wiederanlauf 21

22 Weiterführende Links Technische Hochverfügbarkeits-SQL-Server Lösungen: SSIS-Catalog AlwaysOn ORAYLIS

23 Fragen? 23

Ähnliche Dokumente

Hochverfügbarkeit mit Data Guard Möglichkeiten und Grenzen

Hochverfügbarkeit mit Data Guard Möglichkeiten und Grenzen DOAG Konferenz 16. 18.11.2010, Nürnberg Andreas Kother info@ordix.de www.ordix.de Agenda Definition Hochverfügbarkeit Abgrenzung RAC vs. Data