Udostępnij za pomocą


Wdróż wystąpienie usługi Azure API Management w wielu regionach Azure

DOTYCZY: Premium

Usługa Azure API Management obsługuje wdrażanie w wielu regionach, co umożliwia wydawcom interfejsów API dodawanie regionalnych bram interfejsu API do istniejącego wystąpienia API Management w co najmniej jednym obsługiwanym regionie świadczenia usługi Azure. Wdrożenie w wielu regionach pomaga zmniejszyć opóźnienie żądań postrzegane przez geograficznie rozproszonych użytkowników interfejsu API i zwiększa dostępność usług, jeśli jeden region przejdzie w tryb offline.

Podczas dodawania regionu należy skonfigurować:

  • Liczba jednostek skalowania, które będą hostowane w danym regionie.

  • Strefy dostępności, jeśli ten region go obsługuje. Domyślnie usługa API Management automatycznie konfiguruje strefy dostępności dla dodanego regionu, co jest zalecane. Można również ręcznie skonfigurować strefy dostępności dla dodanego regionu.

  • Ustawienia sieci wirtualnej w dodanym regionie, jeśli sieć jest skonfigurowana w istniejącym regionie lub regionach.

Ważne

Funkcja włączania przechowywania danych klientów w jednym regionie jest obecnie dostępna tylko w regionie Azja Południowo-Wschodnia (Singapur) w obszarze geograficznym Azja i Pacyfik. W przypadku wszystkich innych regionów dane klientów są przechowywane w systemie Geo.

Ważne

Zmiany w infrastrukturze usługi API Management (takie jak konfigurowanie domen niestandardowych, dodawanie certyfikatów urzędu certyfikacji, skalowanie, konfiguracja sieci wirtualnej, zmiany strefy dostępności i dodawanie regionów) mogą potrwać 15 minut lub dłużej, w zależności od warstwy usługi i rozmiaru wdrożenia. Spodziewaj się dłuższego czasu działania instancji z większą liczbą jednostek skalowania lub z konfiguracją obejmującą wiele regionów. Zmiany etapowe w usłudze API Management są wykonywane ostrożnie, aby zachować pojemność i dostępność.

Podczas aktualizowania usługi nie można wprowadzać innych zmian infrastruktury usług. Można jednak skonfigurować interfejsy API, produkty, zasady i ustawienia użytkownika. Usługa nie doświadczy przestoju bramy, a zarządzanie interfejsem API będzie nadal obsługiwać żądania bez przerwy (z wyjątkiem poziomu Deweloper).

Informacje o wdrożeniu w wielu regionach

  • Tylko komponent bramy wystąpienia usługi API Management jest replikowany w wielu regionach. Płaszczyzna zarządzania instancji i portal deweloperów są hostowane tylko w regionie podstawowym w którym pierwotnie wdrożono usługę.

  • Jeśli chcesz skonfigurować lokalizację pomocniczą dla instancji usługi API Management podczas wdrażania w sieci wirtualnej, sieć wirtualna i region podsieci powinny być zgodne z lokalizacją pomocniczą, którą konfigurujesz. Jeśli dodasz, usuniesz lub włączysz strefę dostępności w regionie podstawowym lub zmienisz podsieć regionu podstawowego, adres VIP wystąpienia usługi API Management się zmieni. Aby uzyskać więcej informacji, zobacz Adresy IP usługi Azure API Management. Jednak w przypadku dodawania regionu pomocniczego adres VIP regionu podstawowego nie zmieni się, ponieważ każdy region ma własny prywatny adres VIP.

  • Konfiguracje bramy, takie jak interfejsy API i definicje zasad, są regularnie synchronizowane między dodanymi regionami podstawowymi i pomocniczymi. Propagacja aktualizacji do bram regionalnych zwykle trwa mniej niż 10 sekund. Wdrożenie w wielu regionach zapewnia dostępność bramy interfejsu API w więcej niż jednym regionie i zapewnia dostępność usługi, jeśli jeden region przejdzie w tryb offline.

  • Kiedy usługa API Management odbiera publiczne żądania HTTP skierowane do punktu końcowego zarządcy ruchu (dotyczy zewnętrznej sieci VNet i trybów bez sieci usługi API Management), ruch jest przekierowywany do bramy regionalnej na podstawie najmniejszego opóźnienia, co może zmniejszyć opóźnienia doświadczane przez geograficznie rozproszonych użytkowników API. W wewnętrznym trybie sieci wirtualnej klienci muszą skonfigurować własne rozwiązanie do kierowania i równoważenia obciążenia ruchu między bramami regionalnymi. Aby uzyskać szczegółowe informacje, zobacz Zagadnienia dotyczące sieci.

  • Brama w każdym regionie (w tym w regionie podstawowym) ma regionalną nazwę DNS zgodną ze wzorcem adresu URL https://<service-name>-<region>-01.regional.azure-api.net, na przykład https://contoso-westus2-01.regional.azure-api.net.

  • Jeśli region stanie się niedostępny, żądania interfejsu API są automatycznie przekierowywane na najbliższą bramę, omijając ten, który przestał działać.

  • Jeśli region podstawowy jest niedostępny, warstwa zarządzania API Management i portal deweloperów staną się niedostępne, ale regiony pomocnicze nadal obsługują żądania API przy użyciu najnowszej konfiguracji bramy.

  • W przypadku skonfigurowania zasady rate-limit i rate-limit-by-key liczą wywołania oddzielnie na każdej bramie regionalnej w ramach wdrożenia. Zasady nie agregują wszystkich danych połączeń dla danego wystąpienia. Polityki azure-openai-token-limit i llm-token-limit liczą użycie tokenów osobno na każdej bramie regionalnej w ramach wdrożenia.

