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?

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.)

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.

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.

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.