Udostępnij za pośrednictwem

Wybieranie regionów platformy Azure na potrzeby migracji

  • Artykuł

Podczas migracji istniejącego środowiska na platformę Azure należy wybrać region platformy Azure lub zestaw regionów do hostowania zmigrowanych składników. Wybór regionu obejmuje następujące kroki wysokiego poziomu:

  • Zapoznaj się z podstawowymi wskazówkami dotyczącymi wyboru regionów świadczenia usługi Azure, aby dowiedzieć się, jak wybrać regiony platformy Azure spełniające twoje wymagania.
  • Spis i dokumentowanie bieżącego stanu środowiska.
  • Zaimplementuj ogólne podejście do migracji, w tym to, czy należy uruchomić w jednym regionie, użyć wielu stref dostępności lub użyć wielu regionów.
  • Ocena zmian procesu, które mogą być wymagane.
  • Planowanie procesu migracji.
  • Optymalizowanie i podwyższanie poziomu zmian procesu.

Ten artykuł zawiera wskazówki dotyczące wybierania regionów platformy Azure spełniających potrzeby migracji. Jeśli jeszcze tego nie zrobiono, może być konieczne rozszerzenie regionów strefy docelowej w celu obsługi podejść obejmujących wiele regionów.

Uwaga

W tym artykule opisano zagadnienia specyficzne dla migracji obciążeń. Należy również zapoznać się z ogólnymi zasadami wybierania regionów platformy Azure dla dowolnej organizacji lub obciążenia. Aby uzyskać więcej informacji, zobacz Wybieranie regionów świadczenia usługi Azure.

Dokumentowanie złożoności scenariusza

Ustal, czy scenariusz wymaga dostosowania dokumentacji i procesu. Poniższe podejście może pomóc ocenić potencjalne wyzwania i ustanowić ogólny przebieg działania:

  • Rozważ bardziej niezawodną gotowość i implementację ładu.
  • Utwórz spis obszarów geograficznych, których dotyczy problem. Skompiluj listę krajów lub regionów, których dotyczy problem.
  • Dokumentowanie bazy użytkowników. Czy migracja do chmury wpłynie na pracowników, partnerów lub klientów w określonym kraju lub regionie?
  • Dokumentowanie centrów danych i zasobów. Czy nakład pracy na migrację obejmuje jakiekolwiek zasoby w zidentyfikowanym kraju lub regionie?
  • Dokumentowanie regionalnych wymagań dotyczących dostępności wersji produktu i trybu failover.
  • Udokumentowanie wymagań dotyczących odporności w celu określenia, czy strefy dostępności są wymagane. Zazwyczaj należy wziąć pod uwagę wymagania dotyczące odporności dla całego scenariusza, a nie dla poszczególnych regionów.
  • Udokumentowanie wymagań dotyczących niezależności i wymagań dotyczących rezydencji danych. Obciążenia, które mają określone wymagania dotyczące niezależności lub przechowywania danych, mogą mieć wpływ na wybór regionów świadczenia usługi Azure.

W trakcie procesu migracji należy wziąć pod uwagę sposób dopasowywania zmian do różnych scenariuszy i spisów. W poniższej tabeli przedstawiono przykład sposobu dokumentowania różnych scenariuszy.

Region (Region) Kraj/region Pracownicy lokalni Lokalni użytkownicy zewnętrzni Lokalne centra danych lub zasoby Wymagania dotyczące niezależności danych
Ameryka Północna Stany Zjednoczone Tak Partnerzy i klienci Tak Nie.
Ameryka Północna Kanada Nie. Odbiorcy Tak Tak
Europa Niemcy Tak Partnerzy i klienci Nie — tylko sieć Tak
Azja i Pacyfik Korea Południowa Tak Partnerzy Tak Nie.

Dlaczego lokalizacja użytkowników jest odpowiednia?

Organizacje, które obsługują użytkowników w wielu krajach lub regionach, opracowują rozwiązania techniczne, które dotyczą ruchu użytkowników. W niektórych przypadkach rozwiązania obejmują lokalizację zasobów. W innych scenariuszach organizacja może zdecydować się na wdrożenie rozwiązań globalnej sieci rozległej (WAN), aby rozwiązać problemy z różnymi bazami użytkowników za pośrednictwem rozwiązań skoncentrowanych na sieci. W obu przypadkach profile użycia różnych użytkowników mogą mieć wpływ na strategię migracji.

