Migracja do chmury Microsoft Azure

Migracja do chmury Microsoft Azure to wyzwanie dla wielu firm, które realizują proces cyfrowej transformacji. Postanowiliśmy przygotować mały poradnik, zwracający uwagę na najczęściej pojawiające się kwestie przy migracji do chmury Azure.

Migracja do chmury Microsoft Azure - najczęściej popełniane błędy

Błąd 1: Ten sam model zarządzania zasobami w „chmurze” jak w lokalnym centrum danych

Usługi i rozwiązania chmurowe dostarczane są w różnych modelach (m.in. IaaS, SaaS, PaaS), gdzie w zależności od modelu, za poszczególne warstwy utrzymania (np. sprzętu fizycznego, sieci, systemów operacyjnych a także aplikacji)  odpowiadają dostawcy usług – dlatego, podczas migracji należy zwrócić uwagę na to, jaki zakres odpowiedzialności jest po stronie dostawcy usług, a jaki po stronie ich nabywcy.

Błąd 2: Porównanie kosztów

Często porównując koszty rozwiązań chmurowych vs. utrzymanie lokalnej serwerowni, bierzemy pod uwagę jedynie koszty sprzętu fizycznego oraz licencji, które posiadamy,  pomijając koszty operacyjne związane z jej utrzymaniem (m.in. media, wsparcie techniczne, monitorowanie i zarządzanie infrastrukturą), które mogą stanowić nawet 90% wszystkich kosztów.

Błąd 3: Planując ilość potrzebnych  zasobów do uruchomienia usług w chmurze, często porównujemy je 1:1 z aktualnie posiadanymi zasobami w lokalnej serwerowni.

Należy jednak pamiętać, że obecne zasoby są efektem planowanego wzrostu obciążenia w przyszłości, które zostały przewidziane na etapie ich  wdrożenia. Uruchamiając usługi w chmurze, mamy możliwość zmiany przydzielonych zasobów w dowolnym momencie, a także możemy wdrożyć pewną dynamikę korzystania z tych zasobów w zależności od aktualnego obciążenia, co pozwala je optymalizować i ponosić koszty tylko tych zasobów, z których aktualnie korzystamy. Pomocne są tu narzędzia Azure Reservations i Azure Advisor.

Azure Recovery Services  oferuje  dwie usługi:

• Azure Backup – umożliwia proste, bezpieczne i ekonomiczne wykonanie kopii zapasowych infrastruktury w chmurze,
• Azure Site Recovery - umożliwia odzyskiwanie (przywracanie)  stanu infrastruktury  sprzed  awarii  (usługa DRaaS platformy Azure).

Azure Backup  oferuje tworzenie kopii zapasowych:

• Danych z lokalnego serwera— umożliwia utworzenie kopii zapasowych plików, folderów oraz stanu lokalnego systemu przy użyciu agenta MARS,
• Maszyn wirtualnych – umożliwia utworzenie kopii zapasowej całych maszyn wirtualnych systemu Windows/Linux VMware i Hyper-V
• Serwer SQL – umożliwia utworzenie kopii zapasowych baz danych programu SQL Server
• Bazy danych SAP HANA - umożliwia utworzenie kopii zapasowych bazy danych SAP HANA uruchomionych na maszynach wirtualnych platformy Azure

Jeżeli chodzi o kopię zapasową mamy tak naprawdę dwie możliwości:

• Kopia bezpośrednia – pozwala na tworzenie kopii zapasowych systemów operacyjnych i aplikacji oraz ich przechowywanie w chmurze z wykorzystaniem dedykowanego agenta (MARS).  Agent Microsoft Azure Recovery Services (MARS)  służy do konfigurowania zasad tworzenia kopii zapasowych, co daje nam możliwość wykonywania różnego rodzaju kopii, jak również zdefiniowanie jakie kopie i jak długo powinny być przechowywane na platformie Azure
  
  
• Kopia pośrednia – dedykowane rozwiązanie dla większych środowisk oparte na wdrożeniu dodatkowego serwera, który będzie pośredniczył w przekazywaniu kopii zapasowych na platformę Azure za pomocą DPM (System Center Data Protection Manager) lub Azure Backup Server

Azure Site Recovery – umożliwia replikację infrastruktury maszyn fizycznych i wirtualnych z lokalnego centrum danych do platformy Azure. W przypadku awarii w lokalnym centrum danych wdrażane jest   przełączenie w tryb failover do zreplikowanej infrastruktury na platformie Azure, który umożliwia  dostęp do aplikacji. Po usunięciu awarii lokalnego centrum danych możliwy jest powrót do lokalnej infrastruktury, a więc wyłączenie zapasowej infrastruktury.

