Megosztás a következőn keresztül:

Az stv1 platformon üzemeltetett VNet-injektált API Management-példány migrálása az stv2-be

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: Fejlesztő | Prémium

Ez a cikk a számítási platformon stv1 üzemeltetett API Management-példány helyszíni migrálásának lépéseit ismerteti a stv2 platformra, amikor a példányt egy külső vagy belső virtuális hálózatba injektálják (üzembe helyezik). Tudja meg, hogy szükség van-e erre.

Feljegyzés

Újdonságok 2024 augusztusában: A virtuális hálózatba injektált példány migrálásához javítottuk a migrálási lehetőségeket a portálon! Most már helyben migrálhatja a példányt, és megtarthatja ugyanazt az alhálózatot és IP-címet.

VNet-injektált példány esetén a következő áttelepítési lehetőségek állnak rendelkezésre:

  • 1. lehetőség: Tartsa meg ugyanazt az alhálózatot – Migrálja a példányt helyben, és tartsa meg a példányok meglévő alhálózati konfigurációját. Megadhatja, hogy az API Management-példány eredeti VIP-címe megmarad-e (ajánlott), vagy új VIP-cím jön létre.

  • 2. lehetőség: Váltás új alhálózatra – A példány áttelepítése egy másik alhálózat megadásával ugyanabban vagy egy másik virtuális hálózaton. A migrálás után szükség esetén térjen vissza a példány eredeti alhálózatára. A migrálási folyamat megváltoztatja a példány VIP-címét. A migrálás után frissítenie kell minden hálózati függőséget, beleértve a DNS-t, a tűzfalszabályokat és a virtuális hálózatokat az új VIP-cím(ek) használatához.

Ha nem VNnet-injektált API Managementet kell migrálnia a stv1 platformon, olvassa el a nem VNetbe injektált API Management-példány migrálását az stv2 platformra.

Fontos

A platformon stv1 üzemeltetett API Management-példányok támogatása megszűnik. A globális Azure-ban a kivonás dátuma 2024. augusztus 31. Az Azure Governmentben és a 21Vianet által üzemeltetett Azure-ban (a kínai Azure-ban) a kivonás dátuma 2025. február 24. Ha a platformon stv1 vannak példányai, a szolgáltatáskimaradások elkerülése érdekében migrálja őket stv2 a platformra a kivonási dátum előtt.

Figyelemfelhívás

  • Az API Management-példány platformra való stv2 migrálása hosszú ideig futó művelet.
  • A migrálás stv2 nem visszafordítható.

Mi történik a migrálás során?

Az API Management platform áttelepítése stv1 magában stv2 foglalja a mögöttes számítás egyedüli frissítését, és nincs hatással a tárolási rétegben tárolt szolgáltatás-/API-konfigurációra.

  • A frissítési folyamat magában foglalja egy új számítás létrehozását a régi számítással párhuzamosan, amely akár 45 percet is igénybe vehet. Tervezze meg hosszabb ideig a többrégiós üzemelő példányokat, és olyan forgatókönyvekben, amelyekben az alhálózat többszöri módosítása is szerepel.
  • Az Api Management állapota az Azure Portalon frissítés lesz.
  • Bizonyos migrálási beállítások esetén megadhatja, hogy megőrződik-e a VIP-cím, vagy létrejön egy új nyilvános VIP.
  • Áttelepítési forgatókönyvek esetén, amikor új VIP-cím jön létre:
    • Az Azure kezeli a migrálást.
    • Az átjáró DNS-je továbbra is a régi számításra mutat, ha egyéni tartomány van használatban.
    • Ha az egyéni DNS nincs használatban, az átjáró és a portál DNS-címe azonnal az új számításra mutat.
    • Egy belső virtuális hálózati módban lévő példány esetében az ügyfél kezeli a DNS-t, így a DNS-bejegyzések a régi számításra mutatnak, amíg az ügyfél nem frissíti.
    • Ez a DNS az új vagy a régi számításra mutat, így nincs állásidő az API-k számára.
    • Ha vannak ilyenek, módosítani kell a tűzfalszabályokat, hogy az új számítási alhálózat elérje a háttérrendszereket.
    • A sikeres migrálás után a rendszer rövid idő elteltével automatikusan leszereli a régi számítást. Amikor új alhálózatra vált a portál platformmigrálási paneljén, engedélyezheti, hogy a migrálási beállítás 48 órán át megőrizze a régi átjárót. A 48 órás késleltetési lehetőség csak a virtuális hálózatba injektált szolgáltatásokhoz érhető el.

