Migrieren einer in ein VNet eingefügten API Management-Instanz, die auf der stv1-Plattform gehostet wird, zu stv2

GILT FÜR: Entwickler | Premium

Dieser Artikel enthält Schritte zum direkten Migrieren einer API Management-Instanz, die auf der stv1-Computeplattform gehostet wird, zur stv2-Plattform, wenn die Instanz in ein externes oder internes VNet eingefügt (bzw. in einem solchen bereitgestellt) wird. Migrieren Sie für dieses Szenario Ihre Instanz, indem Sie die VNet-Konfigurationseinstellungen aktualisieren. Ob dies erforderlich ist, erfahren Sie hier.

Falls Sie eine nicht in ein VNet eingefügte API Management-Instanz migrieren müssen, die auf der stv1-Plattform gehostet wird, lesen Sie Migrieren einer nicht in ein VNet eingefügten API Management-Instanz zur stv2-Plattform.

Wichtig

Unterstützung für API Management-Instanzen, die auf der Plattform stv1 gehostet werden, wird am 31. August 2024 eingestellt. Wenn Sie Instanzen auf der stv1-Plattform gehostet haben, migrieren Sie sie vor diesem Datum zur stv2-Plattform, um Dienstunterbrechungen zu vermeiden. Weitere Informationen

Achtung

• Die Migration Ihrer API Management-Instanz zur stv2-Plattform ist ein zeitintensiver Vorgang.
• Die VIP-Adresse Ihrer Instanz ändert sich. Nach der Migration müssen Sie alle Netzwerkabhängigkeiten einschließlich DNS, Firewallregeln und VNets aktualisieren, um die neue VIP-Adresse zu verwenden. Planen Sie Ihre Migration entsprechend.
• Die Migration zu stv2 ist nicht umkehrbar.

Was geschieht während der Migration?

Die Migration der API Management-Plattform von stv1 zu stv2 umfasst lediglich die Aktualisierung der zugrunde liegenden Computeressource und hat keine Auswirkungen auf die in der Speicherebene gespeicherte Dienst-/API-Konfiguration.

• Der Upgradeprozess umfasst das Erstellen einer neuen Computeressource parallel zur alten Computeressource. Dies kann bis zu 45 Minuten dauern.
• Der API Management-Status im Azure-Portal lautet Wird aktualisiert.
• Die VIP-Adresse der Instanz ändert sich (bzw. im Falle einer Bereitstellung mit mehreren Regionen die VIP-Adressen).
• Azure verwaltet das Verwaltungsendpunkt-DNS und aktualisiert die neue Computeressource bei einer erfolgreichen Migration sofort.
• Bei Verwendung einer benutzerdefinierten Domäne verweist das Gateway-DNS weiterhin auf die alte Computeressource.
• Wird kein benutzerdefiniertes DNS verwendet, verweisen das Gateway- und das Portal-DNS sofort auf die neue Computeressource.
• Für eine Instanz im internen VNet-Modus verwaltet der Kunde das DNS, sodass die DNS-Einträge weiterhin auf die alte Computeressource verweisen, bis sie vom Kunden aktualisiert wurden.
• Das DNS verweist entweder auf die neue oder die alte Computeressource, daher tritt keine Downtime für die APIs auf.
• Firewallregeln müssen geändert werden (sofern vorhanden), damit das neue Computesubnetz die Back-Ends erreichen kann.
• Nach erfolgreicher Migration wird der alte Compute standardmäßig nach ungefähr 15 Minuten automatisch außer Betrieb genommen. Sie können eine Migrationseinstellung aktivieren, um das alte Gateway 48 Stunden lang beizubehalten. Die Option für die 48-stündige Verzögerung ist nur für in das VNet eingefügte Dienste verfügbar.

Voraussetzungen

