Clustering vs. Transaktionsreplikation vs. Verfügbarkeitsgruppen

47

Angenommen, Sie müssen sicherstellen, dass Ihre Anwendung, die SQL Server 2012 als Datenbank-Backend verwendet, rund um die Uhr verfügbar ist, auch wenn ein Server ausfällt.

Als Entwickler und nicht als DBA habe ich Probleme zu verstehen, wann ich welches Szenario für mein Failover / meine Hochverfügbarkeit verwenden soll:

  • Zwei (oder mehr) Server in einem Windows-Failovercluster, SQL Server als Clusterinstanz
  • Zwei (oder mehr) SQL Server-Instanzen, die mit der Transaktionsreplikation auf dem neuesten Stand gehalten werden
  • Zwei (oder mehr) SQL Server in einer SQL Server-Verfügbarkeitsgruppe, konfiguriert in einem synchronen Festschreibungsmodus

Welches dieser Szenarien funktioniert für welche Art von Workload und welche Art von Ausfall / Ausfall kann von diesen Szenarien behandelt werden? Sind sie überhaupt vergleichbar / austauschbar?

marc_s
quelle

Antworten:

50

Die Art und Weise, wie ich Hochverfügbarkeitslösungen immer visualisiere, ist die folgende:

SQL Server-Failoverclusterinstanz (FCI)

Was ist hoch verfügbar? Die gesamte Instanz. Dies beinhaltet alle Serverobjekte (Logins, SQL Server Agent Jobs, etc.). Dies schließt auch Datenbanken und ihre enthaltenen Entitäten ein. Es ist eine großartige Lösung für hochverfügbare SQL Server-Instanzen, da dies die Ebene der Eindämmung mit dieser gegebenen Lösung sein wird.

Was ist mit Berichterstattung? Keine, NULL, nicht vorhanden. Eine Failover-Cluster-Instanz verfügt über einen aktiven Knoten, der die Cluster-Gruppe mit der Instanz, dem VNN usw. bereitstellt, und alle anderen Knoten sind passiv, befinden sich im Leerlauf (soweit es die aktuelle Cluster-Gruppe betrifft) und warten auf ein Failover.

Was passiert bei einem Failover? Die Ausfallzeit für eine FCI wird durch die Zeit bestimmt, die der passive Knoten benötigt, um die Clusterressource abzurufen und die SQL Server-Instanz in einen aktiven Zustand zu versetzen. Dies ist in der Regel zeitlich minimal.

Irgendeine Client-Abstraktion? Ja, dies wird automatisch mit dem Namen des virtuellen Netzwerks für die Failover-Cluster-Instanz integriert. Dies zeigt immer auf den aktiven Knoten, der aktuell die SQL Server-Clusterressource bereitstellt.

AlwaysOn-Verfügbarkeitsgruppen

Was ist hoch verfügbar? Eine Verfügbarkeitsgruppe ist hier die logische Eingrenzung der Hochverfügbarkeit, während eine Verfügbarkeitsgruppe aus einer Reihe von Datenbanken und einem virtuellen Netzwerknamen (dem Listener, einer optionalen Clusterressource) besteht. Es ist zu beachten, dass Serverobjekte wie Anmeldungen und SQL Server-Agent-Jobs nicht Teil der HA-Lösung sind und dass besondere Überlegungen erforderlich sind, um sicherzustellen, dass diese mit einer Verfügbarkeitsgruppe ordnungsgemäß implementiert werden. Keine übermäßig belastende Anforderung, sondern muss gepflegt werden.

Was ist mit Berichterstattung? Dies ist eine großartige Lösung für die Berichterstellung, obwohl ich wahrscheinlich kein synchrones Replikat als Berichtsinstanz verwenden würde. Es gibt zwei Festschreibungsbeziehungen, synchron und asynchron. Meiner Meinung nach und nach dem, was ich in der Praxis gesehen habe, wartet Ihr synchrones sekundäres Replikat dort auf eine Katastrophe. Stellen Sie sich dieses Replikat vor, das bereit ist, im Falle eines Problems ein Failover ohne Datenverlust durchzuführen. Dann gibt es asynchrone Replikate, die diese Berichtsauslastung verarbeiten können. Sie verwenden dieses Replikat nicht als die oben genannte Lösung, sondern auch für Dinge wie Berichterstellung. Berichts-Workloads können auf dieses Replikat verwiesen werden (entweder direkt oder indirekt durch schreibgeschütztes Routing über den Listener).

