SQL Server entspricht der Funktionalität von Oracle RAC? [geschlossen]

Ich habe ein bisschen gegoogelt und konnte vor einigen Jahren keine Antwort auf diese Frage finden, also dachte ich, ich würde fragen. Die RAC-Funktion von Oracle bietet einen Lastenausgleich für Lese- und Schreibtransaktionen sowie eine Skalierung und Hochverfügbarkeit ohne Ausfallzeiten (zumindest so wie ich es verstehe - wir sind dabei, unsere ersten Datenbanken bereitzustellen, die RAC verwenden Ich werde sehen, wie es geht.

Gibt es einen SQL Server-Funktionsumfang (oder eine Komponente eines Drittanbieters, die Sie oben installieren könnten), die gleichwertige Funktionen bietet? Wir haben immer Windows-Clustering verwendet, bei dem ein Failover-Ereignis etwa 20 bis 30 Sekunden SQL-Ausfallzeit verursacht - immer tolerierbar, aber nicht ideal. Mit AlwaysOn in SQL 2012 verringert SQL Server diesen Wert auf etwa 15 Sekunden und fügt das Konzept schreibgeschützter sekundärer Datenbanken hinzu. Sie erfordern jedoch weiterhin, dass Schreibtransaktionen über einen einzigen Verbindungspunkt erstickt werden (erheblich verbessert, da viele Transaktionen durchgeführt werden) nur lesen, aber immer noch nicht wirklich Lastenausgleich), und im Falle eines Knotenausfalls oder der Notwendigkeit eines Patches gibt es immer noch Ausfallzeiten.

Ich nehme an, es ist nur mehr Neugier - ich denke, dies ist der einzige Bereich, in dem SQL Server hinter Oracle zurückfällt (zumindest unter den Funktionen, die ich persönlich verwendet habe). Ich wollte herausfinden, ob es Optionen gibt, um diese Lücke zu schließen und möglicherweise unsere eigene SQL Server-Bereitstellung zu verbessern, während wir darauf warten, dass die entsprechende Funktion von Microsoft hinzugefügt wird - möglicherweise in SQL 2014/2015?

Nein, nichts in SQL Server können Sie die gleiche Sache aus dem Kasten heraus .

Derzeit ist die Peer-to-Peer-Replikation die einzige SQL Server-Technologie, die gleichzeitiges Schreiben auf mehreren Knoten ermöglicht . Beachten Sie, dass ich nicht "Scale-Out schreiben" gesagt habe, da dies so funktioniert, dass das gesamte System nur die Schreibkapazität eines einzelnen Knotens hat. Der einleitende Absatz dieser Seite ist sorgfältig formuliert und enthält den Begriff "Scale-Out", ohne "Scale-Out schreiben" zu sagen. Yay für Marketing-Sprechen.

Nach dem, was ich gelesen habe , ist Oracle RAC in dieser Hinsicht dasselbe. Funktionell fehlt SQL Server in dieser Konfiguration nur eine Lösung für den Lastenausgleich. Dies ist sowohl ein Vorteil (Sie können sie nach Belieben implementieren) als auch ein Nachteil (nicht im Lieferumfang enthalten oder von Microsoft unterstützt) Vergleich mit Konkurrenzprodukten.

Im Gegensatz dazu hat Oracle RAC gibt Ihnen nicht die gleichen wie SQL Server aus der Box entweder. Beispielsweise wird empfohlen, RAC aufgrund der Echtzeit-Netzwerklatenz mit Knoten innerhalb von 100 km voneinander zu implementieren, während die Peer-to-Peer-Replikation keine solche Einschränkung aufweist. (Ich sage nicht, dass eine Lösung besser ist als die andere: Ich möchte nur darauf hinweisen, dass sie unterschiedlich sind. Das Unternehmen sollte eine Lösung wählen, die ihren spezifischen Anforderungen am besten entspricht.)

Ich bin ein DBA, der sowohl SQL 2000-2012, Oracle 11g als auch Oracle 11g RAC unterstützt.