• Die API Management-Instanz, die auf der stv1-Computeplattform gehostet wird. Informationen zur Bestätigung, dass Ihre Instanz auf der stv1-Plattform gehostet wird, finden Sie unter Wie finde ich heraus, welche Plattform meine API Management-Instanz hostet?. Die Instanz muss in ein virtuelles Netzwerk eingefügt werden.

• Ein neues Subnetz im aktuellen virtuellen Netzwerk in jeder Region, in der die API Management-Instanz bereitgestellt wird. (Richten Sie alternativ ein Subnetz in einem anderen virtuellen Netzwerk in der gleichen Region und im gleichen Abonnement wie Ihre API Management-Instanz ein.) Eine Netzwerksicherheitsgruppe muss an das Subnetz angefügt werden, und NSG-Regeln für API Management müssen konfiguriert werden.

• (Optional) Eine neue Standard-SKU-Ressource mit öffentlicher IPv4-Adresse in der gleichen Region (bzw. in den gleichen Regionen) und im gleichen Abonnement wie Ihre API Management-Instanz. Details finden Sie unter Voraussetzungen für Netzwerkverbindungen.

  Wichtig

  • Ab Mai 2024 wird keine öffentliche IP-Adresse mehr benötigt, wenn eine API-Verwaltungsinstanz in einem VNet im internen Modus bereitgestellt (injiziert) oder die interne VNet-Konfiguration zu einem neuen Subnetz migriert wird. Im externen VNet-Modus ist die Angabe einer öffentlichen IP-Adresse optional; wenn Sie keine angeben, wird automatisch eine von Azure verwaltete öffentliche IP-Adresse konfiguriert. Im externen VNet-Modus wird die öffentliche IP-Adresse für Runtime-API-Datenverkehr verwendet.
  • Wenn Sie Zonenredundanz für eine API-Verwaltungsinstanz in einem VNet im internen oder externen Modus aktivieren, müssen Sie eine neue öffentliche IP-Adresse angeben.

Auslösen der Migration einer in ein Netzwerk eingefügten API Management-Instanz

Lösen Sie die Migration einer in ein Netzwerk eingefügten API Management-Instanz zur stv2-Plattform aus, indem Sie in jeder Region, in der die Instanz bereitgestellt wird, die vorhandene Netzwerkkonfiguration aktualisieren, um die neuen Netzwerkeinstellungen zu verwenden. Nach Abschluss dieses Updates können Sie als optionalen Schritt wieder zu den ursprünglichen VNets und Subnetzen migrieren, die Sie verwendet haben.

Sie können auch zur stv2-Plattform migrieren, indem Sie Zonenredundanz aktivieren (verfügbar im Tarif Premium).

Wichtig

Die VIP-Adresse(n) Ihrer API Management-Instanz werden sich ändern. API-Anforderungen bleiben jedoch während der Migration reaktionsfähig. Die Infrastrukturkonfiguration (z. B. benutzerdefinierte Domänen, Standorte und Zertifizierungsstellenzertifikate) wird 30 Minuten lang gesperrt. Nach der Migration müssen alle Netzwerkabhängigkeiten (einschließlich DNS, Firewallregeln und mittels Peering verknüpfter VNets) aktualisiert werden, um die neue(n) VIP-Adresse(n) zu verwenden.

Aktualisieren der Netzwerkkonfiguration

Sie können das Azure-Portal verwenden, um zu einem neuen Subnetz im selben oder einem anderen VNet zu migrieren. Die folgende Abbildung zeigt eine allgemeine Übersicht über die Abläufe bei der Migration zu einem neuen Subnetz:

Portal

1. Navigieren Sie im Azure-Portal zu Ihrer API Management-Instanz.

2. Wählen Sie im linken Menü unter Einstellungen die Option Plattformmigration aus.

3. Überprüfen Sie auf der Seite PlattformmigrationSchritt 1 die Migrationsanforderungen und -voraussetzungen.

