Udostępnij za pośrednictwem

Migrowanie wystąpienia usługi API Management ze wstrzykniętą siecią wirtualną hostowanego na platformie stv1 do wersji stv2

  • Artykuł

DOTYCZY: Developer | Premium

Ten artykuł zawiera kroki migracji wystąpienia usługi API Management hostowanego na stv1 platformie obliczeniowej w miejscu na stv2 platformie, gdy wystąpienie jest wstrzykiwane (wdrożone) w zewnętrznej lub wewnętrznej sieci wirtualnej. W tym scenariuszu przeprowadź migrację wystąpienia, aktualizując ustawienia konfiguracji sieci wirtualnej. Dowiedz się, czy musisz to zrobić.

Jeśli musisz przeprowadzić migrację innej niż sieć wirtualna usługi API Management hostowanej na stv1 platformie, zobacz Migrowanie wystąpienia usługi API Management innej niż sieć wirtualna do platformy stv2.

Ważne

Obsługa wystąpień usługi API Management hostowanych na stv1 platformie zostanie wycofana do 31 sierpnia 2024 r. Jeśli masz wystąpienia hostowane na stv1 platformie, przeprowadź migrację ich do stv2 platformy przed tą datą, aby uniknąć zakłóceń w działaniu usługi. Dowiedz się więcej.

Uwaga

  • Migrowanie wystąpienia usługi API Management do stv2 platformy jest długotrwałą operacją.
  • Adres VIP wystąpienia ulegnie zmianie. Po migracji należy zaktualizować wszystkie zależności sieciowe, w tym dns, reguły zapory i sieci wirtualne, aby używać nowego adresu VIP. Zaplanuj migrację odpowiednio.
  • Migracja do stv2 programu nie jest odwracalna.

Co się dzieje podczas migracji?

Migracja platformy API Management z stv1 platformy do stv2 obejmuje aktualizowanie samego bazowego środowiska obliczeniowego i nie ma wpływu na konfigurację usługi/interfejsu API utrwalonej w warstwie magazynu.

  • Proces uaktualniania obejmuje utworzenie nowego środowiska obliczeniowego równolegle ze starymi obliczeniami, co może potrwać do 45 minut.
  • Stan usługi API Management w witrynie Azure Portal to Aktualizowanie.
  • Adres VIP (lub adresy dla wdrożenia w wielu regionach) wystąpienia ulegnie zmianie.
  • Platforma Azure zarządza systemem DNS punktu końcowego zarządzania i aktualizuje nowe zasoby obliczeniowe natychmiast po pomyślnej migracji.
  • System DNS bramy nadal wskazuje stare obliczenia, jeśli domena niestandardowa jest używana.
  • Jeśli niestandardowy system DNS nie jest używany, brama i portal DNS natychmiast wskazują nowe środowisko obliczeniowe.
  • W przypadku wystąpienia w wewnętrznym trybie sieci wirtualnej klient zarządza systemem DNS, więc wpisy DNS nadal wskazują stare obliczenia do momentu zaktualizowania przez klienta.
  • Jest to system DNS, który wskazuje na nowe lub stare obliczenia, a tym samym bez przestoju w interfejsach API.
  • Zmiany są wymagane do reguł zapory, jeśli istnieją, aby umożliwić nowej podsieci obliczeniowej dotarcie do zapleczy.
  • Po pomyślnej migracji stare zasoby obliczeniowe zostaną automatycznie zlikwidowane po około 15 minutach, z opcją opóźnienia przez maksymalnie 48 godzin. Opcja opóźnienia 48 godzin jest dostępna tylko dla usług wstrzykowanych przez sieć wirtualną.

