Ich finde, dass Leute, die eine Oracle RAC-Architektur entwerfen, oft nicht an N+1-Redundanz in ihren Implementierungsplänen denken. Es gibt zwei Gründe für die Implementierung von Oracle RAC:Verfügbarkeit und Skalierbarkeit. Für die Zwecke dieser Diskussion konzentriere ich mich nur auf die Verfügbarkeitsseite. Wenn Ihre RAC-Bereitstellungen nur Skalierbarkeitsgründen dienen, trifft dieses Thema möglicherweise nicht auf Sie zu.
Was ist also N+1-Redundanz? Einfach ausgedrückt, wenn Sie N Einheiten von etwas benötigen, sollten Sie aus Redundanzgründen N + 1 von diesem Artikel haben. Schauen wir uns einen Datenbankserver an. Es muss eine Stromversorgung haben. Das ist eine Voraussetzung. Ohne eine funktionierende Stromversorgung funktioniert der Server überhaupt nicht. Die Mindestanzahl an Netzteilen ist 1. Wenn wir möchten, dass dieser Server ein hohes Maß an Verfügbarkeit hat, stellen wir sicher, dass er über N+1-Netzteile oder in diesem Fall über zwei Netzteile verfügt. Wenn nur ein Netzteil vorhanden ist und dieses ausfällt, nimmt es den Server mit. Wenn wir ein zusätzliches Netzteil haben, ein Ersatzgerät, wird der Ausfall eines Netzteils den Server nicht mit sich bringen. Redundanz ist eine großartige Sache und eine wesentliche Komponente einer Infrastruktur mit hoher Verfügbarkeit.
Beim Entwerfen eines Oracle RAC-Systems muss der DBA bestimmen, wie viele Knoten benötigt werden, um die Anforderungen des Endbenutzers zu unterstützen. Wenn der DBA feststellt, dass 4 Knoten erforderlich sind und dieser RAC-Cluster Hochverfügbarkeitsmerkmale aufweisen muss, muss der DBA unbedingt einen 5-Knoten-Cluster (4+1) erstellen. Wenn die Ressourcenanforderungen ausreichen, um 4 Knoten zu beschäftigen, und ein Knoten ausfällt, können die verbleibenden 3 mit der Arbeitslast nicht Schritt halten. Wenn der DBA das RAC-System mit N+1-Fähigkeit erstellt, wird der Verlust eines Knotens von den Endbenutzern nicht bemerkt. Wenn der DBA den RAC-Cluster ohne N+1-Redundanz aufbaut, kann der Verlust eines Knotens so schrecklich für die Leistung des Endbenutzers sein, dass der gesamte Cluster genauso gut ausfallen könnte. Streben Sie beim Entwerfen Ihrer RAC-Implementierungen nach N+1-Redundanz.
Ich erinnere mich, dass ich vor zwei Jahren einen RAC-Cluster hatte, der einen Knoten verlor. Kein Problem, wir hatten noch zwei Knoten frei. Als ich die Leistung der beiden verbleibenden Knoten beobachtete, schienen sie ziemlich überfordert zu sein. Unser Callcenter begann, Beschwerden zu erhalten. Ich habe mit anderen Administratoren im IT-Team zusammengearbeitet, um diesen Knoten so schnell wie möglich wieder zum Laufen zu bringen, aber dies ist möglicherweise nicht immer der Fall, wenn der Grund für den Ausfall hardwarebezogen ist und Teile ersetzt werden müssen. Nachdem der Knoten wieder in Betrieb war, überwachte ich die Clusterleistung noch Wochen später. Unsere Nutzung hat zugenommen, seit dieses System ursprünglich entwickelt wurde. Wir hatten dieses System ursprünglich mit Blick auf N+1-Redundanz entwickelt, aber unsere Nutzung wuchs und N ging von 2 auf 3. Unser aktuelles 3-Knoten-Cluster war nicht mehr N+1-redundant. Also habe ich mit dem Management zusammengearbeitet, um genügend Mittel in das Budget des nächsten Jahres einzuplanen, um einen neuen Knoten zu beschaffen und sicherzustellen, dass Oracle dafür lizenziert wurde. Ich schlafe nachts viel besser, da ich weiß, dass ich wieder N+1-Redundanz habe.
Wie viele Implementierungen da draußen ist mein RAC-System nicht die einzige Hochverfügbarkeitsfunktion, die in unsere Infrastruktur integriert ist. Diese RAC-Datenbank ist eine Primärdatenbank für eine physische Standby-Datenbank mit Oracle Data Guard. Ich bin überrascht, wenn ich mit anderen Oracle-DBAs über RAC-Standby-Datenbanken spreche, wie viele von ihnen nicht an N+1-Fähigkeit für ihre Standby-Datenbank denken. Die physische Standby-Datenbank ist mein Sicherheitsnetz, falls das primäre Rechenzentrum aus irgendeinem Grund nicht verfügbar ist. Ich habe so viele Oracle-DBAs gesehen, die eine Einzelinstanz-Standby für einen primären RAC mit mehreren Knoten implementiert haben. Autsch! Ich hoffe, sie müssen nie ausfallen. Die Arbeitslast ihres gesamten Multi-Node-RAC-Clusters wird auf dieser Standby-Instanz mit einer einzigen Instanz mächtig zu kämpfen haben. Berücksichtigen Sie also beim Entwerfen Ihrer RAC-Implementierungen sowohl für den primären als auch für den Standby die Auswirkungen der N+1-Redundanz auf das Architekturdesign.
Wo ich mich wahrscheinlich von vielen Leuten unterscheide, ist, dass meine physischen Standby-Implementierungen nicht N+1-fähig sind, sondern N. Ich überspringe den redundanten zusätzlichen Knoten für meinen physischen Standby. Warum ist das so? Rein aus Kostensicht. Meine physische Bereitschaft ist nur ein Sicherheitsnetz. Ich möchte, dass es an dem Tag funktioniert, an dem ich es brauche. Aber ich werde es hoffentlich nie brauchen. Die physische Bereitschaft ist meine Versicherungspolice für den Fall, dass das Risiko Wirklichkeit wird. Für mich ist dieses zusätzliche „+1“ am Standby-Standort eine Überversicherung. Ich kann die physische Hardware und die Oracle-Lizenzierung sparen.
Nehmen wir also an, der Tag kommt und ich führe ein Failover zum Standby durch. Ich habe meine N+1-Redundanz verloren. Aber wie hoch ist die Wahrscheinlichkeit, dass ich das primäre Rechenzentrum verliere *und* einen der Knoten in meinem Standby-Cluster verliere? Ziemlich geringe Chancen. Die Wahrscheinlichkeit von Ausfällen an zwei Standorten gleichzeitig ist ziemlich gering. An diesem Punkt wertet unser IT-Team aus, warum unser primäres Rechenzentrum verloren gegangen ist und wann wir unseren Betrieb höchstwahrscheinlich an diese Einrichtung zurückführen können. Wenn das primäre Rechenzentrum seine gesamte Energie verloren hat und der Energieversorger sagt, dass der Dienst bis morgen wiederhergestellt wird, werden wir einfach im Standby-Rechenzentrum laufen, obwohl wir dort nur N Knoten für die RAC-Datenbank haben. Wenn jedoch das primäre Rechenzentrum durch einen Brand zerstört wurde, kann es viele Monate dauern, bis es wieder in Betrieb ist. An diesem Punkt muss ich planen, diesen physischen Standby-Modus auf eine N+1-Redundanz zu bringen, da unsere Zeit, in der wir diesen Standby-Modus als primären verwenden, viel länger dauern wird. Also bestellen wir schnell einen weiteren Server und fügen ihn dem Cluster so schnell wie möglich hinzu. Daher entwerfe ich meine Standby-RAC-Datenbank als N, nicht als N+1, mit dem Ziel, sie in Kürze auf N+1 zu erhöhen, wenn wir feststellen, dass wir die Standby-Datenbank für einen längeren Zeitraum wirklich verwenden werden.
Es gibt also noch einen weiteren Spezialfall, den ich diskutieren möchte. Dort stellt der DBA fest, dass N =1 ist. Für die aktuellen Workload-Anforderungen ist ein Knoten ausreichend. Aber wir wollen Hochverfügbarkeit haben, also entwerfen wir einen RAC-Cluster mit zwei Knoten für die primäre Datenbank. Wir haben jetzt N+1-Redundanz in die Primärseite eingebaut. Nach meinem letzten Absatz benötigt meine Standby-Datenbank nur 1 Knoten. Der Fehler, den ich bei einigen Leuten sehe, besteht darin, die Standby-Datenbank als Einzelinstanzdatenbank zu erstellen. Soweit macht ihre Logik Sinn. Primär ist N+1 und Standby ist N. So weit so gut. Wo ich mich unterscheide, ist, dass ich den Standby zu einem Ein-Knoten-RAC-Cluster mache, nicht zu einer reinen Einzelinstanz-Implementierung. Der Grund liegt im zukünftigen Wachstum. Irgendwann stellt der DBA möglicherweise fest, dass N auf der Primärseite nicht mehr gleich 1 ist. Die Nutzung hat zugenommen und N muss jetzt 2 sein. Der DBA möchte den Primärknoten auf 3 Knoten (2+1) erweitern. Dies lässt sich einfach und ohne Ausfallzeit herunterfahren, um einen neuen Knoten zum Cluster hinzuzufügen und die RAC-Datenbank auf diesen neuen Knoten zu erweitern. Aber es ist im Standby nicht so einfach, den Standby zu einem 2-Knoten-Cluster zu machen, wenn dieser 1 vorhandene Knoten nicht RAC-fähig ist. Wenn nur eine reine Einzelinstanz-Standby vorhanden ist, muss der DBA sie verwerfen und in einen Zwei-Knoten-Cluster verschieben. Wenn der DBA vorausschauend installiert und die Grid-Infrastruktur so installiert hat, als ob der physische Standby-Cluster ein Einzelknoten-Cluster wäre, muss der DBA nur einen neuen Knoten hinzufügen, genau wie er es auf der Primärseite getan hat.
Stellen Sie beim Entwerfen Ihrer RAC-Implementierungen sicher, dass Sie über N+1-Fähigkeit auf dem primären und mindestens N auf dem Standby verfügen. Wenn ein Unternehmen feststellt, dass der Standby-Modus zu kritisch ist, möchte es möglicherweise auch N+1 im Standby-Modus implementieren. Wenn der DBA feststellt, dass N =1, sollten Sie erwägen, den Standby-Cluster auf mindestens einen RAC-Cluster mit einem einzelnen Knoten zu setzen.
