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 | Premia

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. Dowiedz się, czy musisz to zrobić.

Uwaga

Nowość w sierpniu 2024 r.: Aby ułatwić migrację wystąpienia z wstrzykniętą siecią wirtualną, ulepszyliśmy opcje migracji w portalu! Teraz możesz przeprowadzić migrację wystąpienia w miejscu i zachować ten sam podsieć i adres IP.

W przypadku wystąpienia iniekcji sieci wirtualnej dostępne są następujące opcje migracji:

  • Opcja 1. Zachowaj tę samą podsieć — przeprowadź migrację wystąpienia w miejscu i zachowaj istniejącą konfigurację podsieci wystąpień. Możesz wybrać, czy oryginalny adres VIP wystąpienia usługi API Management jest zachowywany (zalecany), czy też zostanie wygenerowany nowy adres VIP.

  • Opcja 2. Zmień na nową podsieć — przeprowadź migrację wystąpienia, określając inną podsieć w tej samej lub innej sieci wirtualnej. Po migracji opcjonalnie zmigruj z powrotem do oryginalnej podsieci wystąpienia. Proces migracji zmienia adresy VIP wystąpienia. Po migracji należy zaktualizować wszystkie zależności sieciowe, w tym dns, reguły zapory i sieci wirtualne, aby używać nowych adresów VIP.

W pewnych, rzadziej występujących warunkach migracja w tej samej podsieci może nie być możliwa lub działa inaczej. Aby uzyskać więcej informacji, zobacz Specjalne warunki i scenariusze.

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 jest wycofywana. Na globalnej platformie Azure data wycofania to 31 sierpnia 2024 r. W usłudze Azure Government i na platformie Azure obsługiwanej przez firmę 21Vianet (Azure w Chinach) data wycofania to 24 lutego 2025 r. Jeśli masz wystąpienia hostowane na stv1 platformie, przeprowadź migrację ich na stv2 platformę przed datą wycofania, aby uniknąć przerw w działaniu usługi.

Uwaga

  • Migrowanie wystąpienia usługi API Management do stv2 platformy jest długotrwałą operacją.
  • 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. Planowanie dłuższych czasów wdrożeń w wielu regionach i w scenariuszach obejmujących zmianę podsieci więcej niż raz.
  • Stan usługi API Management w witrynie Azure Portal to Aktualizowanie.
  • W przypadku niektórych opcji migracji można wybrać zachowanie adresu VIP lub zostanie wygenerowany nowy publiczny adres VIP.
  • W przypadku scenariuszy migracji w przypadku wygenerowania nowego adresu VIP:
    • Platforma Azure zarządza migracją.
    • 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 krótkim okresie. Podczas zmiany na nową podsieć przy użyciu bloku Migracja platformy w portalu możesz włączyć ustawienie migracji, aby zachować starą bramę przez 48 godzin. Opcja opóźnienia 48 godzin jest dostępna tylko dla usług wstrzykowanych przez sieć wirtualną.

Wymagania wstępne

Inne wymagania wstępne są specyficzne dla opcji migracji w poniższych sekcjach.

Opcja 1. Migrowanie i utrzymywanie tej samej podsieci

Wystąpienie usługi API Management można migrować do stv2 platformy, która przechowuje istniejącą konfigurację podsieci, co upraszcza migrację. Migrację można przeprowadzić przy użyciu bloku Migracja platformy w witrynie Azure Portal lub interfejsu API REST usługi Stv2.

Wymagania wstępne

  • Sieciowa grupa zabezpieczeń musi być dołączona do każdej podsieci, a reguły sieciowej grupy zabezpieczeń dla usługi API Management na stv2 platformie muszą być skonfigurowane. Poniżej przedstawiono minimalne ustawienia łączności:

    • Ruch wychodzący do usługi Azure Storage przez port 443
    • Ruch wychodzący do usługi Azure SQL przez port 1433
    • Ruch wychodzący do usługi Azure Key Vault za pośrednictwem portu 443
    • Ruch przychodzący z usługi Azure Load Balancer przez port 6390
    • Ruch przychodzący z tagu usługi ApiManagement przez port 3443
    • Ruch przychodzący przez port 80/443 dla klientów wywołujących usługę API Management
    • Podsieć musi mieć włączone punkty końcowe usługi dla usług Azure Storage, Azure SQL i Azure Key Vault

  • Przestrzeń adresowa każdej istniejącej podsieci musi być wystarczająco duża, aby hostować kopię istniejącej usługi obok istniejącej usługi podczas migracji.

  • Inne zagadnienia dotyczące sieci:

    • Wyłącz wszystkie reguły skalowania automatycznego skonfigurowane dla wystąpień usługi API Management wdrożonych w podsieci. Reguły skalowania automatycznego mogą zakłócać proces migracji.
    • Jeśli masz wiele wystąpień usługi API Management w tej samej podsieci, przeprowadź migrację każdego wystąpienia w sekwencji. Zalecamy szybkie migrowanie wszystkich wystąpień w podsieci, aby uniknąć potencjalnych problemów z wystąpieniami hostowanymi na różnych platformach w tej samej podsieci.