Wymagania wstępne

  • Dokładnie zapoznaj się ze wszystkimi wymaganiami i czynnikami dotyczącymi umożliwienia wdrożeń wieloregionalnych w systemie API Management.

  • Jeśli nie utworzono wystąpienia usługi API Management, zobacz Tworzenie wystąpienia usługi API Management. Wybierz warstwę usługi Premium.

  • Jeśli wystąpienie usługi API Management jest wdrażane w sieci wirtualnej, upewnij się, że skonfigurowano sieć wirtualną i podsieć w lokalizacji, którą planujesz dodać, i w ramach tej samej subskrypcji. Zobacz Wymagania wstępne dotyczące sieci wirtualnej.

Wdrażanie usługi API Management w dodatkowym regionie

  1. W witrynie Azure Portal przejdź do usługi API Management i wybierz pozycję Lokalizacje z menu po lewej stronie.
  2. W górnym pasku wybierz + Dodaj.
  3. Wybierz dodaną lokalizację z listy rozwijanej.
  4. Wybierz liczbę jednostek skalowania w lokalizacji.
  5. Jeśli region obsługuje strefy dostępności, pozostaw ustawienie Automatyczne (zalecane) lub opcjonalnie wybierz co najmniej jedną strefę. W przypadku wybrania określonych stref wybrana liczba wybranych jednostek musi równomiernie dystrybuować się między strefami dostępności. Jeśli na przykład wybierzesz trzy jednostki, musisz wybrać trzy strefy, aby każda strefa hostuje jedną jednostkę.
  6. Jeśli wystąpienie usługi API Management zostanie wdrożone w sieci wirtualnej, skonfiguruj ustawienia sieci wirtualnej w lokalizacji, w tym sieć wirtualną, podsieć i publiczny adres IP.
  7. Wybierz pozycję Dodaj , aby potwierdzić.
  8. Powtórz ten proces do momentu skonfigurowania wszystkich lokalizacji.
  9. Wybierz pozycję Zapisz na górnym pasku, aby rozpocząć proces wdrażania.

Usuwanie regionu usługi API Management

  1. W witrynie Azure Portal przejdź do usługi API Management i wybierz pozycję Lokalizacje z menu po lewej stronie.
  2. Dla lokalizacji, którą chcesz usunąć, wybierz menu kontekstowe przy użyciu przycisku ... na prawym końcu tabeli. Wybierz pozycję Usuń.
  3. Potwierdź usunięcie i wybierz pozycję Zapisz , aby zastosować zmiany.

Kierowanie wywołań interfejsu API do regionalnych usług zaplecza

