reklama

Jak zwiększyć wydajność infrastruktury serwerowej oszczędzając czas i pieniądze?

Dzięki najnowszym rozwiązaniom serwerowym można sprawnie realizować zadania, jakie przynosi przyszłość. Przynoszą one znaczące oszczędności, dzięki którym można skutecznie konkurować na stale ewoluującym rynku.
Zapoznaj się z bezpłatnym raportem

popularne komentowane nowości

popularne

Najczęściej czytane

więcej...

powiększ tekst

AKTUALNOŚCI

Od wybuchu do rozruchu

21 czerwca 2007

Krzysztof Jakubik

Nawet dla najlepiej zorganizowanej firmy katastrofa wpływająca na poprawne funkcjonowanie centrum danych jest trudnym testem. Aby go przejść trzeba bardzo rzetelnie przygotować cały plan działań, aby być w stanie spełnić wymagania stawiane przez jednostki biznesowe firmy.

Przy tworzeniu planu disaster recovery (DR) konieczne jest, aby wziąć pod uwagę dwa ważne parametry, które zarząd firmy powinien określić wspólnie z informatykami - RPO i RTO. Pierwszy z nich (Recovery Point Objective) określa moment w przeszłości, w którym po raz ostatni została wykonana kopia danych i do którego momentu działalności będzie można wrócić. Czas ten zależy głównie od charakteru działalności firmy i jest różny zarówno dla różnych przedsiębiorstw, jak też poszczególnych serwerów i usług (jednym wystarczy kopia sprzed tygodnia, inni zaś potrzebują danych sprzed kilkunastu sekund).

Drugi ważny parametr - Recovery Time Objective - określa maksymalny czas po awarii, potrzebny do przywrócenia działania aplikacji, systemów i procesów biznesowych. Określając parametr RTO należy doprowadzić do kompromisu między potencjalnymi stratami a kosztami rozwiązania umożliwiającego jak najszybsze odtworzenie stanu sprzed awarii.

Przygotowując plan DR warto też zastanowić się, od kiedy zaczynać liczyć czas RTO. Często bowiem liczony jest on od momentu rozpoczęcia procedury opisanej w planie DR, podczas gdy rzeczywisty brak dostępności do danych nastąpił zdecydowanie wcześniej, czasem już w momencie wystąpienia katastrofy.

W tym artykule prezentujemy 10 najważniejszych kroków, które powinien obejmować plan DR - od momentu wystąpienia katastrofy, aż do pełnego uruchomienia usług IT w centrum zapasowym. Dla każdego z tych kroków ważne jest określenie czasu, który zajmie jego wykonanie.

Naszym zadaniem jest naszkicowanie linii czasu, gdzie zaznaczymy każdy rodzaj aktywności, każde wydarzenie lub komponent związany z nasza firmą w kontekście ponownego przywrócenia jej działalności do pracy. Unikajmy wchodzenia w zbędne detale. Dla każdego przypadku zastanówmy się nad najbardziej optymistyczną i pesymistyczną wersją. Dołączmy różne dokumenty, które mogą pozwolić na przyspieszenie procesu decyzyjnego podczas realizacji planu DR.

Zaprojektowany plan DR należy też przetestować. W zaimprowizowanym środowisku trzeba zmierzyć się z założonym scenariuszem wydarzeń i sprawdzić na ile zaprojektowany przez nas plan DR ma związek z rzeczywistością i spełnia założony czas RTO. Potrzebne są też konsultacje z działami biznesowymi - ocena potrzeb każdego z nich i być może ustalenie indywidualnych czasów RTO, które będziemy musieli osiągnąć podczas realizowania założeń planu DR.

1. Katastrofa

Chociaż to zabrzmi banalnie, ale całą procedurę musi rozpocząć fakt wykrycia wystąpienia katastrofy. Dużą eksplozję o północy szybko odkryją wszyscy sąsiedzi, ale fakt zalania serwerowni, bądź pojawienia się tam ognia, już nie. Tworząc plan disaster recovery należy przewidzieć różne przypadki, oceniając także, jak wpływ mogą mieć one na funkcjonowanie systemów IT i dostępność danych. Trzeba też umieć ocenić, czy sam moment wystąpienia katastrofy miał wpływ na systemy IT i czy czas RTO należy mierzyć właśnie od tego momentu.

2. Ogłoszenie katastrofy

W planie DR powinna być wskazana osoba (bądź grupa) upoważniona do formalnego ogłoszenia wystąpienia katastrofy. Fakt ten zainicjuje wdrożenie do życia realizacji zapisów planu DR. Kluczową sprawą jest tutaj określenie, czy katastrofa miała wpływ na systemy IT i czy konieczne jest natychmiastowe uruchomienie planu DR, bądź też wzmożona obserwacja sytuacji przy zwiększonym prawdopodobieństwie konieczności uruchomienia procedur awaryjnych (być może dysponujemy systemami, które automatycznie potrafią reagować w przypadku awarii i przełączać pracę na systemy rezerwowe).

3. Poinformowanie zespołu DR

Po ogłoszeniu stanu katastrofy powinno nastąpić poinformowanie zespołu odpowiedzialnego za realizację planu DR. Jak już wspomniano, nie zawsze oznacza to od razu wdrożenie tego planu w życie. Natomiast warto zadbać o to, aby cały zespół zebrał się w jednym konkretnym, wskazanym wcześniej miejscu (np. siedzibie zapasowej) lub zajął także wcześniej określone pozycje. Całą tą operację warto dokładnie przemyśleć, dlatego że zajmie ona parę godzin bardzo cennego czasu. Trzeba też wziąć pod uwagę fakt możliwości wystąpienia problemów natury komunikacyjnej (zerwany most, linia kolejowa itp.), co jeszcze bardziej wydłuży ten czas.