4. Wählen Sie in Schritt 2 die Migrationseinstellungen aus:

   • Wählen Sie einen zu migrierenden Speicherort aus.

   • Wählen Sie das virtuelle Netzwerk, Subnetz und optional die Öffentliche IP-Adresse aus, zu der Sie migrieren möchten.

     

   • Wählen Sie entweder schnellstmöglich oder Im neuen Subnetz bleiben und stv1-Compute 48 Stunden nach der Migration behalten. Wenn Sie das vorherigen Auswählen auswählen, wird der Compute stv1 ca. 15 Minuten nach der Migration gelöscht, sodass Sie bei Bedarf direkt mit der Migration zum ursprünglichen Subnetz fortfahren können. Wenn Sie letzteres auswählen, wird der stv1-Compute 48 Stunden lang aufbewahrt. Sie können diesen Zeitraum verwenden, um Ihre Netzwerkeinstellungen und die Konnektivität zu überprüfen.

     

5. Bestätigen Sie in Schritt 3, dass Sie migrieren möchten, und wählen Sie Migrieren aus. Der Status Ihrer API-Verwaltungsinstanz ändert sich in Aktualisieren. Der Migrationsprozess dauert ca. 45 Minuten. Wenn sich der Status in Online ändert, ist die Migration abgeschlossen.

Wenn Ihre API-Verwaltungsinstanz in mehreren Regionen bereitgestellt wird, wiederholen Sie die vorherigen Schritte, um die Migration der VNet-Einstellungen für die verbleibenden Speicherorte Ihrer Instanz fortzusetzen.

(Optional) Migrieren zum ursprünglichen Subnetz

Sie können optional wieder zum ursprünglichen Subnetz migrieren, das Sie vor der Migration zur stv2-Plattform in den einzelnen Regionen verwendet haben. Aktualisieren Sie hierzu erneut die VNet-Konfiguration, und geben Sie dieses Mal in jeder Region das ursprüngliche VNet und Subnetz an. Wie bei der vorherigen Migration sollten Sie sich auf einen Vorgang mit langer Ausführungsdauer einstellen und damit rechnen, dass sich die VIP-Adresse ändert.

Die folgende Abbildung zeigt eine allgemeine Übersicht über die Abläufe bei der Migration zum ursprünglichen Subnetz:

Wichtig

Falls das VNet und das Subnetz gesperrt sind (weil dort andere, auf der stv1-Plattform basierende API Management-Instanzen bereitgestellt werden) oder die Ressourcengruppe, in der das ursprüngliche VNet bereitgestellt wird, über eine Ressourcensperre verfügt, muss die Sperre vor der Migration zum ursprünglichen Subnetz entfernt werden. Warten Sie, bis das Entfernen der Sperre abgeschlossen ist, bevor Sie versuchen, die Migration zum ursprünglichen Subnetz durchzuführen. Weitere Informationen

Zusätzliche Voraussetzungen

• Das entsperrte ursprüngliche Subnetz in jeder Region, in der die API Management-Instanz bereitgestellt wird. Eine Netzwerksicherheitsgruppe muss an das Subnetz angefügt werden, und NSG-Regeln für API Management müssen konfiguriert werden.

• (Optional) Eine neue Standard-SKU-Ressource mit öffentlicher IPv4-Adresse in der gleichen Region (bzw. in den gleichen Regionen) und im gleichen Abonnement wie Ihre API Management-Instanz.

  Wichtig

  • Ab Mai 2024 wird keine öffentliche IP-Adresse mehr benötigt, wenn eine API-Verwaltungsinstanz in einem VNet im internen Modus bereitgestellt (injiziert) oder die interne VNet-Konfiguration zu einem neuen Subnetz migriert wird. Im externen VNet-Modus ist die Angabe einer öffentlichen IP-Adresse optional; wenn Sie keine angeben, wird automatisch eine von Azure verwaltete öffentliche IP-Adresse konfiguriert. Im externen VNet-Modus wird die öffentliche IP-Adresse für Runtime-API-Datenverkehr verwendet.
  • Wenn Sie Zonenredundanz für eine API-Verwaltungsinstanz in einem VNet im internen oder externen Modus aktivieren, müssen Sie eine neue öffentliche IP-Adresse angeben.