Domyślnie każdy interfejs API kieruje żądania do pojedynczego adresu URL usługi zaplecza. Nawet jeśli skonfigurujesz bramy usługi API Management w różnych regionach, brama interfejsu API nadal przekazuje żądania do tej samej usługi zaplecza, która jest wdrażana tylko w jednym regionie. W takim przypadku zwiększona wydajność pochodzi tylko z odpowiedzi buforowanych w usłudze API Management w regionie specyficznym dla żądania. Kontaktowanie się z zapleczem na całym świecie może nadal powodować duże opóźnienie.

Aby korzystać z geograficznego rozkładu systemu, powinno się wdrożyć usługi backendowe w tych samych regionach co instancje API Management. Następnie, przy użyciu polityk oraz właściwości @(context.Deployment.Region), można kierować ruch do lokalnych instancji swojego zaplecza.

  1. Przejdź do instancji API Management i wybierz pozycję API z menu po lewej stronie.

  2. Wybierz żądany interfejs API.

  3. Na karcie Projektowanie w sekcji Przetwarzanie przychodzące wybierz pozycję Edytor kodu.

    Zrzut ekranu przedstawiający edytor kodu interfejsu API na karcie projektowania.

  4. Użyj set-backend w połączeniu z warunkowymi zasadami choose, aby utworzyć odpowiednie zasady routingu w sekcji <inbound> </inbound> tego pliku.

    Na przykład następujący plik XML będzie działać w regionach Zachodnie stany USA i Azja Wschodnia:

    <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>
    

Używanie usługi Traffic Manager do routingu do regionalnych zapleczy

Usługi zaplecza można również kierować za pomocą usługi Azure Traffic Manager, kierować wywołania interfejsu API do usługi Traffic Manager i zezwolić na automatyczne rozwiązywanie routingu.

  • W przypadku dystrybucji ruchu i trybu failover zalecamy użycie usługi Traffic Manager z metodą routingu geograficznego . Nie zalecamy używania usługi Traffic Manager z metodą routingu ważonego z zapleczemi usługi API Management.

  • W przypadku kontroli ruchu podczas operacji konserwacji zalecamy użycie metody routingu Priorytet.

Używanie routingu niestandardowego do bram regionalnych usługi API Management

Usługa API Management kieruje żądania do bramy regionalnej na podstawie najmniejszego opóźnienia. Chociaż nie można zastąpić tego ustawienia w usłudze API Management, możesz użyć własnej usługi Traffic Manager z niestandardowymi regułami routingu.

  1. Utwórz własną usługę Traffic Manager.
  2. Jeśli używasz domeny niestandardowej, użyj jej z usługą Traffic Manager zamiast usługi API Management.
  3. Skonfiguruj regionalne punkty końcowe usługi API Management w usłudze Traffic Manager. Regionalne punkty końcowe są zgodne ze wzorcem adresu URL https://<service-name>-<region>-01.regional.azure-api.net, na przykład https://contoso-westus2-01.regional.azure-api.net.
  4. Skonfiguruj punkty końcowe regionalnego stanu usługi API Management w usłudze Traffic Manager. Punkty końcowe stanu regionalnego są zgodne z wzorcem adresu URL https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef, na przykład https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef.
  5. Określ metodę routingu usługi Traffic Manager.

Wyłączanie routingu do bramy regionalnej

W niektórych warunkach może być konieczne tymczasowe wyłączenie routingu do jednej z bram regionalnych. Na przykład:

  • Po dodaniu nowego regionu, pozostaw go wyłączonego w trakcie konfigurowania i testowania regionalnej usługi zaplecza.
  • Podczas regularnej konserwacji zaplecza systemu w regionie
  • Aby przekierować ruch do innych regionów podczas zaplanowanej symulacji odzyskiwania po awarii, która symuluje niedostępność danego regionu lub w przypadku awarii regionalnej.

Aby wyłączyć routing do bramy regionalnej w wystąpieniu usługi API Management, zaktualizuj wartość właściwości bramy disableGateway na true. Wartość można ustawić przy użyciu interfejsu API REST tworzenia lub aktualizowania usługi , polecenia az apim update w interfejsie wiersza polecenia platformy Azure, polecenia set-azapimanagement programu Azure PowerShell lub innych narzędzi platformy Azure.