Wymagania wstępne

  • Wystąpienie usługi API Management hostowane na platformie obliczeniowej stv1 . Aby potwierdzić, że twoje wystąpienie jest hostowane na stv1 platformie, zobacz Jak mogę wiedzieć, która platforma hostuje moje wystąpienie usługi API Management? Wystąpienie musi być wstrzykiwane w sieci wirtualnej.

  • Nowa podsieć w bieżącej sieci wirtualnej w każdym regionie, w którym wdrożono wystąpienie usługi API Management. (Alternatywnie skonfiguruj podsieć w innej sieci wirtualnej w tych samych regionach i subskrypcji co wystąpienie usługi API Management). Sieciowa grupa zabezpieczeń musi być dołączona do podsieci, a reguły sieciowej grupy zabezpieczeń dla usługi API Management muszą być skonfigurowane.

  • (Opcjonalnie) Nowy zasób publicznego adresu IPv4 jednostki SKU w warstwie Standardowa w tych samych regionach i subskrypcji co wystąpienie usługi API Management. Aby uzyskać szczegółowe informacje, zobacz Wymagania wstępne dotyczące połączeń sieciowych.

    Ważne

    • Od maja 2024 r. publiczny adres IP nie jest już potrzebny podczas wdrażania (wstrzykiwania) wystąpienia usługi API Management w sieci wirtualnej w trybie wewnętrznym lub migracji wewnętrznej konfiguracji sieci wirtualnej do nowej podsieci. W trybie zewnętrznej sieci wirtualnej określenie publicznego adresu IP jest opcjonalne. Jeśli go nie podasz, publiczny adres IP zarządzany przez platformę Azure zostanie automatycznie skonfigurowany. W trybie zewnętrznej sieci wirtualnej publiczny adres IP jest używany na potrzeby ruchu interfejsu API środowiska uruchomieniowego.
    • Obecnie, jeśli włączysz nadmiarowość strefy dla wystąpienia usługi API Management w sieci wirtualnej w trybie wewnętrznym lub zewnętrznym, musisz określić nowy publiczny adres IP.

  • (Opcjonalnie) Skontaktuj się z pomoc techniczna platformy Azure, aby poprosić o równoległą obsługę oryginalnej infrastruktury usług przez maksymalnie 48 godzin po pomyślnej migracji. Ta opcja wydłuża okres, w przypadku gdy stara infrastruktura jest dostępna po migracji przekraczającej wartość domyślną 15 minut przed jego przeczyszczeniem. Ta opcja jest dostępna tylko dla usług wstrzykniętych przez sieć wirtualną, aby umożliwić właścicielom usług aktualizowanie ustawień sieciowych i testowanie aplikacji w celu korzystania z nowej infrastruktury. To żądanie rozszerzenia dotyczy wszystkich wystąpień usługi API Management w ramach subskrypcji.

    Uwaga

    Jeśli planujesz migrację wystąpienia usługi API Management ze wstrzykniętą siecią wirtualną z powrotem do oryginalnej podsieci po migracji, zalecamy, aby nie żądać rozszerzenia 48-godzinnego.

Wyzwalanie migracji wystąpienia usługi API Management ze wstrzykniętą siecią

Wyzwól migrację wystąpienia usługi API Management z wstrzykniętą siecią do stv2 platformy, aktualizując istniejącą konfigurację sieci w celu używania nowych ustawień sieciowych w każdym regionie, w którym jest wdrażane wystąpienie. Po zakończeniu tej aktualizacji w ramach opcjonalnego kroku można przeprowadzić migrację z powrotem do oryginalnych używanych sieci wirtualnych i podsieci.

Możesz również przeprowadzić migrację na platformę stv2 , włączając nadmiarowość strefy dostępną w warstwie Premium .

Ważne

Adresy VIP wystąpienia usługi API Management zmienią się. Jednak żądania interfejsu API pozostają dynamiczne podczas migracji. Konfiguracja infrastruktury (na przykład domeny niestandardowe, lokalizacje i certyfikaty urzędu certyfikacji) zostanie zablokowana przez 30 minut. Po migracji należy zaktualizować wszystkie zależności sieciowe, w tym dns, reguły zapory i równorzędne sieci wirtualne, aby używać nowych adresów VIP.

Aktualizowanie konfiguracji sieci

Możesz użyć witryny Azure Portal lub innych narzędzi platformy Azure, takich jak migracja do nowej podsieci w tej samej lub innej sieci wirtualnej. Na poniższej ilustracji przedstawiono ogólny przegląd tego, co dzieje się podczas migracji do nowej podsieci.

Diagram migracji w miejscu do nowej podsieci.