Jeśli na przykład organizacja obsługuje pracowników, partnerów i klientów w Niemczech, ale obecnie nie ma centrów danych w Niemczech, organizacja prawdopodobnie implementuje rozwiązanie dzierżawione . Tego typu rozwiązanie kieruje ruch do centrów danych w innych krajach lub regionach. Ten istniejący routing stanowi znaczne ryzyko dla postrzeganej wydajności migrowanych aplikacji. Wstrzykiwanie większej liczby przeskoków w ustalonej i dostrojonej globalnej sieci WAN może stworzyć postrzeganie niedostatecznych aplikacji po migracji. Znajdowanie i rozwiązywanie tych problemów może dodać do projektu znaczne opóźnienia.

Każda z poniższych sekcji zawiera wskazówki dotyczące rozwiązywania tej złożoności między wymaganiami wstępnymi i procesami oceny, migracji i optymalizacji. Zrozumienie profilów użytkowników w każdym kraju lub regionie ma kluczowe znaczenie dla prawidłowego zarządzania tą złożonością.

Dlaczego lokalizacja centrów danych jest ważna?

Lokalizacja istniejących centrów danych może mieć wpływ na strategię migracji. Rozważmy następujący czynniki:

Decyzje dotyczące architektury: Jednym z pierwszych kroków w projekcie strategii migracji jest określenie regionu docelowego. Lokalizacja istniejących zasobów często wpływa na tę determinację. Ponadto dostępność usług w chmurze i koszt jednostkowy tych usług mogą się różnić w zależności od regionów. Wymagania dotyczące rezydencji danych, w tym wymagania dotyczące niezależności, mogą również mieć wpływ na decyzję o architekturze. Zrozumienie, gdzie znajdują się bieżące i przyszłe zasoby, wpływa na decyzje dotyczące architektury i może wpływać na szacunki budżetowe.

Zależności centrum danych: w tabeli w sekcji Dokumentowanie złożoności scenariusza przykładowe scenariusze pokazują, że prawdopodobnie trzeba zaplanować zależności między różnymi globalnymi centrami danych. Organizacje, które działają na tej skali, mogą nie udokumentować lub jasno zrozumieć te zależności. Podejście organizacji do oceny profilów użytkowników pomaga zidentyfikować niektóre z tych zależności w organizacji. Twój zespół powinien również zbadać więcej kroków oceny, które mogą pomóc w ograniczeniu ryzyka i złożoności wynikających z zależności.

Implementowanie ogólnego podejścia

Poniższe podejście korzysta z modelu opartego na danych, aby sprostać globalnym złożonościom migracji. Jeśli zakres migracji obejmuje wiele regionów, zespół wdrożeniowy ds. chmury powinien ocenić następujące zagadnienia dotyczące gotowości:

  • Określ, czy możesz spełnić wymagania biznesowe: użyj wielu stref dostępności, aby określić wymagania dotyczące wysokiej dostępności, odporności, wydajności i kosztów. Jeśli te wymagania nie zostaną spełnione, zastanów się, czy potrzebujesz podejścia obejmującego wiele regionów.

  • Ocena niezależności danych: niezależność danych może wymagać lokalizacji niektórych zasobów, ale wiele zasobów nie podlega tym ograniczeniom zgodności. Usługi takie jak rejestrowanie, raportowanie, routing sieciowy, tożsamość i inne centralne usługi IT mogą być hostowane jako usługi udostępnione w wielu subskrypcjach lub regionach. Ocena niezależności danych przy użyciu modelu usługi udostępnionej dla tych usług. Aby zapoznać się z opisem tego podejścia, zobacz architekturę referencyjną topologii piasty i szprych z usługami udostępnionymi.

  • Upewnij się, że środowisko jest skalowane: jeśli wdrażasz wiele wystąpień podobnych środowisk, możesz ustanowić dedykowany zespół ds. migracji środowiska, aby ułatwić tworzenie spójności, ulepszanie ładu i przyspieszanie wdrażania. W przypadku przewodnika dotyczącego ładu dla przedsiębiorstw złożonych jest ustanawiane podejście, które tworzy środowisko skalujące się w wielu regionach.

