Was ist SQL Server AlwaysOn?
Von: Simon Liew | Aktualisiert: 2017-02-20 | Kommentare (10) | Verwandt: Mehr > Verfügbarkeitsgruppen
Problem
SQL Server AlwaysOn ist ein beliebter Begriff, der in verschiedenen Quellen erwähnt wird, aber was bedeutet SQL Server AlwaysOn wirklich? Dieser Tipp erklärt den Begriff SQL Server AlwaysOn und seine zwei Haupttechnologien.
Lösung
SQL Server AlwaysOn ist ein Marketingbegriff, der sich auf die Hochverfügbarkeits- und Disaster-Recovery-Lösung bezieht, die mit der Einführung von SQL Server 2012 eingeführt wurde.
Näher betrachtet besteht SQL Server AlwaysOn aus zwei Technologien:
- AlwaysOn Failover Clustering Instances (AlwaysOn FCI)
- AlwaysOn Availability Groups (AlwaysOn AG)
Während beide Technologien Gemeinsamkeiten aufweisen, wie z.B. die Notwendigkeit von Windows Server FailoverClustering (WSFC) als Grundlage für die Implementierung, ist jede eine eigenständige Technologie unter dem Dach von AlwaysOn.
AlwaysOn Failover Clustering Instances (FCI)
AlwaysOn FCI benötigt Shared Storage wie ein iSCSI oder Fibre Channel SAN, auf das alle Knoten im Cluster zugreifen können. Es gibt auch die Möglichkeit, Datenreplikationstools von Drittanbietern zu verwenden, die bei den Speicheranforderungen helfen können, wenn Sie keinen gemeinsamen Speicher haben oder dies für virtuelle Maschinen oder in der Cloud tun wollen.
Es unterstützt Multisite-Clustering über Subnetze hinweg, was ein Failover von SQL Server-Instanzen über Rechenzentren hinweg ermöglicht, aber dies erfordert eine Replikation der Daten zwischen dem gemeinsamen Speicher in jedem der Rechenzentren.
AlwaysOn FCI ist sowohl in der SQL Server Standard als auch in der Enterprise Edition verfügbar, unterliegt aber in der SQL Server Standard Edition Einschränkungen, wie z. B. ein 2-Knoten-Limit.
Bei der Installation von SQL Server wählen Sie die Option „Neue SQL Failover-Cluster-Installation“.
Eine Implementierung von AlwaysOn FCI mit einem Standort und zwei Knoten (unter Verwendung des Quorum-Modus Node und DiskMajority) ist unten abgebildet.
Der Quorum-Modus hilft bei der Bestimmung, welche Knoten verfügbar sind und welcher Knoten der primäre Knoten sein soll. Durch die Beteiligung einer weiteren Maschine/eines weiteren Objekts kann bestimmt werden, ob die Kommunikation zwischen den Maschinen verloren geht und somit ein Afailover stattfinden sollte. Nachfolgend sind gängige Beispiele für den Quorum-Modus aufgeführt, die in einer AlwaysOn FCI-Konfiguration verwendet werden können.
- Knotenmehrheit
- Knoten- und Fileshare-Mehrheit
- Knoten- und (symmetrische) Plattenmehrheit
Ein symmetrischer Speicher bedeutet eine Clusterplatte, die von allen WSFC-Knoten gemeinsam genutzt wird. Dadurch ist der gemeinsame Plattenspeicher für alle potenziellen Failover-Knoten im WSFC-Cluster verfügbar.
AlwaysOn Availability Groups
AlwaysOn AG benötigt keinen gemeinsamen Plattenspeicher für den Server, der den SQL Server hostet. Diese SQL Server-Hochverfügbarkeitstechnologie ist ein Enterprise-Feature. Das bedeutet, dass Sie die SQL ServerStandard Edition nicht für die Verwendung von AlwaysOn AG mit Versionen vor SQL Server 2016 konfigurieren können.
Es gibt jetzt eine Option, um eine grundlegende Verfügbarkeitsgruppe mit der SQL Server 2016Standard Edition zu erstellen, die ich im Folgenden bespreche.
Bei der Installation von SQL Server wählen Sie die Option „Neue SQL-Standalone-Installation…“.
Eine Implementierung von AlwaysOn AG für HA und DR (unter Verwendung des Quorum-Modus „Node Majority“) ist unten abgebildet.
Nachfolgend finden Sie einige gängige Beispiele für den Quorum-Modus, der in einer AlwaysOn AG-Konfiguration verwendet wird.
- Knotenmehrheit
- Knoten- und Fileshare-Mehrheit
- Knoten- und (asymmetrische) Festplattenmehrheit
Eine asymmetrische Speicherung bedeutet, dass eine Cluster-Festplatte nur von einer Teilmenge der Knoten gemeinsam genutzt wird. Die asymmetrische Festplattenfunktion wurde erstmals in Windows Server 2008 eingeführt und ermöglicht es, dass ein Festplattenzeuge nur für Knoten an einem Standort, typischerweise dem primären Standort, konfiguriert und zugänglich ist.
Neue Funktionen in SQL Server 2016
Nachdem Sie die Unterschiede zwischen AlwaysOn FCI und AlwaysOn AG verstanden haben, wurden mit SQL Server 2016 zwei weitere Varianten von AlwaysOn AG eingeführt.
- AlwaysOn Basic Availability Groups (AlwaysOn BAG)
- AlwaysOn Distributed Availability Group (AlwaysOn DAG)
AlwaysOn Basic Availability Group (AlwaysOn BAG)
Die AlwaysOn-Funktion ist nun in der SQL Server 2016 Standard Edition enthalten, wird aber als AlwaysOn BAG bezeichnet. Sie wird ähnlich wie AG erstellt und verwaltet, aberAlwaysOn BAG ist in der Lage, nur eine Teilmenge von Funktionen zu verwenden, verglichen mit der erweitertenAlwaysOn AG auf SQL Server Enterprise Edition. Eine Einschränkung ist zum Beispiel, dass BAG nur zwei Replikate (primär und sekundär) zulässt.
AlwaysOn BAG bietet Failover-Unterstützung nur für eine einzelne Datenbank und ersetzt die Datenbankspiegelung, die veraltet ist.
AlwaysOn Distributed Availability Group (AlwaysOn DAG)
AlwaysOn DAG sind lose gekoppelte Gruppen von AGs. AlwaysOn DAG läuft auf zwei verschiedenen AGs, was bedeutet, dass sie sich auf zwei verschiedenen WSFCs mit eigenem Quorum- und Abstimmungsmanagement befinden.
Diese Konfiguration ermöglicht es, dass sekundäre Replikate einer AG in einer anderen geografischen Region als die primäre existieren. Ein beispielhafter Anwendungsfall wäre es, Read-Only-Workloads für entfernte Regionen zu ermöglichen und gleichzeitig mögliche Netzwerkprobleme am sekundären Standort zu vermeiden, die sich auf den primären Standort auswirken können.
Charakteristika von AlwaysOn FCI und AlwaysOn AG
Jede der beiden Technologien unterscheidet sich in ihrem Zweck. Es ist möglich,AlwaysOn FCI und AlwaysOn AG zu kombinieren. Geschäftsanforderungen könnten eine lokale Hochverfügbarkeit innerhalb eines Rechenzentrums mit AlwaysOn FCI und eine rechenzentrumsübergreifende Disaster Recovery mit AlwaysOn AG erfordern. Das bedeutet, dass die Lösung dann aus einer Kombination von Shared Storage und Non-Shared Storage in der Implementierung bestehen würde.
Wenn Sie sich fragen, welche Lösung Sie implementieren sollten, fasst die folgende Tabelle die Ähnlichkeiten und Unterschiede in den Merkmalen zwischen den Lösungen SQL Server AlwaysOn FCI undAlwaysOn AG zusammen und dient als Leitfaden bei der Evaluierung von SQL Server AlwaysOn.
| AlwaysOn FCI für HA und DR | AlwaysOn AG für HA und DR |
|---|---|
| Shared Storage Lösung | Non-Shared Storage Lösung |
| Instanzlevel HA Anmeldungen, SQL-Agent-Jobs, Zertifikate und andere Objekte auf SQL Server-Instanzebene sind nach dem Failover intakt |
Datenbankebene HA (kann eine oder mehrere Datenbanken sein) Manuelles Hinzufügen von Logins, SQL-Agent-Aufträge, Zertifikate und andere SQL Server-Instanzebene-Objekte zu allen sekundären |
| Schutz auf Instanzebene ohne Datenredundanz | Jede Gruppe von sekundären AG-Datenbanken sind redundante Kopien der primären |
| Haben aktive | DR-Replik kann Active Secondary für Backup, schreibgeschützte Arbeitslast sein. |
| Anwendung verbindet sich über den Namen des virtuellen Servers | Anwendung verbindet sich über den Namen des AG-Listeners |
| Behält keine redundante Kopie der Daten aufrecht und bietet daher keinen Schutz vor einem Ausfall des I/O-Subsystems | Schutz vor einem Ausfall des I/O-Subsystems, d. h. automatische Seitenreparatur |
| Keine besonderen Anforderungen in Bezug auf Datenbank-Wiederherstellungsmodelle | Die Datenbank(en) in AG müssen im FULL-Wiederherstellungsmodell sein |
Andere Dinge zu beachten für beide:
- Jeder einzelne AlwaysOn-Einsatz ist ein WSFC-Einsatz
- Beide, FCIs und AGs, können sich über mehrere Rechenzentren erstrecken, jedoch mit unterschiedlichen Implementierungen
- Sie können auf physischen SQLServer-Systemen implementiert werden, oder auf SQL Server-Systemen, die als Virtualmachines laufen
Zusammenfassung
Wenn von SQL Server AlwaysOn die Rede ist, ist dies nicht spezifisch, da es sich entweder auf AlwaysOn FCI oder AlwaysOn AG beziehen kann.
Zusammenfassend:
- AlwaysOn = {SQL Server Failover Cluster Instances, Availability Groups}
- AlwaysOn != SQL Server Failover Cluster Instances != Availability Groups
- Availability Groups != Database Mirroring
- WSFC != SQL Server Failover Cluster-Instanzen
Nächste Schritte
- Hochverfügbarkeitslösungen (SQL Server)
- WWSFC Quorum-Modi und Abstimmungskonfiguration (SQL Server)
- Windows Server Failover Clustering Quorum-Konfigurationsmodelle erklärt
- SQL Server AlwaysOn Availability Groups – Konfiguration Teil 1
- Installation von SQL Server 2008 auf einem Windows Server 2008 Cluster Teil 1
- SQL Server Clustering Tipps
- SQL Server Availability Groups Tipps
Letzte Aktualisierung: 2017-02-20
Über den Autor
Simon Liew ist ein unabhängiger SQL Server Berater in Sydney, Australien. Er ist Microsoft Certified Master für SQL Server 2008 und hat einen Master-Abschluss in Distributed Computing.Alle meine Tipps ansehen
- Mehr SQL Server DBA-Tipps…