Przenoszenie usług aplikacja systemu Azure do innego regionu

W tym artykule opisano sposób przenoszenia zasobów usługi App Service do innego regionu świadczenia usługi Azure.

Istnieją różne powody, dla których możesz przenieść istniejące zasoby platformy Azure z jednego regionu do innego. Możesz chcieć:

• Skorzystaj z nowego regionu świadczenia usługi Azure.
• Wdrażanie funkcji lub usług dostępnych tylko w określonych regionach.
• Spełnij wymagania dotyczące zasad wewnętrznych i ładu.
• Dopasowanie do fuzji i przejęć firmy
• Spełnianie wymagań dotyczących planowania pojemności.

Zasoby usługi App Service są specyficzne dla regionu i nie można ich przenosić między regionami. Musisz utworzyć kopię istniejących zasobów usługi App Service w regionie docelowym, a następnie przenieść zawartość do nowej aplikacji. Jeśli aplikacja źródłowa używa domeny niestandardowej, możesz przeprowadzić migrację jej do nowej aplikacji w regionie docelowym po zakończeniu relokacji.

Aby ułatwić kopiowanie aplikacji, możesz utworzyć kopię zapasową i przywrócić pojedynczą aplikację usługi App Service do planu usługi App Service w innym regionie.

Wymagania wstępne

• Upewnij się, że aplikacja usługi App Service znajduje się w regionie świadczenia usługi Azure, z którego chcesz się przenieść.
• Upewnij się, że region docelowy obsługuje usługę App Service i dowolną powiązaną usługę, której zasoby chcesz przenieść.
• Sprawdź, czy istnieją wystarczające uprawnienia do wdrażania zasobów usługi App Service w subskrypcji docelowej i regionie.
• Sprawdź, czy jakiekolwiek zasady platformy Azure są przypisane z ograniczeniem regionu.
• Rozważ wszelkie koszty operacyjne, ponieważ ceny zasobów obliczeniowych mogą się różnić w zależności od regionu do regionu. Aby oszacować możliwe koszty, zobacz Kalkulator cen.

Przygotowywanie

Zidentyfikuj wszystkie aktualnie używane zasoby usługi App Service. Na przykład:

• Aplikacje usługi App Service
• Plany usługi App Service
• Miejsca wdrożenia
• Domeny niestandardowe zakupione na platformie Azure
• Certyfikaty TLS/SSL
• Integracja z usługą Azure Virtual Network
• Połączenia hybrydowe.
• Tożsamości zarządzane
• Ustawienia kopii zapasowej

Niektóre zasoby, takie jak zaimportowane certyfikaty lub połączenia hybrydowe, zawierają integrację z innymi usługami platformy Azure. Aby uzyskać informacje na temat przenoszenia tych zasobów między regionami, zobacz dokumentację odpowiednich usług.

Planowanie

Ta sekcja jest listą kontrolną planowania w następujących obszarach:

• Zależności stanu, magazynu i podrzędnego
• Certyfikaty
• Konfigurowanie
• Łączność z siecią wirtualną / nazwy niestandardowe / DNS
• Tożsamości
• Punkty końcowe usługi

Zależności stanu, magazynu i podrzędnego

• Ustal, czy aplikacja usługi App Service jest stanowa, czy bezstanowa. Mimo że zalecamy, aby aplikacje usługi App Service były bezstanowe, a pliki na %HOME%\site dysku powinny być tylko tymi, które są wymagane do uruchomienia wdrożonej aplikacji z dowolnymi plikami tymczasowymi, nadal można przechowywać stan aplikacji środowiska uruchomieniowego na %HOME%\site dysku wirtualnym. Jeśli aplikacja zapisuje stan na udostępnionej ścieżce magazynu aplikacji, pamiętaj, aby zaplanować sposób zarządzania tym stanem podczas przenoszenia zasobu.

  Napiwek

  Możesz użyć narzędzia Kudu, aby wraz z dostępem do portalu udostępnić interfejs API dostępu do plików (wirtualny system plików (VFS)), który może odczytywać/zapisywać pliki w %HOME%\site katalogu. Aby uzyskać więcej informacji, zobacz Kudu Wiki.