Wymagania wstępne oparte na danych

Jeśli twój zespół jest komfortowo z podejściem bazowym i gotowość jest dopasowany, należy wziąć pod uwagę następujące wymagania wstępne oparte na danych:

  • Kompletne ogólne odnajdywanie: ukończ tabelę w temacie Złożoność dokumentu, aby ocenić złożoność strategii wdrażania chmury.

  • Analizowanie profilów użytkowników dla każdego kraju lub regionu, którego dotyczy problem: ważne jest, aby zrozumieć ogólny routing użytkowników na wczesnym etapie procesu migracji. Zmiana globalnych linii dzierżawy i dodawanie połączeń, takich jak usługa Azure ExpressRoute do centrum danych w chmurze, może spowodować miesiące opóźnień w sieci. Rozwiąż problem z routingiem użytkowników tak szybko, jak to możliwe.

  • Ukończenie początkowej racjonalizacji majątku cyfrowego: jeśli wprowadzisz złożoność strategii migracji, ukończ początkową racjonalizację majątku cyfrowego. Aby uzyskać więcej informacji, zobacz Co to jest majątek cyfrowy?.

  • Użyj tagowania dla wymagań dotyczących majątku cyfrowego: ustanów zasady tagowania, aby zidentyfikować wszelkie obciążenia, które mają wpływ na wymagania dotyczące niezależności danych. Upewnij się, że wymagane tagi zaczynają się racjonalizacji majątku cyfrowego i przechodzą do zmigrowanych zasobów.

  • Ocena modelu piasty i szprych: systemy rozproszone często mają wspólne zależności. Często można rozwiązać współużytkowane zależności, implementując model piasty i szprych. Chociaż implementacja modelu piasty i szprych jest poza zakresem procesu migracji, flaga modelu do rozważenia podczas przyszłych iteracji gotowych procesów.

  • Określanie priorytetów listy prac migracji: jeśli wymagane są zmiany sieci w celu obsługi wdrożenia produkcyjnego obciążenia obsługującego wiele regionów, zespół strategiczny ds. chmury powinien śledzić eskalacje wynikające ze zmian sieci i zarządzać nimi. Ten wyższy poziom pomocy technicznej kadry kierowniczej pomaga przyspieszyć zmianę, zwalniając zespół strategiczny do ponownego pisania listy prac i upewniając się, że zmiany w sieci nie blokują obciążeń globalnych. Określanie priorytetów obciążeń globalnych tylko po zakończeniu zmian sieci.

Te wymagania wstępne pomagają ustalić procesy, które mogą sprostać złożoności podczas wykonywania strategii migracji.

Zmiany procesu oceniania

Jeśli scenariusz migracji obejmuje globalne złożoność zasobów i baz użytkowników, dodaj kluczowe działania, aby ocenić kandydatów do migracji. Te działania generują dane, aby ułatwić wyjaśnienie przeszkód i wyników dla użytkowników i zasobów globalnych.

Sugerowane akcje podczas procesu oceny

Ocena zależności między centrami danych: narzędzia do analizy zależności w usłudze Azure Migrate mogą pomóc w określeniu zależności. Przed rozpoczęciem migracji użyj tych narzędzi. Jeśli scenariusz obejmuje złożoność globalną, ocena zależności jest niezbędnym krokiem w procesie oceny. Grupowanie zależności umożliwia wizualizowanie zależności oraz identyfikowanie adresów IP i portów wszystkich zasobów wymaganych do obsługi obciążenia.

Ważne

  • Potrzebujesz eksperta w tej dziedzinie (SME), który rozumie schematy umieszczania zasobów i adresów IP, aby zidentyfikować zasoby, które znajdują się w pomocniczym centrum danych.
  • Oceń zależności podrzędne i klientów w wizualizacji, aby zrozumieć zależności dwukierunkowe.

Identyfikowanie wpływu na użytkowników globalnych: dane wyjściowe z analizy wymagań wstępnych profilu użytkownika powinny identyfikować wszelkie obciążenia, które mają wpływ na globalne profile użytkowników. Jeśli kandydat do migracji znajduje się na liście obciążeń, których dotyczy problem, architekt migracji powinien skonsultować się z siecią i operacjami MŚP. Ci eksperci pomagają zweryfikować oczekiwania dotyczące routingu i wydajności sieci. Co najmniej architektura powinna obejmować połączenie usługi ExpressRoute między najbliższym centrum operacji sieciowych a platformą Azure. Architektura referencyjna połączeń usługi ExpressRoute może pomóc w skonfigurowaniu niezbędnych połączeń sieciowych.

