Freigeben über

Bereitstellen einer Azure API Management-Instanz in mehreren Azure-Regionen

GILT FÜR: Premium

Azure API Management unterstützt die Bereitstellung in mehreren Regionen. Dadurch haben API-Herausgeber die Möglichkeit, regionale API-Gateways zu einer vorhandenen API Management-Instanz in einer oder mehreren unterstützten Azure-Regionen hinzuzufügen. Die Bereitstellung in mehreren Regionen trägt dazu bei, die Anforderungslatenz bei geografisch verteilten API-Nutzern zu verringern, und verbessert gleichzeitig die Dienstverfügbarkeit, wenn eine Region offline geht.

Konfigurieren Sie beim Hinzufügen einer Region Folgendes:

  • Die Anzahl der Skalierungseinheiten, die von dieser Region gehostet werden

  • Verfügbarkeitszonen, wenn diese Region sie unterstützt. Standardmäßig konfiguriert die API-Verwaltung automatisch Verfügbarkeitszonen für die hinzugefügte Region, die empfohlen wird. Sie können verfügbarkeitszonen auch manuell für die hinzugefügte Region konfigurieren.

  • Einstellungen für virtuelle Netzwerke in der hinzugefügten Region, wenn das Netzwerk in den vorhandenen Regionen konfiguriert ist

Wichtig

Die Funktion zum Aktivieren des Speicherns von Kundendaten in einer einzelnen Region ist derzeit nur in der Region „Asien, Südosten“ (Singapur) des geografischen Raums „Asien-Pazifik“ verfügbar. Bei allen anderen Regionen werden Kundendaten im geografischen Raum gespeichert.

Wichtig

Änderungen an der Infrastruktur Ihres API-Verwaltungsdiensts (z. B. Konfigurieren von benutzerdefinierten Domänen, Hinzufügen von Zertifizierungsstellenzertifikaten, Skalierung, Konfiguration virtueller Netzwerke, Änderungen der Verfügbarkeitszone und Regionszufügungen) können je nach Dienstebene und Größe der Bereitstellung 15 Minuten oder länger dauern. Sie können mit einer längeren Dauer für Instanzen mit einer größeren Anzahl von Skalierungseinheiten oder einer Konfiguration mit mehreren Regionen rechnen. Laufende Änderungen an der API-Verwaltung werden sorgfältig ausgeführt, um Kapazität und Verfügbarkeit zu bewahren.

Während der Dienst aktualisiert wird, können andere Änderungen an der Dienstinfrastruktur nicht vorgenommen werden. Sie können jedoch APIs, Produkte, Richtlinien und Benutzereinstellungen konfigurieren. Der Dienst erlebt keine Ausfallzeiten des Gateways, und die API-Verwaltung wird weiterhin API-Anforderungen ohne Unterbrechung (mit Ausnahme der Entwicklerebene) dienstieren.

Informationen zur Bereitstellung in mehreren Regionen

  • Nur die Gatewaykomponente Ihrer API Management-Instanz wird in mehreren Regionen repliziert. Die Verwaltungsebene und das Entwicklerportal der Instanz werden weiterhin nur in der primären Region gehostet. Dabei handelt es sich um die Region, in der Sie den Dienst ursprünglich bereitgestellt haben.

  • Wenn Sie einen sekundären Standort für Ihre API Management-Instanz konfigurieren möchten, wenn diese in einem virtuellen Netzwerk bereitgestellt (eingefügt) wird, sollten die VNet- und Subnetzregion mit dem konfigurierten sekundären Standort übereinstimmen. Wenn Sie die Verfügbarkeitszone in der primären Region hinzufügen, entfernen oder aktivieren oder wenn Sie das Subnetz der primären Region ändern, ändert sich die VIP-Adresse Ihrer API Management-Instanz. Weitere Informationen finden Sie unter IP-Adressen von Azure API Management. Wenn Sie jedoch eine sekundäre Region hinzufügen, ändert sich die VIP der primären Region nicht, da jede Region über eine eigene private VIP verfügt.

  • Gatewaykonfigurationen wie APIs und Richtliniendefinitionen werden regelmäßig zwischen den von Ihnen hinzugefügten primären und sekundären Regionen synchronisiert. Die Verteilung von Updates an die regionalen Gateways dauert normalerweise weniger als 10 Sekunden. Die Bereitstellung in mehreren Regionen bietet Verfügbarkeit des API-Gateways in mehr als einer Region sowie Dienstverfügbarkeit, wenn eine Region offline geht.

  • Wenn API Management öffentliche HTTP-Anforderungen an den Endpunkt des Datenverkehrsmanagers empfängt (gilt für das externe VNet und die nicht vernetzten Modi von API Management), wird der Datenverkehr basierend auf der niedrigsten Wartezeit an ein regionales Gateway weitergeleitet. Dadurch kann die Wartezeit für geografisch verteilte API-Consumer verringert werden. Im internen VNet-Modus muss die Kundschaft ihre eigene Lösung konfigurieren, um Datenverkehr über die regionalen Gateways weiterzuleiten und einen Lastenausgleich für sie einzurichten. Einzelheiten finden Sie unter Überlegungen zum Netzwerkbetrieb.

  • Das Gateway in jeder Region (einschließlich der primären Region) weist einen regionalen DNS-Namen auf, der dem URL-Muster von https://<service-name>-<region>-01.regional.azure-api.netfolgt, z. B. https://contoso-westus2-01.regional.azure-api.net.

  • Wenn eine Region offline geschaltet wird, werden die API-Anforderungen automatisch unter Auslassung der fehlerhaften Region an das nächstgelegene Gateway weitergeleitet.

  • Wenn die primäre Region offline geschaltet wird, sind die Verwaltungsebene und das Entwicklerportal von API Management nicht mehr verfügbar. Sekundäre Regionen verarbeiten API-Anforderungen unter Verwendung der neuesten Gatewaykonfiguration jedoch weiterhin.

  • Wenn konfiguriert, zählen die Richtlinien Rate-Limit und Rate-limit-by-Key Anrufe separat an jedem regionalen Gateway in der Bereitstellung. Die Richtlinien aggregieren nicht alle Anrufdaten für die Instanz. Entsprechend zählen die Richtlinien azure-openai-token-limit und llm-token-limit die Tokennutzung separat an jedem regionalen Gateway in der Bereitstellung.

