Es ist kein Geheimnis, dass ich die Datenbank-Clustering-Lösung von Oracle ziemlich gut kenne. Kürzlich habe ich eine SQL Server-Clustering-Hochverfügbarkeitslösung fertiggestellt, die vom ersten Entwurf bis zur endgültigen Implementierung zwei Jahre gedauert hat. Dieser Prozess umfasste das Dokumentieren von Anforderungen, das Bestimmen der Optionen, das Zuordnen von Anforderungen zu Implementierungsdetails, Budgetierung, Beschaffung, Installation, Konfiguration und Tests.
Jetzt, da mein Projekt abgeschlossen ist, dachte ich, ich würde ein paar Artikel über das Clustering von SQL Server aus der Perspektive eines Oracle RAC-Typen geben. Wir alle wissen, dass SQL Server und Oracle beide RDBMS-Engines sind, und sie haben möglicherweise einige Gemeinsamkeiten. Aber sie sind auch völlig andere Kreaturen. Wenn Sie also mit der Grid-Infrastruktur und RAC und Data Guard von Oracle vertraut sind und die Implementierung einer SQL Server HA-Lösung in Betracht ziehen, finden Sie hier vielleicht einige gute Informationen.
Unser aktuelles Produktionssystem ist eine Oracle RAC-Primärdatenbank mit 4 Knoten. Dies bietet eine hohe Verfügbarkeit (und hohe Leistung) in unserem primären Rechenzentrum. Wir verwenden Data Guard, um Redo zu einer physischen RAC-Standby-Datenbank mit 3 Knoten zu übertragen. Obwohl SQL Server <> Oracle, wollte ich unsere Konfiguration so ähnlich wie möglich halten, um die Verwaltung zu vereinfachen. Also haben wir einen 2-Knoten-SQL Server-Failover-Cluster an unserem primären Standort und eine 1-Knoten-„Standby“-Datenbank an unserem DR-Standort bereitgestellt.
Nun zu meinen Beobachtungen, in keiner bestimmten Reihenfolge.
- Die HA-Clustering-Lösung von SQL Server ist aktiv/passiv. Oracle ist Active/Active, was für mich „besser“ ist, und ja … das ist ein subjektiver Begriff. Für unsere Aktiv/Passiv-Implementierung gefiel mir die Idee nicht, dass zwei physische Server dort sitzen und einer im Wesentlichen die ganze Zeit im Leerlauf ist. Wir haben also einen physischen Server, der der „bevorzugte“ Knoten ist, und einen virtuellen Server. Wenn der physische Server ausfällt, führt das Clustering automatisch ein Failover der SQL Server-Instanz zum virtuellen Server durch und wir sind wieder einsatzbereit. Dieser Aktiv/Passiv-Cluster hat nichts mit der Skalierbarkeit zu tun, wie es Oracle RAC tut, aber er bietet mir eine höhere Verfügbarkeit in unserer primären Umgebung.
- Die Implementierung des Clusterings ist supereinfach. Aktivieren Sie das Clustering auf Betriebssystemebene. Da es sich um einen reinen Microsoft-Stack handelt, haben sie Clustering in das Betriebssystem integriert. Es ist bereits für Sie da. Sie müssen es nur einschalten. Starten Sie dann Verwaltung -> Failover-Cluster-Manager und Assistenten führen Sie durch die Einrichtung. Es ist viel einfacher als die Installation einer Grid-Infrastruktur. Aber Oracle muss sich mit verschiedenen OS-Plattformen auseinandersetzen, was es dort schwieriger macht. Es wird interessant sein zu sehen, wie SQL Server 2016 unter Linux mit Failover-Clustering umgeht.
- Oracle verwendet ein Shared Disk-Modell, während SQL Server Shared Nothing ist. Aber Sie müssen „freigegebene Festplatte“ in gewisser Weise verwenden, da die Festplatte auf beiden Knoten verfügbar sein muss. Allerdings stellt MS Failover Clustering (MSFC) den geclusterten Datenträger auf dem aktiven Knoten bereit. Wenn SQL Server auf den anderen Knoten verschoben wird, entweder automatisch oder manuell, wird MSFC die Bereitstellung des Datenträgers auf einem Knoten aufheben und ihn dann auf dem anderen bereitstellen. Es ist irgendwie seltsam, ein Windows Explorer-Fenster geöffnet zu haben und zu sehen, wie die Festplatte während dieses Übergangs entweder erscheint oder verschwindet.
- Die Grid-Infrastruktur verwendet die Voting Disk für Quorum-Operationen. In MSFC können Sie einen Quorum-Datenträger haben, eine Dateifreigabe verwenden oder ohne Quorum konfigurieren. Wenn Sie sich für Letzteres entscheiden, behindern Sie Ihre automatische Failover-Fähigkeit.
- Ich bin daran gewöhnt, dass mein Primary seinen eigenen Cluster und der Standby seinen eigenen Cluster hat. Bei SQL Server müssen die primären Knoten und die Standby-Knoten Teil desselben Clusters sein. Glücklicherweise kann der Cluster Subnetze überschreiten, was anders ist als bei Oracle GI. Das Hinzufügen des Standby-Knotens war super einfach, wir haben nur seine Stimmrechte entfernt und die Quorum-Festplatte für den Standby-Knoten nicht konfiguriert. Das war für uns in Ordnung, da wir möchten, dass das Failover zum Standby ein manueller Vorgang ist.
- Für eine Standby-Datenbank können Sie Datenbankspiegelung, Protokollversand oder AlwaysOn-Verfügbarkeitsgruppen (AGs) verwenden. Die ersten beiden sind auf dem Weg nach draußen, also bin ich mit den AGs gegangen. AGs erfordern, dass der Standby-Knoten Teil desselben Clusters wie der Primärknoten ist. Es gibt einen Assistenten, der Sie durch die Einrichtung der Datenbanken für die Teilnahme an der AG führt. Dies ist viel einfacher als das Einrichten eines physischen Oracle-Standbys.
- Für diejenigen unter Ihnen, die die Oracle-Dokumentation hassen, ist es an der Zeit, dankbar zu sein. Während dieses Prozesses habe ich oft festgestellt, dass in der MS-Dokumentation sehr große Teile fehlen. Zum Beispiel habe ich nie herausgefunden, wie ich meinen Standby-Knoten so konfigurieren kann, dass er keine Stimmrechte hat. Zum Glück konnten wir uns durchklicken.
Letztendlich war es nicht so schwierig, die SQL Server-Lösung zu implementieren. Manchmal musste ich mich auf mein Wissen über Clustering verlassen. In anderen Fällen kam die Terminologie von Microsoft in die Quere. Der Rest der Welt nennt es zum Beispiel „Split Brain“, aber MS nennt es „Split Cluster“. Manchmal war die Überwindung der Lexikonunterschiede die größte Hürde.