Előfeltételek

Az egyéb előfeltételek a következő szakaszokban szereplő áttelepítési lehetőségekre vonatkoznak.

1. lehetőség: Azonos alhálózat migrálása és megtartva

Az API Management-példányt a stv2 meglévő alhálózati konfigurációt megtartó platformra migrálhatja, ami leegyszerűsíti a migrálást. A migrálás az Azure Portal platformmigrálási paneljén vagy az Stv2 REST API-ba való migrálással történik.

Előfeltételek

  • Minden alhálózathoz hálózati biztonsági csoportot kell csatlakoztatni, és konfigurálnia kell a stv2 platformon az API Management NSG-szabályait. A minimális kapcsolati beállítások a következők:

    • Kimenő forgalom az Azure Storage-ba a 443-as porton keresztül
    • Kimenő forgalom az Azure SQL-be az 1433-as porton keresztül
    • Kimenő forgalom az Azure Key Vaultba a 443-as porton keresztül
    • Bejövő forgalom az Azure Load Balancerből a 6390-s porton keresztül
    • Bejövő forgalom az ApiManagement szolgáltatás címkéjéből a 3443-es porton keresztül
    • Bejövő forgalom a 80/443-es porton az API Management szolgáltatást hívó ügyfelek számára
    • Az alhálózatnak engedélyeznie kell az Azure Storage, az Azure SQL és az Azure Key Vault szolgáltatásvégpontjait

  • Az egyes meglévő alhálózatok címterének elég nagynak kell lennie ahhoz, hogy a meglévő szolgáltatás egy példányát a meglévő szolgáltatás mellett tárolja az áttelepítés során.

  • Egyéb hálózati szempontok:

    • Kapcsolja ki az alhálózaton üzembe helyezett API Management-példányokhoz konfigurált automatikus méretezési szabályokat. Az automatikus méretezési szabályok zavarhatják az áttelepítési folyamatot.
    • Ha több API Management-példánya van ugyanabban az alhálózatban, az egyes példányokat egymás után migrálja. Javasoljuk, hogy azonnal migrálja az alhálózat összes példányát, hogy elkerülje az azonos alhálózat különböző platformjain üzemeltetett példányokkal kapcsolatos esetleges problémákat.

Nyilvános IP-cím beállításai – azonos alhálózati migrálás

Megadhatja, hogy az API Management-példány eredeti VIP-címe megmarad-e (ajánlott), vagy új VIP-cím jön létre.

  • Virtuális IP-cím megőrzése – Ha külső módban őrzi meg a virtuális hálózat VIP-címét, az API-kérések a migrálás során is reagálhatnak (lásd : Várható állásidő); belső módban lévő virtuális hálózatok esetén ideiglenes állásidő várható. Az infrastruktúra-konfiguráció (például egyéni tartományok, helyek és ca-tanúsítványok) 45 percig zárolva lesznek. A migrálás után nincs szükség további konfigurációra.

    Ezzel a beállítással a stv1 számítás véglegesen törlődik az áttelepítés befejezése után. Ideiglenesen nem tarthatja meg.

    Az alábbi képen magas szintű áttekintés látható arról, hogy mi történik az IP-cím megőrzésekor.

    Diagram az azonos alhálózatra történő helyszíni migrálásról és az IP-cím megőrzéséről.

  • Új virtuális IP-cím – Ha ezt a lehetőséget választja, az API Management létrehoz egy új VIP-címet a példányhoz. Az API-kérések a migrálás során is válaszolnak. Az infrastruktúra-konfiguráció (például egyéni tartományok, helyek és ca-tanúsítványok) 30 percig zárolva lesznek. A migrálás után frissítenie kell minden hálózati függőséget, beleértve a DNS-t, a tűzfalszabályokat és a virtuális hálózatokat az új VIP-cím használatához.

    Ezzel a beállítással a stv1 számítás alapértelmezés szerint rövid ideig marad meg a migrálás befejezése után, így ellenőrizheti a migrált példányt, és megerősítheti a hálózati és DNS-konfigurációt.

    Az alábbi képen magas szintű áttekintés látható arról, hogy mi történik új IP-cím létrehozásakor.

    Diagram a helyi migrálásról ugyanarra az alhálózatra, és új IP-cím létrehozása.

