Centrum danych
Jedno centrum danych nie zawsze jest wystarczające, szczególnie dla serwisów transakcyjnych, w których dostępność danych jest kluczowa z punktu widzenia interesów użytkowników serwisu. Naturalnie dotyczy to interfejsów bankowości elektronicznej, ale równie niezbędne jest wszędzie tam gdzie utrata danych (lub brak ich dostępności przez dłuższy czas) może zaważyć na możliwości kontynuacji działania serwisu po usunięciu awarii (poprzez znaczną utratę zaufania klientów, lub ich wymierne straty finansowe).
Okazuje się że przy tak postawionej tezie, znaczna część serwisów kwalifikuje się do wdrożenia co najmniej jednego zapasowego centrum. Nawet przy średniej wielkości sklepie internetowym, utrata danych transakcyjnych spowoduje w praktyce znaczne obniżenie wartości marki, w konsekwencji gwałtowny spadek obrotów a to z kolei może doprowadzić do zamknięcia nawet dobrze zapowiadającego się interesu.
Mając tego świadomość i ponosząc często niewielkie koszty utrzymania tylko niewielkiego procenta głównego środowiska u innego operatora można z łatwością uniknąć takiego ryzyka.
Czym innym jest bowiem wolno ładujący się serwis (z zapasowego centrum) a czym innym kompletny downtime.
Oczywiście koszt utrzymania środowiska zapasowego będzie ściśle zależny od złożoności środowiska głównego, ale z naszych doświadczeń przy serwisach obsługiwanych przez jeden do kilkunastu serwerów nie powinien przekroczyć 25% kosztów środowiska głównego.
W pewnych specyficznych scenariuszach, podział środowisko główne i zapasowe może zostać zastąpione kilkoma środowiskami głównymi/równoległymi, dotyczy to jednak wyłącznie serwisów o bardzo dużym zasięgu, gdzie serwowanie treści z różnych geograficznie lokalizacji doskonale wpływa na czas ich ładowania.
Wytworzenie takiego rozwiązania, choć z pozoru trudne to przy obecnie stosowanej technice jest możliwe relatywnie niewielkim kosztem. Z pomocą przychodzą tutaj zaawansowane systemy globalnego równoważnia obciążeniem GSLB (Global Server Load Balancing) oraz mocno obecnie rozbudowane sieci CDN (Content Delivery Network)
Procedury
Oprócz redundancji systemów na poziomie sprzętu i centrum danych, DR należy również traktować jako zbiór przepisów i działań regulujących działania w trakcie katastrofy.
Obecnie znaczna część przedsiębiorstw (niekoniecznie informatycznych) wdraża procedury DR jako metodę ograniczenia ryzyka i odtworzenia działalności po katastrofie. Jest to słuszne z punktu widzenia ciągłości biznesu i ma również swoje odniesienie do platform hostingowych.
Okazuje się bowiem, że odpowiednio napisana dokumentacja DR pozwoli w bardzo szybkim czasie uruchomić od nowa serwis wyłączony np. w wyniku powodzi w okolicy centrum danych.
Z perspektywy serwisów internetowych, dokumentacja i procedury DR powinny w szczególności zawierać informację gdzie przechowywana jest kopia danych, z kim należy nawiązać kontakt aby wypożyczyć lub błyskawicznie kupić serwery, gdzie należy się udać aby wynająć powierzchnię w centrum danych, kto odpowiada za nadzór nad domenami, gdzie znajduje się instrukcja odtworzenia systemu, jak skontaktować się z achitektami/programistami serwisu.
Obecnie zamawiając u popularnych dostawców usług hostingowych dedykowane serwery należy się liczyć z kilkudniowym lub tygodniowym terminem oczekiwania na sprzęt. Może więc aby zminimalizować ryzyko, wystarczy podpisać stosowną umowę z dostawcą sprzętu lub innym operatorem hostingowym na dostarczenie urządzeń w 24 godzinnym terminie ?
Takie umowy nie są specjalnie kosztowne, natomiast nawet jeśli nie mamy zapasowego centrum danych pozwalają wierzyć, że będziemy w stanie odtworzyć główne środowisko najszybciej jak to będzie możliwe.
Kopie zapasowe
Ten temat zasługuje na osobny punkt ponieważ jest absolutnie najważniejszy w całym procesie świadczenia usług hostingowych. Potrzeba jego istnienia oczywiście najczęściej jest widoczna w momencie kiedy taka kopia właśnie teraz niezbędnie jest nam potrzebna.
Większość dostawców usług hostingowych daje możliwość tworzenia kopii zapasowych ale niestety samodzielnie jej nie realizuje w rozwiązaniach dedykowanych klientom. To klient musi zadbać o stworzenie odpowiednich mechanizmów, polityk kopii i przetestowania całego rozwiązania.
Kilka bardzo istotnych punktów do polityki kopii zapasowych:
1. Kopie powinny być przechowywane w dwóch miejscach. W głównym centrum danych oraz gdzieś bardzo od niego daleko. W głównym centrum mogą to być macierze dyskowe (łatwość dostępu), w zdalnej lokalizacji wyłącznie taśmy (łatwo przenaszalne).
2. Kopie powinny być robione najczęściej jak to możliwe (w ramach rozsądku i zgodnie z założeniami systemu), jednak nie rzadziej niż raz dziennie dla plików aplikacji oraz baz danych. Jeśli zachodzi taka potrzeba, w ciągu dnia co kilka godzin można tworzyć kopie logów transakcyjnych baz danych.
3. Najlepsze są pełne kopie systemu, aplikacji oraz bazy. Optymalnie wystarczą inkrementalne kopie systemu i aplikacji, oraz pełne kopie bazy.
4. Standardowo inkrementacja nie powinna być dłuższa niż 1 tydzień, po którym następuje stworzenie kopii pełnej.
5. Raz na kilka miesięcy powinna nastąpić próba całkowitego odtworzenia środowiska z kopii zapasowych.
6. Jeśli jest taka możliwość, co najmniej jedna osoba powinna obowiązkowo czytać codzienne raporty z systemów kopii.
Stosując te zasady możemy być spokojni o bezpieczeństwo serwisu, niezależnie od tego czy wybierzemy opcję zapasowego centrum danych, czy tylko porządnego planu DR i stosownej polityki kopii zapasowych