Nadmierny optymizm w kwestii katastrof

Chociaż w ostatnich latach bezpieczeństwo uzyskało wysoki priorytet i pochłania znaczącą część budżetów IT, odtwarzanie po katastrofach nadal jest przesuwane na drugi plan. Taki stan musi się zmienić, jeśli organizacje chcą mieć możliwość kontynuowania operacji z minimalną lub żadną przerwą, niezależnie od tego czy odtwarzany jest przypadek załamania pojedynczego serwera, czy utraty zasobów całego centrum danych w wyniku katastrofy.

Według badań przeprowadzonych w 2007 r. (wśród 1000 przedsiębiorstw) przez Computing Technology Industry Association, w 2006 r. organizacje IT wydały 20% swoich budżetów na bezpieczeństwo, co oznacza istotny wzrost - z 12% dwa lata wcześniej. Ten trend prawdopodobnie nie osłabnie w kolejnych latach.

Ostro kontrastuje z tym poziom wydatków na odtwarzanie po katastrofie i zapewnienie ciągłości biznesowej, liczone według przeprowadzonych w tym samym czasie badań IDC, na 6% budżetów IT w 2006 r. Wydatki te pozostaną prawdopodobnie na tym samym poziomie: prawie 75% badanych nie przewidywało zwiększenia wydatków na odtwarzanie po katastrofie w 2007 r. Chociaż utrzymanie systemów i centrów danych w dobrej kondycji pozostaje jednym z głównych priorytetów IT, to najwyraźniej na operacje odtwarzania, wynikające z uszkodzeń infrastruktury, przydzielane są mniejsze zasoby.

Planowanie składowania i odtwarzania po katastrofie nie jest jednak tylko drugoplanowym zadaniem i może stać się elementem decydującym o przetrwaniu biznesu po zaistnieniu losowego zdarzenia powodującego zniszczenie elementów infrastruktury IT. Testowanie procesów odtwarzania po katastrofie jest rzadko przeprowadzane w sposób wyczerpujący. Nawet w czasie trwania zwykłych operacji biznesowych, kiedy dokonywane jest codzienne składowanie, testowanie integralności składowań jest rzadkością. Może to oznaczać niemożność wykonania pomyślnej operacji odtworzenia, co spowoduje zatrzymanie biznesu w punkcie, z którego odtworzenie nie będzie możliwe.

Co gorsza, niezależnie od małego budżetu rezerwowanego na poczet odtwarzania po katastrofie, blisko 80% celów składowania dotyczy tylko tych kilku serwerów, które są uważane za najważniejsze i chroni zaledwie niewielki fragment całej infrastruktury centrum danych. Z pewnością każda decyzja alokowania 80% budżetu odtwarzania po katastrofie do ochrony 20% zasobów centrum danych jest pragmatyczna, balansując pomiędzy ograniczeniami budżetu a koniecznością zapewnienia ciągłości biznesowej. W odtwarzaniu po katastrofie, podobnie jak w ubezpieczeniach na życie, każdy "kupuje" taką ochronę, na jaką może sobie pozwolić. Chociaż serwery uznane za najbardziej krytyczne są bezpośrednim celem budżetu disaster recovery, pozostałej większości serwerów często przydziela się minimalny priorytet - słusznie lub nie. Istnieje jeszcze trzecia kategoria: serwery otrzymujące większą ochronę niż potrzeba, lub umieszczane na wyższym poziomie priorytetów niż na to zasługują, głównie z powodu braku elastycznej alternatywy dla odtwarzania po katastrofie typu "wszystko albo nic". Dla takiej pośredniej grupy, pieniądze IT są wydawane na ochronę "niby-krytycznych" serwerów, ponieważ dostępne rozwiązanie dostosowane jest do garstki tych najważniejszych.

Biorąc pod uwagę typowe środowiska korporacyjne z niezależnymi serwerami, maszynami wirtualnymi i systemami high-end, obejmującymi szeroki zakres systemów operacyjnych, jest prawie pewne, że do składowania takich systemów używany będzie zestaw niekompatybilnych narzędzi. Jest to nie tylko nieefektywne wykorzystanie zasobów systemowych i ludzkich, lecz także prowadzi to do niespójnej polityki, która może pozostawiać istotne zasoby bez ochrony.

W tych zmiennych warunkach i mieszanym środowisku centrów danych, aby zapewnić ochronę wszystkich zasobów i zdolność odtworzenia biznesu po katastrofie w sposób planowany, spójny i gruntowny, można wykorzystać możliwości środowiska maszyn wirtualnych poprzez skonsolidowane odtwarzanie.

Podstawowe parametry pomiarowe

W świecie idealnym odtworzenie - po dowolnej przerwie w działaniu obejmującej cały system lub utratę dowolnego żywotnego komponentu - powinno być natychmiastowe i transparentne dla użytkownika. Chociaż taki scenariusz jest osiągalny poprzez zainstalowanie wielopoziomowych systemów redundantnych, koszt wykonania tego jest zbyt wygórowany. Bardziej realistyczne podejście to: zdefiniowanie zbioru specyficznych parametrów, które określą jak długo organizacja może obyć się bez istotnych systemów IT i danych, punkt na osi czasu składowania, od którego dane muszą być odtworzone i, oddzielnie, przedział czasowy, w którym testowanie składowania musi być wykonane, aby uważać je za pomyślne. Parametry te są powiązane z wrażliwością biznesu na opóźnienia informacyjne oraz na utratę informacji.

RTO (Recovery Time Objective) - docelowy czas odtwarzania - jest parametrem określającym przedział czasowy, w jakim aplikacja lub cała sieć organizacji musi być odtworzona. W zależności od natury aplikacji i wyników analizy biznesowej, pożądana docelowa szybkość odtwarzania może mieć różną wartość. Na przykład dopuszczalny, najgorszy przypadek wyłączenia dla systemu przetwarzania zamówień klientów nie powinien przekraczać kilku godzin, podczas gdy system pracujący jedynie okresowo, np. comiesięczne sporządzanie listy płac, może mieć dopuszczalny czas wyłączenia rzędu tygodni. Systemy sterowania procesami przemysłowymi mogą mieć RTO ustalane na sekundy lub minuty.

RPO (Recovery Point Objective) - docelowy punkt odzyskiwania - określa punkt na osi czasu składowania, od którego muszą być odtworzone dane. Innymi słowy, RPO kwantyfikuje ilość danych, jaka może być utracona lub które organizacja gotowa jest poświęcić jako skutek katastrofy. Parametr RPO może być wyrażony ilością informacji (liczbą transakcji biznesowych), których utrata nie spowoduje zagrożenia dla pracy firmy. Dla systemu listy płac, odtwarzanie może być określone na tygodnie do tyłu i łatwe do uzyskania. Dane utworzone w oknie RPO - po ostatnim składowaniu - są utracone i muszą być zrekonstruowane. Dla aplikacji krytycznych, takich jak transfery pieniężne, RPO może być cofnięciem do punktu, w którym wydarzyło się uszkodzenie, co zapewnia brak utraty danych. W miarę jak interwał czasowy RPO zmniejsza się, rozwiązanie często staje się coraz bardziej złożone i kosztowne.