Előre létrehozott IP-cím a migráláshoz

Nyilvános IP-címmel elérhető API Management-példányok esetén az API Management előtelepít egy nyilvános IP-címet az áttelepítési folyamathoz. Keresse meg az előre létrehozott IP-címet az API Management-példány tulajdonságainak JSON-kimenetében. Alatta customPropertiesaz előre létrehozott IP-cím a Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps tulajdonság értéke. Többrégiós üzemelő példány esetén az érték az előre létrehozott IP-címek vesszővel tagolt listája.

A migrálási folyamat kezeléséhez használja az előre létrehozott IP-címet (vagy címeket):

  • A VIP-cím áttelepítése és megőrzésekor a rendszer ideiglenesen hozzárendeli az előre létrehozott IP-címet az új stv2 üzembe helyezéshez, mielőtt az eredeti IP-címet hozzárendeli az stv2 üzembe helyezéshez. Ha például tűzfalszabályok korlátozzák az API Management-példányhoz való hozzáférést, hozzáadhatja az előre létrehozott IP-címet az engedélyezési listához, hogy megőrizze az ügyfélhozzáférés folytonosságát a migrálás során. A migrálás befejezése után eltávolíthatja az előre létrehozott IP-címet az engedélyezési listáról.
  • Amikor migrál és létrehoz egy új VIP-címet, az előre létrehozott IP-cím hozzá lesz rendelve az új stv2 üzembe helyezéshez az áttelepítés során, és az áttelepítés befejezése után is megmarad. Az előre létrehozott IP-címmel frissítheti a hálózati függőségeket, például a DNS- és tűzfalszabályokat, hogy az új IP-címre mutasson.

Várható állásidő és számítási adatmegőrzés

Ha migrál egy virtuális hálózatba injektált példányt, és megtartja ugyanazt az alhálózati konfigurációt, az API-átjáró minimális leállása vagy leállása várható. Az alábbi táblázat összefoglalja az egyes migrálási forgatókönyvek várható állásidejét és stv1 számítási megőrzését ugyanazon alhálózat megtartásakor:

Virtuális hálózat mód Nyilvános IP-cím beállítás Várható állásidő stv1 számítási adatmegőrzés
Külső VIP megőrzése Nincs állásidő; a forgalom egy ideiglenes IP-címen lesz kiszolgálva az új stv2 üzembe helyezésre való migrálás során legfeljebb 20 percig Nincs adatmegőrzés
Külső Új VIP Nincs állásidő Alapértelmezés szerint 15 percig őrzi meg, hogy lehetővé tegye a hálózati függőségek frissítését
Belső VIP megőrzése A migrálás során körülbelül 20 percig tart az állásidő, amíg a meglévő IP-cím hozzá van rendelve az új stv2 üzembe helyezéshez. Nincs adatmegőrzés
Belső Új VIP Nincs állásidő Alapértelmezés szerint 15 percig őrzi meg, hogy lehetővé tegye a hálózati függőségek frissítését; a portál használata esetén 48 órára meghosszabbítható

Migrálási lépések – azonos alhálózat megtartása

  1. Az Azure Portalon keresse meg az API Management-példányt.
  2. A bal oldali menü Beállítások területén válassza a Platformmigrálás lehetőséget.
  3. A Migrálás kiválasztása lehetőség alatt válassza az Azonos alhálózat megtartása lehetőséget.
  4. Az IP-cím kiválasztása beállításnál válasszon egyet a két IP-cím közül.

    Feljegyzés

    Ha a virtuális hálózat külső módban van, jegyezze fel az áttelepítési folyamat előre létrehozott nyilvános IP-címét. Ezzel a címmel konfigurálhatja a migrált példány hálózati kapcsolatát.

  5. (Belső módban injektált és új VIP-re migrált példányok esetén) A Követelményeknek megfelelő forgatókönyv kiválasztása területen válasszon egyet a két lehetőség közül attól függően, hogy az eredeti stv1 számítást a migrálás utáni időszakra szeretné-e fenntartani.
  6. Az Ellenőrzés lehetőséget választva automatikus ellenőrzéseket futtathat az alhálózaton. Ha problémákat észlel, módosítsa az alhálózat konfigurációját, és futtassa újra az ellenőrzéseket. Más hálózati függőségek, például a DNS és a tűzfalszabályok esetében ellenőrizze manuálisan.
  7. Győződjön meg arról, hogy migrálni szeretne, és válassza a Migrálás indítása lehetőséget. Az API Management-példány állapota frissítésre változik. Az áttelepítési folyamat körülbelül 45 percet vesz igénybe. Amikor az állapot online állapotúra változik, a migrálás befejeződött.