Projektowanie pod kątem zgodności: dane wyjściowe z wymaganej analizy profilu użytkownika powinny również identyfikować wszelkie obciążenia, które mają wpływ na wymagania dotyczące niezależności danych. Podczas działań związanych z architekturą procesu oceny przypisany architekt powinien skonsultować się ze specjalistami ds. zgodności. Ci eksperci mogą pomóc architektowi zrozumieć wszelkie wymagania dotyczące migracji i wdrażania w wielu regionach. Te wymagania znacząco wpływają na strategie projektowania. Następujące architektury referencyjne mogą pomóc w projektowaniu:

Ostrzeżenie

Jeśli używasz architektury referencyjnej dla usługi ExpressRoute lub architektur referencyjnych aplikacji, może być konieczne wykluczenie określonych elementów danych z procesów replikacji w celu spełnienia wymagań dotyczących niezależności danych. Zadanie wykluczania określonych elementów danych dodaje krok do procesu podwyższania poziomu.

Zmiany procesu migracji

W przypadku migracji aplikacji, która musi zostać wdrożona w wielu regionach, zespół wdrożeniowy ds. chmury musi uwzględnić jeszcze kilka zagadnień. Projekt magazynów i serwerów przetwarzania usługi Azure Site Recovery to dwa z tych zagadnień. Dwie inne zagadnienia to projekty przepustowości sieci i synchronizacja danych.

Sugerowane akcje podczas procesu migracji

Projekt magazynu usługi Site Recovery: usługa Site Recovery to sugerowane narzędzie do replikacji natywnej dla chmury i synchronizacji zasobów cyfrowych na platformie Azure. Usługa Site Recovery replikuje dane dotyczące każdego zasobu do magazynu usługi Site Recovery. Ten magazyn jest powiązany z określoną subskrypcją w określonym regionie i centrum danych platformy Azure. W przypadku replikowania zasobów do drugiego regionu może być również potrzebny drugi magazyn usługi Site Recovery.

Projekt serwera konfiguracji i przetwarzania: usługa Site Recovery współpracuje z lokalnym wystąpieniem konfiguracji i serwera przetwarzania powiązanego z pojedynczym magazynem usługi Site Recovery. W przypadku korzystania z tej konfiguracji może być konieczne zainstalowanie drugich wystąpień tych serwerów w źródłowym centrum danych, aby ułatwić replikację.

Projekt przepustowości sieci: podczas replikacji i trwającej synchronizacji dane binarne są przenoszone przez sieć ze źródłowego centrum danych do magazynu usługi Site Recovery w docelowym centrum danych platformy Azure. Proces replikacji i synchronizacji zużywa przepustowość. Duplikowanie obciążenia do drugiego regionu podwaja ilość zużytej przepustowości.

W niektórych scenariuszach przepustowość jest ograniczona. W innych obciążeniach wiąże się ze znaczną konfiguracją lub dryfem danych. W takich przypadkach replikowanie danych do drugiego regionu może zakłócać czas potrzebny na ukończenie migracji. Co ważniejsze, te ograniczenia mogą mieć wpływ na środowisko użytkowników lub aplikacji, które nadal zależą od przepustowości dostępnej w źródłowym centrum danych.

Synchronizacja danych: największy drenaż przepustowości często pochodzi z synchronizacji platformy danych. W przypadku wdrażania w wielu strefach dostępności może być możliwe użycie strefowo nadmiarowych usług danych, które automatycznie synchronizują dane w wielu strefach dostępności. Wdrożenie w wielu regionach często wymaga synchronizacji danych, aby aplikacje były dostosowane. Takie podejście jest definiowane w architekturach referencyjnych dla aplikacji internetowych w wielu regionach i aplikacji n-warstwowych w wielu regionach.

