Verzeihen Sie mir, wenn ich mich hier nicht ganz klar ausdrücken kann. Das ist nicht beabsichtigt, ich bin ein leitender Entwickler in einem sehr kleinen Unternehmen und muss mich im Moment wie ein Manager verhalten.
Wie dem auch sei, die Geschichte ist, dass wir 2 ältere Dell-Server mit SQL Server 2008 Standard in einem „Cluster“ haben. Ich habe das in Anführungszeichen gesetzt, weil mir immer noch nicht 100% klar ist, was das bedeutet. Wir haben 2 brandneue Blade-Server und möchten die vorhandenen Datenbanken auf die neue Hardware verschieben.
Ok, hier ist also der Haken. Wir müssen dies mit wenig oder gar keiner Ausfallzeit tun. Mir wird gesagt, dass wir den passiven Knoten auslagern und dann einen der neuen Server einbinden können. Mir wird aber auch gesagt, dass dies ein gefährlicher Schritt ist, weil etwas schiefgehen könnte, was zum Ausfall des Clusters führen würde, und dann stünden wir mit nichts da, weil der aktive Server nicht wieder hochfahren könnte.
Hat jemand eine Idee, wie man damit umgehen soll? Mir wurde gesagt, dass der einzige Weg, um Erfolg zu gewährleisten, darin besteht, mindestens einen Tag Ausfallzeit einzuplanen, in der wir einen neuen Cluster auf der neuen Hardware einrichten und dann die Datenbanken einzeln migrieren.
[Bearbeiten] Da es immer noch mit dieser Frage zusammenhängt, möchte ich noch eine weitere Frage hinzufügen. Ist es uns möglich, eine Maschine aus dem Cluster zu entfernen. Dann einen neuen Cluster mit dem entfernten Knoten als aktive Maschine erstellen und dann einen neuen Server dort einfügen? Bleibt der alte Cluster effektiv erhalten, während die neuen Maschinen ein- und ausgetauscht werden, falls etwas schief geht?
Antwort1
kaum oder keine Ausfallzeiten
Obwohl es jetzt wenig hilft, sollten Sie ein Unternehmen führen, wenn Sie hohe Verfügbarkeit benötigen. Die offensichtlichste Funktion, die Sie in dieser Situation verwenden würden, ist die Möglichkeit, bis zu 16 Knoten in einem Cluster zu haben. In Ihrem Fall hätten Sie also einfach zwei weitere Knoten hinzugefügt und dann die entfernt, die Sie nicht mehr wollten. Ich würde in Betracht ziehen, die Version zu aktualisieren, während Sie die Hardware aktualisieren
... Mir wird aber auch gesagt, dass dies ein gefährlicher Schritt ist, weil etwas schiefgehen könnte, was zu einem Ausfall des Clusters führen würde, und dann stünden wir mit nichts da, weil der aktive Server nicht wieder hochfahren könnte.
Alles ist möglich. Ich habe noch nie erlebt, dass ein Server 208 SQL 2008-Failovercluster einfach ausfällt, aber theoretisch ist es möglich. Beachten Sie, dass der aktive Knoten während des Knotenupgrades nicht „down“ ist, sodass nichts heruntergefahren werden muss. Der Cluster läuft einfach auf einem Knoten ohne die Möglichkeit eines Failovers. Der vernünftige Worst-Case-Szenario ist, dass der alte Knoten irgendwie ausfällt und der Ersatz nicht hinzugefügt wird. In diesem Fall würden Sie ohne Failover-Funktion laufen, bis das Problem, das dazu führt, dass der Server nicht hinzugefügt wird, behoben ist.
Mir wurde gesagt, dass der einzige Weg, den Erfolg sicherzustellen, darin besteht, mindestens einen Tag Ausfallzeit einzuplanen, während der wir einen neuen Cluster auf der neuen Hardware hochfahren und dann die Datenbanken einzeln migrieren.
Das ist wahrscheinlich die einzige Möglichkeit, den Erfolg desjenigen sicherzustellen, der die Arbeit erledigt. Ich würde die unschuldige Frage stellen: „Wenn es einen Tag Ausfallzeit braucht, um einen Cluster zu verschieben, warum sollte ich dann überhaupt einen Cluster erstellen? Ich könnte zwei Maschinen kaufen und eine davon ausgeschaltet lassen und für diese Art von Verfügbarkeit einsatzbereit lassen.“ Kurz gesagt, Sie müssen jemanden finden, der tatsächlich mit Clustern arbeitet und die damit verbundene Technologie versteht. Vorausgesetzt, es gibt keine einzigartigen Probleme (z. B. hat Ihr Unternehmen einigefastclusterfähige Software, die auf dem Cluster läuft) Ich würde denken, dass es den meisten professionellen Microsoft-Administratoren peinlich wäre zu sagen, dass es einen Tag Ausfallzeit erfordern würde, um Hardware zu einem bestehenden, funktionierenden Cluster zu ersetzen/hinzuzufügen
Antwort2
Zunächst einmal ist die empfohlene Strategie am Ende Ihrer Frage die, die ich auch empfehlen würde, aber da dies keine Option ist, würde ich es so handhaben. Sie scheinen sich über einen Cluster nicht im Klaren zu sein. Im Grunde haben beide Server SQL und Clusterdienste installiert. Mit einem Befehl über Clusterdienste können Sie SQL von einem Server auf einen anderen „rollen“. Wenn ich an Ihrer Stelle wäre, würde ich es so machen, wie Sie vorgeschlagen haben: alle Dienste auf einen Knoten rollen, den zweiten Knoten aus dem Cluster entfernen, einen Ihrer neuen Server als Clusterknoten hinzufügen, alle Dienste auf den neuen Clusterknoten rollen, den zweiten neuen Knoten hinzufügen und den zweiten alten Knoten aus dem Cluster entfernen.
**Bitte beachten Sie: Wenn Sie mit Cluster-Diensten und/oder geclusterten SQL-Installationen nicht vertraut sind und dies auf Ihrem Live-System versuchen, kann dies sehr, sehr schlimm für Sie enden. Und zwar weitaus schlimmer als der geplante Ausfalltag von einem Tag. Ich würde entweder einen Berater mit Erfahrung mit Clustern beauftragen oder, falls dies nicht möglich wäre, eine Testumgebung einrichten, in der der Prozess gründlich getestet werden kann.
Hierist ein Link zu den Schritten zum Hinzufügen eines Knotens zu Ihrem Cluster.
Antwort3
Sie müssen den alten Cluster überhaupt nicht zerstören, es sei denn, Sie möchten die Hardware erneut verwenden. Ich würde Folgendes empfehlen:
- Erstellen Sie einen neuen Cluster mit den neuen Blades
- Installieren Sie SQL auf dem neuen Cluster. Behalten Sie die Laufwerkbuchstaben, Pfade, Ports und Instanznamen (falls zutreffend) bei.
- Nach der Installation müssen Sie die Master- und msdb-Datenbanken vom alten SQL-Server auf den neuen Server wiederherstellen bzw. ersetzen, um die Logins und Jobs abzurufen. Alternativ können Sie die Jobs auch auf dem alten Server ausführen und sp_help_revlogins verwenden.
- Protokollieren oder spiegeln Sie die Datenbank vom alten Server auf den neuen, um die Daten auf den neuesten Stand zu bringen.
Dadurch wird Ihre neue Instanz in den gleichen Zustand wie die alte versetzt, zusammen mit einer Neuinstallation des Betriebssystems und von SQL. Um auf den neuen Cluster umzusteigen, können Sie Folgendes tun, vorausgesetzt, der Name Ihrer alten Instanz ist INSTA und der der neuen Instanz ist INSTB:
- Alte SQL-Instanz offline nehmen
- Wiederherstellen der Datenbanken auf dem neuen Server
- Löschen Sie den INSTA-DNS-Eintrag aus dem DNS des Active Directory
- Erstellen Sie einen neuen CNAME (Alias) DNS-Eintrag in Active Directory DNS, der auf INSTB verweist
Sobald dies erledigt ist, sollten die Anwendungen eine Verbindung zum alten Namen der SQL-Instanz herstellen, aber dadurch werden sie zum neuen Server weitergeleitet. Möglicherweise müssen Sie „ipconfig /flushdns“ auf allen Anwendungsservern ausführen, damit die DNS-Änderung schneller funktioniert. Achten Sie darauf, den alten Namen anzupingen, um zu sehen, wann er zurückverweist. Wir verwenden diese Methode für die Umstellung, da wir damit den alten Cluster behalten können, falls wir ein Rollback durchführen müssen. Sie können die alte SQL-Instanz erst dann hochfahren, wenn Sie den Parameter „SQL Server Network Name“ in etwas anderes ändern. Sobald dies erledigt ist, können Sie den DNS-Alias einfach wieder auf den alten verweisen, wenn Sie ein Rollback durchführen möchten.
Antwort4
Ohne die Hardware-Besonderheiten zu kennen und zu wissen, ob das funktionieren würde, würde ich vorschlagen, ein Image des alten passiven Knotens auf den neuen Server zu übertragen. Wenn Sie etwas wie Acronis verwenden, das das Übertragen des Images auf neue Hardware ermöglicht, sollten Sie den passiven Knoten grundsätzlich auf die neue Hardware verschieben können. Dort angekommen können Sie ihn einschalten und überprüfen, ob er ordnungsgemäß funktioniert (so gut Sie können) und dann versuchen, ihn auf die neue Hardware umzustellen. Obwohl viele Dinge schiefgehen können, wie Jim B sagte, besteht eine gute Chance, dass er entweder ordnungsgemäß auf die neue Hardware umgestellt wird oder nicht funktioniert und Sie einfach zur alten Hardware zurückkehren müssen. Wenn es funktioniert, können Sie den Vorgang auf dem anderen Knoten wiederholen. Wenn nicht, können Sie den alten passiven Knoten einfach wieder einschalten (den Sie nicht zerstören müssten) und etwas anderes versuchen.