Compartir a través de

Implementar una instancia de Azure API Management en varias regiones de Azure

SE APLICA A: Premium

Azure API Management admite la implementación en varias regiones, lo que permite a los publicadores de API agregar puertas de enlace de API regionales a una instancia de API Management existente en una o varias regiones de Azure admitidas. La implementación en varias regiones ayuda a reducir la latencia de las solicitudes que perciben los consumidores de API distribuidos geográficamente, y mejora la disponibilidad del servicio en caso de que una región se quede sin conexión.

Al agregar una región, configure:

  • Número de unidades de escalado que hospedará esa región.

  • Zonas de disponibilidad, si esa región la admite. De forma predeterminada, API Management configura automáticamente las zonas de disponibilidad para la región agregada, que se recomienda. También puede configurar manualmente las zonas de disponibilidad para la región agregada.

  • Configuración de red virtual en la región agregada, si las redes están configuradas en la región o regiones existentes.

Importante

La característica para permitir el almacenamiento de datos de clientes en una única región solo está disponible actualmente en la región Sudeste Asiático (Singapur) de la geoárea Asia Pacífico. En todas las demás regiones, los datos del cliente se almacenan en la geoárea.

Importante

Los cambios en la infraestructura del servicio API Management (por ejemplo, la configuración de dominios personalizados, la adición de certificados de CA, el escalado, la configuración de red virtual, los cambios de zona de disponibilidad y las adiciones de regiones) pueden tardar 15 minutos o más en completarse, según el nivel de servicio y el tamaño de la implementación. Espere tiempos más largos para una instancia con un mayor número de unidades de escalado o configuración de varias regiones. Los cambios graduales en API Management se ejecutan cuidadosamente para conservar la capacidad y la disponibilidad.

Aunque el servicio se está actualizando, no se pueden realizar otros cambios en la infraestructura de servicio. Sin embargo, puede configurar las API, los productos, las directivas y la configuración del usuario. El servicio no experimentará tiempo de inactividad de la puerta de enlace y API Management seguirá ofreciendo servicio a las solicitudes de API sin interrupción (excepto en el nivel Desarrollador).

Acerca de la implementación multirregional

  • Solo el componente de puerta de enlace de su instancia de API Management se replica en varias regiones. El plano de administración y el portal para desarrolladores de la instancia permanecen hospedados solo en la región primaria, donde implementó originalmente el servicio.

  • Si quiere configurar una ubicación secundaria para la instancia de API Management cuando se implementa (inserta) en una red virtual, la red virtual y la región de subred deben coincidir con la ubicación secundaria que está configurando. Si está añadiendo, eliminando o habilitando la zona de disponibilidad en la región primaria, o si está cambiando la subred de la región primaria, la dirección VIP de su instancia de API Management cambiará. Para más información, consulte Direcciones IP del servicio Azure API Management. Sin embargo, si va a agregar una región secundaria, la VIP de APIM de la región primaria no cambiará porque cada región tiene su propia VIP privada.

  • Las configuraciones de puerta de enlace, como las API y las definiciones de directiva, se sincronizan periódicamente entre las regiones principal y secundaria que agregue. La propagación de actualizaciones a las puertas de enlace regionales normalmente tarda menos de 10 segundos. La implementación en varias regiones proporciona disponibilidad de la puerta de enlace de API en más de una región y proporciona disponibilidad del servicio si una región se queda sin conexión.

  • Cuando API Management recibe solicitudes HTTP públicas al punto de conexión del administrador de tráfico (se aplica para los modos de VNet externa y no en red de API Management), el tráfico se enruta a una puerta de enlace regional en función de la latencia más baja, lo que puede reducir la latencia experimentada por los consumidores de API distribuidos geográficamente. En el modo de red virtual interna, los clientes deben configurar su propia solución para enrutar y equilibrar la carga del tráfico entre las puertas de enlace regionales. Para obtener más información, consulte Consideraciones sobre redes.

  • La puerta de enlace de cada región (incluida la región primaria) tiene un nombre DNS regional que sigue el patrón de dirección URL de https://<service-name>-<region>-01.regional.azure-api.net, por ejemplo https://contoso-westus2-01.regional.azure-api.net.

  • Si una región se queda sin conexión, las solicitudes de la API se enrutan de forma automática para evitar la región con errores hacia la siguiente puerta de enlace más cercana.

  • Si la región primaria se queda sin conexión, el plano de administración de API Management y el portal para desarrolladores deja de estar disponible, pero las regiones secundarias siguen atendiendo solicitudes de API mediante la configuración de puerta de enlace más reciente.

  • Si se configura, las directivas rate-limit y rate-limit-by-key cuentan llamadas por separado en cada puerta de enlace regional de la implementación. Las directivas no agregan todos los datos de llamada de la instancia. Del mismo modo, las directivas azure-openai-token-limit y llm-token-limit cuentan el uso de tokens por separado en cada puerta de enlace regional de la implementación.