2. lehetőség: Migrálás és váltás új alhálózatra

Az Azure Portal használatával migrálhatja a példányt úgy, hogy egy másik alhálózatot ad meg ugyanabban vagy egy másik virtuális hálózatban. A migrálás után szükség esetén térjen vissza a példány eredeti alhálózatára.

Az alábbi képen magas szintű áttekintés látható arról, hogy mi történik az új alhálózatra való migrálás során.

Diagram az új alhálózatra történő helyszíni migrálásról.

Előfeltételek

Fontos

  • 2024 májusától már nincs szükség nyilvános IP-címerőforrásra, ha belső módban helyez üzembe (injektál) egy API Management-példányt egy virtuális hálózaton, vagy migrálja a belső virtuális hálózat konfigurációját egy új alhálózatra. Külső virtuális hálózat módban a nyilvános IP-cím megadása nem kötelező; ha nem ad meg egyet, a rendszer automatikusan konfigurál egy Azure által felügyelt nyilvános IP-címet, és használja a futtatókörnyezeti API-forgalomhoz. Csak akkor adja meg a nyilvános IP-címet, ha az internet felé irányuló bejövő vagy kimenő kommunikációhoz használt nyilvános IP-címet szeretné birtokolni és szabályozni.

Áttelepítési lépések – váltás új alhálózatra

  1. Az Azure Portalon keresse meg az API Management-példányt.

  2. A bal oldali menü Beállítások területén válassza a Platformmigrálás lehetőséget.

  3. A Migrálás kiválasztása lehetőségnél válassza a Módosítás új alhálózatra lehetőséget.

  4. A Követelményeknek megfelelő forgatókönyv kiválasztása területen válasszon egyet a két lehetőség közül attól függően, hogy az eredeti stv1 számítást a migrálás utáni időszakra szeretné-e fenntartani.

    Képernyőkép az stv1 számítás portálon való megőrzésének lehetőségeiről.

  5. Az egyes helyek áttelepítési beállításainak megadása csoportban:

    1. Válasszon ki egy migrálni kívánt helyet.
    2. Válassza ki azt a virtuális hálózatot, alhálózatot és opcionális nyilvános IP-címet , amelybe át szeretne migrálni.

    Képernyőkép a portál hálózati áttelepítési beállításainak kiválasztásáról.

  6. Az Alhálózat áttelepítési követelményeknek való megfelelésének ellenőrzése csoportban válassza az Ellenőrzés lehetőséget az automatikus ellenőrzések alhálózaton való futtatásához. Ha problémákat észlel, módosítsa az alhálózat konfigurációját, és futtassa újra az ellenőrzéseket. Más hálózati függőségek, például a DNS és a tűzfalszabályok esetében ellenőrizze manuálisan.

  7. Győződjön meg arról, hogy migrálni szeretne, és válassza az Áttelepítés lehetőséget. Az API Management-példány állapota frissítésre változik. Az áttelepítési folyamat körülbelül 45 percet vesz igénybe. Amikor az állapot online állapotúra változik, a migrálás befejeződött.

Ha az API Management-példány több régióban van üzembe helyezve, ismételje meg az előző lépéseket, és folytassa a virtuális hálózat beállításainak áttelepítését a példány többi helyén.

(Nem kötelező) Migrálás az eredeti alhálózatra

Ha áttelepített és új alhálózatra váltott, igény szerint térjen vissza az egyes régiókban használt eredeti alhálózatra. Ehhez frissítse ismét a virtuális hálózat konfigurációját, ezúttal az egyes régiókban az eredeti virtuális hálózatot és alhálózatot adja meg. Az előző migráláshoz hasonlóan várjon egy hosszú ideig futó műveletet, és várja, hogy a VIP-cím megváltozzon.

Az alábbi képen magas szintű áttekintés látható arról, hogy mi történik az eredeti alhálózatra való migrálás során.

Az eredeti alhálózatra való helyi migrálás diagramja.

Fontos