• Sprawdź wewnętrzne buforowanie i stan w kodzie aplikacji.

• Wyłącz ustawienie koligacji sesji. Jeśli to możliwe, zalecamy wyłączenie ustawienia koligacji sesji. Wyłączenie koligacji sesji poprawia równoważenie obciążenia dla poziomego skalowania w poziomie. Każdy stan wewnętrzny może mieć wpływ na planowanie cięcia obciążenia — szczególnie jeśli wymagany jest zerowy czas pracy. Jeśli to możliwe, korzystne może być refaktoryzację dowolnego stanu aplikacji, aby aplikacja była bezstanowa w ramach przygotowań do przeniesienia.

• Analizowanie parametry połączenia bazy danych. Parametry połączenia bazy danych można znaleźć w obszarze Ustawienia aplikacji. Mogą być one jednak również zakodowane w kodzie twardym lub zarządzane w plikach konfiguracji dostarczanych z aplikacją. Analizowanie i planowanie migracji/replikacji danych w ramach planowania wyższego poziomu w celu przeniesienia obciążenia. W przypadku aplikacji krytycznych o czacie lub opóźnieniach aplikacja w regionie docelowym nie jest wydajna, aby wrócić do źródeł danych w regionie źródłowym.

• Analizowanie zewnętrznego buforowania (na przykład Redis). Pamięci podręczne aplikacji powinny być wdrażane jak najbliżej aplikacji. Przeanalizuj sposób wypełniania pamięci podręcznej, zasad wygasania/eksmisji i wpływu na zimną pamięć podręczną mogą mieć na pierwszych użytkowników dostęp do obciążenia po przecięciu.

• Analizowanie i planowanie zależności interfejsu API (lub aplikacji) między regionami jest znacznie mniej wydajne, jeśli aplikacja w regionie docelowym wraca do zależności, które nadal znajdują się w regionie źródłowym. Zalecamy przeniesienie wszystkich zależności podrzędnych w ramach relokacji obciążenia. Jednak *zasoby lokalne* są wyjątkiem, w szczególności tych zasobów, które są geograficznie bliżej regionu docelowego (tak jak w przypadku scenariuszy repatriacji).

  Usługa Azure Container Registry może być zależnością podrzędną (środowiska uruchomieniowego) dla usługi App Service skonfigurowanej do uruchamiania względem niestandardowych obrazów kontenerów. Bardziej sensowne jest, aby usługa Container Registry znajdowała się w tym samym regionie co sama aplikacja. Rozważ przekazanie wymaganych obrazów do nowego rekordu ACR w docelowym regionie pobierania. W przeciwnym razie rozważ użycie funkcji replikacji geograficznej, jeśli planujesz przechowywanie obrazów w regionie źródłowym.

• Analizowanie i planowanie usług regionalnych. Dane usługi Application Insights i Log Analytics to usługi regionalne. Rozważ utworzenie nowego magazynu usługi Application Insights i usługi Log Analytics w regionie docelowym. W przypadku usługi App Insights nowy zasób ma również wpływ na parametry połączenia, które należy zaktualizować w ramach zmiany w usłudze App Configuration.

Certyfikaty

Istnieje wiele różnych typów certyfikatów, które należy wziąć pod uwagę podczas planowania relokacji usługi App Service:

• Bezpłatny zarządzany certyfikat z usługi App Service nie można eksportować.
• Certyfikat usługi App Service za pośrednictwem usługi Azure Key Vault można wyeksportować przy użyciu programu PS1/interfejsu wiersza polecenia.
• Certyfikat zarządzany poza usługą App Service.
• Certyfikat usługi App Service, który nie jest zarządzany za pośrednictwem usługi Azure Key Vault, można wyeksportować.
• Zasoby certyfikatów usługi App Service można przenieść do nowej grupy zasobów lub subskrypcji, ale nie między regionami. Relokacje między regionami nie są obsługiwane przez certyfikaty usługi App Service.
• Certyfikaty zarządzane, którymi zarządzasz i przechowujesz w usłudze Azure Key Vault, najpierw muszą zostać wyeksportowane ze źródłowej usługi Key Vault i ponownie zaimportowane do docelowej usługi Key Vault skojarzonej z aplikacją docelową.

Kilka dalszych kwestii, które należy wziąć pod uwagę:

• Adresy przypisane do aplikacji, w których połączenie SSL aplikacji usługi App Service jest powiązane z określonym wyznaczonym adresem IP aplikacji, może służyć do wywołań dozwolonych z sieci innych firm do usługi App Service. Na przykład administrator sieci/IT może chcieć zablokować połączenia wychodzące z sieci lokalnej lub sieci wirtualnej, aby używać statycznego, dobrze znanego adresu. W związku z tym, jeśli funkcja Adres przypisany do aplikacji jest używana, nadrzędne reguły zapory — takie jak wewnętrzne, zewnętrzne lub zewnętrzne — dla osób wywołujących w aplikacji powinny być sprawdzane i informowane o nowym adresie. Reguły zapory mogą być wewnętrznymi, zewnętrznymi lub zewnętrznymi firmami, takimi jak partnerzy lub dobrze znani klienci.

• Rozważ wszelkie nadrzędne wirtualne urządzenie sieciowe (WUS) lub zwrotny serwer proxy. Konfiguracja urządzenia WUS może wymagać zmiany, jeśli zapisujesz nagłówek hosta lub/lub kończysz protokół SSL.

Konfigurowanie

• Przejrzyj sekcję Konfiguracja aplikacji dla ustawień specyficznych dla środowiska i regionu, które mogą wymagać modyfikacji. Upewnij się, że opcja zawiera konfigurację pliku dysku, która może lub nie jest zastępowana przy użyciu ustawień aplikacji.

• Należy wziąć pod uwagę, że konfiguracja może być również zarządzana z zależności centralnej (podrzędnej) bazy danych lub usługi, takiej jak aplikacja systemu Azure Configuration.

• Utwórz ponownie odwołania do usługi App Service Key Vault. Odwołania do usługi Key Vault są powiązane z unikatową tożsamością usługi zarządzanej przypisaną do zasobu (która ma dostęp do płaszczyzny danych KV), a sama usługa Key Vault najprawdopodobniej musi znajdować się w tym samym regionie źródłowym. Nie można wyeksportować zawartości usługi Az Key Vault na granicę geograficzną platformy Azure.

Łączność z siecią wirtualną / nazwy niestandardowe / DNS

• App Service Environment to pojedyncza usługa dzierżawy z obsługą sieci wirtualnej. Sieć środowiska App Service Environment różni się od wielodostępnej usługi App Service, która wymaga jednej lub obu "prywatnych punktów końcowych" lub "regionalnej integracji z siecią wirtualną". Inne opcje, które mogą być w grze, obejmują starszą integrację sieci VPN typu punkt-lokacja i połączenia hybrydowe (usługa Azure Relay).

  Uwaga

  Sieć ASEv3 jest uproszczona — ruch usługi Azure Management i własne zależności podrzędne środowiska App Service Environment nie są widoczne dla sieci wirtualnej klienta, co znacznie upraszcza konfigurację wymaganą, gdy klient korzysta z tunelu wymuszonego dla całego ruchu lub wysyłania podzbioru ruchu wychodzącego za pośrednictwem wirtualnego urządzenia sieciowego/zapory.

  Połączenia hybrydowe (Azure Relay) są regionalne. Jeśli są używane połączenia hybrydowe i chociaż przestrzeń nazw usługi Azure Relay może zostać przeniesiona do innego regionu, łatwiej byłoby ponownie wdrożyć połączenie hybrydowe (upewnij się, że połączenie hybrydowe jest skonfigurowane w nowym regionie w ramach wdrażania zasobów docelowych) i ponownie połącz je z Menedżer połączeń hybrydowych. Należy dokładnie rozważyć lokalizację Menedżer połączeń hybrydowych.