Requisitos previos

Implementación del servicio API Management en una región adicional

  1. En Azure Portal, vaya al servicio API Management y seleccione Ubicaciones en el menú de la izquierda.
  2. Seleccione + Agregar en la barra superior.
  3. Seleccione la ubicación agregada en la lista desplegable.
  4. Seleccione el número de unidades de escalado de la ubicación.
  5. Si la región admite zonas de disponibilidad, deje el valor Automático (recomendado) o, opcionalmente, seleccione una o varias zonas. Si selecciona zonas específicas, el número de unidades que seleccione debe distribuirse uniformemente entre las zonas de disponibilidad. Por ejemplo, si selecciona tres unidades, debe seleccionar tres zonas para que cada zona hospede una unidad.
  6. Si la instancia de API Management se implementa en una red virtual, configure las opciones de red virtual en la ubicación, incluida la red virtual, la subred y la dirección IP pública.
  7. Seleccione Agregar para confirmar.
  8. Repita este proceso hasta que configure todas las ubicaciones.
  9. Seleccione Guardar en la barra superior para iniciar el proceso de implementación.

Eliminación de una región del servicio API Management

  1. En Azure Portal, vaya al servicio API Management y seleccione Ubicaciones en el menú de la izquierda.
  2. Para la ubicación que desee eliminar, seleccione el menú contextual mediante el botón ... situado a la derecha de la tabla. Seleccione Eliminar.
  3. Confirme la eliminación y seleccione Guardar para aplicar los cambios.

Enruta las llamadas API a servicios de respaldo regionales

De forma predeterminada, cada API enruta las solicitudes a una única dirección URL del servicio back-end. Incluso si configura puertas de enlace de API Management en varias regiones, la puerta de enlace de API sigue reenviando solicitudes al mismo servicio back-end, que se implementa en una sola región. En este caso, el rendimiento mejorado solo procede de las respuestas almacenadas en caché dentro de API Management en una región específica de la solicitud. Comunicar con el backend a nivel mundial puede provocar una latencia alta.

Para aprovechar la distribución geográfica del sistema, debe implementar servicios back-end en las mismas regiones que las instancias de API Management. A continuación, mediante políticas y la propiedad @(context.Deployment.Region), puede enrutar el tráfico a instancias locales del backend.

  1. Vaya a la instancia de API Management y seleccione API en el menú de la izquierda.

  2. Seleccione la API que desee.

  3. En la pestaña Diseño , en la sección Procesamiento de entrada , seleccione Editor de código.

    Captura de pantalla que resalta el editor de código de API en la pestaña diseño.

  4. Use set-backend en combinación con directivas choose condicionales para construir una directiva de enrutamiento adecuada en la sección <inbound> </inbound> del archivo.

    Por ejemplo, el siguiente archivo XML funcionaría para las regiones de Oeste de EE. UU. y Asia Pacífico:

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

Uso de Traffic Manager para el enrutamiento a back-end regionales

También puede adelantar sus servicios de back-end con Azure Traffic Manager, dirigir las llamadas de las API a Traffic Manager y dejar que resuelva el enrutamiento automáticamente.

  • Para la distribución de tráfico y la conmutación por error, se recomienda usar Traffic Manager con el método de enrutamiento Geográfico. No se recomienda usar Traffic Manager con el método de enrutamiento Ponderado con los back-end de API Management.

  • Para el control de tráfico durante las operaciones de mantenimiento, se recomienda usar el método de enrutamiento Prioridad.

Uso del enrutamiento personalizado a puertas de enlace regionales de API Management

API Management enruta las solicitudes a una puerta de enlace regional en función de la latencia más baja. Aunque no es posible invalidar esta configuración en API Management, puede usar su propia instancia de Traffic Manager con reglas de enrutamiento personalizadas.

  1. Cree su propio Traffic Manager.
  2. Si usa un dominio personalizado, úselo con Traffic Manager en lugar del servicio API Management.
  3. Configuración de los puntos de conexión regionales de API Management en Traffic Manager. Los puntos de conexión regionales siguen el patrón de dirección URL de https://<service-name>-<region>-01.regional.azure-api.net, por ejemplo https://contoso-westus2-01.regional.azure-api.net.
  4. Configure los puntos de conexión de estado regional de API Management en Traffic Manager. Los puntos de conexión de estado regional siguen el patrón de dirección URL de https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef, por ejemplo https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef.
  5. Especifique el método de enrutamiento de Traffic Manager.