Aby na przykład użyć portalu:

  1. W portalu przejdź do wystąpienia usługi API Management.
  2. W menu po lewej stronie wybierz pozycję Sieć wirtualna>.
  3. Wybierz połączenie sieciowe w lokalizacji, w której chcesz zaktualizować.
  4. Wybierz sieć wirtualną i podsieć, którą chcesz skonfigurować. Opcjonalnie wybierz nowy publiczny adres IP. Wybierz Zastosuj.
  5. Kontynuuj konfigurowanie ustawień sieci wirtualnej dla pozostałych lokalizacji wystąpienia usługi API Management.
  6. Na górnym pasku nawigacyjnym wybierz pozycję Zapisz.

Po zaktualizowaniu konfiguracji sieci wirtualnej stan wystąpienia usługi API Management zmieni się na Aktualizowanie. Proces migracji trwa około 45 minut. Gdy stan zmieni się na Online, migracja zostanie ukończona.

(Opcjonalnie) Migrowanie z powrotem do oryginalnej podsieci

Opcjonalnie możesz przeprowadzić migrację z powrotem do oryginalnej podsieci używanej w każdym regionie przed migracją na platformę stv2 . W tym celu zaktualizuj ponownie konfigurację sieci wirtualnej, tym razem określając oryginalną sieć wirtualną i podsieć w każdym regionie. Podobnie jak w przypadku poprzedniej migracji, należy oczekiwać długotrwałej operacji i oczekiwać zmiany adresu VIP.

Na poniższej ilustracji przedstawiono ogólny przegląd tego, co się dzieje podczas migracji z powrotem do oryginalnej podsieci.

Diagram migracji w miejscu z powrotem do oryginalnej podsieci.

Ważne

Jeśli sieć wirtualna i podsieć są zablokowane (ponieważ są tam wdrożone inne stv1 wystąpienia usługi API Management oparte na platformie) lub grupa zasobów, w której wdrożono oryginalną sieć wirtualną, ma blokadę zasobu, pamiętaj o usunięciu blokady przed migracją z powrotem do oryginalnej podsieci. Przed podjęciem próby migracji do oryginalnej podsieci poczekaj na zakończenie usuwania blokady. Dowiedz się więcej.

Uwaga

Jeśli planujesz migrację z powrotem do oryginalnej podsieci, zalecamy, aby nie zażądać rozszerzenia 48-godzinnego dla subskrypcji w celu utrzymania starej infrastruktury; w przeciwnym razie migracja zostanie opóźniona. Jeśli musisz anulować rozszerzenie, skontaktuj się z pomoc techniczna platformy Azure.

Dodatkowe wymagania wstępne

  • Odblokowana oryginalna podsieć w każdym regionie, w którym wdrożono wystąpienie usługi API Management. Sieciowa grupa zabezpieczeń musi być dołączona do podsieci, a reguły sieciowej grupy zabezpieczeń dla usługi API Management muszą być skonfigurowane.

  • (Opcjonalnie) Nowy zasób publicznego adresu IPv4 jednostki SKU w warstwie Standardowa w tych samych regionach i subskrypcji co wystąpienie usługi API Management.

    Ważne

    • Od maja 2024 r. publiczny adres IP nie jest już potrzebny podczas wdrażania (wstrzykiwania) wystąpienia usługi API Management w sieci wirtualnej w trybie wewnętrznym lub migracji wewnętrznej konfiguracji sieci wirtualnej do nowej podsieci. W trybie zewnętrznej sieci wirtualnej określenie publicznego adresu IP jest opcjonalne. Jeśli go nie podasz, publiczny adres IP zarządzany przez platformę Azure zostanie automatycznie skonfigurowany. W trybie zewnętrznej sieci wirtualnej publiczny adres IP jest używany na potrzeby ruchu interfejsu API środowiska uruchomieniowego.
    • Obecnie, jeśli włączysz nadmiarowość strefy dla wystąpienia usługi API Management w sieci wirtualnej w trybie wewnętrznym lub zewnętrznym, musisz określić nowy publiczny adres IP.

Aktualizowanie konfiguracji sieci wirtualnej

  1. W portalu przejdź do oryginalnej sieci wirtualnej.
  2. W menu po lewej stronie wybierz pozycję Podsieci, a następnie oryginalną podsieć.
  3. Sprawdź, czy oryginalne adresy IP zostały wydane przez usługę API Management. W obszarze Dostępne adresy IP zanotuj liczbę adresów IP dostępnych w podsieci. Wszystkie adresy (z wyjątkiem adresów zarezerwowanych platformy Azure) powinny być dostępne. W razie potrzeby poczekaj na wydanie adresów IP.
  4. Powtórz kroki migracji w poprzedniej sekcji. W każdym regionie określ oryginalną sieć wirtualną i podsieć. Opcjonalnie wybierz nowy publiczny adres IP.
  5. Na górnym pasku nawigacyjnym wybierz pozycję Zapisz.