• Postępuj zgodnie ze strategią dla ciepłego regionu rezerwowego. Upewnij się, że podstawowa sieć i łączność, sieć koncentratora, kontrolery domeny, dns, sieć VPN lub usługa Express Route itp., są obecne i testowane przed przeniesieniem zasobów.

• Zweryfikuj wszystkie listy ACL i konfigurację sieci nadrzędnej lub podrzędnej. Rozważmy na przykład zewnętrzną usługę podrzędną, która zezwala tylko na ruch aplikacji. Przeniesienie do nowego planu aplikacji dla wielodostępnej usługi App Service spowoduje również zmianę wychodzących adresów IP.

• W większości przypadków najlepiej upewnić się, że sieci wirtualne regionu docelowego mają unikatową przestrzeń adresową. Unikatowa przestrzeń adresowa ułatwia łączność z siecią wirtualną, jeśli jest wymagana, na przykład do replikowania danych. W związku z tym w tych scenariuszach istnieje niejawne wymaganie zmiany:

  • Prywatna strefa DNS
  • Każda zakodowana lub zewnętrzna konfiguracja, która odwołuje się do zasobów według adresu IP (bez nazwy hosta)
  • Listy ACL sieci, w tym sieciowe grupy zabezpieczeń i konfiguracja zapory (należy również rozważyć wpływ na wszystkie lokalne urządzenia WUS)
  • Wszystkie reguły routingu, tabele tras zdefiniowane przez użytkownika

  Ponadto upewnij się, że konfiguracja obejmuje zakresy adresów IP lub tagi usługi specyficzne dla regionu, jeśli przeprowadzasz istniejące zasoby wdrożenia metodyki DevOps.

• W przypadku prywatnej usługi DNS wdrożonej przez klienta jest wymagana mniejsza liczba zmian skonfigurowanych do przekazywania dalej na platformę Azure dla domen platformy Azure i stref prywatnych usługi Azure DNS. Jednak ponieważ prywatne punkty końcowe są oparte na nazwie FQDN zasobu i często jest to również nazwa zasobu (która może być inna w regionie docelowym), pamiętaj, aby sprawdzić krzyżowo konfigurację, aby upewnić się, że nazwy FQDN, do których odwołuje się konfiguracja, są odpowiednio aktualizowane.

• Utwórz ponownie prywatne punkty końcowe, jeśli są używane, w regionie docelowym. Dotyczy to również integracji regionalnej sieci wirtualnej.

• Usługa DNS dla środowiska App Service Environment jest zwykle zarządzana za pośrednictwem prywatnego niestandardowego rozwiązania DNS klientów (w przypadku poszczególnych aplikacji w warstwie Podstawowa dostępne są ustawienia ręczne). Środowisko App Service Environment zapewnia moduł równoważenia obciążenia dla ruchu przychodzącego/wychodzącego, a sama usługa App Service filtruje nagłówki hosta. W związku z tym wiele nazw niestandardowych można wskazać na ten sam punkt końcowy ruchu przychodzącego środowiska App Service Environment. Środowisko App Service Environment nie wymaga weryfikacji domeny.

  Uwaga

  Punkt końcowy Kudu dla środowiska App Service Environment w wersji 3 jest dostępny tylko pod adresem {resourcename}.scm.{asename}.appserviceenvironment.net. Aby uzyskać więcej informacji na temat środowiska App Service Environment w wersji 3 dns i sieci itp., zobacz Sieć środowiska App Service Environment.

  W przypadku środowiska App Service Environment klient jest właścicielem routingu i w związku z tym zasobami używanymi do przecięcia. Wszędzie tam, gdzie jest włączony dostęp do środowiska App Service Environment zewnętrznie — zazwyczaj za pośrednictwem wirtualnego urządzenia sieciowego warstwy 7 lub zwrotnego serwera proxy — traffic manager lub usługi Azure Front Door/Other L7 Global Load Balancing Service można używać.