Deshabilitar el enrutamiento a una puerta de enlace regional

En algunas condiciones, es posible que tengas que deshabilitar temporalmente el enrutamiento a una de las puertas de enlace regionales. Por ejemplo:

  • Después de agregar una nueva región, para mantenerla deshabilitada mientras configura y prueba el servicio back-end regional
  • Durante el mantenimiento de back-end normal en una región
  • Para redirigir el tráfico a otras regiones durante un simulacro de recuperación ante desastres planeado que simula una región no disponible o durante un error regional

Para deshabilitar el enrutamiento a una puerta de enlace regional en la instancia de API Management, actualiza el valor de propiedad disableGateway de la puerta de enlace a true. Puede establecer el valor mediante la API REST crear o actualizar servicio, el comando az apim update en la CLI de Azure, el cmdlet de Azure PowerShell set-azapimanagement u otras herramientas de Azure.

Importante

  • Solo puede establecer la propiedad disableGateway para deshabilitar el enrutamiento a una puerta de enlace regional cuando se utiliza el enrutamiento predeterminado en API Management, y no una solución de enrutamiento personalizada.
  • No se puede establecer la propiedad disableGateway para deshabilitar el enrutamiento a una puerta de enlace regional cuando la instancia de API Management se implementa en una red virtual en modo interno. En este caso, debe administrar el enrutamiento y el equilibrio de carga entre varias regiones usted mismo.

Para deshabilitar una puerta de enlace regional mediante la CLI de Azure:

  1. Usa el comando az apim show para mostrar las ubicaciones, el estado de la puerta de enlace y las direcciones URL regionales configuradas para la instancia de API Management.

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

    Salida de ejemplo:

    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. Usa el comando az apim update para deshabilitar la puerta de enlace en una ubicación disponible, como Oeste de EE. UU. 2.

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

    La actualización puede tardar unos minutos.

  3. Comprueba que el tráfico dirigido a la dirección URL de la puerta de enlace regional se redirige a otra región.

Para restaurar el enrutamiento a la puerta de enlace regional, establece el valor de disableGateway en false.

Redes virtuales

En esta sección se proporcionan consideraciones para las implementaciones de varias regiones cuando la instancia de API Management se inserta en una red virtual.

  • Configure cada red regional de forma independiente. Los requisitos de conectividad, como las reglas de grupo de seguridad de red necesarias para una red virtual en una región agregada, suelen ser los mismos que los requisitos de una red en la región primaria.
  • No es necesario emparejar redes virtuales en las distintas regiones.

Importante

Al configurar la instancia de API Management para que use el modo de red virtual interno, cada puerta de enlace regional también debe tener conectividad saliente en el puerto 1433 a la base de datos de Azure SQL configurada para la instancia de API Management, que solo se encuentra en la región primaria . Asegúrese de permitir la conectividad con el nombre de dominio completamente calificado (FQDN) o la dirección IP de esta base de datos de Azure SQL en cualquier ruta o regla de firewall que configure para las redes de las regiones secundarias; el punto de conexión de servicio de Azure SQL no se puede usar en este escenario. Para buscar el nombre de la base de datos de Azure SQL en la región primaria, vaya a la página Redes>Estado de la red de la instancia de API Management en el portal.

Direcciones IP

  • Se crea una dirección IP virtual pública en cada región agregada con una red virtual. En el caso de las redes virtuales en modo externo o en modo interno, esta dirección IP pública se usa para la administración del tráfico en el puerto 3443.

    • Modo de red virtual externa: Las direcciones IP públicas también son necesarias para enrutar el tráfico HTTP público a las puertas de enlace de API.

    • Modo de red virtual interna: También se crea una dirección IP privada en cada región agregada con una red virtual. Use estas direcciones para conectarse dentro de la red a los puntos de conexión de API Management en las regiones primarias y secundarias.

Enrutamiento

  • Modo de red virtual externa: El enrutamiento del tráfico HTTP público a las puertas de enlace regionales se controla automáticamente, de la misma manera que para una instancia de API Management no en red.

  • Modo de red virtual interna: El tráfico HTTP privado no se enruta ni se equilibra la carga a las puertas de enlace regionales de forma predeterminada. Los usuarios son propietarios del enrutamiento y son responsables de traer su propia solución para administrar el enrutamiento y el equilibrio de carga privado en varias regiones.

Contenido relacionado

  • Last updated on