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

  • Artikel
  • 7 Minuten Lesedauer

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

  • Optionale Zonenredundanz, wenn diese Region dies unterstützt

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

Verfügbarkeit

Wichtig

Diese Funktion ist nur auf der Ebene Premium von API Management verfügbar.

Informationen zur Bereitstellung in mehreren Regionen

  • Bei der Bereitstellung in mehreren Regionen wird nur die Gatewaykomponente Ihrer API Management-Instanz 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.

  • Gatewaykonfigurationen wie APIs und Richtliniendefinitionen werden regelmäßig zwischen den von Ihnen hinzugefügten primären und sekundären Regionen synchronisiert. 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 primären Gatewayendpunkt empfängt, wird der Datenverkehr basierend auf der kürzesten Wartezeit an ein regionales Gateway weitergeleitet. Dadurch kann die Wartezeit für geografisch verteilte API-Consumer verringert werden.

  • 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 Management-Instanz in einem virtuellen Netzwerk bereitgestellt wird, müssen Sie an jedem neuen Standort, den Sie hinzufügen möchten, ein virtuelles Netzwerk, ein Subnetz und eine öffentliche IP-Adresse einrichten. 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. Wird die API Management-Instanz in einem virtuellen Netzwerk bereitgestellt, konfigurieren Sie Einstellungen für das virtuelle Netzwerk am Standort. Wählen Sie ein vorhandenes virtuelles Netzwerk, ein Subnetz und eine öffentliche IP-Adresse aus, die am Standort verfügbar sind.
  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.

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 myResourceGroup \
    --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 myResourceGroup \
--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 denen für ein Netzwerk in der primären Region.
  • Virtuelle Netzwerke in den verschiedenen Regionen müssen nicht per Peering verknüpft werden.

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 ist diese öffentliche IP-Adresse für die Verwaltung des Datenverkehrs an Port 3443erforderlich.

    • 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. Beispiellösungen umfassen Azure Application Gateway und Azure Traffic Manager.

Nächste Schritte