Hersteltijddoelstelling en herstelpuntdoelstelling beschrijven
Inzicht in de beoogde hersteltijd en herstelpunten zijn van cruciaal belang voor uw HADR-plan (hoge beschikbaarheid en herstel na noodgevallen), omdat ze de basis vormen voor elke beschikbaarheidsoplossing.
Beoogde hersteltijd
Recovery Time Objective (RTO) is de maximale hoeveelheid tijd die beschikbaar is om resources online te brengen na een storing of probleem. Als dat proces langer duurt dan de RTO, kunnen er gevolgen zijn, zoals financiële sancties, werk dat niet kan worden uitgevoerd, enzovoort. RTO kan worden opgegeven voor de hele oplossing, waaronder alle resources, evenals voor afzonderlijke onderdelen, zoals SQL Server-exemplaren en -databases.
Beoogde herstelpunt
Recovery Point Objective (RPO) is het tijdstip waarop een database moet worden hersteld en gelijk is aan de maximale hoeveelheid gegevensverlies die het bedrijf wil accepteren. Stel dat een IaaS-VM met SQL Server om 10:00 uur een storing ondervindt en dat de databases binnen het SQL Server-exemplaar een RPO van 15 minuten hebben. Ongeacht welke functie of technologie wordt gebruikt om dat exemplaar en de bijbehorende databases terug te brengen, is de verwachting dat er maximaal 15 minuten aan gegevens verloren gaan. Dit betekent dat de database kan worden hersteld naar 9:45 uur of later om ervoor te zorgen dat er minimaal tot geen gegevensverlies is voldaan aan de vermelde RPO. Er kunnen factoren zijn die bepalen of die RPO haalbaar is.
Doelstellingen voor hersteltijd en herstelpunt definiëren
RPO's en RPO's worden aangestuurd door zakelijke vereisten, maar zijn ook gebaseerd op verschillende technologische en andere factoren, zoals de vaardigheden en vaardigheden van de beheerders (niet alleen DBA's). Hoewel het bedrijf geen downtime of nul gegevensverlies wil, is dat mogelijk niet realistisch of mogelijk om verschillende redenen. Het bepalen van de RTO en RPO van uw oplossing moet een open en eerlijke discussie tussen alle betrokken partijen zijn.
Een van de aspecten die cruciaal zijn voor zowel RTO als RPO is het kennen van de kosten van downtime. Als u dat aantal definieert en het algehele effect dat niet beschikbaar is voor het bedrijf, is het eenvoudiger om oplossingen te definiëren. Als het bedrijf bijvoorbeeld 10.000 per uur kan verliezen of een boete kan krijgen van een overheidsinstantie als iets niet kan worden verwerkt, is dat een meetbare manier om RTO en RPO te definiëren. De uitgaven voor de oplossing moeten evenredig zijn met het bedrag of de kosten van downtime. Als uw HADR-oplossing $X kost, maar u slechts een paar seconden wordt beïnvloed in plaats van uren of dagen wanneer er een probleem optreedt, heeft het voor zichzelf betaald.
Vanuit een niet-zakelijk oogpunt moet RTO worden gedefinieerd op onderdeelniveau (bijvoorbeeld SQL Server) en voor de hele toepassingsarchitectuur. De mogelijkheid om te herstellen van een storing is slechts zo goed als de zwakste koppeling. Als SQL Server en de bijbehorende databases bijvoorbeeld binnen vijf minuten online kunnen worden gebracht, maar het 20 minuten duurt voordat toepassingsservers hetzelfde doen, is de totale RTO 20 minuten, niet vijf. De SQL Server-omgeving kan nog vijf minuten een RTO hebben; de totale tijd die moet worden hersteld, wordt nog steeds niet gewijzigd.
RPO behandelt specifiek gegevens en heeft rechtstreeks invloed op het ontwerp van een HADR-oplossing, evenals beheerbeleid en procedures. De functies die worden gebruikt, moeten zowel de RTO als de RTO's ondersteunen die zijn gedefinieerd. Als back-ups van transactielogboeken bijvoorbeeld elke 30 minuten worden gepland, maar er een RPO van 15 minuten is, kan een database alleen worden hersteld naar de laatste back-up van het transactielogboek die in het ergste geval 30 minuten geleden zou zijn. Bij deze timing wordt ervan uitgegaan dat er geen andere problemen zijn en dat de back-ups zijn getest en bekend zijn dat ze goed zijn. Hoewel het moeilijk is om elke back-up te testen die wordt gegenereerd voor elke database in uw omgeving, zijn back-ups alleen bestanden op een bestandssysteem. Zonder ten minste periodieke herstelbewerkingen, is er geen garantie dat ze goed zijn. Het uitvoeren van controles tijdens het back-upproces kan u enige vertrouwen geven.
De specifieke functies die worden gebruikt, zoals een AlwaysOn-beschikbaarheidsgroep (AG) of een AlwaysOn-failoverclusterexemplaar (FCI), hebben ook invloed op uw RPO's en RPO's. Afhankelijk van hoe de functies zijn geconfigureerd, kunnen IaaS- of PaaS-oplossingen wel of niet automatisch een failover uitvoeren naar een andere locatie, wat kan leiden tot langere downtime. Door RTO en RPO te definiëren, kan de technische oplossing die deze vereiste ondersteunt, worden ontworpen met kennis van de vergoedingen voor tijd en gegevensverlies. Als deze onrealistisch zijn, moeten RPO's en RPO's dienovereenkomstig worden aangepast. Als er bijvoorbeeld een gewenste RTO van twee uur is, maar een back-up drie uur duurt om te kopiëren naar de doelserver voor het herstellen, wordt de RTO al gemist. Deze typen factoren moeten worden verwerkt bij het bepalen van uw RPO's en RPO's.
Er moeten RTO's en RPO's zijn gedefinieerd voor zowel hoge beschikbaarheid als herstel na noodgevallen. Hoge beschikbaarheid wordt beschouwd als een meer gelokaliseerde gebeurtenis die gemakkelijker kan worden hersteld. Een voorbeeld van hoge beschikbaarheid is dat een AG automatisch een failover van de ene replica naar de andere binnen een Azure-regio uitvoert. Dit kan seconden duren. Op dat moment moet u ervoor zorgen dat de toepassing verbinding kan maken na de failovers. De downtime van SQL Server is minimaal. Een lokale RTO of RPO kan in enkele minuten worden gemeten, afhankelijk van de kritieke aard van de oplossing of het systeem.
DR zou vergelijkbaar zijn met het opzetten van een heel nieuw datacentrum. Er zijn veel stukjes aan de puzzel; SQL Server is slechts één onderdeel. Het online downloaden van alles kan uren of langer duren. Daarom zijn de RPO's en RPO's gescheiden. Zelfs als veel technologieën en functies die worden gebruikt voor hoge beschikbaarheid en herstel na noodgevallen hetzelfde zijn, is het tijdsniveau en de betrokken tijd mogelijk niet.
Alle RPO's en RPO's moeten formeel worden gedocumenteerd en periodiek of indien nodig herzien. Zodra ze zijn gedocumenteerd, kunt u overwegen welke technologieën en functies u voor de architectuur kunt gebruiken.