Po zaktualizowaniu konfiguracji sieci wirtualnej stan wystąpienia usługi API Management zmieni się na Aktualizowanie. Proces migracji trwa około 45 minut. Gdy stan zmieni się na Online, migracja zostanie ukończona.

Weryfikowanie migracji

Aby sprawdzić, czy migracja zakończyła się pomyślnie, gdy stan zmieni się na Online, sprawdź wersję platformy wystąpienia usługi API Management. Po pomyślnej migracji wartość to stv2 lub stv2.1.

Potwierdzanie ustawień przed przeczyszczeniem starej bramy

Po pomyślnej migracji wystąpienia usługi API Management ze wstrzykniętą siecią wirtualną stare i nowe zasoby obliczeniowe utworzone podczas migracji współistnieją przez krótki czas, czyli około 15 minut, co jest małym przedziałem czasu, którego można użyć do zweryfikowania wdrożenia i działania aplikacji zgodnie z oczekiwaniami. (To okno można przedłużyć do 48 godzin, kontaktując się z pomoc techniczna platformy Azure z wyprzedzeniem).

  • W tym oknie stare i nowe bramy są zarówno w trybie online, jak i obsługują ruch. Opłaty nie są naliczane w tym czasie.
  • Użyj tego okna, aby zaktualizować wszystkie zależności sieciowe, w tym dns, reguły zapory i sieci wirtualne, aby używać nowego adresu VIP i przestrzeni adresowej podsieci.
  • Ponadto sprawdź stan sieci zaktualizowanego wystąpienia, aby zapewnić łączność wystąpienia z jego zależnościami. W portalu w menu po lewej stronie w obszarze Wdrażanie i infrastruktura wybierz pozycję Stan sieci sieciowej>. W razie potrzeby zaktualizuj ustawienia, takie jak trasy zdefiniowane przez użytkownika i reguły sieciowej grupy zabezpieczeń.
  • Po upływie okna stara brama zostanie zlikwidowana, a nowa brama jest jedyną bramą obsługującą ruch.

Przywróć automatycznie, jeśli migracja nie powiedzie się

Jeśli podczas procesu migracji wystąpi błąd, wystąpienie zostanie automatycznie przywrócone do stv1 platformy. Jeśli migracja zakończy się pomyślnie (wersja platformy wystąpienia jest wyświetlana jako stv2 lub stv2.1 i stan w trybie Online), nie można wycofać się z stv1 platformy.

Aby uzyskać pomoc w przypadku niepowodzenia migracji, skontaktuj się z pomoc techniczna platformy Azure.

Jeśli potrzebujesz możliwości ręcznego wycofania, zaleca się wdrożenie nowego wystąpienia obok oryginalnego stv2 wystąpienia usługi API Management.

Pomoc i obsługa techniczna 

Jesteśmy tutaj, aby pomóc Ci przeprowadzić migrację na platformę stv2 z minimalnymi zakłóceniami w Twoich usługach.

Jeśli masz pytania, uzyskaj szybkie odpowiedzi od ekspertów społeczności w usłudze Microsoft Q&A. Jeśli masz plan pomocy technicznej i potrzebujesz takiej pomocy, utwórz wniosek o pomoc techniczną.

  1. W obszarze Podsumowanie wpisz opis problemu, na przykład "stv1 retirement".
  2. W obszarze Typ problemu wybierz pozycję Techniczne.
  3. W obszarze Subskrypcja wybierz swoją subskrypcję.
  4. W obszarze Usługa wybierz pozycję Moje usługi, a następnie wybierz pozycję Usługa API Management.
  5. W obszarze Zasób wybierz zasób platformy Azure, dla którego tworzysz wniosek o pomoc techniczną.
  6. W polu Typ problemu wybierz pozycję Administracja istration i Management.
  7. W obszarze Podtyp problemu wybierz pozycję Uaktualnij, Skaluj lub Zmiany jednostki SKU.