Voraussetzungen

Bereitstellen des API Management-Diensts in einer zusätzlichen Region

  1. Navigieren Sie im Azure-Portal zu Ihrem API Management-Dienst, und wählen Sie im Menü auf der linken Seite Standorte aus.
  2. Klicken Sie in der oberen Leiste auf + Hinzufügen.
  3. Wählen Sie in der Dropdownliste den hinzugefügten Standort aus.
  4. Wählen Sie die Anzahl der Skalierungseinheiten am Standort aus.
  5. Wenn die Region Verfügbarkeitszonen unterstützt, lassen Sie die automatische Einstellung (empfohlen) oder wählen Sie optional eine oder mehrere Zonen aus. Wenn Sie bestimmte Zonen auswählen, muss die Anzahl der ausgewählten Einheiten gleichmäßig über die Verfügbarkeitszonen verteilt werden. Wenn Sie beispielsweise drei Einheiten auswählen, müssen Sie drei Zonen auswählen, damit jede Zone eine Einheit hosten kann.
  6. Wenn die API-Verwaltungsinstanz in einem virtuellen Netzwerk bereitgestellt wird, konfigurieren Sie die Einstellungen des virtuellen Netzwerks am Standort, einschließlich des virtuellen Netzwerks, des Subnetzs und der öffentlichen IP-Adresse.
  7. Klicken Sie zur Bestätigung auf Hinzufügen.
  8. Wiederholen Sie diesen Vorgang, bis alle Standorte konfiguriert sind.
  9. Klicken Sie in der oberen Leiste auf Speichern, um den Bereitstellungsprozess zu starten.

Entfernen einer API-Verwaltungsdienstregion

  1. Navigieren Sie im Azure-Portal zu Ihrem API Management-Dienst, und wählen Sie im Menü auf der linken Seite Standorte aus.
  2. Öffnen Sie für den Standort, den Sie entfernen möchten, das Kontextmenü mit der Schaltfläche ... ganz rechts in der Tabelle. Klicken Sie auf Löschen.
  3. Bestätigen Sie den Löschvorgang, und wählen Sie Speichern aus, um die Änderungen zu übernehmen.

Weiterleiten von API-Aufrufen an regionale Back-End-Dienste

Standardmäßig leitet jede API die Anforderungen an eine einzelne Back-End-Dienst-URL weiter. Selbst wenn Sie API-Verwaltungsgateways in verschiedenen Regionen konfigurieren, leitet das API-Gateway weiterhin Anforderungen an denselben Back-End-Dienst weiter, der nur in einer Region bereitgestellt wird. In diesem Fall stammt eine verbesserte Leistung nur aus Antworten, die in der API-Verwaltung in einer regional-spezifischen Region für die Anforderung zwischengespeichert wurden. Wenn Sie das Back-End auf der ganzen Welt kontaktieren, kann dies dennoch zu einer hohen Latenz führen.

