Jeśli masz u siebie środowisko serwerów to warto sobie czasem zadać pytanie – co się stanie z moimi aplikacjami czy też danymi – jeśli coś się wydarzy złego i stracisz dostęp do serwerów. Oczywiście pewnie korzystasz z kopii zapasowych – punkt dla Ciebie. Ale czy analizowałeś jaki jest czas przywrócenia danych z kopii? Jak długo Twoi użytkownicy a może i klienci będą czekać na dostęp do danych i aplikacji?
To mogą być dni, a może i tygodnie jeśli masz dużo danych i ulegnie większość systemów lokalnych. A czas kosztuje wg różnych badań w 2014 roku każda godzina kosztowała średnio 100-400tys USD. Oczywiście w polskich realiach kwoty mogą być niższe, ale nadal wysokie. Biuro i pracownicy nadal nas kosztują tak samo jak brak zamówień od klientów, a dodatkowo cierpi na tym nasza reputacja.
Już od wielu lat większe firmy inwestują ogromne środki w zabezpieczenia swoich systemów na wypadek awarii, niemal każdy bank ma zapasowe centrum danych do którego może przenieść nawet 100% swoich zasobów jeśli główna serwerownia przestanie działać.
Obecnie te rozwiązania są dostępne też dla mniejszych firm.
Replikacja Hyper-V
Jeśli korzystasz z Hyper-V to zapewne znalazłeś (a może i korzystałeś) z funkcjonalności replikacji maszyn wirtualnych. Od wersji Windows Server 2012 Microsoft zaoferował możliwość realizacji kopii lokalnych VM na innym serwerze. Rozwiązanie umożliwia trzymanie replik w innym centrum danych, bowiem sam proces kopiowania danych jest asynchroniczny. Potencjalne RPO czyli ilość danych jakie stracimy w przypadku awarii wynosi do 30 sekund (dla Windows Server 2012R2 i nowszych), więc relatywnie mało. Krótki jest też czas RTO – bowiem przywrócenie serwerów nie oznacza odtwarzanie ich z kopii zapasowej a w skrócie – uruchomieniu kopii.
Replikację, która jest dostępna w Windows Server omawiałem już parę lat temu:
- Replikacja maszyn w Hyper-V
- Hyper-V Replikacja pomiędzy różnymi domenami
Niestety w/w rozwiązanie ma swoje ograniczenia.
- Monitoring
W przypadku usługi opartej o Windows Server nie ma gotowego narzędzia w systemie, które by monitorowało stan replikacji. Można sobie radzić skryptami PowerShell czy szukać rozwiązań innych producentów – nie mniej jednak wymaga to dodatkowego nakładu czasu i kosztów. - Replikacja oparta o pojedyncze VM
Replikacja w Windows Server opiera się o pojedyńcze maszyny – jeśli replikujemy małe serwery, które mają pewne zamknięte rozwiązanie – to nie ma problemu, ale jeśli replikujemy większe rozwiązanie, składające się z kilku-kilkunastu serwerów to proces replikacji wymaga większej kontroli – szczególnie przy procesie uruchomienia kopii. M.in. kolejność włączania systemów, może jakieś modyfikacje konfiguracji… - Brak prostych mechanizmów testów
Sama replikacja umożliwia nam włączenie środowiska do testów, jednakże nadal realizujemy to dla pojedynczych maszyn. Jeśli chcemy przetestować większe rozwiązanie to czeka nas sporo dodatkowej pracy.
Replikacja zarządzana przez ASR
I tutaj pojawia się ASR. Usługa dostępna w Azure dodaje dodatkową warstwę zarządzania i monitoringu na systemową funkcję replikacji.
- Zapewnia pełny monitoring – zarówno procesu wstępnej replikacji (czyli kopiowania danych pomiędzy hostami), jak i późniejszej synchronizacji. W przypadku jakichkolwiek problemów możemy w najprostszym przypadku otrzymać alert (e-mail, sms), w bardziej złożonym wywołać jakieś zdarzenie automatyczne.
- ASR replikuje maszyny ale pozwala tworzyć scenariusze Disaster Recovery. Scenariusz (Recovery Plan) to zestaw zdarzeń jakie mają zostać zrealizowane w przypadku awarii. W najprostszym modelu będą to operacje włączenia wybranych maszyn po stronie repliki, możemy oczywiście określić kolejność włączania maszyn. Co więcej możemy w każdym momencie (przed utworzeniem maszyny, po jej utworzeniu, przed włączenie, po włączeniu itp) wywołać dodatkowe zdarzenia – skrypty, które albo mogą np. zmodyfikować nam parametry maszyny (choćby adresy IP), utworzyć jakieś rozwiązania (sieci, vpn itp).
Dodatkowo możemy utworzyć zadania dla administratora – poprzez wyświetlenie komunikatu – co ma zrobić, do kogo np. zadzwonić i poinformować o działaniach…
Pamiętaj, że awarie zdarzają się naogół w najmniej oczekiwanym momencie, administrator wyrwany w nocy o 4 rano nie będzie mieć czasu na szukanie dokumentacji – on ma przywrócić środowisko.
- ASR zapewnia nam też testy rozwiązań, dzięki czemu scenariusze, które omawiałem w poprzednim punkcie możemy sprawdzić by na pewno zadziałały i dodatkowo zmierzyć czas ich realizacji (by znać odpowiedź na pytanie – za ile czasu nasze systemy będą dostępne).
- Ale jest i więcej – wspomniałem o replikacji z Hyper-V – ASR w jednym panelu wspiera zarówno replikację z Hyper-V, vmWare jak i serwerów fizycznych (oczywiście tylko w jedną stronę – ale to działa i da się zabezpieczyć fizyczny serwer przed awarią). Całość jest monitorowana i zarządzana centralnie z jednej konsoli.
- Replikację możemy realizować do innego centrum danych, ale też możemy maszyny replikować do Azure. A to jest tańsze, bowiem nie musimy posiadać drugiego centrum danych (lub wynajmować kolokacji), nie musimy też płacić za dzierżawę serwerów i macierzy po drugiej stronie, na które „spływają” nasze kopie. Za VM w Azure płacimy dopiero wtedy jak włączymy nasze maszyny – czy to do testów czy produkcyjnie – zapłacimy tak samo jak za typową maszynę wirtualną.
