Opis celu czasu odzyskiwania i celu punktu odzyskiwania
Zrozumienie celów czasu odzyskiwania i punktu odzyskiwania ma kluczowe znaczenie dla planu wysokiej dostępności i odzyskiwania po awarii (HADR), ponieważ stanowią podstawę dla dowolnego rozwiązania dostępności.
Cel czasu odzyskiwania
Cel czasu odzyskiwania (RTO) to maksymalny czas dostępny do przełączenia zasobów w tryb online po awarii lub problemie. Jeśli ten proces trwa dłużej niż cel czasu odzyskiwania, mogą istnieć konsekwencje, takie jak kary finansowe, nie można wykonać pracy itd. Cel czasu odzyskiwania można określić dla całego rozwiązania, które obejmuje wszystkie zasoby, a także dla poszczególnych składników, takich jak wystąpienia programu SQL Server i bazy danych.
Cel punktu odzyskiwania
Cel punktu odzyskiwania (RPO) to punkt w czasie, do którego należy odzyskać bazę danych i odpowiada maksymalnej ilości utraty danych, którą firma chce zaakceptować. Załóżmy na przykład, że maszyna wirtualna IaaS zawierająca program SQL Server doświadcza awarii o godzinie 10:00, a bazy danych w wystąpieniu programu SQL Server mają cel punktu odzyskiwania wynoszący 15 minut. Niezależnie od tego, jaka funkcja lub technologia jest używana do przywrócenia tego wystąpienia i jego baz danych, oczekuje się, że dane zostaną utracone przez co najwyżej 15 minut. Oznacza to, że bazę danych można przywrócić do 9:45 lub nowszej, aby zapewnić minimalną wartość do braku spotkania w przypadku utraty danych określonego celu punktu odzyskiwania. Mogą istnieć czynniki, które określają, czy cel punktu odzyskiwania jest osiągalny.
Definiowanie celów czasu odzyskiwania i punktu odzyskiwania
RTO i RPO są oparte na wymaganiach biznesowych, ale są również oparte na różnych czynnikach technologicznych i innych, takich jak umiejętności i umiejętności administratorów (nie tylko dbAs). Chociaż firma może nie chcieć żadnych przestojów lub zerowej utraty danych, może to nie być realistyczne lub możliwe z różnych powodów. Określenie celu punktu odzyskiwania i celu punktu odzyskiwania rozwiązania powinno być otwartą i uczciwą dyskusją między wszystkimi zaangażowanymi stronami.
Jednym z aspektów, które mają kluczowe znaczenie zarówno dla celu czasu odzyskiwania, jak i celu punktu odzyskiwania, jest znajomość kosztów przestoju. Jeśli zdefiniujesz ten numer, a ogólny efekt jest wyłączony lub niedostępny musi działać, łatwiej jest zdefiniować rozwiązania. Jeśli na przykład firma może stracić 10 000 na godzinę lub może zostać ukarana grzywną przez agencję rządową, jeśli coś nie może zostać przetworzone, jest to wymierny sposób, aby pomóc zdefiniować cel czasu odzyskiwania i cel punktu odzyskiwania. Wydatki na rozwiązanie powinny być proporcjonalne do kwoty lub kosztu przestoju. Jeśli rozwiązanie HADR kosztuje $X, ale kończy się tylko przez kilka sekund zamiast godzin lub dni, gdy wystąpi problem, zapłacił za siebie.
Z punktu widzenia firmy niebiznesowej cel czasu odzyskiwania powinien być definiowany na poziomie składnika (na przykład programu SQL Server), a także dla całej architektury aplikacji. Możliwość odzyskania sprawności po awarii jest tylko tak dobra, jak jego najsłabszy związek. Jeśli na przykład program SQL Server i jego bazy danych mogą być w trybie online w ciągu pięciu minut, ale wykonywanie tego samego zadania zajmuje serwerom aplikacji 20 minut, ogólny cel czasu odzyskiwania to 20 minut, a nie pięć. Środowisko programu SQL Server może nadal mieć wartość RTO 5 minut; nadal nie zmieni ogólnego czasu na odzyskanie.
Cel punktu odzyskiwania dotyczy konkretnie danych i bezpośrednio wpływa na projektowanie dowolnego rozwiązania HADR, a także zasad i procedur administracyjnych. Używane funkcje muszą obsługiwać zdefiniowane obiekty RTO i RPO. Jeśli na przykład kopie zapasowe dziennika transakcji są zaplanowane co 30 minut, ale istnieje 15-minutowy cel punktu odzyskiwania, baza danych może zostać odzyskana tylko do ostatniej dostępnej kopii zapasowej dziennika transakcji, która w najgorszym przypadku będzie 30 minut temu. Ten czas zakłada, że żadne inne problemy i kopie zapasowe zostały przetestowane i są znane jako dobre. Chociaż trudno jest przetestować każdą kopię zapasową wygenerowaną dla każdej bazy danych w danym środowisku, kopie zapasowe to tylko pliki w systemie plików. Bez wykonywania co najmniej okresowych przywracania nie ma gwarancji, że są dobre. Uruchamianie kontroli podczas procesu tworzenia kopii zapasowej może dać pewien stopień pewności.
Określone używane funkcje, takie jak zawsze włączona grupa dostępności lub wystąpienie klastra trybu failover (FCI, Always On Failover Cluster Instance) również wpłynie na obiekty RTO i RPO. W zależności od sposobu konfigurowania funkcji rozwiązania IaaS lub PaaS mogą lub nie mogą automatycznie przejść w tryb failover do innej lokalizacji, co może spowodować dłuższy przestój. Definiując cel czasu odzyskiwania i cel punktu odzyskiwania, rozwiązanie techniczne, które obsługuje to wymaganie, można zaprojektować znając przydziały czasu i utraty danych. Jeśli te likwidacje są nierealistyczne, RTO i RPO muszą być odpowiednio dostosowane. Jeśli na przykład istnieje żądany cel czasu odzyskiwania z dwóch godzin, ale kopia zapasowa będzie trwać trzy godziny, aby skopiować na serwer docelowy do przywrócenia, cel czasu odzyskiwania jest już pominięty. Te typy czynników muszą być uwzględniane podczas określania celów RTO i RPO.
Powinny istnieć obiekty RTO i RPO zdefiniowane zarówno dla wysokiej dostępności, jak i odzyskiwania po awarii. Wysoka dostępność jest uznawana za bardziej zlokalizowane zdarzenie, które można łatwiej odzyskać. Przykładem wysokiej dostępności jest automatyczne przełączanie grupy dostępności w tryb failover z jednej repliki do innej w regionie świadczenia usługi Azure. Może to potrwać kilka sekund, a w tym momencie należy upewnić się, że aplikacja może nawiązać połączenie po przejściu w tryb failover. Przestój programu SQL Server byłby minimalny. Lokalny cel czasu odzyskiwania lub cel punktu odzyskiwania może być potencjalnie mierzony w minutach w zależności od krytycznego charakteru rozwiązania lub systemu.
Odzyskiwanie po awarii byłoby związane z tworzeniem zupełnie nowego centrum danych. Jest wiele kawałków do układanki; Program SQL Server jest tylko jednym składnikiem. Pobieranie wszystkiego online może potrwać kilka godzin lub dłużej. Dlatego obiekty RTO i RPO są oddzielne. Nawet jeśli wiele technologii i funkcji używanych do wysokiej dostępności i odzyskiwania po awarii są takie same, poziom nakładu pracy i czasu może nie być.
Wszystkie RTO i RPO powinny być formalnie udokumentowane i poprawione okresowo lub zgodnie z potrzebami. Po ich udokumentowaniu możesz rozważyć, jakie technologie i funkcje mogą być używane w architekturze.