Często zadawane pytania

  • Jakie informacje musimy wybrać ścieżkę migracji?

    • Jaki jest tryb sieciowy wystąpienia usługi API Management?
    • Czy domeny niestandardowe są skonfigurowane?
    • Czy jest zaangażowana zapora?
    • Jakiekolwiek znane zależności podjęte przez nadrzędny/podrzędny dla zaangażowanych adresów IP?
    • Czy jest to wdrożenie w wielu regionach?
    • Czy można zmodyfikować istniejące wystąpienie lub czy wymagana jest konfiguracja równoległa?
    • Czy może wystąpić przestój?
    • Czy migracja może odbywać się w godzinach nonbusiness?

  • Jakie są wymagania wstępne dotyczące migracji?

    W przypadku wystąpień z wstrzykniętą siecią wirtualną potrzebna jest nowa podsieć do migracji w każdej sieci wirtualnej (tryb zewnętrzny lub wewnętrzny). W trybie zewnętrznym opcjonalnie podaj zasób publicznego adresu IP. Podsieć musi mieć dołączoną sieciową grupę zabezpieczeń zgodnie z regułami dotyczącymi stv2 platformy zgodnie z opisem w tym miejscu.

  • Czy migracja spowoduje przestój?

    Ponieważ stara brama jest czyszczone dopiero po tym, jak nowe zasoby obliczeniowe są w dobrej kondycji i w trybie online, nie powinno być żadnych przestojów, jeśli są używane domyślne nazwy hostów. Ważne jest, aby wszystkie zależności sieci zostały zadbane z góry o działanie interfejsów API, których to dotyczy. Jeśli jednak domeny niestandardowe są używane, będą wskazywać przeczyszczane zasoby obliczeniowe do momentu ich zaktualizowania, co może spowodować przestój. Alternatywnie możesz poprosić o zachowanie starej bramy przez maksymalnie 48 godzin, tworząc bilet pomoc techniczna platformy Azure z wyprzedzeniem. Posiadanie starego i nowego współistnienia obliczeniowego ułatwi walidację, a następnie można zaktualizować niestandardowe wpisy DNS na stronie.

  • Ruch jest wymuszany przez zaporę. Jakie zmiany są wymagane?

    • Najpierw upewnij się, że nowe podsieci utworzone na potrzeby migracji zachowują następującą konfigurację (powinny one być już skonfigurowane w bieżącej podsieci):
      • Włączanie punktów końcowych usługi zgodnie z opisem w tym miejscu
      • Trasa zdefiniowana przez użytkownika (trasa zdefiniowana przez użytkownika) ma przeskok z tagu usługi ApiManagement ustawioną na "Internet", a nie tylko na adres zapory
    • Wymagania dotyczące konfiguracji sieciowej grupy zabezpieczeń dla stv2 pozostają takie same, niezależnie od tego, czy masz zaporę, czy nie; upewnij się, że nowa podsieć ma ją
    • Reguły zapory odwołujące się do bieżącego zakresu adresów IP wystąpienia usługi API Management powinny zostać zaktualizowane w celu użycia zakresu adresów IP nowej podsieci.

  • Czy dane lub straty konfiguracji mogą wystąpić przez/podczas migracji?

    stv1 migracja stv2 obejmuje aktualizowanie samej platformy obliczeniowej, a wewnętrzna warstwa magazynu nie jest zmieniana. W związku z tym cała konfiguracja jest bezpieczna podczas procesu migracji. Obejmuje to tożsamość zarządzaną przypisaną przez system, która w przypadku włączenia jest zachowywana.

  • Jak potwierdzić, że migracja została ukończona i zakończona pomyślnie?

    Migracja jest uważana za ukończoną i pomyślną, gdy stan na stronie przeglądu odczytuje wartość Online wraz z wersją platformy lub stv2stv2.1. Sprawdź również, czy stan sieci w bloku sieci jest wyświetlany na zielono dla wszystkich wymaganych połączeń.

  • Czy mogę przeprowadzić migrację przy użyciu portalu?

    Tak, wystąpienia wstrzyknięte przez sieć wirtualną można migrować, zmieniając konfiguracje podsieci w bloku Sieć .

  • Czy mogę zachować adres IP wystąpienia?

    Obecnie nie ma możliwości zachowania adresu IP, jeśli wystąpienie jest wstrzykiwane do sieci wirtualnej.

  • Czy istnieje ścieżka migracji bez modyfikowania istniejącego wystąpienia?

    Tak, potrzebna jest migracja równoległa. Oznacza to, że utworzysz nowe wystąpienie usługi API Management równolegle z bieżącym wystąpieniem i skopiujesz konfigurację do nowego wystąpienia.

  • Co się stanie, jeśli migracja zakończy się niepowodzeniem?

    Jeśli wystąpienie usługi API Management nie wyświetla wersji platformy jako stv2 lub stv2.1 stanu online po zainicjowaniu migracji, prawdopodobnie nie powiodło się. Usługa jest automatycznie przywracana do starego wystąpienia i nie są wprowadzane żadne zmiany.

  • Jakie funkcje nie są dostępne podczas migracji?

    Żądania interfejsu API pozostają dynamiczne podczas migracji. Konfiguracja infrastruktury (na przykład domeny niestandardowe, lokalizacje i certyfikaty urzędu certyfikacji) jest zablokowana przez 30 minut. Po migracji należy zaktualizować wszystkie zależności sieciowe, w tym dns, reguły zapory i sieci wirtualne, aby używać nowego adresu VIP.

  • Jak długo potrwa migracja?

    Oczekiwany czas trwania migracji do nowej konfiguracji sieci wirtualnej wynosi około 45 minut. Wskaźnikiem sprawdzania, czy migracja została już wykonana, jest sprawdzenie, czy stan wystąpienia jest z powrotem do trybu online , a nie do aktualizowania.

  • Czy istnieje sposób weryfikacji konfiguracji sieci wirtualnej przed podjęciem próby migracji?

    Możesz wdrożyć nowe wystąpienie usługi API Management przy użyciu nowego zasobu adresu IP sieci wirtualnej, podsieci i (opcjonalnie) używanego do rzeczywistej migracji. Przejdź do strony Stan sieci po zakończeniu wdrażania i sprawdź, czy każdy stan łączności punktu końcowego jest zielony. Jeśli tak, możesz usunąć to nowe wystąpienie usługi API Management i przejść do rzeczywistej migracji z oryginalną stv1usługą hostowaną.

  • Czy mogę wycofać migrację, jeśli jest to wymagane?

    Jeśli wystąpi błąd podczas procesu migracji, wystąpienie zostanie automatycznie wycofane z platformy stv1 . Jednak po pomyślnym przeprowadzeniu migracji usługi nie można wycofać jej z platformy stv1 .

    Po pomyślnym przeprowadzeniu migracji usługi z wstrzykniętą siecią wirtualną istnieje krótki przedział czasu, w którym stara brama będzie nadal obsługiwać ruch i można potwierdzić ustawienia sieci. Zobacz Potwierdzanie ustawień przed przeczyszczeniem starej bramy

  • Czy w domenie niestandardowej/prywatnych strefach DNS jest wymagana jakakolwiek zmiana?

    W przypadku wystąpień w sieci wirtualnej w trybie wewnętrznym należy zaktualizować prywatne strefy DNS do nowego adresu IP sieci wirtualnej uzyskanego po migracji. Należy również zwrócić uwagę na aktualizowanie stref dns spoza platformy Azure (na przykład lokalne serwery DNS wskazujące prywatny adres IP usługi API Management). Jednak w trybie zewnętrznym proces migracji automatycznie zaktualizuje domeny domyślne, jeśli są używane.

  • Moje wystąpienie stv1 jest wdrażane w wielu regionach platformy Azure (w wielu regionach). Jak mogę uaktualnić do wersji stv2?

    Wdrożenia w wielu regionach obejmują więcej bram zarządzanych wdrożonych w innych lokalizacjach. Każda lokalizacja powinna być migrowana oddzielnie, udostępniając nową podsieć i nowy publiczny adres IP (wymagany podczas włączania nadmiarowości strefy). Przejdź do bloku Lokalizacje i wykonaj zmiany w każdej wymienionej lokalizacji. Wystąpienie jest uznawane za migrowane na nową platformę tylko wtedy, gdy wszystkie lokalizacje są migrowane. Wszystkie bramy regionalne nadal działają normalnie w całym procesie migracji.

  • Czy mogę uaktualnić moje wystąpienie stv1 do tej samej podsieci?

    • Nie można migrować stv1 wystąpienia do tej samej podsieci w jednym przebiegu bez przestoju. Możesz jednak opcjonalnie przenieść zmigrowane wystąpienie z powrotem do oryginalnej podsieci. Więcej szczegółów można znaleźć tutaj.
    • Stara brama trwa od 15 minut do 45 minut, aby opuścić podsieć, aby można było zainicjować przeniesienie. Możesz jednak poprosić o zwiększenie tego czasu do 48 godzin przez bilet pomocy technicznej.
    • Upewnij się, że sieć starej podsieci dla sieciowej grupy zabezpieczeń i zapory została zaktualizowana pod kątem stv2 zależności.
    • Alokacja adresów IP podsieci jest nieokreślona, dlatego oryginalny adres IP wewnętrznego modułu równoważenia obciążenia dla wdrożeń "trybu wewnętrznego" może ulec zmianie po powrocie do oryginalnej podsieci. Wymaga to zmiany DNS, jeśli używasz rekordów A.

  • Czy mogę przetestować nową bramę przed przełączeniem ruchu na żywo?

    • Domyślnie stare i nowe bramy zarządzane współistnieją przez 15 minut, co jest małym przedziałem czasu na zweryfikowanie wdrożenia. Możesz poprosić o zwiększenie tego czasu do 48 godzin za pośrednictwem biletu pomoc techniczna platformy Azure. Ta zmiana utrzymuje stare i nowe bramy zarządzane aktywne w celu odbierania ruchu i ułatwienia walidacji.
    • Proces migracji automatycznie aktualizuje domyślne nazwy domen, a jeśli jest używany, ruch kieruje się natychmiast do nowych bram.
    • Jeśli nazwy domen niestandardowych są używane, odpowiednie rekordy DNS mogą być konieczne zaktualizować przy użyciu nowego adresu IP, jeśli nie używa CNAME. Klienci mogą zaktualizować plik hostów do nowego adresu IP usługi API Management i zweryfikować wystąpienie przed przełączenia. Podczas tego procesu walidacji stara brama nadal obsługuje ruch na żywo.

  • Czy istnieją jakieś zagadnienia dotyczące używania domyślnej nazwy domeny?

    Wystąpienia korzystające z domyślnej nazwy DNS w trybie zewnętrznym mają automatycznie zaktualizowany przez proces migracji DNS. Ponadto punkt końcowy zarządzania, który zawsze używa domyślnej nazwy domeny, jest automatycznie aktualizowany przez proces migracji. Ponieważ przełącznik odbywa się natychmiast po pomyślnej migracji, nowe wystąpienie natychmiast zaczyna odbierać ruch i ma kluczowe znaczenie dla wszelkich ograniczeń sieci/zależności z wyprzedzeniem, aby uniknąć niedostępności interfejsów API, których dotyczy problem.

  • Co należy wziąć pod uwagę w przypadku bram hostowanych samodzielnie?

    Nie musisz nic robić w własnych bramach. Wystarczy przeprowadzić migrację wystąpień usługi API Management działających na platformie Azure, które mają wpływ na stv1 wycofanie platformy. Należy pamiętać, że dla punktu końcowego konfiguracji wystąpienia usługi API Management może istnieć nowy adres IP, a wszelkie ograniczenia sieciowe przypięte do adresu IP powinny zostać zaktualizowane.

  • Jaki wpływ ma portal deweloperów na migrację?

    Nie ma to wpływu na portal deweloperów. Jeśli są używane domeny niestandardowe, rekord DNS powinien zostać zaktualizowany przy użyciu obowiązującego adresu IP, po migracji. Jeśli jednak domeny domyślne są używane, są one automatycznie aktualizowane po pomyślnej migracji. Podczas migracji nie ma przestoju w portalu dla deweloperów.

  • Czy po przeprowadzeniu migracji do wersji stv2 ma jakiś wpływ na koszt?

    Model rozliczeń pozostaje taki sam w przypadku stv2 i nie będzie już poniesionych kosztów podczas migracji i po niej.

  • Jakie uprawnienia RBAC są wymagane do migracji stv1 do stv2?

    Użytkownik/proces podejmujący migrację wymaga dostępu do zapisu w wystąpieniu usługi API Management. Ponadto wymagane są następujące dwa uprawnienia:

    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/publicIPAddresses/join/action

Wideo

Powiązana zawartość