Um die geografische Verteilung Ihres Systems zu nutzen, sollten Sie Back-End-Dienste in denselben Regionen wie API-Verwaltungsinstanzen bereitstellen. Anschließend können Sie mithilfe von Richtlinien und der @(context.Deployment.Region) Eigenschaft den Datenverkehr an lokale Instanzen Ihres Back-End weiterleiten.

  1. Wechseln Sie zu Ihrer API-Verwaltungsinstanz, und wählen Sie im linken Menü APIs aus.

  2. Wählen Sie die gewünschte API aus.

  3. Wählen Sie auf der Registerkarte "Entwurf " im Abschnitt " Eingehende Verarbeitung " den Code-Editor aus.

    Ein Screenshot, der den API-Code-Editor auf der Registerkarte

  4. Verwenden Sie set-backend in Kombination mit bedingten choose-Richtlinien zum Erstellen einer ordnungsgemäßen Routingrichtlinie im Abschnitt <inbound> </inbound> der Datei.

    Die folgende XML-Datei würde z. B. für die Regionen „USA, Westen“ und „Asien, Osten“ funktionieren:

    <policies>
    <inbound>
        <base />
        <choose>
            <when condition="@("West US".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                <set-backend-service base-url="http://contoso-backend-us.com/" />
            </when>
            <when condition="@("East Asia".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                <set-backend-service base-url="http://contoso-backend-asia.com/" />
            </when>
            <otherwise>
                <set-backend-service base-url="http://contoso-backend-other.com/" />
            </otherwise>
        </choose>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Verwenden von Traffic Manager für das Routing an regionale Back-Ends

Sie können Ihre Back-End-Dienste auch mit Azure Traffic Manager anstellen, die API-Aufrufe an den Traffic Manager weiterleiten und das Routing automatisch auflösen lassen.

  • Für die Datenverkehrsverteilung und das Failover wird empfohlen, Traffic Manager mit der geografischen Routingmethode zu verwenden. Die Verwendung von Traffic Manager mit der gewichteten Routingmethode wird für API Management Back-Ends nicht empfohlen.

  • Zur Steuerung des Datenverkehrs während Wartungsvorgängen wird empfohlen, die Prioritätsroutingmethode zu verwenden.

Verwenden des benutzerdefinierten Routings für regionale API-Verwaltungsgateways

API Management leitet die Anforderungen basierend auf der geringsten Latenz an ein regionales Gateway weiter. Es ist zwar nicht möglich, diese Einstellung in API Management außer Kraft zu setzen, Sie können jedoch Ihre eigene Traffic Manager-Instanz mit benutzerdefinierten Routingregeln verwenden.

  1. Erstellen Sie Ihren eigenen Traffic Manager.
  2. Wenn Sie eine benutzerdefinierte Domäne verwenden, verwenden Sie sie mit Traffic Manager anstelle des API-Verwaltungsdiensts.
  3. Konfigurieren Sie die regionalen API Management-Endpunkte in Traffic Manager. Die regionalen Endpunkte folgen dem URL-Muster https://<service-name>-<region>-01.regional.azure-api.net, z. B. https://contoso-westus2-01.regional.azure-api.net.
  4. Konfigurieren Sie die regionalen API Management-Statusendpunkte in Traffic Manager. Die regionalen Statusendpunkte folgen dem URL-Muster https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef, z. B. https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef.
  5. Geben Sie die Routingmethode von Traffic Manager an.

Deaktivieren des Routings an ein regionales Gateway

Unter bestimmten Bedingungen müssen Sie möglicherweise das Routing zu einem der regionalen Gateways vorübergehend deaktivieren. Beispiel:

  • Nachdem Sie eine neue Region hinzugefügt haben, lassen Sie diese deaktiviert, während Sie den regionalen Back-End-Dienst konfigurieren und testen.
  • Während der regelmäßigen Back-End-Wartung in einer Region
  • Zum Umleiten des Datenverkehrs an andere Regionen während einer geplanten Notfallwiederherstellungsübung, die eine nicht verfügbare Region simuliert, oder während eines regionalen Ausfalls

Um das Routing an ein regionales Gateway in Ihrer API Management-Instanz zu deaktivieren, aktualisieren Sie den Eigenschaftswert disableGateway des Gateways auf true. Sie können den Wert mithilfe der REST-API zum Erstellen oder Aktualisieren des Diensts , dem Az apim-Updatebefehl in der Azure CLI, dem Azure PowerShell-Cmdlet "set-azapimanagement " oder anderen Azure-Tools festlegen.

Wichtig

  • Sie können die Eigenschaft nur so festlegen, dass das disableGateway Routing an ein regionales Gateway deaktiviert wird, wenn Sie das Standardrouting in der API-Verwaltung und keine benutzerdefinierte Routinglösung verwenden.
  • Sie können die Eigenschaft nicht festlegen, um das disableGateway Routing an ein regionales Gateway zu deaktivieren, wenn die API-Verwaltungsinstanz in einem virtuellen Netzwerk im internen Modus bereitgestellt wird. In diesem Fall müssen Sie Routing und Lastenausgleich für mehrere Regionen selbst verwalten.