Aktualisieren von VNet-Konfigurationen

1. Navigieren Sie im Portal zu Ihrem ursprünglichen VNet.
2. Wählen Sie im Menü auf der linken Seite Subnetze und dann das ursprüngliche Subnetz aus.
3. Überprüfen Sie, ob die ursprünglichen IP-Adressen von API Management freigegeben wurden. Notieren Sie sich unter Verfügbare IP-Adressen die Anzahl der im Subnetz verfügbaren IP-Adressen. Alle Adressen (mit Ausnahme von reservierten Azure-Adressen) sollten verfügbar sein. Warten Sie bei Bedarf, bis IP-Adressen freigegeben werden.
4. Navigieren Sie zu Ihrer API Management-Instanz.
5. Wählen Sie im linken Menü unter Netzwerkvirtuelles Netzwerk aus.
6. Wählen Sie die Netzwerkverbindung an dem Standort aus, den Sie aktualisieren möchten.
7. Wählen Sie das ursprüngliche VNet-Netzwerk und das Subnetz aus. Wählen Sie optional eine neue öffentliche IP aus. Wählen Sie Übernehmen.
8. Wenn Ihre API-Verwaltungsinstanz in mehreren Regionen bereitgestellt wird, konfigurieren Sie weiterhin die VNet-Einstellungen für die verbleibenden Speicherorte Ihrer Instanz.
9. Wählen Sie auf der oberen Navigationsleiste die Option Speichern aus.

Nachdem Sie die VNet-Konfiguration aktualisiert haben, ändert sich der Status Ihrer API Management-Instanz in Wird aktualisiert. Der Migrationsprozess dauert ca. 45 Minuten. Wenn sich der Status in Online ändert, ist die Migration abgeschlossen.

Überprüfen der Migration

Überprüfen Sie die Plattformversion Ihrer API Management-Instanz, wenn sich der Status in Online ändert, um sich zu vergewissern, dass die Migration erfolgreich war. Nach erfolgreicher Migration lautet der Wert stv2 oder stv2.1.

Bestätigen der Einstellungen vor dem endgültigen Löschen des alten Gateways

Nach erfolgreicher Migration einer in ein VNet eingefügten API Management-Instanz sind die alte und die während der Migration erstellte neue Computeressource etwa 15 Minuten lang parallel vorhanden. In diesem kurzen Zeitfenster können Sie die Bereitstellung überprüfen und sich vergewissern, dass Ihre Anwendungen erwartungsgemäß funktionieren. (Dieses Zeitfenster kann auf bis zu 48 Stunden verlängert werden. Wenden Sie sich hierzu im Voraus an den Azure-Support.)

• Während dieses Zeitfensters ist sowohl das alte als auch das neue Gateway online und verarbeitet Datenverkehr. Diese Zeit wird Ihnen nicht in Rechnung gestellt.
• Nutzen Sie dieses Zeitfenster, um etwaige Netzwerkabhängigkeiten einschließlich DNS, Firewallregeln und VNets für die Verwendung der neuen VIP-Adresse und des neuen Subnetzadressraums zu aktualisieren.
• Überprüfen Sie außerdem den Netzwerkstatus der aktualisierten Instanz, um die Konnektivität der Instanz mit ihren Abhängigkeiten sicherzustellen. Wählen Sie im Portal im linken Menü unter Bereitstellung und Infrastruktur die Option Netzwerk>Netzwerkstatus aus. Aktualisieren Sie bei Bedarf Einstellungen wie UDRs und NSG-Regeln.
• Am Ende des Zeitfensters wird das alte Gateway außer Betrieb gesetzt, und Datenverkehr wird nur noch vom neuen Gateway verarbeitet.

Automatisches Zurücksetzen, wenn die Migration fehlschlägt