Opcje publicznego adresu IP — migracja tej samej podsieci

Możesz wybrać, czy oryginalny adres VIP wystąpienia usługi API Management jest zachowywany (zalecany), czy też zostanie wygenerowany nowy adres VIP.

  • Zachowaj wirtualny adres IP — jeśli zachowasz adres VIP w sieci wirtualnej w trybie zewnętrznym, żądania interfejsu API mogą pozostać dynamiczne podczas migracji (zobacz Oczekiwany przestój); w przypadku sieci wirtualnej w trybie wewnętrznym oczekiwany jest tymczasowy przestój. Konfiguracja infrastruktury (na przykład domeny niestandardowe, lokalizacje i certyfikaty urzędu certyfikacji) zostanie zablokowana przez 45 minut. Po migracji nie jest wymagana żadna dalsza konfiguracja.

    Dzięki tej opcji stv1 obliczenia zostaną trwale usunięte po zakończeniu migracji. Nie ma możliwości tymczasowego zachowywania go.

    Na poniższej ilustracji przedstawiono ogólny przegląd tego, co się stanie po zachowaniu adresu IP.

    Diagram migracji w miejscu do tej samej podsieci i zachowania adresu IP.

  • Nowy wirtualny adres IP — jeśli wybierzesz tę opcję, usługa API Management wygeneruje nowy adres VIP dla twojego wystąpienia. Żą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 sieci wirtualne, aby używać nowego adresu VIP.

    Dzięki tej opcji stv1 środowisko obliczeniowe jest domyślnie zachowywane przez krótki okres po zakończeniu migracji, aby można było zweryfikować zmigrowane wystąpienie i potwierdzić konfigurację sieci i systemu DNS.

    Na poniższej ilustracji przedstawiono ogólny przegląd tego, co się stanie po wygenerowaniu nowego adresu IP.

    Diagram migracji w miejscu do tej samej podsieci i generowania nowego adresu IP.

Wstępnie utworzony adres IP na potrzeby migracji

W przypadku wystąpień usługi API Management, które są osiągalne przez publiczny adres IP, usługa API Management wstępnie utworzy publiczny adres IP dla procesu migracji. Znajdź wstępnie utworzony adres IP w danych wyjściowych JSON właściwości wystąpienia usługi API Management. W obszarze customPropertieswstępnie utworzony adres IP jest wartością Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps właściwości . W przypadku wdrożenia w wielu regionach wartość jest rozdzieloną przecinkami listą wstępnie utworzonych adresów IP.

Użyj wstępnie utworzonego adresu IP (lub adresów), aby ułatwić zarządzanie procesem migracji:

  • Podczas migracji i zachowania adresu VIP wstępnie utworzony adres IP jest tymczasowo przypisywany do nowego stv2 wdrożenia, zanim oryginalny adres IP zostanie przypisany do stv2 wdrożenia. Jeśli masz reguły zapory ograniczające dostęp do wystąpienia usługi API Management, możesz na przykład dodać wstępnie utworzony adres IP do listy dozwolonych, aby zachować ciągłość dostępu klienta podczas migracji. Po zakończeniu migracji można usunąć wstępnie utworzony adres IP z listy dozwolonych.
  • Podczas migracji i generowania nowego adresu VIP wstępnie utworzony adres IP jest przypisywany do nowego stv2 wdrożenia podczas migracji i utrwala się po zakończeniu migracji. Użyj wstępnie utworzonego adresu IP, aby zaktualizować zależności sieciowe, takie jak reguły DNS i zapory, aby wskazać nowy adres IP.