Ha a virtuális hálózat és az alhálózat zárolva van (mert más stv1 platformalapú API Management-példányok is telepítve vannak), vagy az erőforráscsoport, amelyben az eredeti virtuális hálózat telepítve van, erőforrás-zárolással rendelkezik, mindenképpen távolítsa el a zárolást, mielőtt visszatelepítené az eredeti alhálózatra. Várjon, amíg a zárolás eltávolítása befejeződik, mielőtt megkíséreli az eredeti alhálózatra való migrálást. További információ.

További előfeltételek

  • A feloldott eredeti alhálózat minden régióban, ahol az API Management-példány telepítve van. Hálózati biztonsági csoportot kell csatlakoztatni az alhálózathoz, és konfigurálni kell az API Management NSG-szabályait .

  • (Nem kötelező) Új standard termékváltozatú nyilvános IPv4-címerőforrás ugyanabban a régióban vagy előfizetésben, mint az API Management-példány.

    Fontos

    • 2024 májusától már nincs szükség nyilvános IP-címerőforrásra, ha belső módban helyez üzembe (injektál) egy API Management-példányt egy virtuális hálózaton, vagy migrálja a belső virtuális hálózat konfigurációját egy új alhálózatra. Külső virtuális hálózat módban a nyilvános IP-cím megadása nem kötelező; ha nem ad meg egyet, a rendszer automatikusan konfigurál egy Azure által felügyelt nyilvános IP-címet, és használja a futtatókörnyezeti API-forgalomhoz. Csak akkor adja meg a nyilvános IP-címet, ha az internet felé irányuló bejövő vagy kimenő kommunikációhoz használt nyilvános IP-címet szeretné birtokolni és szabályozni.

Virtuális hálózat konfigurációjának frissítése

  1. A portálon keresse meg az eredeti virtuális hálózatot.
  2. A bal oldali menüben válassza az Alhálózatok, majd az eredeti alhálózat lehetőséget.
  3. Ellenőrizze, hogy az EREDETI IP-címeket az API Management adta-e ki. Az Elérhető IP-címek területen jegyezze fel az alhálózatban elérhető IP-címek számát. Minden címnek elérhetőnek kell lennie (kivéve a fenntartott Azure-címeket). Ha szükséges, várjon, amíg az IP-címek ki lesznek adva.
  4. Lépjen az API Management-példányra.
  5. A bal oldali menü Hálózat területén válassza a Virtuális hálózat lehetőséget.
  6. Válassza ki a hálózati kapcsolatot a frissíteni kívánt helyen.
  7. Válassza ki az eredeti virtuális hálózati hálózatot és alhálózatot. Igény szerint válasszon ki egy új nyilvános IP-címet. Válassza az Alkalmazás lehetőséget.
  8. Ha az API Management-példány több régióban van üzembe helyezve, folytassa a virtuális hálózat beállításainak konfigurálását a példány többi helyéhez.
  9. A felső navigációs sávon válassza a Mentés lehetőséget.

A virtuális hálózat konfigurációjának frissítése után az API Management-példány állapota frissítésre változik. Az áttelepítési folyamat körülbelül 45 percet vesz igénybe. Amikor az állapot online állapotúra változik, a migrálás befejeződött.

Áttelepítés ellenőrzése

Ha ellenőrizni szeretné, hogy a migrálás sikeres volt-e, amikor az állapot online állapotúra változik, ellenőrizze az API Management-példány platformverzióját. A sikeres migrálás után az érték vagy stv2 stv2.1.

Beállítások megerősítése a régi átjáró törlése előtt

Azokban a forgatókönyvekben, amelyekben a régi átjáró ideiglenesen megmarad az áttelepítés után, a migrálás során létrehozott régi és új számítás rövid ideig, körülbelül 15 percig együtt létezik, amellyel ellenőrizheti az üzembe helyezést, és az alkalmazások a várt módon működnek. Bizonyos esetekben a megőrzési időtartamot egy portálbeállítással 48 órára is meghosszabbíthatja.

  • Ebben az ablakban a régi és az új átjárók egyaránt online állapotban vannak, és a forgalmat szolgálják ki. Ez idő alatt nem kell fizetnie.
  • Ebben az ablakban frissítheti a hálózati függőségeket, például a DNS-t, a tűzfalszabályokat és a virtuális hálózatokat az új VIP-cím és alhálózati címtér használatához.
  • Emellett ellenőrizze a frissített példány hálózati állapotát, hogy biztosítsa a példány függőségeihez való kapcsolódását. A portál bal oldali menüjének Üzembe helyezés és infrastruktúra területén válassza a Hálózati>hálózat állapotát. Szükség esetén frissítse a beállításokat, például az UDR-eket és az NSG-szabályokat.
  • Az ablak után a régi átjáró leszerelve, és az új átjáró az egyetlen, amely a forgalmat szolgálja ki.

