Compartir vía

Garantía de la disponibilidad y confiabilidad de API Management

  • Artículo

SE APLICA A: Premium

Este artículo es una introducción a las funcionalidades del servicio para asegurarse de que la instancia de API Management sigue sirviendo solicitudes de API si se producen interrupciones de Azure.

API Management ofrece las siguientes funcionalidades para soluciones de Azureconfiables y resistentes. Úselos individualmente o juntos para mejorar la disponibilidad:

  • Zonas de disponibilidad: resistencia a interrupciones de nivel de centro de datos

  • Implementación en varias regiones: resistencia a interrupciones regionales

Nota:

Zonas de disponibilidad

Las zonas de disponibilidad de Azure son ubicaciones separadas físicamente dentro de una región de Azure y toleran los errores de nivel de centro de datos. Cada zona consta de uno o varios centros de datos equipados con una infraestructura de alimentación, refrigeración y redes independientes. Para garantizar la resistencia, hay un mínimo de 3 zonas de disponibilidad independientes en todas las regiones habilitadas. Más información

La habilitación de la redundancia de zona para una instancia de API Management en una región admitida proporciona redundancia para todos los componentes de servicio: puerta de enlace, plano de administración y portal para desarrolladores. Azure replica de forma automática todos los componentes de servicio en las zonas que seleccione.

Al habilitar la redundancia de zona en una región, tenga en cuenta el número de unidades de escalado de API Management que deben distribuirse. Como mínimo, configure el mismo número de unidades que de zonas de disponibilidad o un múltiplo para que las unidades se distribuyan uniformemente entre las zonas. Por ejemplo, si selecciona 3 zonas de disponibilidad en una región, podría tener 3 unidades para que cada zona hospede una unidad.

Nota:

Use métricas de capacidad y sus propias pruebas para decidir el número de unidades de escalado que proporcionarán el rendimiento de la puerta de enlace para sus necesidades. Obtenga más información sobre el escalado y la actualización de la instancia de servicio.

Implementación en varias regiones

Con la implementación de varias regiones puede 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.

  • 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 disponibles, pero las regiones secundarias siguen atendiendo solicitudes de API mediante la configuración de puerta de enlace más reciente.

Combinación de zonas de disponibilidad e implementación en varias regiones

Combinar las zonas de disponibilidad para la redundancia dentro de una región, y las implementaciones en varias regiones para mejorar la disponibilidad de la puerta de enlace si se produce una interrupción regional, ayuda a mejorar tanto la confiabilidad como el rendimiento de la instancia de API Management.

Ejemplos:

  • Uso de zonas de disponibilidad para mejorar la resistencia de la región primaria en una implementación de varias regiones

  • Distribución de unidades de escalado entre zonas de disponibilidad y regiones para mejorar el rendimiento de la puerta de enlace regional

Consideraciones del Acuerdo de Nivel de Servicio

API Management proporciona un Acuerdo de Nivel de Servicio del 99,99 % al implementar al menos una unidad en dos o más zonas de disponibilidad o regiones. Para obtener más información, consulte el apartado Precios.

Nota

Aunque Azure se esfuerza continuamente por lograr la máxima resistencia posible en el Acuerdo de Nivel de Servicio para la plataforma en la nube, debe definir sus propios Acuerdos de Nivel de Servicio de destino para otros componentes de la solución.

Disponibilidad de back-end

En función de dónde y cómo se hospeden los servicios back-end, es posible que tenga que configurar back-end redundantes en distintas regiones para satisfacer los requisitos de disponibilidad del servicio. También puede configurar las propiedades de back-end para mejorar la resistencia y la disponibilidad de los servicios back-end.

Back-end regionales

Puede administrar back-end regionales y controlar la conmutación por error mediante API Management para mantener la disponibilidad. Por ejemplo:

  • En las implementaciones de varias regiones, use directivas para enrutar las solicitudes mediante puertas de enlace regionales a back-end regionales.

  • Configure directivas para enrutar las solicitudes condicionalmente a diferentes back-end si hay un error de back-end en una región determinada.

  • Use el almacenamiento en caché para reducir las llamadas con errores.

Para más información, consulte la entrada de blog Redundancia de API de back-end con API Manager de Azure.

Configuración de las propiedades de back-end para la disponibilidad

Las entidades de back-end de API Management permiten administrar y aplicar propiedades de back-end para mejorar la disponibilidad de los back-end. Por ejemplo:

Pasos siguientes