„Site Recovery to natywne rozwiązanie odzyskiwania po awarii jako usługa (DRaaS), a w raporcie firmy Gartner „Magic Quadrant for Disaster Recovery as a Service” z 2019 roku firma Microsoft została uznana za lidera wśród dostawców rozwiązań DRaaS na podstawie kompletności wizji i możliwości jej realizowania.”

Microsoft deklaruje, że jeżeli czas przełączenie będzie trwał więcej niż 2h, to otrzymujemy 100% zwrotu kosztów za usługę, co  wskazuje, że  maksymalny czas przełączenia to 2h.

Scenariusze odzyskiwania po awarii przy wykorzystaniu usługi Site Recovery:

1. Maszyn fizycznych – jest to możliwe częściowo, co oznacza, że możliwa jest replikacja maszyny fizycznej na platformę Azure, jednak w tym scenariuszu przełączenie powrotne możliwe jest jedynie na platformę wirtualną.
2. Maszyn wirtualnych – w tym scenariusz replikowane są wirtualne maszyny Hyper-V lub Vmware, przełączenie powrotne odbywa się do odpowiednie wirtualnego środowiska.
3. Replikacja maszyn do innego regionu – w tym scenariuszu, replikowane są maszyny do kolejnych regionów.

Wyzwania podczas wdrożenia:

• czas odzyskiwania (RTO, recovery time objectives) - to maksymalny czas, w którym konieczne jest odzyskanie danych i pełne wznowienie działania systemu, czyli czas na usunięcie awarii, czas kiedy usługa nie działa
• punkt odzyskiwania (RPO, recovery point objectives) - maksymalna tolerancja utraty danych w czasie, na jaką może sobie pozwolić przedsiębiorstwo.

Należy pamiętać, że w przypadku przywracania po awarii te czasu się sumują.

Narzędzia wspierające punkty przywracania :

• Spójność danych wielu maszyn – możemy zdefiniować maszyny, które będę miały punkt przywracania utworzony dokładnie w tym samym czasie, co gwarantuje integralność danych po zakończeniu procesu ich odtwarzania.
• Plany odzyskiwania – pozwalają zdefiniować w jakiej kolejności maszyny wirtualne będę uruchamiane w zdalnej lokalizacji w trakcie odtwarzania po awarii.

Dlaczego warto skorzystać w ramach Disaster Recovery z narzędzi Microsoft i platformy Azure?:

1. Testowe przełączenie – polega na uruchomieniu maszyny wirtualnej lub grupy maszyn, dla których jest skonfigurowana replikacja na platformę Azure. Przełączenie w żaden sposób nie wpływa na skonfigurowaną replikację, jednocześnie pozwalając na sprawdzenie w dowolnym momencie jak zostaną odtworzone maszyny w przypadku awarii lokalnej infrastruktury.
2. Planowe przełączenie – pozwala w bezpieczny i kontrolowany sposób przełączyć lokalną infrastrukturę na tę replikowaną do chmury. Jest to szczególnie przydatne, kiedy spodziewamy się prac planowanych, które mogą w jakimś stopniu stwarzać ryzyko przerwy działania naszej infrastruktury lokalnej.  Uruchamiając planowe przełączenie, jeszcze w czasie kiedy nasza lokalna infrastruktura działa poprawnie, w pierwszej kolejności następuje replikacja wszystkich zmian, które występują pomiędzy lokalną infrastrukturą a tą zreplikowaną w Azure. Takie rozwiązanie gwarantuje RPO na poziomie równym 0.
3. Przełączenie powrotne – jest realizowane wtedy, gdy awaria lokalnej infrastruktury została usunięta i wszystkie systemy mogą być uruchomione lokalnie. Po przełączeniu usługi korzystają tylko z zasobów lokalnych. Koszty związane z zasobami używanymi na platformie Azure są zminimalizowane, ponieważ infrastruktura na tej platformie została uruchomiona tylko na czas awarii i zostaje wyłączona w momencie przełączenia powrotnego.
4. Replikacja przyrostowa – jest istotna dla utrzymania aktualnego stanu infrastruktury na platformie Azure. Pozwala na szybkie aktualizowanie stanu maszyn wirtualnych, przesyłając jedynie te dane, które się zmieniły. Pozwala to na osiągnięcie stosunkowo niskiego wskaźnika RPO w przypadku awarii.

PYTANIA? SKONTAKTUJ SIĘ Z NAMI

Zobacz również:

Analiza kosztów w AWS, Azure, GCP, OVHcloud

Wprowadzenie do Microsoft Azure

Wysoka dostępność serwisu. Jak ją ustalić i wyliczyć?