Wenn während des Migrationsprozesses ein Fehler auftritt, wird die Instanz automatisch auf die stv1-Plattform zurückgesetzt. Nach erfolgreichem Abschluss der Migration (für die Plattformversion der Instanz wird stv2 oder stv2.1 und für den Status wird Online angezeigt) ist kein Rollback zur stv1-Plattform mehr möglich.

Im Falle einer nicht erfolgreichen Migration erhalten Sie Hilfe vom Azure-Support.

Wenn Sie die Möglichkeit benötigen, ein manuelles Rollback auszuführen, empfiehlt es sich, eine neue stv2-Instanz parallel zu Ihrer ursprünglichen API Management-Instanz bereitzustellen.

Hilfe und Support

Wir helfen Ihnen bei der Migration zur stv2-Plattform mit minimalen Unterbrechungen für Ihre Dienste.

Bei Fragen können Sie schnelle Antworten von Communityexperten auf Microsoft Q&A erhalten. Wenn Sie über einen Supportplan verfügen und technische Hilfe benötigen, erstellen Sie eine Supportanfrage.

1. Geben Sie als Zusammenfassung eine Beschreibung Ihres Problems ein, z. B. „stv1 Einstellung“.
2. Wählen Sie unter Problemtyp die Option Technisch aus.
3. Wählen Sie unter Abonnement Ihr Abonnement aus.
4. Wählen Sie unter Dienst die Option Meine Dienste und dann API Management-Dienst aus.
5. Wählen Sie unter Ressource die Azure-Ressource aus, für die Sie eine Supportanfrage erstellen.
6. Wählen Sie als Problemtyp die Option Administration und Verwaltung aus.
7. Wählen Sie als Problemuntertyp die Option Upgrade, Skalierung oder SKU-Änderungen aus.

Häufig gestellte Fragen

• Welche Informationen benötigen wir für die Auswahl eines Migrationspfads?

  • Wie lautet der Netzwerkmodus der API Management-Instanz?
  • Sind benutzerdefinierte Domänen konfiguriert?
  • Ist eine Firewall beteiligt?
  • Gibt es bekannte Upstream- oder Downstreamabhängigkeiten für die beteiligten IP-Adressen?
  • Handelt es sich um eine Bereitstellung in mehreren Regionen?
  • Können wir die vorhandene Instanz ändern, oder ist ein paralleles Setup erforderlich?
  • Darf es Downtime geben?
  • Kann die Migration außerhalb der Geschäftszeiten durchgeführt werden?

• Wie lauten die Voraussetzungen für die Migration?

  Für in VNet eingefügte Instanzen benötigen Sie ein neues Subnetz zum Migrieren in jedes VNet (entweder externer oder interner Modus). Geben Sie im externen Modus optional eine öffentliche IP-Adressressource an. An das Subnetz muss eine NSG angefügt sein, die den Regeln für die stv2-Plattform folgt, wie hier beschrieben.

• Verursacht die Migration Downtime?

  Da das alte Gateway erst endgültig gelöscht wird, wenn die neue Computeressource fehlerfrei und online ist, sollte es bei Verwendung von Standardhostnamen keine Downtime geben. Es ist wichtig, dass alle Netzwerkabhängigkeiten vorab behandelt werden, damit die betroffenen APIs funktionsfähig sind. Wenn jedoch benutzerdefinierte Domänen verwendet werden, verweisen sie auf die gelöschte Berechnung, bis sie aktualisiert werden, was zu einer Ausfallzeit führen kann. Alternativ können Sie eine Migrationseinstellung aktivieren, um das alte Gateway 48 Stunden lang beizubehalten. Wenn die alte und die neue Compute koexistieren, wird die Überprüfung erleichtert, und Sie können dann die benutzerdefinierten DNS-Einträge bei Bedarf aktualisieren.