Ważne

  • Możesz ustawić właściwość disableGateway tak, aby wyłączyć routing do bramy regionalnej tylko wtedy, gdy używasz domyślnego routingu w usłudze API Management, a nie rozwiązania niestandardowego.
  • Nie można ustawić właściwości disableGateway w celu wyłączenia routingu do bramy regionalnej, gdy instancja usługi API Management jest wdrażana w sieci wirtualnej w trybie wewnętrznym. W takim przypadku należy samodzielnie zarządzać routingiem i równoważeniem obciążenia w wielu regionach.

Aby wyłączyć bramę regionalną przy użyciu interfejsu wiersza polecenia platformy Azure:

  1. Użyj polecenia az apim show , aby wyświetlić lokalizacje, stan bramy i regionalne adresy URL skonfigurowane dla wystąpienia usługi API Management.

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

    Przykładowe wyjście:

    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. Użyj polecenia az apim update aby wyłączyć bramę w dostępnej lokalizacji, takiej jak Zachodnie USA 2.

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

    Aktualizacja może potrwać kilka minut.

  3. Sprawdź, czy ruch kierowany do adresu URL bramy regionalnej jest przekierowywany do innego regionu.

Aby przywrócić routing do bramy regionalnej, ustaw wartość disableGateway na false.

Sieć wirtualna

Ta sekcja zawiera informacje odnośnie do wdrożeń wieloregionalnych, gdy wystąpienie usługi API Management jest integrowane w sieciach wirtualnych.

  • Skonfiguruj niezależnie każdą sieć regionalną. Wymagania dotyczące łączności, takie jak wymagane reguły sieciowej grupy zabezpieczeń dla sieci wirtualnej w dodanym regionie, są zazwyczaj takie same jak wymagania dotyczące sieci w regionie podstawowym.
  • Sieci wirtualne w różnych regionach nie muszą być połączone.

Ważne

Podczas konfigurowania wystąpienia usługi API Management do korzystania z wewnętrznego trybu sieci wirtualnej każda regionalna brama musi mieć również łączność wychodzącą na port 1433 z bazą danych Azure SQL Database skonfigurowaną dla wystąpienia usługi API Management, znajdującą się wyłącznie w regionie podstawowym. Upewnij się, że zezwalasz na łączność z w pełni kwalifikowaną nazwą domeny (FQDN) lub adresem IP tej bazy danych Azure SQL Database w dowolnych trasach lub regułach zapory skonfigurowanych dla sieci w regionach pomocniczych; w tym scenariuszu nie można użyć punktu końcowego usługi Azure SQL. Aby znaleźć nazwę bazy danych Azure SQL w regionie podstawowym, przejdź do strony Sieć>Stan sieci wystąpienia usługi Azure API Management w portalu.

Adresy IP

  • Publiczny wirtualny adres IP jest tworzony w każdym regionie, który został dodany do sieci wirtualnej. W przypadku sieci wirtualnych w trybie zewnętrznym lub wewnętrznym ten publiczny adres IP jest używany do zarządzania ruchem na porcie 3443.

    • Tryb zewnętrznej sieci wirtualnej: Publiczne adresy IP są również wymagane do kierowania publicznego ruchu HTTP do bram API.

    • Wewnętrzny tryb sieci wirtualnej: Prywatny adres IP jest również tworzony w każdym regionie, który jest połączony z dodaną siecią wirtualną. Użyj tych adresów, aby połączyć się w sieci z punktami końcowymi usługi API Management w regionach podstawowych i pomocniczych.

Routowanie

  • Tryb zewnętrznej sieci wirtualnej: Routing publicznego ruchu HTTP do bram regionalnych jest obsługiwany automatycznie w taki sam sposób, jak w przypadku niesieciowego wystąpienia usługi API Management.

  • Wewnętrzny tryb sieci wirtualnej: Prywatny ruch HTTP nie jest domyślnie kierowany ani zrównoważony pod względem obciążenia do bram regionalnych. Użytkownicy są właścicielami routingu i są odpowiedzialni za wprowadzenie własnego rozwiązania do zarządzania routingiem i równoważeniem obciążenia prywatnego w wielu regionach.