Was passiert bei einem Failover? Bei einem sekundären Synchron-Commit-Replikat, das mit einem automatischen Failover gekoppelt ist, ist dies die Statusänderung der Replikatrolle von SECONDARY_NORMAL nach PRIMARY_NORMAL. Damit ein automatisches Failover durchgeführt werden kann, muss ein synchrones sekundäres Replikat vorhanden sein, das derzeit synchronisiert ist, und die Richtlinie für flexibles Failover ist implementiert, um zu bestimmen, wann dieses Failover tatsächlich stattfinden soll. Diese Richtlinie ist in der Tat konfigurierbar.

Irgendeine Client-Abstraktion? Ja, Sie können optional einen AlwaysOn-Verfügbarkeitsgruppen-Listener konfigurieren. Dies ist im Grunde genommen nur ein virtueller Netzwerkname (der über WSFC als Clusterressource in der Clustergruppe der AG angezeigt wird), der auf das aktuelle primäre Replikat verweist. Dies ist ein wichtiger Teil der Verlagerung Ihrer Berichterstellungsarbeitslast sowie der Einrichtung einer schreibgeschützten Routingliste auf allen Servern, die ReadOnly-Datenverkehr umleiten sollen (dies wird über die Verbindungszeichenfolge mit dem .NET Framework-Anbieter für SQL festgelegt) Server, dies ist der Application Intent- Parameter ( ReadOnly ). Sie müssten auch eine schreibgeschützte Routing-URL für jedes Replikat festlegen, für das Sie diese Berichtsauslastung in der sekundären Replikatrolle erhalten möchten.

Transaktionsreplikation

Was ist hoch verfügbar? Das ist fraglich, aber ich werde nichts sagen . Ich sehe Replikation überhaupt nicht als Hochverfügbarkeitslösung. Ja, Datenänderungen werden an die Abonnenten weitergeleitet, aber wir sprechen auf Veröffentlichungs- / Artikelebene. Dies wird eine Teilmenge der Daten sein (könnte alle Daten enthalten, dies wird jedoch nicht erzwungen. Sie erstellen also eine neue Tabelle in der Publisher-Datenbank, die nicht automatisch an die Abonnenten weitergeleitet wird). Was HA betrifft, handelt es sich um Bottom-of-the-Barrel, und ich werde es dort nicht mit einer felsenfesten HA-Lösung zusammenfassen.

Was ist mit Berichterstattung? Eine großartige Lösung für die Berichterstattung über eine Teilmenge von Daten, keine Frage. Wenn Sie über eine 1-TB-Datenbank mit hohem Transaktionsgrad verfügen und diese Berichtsauslastung von der OLTP-Datenbank fernhalten möchten, ist die Transaktionsreplikation eine hervorragende Möglichkeit, eine Teilmenge der Daten für die Berichtsauslastung an einen Abonnenten (oder Abonnenten) zu senden. Was passiert, wenn von dieser 1 TB Datenmenge nur etwa 50 GB für Ihre Berichterstellung erforderlich sind? Dies ist eine intelligente Lösung, die sich relativ gut an Ihre geschäftlichen Anforderungen anpassen lässt.

Zusammenfassung

Worauf es ankommt, sind ein paar Fragen, die beantwortet werden müssen (teilweise vom Unternehmen):

  1. Was muss hoch verfügbar sein ?
  2. Was schreibt das SLA für HA / DR vor?
  3. Welche Art von Berichterstattung wird stattfinden und welche Latenzen sind akzeptabel?
  4. Was müssen wir mit geografisch verteiltem HA anfassen? (Speicherreplikation ist teuer, aber ein Muss bei einer FCI. AGs benötigen keinen gemeinsam genutzten Speicher für eigenständige Instanzen, und Sie können einen Dateifreigabezeugen für das Quorum verwenden, um die Notwendigkeit eines gemeinsam genutzten Speichers auszuschließen.)