Jeśli synchronizowanie aplikacji jest stanem operacyjnym aplikacji, który chcesz zsynchronizować, możesz zsynchronizować źródłową platformę danych z każdą platformą w chmurze. Wykonaj tę synchronizację przed przeprowadzeniem migracji zasobów aplikacji i warstwy środkowej.

Odzyskiwanie po awarii z platformy Azure do platformy Azure: alternatywna opcja może jeszcze bardziej zmniejszyć złożoność. Jeśli używasz wdrożenia dwuetapowego w celu spełnienia wymagań dotyczących osi czasu i synchronizacji danych, odzyskiwanie po awarii z platformy Azure do platformy Azure może być akceptowalnym rozwiązaniem. W tym scenariuszu zmigrujesz obciążenie do pierwszego centrum danych platformy Azure przy użyciu jednego magazynu usługi Site Recovery oraz konfiguracji i projektu serwera przetwarzania. Po przetestowaniu obciążenia można odzyskać obciążenie do drugiego centrum danych platformy Azure z migrowanych zasobów.

Takie podejście zmniejsza wpływ na zasoby w źródłowym centrum danych. Odzyskiwanie po awarii między platformą Azure i platformą Azure korzysta również z szybkich szybkości transferu i wysokich limitów przepustowości między centrami danych platformy Azure.

Uwaga

Podejście do odzyskiwania po awarii z platformy Azure do platformy Azure może zwiększyć krótkoterminowe koszty migracji dzięki wyższym opłatom za przepustowość ruchu wychodzącego.

Zmiany procesu wydania

W miarę rozwiązywania problemów ze złożonością globalną podczas optymalizacji i podwyższania poziomu możesz wymagać identycznych wysiłków w każdym regionie, w którym wdrażasz. Jeśli używasz jednego regionu, nadal może być konieczne replikowanie planów testowania biznesowego i zmian biznesowych.

Sugerowane akcje podczas procesu wydawania

Optymalizacja przedtestem: wstępne testowanie automatyzacji może identyfikować potencjalne możliwości optymalizacji, podobnie jak w przypadku wszelkich działań migracji. W przypadku obciążeń globalnych niezależnie przetestuj obciążenie w każdym regionie. Drobne zmiany konfiguracji w sieci lub w wybranym centrum danych platformy Azure mogą mieć wpływ na wydajność.

Plany zmian biznesowych: utwórz plan zmian biznesowych dla dowolnego złożonego scenariusza migracji. Plan zmian biznesowych pomaga zapewnić wyraźną komunikację na temat zmian w procesach biznesowych i środowiskach użytkownika. Plan pomaga również zapewnić wyraźną komunikację na temat czasu wysiłków wymaganych do zintegrowania zmian. W ramach globalnego nakładu pracy nad migracją plan powinien uwzględniać zagadnienia dotyczące użytkowników w każdej lokalizacji geograficznej, której dotyczy problem.

Testowanie biznesowe: każdy region może również wymagać testowania biznesowego. Testowanie biznesowe pomaga zapewnić odpowiednią wydajność i przestrzeganie zmodyfikowanych wzorców routingu sieciowego.

Loty podwyższania poziomu: podwyższenie poziomu często odbywa się jako pojedyncze działanie, a ruch produkcyjny jest natychmiast przekierowywany do migrowanych obciążeń. W ramach globalnego nakładu pracy nad wydaniem należy zapewnić promocję w wstępnie zdefiniowanych kolekcjach użytkowników nazywanych lotami. Loty podwyższania poziomu zapewniają zespołowi ds. strategii chmury i zespołowi wdrożeniowemu ds. chmury możliwość obserwowania wydajności i poprawy obsługi użytkowników w każdym regionie. Możesz kontrolować loty podwyższania poziomu na poziomie sieci. W szczególności można zmienić routing określonych zakresów adresów IP z zasobów obciążenia źródłowego na nowo zmigrowane zasoby. Po przeprowadzeniu migracji określonej kolekcji użytkowników możesz przekierować następną grupę.

Optymalizacja lotów: Jedną z korzyści związanych z podwyższeniem poziomu jest to, że zapewniają one dokładniejsze obserwacje i możliwość optymalizacji wdrożonych zasobów. Gdy pierwszy lot pomyślnie używa środowiska produkcyjnego przez krótki czas, możesz udoskonalić zmigrowane zasoby, gdy procedury operacji IT go obsługują.