Automatikus visszaállítás sikertelen migrálás esetén

Ha az áttelepítési folyamat során hiba történik, a példány automatikusan visszatér a stv1 platformra. Ha a migrálás sikeresen befejeződött (a példány platformverziója online állapotúként vagy stv2.1 állapotként stv2 jelenik meg), nem lehet visszatérni a stv1 platformra.

Ha a migrálás sikertelen, forduljon Azure-támogatás.

Ha szüksége van a manuális visszaállítás képességére, javasoljuk, hogy helyezzen üzembe egy új stv2 példányt az eredeti API Management-példány mellett.

Súgó és támogatás

Azért vagyunk itt, hogy segítsünk a platformra való migrálásban, stv2 minimális fennakadásokkal a szolgáltatásokban.

Ha kérdései vannak, gyors válaszokat kaphat a Microsoft Q&A közösségi szakértőitől. Ha rendelkezik támogatási konstrukcióval és technikai segítségre van szüksége, hozzon létre egy támogatási kérést.

  1. Összegzésként írja be a probléma leírását, például :"stv1 retirement".
  2. A Probléma típusa csoportban válassza a Technical (Technikai) lehetőséget.
  3. Az Előfizetés alatt válassza ki az előfizetését.
  4. A Szolgáltatás területen válassza a Saját szolgáltatások, majd az API Management Service lehetőséget.
  5. Az Erőforrás területen válassza ki azt az Azure-erőforrást, amelyhez támogatási kérelmet hoz létre.
  6. Problématípus esetén válassza a Felügyelet és kezelés lehetőséget.
  7. A Probléma altípus esetében válassza a Frissítés, a Skálázás vagy az Termékváltozat módosításai lehetőséget.