Thomas Stringer
quelle
Danke für die tolle Antwort, Thomas! Wenn ich das richtig verstehe, würde FCI automatisch auf einen "Hot Standby" -Server umschalten, wenn der Hauptcomputer ausfällt - richtig? Was ist mit AlwaysOn? Bietet das auch eine Art automatisches "Failover" oder ist es nur eine sekundäre Kopie der Datenbank, aber einige Administratoren müssen im Falle eines Fehlers manuell umschalten?
Marc_s
+1 - tolle Antwort und gute Infos zum Melden. Entschuldigung für das Crossposting, aber ich war mit 3/4 fertig, als du deine Antwort geteilt hast :-)
Mike Walsh
1
@marc_s Bin froh zu helfen! In Bezug auf eine FCI haben Sie Recht, vorausgesetzt, die WSFC selbst fällt nicht aus (dh sie verliert das Quorum) und es gibt einen passiven Knoten, der im Falle eines Failovers die SQL Server-Clusterressourcengruppe übernehmen kann. Wie bei einer AlwaysOn AG ist ein automatisches Failover möglich. Ich habe meine Antwort so bearbeitet, dass sie diese Informationen enthält. Grundsätzlich benötigen Sie jedoch ein synchronisiertes sekundäres Replikat, das für das automatische Failover konfiguriert ist. Sie können auch ein manuelles Failover durchführen, ohne dass Daten auf ein synchronisiertes zweites Replikat verloren gehen.
Thomas Stringer
@ThomasStringer - das ist sehr hilfreich. Danke! Ich frage mich, ob Sie sich mit Schemaänderungen für jede der drei Optionen befassen können. Wir haben die Transaktionsreplikation nur eingerichtet, um herauszufinden, dass es für den Herausgeber sehr schwierig ist, Schemaänderungen vorzunehmen . Was ist mit AlwaysOn? Würden wir auch hier auf dasselbe Problem stoßen?
Casey Crookston
22

zwei (oder mehr) Server in einem Windows-Failovercluster, SQL Server als Clusterinstanz

  1. Was für eine Arbeitsbelastung? "Es kommt darauf an" - aber im Ernst, dies ist nützlich für eine Online-Anwendung, bei der eine lokale Hochverfügbarkeit im Rechenzentrum erforderlich ist. Sie sind gegen den Ausfall eines Computers oder eines Betriebssystems geschützt. Die Anmeldungen, Jobs, neuen Datenbanken, Wartungsarbeiten usw. werden automatisch synchronisiert, da es sich um einen Cluster mit zwei Knoten handelt, die sich genau den gleichen Speicher teilen und über dieselben Systemdatenbanken verfügen. Sehr schnelles Failover, aber es gibt immer noch ein Problem, das wie ein Neustart von SQL Server aussieht, wenn das Failover auftritt.

  2. Nachteile / Bedenken - Ein einziger Fehlerpunkt ist Ihr Speicher und alle seine Komponenten. SAN-Anbieter sagen immer, dass SANs nicht ausfallen, aber es gibt viele bewegliche Teile in einem Storage Area Network, und wie ich hier beschrieben habe , können sie dies. Außerdem bezahlen Sie für einen sekundären Server, der nichts anderes kann, als herumzuhängen und zu warten. Jetzt können Sie Active / Active / Multi-Node ausführen und über zwei aktive Instanzen verfügen, die ein Failover in beide Richtungen ausführen und den zweiten Knoten verwenden können.

  3. Automatisches Failover? Die "meisten" automatisch. Es wird kein Zeuge benötigt, es ist ein Cluster. Dies ist die Aufgabe eines Clusters, um es so nahtlos wie möglich zu gestalten. Wenn nun ein Failover stattfindet, werden Sie es "fühlen", weil SQL gestartet werden muss oder Verbindungen zeigen müssen. Wenn dies passiert, werden Sie sich im Grunde wie ein Neustart von SQL fühlen, DBs kehren zurück und führen recovery / etc aus.