4. Uruchomienie centrum zapasowego

Gdy zespół odpowiedzialny za działania związane z systemami IT dotrze do centrum zapasowego, wszystkie konieczne do obsługi urządzenia powinny być już włączone i gotowe do pracy. Jeśli tak nie jest, to operacja ta także zajmie trochę czasu. Jeśli nie mamy wykonywanej zdalnej replikacji, to będzie trzeba też poczekać chwilę na nośnik z danymi, które będziemy musieli udostępnić w centrum zapasowym. Nieco gorsza sytuacja będzie, jeśli wynajmujemy centrum zapasowe i w wyniku katastrofy nagle zjawi się tam kilka takich samych jak my zespołów. Tę opcję także trzeba wziąć pod uwagę.

5. Uruchomienie sieci

Połączenia sieciowe w centrum zapasowym powinny być odpowiednio skonfigurowane na wypadek wystąpienia katastrofy, aby uniknąć dodatkowych opóźnień. Jeśli nie zostało to odpowiednio zaplanowane i przygotowane, możemy stracić mnóstwo czasu na uruchamianie poszczególnych usług sieciowych. Uruchamianie i testowanie poszczególnych procesów może zabrać zarówno parę godzin albo nawet całą dobę. Dlatego plany sieci zawsze powinny być odpowiednio przemyślane, przygotowane i przetestowane na różne, nawet najbardziej niewiarygodne okoliczności.

6. Odzyskanie danych

Czynnością, dla której odbywa się cała ta procedura jest odzyskanie i udostępnienie danych, na których pracuje firma. Jeśli w firmie nie funkcjonuje replikacja dyskowa, to naszym celem jest zdobycie nośnika z zapasową kopią danych. Niektóre plany disaster recovery zakładają codzienne przewożenie takiego nośnika do centrum zapasowego - wtedy będziemy dysponowali kopią z ostatniego dnia. Ale często też może się okazać, że tę kopię będzie trzeba przywieźć z centrum podstawowego, gdzie wystąpiła katastrofa. Tą procedurę także warto bardzo dokładnie przeanalizować.

Inną, ale równie ważną kwestią przy tworzeniu planu DR, jest przemyślenie priorytetów dla nośników z backupem. W każdej firmie są serwery bardziej i mniej ważne. Dane ze wszystkich maszyn nigdy nie powinny znaleźć się na tym samym nośniku - zawsze dla najbardziej ważnych serwerów powinny być przeznaczone oddzielne nośniki. Wiele firm, tworząc strategie backupu, optymalizuje go pod kątem czasu wykonania kopii zapasowej, nie myśląc o czasie odzyskania danych (i, co gorsza, nigdy nie testując tej procedury). Natomiast wielokrotnie słychać o przypadkach, gdzie z backupu wykonanego przez 2 godziny dane były odzyskiwane przez 5 dni. Dlatego całą tą procedurę trzeba bardzo dokładnie przetestować.

7. Uruchomienie i ustabilizowanie baz danych

Po fizycznym odzyskaniu danych konieczne jest sprawdzenie logicznej integralności wszystkich danych, a szczególnie baz danych. Za ten element planu DR powinni być odpowiedzialni administratorzy baz danych (systemy baz danych udostępniają wiele narzędzi do tego typu operacji). Ta operacja także może zabrać parę godzin - zależy od objętości bazy danych, ale także od dostępności administratorów.

8. Uruchomienie serwerów aplikacyjnych

Przyszła pora na uruchomienie kluczowych aplikacji. Mogłoby się wydawać, że jest to najłatwiejszy element, ale tak nie jest. Często okazuje się, że w środowiskach zapasowych nie są przeprowadzane te same aktualizacje oprogramowania jak w centrach podstawowych i finalnie może okazać się, że nasze dane nie są w stanie być odczytane i przetwarzane przez oprogramowanie zainstalowane na serwerach w centrum zapasowym. Stąd bardzo ważne jest wdrożenie odpowiednich systemów zarządzania zmianami w firmie, a szczególnie aktualizacjami krytycznego oprogramowania.

9. Udostępnienie danych użytkownikom

Finalnie można przywrócić dostęp do aplikacji i danych użytkownikom. Podczas procesu realizacji planu DR prawdopodobnie wszyscy wyłączyli telefony, aby uniknąć tysięcy takich samych pytań - kiedy znów wszystko będzie działać. Z tego samego powodu nie powinno następować natychmiastowe przyłączanie do sieci wszystkich użytkowników. Z pewnością wystąpią wtedy jakieś problemy, a ich eliminacja powinna następować partiami. Stąd podczas tworzenia planu DR powinno określić się poszczególne fazy przyłączania - zarówno oddziałów, jak też konkretnych użytkowników.

10. Finalny przegląd działań

Na zakończenie procesu realizacji zapisów planu DR, gdy opanowaliśmy już sytuację, należy jeszcze raz przyjrzeć się wszystkim wykonanym operacjom, bezpieczeństwu danych i pomyśleć o działaniach, które trzeba będzie podjąć po ponownym uruchomieniu centrum podstawowego. Konieczne jest też wyciągnięcie odpowiednich wniosków z całego wydarzenia i odpowiednia modyfikacja planu DR.