Gyakori kérdések

  • Milyen információkra van szükségünk a migrálási útvonal kiválasztásához?

    • Mi az API Management-példány hálózati módja?
    • Egyéni tartományok vannak konfigurálva?
    • Tűzfal van benne?
    • Vannak ismert függőségek, amelyeket az érintett IP-címek felső vagy alsóbb rétege vett fel?
    • Többrégiós telepítésről van szó?
    • Módosíthatjuk a meglévő példányt, vagy párhuzamos telepítésre van szükség?
    • Lehet állásidő?
    • Elvégezhető a migrálás üzemszüneti órákban?

  • Mik a migrálás előfeltételei?

    A virtuális hálózatba injektált példányok esetében tekintse meg azokat az előfeltételeket, amelyeknek az előfeltételei az azonos alhálózat migrálásának és megtartásának, illetve az új alhálózatra való migrálásnak és váltásnak.

  • Leállást fog okozni a migrálás?

    Ha migrál egy virtuális hálózatba injektált példányt, és megtartja ugyanazt az alhálózati konfigurációt, az API-átjáró minimális leállása vagy leállása várható. Tekintse meg az összefoglaló táblázatot a Várt állásidő című témakörben.

    Új VIP-címre való migráláskor és váltáskor nem szabad leállni, ha az alapértelmezett gazdagépnevek használatban vannak. Kritikus fontosságú, hogy minden hálózati függőséget előre gondoskodjon, hogy az érintett API-k működőképesek legyenek. Ha azonban az egyéni tartományok használatban vannak, akkor a kiürített számításra fognak mutatni, amíg nem frissülnek, ami leállást okozhat. Bizonyos migrálási beállítások esetén engedélyezheti, hogy a migrálási beállítás 48 órán át megőrizze a régi átjárót. A régi és az új számítás egyidejű használata megkönnyíti az érvényesítést, majd igény szerint frissítheti az egyéni DNS-bejegyzéseket.

  • A forgalom tűzfalon keresztül bújtatva van. Milyen módosításokra van szükség?

    • Először is győződjön meg arról, hogy az áttelepítéshez használt alhálózat(ok) megtartják a következő konfigurációt (ezeket már konfigurálni kell, ha migrálja és megtartja az aktuális alhálózatot):
      • Szolgáltatásvégpontok engedélyezése az itt leírtak szerint
      • Az UDR (felhasználó által definiált útvonal) az ApiManagement szolgáltatáscímkéje "Internet" értékre van állítva, és nem csak a tűzfal címére
    • Az stv2 NSG-konfigurálásának követelményei változatlanok maradnak, akár tűzfallal rendelkezik, akár nem; győződjön meg arról, hogy az új alhálózat rendelkezik vele
    • Az API Management-példány aktuális IP-címtartományára hivatkozó tűzfalszabályokat frissíteni kell az új alhálózat IP-címtartományának használatához.

  • Előfordulhatnak adatok vagy konfigurációs veszteségek a migrálás során/alatt?

    stv1 a migrálás stv2 magában foglalja a számítási platform egyedüli frissítését, és a belső tárolási réteg nem változik. Ezért az áttelepítési folyamat során minden konfiguráció biztonságos. Ebbe beletartozik a rendszer által hozzárendelt felügyelt identitás is, amely ha engedélyezve van, megmarad.

  • A migrálás befejezésének és sikerességének ellenőrzése

    A migrálás akkor tekinthető teljesnek és sikeresnek, ha az Áttekintés lapon az állapot online állapotú, valamint a platformverzió vagy stv2 stv2.1. Ellenőrizze azt is, hogy a Hálózat panelen a hálózat állapota zöld színnel jelenik-e meg az összes szükséges kapcsolat esetében.

  • Elvégezhetem a migrálást a portálon?

    Igen, a virtuális hálózatokba injektált példányok a Platform migrálási paneljének használatával migrálhatók.

  • Megőrizhetem a példány IP-címét?

    Igen, a portál platformmigrálási paneljén és a REST API-ban lehetőség van az IP-cím megőrzésére.

  • Van migrálási útvonal a meglévő példány módosítása nélkül?

    Igen, szükség van egy egymás melletti migrálásra. Ez azt jelenti, hogy az aktuális példánysal párhuzamosan létrehoz egy új API Management-példányt, és átmásolja a konfigurációt az új példányba.

  • Mi történik, ha a migrálás meghiúsul?

    Ha az API Management-példány a migrálás kezdeményezése után nem jeleníti meg a platform online verzióját stv2 vagy stv2.1 állapotát, az valószínűleg meghiúsult. A szolgáltatás automatikusan vissza lesz állítva a régi példányra, és nem történik módosítás.

  • Milyen funkciók nem érhetők el a migrálás során?

    Az API-kérések a migrálás során is válaszolnak. Az infrastruktúra-konfiguráció (például egyéni tartományok, helyek és hitelesítésszolgáltatói tanúsítványok) 30 percig zárolva van.

  • Mennyi ideig tart a migrálás?

    Az új virtuális hálózat konfigurációjába való migrálás várható időtartama körülbelül 45 perc. Annak ellenőrzésére, hogy a migrálás már megtörtént-e, annak ellenőrzésére, hogy a példány állapota vissza lett-e adva az Online állapotba, és nem a Frissítésre. Tervezze meg hosszabb ideig a többrégiós üzemelő példányokat, és olyan forgatókönyvekben, amelyekben az alhálózat többszöri módosítása is szerepel.

  • Van mód a virtuális hálózat konfigurációjának ellenőrzésére a migrálási kísérlet előtt?

    Ha az áttelepítés során módosítani szeretné az alhálózatot, üzembe helyezhet egy új API Management-példányt a tényleges migráláshoz használni kívánt virtuális hálózattal, alhálózattal és (nem kötelező) IP-címerőforrással. Az üzembe helyezés befejezése után lépjen a Hálózat állapot lapjára, és ellenőrizze, hogy minden végpontkapcsolat állapota zöld-e. Ha igen, eltávolíthatja ezt az új API Management-példányt, és folytathatja a valódi migrálást az eredeti stv1üzemeltetett szolgáltatással.

  • Szükség esetén visszaállíthatom a migrálást?

    Ha a migrálási folyamat során hiba történik, a példány automatikusan visszatér a stv1 platformra. A szolgáltatás sikeres migrálása után azonban nem lehet visszatérni a stv1 platformra.

  • Szükség van módosításra az egyéni tartomány-/privát DNS-zónákban?

    Ha a virtuális hálózatba injektált példányok belső módban lesznek, és új VIP-ra váltanak, a privát DNS-zónákat frissítenie kell az áttelepítés után beszerzett új virtuális hálózat IP-címére. Ügyeljen a nem Azure-beli DNS-zónák frissítésére is (például a helyszíni DNS-kiszolgálók az API Management privát IP-címére mutatnak). Külső módban azonban az áttelepítési folyamat automatikusan frissíti az alapértelmezett tartományokat, ha használatban van.

  • Az stv1-példányom több Azure-régióban (többrégióban) van üzembe helyezve. Hogyan frissítés az stv2-re?

    A többrégiós üzemelő példányok több felügyelt átjárót tartalmaznak, amelyeket más helyeken helyeznek üzembe. Amikor a portál platformmigrálási paneljén migrál, az egyes helyeket külön-külön migrálja. Az Stv2 REST API-ba való migrálás egy hívás minden helyét áttelepíti. A példány csak akkor tekinthető áttelepítettnek az új platformra, ha az összes hely áttelepítése történik. A migrálási folyamat során az összes regionális átjáró továbbra is normálisan működik.

  • Frissíthetem az stv1-példányomat ugyanarra az alhálózatra?

    Igen, használja a platform migrálási paneljét a portálon, vagy használja a Migrálást az stv2 REST API-hoz.

  • Tesztelhetem az új átjárót egy új alhálózaton az élő forgalom váltása előtt?

    • Amikor új alhálózatra migrál, alapértelmezés szerint a régi és az új felügyelt átjárók 15 percig élnek együtt, ami egy kis időkeret az üzembe helyezés ellenőrzéséhez. Engedélyezheti, hogy a migrálási beállítás 48 órán át megőrizze a régi átjárót. Ez a módosítás aktív marad a régi és az új felügyelt átjárók számára a forgalom fogadása és az ellenőrzés megkönnyítése érdekében.
    • Az áttelepítési folyamat automatikusan frissíti az alapértelmezett tartományneveket, és használat esetén a forgalom azonnal az új átjárókra kerül.
    • Ha egyéni tartománynevek vannak használatban, előfordulhat, hogy a megfelelő DNS-rekordokat frissíteni kell az új IP-címmel, ha nem CNAME-t használ. Az ügyfelek a váltás előtt frissíthetik a gazdagépfájlt az új API Management IP-címre, és ellenőrizhetik a példányt. Az érvényesítési folyamat során a régi átjáró továbbra is az élő forgalmat szolgálja ki.

  • Vannak megfontolandó szempontok az alapértelmezett tartománynév új alhálózatban való használatakor?

    Azok a példányok, amelyek az alapértelmezett DNS-nevet külső módban használják, az áttelepítési folyamat automatikusan bekapcsolja a DNS-t. Emellett az áttelepítési folyamat automatikusan frissíti a felügyeleti végpontot, amely mindig az alapértelmezett tartománynevet használja. Mivel a váltás egy sikeres migrálás során azonnal megtörténik, az új példány azonnal megkezdi a forgalom fogadását, és kritikus fontosságú, hogy a hálózatkezelési korlátozások/függőségek előre gondoskodjanak arról, hogy az érintett API-k ne legyenek elérhetők.

  • Mit érdemes figyelembe vennünk a saját üzemeltetésű átjárók esetében?

    Nem kell semmit tennie a saját üzemeltetésű átjárókban. Csak az Azure-ban futó API Management-példányokat kell migrálnia, amelyeket a platform kivonása stv1 érint. Vegye figyelembe, hogy az API Management-példány konfigurációs végpontjának új IP-címe lehet, és az IP-címre rögzített hálózati korlátozásokat frissíteni kell.

  • Hogyan érinti a fejlesztői portált a migrálás?

    Nincs hatással a fejlesztői portálra. Egyéni tartományok használata esetén a DNS-rekordot frissíteni kell a tényleges IP-címmel, a migrálás után. Ha azonban az alapértelmezett tartományok használatban vannak, azok automatikusan frissülnek a sikeres migráláskor. A migrálás során nincs állásidő a fejlesztői portálon.

  • Van bármilyen hatása a költségekre, miután migráltunk az stv2-be?

    A számlázási modell változatlan stv2 marad, és a migrálás során és után nem merül fel további költség.

  • Milyen RBAC-engedélyek szükségesek az stv1 stv2 migrálásához?

    A migrálást végző felhasználónak/folyamatnak írási hozzáférésre lenne szüksége az API Management-példányhoz. Emellett a következő két engedélyre van szükség:

    • Microsoft.Network/virtualNetworks/alhálózatok/csatlakozás/művelet
    • Microsoft.Network/publicIPAddresses/join/action

Kapcsolódó tartalom