Oczekiwany przestój i przechowywanie zasobów obliczeniowych

Podczas migrowania wystąpienia z wstrzykniętą siecią wirtualną i zachowania tej samej konfiguracji podsieci jest oczekiwany minimalny lub żaden przestój bramy interfejsu API. W poniższej tabeli przedstawiono podsumowanie oczekiwanego przestoju i stv1 przechowywania zasobów obliczeniowych dla każdego scenariusza migracji podczas przechowywania tej samej podsieci:

Tryb sieci wirtualnej Opcja Publicznego adresu IP Oczekiwany przestój stv1 przechowywanie zasobów obliczeniowych
Zewnętrzne Zachowaj adres VIP Brak przestoju; ruch jest obsługiwany na tymczasowym adresie IP przez maksymalnie 20 minut podczas migracji do nowego stv2 wdrożenia Brak przechowywania
Zewnętrzne Nowy adres VIP Brak przestoju Zachowywane domyślnie przez 15 minut, aby umożliwić aktualizowanie zależności sieci
Wewnętrzny Zachowaj adres VIP Przestój przez około 20 minut podczas migracji, gdy istniejący adres IP jest przypisany do nowego stv2 wdrożenia. Brak przechowywania
Wewnętrzny Nowy adres VIP Brak przestoju Zachowywane domyślnie przez 15 minut, aby umożliwić aktualizowanie zależności sieci; można przedłużyć do 48 godzin w przypadku korzystania z portalu

Kroki migracji — zachowaj tę samą podsieć

  1. W witrynie Azure Portal przejdź do wystąpienia usługi API Management.
  2. W menu po lewej stronie w obszarze Ustawienia wybierz pozycję Migracja platformy.
  3. W obszarze Wybierz opcję migracji wybierz pozycję Zachowaj tę samą podsieć.
  4. W obszarze Wybierz adres IP wybierz jedną z dwóch opcji adresu IP.

    Uwaga

    Jeśli sieć wirtualna jest w trybie zewnętrznym, zanotuj wstępnie utworzony publiczny adres IP procesu migracji. Użyj tego adresu, aby skonfigurować łączność sieciową dla migrowanego wystąpienia.

  5. (W przypadku wystąpień w trybie wewnętrznym i migracji do nowego adresu VIP) W obszarze Wybierz scenariusz, który jest zgodny z wymaganiami, wybierz jedną z dwóch opcji, w zależności od tego, czy chcesz zachować oryginalne stv1 zasoby obliczeniowe przez okres po migracji.
  6. Wybierz pozycję Weryfikuj , aby uruchomić automatyczne kontrole w podsieci. Jeśli zostaną wykryte problemy, dostosuj konfigurację podsieci i ponownie uruchom testy. W przypadku innych zależności sieciowych, takich jak reguły DNS i zapory, sprawdź ręcznie.
  7. Upewnij się, że chcesz przeprowadzić migrację, a następnie wybierz pozycję Rozpocznij migrację. Stan wystąpienia usługi API Management zmienia się na Aktualizowanie. Proces migracji trwa około 45 minut. Gdy stan zmieni się na Online, migracja zostanie ukończona.

Opcja 2. Migrowanie i zmienianie podsieci na nową

Za pomocą witryny Azure Portal możesz przeprowadzić migrację wystąpienia, określając inną podsieć w tej samej lub innej sieci wirtualnej. Po migracji opcjonalnie zmigruj z powrotem do oryginalnej podsieci wystąpienia.

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.

Wymagania wstępne

  • 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 każdej podsieci, a reguły sieciowej grupy zabezpieczeń dla usługi API Management na stv2 platformie 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. zasób publicznego adresu IP nie jest już potrzebny podczas wdrażania (wstrzykiwania) wystąpienia usługi API Management w sieci wirtualnej w trybie wewnętrznym lub migrowania 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 jest automatycznie konfigurowany i używany na potrzeby ruchu interfejsu API środowiska uruchomieniowego. Podaj tylko publiczny adres IP, jeśli chcesz być właścicielem i kontrolować publiczny adres IP używany do komunikacji przychodzącej lub wychodzącej z Internetem.