• Für meinen Datenverkehr wird Tunneling durch eine Firewall erzwungen. Welche Änderungen sind erforderlich?

  • Stellen Sie zunächst sicher, dass die neuen Subnetze, die Sie für die Migration erstellt haben, die folgende Konfiguration behalten (die Komponenten sollten bereits in Ihrem aktuellen Subnetz konfiguriert sein):
    • Aktivieren Sie Dienstendpunkte wie hier beschrieben.
    • Für die benutzerdefinierte Route (User-Defined Route, UDR) ist der Hop des ApiManagement-Diensttags auf „Internet“ und nicht nur auf Ihre Firewalladresse festgelegt.
  • Die Anforderungen für die NSG-Konfiguration für stv2 bleiben unverändert, unabhängig davon, ob Sie über eine Firewall verfügen oder nicht. Stellen Sie jedoch sicher, dass das neue Subnetz darüber verfügt.
  • Firewallregeln, die sich auf den aktuellen IP-Adressbereich der API Management-Instanz beziehen, müssen aktualisiert werden, damit sie den IP-Adressbereich Ihres neuen Subnetzes verwenden.

• Kann es durch die bzw. während der Migration zu Daten- oder Konfigurationsverlusten kommen?

  Bei der Migration von stv1 zu stv2 wird nur die Computeplattform aktualisiert. Die interne Speicherebene wird nicht geändert. Daher ist die gesamte Konfiguration während des Migrationsprozesses sicher. Somit bleibt auch die systemseitig zugewiesene verwaltete Identität erhalten (sofern aktiviert).

• Wie kann ich bestätigen, dass die Migration abgeschlossen ist und erfolgreich war?

  Die Migration gilt als abgeschlossen und erfolgreich, wenn der Status auf der Seite ÜbersichtOnline zusammen mit der Plattformversion gelesen wird, die entweder stv2 oder stv2.1 ist. Überprüfen Sie außerdem, ob der Netzwerkstatus auf dem Blatt Netzwerk für alle erforderlichen Verbindungen grün angezeigt wird.

• Kann ich die Migration über das Portal durchführen?

  Ja. In ein VNet eingefügte Instanzen können durch Ändern der Subnetzkonfigurationen auf dem Blatt Plattformmigration migriert werden.

• Kann ich die IP-Adresse der Instanz beibehalten?

  Derzeit gibt es keine Möglichkeit, die IP-Adresse beizubehalten, wenn Ihre Instanz in ein VNet eingefügt wird.

• Gibt es einen Migrationspfad, ohne dass die vorhandene Instanz geändert werden muss?

  Ja. Hierzu ist eine parallele Migration erforderlich. Das bedeutet, dass Sie parallel zu Ihrer aktuellen Instanz eine neue API Management-Instanz erstellen und die Konfiguration in die neue Instanz kopieren.

• Was passiert, wenn die Migration nicht erfolgreich abgeschlossen werden kann?

  Wenn für Ihre API Management-Instanz nicht die Plattformversion stv2 oder stv2.1 und nicht der Status Online anzeigt werden, nachdem Sie die Migration initiiert haben, war sie wahrscheinlich nicht erfolgreich. Ihr Dienst wird automatisch auf die alte Instanz zurückgesetzt, und es werden keine Änderungen vorgenommen.

• Welche Funktionalität ist während der Migration nicht verfügbar?

  API-Anforderungen bleiben während der Migration reaktionsfähig. Die Infrastrukturkonfiguration (z. B. benutzerdefinierte Domänen, Standorte und Zertifizierungsstellenzertifikate) wird 30 Minuten lang gesperrt. Nach der Migration müssen Sie alle Netzwerkabhängigkeiten einschließlich DNS, Firewallregeln und VNets aktualisieren, um die neue VIP-Adresse zu verwenden.

• Wie lange dauert die Migration?

  Eine Migration zu einer neuen VNet-Konfiguration dauert voraussichtlich etwa 45 Minuten. Überprüfen Sie, ob der Status Ihrer Instanz wieder Online und nicht mehr Wird aktualisiert lautet, um zu ermitteln, ob die Migration bereits ausgeführt wurde.

