Analizowanie kryteriów podejmowania decyzji dotyczących wyboru narzędzi i modelu migracji
Po zapoznaniu się z opcjami metodologii migracji i opcji narzędzi możemy zapoznać się z kryteriami podejmowania decyzji, które należy wziąć pod uwagę, aby wykonać migracje do serwera elastycznego usługi Azure Database for PostgreSQL. Trzy główne kryteria, które pomagają nam dokonać wyborów, to Przestój, Lokalizacja źródłowej bazy danych i Możliwość dostosowywania.
Przestój
Przestój jest kluczowym aspektem działań związanych z migracją, a czas trwania, który jest akceptowalny dla uczestników projektu, pomaga nam zdecydować, czy musimy wykonać działania migracji w trybie offline lub online.
Zwykle działania związane z migracją są planowane z dużym wyprzedzeniem, aby upewnić się, że odpowiednie mechanizmy kontroli zmian i skojarzony nadzór zostaną ukończone dla działania. To planowanie umożliwia okno dialogowe z kluczowymi uczestnikami projektu, aby zrozumieć, jak długo system może być w trybie offline. W takiej sytuacji zaleca się, aby wiedzieć, jak długo trwa to dla różnych opcji, można ustanowić szacowany minimalny i maksymalny czas trwania przestojów.
Ustalenie minimalnego przestoju wymaganego do wykonania cięcia aplikacji jest kluczem. Ostatecznie tym razem jest to ilość, którą trzeba przejąć do trybu offline nawet w przypadku działania migracji online (lub minimalnego przestoju). Złożoność aplikacji będzie dyktować tę skalę czasu. W przypadku stosunkowo prostej aplikacji ten proces może być przypadkiem zatrzymania usługi, zaktualizowania pliku konfiguracji, a następnie włączenia go z powrotem. W bardziej złożonych środowiskach ten proces może trwać znacznie dłużej, jeśli istnieje wiele serwerów i warstw aplikacji w grze.
Zrozumienie czasu trwania działań związanych z migracją w trybie online lub offline jest kolejnym ważnym elementem związanym z przestojem. Jeśli jest to migracja w trybie offline, czas potrzebny na wyodrębnianie, przesyłanie i ładowanie danych ze źródła do miejsca docelowego, a następnie walidacja i weryfikacja to przestój. Ten przestój jest następnie przełączany między czasem potrzebnym do wyłączenia aplikacji/obciążenia i czasu potrzebnego do ponownego włączenia aplikacji/obciążenia.
Jeśli jest to migracja w trybie online (minimalny przestój), czas przestoju jest wymagany do zsynchronizowania ostatecznych zmian ze źródła do miejsca docelowego po wyłączeniu aplikacji. Dodaj do tego przestoju, walidację i działania weryfikacji przed ponownym skonfigurowaniem i włączeniem aplikacji/obciążenia.
Po udostępnieniu tych informacji możemy przyjrzeć się elementom technicznym migracji, aby ułatwić ustalenie, jakie są nasze realne opcje.
Lokalizacja źródłowej bazy danych
Lokalizacja źródłowa baz danych, które mają zostać zmigrowane, odgrywa rolę ze względu na ograniczenia, które prawdopodobnie zostaną wprowadzone dla danej konfiguracji.
Źródła lokalne lub nienależące do platformy Azure
W przypadku lokalnej lub nielokanej bazy danych platformy Azure ograniczenie klucza jest zwykle łącznością sieciową między źródłem a miejscem docelowym. Trzy kwestie, które należy wziąć pod uwagę, to przepustowość, opóźnienie i ilość danych. Po zrozumieniu tych punktów możemy podjąć świadomą decyzję o tym, jakiego typu migracja jest opłacalna.
Jeśli mamy dużą ilość danych do migracji i proporcjonalnie małą przepustowość, prawdopodobnie proste zrzuty i przywracanie prawdopodobnie nie będą opłacalne. Podczas gdy mamy dużą ilość danych i dużą przepustowość, jest to mniej istotne.
Podobnie, jeśli jest to migracja online, w której odbędzie się synchronizacja danych, opóźnienie jest jednym z kluczowych czynników. Jeśli opóźnienie jest wysokie, może to mieć negatywny wpływ na wydajność systemu, ponieważ proces synchronizacji trwa zbyt długo.
Ważnym czynnikiem, który należy również wziąć pod uwagę podczas migracji z innych dostawców chmury, jest to, czy pobierają opłaty za ruch wychodzący danych. Jeśli tak, może być możliwe zminimalizowanie fizycznego śladu przesyłanych danych może być istotne. W takich sytuacjach technologia kompresji może być ważna dla zrzutów lub strumieni danych używanych do synchronizacji.
Inne usługi oparte na platformie Azure
Będą sytuacje, w których chcesz przeprowadzić migrację z innych usług opartych na platformie Azure do usługi Azure Database for PostgreSQL — serwer elastyczny. Te źródłowe bazy danych mogą znajdować się na maszynach wirtualnych, kontenerach platformy Azure lub na pojedynczym serwerze usługi Azure Database for PostgreSQL. Jeśli tak, istnieje inny zestaw zagadnień do zbadania, ale jednocześnie kilka możliwości skorzystania z optymalizacji w ramach usług platformy Azure dla tych scenariuszy.
Dostosowywania
Ostatnim obszarem uwagi jest to, ile jest potrzebne lub pożądane dostosowanie. Może to mieć postać konieczności zmodyfikowania struktury źródłowej bazy danych w celu obsługi replikacji danych. Alternatywnie może to oznaczać, jak łatwo jest zautomatyzować skrypty.
Dobrym przykładem może być automatyzacja migracji bazy danych w trybie offline za pośrednictwem pg_dump i pg_restore, ale jednocześnie w tym kompresji i dekompresji plików zrzutu.
Podejmowanie decyzji
Po przejściu przez proces zbierania wszystkich tych informacji możemy współpracować z uczestnikami projektu, aby określić najlepszą opcję dla danego scenariusza. Podczas podejmowania decyzji, która metodologia i technologia mają być używane, ważne jest, aby nie tylko współpracować z uczestnikami projektu biznesowego, ale także z zainteresowanymi stronami technicznymi. Ta współpraca pomaga uniknąć sytuacji, w której firma prowadzi do minimalnej migracji przestojów, której zespół techniczny nie jest w stanie dostarczyć z powodu ograniczeń kadrowych, zasobów lub technologii.
Kluczową rzeczą jest zarządzanie oczekiwaniami i otwarte i uczciwe okno dialogowe. Ważne jest również zapewnienie, że firma przejmie na własność zadania weryfikacji, które znajdują się poza zakresem kompetencji zespołów technicznych dostarczających migrację bazy danych. Ta walidacja może obejmować sprawdzanie spójności i walidacji danych oraz testowanie środowiska użytkownika.