IMO, Always On Availability Groups in SQL 2012 kommt der Verfügbarkeit und Skalierbarkeit von RAC sehr nahe und ist sowohl in US-Dollar als auch in Komplexität viel kostengünstiger. Sie können Lesevorgänge skalieren, indem Sie die Spiegel abfragen. Sie möchten jedoch alle DMLs an den Primärserver weiterleiten (SQL Server-Spiegel können nicht aktualisiert werden). Wenn der primäre SQL Server abstürzt, erfolgt das Failover auf einen der Spiegel fast sofort. Bei RAC tritt eine ähnliche Pause auf, wenn ein Knoten abstürzt, wenn nicht festgeschriebene Transaktionen auf dem ausgefallenen Knoten vom überlebenden Knoten zurückgesetzt werden.

Der größte Vorteil (IMHO) von SQL 2012 AAAG gegenüber RAC ist, dass es sich um eine Shared-Nothing-Architektur handelt. RAC teilt den Speicher. Wenn dies fehlschlägt, ist der gesamte Cluster ausgefallen. Das ist ein riesiger SPOF im RAC, den jeder zu vergessen scheint. Wenn Sie sich davor schützen möchten, müssen Sie einen Standby-Server einrichten. Wenn Sie möchten, dass dies RAC ist, werden die Kosten immer weiter erhöht.

Die direkte Antwort auf Ihre Frage lautet "Nein". SQL Server verfügt nicht über gleichwertige Funktionen. Es gibt Aspekte von SQL Server, die Ihnen die gewünschte Fehlertoleranz bieten (sogar bis zu SQL Server 2005 bei Verwendung der DB-Spiegelung und einer spiegelsensitiven Anwendung), aber mit Oracle RAC gibt es kein 1: 1.

Ein besserer Vergleich von AlwaysOn wäre die Data Guard-Funktion von Oracle. Aktiv-Passiv-Clustering. (Ja, Sie können aus dem Standby-Modus lesen, aber es ist schreibgeschützt, sodass immer noch nur ein Knoten aktiv ist. ")

Oracle RAC ist ein völlig anderes Tier und Aktiv-Aktiv-Clustering. Ich habe keine Änderungen gesehen, wenn Microsoft dies jemals implementieren möchte.

SQL Server 2012/2014 mit AlwaysOn bietet viele Funktionen, mit denen Sie Oracle RAC näher kommen - und in einigen Fällen verbessern können. (Denken Sie daran, dass Sie mit RAC Oracle App Server, Weblogic und JDBC verwenden müssen. Außerdem müssen Sie in einem einzigen Rechenzentrum arbeiten und die App kann nur eine Verbindung zu einem RAC-Cluster herstellen. Shared Storage bedeutet, dass RAC in der Cloud nicht funktioniert.) .

Mit AlwaysOn erhalten Sie schreibgeschützte Secondaries (4 in 12, 8 in 14) und Auto-Failover-Unterstützung. Einige Dinge sind jedoch eine Herausforderung - AlwaysOn unterstützt den Lastausgleich nicht. Wenn Sie kein Skript schreiben, wird immer der erste Server auf der Liste gezeichnet. Das Failover wirkt sich auch auf die App aus - es ist nicht transparent, sodass Apps möglicherweise neu gestartet werden müssen.

Vollständige Offenlegung - Ich arbeite für ein Unternehmen, das Software herstellt, die AlwaysOn erweitert. Unsere Software- Frontends für Datenbank-Lastausgleichssoftware SQL Server - sie führt im Auftrag der App eine Lese- / Schreibaufteilung durch, führt einen auf der Antwortzeit basierenden Lastausgleich durch, der sich über Rechenzentren erstreckt, und stellt eingehende Schreib- / Transaktionen während des Failovers in die Warteschlange, damit Apps keine Fehler sehen . Erfahren Sie, wie Microsoft, Dell, Quicken Loans und andere Unternehmen die ScaleArc-Software verwenden, um SQL Server AlwaysOn zu erweitern und RAC-ähnliche Funktionen ohne App-Änderungen zu erhalten.