So deaktivieren Sie ein regionales Gateway mithilfe der Azure CLI:

  1. Verwenden Sie den Befehl az apim show, um die Standorte, den Gatewaystatus und die regionalen URLs anzuzeigen, die für die API Management-Instanz konfiguriert sind.

    az apim show --name contoso --resource-group apim-hello-world-resource \
    --query "additionalLocations[].{Location:location,Disabled:disableGateway,Url:gatewayRegionalUrl}" \
    --output table

    Beispielausgabe:

    Location    Disabled    Url
----------  ----------  ------------------------------------------------------------
West US 2   True        https://contoso-westus2-01.regional.azure-api.net
West Europe True        https://contoso-westeurope-01.regional.azure-api.net

  2. Verwenden Sie den Befehl az apim update, um das Gateway an einem verfügbaren Standort zu deaktivieren, z. B. USA, Westen 2.

    az apim update --name contoso --resource-group apim-hello-world-resource \
--set additionalLocations[location="West US 2"].disableGateway=true

    Das Update kann einige Minuten dauern.

  3. Stellen Sie sicher, dass Datenverkehr, der an den regionale Gateway-URL geleitet wird, in eine andere Region umgeleitet wird.

Um das Routing an das regionale Gateway wiederherzustellen, legen Sie den Wert von disableGateway auf fest false.

Virtuelle Netzwerke

Dieser Abschnitt enthält Überlegungen zu Bereitstellungen in mehreren Regionen, wenn die API Management-Instanz in ein virtuelles Netzwerk eingefügt wird.

  • Konfigurieren Sie jedes regionale Netzwerk unabhängig. Die Konnektivitätsanforderungen, z. B. erforderliche Regeln für netzwerksicherheitsgruppen für ein virtuelles Netzwerk in einer hinzugefügten Region, sind im Allgemeinen identisch mit den Anforderungen für ein Netzwerk in der primären Region.
  • Virtuelle Netzwerke in den verschiedenen Regionen müssen nicht per Peering verknüpft werden.

Wichtig

Wenn Sie Ihre API-Verwaltungsinstanz für die Verwendung des internen virtuellen Netzwerkmodus konfigurieren, muss jedes regionale Gateway auch über ausgehende Konnektivität auf Port 1433 mit der Azure SQL-Datenbank verfügen, die für Ihre API-Verwaltungsinstanz konfiguriert ist, die sich nur in der primären Region befindet. Stellen Sie sicher, dass Sie die Konnektivität mit dem vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) oder der IP-Adresse dieser Azure SQL-Datenbank in allen Routen oder Firewallregeln zulassen, die Sie für Netzwerke in Ihren sekundären Regionen konfigurieren; Der Azure SQL-Dienstendpunkt kann in diesem Szenario nicht verwendet werden. Um den Namen der Azure SQL-Datenbank-Instanz in der primären Region zu ermitteln, wechseln Sie im Portal zur Seite Netzwerk>Netzwerkstatus Ihrer API Management-Instanz.

IP-Adressen

  • Eine öffentliche virtuelle IP-Adresse wird in jeder Region erstellt, die mit einem virtuellen Netzwerk hinzugefügt wurde. Für virtuelle Netzwerke im externen Modus oder internen Modus wird diese öffentliche IP-Adresse für den Verwaltungsdatenverkehr an Port 3443 verwendet.

    • Externer VNet-Modus: Die öffentlichen IP-Adressen sind auch erforderlich, um öffentlichen HTTP-Datenverkehr an die API-Gateways weiterzuleiten.

    • Interner VNet-Modus: Eine private IP-Adresse wird auch in jeder Region erstellt, die mit einem virtuellen Netzwerk hinzugefügt wird. Verwenden Sie diese Adressen, um innerhalb des Netzwerks eine Verbindung mit den API Management-Endpunkten in den primären und sekundären Regionen herzustellen.

Routenplanung

  • Externer VNet-Modus: Das Routing des öffentlichen HTTP-Datenverkehrs an die regionalen Gateways wird automatisch behandelt, und zwar auf die gleiche Weise wie für eine nicht netzwerkbasierte API-Verwaltungsinstanz.

  • Interner VNet-Modus: Privater HTTP-Datenverkehr wird standardmäßig nicht an die regionalen Gateways weitergeleitet oder dort lastenausgeglichen. Benutzer sind Besitzer des Routings und dafür verantwortlich, ihre eigene Lösung zur Verwaltung des Routings und des privaten Lastenausgleichs in mehreren Regionen zu nutzen.

Verwandte Inhalte

  • Last updated on