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

  • Artículo

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:

Importante

La característica para permitir el almacenamiento de datos de clientes en una sola región solo está disponible actualmente en la región de 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.

Acerca de la implementación multirregional

  • Sólo el componente de puerta de enlace de su instancia de Gestión de API 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.

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

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. Opcionalmente, seleccione una o más zonas de disponibilidad.
  6. Si la instancia de API Management se ha implementado en una red virtual, configure las siguientes opciones de la red virtual en la ubicación. Seleccione una red virtual, una subred y una dirección IP pública existentes que estén disponibles en la ubicación.
  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 de servicio de 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.

Enrutamiento de las llamadas API a servicios regionales back-end

De forma predeterminada, cada API enruta las solicitudes a una única dirección URL del servicio back-end. Incluso si ha configurado las puertas de enlace de Azure API Management en varias regiones, la puerta de enlace de la API seguirá reenviando las solicitudes al mismo servicio backend, que está implementado en una sola región. En este caso, la ganancia de rendimiento procederá solo de las respuestas en caché a la solicitud en Azure API Management de una región específica, también puede generar una latencia alta al ponerse en contacto con el back-end de todo el mundo.

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

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

  2. Seleccione la API que desee.

  3. Seleecione el Editor de código de la flecha desplegable de Procesamiento de entrada.

    Editor de código de API

  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 perfil de Azure Traffic Manager.
  2. Si usa un dominio personalizado, úselo con Traffic Manager y no con el 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 configuras y pruebas 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. Puedes establecer el valor mediante la API de REST del Servicio de creación o actualización, el comando az apim update en la CLI de Azure, el cmdlet set-azapimanagement de Azure PowerShell u otras herramientas de Azure.

Nota:

Solo puede deshabilitar el enrutamiento a una puerta de enlace regional cuando se usa el enrutamiento predeterminado de API Management, no una solución de enrutamiento personalizada.

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 de una región agregada, suelen ser los mismos que para una red de la región primaria.
  • No es necesario emparejar redes virtuales en las distintas regiones.

Importante

Cuando se configura en modo de red virtual interna, cada puerta de enlace regional también debe tener conectividad saliente en el puerto 1443 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 FQDN o la dirección IP de esta base de datos de Azure SQL en las rutas o reglas de firewall que configure para las redes de las regiones secundarias; la etiqueta de servicio 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áginaRedes>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 es necesaria 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 conectada a la 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. Entre las soluciones de ejemplo se incluyen Azure Application Gateway y Azure Traffic Manager.

Pasos siguientes