Kroki migracji — zmiana na nową podsieć

  1. W witrynie Azure Portal przejdź do wystąpienia usługi API Management.

  2. W menu po lewej stronie w obszarze Ustawienia wybierz pozycję Migracja platformy.

  3. W obszarze Wybierz opcję migracji wybierz pozycję Zmień na nową podsieć.

  4. W obszarze Wybierz scenariusz, który jest zgodny z wymaganiami, wybierz jedną z dwóch opcji, w zależności od tego, czy chcesz zachować oryginalne stv1 zasoby obliczeniowe przez okres po migracji.

    Zrzut ekranu przedstawiający opcje zachowania obliczeń stv1 w portalu.

  5. W obszarze Definiowanie ustawień migracji dla każdej lokalizacji:

    1. Wybierz lokalizację do migracji.
    2. Wybierz sieć wirtualną, podsieć i opcjonalny publiczny adres IP, do którego chcesz przeprowadzić migrację.

    Zrzut ekranu przedstawiający wybieranie ustawień migracji sieci w portalu.

  6. W obszarze Sprawdź, czy podsieć spełnia wymagania dotyczące migracji, wybierz pozycję Weryfikuj , aby uruchomić automatyczne kontrole w podsieci. Jeśli zostaną wykryte problemy, dostosuj konfigurację podsieci i ponownie uruchom testy. W przypadku innych zależności sieciowych, takich jak reguły DNS i zapory, sprawdź ręcznie.

  7. Upewnij się, że chcesz przeprowadzić migrację, a następnie wybierz pozycję Migruj. Stan wystąpienia usługi API Management zmienia się na Aktualizowanie. Proces migracji trwa około 45 minut. Gdy stan zmieni się na Online, migracja zostanie ukończona.

Jeśli wystąpienie usługi API Management jest wdrażane w wielu regionach, powtórz powyższe kroki, aby kontynuować migrację ustawień sieci wirtualnej dla pozostałych lokalizacji wystąpienia.

(Opcjonalnie) Migrowanie z powrotem do oryginalnej podsieci

Jeśli przeprowadzono migrację i zmieniono je na nową podsieć, opcjonalnie przeprowadź migrację z powrotem do oryginalnej podsieci użytej w każdym regionie. 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.

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. zasób publicznego adresu IP nie jest już potrzebny podczas wdrażania (wstrzykiwania) wystąpienia usługi API Management w sieci wirtualnej w trybie wewnętrznym lub migrowania 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 jest automatycznie konfigurowany i używany na potrzeby ruchu interfejsu API środowiska uruchomieniowego. Podaj tylko publiczny adres IP, jeśli chcesz być właścicielem i kontrolować publiczny adres IP używany do komunikacji przychodzącej lub wychodzącej z Internetem.

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. Przejdź do wystąpienia usługi API Management.
  5. W menu po lewej stronie w obszarze Sieć wybierz pozycję Sieć wirtualna.
  6. Wybierz połączenie sieciowe w lokalizacji, w której chcesz zaktualizować.
  7. Wybierz oryginalną sieć wirtualną i podsieć. Opcjonalnie wybierz nowy publiczny adres IP. Wybierz Zastosuj.
  8. Jeśli wystąpienie usługi API Management jest wdrażane w wielu regionach, kontynuuj konfigurowanie ustawień sieci wirtualnej dla pozostałych lokalizacji wystąpienia.
  9. 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

W przypadku scenariuszy, w których stara brama jest tymczasowo zachowywana po migracji, stare i nowe zasoby obliczeniowe utworzone podczas migracji współistnieją przez krótki czas, około 15 minut, których można użyć do zweryfikowania wdrożenia i działania aplikacji zgodnie z oczekiwaniami. W przypadku niektórych scenariuszy możesz opcjonalnie przedłużyć okres przechowywania do 48 godzin za pomocą ustawienia portalu.

  • 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.

Specjalne warunki i scenariusze

W pewnych warunkach opcja 1: Migrowanie i utrzymywanie tej samej podsieci może być niedostępne lub działa inaczej. Portal wykrywa te warunki i zaleca opcje migracji. Jeśli nie możesz użyć opcji 1 lub istnieje wiele warunków, użyj opcji 2: Zmień na nową podsieć.

  • Sieć wirtualna ze specjalnymi warunkami wewnętrznymi — jeśli wystąpienie usługi API Management jest obecnie wdrażane w sieci wirtualnej ze specjalnymi warunkami wewnętrznymi (niepowiązanymi z konfiguracją klienta), otrzymasz powiadomienie w portalu, że opcja 1 dla migracji tej samej podsieci w portalu obejmuje dodatkowy przestój (około 1 godzinę). Zalecane jest użycie portalu do migracji. Możesz również użyć następującego zmodyfikowanego skryptu interfejsu wiersza polecenia platformy Azure na potrzeby migracji tej samej podsieci z około 1 godziną przestoju:

    APIM_NAME={name of your API Management instance}
