Beschreiben von Recovery Time Objective und Recovery Point Objective
Das Verständnis der Vorgaben für Wiederherstellungszeit (RTO) und Wiederherstellungspunkt (RPO) ist entscheidend für Ihren Hochverfügbarkeits- und Notfallwiederherstellungsplan (HADR), da sie die Grundlage für jede Verfügbarkeitslösung darstellen.
Wiederherstellungszeitvorgabe
Recovery Time Objective (RTO) ist der maximale Zeitraum, der zur Verfügung steht, um Ressourcen nach einem Ausfall oder Problem wieder online zu bringen. Wenn dieser Prozess länger dauert als die RTO, kann dies Konsequenzen haben, wie z. B. Strafzahlungen, nicht erledigte Arbeiten usw. RTO kann sowohl für die gesamte Lösung, die alle Ressourcen umfasst, als auch für einzelne Komponenten wie SQL Server-Instanzen und Datenbanken angegeben werden.
Wiederherstellungspunktvorgabe
Recovery Point Objective (RPO) ist der Zeitpunkt, bis zu dem eine Datenbank wiederhergestellt sein sollte, und entspricht der maximalen Menge an Datenverlust, den das Unternehmen zu akzeptieren bereit ist. Angenommen, eine IaaS-VM, die SQL Server enthält, fällt um 10:00 Uhr aus, und die Datenbanken innerhalb der SQL Server-Instanz haben eine RPO von 15 Minuten. Unabhängig davon, welche Funktion oder Technologie verwendet wird, um diese Instanz und ihre Datenbanken wiederherzustellen, ist die Erwartung, dass maximal 15 Minuten an Daten verloren gehen. Das bedeutet, dass die Datenbank bis 9:45 Uhr oder später wiederhergestellt werden kann, um einen minimalen bis gar keinen Datenverlust bei Einhaltung der angegebenen RPO zu gewährleisten. Es kann Faktoren geben, die bestimmen, ob diese RPO erreichbar ist.
Definieren von Recovery Time Objective und Recovery Point Objective
RTOs und RPOs werden von geschäftlichen Anforderungen bestimmt, basieren aber auch auf verschiedenen technologischen und anderen Faktoren, wie z. B. den Fähigkeiten und Fertigkeiten der Administratoren (nicht nur der DBAs). Auch wenn das Unternehmen vielleicht keine Ausfallzeiten oder gar keinen Datenverlust wünscht, ist dies aus verschiedenen Gründen eventuell nicht realistisch oder möglich. Zur Bestimmung der RTO und RPO für Ihre Lösung sollte eine offene und ehrliche Diskussion zwischen allen beteiligten Parteien geführt werden.
Einer der entscheidenden Aspekte sowohl für die RTO als auch für die RPO ist die Kenntnis der Kosten von Ausfallzeiten. Wenn Sie diese Zahl und den Gesamteffekt, den ein Ausfall oder eine Nichtverfügbarkeit für das Unternehmen hat, definieren, lassen sich auch Lösungen leichter definieren. Wenn das Unternehmen beispielsweise 10.000 USD pro Stunde verlieren kann oder von einer Regierungsbehörde mit einer Geldstrafe belegt werden könnte, wenn etwas nicht verarbeitet werden konnte, ist das eine messbare Größe zum Definieren von RTO und RPO. Die Ausgaben für die Lösung sollten im Verhältnis zum Umfang bzw. zu den Kosten der Ausfallzeit stehen. Wenn Ihre HADR-Lösung X USD kostet, Sie aber im Falle eines Problems nur wenige Sekunden statt Stunden oder Tage betroffen sind, hat sie sich bereits bezahlt gemacht.
Von einem nicht geschäftlichen Standpunkt aus betrachtet, sollte die RTO sowohl auf Komponentenebene (z. B. SQL Server) als auch für die gesamte Anwendungsarchitektur definiert werden. Die Fähigkeit, sich von einem Ausfall zu erholen, ist nur so gut wie ihr schwächstes Glied. Wenn z. B. SQL Server und seine Datenbanken in fünf Minuten online gebracht werden können, die Anwendungsserver aber 20 Minuten dafür brauchen, beträgt die Gesamt-RTO 20 Minuten, nicht fünf. Die SQL Server-Umgebung könnte immer noch eine RTO von fünf Minuten haben, doch würde sich die Gesamtzeit für die Wiederherstellung dadurch nicht ändern.
RPO befasst sich speziell mit Daten und hat direkten Einfluss auf das Design jeder HADR-Lösung sowie auf administrative Richtlinien und Verfahren. Die verwendeten Funktionen müssen die definierten RTOs wie auch RPOs unterstützen. Wenn z. B. Transaktionsprotokollsicherungen alle 30 Minuten geplant sind, aber eine RPO von 15 Minuten besteht, könnte eine Datenbank nur bis zur letzten verfügbaren Transaktionsprotokollsicherung wiederhergestellt werden, die im schlechtesten Fall 30 Minuten her wäre. Dieses Timing setzt voraus, dass keine anderen Probleme auftreten und die Sicherungen getestet wurden und bekanntermaßen fehlerfrei sind. Auch wenn es schwierig ist, jede Sicherung zu testen, die für jede Datenbank in Ihrer Umgebung erstellt wird, sind Sicherungen doch auch nur Dateien auf einem Dateisystem. Ohne zumindest regelmäßige Wiederherstellungen durchzuführen, gibt es keine Garantie, dass sie fehlerfrei sind. Die Durchführung von Prüfungen während des Sicherungsvorgangs kann Ihnen ein gewisses Maß an Sicherheit geben.
Die verwendeten spezifischen Funktionen, wie z. B. eine Always On-Verfügbarkeitsgruppe oder eine Always On-Failoverclusterinstanz (FCI), wirken sich ebenfalls auf Ihre RTOs und RPOs aus. Je nachdem, wie die Funktionen konfiguriert sind, kann es bei IaaS- oder PaaS-Lösungen zu einem automatischen Failover auf einen anderen Standort kommen oder auch nicht, was zu längeren Ausfallzeiten führen könnte. Durch die Definition von RTO und RPO kann die technische Lösung, die diese Anforderung unterstützt, in Kenntnis der Toleranzen für Zeit und Datenverlust entworfen werden. Wenn sich diese als unrealistisch herausstellen, müssen RTOs und RPOs entsprechend angepasst werden. Wenn z. B. eine gewünschte RTO von zwei Stunden besteht, das Kopieren einer Sicherung auf den Zielserver zur Wiederherstellung aber drei Stunden benötigt, ist der RTO bereits verfehlt. Diese Arten von Faktoren müssen bei der Bestimmung Ihrer RTOs und RPOs berücksichtigt werden.
Es sollten RTOs und RPOs sowohl für die Hochverfügbarkeit als auch für die Notfallwiederherstellung definiert werden. Hochverfügbarkeit wird als ein eher lokal angesiedeltes Ereignis betrachtet, von dem eine Wiederherstellung leichter möglich ist. Ein Beispiel für Hochverfügbarkeit wäre eine Verfügbarkeitsgruppe, die automatisch ein Failover von einem Replikat auf ein anderes innerhalb einer Azure-Region ausführt. Das kann Sekunden dauern, und zu diesem Zeitpunkt müssten Sie sicherstellen, dass die Anwendung nach dem Failover eine Verbindung herstellen kann. Die Ausfallzeit von SQL Server wäre minimal. Eine lokale RTO oder RPO kann in Abhängigkeit von der kritischen Natur der Lösung oder des Systems möglicherweise in Minuten gemessen werden.
Eine Notfallwiederherstellung käme dem Aufbau eines komplett neuen Rechenzentrums gleich. Das Puzzle besteht aus vielen Teilen, von denen SQL Server nur eine Komponente ist. Alles online zu bringen, kann Stunden oder länger dauern. Aus diesem Grund sind die RTOs und RPOs getrennt. Auch wenn viele der Technologien und Funktionen, die für Hochverfügbarkeit und Notfallwiederherstellung verwendet werden, gleich sind, sind es der Aufwand und die Zeit, die damit verbunden sind, möglicherweise nicht.
Alle RTOs und RPOs sollten formell dokumentiert und regelmäßig oder bei Bedarf überprüft werden. Sobald sie dokumentiert sind, können Sie überlegen, welche Technologien und Funktionen Sie für die Architektur verwenden können.