Wenn ein Client in einer Hochverfügbarkeitsumgebung in meinem lokalen Rechenzentrum "Ich möchte mit allen Datenbanken, allen Anmeldungen usw. auf dem Laufenden sein" sagt, weil ich eine unglaublich geringe Toleranz für Ausfallzeiten habe, würde ich Failover - Cluster - Instanzen in Betracht ziehen (obwohl die Die letzte Option, die Sie erwähnen, ist ein starker Konkurrent (abgesehen von Verwaltungsaufwand). Ich würde wahrscheinlich eine lokale FCI und eine asynchrone sekundäre AG durchführen, um mich vor Standortfehlern oder SAN-Fehlern zu schützen.

zwei (oder mehr) SQL Server-Instanzen, die mit der Transaktionsreplikation auf dem neuesten Stand gehalten werden

  1. Was für eine Arbeitsbelastung? Ich würde hier ehrlich gesagt nicht für viele Fälle gehen, in denen Hochverfügbarkeit oder Notfallwiederherstellung als erste Wahl erforderlich sind. Sicher nicht in SQL 2012. Aber im Grunde ist dies gut, wenn Sie zu einem Rechenzentrum mussten, das nicht in der Nähe war. Sie konnten keine AG verwenden (möglicherweise ein Domänenproblem, das Sie daran hinderte, den für die AG erforderlichen Windows-Cluster zu verwenden). Vielleicht wollten Sie das auch in SQL Server Standard, der Replikation durchführen kann, aber keine AGs, aber Sie wollten trotzdem die Fähigkeit haben, auf der sekundären Seite zu lesen und asynchron zu sein.
  2. Nachteile / Bedenken - Es ist Replikation. Es hat Overhead, es kann aus der Synchronisation geraten, Sie können Probleme mit der Leistung auf der Quellenseite entwickeln, usw.
  3. Automatisches Failover - Nein. Sie müssen es selbst verwalten. Entweder über CNAMEs, die auf das eine oder das andere verweisen, und Sie könnten theoretisch Ihren eigenen Prozess schreiben, um dies zu tun, aber out of the box? Beachten Sie hier.

zwei (oder mehr) SQL Server in einer SQL Server-Verfügbarkeitsgruppe, konfiguriert in einem synchronen Festschreibungsmodus

Das ist es, was ich in letzter Zeit immer mehr Leuten bei der Implementierung geholfen habe, obwohl ich manchmal immer noch Clustering mache.

  1. Was für eine Arbeitsbelastung? Das ist großartig , wenn ich einen überschaubaren Satz von Datenbanken synchron zu halten, und die Ressourcen und Zeit , um sicherzustellen , dass Jobs, Logins, neue Datenbanken, etc. Aufenthalt in sync (obwohl das Team von SQL Fähigkeiten haben eine große Add eingebaut zu Automatisieren Sie einen Teil davon für Sie und machen Sie eine Option noch stärker. Ich mag das, wenn ich die Dinge völlig getrennt halten möchte. Ich schütze vor Hardwareproblemen, Betriebssystemproblemen, Problemen mit der SQL-Installation, Patches und SAN- / Speicherproblemen. Ich habe auch den Vorteil, dass ein Secondary (wenn ich eine Unternehmenslizenz dafür bezahlen möchte) ein aktiver Secondary ist, von dem ich lesen, Backups erstellen usw. kann. Außerdem kann ich in Zukunft einen dritten hinzufügen Sekundär, der an einem Remotestandort asynchron ist und über Failover / DR verfügt.
  2. Nachteile / Bedenken Lizenzierung, maximale Anzahl von Replikaten, Lizenzkosten, um einige der größten Vorteile zu nutzen (Active Secondary), erfordert Unternehmen, erfordert doppelt so viel Speicher als Clustering.
  3. Automatisches Failover - Ja. Dies kann bei einem Zeugen-Setup auftreten, und Ihre App-Entwickler können eine Verbindung zum Listener anstelle eines Knotens herstellen, sodass das Failover dort stattfindet, wo der Listener verweist und Sie dort gut sein sollten. Sie können das also hier tun - und sollten - aber Sie sollten es natürlich gut testen.

Zusammenfassung

HA und DR sind unterschiedlich. Und diese Technologien tragen dazu bei, Teile von beidem bereitzustellen. Hochverfügbarkeit bedeutet für mich, dass Sie schnell eine Wiederherstellung durchführen können, wenn auf einem Computer etwas Schlimmes passiert. Sie haben ein kurzes Ziel für Wiederherstellungspunkte und eine kurze Wiederherstellungszeit. Das ist Clustering und eine synchrone AG.

Disaster Recovery ist "Sie können aufstehen, wenn Sie einen Fehler haben, auch in Ihrer HA-Lösung. Für mich kann dies ein AG sein, wenn Sie zu einem anderen Rechenzentrum gehen, spiegeln oder sogar replizieren.

Mike Walsh
quelle
1
+1 noch eine tolle Antwort - danke! Die Wolken fangen an aufzuklären!
Marc_s
2
Vielen Dank. Außerdem wurde ein Hinweis zum automatischen Failover hinzugefügt.
Mike Walsh
2
@marc_s Clustering (FCI) und AG schließen sich nicht gegenseitig aus. Sie können Node1 und Node2 im selben Datencenter geclustert haben (gemeinsam genutzten Speicher) und eine dritte eigenständige Instanz im Remote-Datencenter (im selben Cluster, aber nicht gemeinsam
genutzten
2
+1 für die Vereinbarung @DaniSQL ;-) Und du hast es in weitaus weniger Worten gesagt.
Mike Walsh
1
Ich wünschte, ich hätte sowohl die Antwort von Thomas als auch Ihre Antwort akzeptieren können - sowohl hervorragend als auch sehr ausführlich - danke!
Marc_s
9

Es ist auch wichtig zu überlegen, was geteilt wird .

Beim Failover-Clustering werden zwei oder mehr Serverknoten verwendet, die sich ein Festplattenarray teilen . Wenn das Festplatten-Array ausfällt, verlieren Sie den Dienst, unabhängig davon, wie viele Serverknoten vorhanden sind. Wenn der Serverraum, in dem sich das Festplatten-Array befindet, Feuer oder Überschwemmungen ausgesetzt ist, verlieren Sie den Dienst.

AlwaysOn-Verfügbarkeitsgruppen und Datenbankspiegelung sind eine Clustering-Technologie, bei der nichts gemeinsam genutzt wird. Die Datenbank befindet sich auf mehreren Festplattenarrays auf mehreren Servern. Wenn Sie über gute Netzwerkverbindungen verfügen, können sich die mehreren Servern in mehreren Serverräumen befinden, um Sie vor Bränden und Überschwemmungen zu schützen.

Greenstone Walker
quelle
6

Der Vollständigkeit halber gibt es die Möglichkeit, eine einfache alte Spiegelung zu verwenden. Zu den Vorteilen zählen zwei Kopien der Datenbank ohne die Komplexität der Verwendung von Verfügbarkeitsgruppen und ohne den gemeinsamen Speicher für das Failover-Clustering. Der leichte Nachteil ist, dass die Spiegelung veraltet ist.

Failover-Zeiten mit Spiegelung liegen in der Größenordnung von 10 Sekunden, obwohl der Anwendungscode alle Transaktionen wiederholen muss, die zum Zeitpunkt des Failovers auftreten.

Max Vernon
quelle
2
+1, um es separat und speziell aufzurufen :) Das heißt - ja, Sie können mit Sicherheit argumentieren, dass das Spiegeln weniger komplex ist und nicht die Cluster-Anforderungen, die damit verbundenen Domain-Anforderungen usw. hat, die AGs haben. Die Komplexität ist also nach wie vor gegeben, und es besteht die Notwendigkeit, Anmeldungen, Aufträge, neue Datenbanken usw. wie bei AGs synchron zu halten. Es hat also einige der gleichen Kosten und ist, wie Sie sagten, veraltet. Aber ich
Mike Walsh,