• Gibt es eine Möglichkeit, die VNet-Konfiguration vor einer Migration zu überprüfen?

  Sie können eine neue API Management-Instanz mit dem neuen VNet, dem neuen Subnetz und (optional) neuen IP-Adressressourcen bereitstellen, die Sie für die tatsächliche Migration verwenden. Navigieren Sie nach Abschluss der Bereitstellung zur Seite Netzwerkstatus, und überprüfen Sie, ob der Status für alle Endpunktverbindungen grün ist. Falls ja, können Sie diese neue API Management-Instanz entfernen und mit der tatsächlichen Migration mit Ihrem ursprünglichen, auf stv1 gehosteten Dienst fortfahren.

• Kann ich bei Bedarf ein Rollback für die Migration ausführen?

  Wenn während des Migrationsprozesses ein Fehler auftritt, wird automatisch ein Rollback der Instanz auf die stv1-Plattform ausgeführt. Nach erfolgreicher Migration des Diensts können Sie jedoch kein Rollback mehr auf die stv1-Plattform ausführen.

  Nach der erfolgreichen Migration eines in ein VNet eingefügten Diensts gibt es ein kurzes Zeitfenster, in dem das alte Gateway weiterhin Datenverkehr verarbeitet und Sie Ihre Netzwerkeinstellungen bestätigen können. Weitere Informationen finden Sie unter Bestätigen der Einstellungen vor dem endgültigen Löschen des alten Gateways.

• Sind Änderungen an benutzerdefinierten Domänen/privaten DNS-Zonen erforderlich?

  Bei in ein VNet eingefügten Instanzen im internen Modus müssen die privaten DNS-Zonen auf die neue VNet-IP-Adresse aktualisiert werden, die nach der Migration bezogen wurde. Achten Sie darauf, auch DNS-Zonen zu aktualisieren, die keine Azure DNS-Zonen sind (z. B. Ihre lokalen DNS-Server, die auf die private IP-Adresse von API Management verweisen). Im externen Modus aktualisiert der Migrationsprozess jedoch automatisch die Standarddomänen, sofern sie verwendet werden.

• Meine stv1-Instanz wird in mehreren Azure-Regionen bereitgestellt. Wie führe ich ein Upgrade auf stv2 aus?

  Bereitstellungen in mehreren Regionen umfassen mehr verwaltete Gateways, die an anderen Standorten bereitgestellt werden. Migrieren Sie jeden Standort separat, indem Sie die entsprechenden Netzwerkeinstellungen aktualisieren , z. B. mithilfe des Blatts Plattformmigration. Die Instanz wird nur dann als zur neuen Plattform migriert betrachtet, wenn alle Standorte migriert wurden. Alle regionalen Gateways werden während des gesamten Migrationsprozesses weiterhin normal ausgeführt.

• Kann ich meine stv1-Instanz auf dasselbe Subnetz aktualisieren?

  • Sie können die stv1-Instanz nicht in einem einzigen Durchlauf ohne Downtime zum gleichen Subnetz migrieren. Sie können Ihre migrierte Instanz jedoch optional wieder in das ursprüngliche Subnetz verschieben. Ausführlichere Informationen finden Sie hier.
  • Das alte Gateway braucht zwischen 15 und 45 Minuten, um das Subnetz zu entfernen, damit Sie das Verschieben initiieren können. Sie können jedoch eine Migrationseinstellung aktivieren, um das alte Gateway 48 Stunden lang beizubehalten.
  • Stellen Sie sicher, dass das Netzwerk des alten Subnetzes für NSG und Firewall für stv2-Abhängigkeiten aktualisiert wird.
  • Die Zuweisung von Subnetz-IP-Adressen ist nicht deterministisch. Daher kann sich die ursprüngliche ILB-IP-Adresse (eingehender Datenverkehr) für Bereitstellungen im internen Modus ändern, wenn Sie wieder zum ursprünglichen Subnetz migrieren. Dies würde eine DNS-Änderung erfordern, wenn Sie A-Einträge verwenden.

