Narzędzia do migracji mogą pomóc podczas przenoszenia aplikacji z lokalnego środowiska do chmury publicznej. Sprawy komplikują się, kiedy aplikacje pracują już w chmurze publicznej. Przeniesienie ich do innego operatora może okazać się żmudnym, przeprowadzanym ręcznie procesem. Brak standardów sprawia, że nie ma dziś dobrego, zautomatyzowanego rozwiązania do takiej migracji.

Za przenoszeniem aplikacji między chmurami publicznymi mogą stać różne powody: finansowe (lepsza oferta nowego operatora); przerwy w dostępności obecnie używanej chmury; brak wystarczających mechanizmów bezpieczeństwa; czy też zakończenie świadczenia danej usługi. Takie rzeczy się zdarzają, co potwierdza przykład rezygnacji z oferowania usług HP Helion Public Cloud.

Brak standardów utrudnia migrację

Chmura miała ułatwić migrowanie zasobów. Teoretycznie w pełni wirtualne środowisko powinno redukować zależności między aplikacjami a warstwą sprzętową. Operatorzy chmurowi z reguły oferują zaś do wyboru różne platformy i narzędzia. Wydawałoby się więc, że kiedy aplikacja znajdzie się już w chmurze, jej przenoszenie powinno być dość proste. Niestety nie ma dwóch identycznych środowisk IT i chmura nie stanowi tu wyjątku, choć o potrzebie stworzenia branżowych standardów w tym obszarze mówi się już długo.

Mimo że chmury publiczne są już powszechnie wykorzystywane, to brak standardów sprawił, że dotychczas nie powstały w pełni zautomatyzowane narzędzia umożliwiające migrację między chmurami publicznymi, które, np. wprowadzałyby wymagane zmiany w konfiguracji (np. IP, DNS) czy też przeprowadzały testy aplikacji. Przykładowo, w nowej lokalizacji może być konieczna rekonfiguracji DNS tak, aby zamiast wskazywać na bramkę NAT, zwracał adresy poszczególnych maszyn. Testy sprawdzające poprawność działania aplikacji w nowym centrum danych mogą zaś zająć więcej czasu niż sama migracja. Ręcznej interwencji może wymagać podstawowy proces migracji – przenoszenia maszyn wirtualnych, systemów operacyjnych oraz danych i plików. Operatorzy chmur rozwijają bowiem własne, unikalne rozwiązania, ale można podjąć działania zapobiegawcze, które w ułatwią migrację.

Większa różnorodność środowiska to łatwiejsza migracja

Najlepszym sposobem na uproszczenie procesu migracji jest ograniczenie zależności od infrastrukturą chmury publicznej. Dlatego już podczas migracji z lokalnego środowiska do chmury należy wybrać takiego operatora, który obsługuje szeroką gamę platform (włączając w to bazy danych, narzędzia programistyczne i protokoły zarządzania siecią – z każdych po kilka wersji). Zaletą jest również wsparcie dla otwartych standardów, jak choćby OpenStack.

Dobrym pomysłem jest też tworzenie aplikacji działających w wirtualnych maszynach i używanie języków programowania wysokiego poziomu. Przełoży się to na większą niezależność od platformy chmurowej. Jeszcze lepszym rozwiązaniem jest tworzenie aplikacji działających w kontenerach, np. w Dockerze, które są niezależne od systemu operacyjnego i platformy wirtualizacyjnej. Jednakże w przypadku starszych aplikacji nie zawsze jest to możliwe, a na pewno będzie wymagało modyfikacji ich kodu.

Jak przeprowadzić testy aplikacji w chmurze

Testy aplikacji w nowym środowisku trzeba przeprowadzić zanim wyłączy się te aplikacje w starej lokalizacji. Operator docelowej chmury powinien umożliwić symulowanie rzeczywistych warunków pracy i nawiązywanie sesji przez wielu użytkowników. Wiele aplikacji działa poprawnie, kiedy korzysta z nich jeden użytkownik, ale przy rosnącej ich liczbie mogą wyjść na jaw różne problemy.

Trzeba ustalić również jaka ilość danych jest do przeniesienia. Mając setki użytkowników i miliony rekordów zapisanych w chmurze, przeniesienie wszystkiego będzie kosztowne i czasochłonne. W tym miejscu pojawia się też kwestie ewentualnego przestoju i jego kosztów. Rozwiązaniem problemu jest synchronizacja, ale nie zawsze będzie możliwa.

Ważnym czynnikiem podczas migracji pomiędzy chmurami jest przepustowość połączenia sieciowego. Idealną sytuacją byłoby bezpośrednie połączenie światłowodowe między chmurami, ale nie należy się spodziewać tego w pracy, szczególnie jeśli chodzi o konkurencyjnych operatorów chmurowych. Warto natomiast ustalić, jakie są możliwości komunikacji między starą chmurą a nowymi, rozważanymi operatorami chmur.

Trzeba pamiętać również, że po przeniesieniu zasobów i przeprowadzeniu testów może być wymagana jeszcze synchronizacja pomiędzy starym i nowym środowiskiem. Aby ją przeprowadzić, z reguły potrzebne jest dodatkowe wsparcie ze strony nowego operatora chmury. Warto zwrócić uwagę, że jest to sposób na zbudowanie mechanizmów przywracania po awarii. Jeśli aplikacje będą utrzymywane w dwóch lokalizacjach i synchronizowane w regularnych odstępach czasu, jedna z chmur obliczeniowych może pełnić rolę ośrodka zapasowego. Niestety trzeba liczyć się z tym, że synchronizacja nie będzie odbywać się w pełni automatycznie.

Migracja usług PaaS

Przenoszenie zasobów między usługami IaaS (Infrastructure-as-a-Service) może wymagać ręcznej interwencji, ale i tak jest łatwiejszym zadaniem, niż przenoszenie danych między różnymi dostawcami usług PaaS (Platform-as-a-Service). Większość pracy podczas migracji między platformami IaaS polega na przenoszeniu danych między repozytoriami. Natomiast aplikacje są znacznie silniej połączone z poszczególnymi platformami PaaS. Przykładowo, dostawcy PaaS obsługują określone języki, ale każdy z nich robi to w nieco inny sposób, więc pojawia się konieczność modyfikowania kodu przenoszonej aplikacji.

Również wyciągnięcie danych z aplikacji może być trudnym zadaniem. Konieczne może się okazać użycie odpowiednich interfejsów API, m.in. do obsługi pamięci podręcznej (cache) czy tworzenia nowych instancji aplikacji. Każdy proces migracji pomiędzy platformami PaaS wymaga indywidualnego podejścia, a dopiero po dokładnym poznaniu tego typu usług od różnych dostawców można przygotować się do procesu migracji.

Podziel się na:
  • Facebook
  • Google Bookmarks
  • LinkedIn