• W przypadku publicznej wielodostępnej wersji usługi domyślna nazwa {resourcename}.azurwwebsites.net jest aprowizowana dla punktów końcowych płaszczyzny danych wraz z domyślną nazwą punktu końcowego Kudu (SCM). Ponieważ usługa domyślnie udostępnia publiczny punkt końcowy, powiązanie musi zostać zweryfikowane, aby udowodnić własność domeny. Jednak po utworzeniu powiązania ponowna weryfikacja nie jest wymagana ani nie jest wymagana, aby publiczne rekordy DNS wskazywały punkt końcowy usługi App Service.

• Jeśli używasz domeny niestandardowej, powiąż ją z preemptively z aplikacją docelową. Zweryfikuj i włącz domenę w aplikacji docelowej.

Tożsamości

• Utwórz ponownie tożsamości usługi zarządzanej usługi App Service w nowym regionie docelowym.

• Przypisz nowy dostęp do usługi podrzędnej poświadczeń tożsamości usługi zarządzanej (RBAC). Zazwyczaj automatycznie utworzona aplikacja Microsoft Entra ID App (używana przez usługę EasyAuth) domyślnie używa nazwy zasobu aplikacji. W tym miejscu może być wymagane ponowne utworzenie nowego zasobu w regionie docelowym. Jednostka usługi zdefiniowana przez użytkownika byłaby przydatna — ponieważ można ją zastosować zarówno do źródła, jak i obiektu docelowego z dodatkowymi uprawnieniami dostępu do docelowych zasobów wdrażania.

• Zaplanuj przeniesienie dostawcy tożsamości (IDP) do regionu docelowego. Mimo że microsoft Entra ID jest usługą globalną, niektóre rozwiązania korzystają z lokalnego (lub podrzędnego lokalnego) dostawcy tożsamości.

• Zaktualizuj wszystkie zasoby do usługi App Service, które mogą polegać na poświadczeniach protokołu FTP Kudu.

Punkty końcowe usługi

Punkty końcowe usługi sieci wirtualnej dla usługi aplikacja systemu Azure Service ograniczają dostęp do określonej sieci wirtualnej. Punkty końcowe mogą również ograniczyć dostęp do listy zakresów adresów IPv4 (protokół internetowy w wersji 4). Każdy użytkownik nawiązujący połączenie z usługą Event Hubs spoza tych źródeł nie ma dostępu. Jeśli punkty końcowe usługi zostały skonfigurowane w regionie źródłowym dla zasobu usługi Event Hubs, należy to zrobić w tym samym miejscu docelowym.

Aby pomyślnie odtworzyć usługę aplikacja systemu Azure w regionie docelowym, należy wcześniej utworzyć sieć wirtualną i podsieć. W przypadku przenoszenia tych dwóch zasobów za pomocą narzędzia Azure Resource Mover punkty końcowe usługi nie będą konfigurowane automatycznie. W związku z tym należy je skonfigurować ręcznie, co można zrobić za pośrednictwem witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell.

Przenieść

Aby przenieść zasoby usługi App Service, możesz użyć witryny Azure Portal lub infrastruktury jako kodu (IaC).

Przenoszenie przy użyciu witryny Azure Portal

Największą zaletą korzystania z witryny Azure Portal do przeniesienia jest jej prostota. Aplikacja, plan i zawartość, a także wiele ustawień są klonowane do nowego zasobu i planu usługi App Service.

