Freigeben über

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

  • Artikel

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:

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 unter „Geografien“ gespeichert.

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 müssen Kunden 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.

Voraussetzungen

  • Falls Sie keine API Management-Dienstinstanz erstellt haben, finden Sie weitere Informationen unter Erstellen einer API Management-Dienstinstanz. Wählen Sie die Dienstebene „Premium“ aus.
  • Wenn Ihre API-Verwaltungsinstanz in einem virtuellen Netzwerk bereitgestellt wird, stellen Sie sicher, dass Sie ein virtuelles Netzwerk und ein Subnetz am Speicherort einrichten, den Sie hinzufügen möchten, und innerhalb desselben Abonnements. Siehe 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. Wählen Sie mindestens eine Verfügbarkeitszone aus.
  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 Subnetzes und der öffentlichen IP-Adresse (wenn Verfügbarkeitszonen aktiviert werden).
  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 Management-Dienstregion

  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. Obwohl Sie in verschiedenen Regionen Azure API Management-Gateways konfiguriert haben, leitet das API-Gateway Anforderungen dennoch an denselben Back-End-Dienst weiter, der nur in einer Region bereitgestellt wird. In diesem Fall wird der Leistungsgewinn nur durch Antworten erzielt, die innerhalb von Azure API Management in einer für die Anforderung spezifischen Region zwischengespeichert werden. Die Kontaktaufnahme mit dem Back-End weltweit kann dennoch zu einer langen Wartezeit führen.

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

  1. Navigieren Sie zu Ihrer Azure API Management-Instanz, und wählen Sie im Menü auf der linken Seite APIs aus.

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

  3. Wählen Sie in der Pfeildropdownliste in Verarbeitung von eingehendem Datenverkehr die Option Code-Editor aus.

    API-Code-Editor

  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 Ihren Back-End-Diensten auch Azure Traffic Manager vorschalten, die API-Aufrufe an Traffic Manager weiterleiten und diesem das automatische Routing überlassen.

  • 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 von benutzerdefiniertem Routing an regionale API Management-Gateways

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 Azure Traffic Manager.
  2. Bei Verwendung einer benutzerdefinierten Domäne verwenden Sie sie mit Traffic Manager anstelle des API Management-Diensts.
  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:

  • Nach dem Hinzufügen einer neuen Region, damit sie deaktiviert bleibt, 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, mit dem Befehl az apim update in der Azure CLI, mit dem Azure PowerShell-Cmdlet set-azapimanagement oder mit anderen Azure-Tools festlegen.

Hinweis

Sie können das Routing an ein regionales Gateway nur deaktivieren, wenn Sie das Standardrouting von API Management verwenden, nicht eine benutzerdefinierte Routinglösung.

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

    Die Aktualisierung 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 Netzwerksicherheitsgruppen-Regeln für ein virtuelles Netzwerk in einer hinzugefügten Region, entsprechen im Allgemeinen denen für ein Netzwerk in der primären Region.
  • Virtuelle Netzwerke in den verschiedenen Regionen müssen nicht per Peering verknüpft werden.

Wichtig

Bei der Konfiguration im internen VNet-Modus muss jedes regionale Gateway auch über ausgehende Verbindungen an Port 1433 mit der Azure SQL-Datenbank-Instanz verfügen, die für Ihre API Management-Instanz konfiguriert ist, die sich nur in der primären Region befindet. Stellen Sie sicher, dass Sie Konnektivität mit dem FQDN oder der IP-Adresse dieser Azure SQL-Datenbank-Instanz in allen Routen und Firewallregeln zulassen, die Sie für Netzwerke in Ihren sekundären Regionen konfigurieren. Das Azure SQL-Diensttag 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.

    • External VNet-Modus: Die öffentlichen IP-Adressen müssen außerdem öffentlichen HTTP-Datenverkehr an die API-Gateways leiten.

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

Routing

  • Externer VNet-Modus: Das Routing des öffentlichen HTTP-Datenverkehrs an die regionalen Gateways erfolgt automatisch, genau wie bei einer nicht vernetzten API Management-Instanz.

  • Interner VNet-Modus: Privater HTTP-Datenverkehr wird nicht standardmäßig an die regionalen Gateways weitergeleitet, bzw. für ihn wird nicht standardmäßig ein Lastenausgleich ausgeführt. 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.

Nächste Schritte