• Kann ich das neue Gateway vor der Umstellung des Livedatenverkehrs testen?

  • Standardmäßig sind die alten und neuen verwalteten Gateways für 15 Minuten koexistieren. Das ist ein kleines Zeitfenster, um die Bereitstellung zu überprüfen. Sie können eine Migrationseinstellung aktivieren, um das alte Gateway 48 Stunden lang beizubehalten. Diese Änderung behält die alten und die neuen verwalteten Gateways aktiv bei, um den Datenverkehr zu empfangen und die Validierung zu erleichtern.
  • Der Migrationsprozess aktualisiert automatisch die Standarddomänennamen und leitet den Datenverkehr, sofern er verwendet wird, sofort an die neuen Gateways weiter.
  • Wenn benutzerdefinierte Domänennamen verwendet werden, müssen die entsprechenden DNS-Einträge möglicherweise mit der neuen IP-Adresse aktualisiert werden, wenn kein CNAME-Eintrag verwendet wird. Kunden können ihre Hostdatei auf die neue API Management-IP-Adresse aktualisieren und die Instanz überprüfen, bevor sie die Umstellung vornehmen. Während dieses Überprüfungsprozesses verarbeitet das alte Gateway weiterhin den Livedatenverkehr.

• Gibt es Überlegungen bei der Verwendung des Standarddomänennamens?

  Bei Instanzen, die den standardmäßigen DNS-Namen im externen Modus verwenden, wird das DNS beim Migrationsprozess automatisch aktualisiert. Darüber hinaus wird der Verwaltungsendpunkt (der immer den Standarddomänennamen verwendet) automatisch durch den Migrationsprozess aktualisiert. Da die Umstellung bei einer erfolgreichen Migration sofort erfolgt, empfängt die neue Instanz sofort Datenverkehr. Es ist wichtig, dass alle Netzwerkeinschränkungen/-abhängigkeiten vorab behandelt werden, um zu verhindern, dass betroffene APIs nicht verfügbar sind.

• Was sollten wir bei selbstgehosteten Gateways berücksichtigen?

  Sie müssen für Ihre selbstgehosteten Gateways keine Schritte unternehmen. Sie müssen nur in Azure ausgeführte API Management-Instanzen migrieren, die von der Einstellung der stv1-Plattform betroffen sind. Beachten Sie, dass es u. U. eine neue IP-Adresse für den Konfigurationsendpunkt der API Management-Instanz gibt. Daher müssen alle an die IP-Adresse angehefteten Netzwerkeinschränkungen aktualisiert werden.

• Wie wirkt sich die Migration auf das Entwicklerportal aus?

  Es gibt keine Auswirkungen auf das Entwicklerportal. Wenn benutzerdefinierte Domänen verwendet werden, sollte der DNS-Eintrag nach der Migration mit der effektiven IP-Adresse aktualisiert werden. Wenn jedoch die Standarddomänen verwendet werden, werden sie bei erfolgreicher Migration automatisch aktualisiert. Während der Migration gibt es keine Downtime für das Entwicklerportal.

• Gibt es nach der Migration zu stv2 Auswirkungen auf die Kosten?

  Das Abrechnungsmodell bleibt für stv2 gleich, und während sowie nach der Migration entstehen keine weiteren Kosten.

• Welche RBAC-Berechtigungen sind für die Migration von stv1 zu stv2 erforderlich?

  Der Benutzer/Prozess, der die Migration durchführt, benötigt Schreibzugriff auf die API Management-Instanz. Außerdem werden die beiden folgenden Berechtigungen benötigt:

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

Video

Zugehöriger Inhalt

• Gewusst wie: Welche Plattform hostet meine API Management-Instanz?

• Computeplattform für Azure API Management – klassische Ebenen

• Einstellung der stv1-Plattform (August 2024)