Restore na inny region (Azure)

Restore na inny region w Azure wymaga uwzględnienia opóźnień replikacji między lokalizacjami geograficznymi.

Na czym polega odtwarzanie zasobów w innym regionie Azure

Restore na inny region w Azure oznacza odtworzenie danych lub zasobu w lokalizacji geograficznej innej niż ta, w której działa środowisko podstawowe. Nie jest to zwykłe przeniesienie maszyny wirtualnej między strefami dostępności. Regiony Azure są oddzielnymi lokalizacjami infrastruktury, z własnymi centrami danych, siecią, magazynami i ograniczeniami dotyczącymi dostępnych usług. Procedura odtwarzania zależy więc od konkretnego produktu, rodzaju kopii zapasowej oraz tego, czy docelowy region obsługuje wymagany typ zasobu.

W przypadku Azure Backup możliwość odtworzenia w regionie zapasowym jest związana z konfiguracją magazynu Recovery Services vault oraz replikacją danych kopii. Magazyn musi korzystać z odpowiedniego mechanizmu redundancji, a zasób musi należeć do kategorii obsługiwanej przez funkcję odtwarzania między regionami. Sam fakt posiadania kopii zapasowej w Azure nie oznacza automatycznie, że każdą kopię można przywrócić w dowolnym regionie. Przed operacją trzeba sprawdzić typ zasobu, region źródłowy, region docelowy, politykę ochrony i dostępne opcje w portalu lub dokumentacji danej usługi.

Replikacja, opóźnienie i punkt odzyskiwania

Najważniejszym ograniczeniem jest różnica między wykonaniem kopii w regionie źródłowym a udostępnieniem jej w regionie docelowym. Dane są przesyłane przez infrastrukturę Azure, dlatego ich kopia może pojawić się w drugim regionie z opóźnieniem. Opóźnienie replikacji wpływa na maksymalny możliwy punkt odzyskiwania. Jeżeli awaria nastąpi krótko po wykonaniu ostatniej kopii, najnowszy punkt może nie być jeszcze dostępny w lokalizacji zapasowej. W praktyce należy rozróżniać RPO, czyli możliwą utratę danych wyrażoną w czasie, od RTO, czyli czasu potrzebnego na uruchomienie odtworzonego środowiska.

Przed rozpoczęciem restore trzeba ustalić, z którego punktu odzyskiwania będą pochodziły dane. Starszy punkt może być dostępny szybciej, natomiast nowszy może oczekiwać na zakończenie replikacji. Weryfikacji wymagają także status zadania backupu, stan replikacji, integralność punktu oraz retencja. Jeżeli polityka przechowywania usunęła wymagany punkt odzyskiwania, zmiana regionu nie przywróci dostępu do tej kopii. Odtworzenie nie powinno być rozpoczynane wyłącznie na podstawie informacji, że kopia istnieje w regionie podstawowym.

Przygotowanie docelowego środowiska i ograniczenia usługi

Restore w innym regionie może utworzyć nową maszynę wirtualną, dyski lub inne elementy zasobu, ale zwykle nie odtwarza całej architektury aplikacji jako jednego, automatycznie działającego systemu. Należy przygotować lub zweryfikować subskrypcję, grupę zasobów, sieć wirtualną, podsieć, reguły dostępu, adresację oraz uprawnienia wymagane do utworzenia zasobu. Trzeba również sprawdzić dostępność rozmiaru maszyny, typu dysku, kluczy szyfrowania i zależnych usług w regionie docelowym. Nazwy, identyfikatory zasobów i adresy prywatne mogą zmienić się po odtworzeniu.

Po zakończeniu operacji trzeba osobno sprawdzić system operacyjny, podłączone dyski, usługi uruchamiane przy starcie, konfigurację DNS, połączenia sieciowe i dostęp aplikacji do zależności. Jeżeli odtwarzana jest maszyna wirtualna, jej uruchomienie nie gwarantuje poprawnego działania aplikacji. Należy wykonać test logowania, odczytu danych, zapisu danych oraz komunikacji z wymaganymi punktami końcowymi. Warto też ustalić, czy nowy zasób nie koliduje z istniejącym adresem IP, nazwą hosta albo konfiguracją monitoringu.

Weryfikacja odtworzenia i postępowanie serwisowe

Poprawnie zaplanowany restore między regionami powinien być testowany przed rzeczywistą awarią. Test obejmuje wybór reprezentatywnego punktu odzyskiwania, utworzenie zasobu w regionie docelowym, sprawdzenie integralności systemu plików oraz uruchomienie najważniejszych funkcji aplikacji. Wynik należy porównać z wymaganym RTO i RPO. Jeżeli odtworzenie trwa dłużej od założeń albo brakuje aktualnych punktów, trzeba zmienić harmonogram kopii, retencję, sposób replikacji lub procedurę przełączenia.

Podczas diagnostyki problemu należy zebrać identyfikator zadania restore, komunikat błędu, region źródłowy i docelowy, typ magazynu, wybrany punkt odzyskiwania oraz szczegóły zasobu. Błędy mogą wynikać z braku uprawnień, niedostępności typu zasobu w regionie docelowym, niezgodności konfiguracji sieci, zakończonej retencji albo opóźnionej replikacji. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, natomiast analiza odtwarzania w Azure wymaga sprawdzenia konfiguracji usługi, konta oraz infrastruktury chmurowej zgodnie z zakresem używanego rozwiązania.