Die Planung und Einführung eines Hochverfügbarkeits- und Notfallwiederherstellungsplans, der alle Service Level Agreements erfüllt, ist kein triviales Unterfangen und erfordert ein sehr klares Verständnis der nativen Stärken und Schwächen von SQL Server. Beim Abgleich von Anforderungen mit einer Kombination von Funktionen werden einige der kritischen Details möglicherweise beschönigt, und in diesem Beitrag gehe ich auf einige häufige Verzerrungen und schlechte Annahmen ein, die sich in eine Lösung einschleichen können – was letztendlich dazu führt, dass wir das Ziel verfehlen zu unseren Zielen für Wiederherstellungspunkt und Wiederherstellungszeit. Einige der Beispiele für Verzerrungen oder Selbsttäuschungen, die ich hier beschreibe, können über verschiedene Merkmale verallgemeinert werden, und einige sind merkmalsspezifisch.
"Wir haben unseren Notfallwiederherstellungsplan getestet, als wir unser Projekt zum ersten Mal gestartet haben, und wir wissen, dass er funktionieren wird"
Ich habe mit Kunden zusammengearbeitet, die ihren Disaster-Recovery-Ansatz tatsächlich „richtig“ gemacht haben – einmal. Aber nachdem sich alle von der Wirksamkeit der Lösung überzeugt hatten, wurden keine weiteren Disaster-Recovery-Übungen mehr durchgeführt. Natürlich – mittlerweile ändern sich die Datenebene und die Anwendung im Laufe der Zeit. Diese Änderungen führen neue Objekte und Prozesse ein, die für die Anwendung kritisch sind. Und selbst wenn nach dem Start alles stagniert, müssen Sie immer noch mit Personalfluktuation und unterschiedlichen Fähigkeiten rechnen. Können die Mitarbeiter von heute eine Disaster-Recovery-Übung erfolgreich durchführen? Und selbst die besten Mitarbeiter brauchen ständige Übung.
"Wir werden keinen Datenverlust haben, da wir synchrone Datenbankspiegelung verwenden"
Angenommen, Sie verwenden die synchrone Datenbankspiegelung zwischen zwei SQL Server-Instanzen, wobei sich jede Instanz in einem separaten Rechenzentrum befindet. Nehmen Sie in diesem Beispiel an, dass die Transaktionslatenz akzeptabel ist, obwohl es sich um eine synchrone Datenbankspiegelungssitzung mit einigen Meilen zwischen den Rechenzentren handelt. Sie haben keinen Zeugen in der Mischung, weil Sie das Failover der Datenbankspiegelung manuell steuern möchten.
Nehmen wir nun an, Ihr Disaster-Recovery-Rechenzentrum fällt weg – aber Ihr primäres Rechenzentrum ist noch verfügbar. Ihre Prinzipaldatenbank ist von der Spiegeldatenbank getrennt, akzeptiert aber weiterhin Verbindungen und Datenänderungen. Was ist jetzt mit der Anforderung „kein Datenverlust“? Wenn Transaktionen für eine weitere Stunde mit dem getrennten Prinzipal ausgeführt werden, was ist Ihr Plan, wenn das primäre Rechenzentrum ebenfalls ausfällt?
"Unser Geschäftsinhaber sagt, dass wir bis zu 12 Stunden Daten verlieren können"
Es ist wichtig, einige Fragen mehr als einmal und an mehr als eine Person in einer Organisation zu stellen. Wenn Ihnen jemand sagt, dass „12 Stunden Datenverlust akzeptabel sind“ – fragen Sie ihn noch einmal oder fragen Sie ihn, welche Folgen dieser Datenverlust hätte. Frag auch andere Leute. Sie könnten Ihnen eine viel strengere Anforderung stellen. Ich habe festgestellt, dass Ziele für Wiederherstellungspunkte einige Verhandlungen und mehr als nur ein paar nachdenkliche, wohlüberlegte Diskussionen erfordern.
"Wir verwenden [Datenbankspiegelung oder Verfügbarkeitsgruppen] und sind daher für das abgesichert, was wir im Katastrophenfall benötigen"
Datenbankspiegelung und Verfügbarkeitsgruppen können sicherlich verwendet werden, um Sie auf Datenbankebene zu schützen, aber was ist mit allem anderen? Was ist mit Ihren Logins? SSIS-Pakete? Arbeitsplätze? Nicht vollständige Wiederherstellungsmodelldatenbanken? Verbundene Server?
"Wir verwenden die SQL Server-Funktion XYZ, sodass wir keine In-Flight-Transaktionen verlieren"
Nein Entschuldigung. Während einige Funktionen eine transparente Umleitung ermöglichen, ist dies nicht dasselbe wie das Aufbewahren und Fortbestehen offener Transaktionen zum Zeitpunkt des Failovers. Keine SQL Server-Funktion bietet diese Funktionalität heute.
"Das Team, das die Datenebene für diese Anwendung unterstützt, hasst die SQL Server-Funktion XYZ, aber wir machen weiter damit, weil uns das von einem externen Berater empfohlen wurde"
Obwohl es schön wäre, wenn die Leute keine spezifischen Vorurteile in Bezug auf Funktionen in SQL Server entwickeln würden, ist dies oft nicht der Fall. Wenn Sie versuchen, einem Personal, das nicht mit an Bord ist, Lösungen aufzuzwingen, laufen Sie Gefahr, vorab zu scheitern. Im Rahmen der HA/DR-Übungen, bei denen ich in der Vergangenheit mitgeholfen habe, bin ich immer daran interessiert, von den Erfahrungen der Menschen mit bestimmten Merkmalen zu hören. Einige Unternehmen nutzen beispielsweise Hunderte von Failover-Cluster-Instanzen sehr gut – während andere sie aufgrund schlechter Erfahrungen mit früheren Versionen vermeiden. Bei der Planung einer Lösung dürfen Sie die Historie oder die Prädispositionen der Mitarbeiter, die letztendlich für die Bereitstellung und Unterstützung der empfohlenen Lösung verantwortlich sein werden, nicht ignorieren.
"Als DBA entscheide ich, welche HA/DR-Technologie für die Datenebene verwendet wird, also werden wir in Zukunft Verfügbarkeitsgruppen verwenden"
Ein Datenbankadministrator könnte möglicherweise eine Datenbankspiegelung ohne oder mit nur geringer Beteiligung anderer Teams einrichten. Jetzt mit Verfügbarkeitsgruppen, selbst wenn ein Datenbankadministrator alles alleine machen könnte, wäre es unklug, dies zu tun. Schließlich – wenn Sie Verfügbarkeitsgruppen für Disaster Recovery-Zwecke bereitstellen, möchten Sie, dass alle an einem Disaster Recovery-Vorgang Beteiligten Ihre Lösung und die Anforderungen kennen, die erforderlich sind, um erfolgreich wieder online zu gehen und Daten wiederherzustellen. Bei Verfügbarkeitsgruppen müssen Sie an den Windows Server-Failovercluster, Quorumkonfigurationen, Knotenabstimmungen, den Verfügbarkeitsgruppenlistener und mehr denken. Wenn Sie andere Personen benötigen, um eine Lösung zu finden, stellen Sie sicher, dass sie an der ersten Empfehlung beteiligt sind.
"Wir verwenden Verfügbarkeitsgruppen, damit wir im Falle eines Ausfalls unseres Read-Write-Replikats eine schreibgeschützte Verfügbarkeit haben können"
Dies ist nur ein Beispiel für ein „Was wäre wenn“-Szenario. Bei jeder Implementierung von Funktionen sollten Sie sich die verschiedenen Möglichkeiten vorstellen, auf die Fehler auftreten können – und diese dann unbedingt testen, um sicherzustellen, dass Ihre Anforderungen weiterhin erfüllt werden. Wenn Sie beispielsweise der Meinung sind, dass die asynchronen schreibgeschützten Replikate Ihrer SQL Server 2012-Verfügbarkeitsgruppe verfügbar sein werden, wenn das Read-Write-Replikat nicht verfügbar ist, werden Sie unangenehm überrascht sein, wenn Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections Nachricht in Produktion.
"Wir haben die SQL Server-Funktion XYZ getestet und das Failover war schnell, also haben wir festgestellt, dass wir unsere Ziele für die Wiederherstellungszeit problemlos erreichen können"
Angenommen, Sie entscheiden sich für die Verwendung der Datenbankspiegelung für eine hohe Verfügbarkeit auf Benutzerdatenbankebene. Sie möchten ein schnelles Failover (gemessen in Sekunden) und sehen tatsächlich ein schnelles Failover während des Testens. Aber war es ein realistischer Test? Haben Sie eine erhebliche Arbeitsbelastung vorangetrieben? Im Beispiel der Datenbankspiegelung kann der längste Teil Ihres Failover-Vorgangs für die Redo-Vorgänge sein. Wenn Sie keine realistischen Workloads fahren, können Sie nicht wirklich sagen, dass Ihr Failover tatsächlich „schnell“ sein wird.
"Wenn wir eine Katastrophe haben und Daten retten und abgleichen müssen, werden wir es herausfinden, wenn die Zeit gekommen ist"
Dies ist eine schwierige Frage. Angenommen, Sie haben eine Katastrophe und müssen Ihr sekundäres Rechenzentrum wieder in Betrieb nehmen. Sie beschließen, den Dienst für die kritischsten Datenbanken im sekundären Rechenzentrum zu erzwingen, und Sie haben jetzt eine Aufteilung in der Herkunft der Datenänderungen (einige nicht abgestimmte Zeilen im primären Rechenzentrum und jetzt neue Änderungen im sekundären Rechenzentrum). Schließlich wird Ihr primäres Rechenzentrum online gebracht – aber jetzt haben Sie Daten, die gerettet und abgeglichen werden müssen, bevor Sie die HA/DR-Gesamtlösung wiederherstellen können. Wie geht's? Was kannst du tun? Diese Diskussion ist selten einfach und kann von mehreren Faktoren abhängen, wie z. B. den von Ihnen erworbenen Softwarepaketen, der Komplexität der Datenebene und den Ihnen zur Verfügung stehenden Datenkonvergenztools. Tatsächlich ist die Diskussion normalerweise so schwierig, dass die Leute sie überhaupt nicht haben. Aber wenn die Daten so kritisch sind, dass Sie ein sekundäres Rechenzentrum eingerichtet haben, dann sollte ein wichtiger Teil der Diskussion darin bestehen, wie Daten am besten gerettet und nach einem Notfall abgeglichen werden können.
Zusammenfassung
Dieser Artikel enthält nur einige Beispiele dafür, wie wir uns der Illusion hingeben können, dass eine Lösung ihre Anforderungen vollständig erfüllt. Obwohl es in der Natur des Menschen liegt, wird unsere Arbeit in Bezug auf Datenverlust und Geschäftskontinuität davon abhängen, dass wir unsere eigenen Überzeugungen und Annahmen aggressiver prüfen.