# In PowerShell, use the following syntax: $APIM_NAME={name of your API Management instance}
RG_NAME={name of your resource group} 
# Get resource ID of API Management instance
APIM_RESOURCE_ID=$(az apim show --name $APIM_NAME --resource-group $RG_NAME --query id --output tsv)
# Call REST API to migrate to stv2 and preserve VIP address for special condition
az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2024-06-01-preview&migrateWithDowntime=true" --body '{"mode": "PreserveIP"}'

  • Wiele wystąpień stv1 w podsieci — wystarczające bezpłatne adresy IP mogą nie być dostępne dla migracji z tej samej podsieci, jeśli próbujesz migrować wystąpienia jednocześnie. Możesz przeprowadzić sekwencyjną migrację wystąpień przy użyciu opcji 1.

  • Delegowanie podsieci — jeśli podsieć, w której wdrożono usługę API Management, jest obecnie delegowana do innych usług platformy Azure, należy przeprowadzić migrację przy użyciu opcji 2.

  • Usługa Azure Key Vault zablokowana — jeśli dostęp do usługi Azure Key Vault jest obecnie zablokowany, musisz przeprowadzić migrację przy użyciu opcji 2, w tym skonfigurowania reguł sieciowej grupy zabezpieczeń w nowej podsieci w celu uzyskania dostępu do usługi Azure Key Vault.

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 i zarządzanie.
  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ą zobacz wymagania wstępne dotyczące opcji migracji i utrzymania tej samej podsieci lub migracji i zmiany w nowej podsieci.

  • Czy migracja spowoduje przestój?

    Podczas migrowania wystąpienia z wstrzykniętą siecią wirtualną i zachowania tej samej konfiguracji podsieci jest oczekiwany minimalny lub żaden przestój bramy interfejsu API. Zobacz tabelę podsumowania w temacie Oczekiwany przestój.

    Podczas migracji i zmieniania na nowy adres VIP nie powinien występować żaden przestój, 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 w przypadku niektórych opcji migracji włącz ustawienie migracji, aby zachować starą bramę przez 48 godzin. 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?

    • Przede wszystkim upewnij się, że podsieci używane do migracji zachowują następującą konfigurację (należy je już skonfigurować, jeśli migrujesz i utrzymujesz bieżącą podsieć):
      • 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ąd odczytuje wartość Online wraz z wersją platformy lub stv2 stv2.1. Sprawdź również, czy stan sieci w bloku Sieć 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ć przy użyciu bloku Migracja platformy.

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

    Tak, blok Migracja platformy w portalu i interfejs API REST mają opcje zachowania adresu IP.

  • 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.

  • 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. Planowanie dłuższych czasów wdrożeń w wielu regionach i w scenariuszach obejmujących zmianę podsieci więcej niż raz.

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

    Jeśli planujesz zmianę podsieci podczas migracji, możesz wdrożyć nowe wystąpienie usługi API Management przy użyciu zasobu sieci wirtualnej, podsieci i (opcjonalnie) adresu IP, który będzie używany 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 .

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

    W przypadku wystąpień w sieci wirtualnej w trybie wewnętrznym i zmianie na nowy adres VIP 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. Podczas migracji przy użyciu bloku Migracja platformy w portalu poszczególne lokalizacje są migrowane oddzielnie. Interfejs API REST migracji do stv2 migruje wszystkie lokalizacje w jednym wywołaniu. 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?

    Tak, użyj bloku Migracja platformy w portalu lub użyj interfejsu API REST migracji do stv2.

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

    • Podczas migracji do nowej podsieci domyślnie stare i nowe bramy zarządzane współistnieją przez 15 minut, co jest małym oknem czasu na zweryfikowanie wdrożenia. Możesz włączyć ustawienie migracji, aby zachować starą bramę przez 48 godzin. 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 w nowej podsieci?

    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

Powiązana zawartość