Należy pamiętać, że w przypadku warstw Środowiska App Service Environment (izolowanego) należy najpierw ponownie wdrożyć całe środowisko App Service Environment w innym regionie, a następnie rozpocząć ponowne wdrażanie poszczególnych planów w nowym środowisku App Service Environment w nowym regionie.

Aby przenieść zasoby usługi App Service do nowego regionu przy użyciu witryny Azure Portal:

1. Utwórz kopię zapasową aplikacji źródłowej.
2. Utwórz aplikację w nowym planie usługi App Service w regionie docelowym.
3. Przywracanie kopii zapasowej w aplikacji docelowej
4. Jeśli używasz domeny niestandardowej, powiąż ją z preemptively z aplikacją docelową za pomocą asuid. polecenia i włącz domenę w aplikacji docelowej.
5. Skonfiguruj wszystkie inne elementy w aplikacji docelowej tak samo jak aplikacja źródłowa i zweryfikuj konfigurację.
6. Gdy wszystko będzie gotowe, aby domena niestandardowa wskazywała aplikację docelową, zamapuj ponownie nazwę domeny.

Przenoszenie przy użyciu IaC

Użyj funkcji IaC, gdy istnieje istniejący potok ciągłej integracji i ciągłego wdrażania(CI/CD) lub można go utworzyć. Po wdrożeniu potoku ciągłej integracji/ciągłego wdrażania zasób usługi App Service można utworzyć w regionie docelowym za pomocą akcji wdrożenia lub wdrożenia zip Kudu.

Wymagania dotyczące umowy SLA powinny określać, ile dodatkowego nakładu pracy jest wymagany. Na przykład: czy jest to ponowne wdrożenie z ograniczonym przestojem, czy jest to ograniczenie czasu niemal rzeczywistego wymagane z minimalnym przestojem?

Włączenie zewnętrznych, globalnych usług brzegowych routingu ruchu, takich jak Traffic Manager lub Azure Front Door, pomaga ułatwić przecięcia dla użytkowników zewnętrznych i aplikacji.

Sprawdź poprawność

Po zakończeniu relokacji przetestuj i zweryfikuj usługę aplikacja systemu Azure z zalecanymi wytycznymi:

• Po przeniesieniu usługi aplikacja systemu Azure do regionu docelowego uruchom test weryfikacyjny kompilacji i integracji. Możesz ręcznie przetestować lub uruchomić test za pomocą skryptu. Upewnij się, że wszystkie konfiguracje i zasoby zależne są prawidłowo połączone i czy wszystkie skonfigurowane dane są dostępne.

• Zweryfikuj wszystkie składniki usługi aplikacja systemu Azure i integrację.

• Przeprowadź testy integracji we wdrożeniu regionu docelowego, w tym wszystkie formalne testy regresji. Testowanie integracji powinno być zgodne ze zwykłym rytmem wdrażania biznesowego i procesami testowania mającym zastosowanie do obciążenia.

• W niektórych scenariuszach, szczególnie w przypadku, gdy relokacja obejmuje aktualizacje, zmiany aplikacji lub zasobów platformy Azure lub zmianę profilu użycia, użyj testowania obciążenia, aby sprawdzić, czy nowe obciążenie jest odpowiednie do celu. Testowanie obciążenia jest również okazją do weryfikowania operacji i monitorowania pokrycia. Na przykład użyj testowania obciążenia, aby sprawdzić, czy wymagane dzienniki infrastruktury i aplikacji są generowane poprawnie. Testy obciążeniowe powinny być mierzone względem ustalonych punktów odniesienia wydajności obciążenia.

Czyszczenie

Usuń aplikację źródłową i plan usługi App Service. Plan usługi App Service w warstwie innej niż bezpłatna niesie ze sobą opłatę, nawet jeśli żadna aplikacja nie jest w niej uruchomiona.

Następne kroki

klonowanie aplikacji usługi aplikacja systemu Azure Service przy użyciu programu PowerShell