Ten wpis mówi głównie o problemach i wyzwaniach związanych z migracją AWS S3 do Azure Blob. Jeśli nie interesuje Cię wstęp kliknij tutaj.
Podobno najtrudniejszą częścią nowego zadania jest jego początek. Tym razem początek był raczej preludium do sztormu wyzwań, ale zacznijmy od początku.
Mój klient postawił sobie proste zadanie. Chciał przenieść wszystkie swoje aplikacje z chmury AWS do Azure. Żadna z nich nie używała czegoś zarezerwowanego tylko dla AWS'a więc temat wydawał się prosty od samego początku, szczególnie, że aplikacje zbudowane były tylko w oparciu o instancje EC2, wiaderka S3 i nie skomplikowane sieci a samo okno migracji mogło wynieść aż 8 godzin. Kilka spotkań z klientem wystarczyło na zebranie wymagań, wyklarowanie pomysłu na samą migrację i określenie największego ryzyka, to jest sprawnego przeniesienia olbrzymiej ilości danych.
Migracja serwerów EC2 do Azure VM była przyjemna i prosta. Same serwery nie przetrzymywały żadnych danych a procedura instalacji aplikacji była pięknie zautomatyzowana przez klienta. Cóż stało na przeszkodzie, aby nie dodać wykwintnego rozwiązania IaaC i zautomatyzować tworzenie także samych maszyn Azure VM? Jedyna napotkana trudność dotyczyła dostępności zasobów w konkretnych regionach Azure. Niby chmura taka elastyczna. Niby ma tak dużo zasobów. W tym projekcie powiedziałem "sprawdzam" i okazało się, że dla mnie tych zasobów zabrakło.
Migracja danych. Niemal każda aplikacja klienta korzystała z trzech miejsc do przetrzymywania danych: baz MS SQL, plików udostępnionych przez CIFS/SMB oraz wiaderek S3.
Na początek o ciszy przed sztormem, czyli migracja MS SQL oraz udostępnionych plików.
Baza danych MS SQL. Temat znany i opisany przez tak wiele osób, że ja sam nie mam nic do dodania. Użyliśmy natywnego dla bazy mechanizmu migracji danych. Wszystko przetestowaliśmy dla każdej aplikacji. Działało miodnie!
Zasoby udostępnione przez CIFS/SMB. Tutaj było podobnie jak w przypadku bazy danych. Migracje tego typu danych były i będą robione na wiele sposobów, z których każdy ma swoje plusy i minusy. W naszym wypadku zdecydowałem się na AWS DataSync. Migracje wstępne i przyrostowe wykonywały się w akceptowalnym czasie a sam proces i konfiguracja były uproszczone do minimum.
Pliki AWS S3 wędrują do Azure Blob.
Temat wydaje się prosty. Zarówno źródło, jak i miejsce docelowe na dane dostarczają podobnych funkcjonalności. Na pewno istnieją więc proste sposoby na przesłanie plików z S3 do Blob - prawda? Oczywiście, że tak! Pomijając aplikacje firm trzecich mamy do dyspozycji chociażby darmowe azcopy i rclone, czy też płatne Azure Data Factory (ADF). Zacząłem od darmowych narzędzi. Kilka szybkich testów dla wstępnych migracji na nieprodukcyjnych danych i mam to. Azcopy kopiuje wszystkie dane z prędkością odpowiadającą wydajności Azure Blob. Rclone zajmuje zaszczytne, drugie miejsce ze względu na czas potrzebny na zakończenie tego samego zadania. Czas na migracje zmian, które zaszły w wiadrze i tutaj pierwsza niespodzianka. Azcopy nie wspiera takiej migracji z S3 do Blob! Wspiera z Blob do Blob, ale mi to nic nie daje. Zostaję więc przy rclone i testuję czas potrzebny na zakończenie kopiowania. Działa! Przeszło! Niezbyt szybko, ale działa a to przecież najważniejsze. Zadowolony z testów przeszedłem do okiełznania największego ryzyka tego projektu, czyli migracji danych produkcyjnych. Szybko uruchomiłem rclone dla poszczególnych aplikacji, aby zebrać informacje ile tak naprawdę czasu będę musiał poświęcić na dogranie zmian przed przełączeniem z AWS do Azure. Pierwsza, druga, trzecia migracja przechodzi bez problemu, ale kiedy uruchomiłem proces dla największych wiaderek przeżywam szok! Prędkość przesyłu danych spada do okazałych wartości 0.05 MBps. Dlaczego? Jedno z wiaderek posiadało 0.3 miliarda malutkich plików. Tak duże spowolnienie wynikało z ograniczonego dostępu do AWS S3 API, a nie samego procesu przesyłania danych zawartych w plikach. Co z tym zrobić? Stwierdziłem, że może to czas, aby skorzystać z większego kalibru i zabrać się za temat przy użyciu Azure Data Factory. Szybka konfiguracja, uruchomienie migracji i leci. Prędkość przesyłania danych na dobrym poziomie, zadanie pokazuje jakieś sensowne statystyki - cudownie! Teraz tylko trzeba poczekać aż proces się zakończy. Niestety po równych 12 godzinach migracja przerwała się z zaskakującym błędem "Activity timed out".
Oblicz ile czasu potrzebujesz na migrację 36 TB danych przy użyciu ADF jeśli dane migrowane są z prędkością 40MBps. Dam Ci chwilę na rozwiązanie tego równania i dowiedzenie się dlaczego także ADF okazał się ślepym zaułkiem.
Dla ostatecznego potwierdzenia czy ADF nie pomoże mi z problemem przeprowadziłem test migracji wszystkich danych utworzonych po konkretnej dacie z przyszłości. Chodziło w nim o sprawdzenie ile czasu ADF będzie przeszukiwał i wybierał pliki do migracji przyrostowej. To zadanie trwało ponad 40 godzin co też stawiało pod znakiem zapytania jego użyteczność przy 8 godzinnym czasie na przełączenie aplikacji.
CDN