Confiabilidad en Azure API Management

Azure API Management. es un servicio totalmente administrado que ayuda a las organizaciones a publicar, proteger, transformar, mantener y supervisar las API. Como servicio de Azure, API Management proporciona una variedad de funcionalidades para satisfacer los requisitos de confiabilidad.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que API Management sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad, interrupciones de regiones y mantenimiento del servicio. También se describe cómo puede usar copias de seguridad para recuperarse de otros tipos de problemas y se resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de API Management.

Introducción a la arquitectura de confiabilidad

API Management usa una arquitectura basada en unidades de escalado para proporcionar redundancia y escalabilidad integradas. Al implementar una instancia de API Management, se configuran una o varias unidades de escalado o unidades. Cada unidad es una representación lógica de la capacidad que contiene los recursos de proceso necesarios para controlar las solicitudes de API.

Al configurar una instancia con dos o más unidades, las unidades disponibles funcionan juntas para procesar solicitudes y proporcionar equilibrio de carga automático. Si una de las unidades deja de estar disponible, las unidades restantes siguen controlando el tráfico, pero con capacidad potencialmente reducida.

Para obtener mayores niveles de confiabilidad, API Management admite la distribución de unidades entre zonas de disponibilidad dentro de una región y entre varias regiones.

Los niveles de servicio de API Management proporcionan distintos niveles de confiabilidad:

• Nivel Premium (clásico): Admite varias unidades que se pueden distribuir entre zonas de disponibilidad y regiones para lograr una máxima resistencia. En el nivel Premium, cada unidad consta de dos máquinas virtuales (VM) que proporcionan los recursos de proceso para controlar las solicitudes de API.

• Niveles Básico v2, Estándar, Estándar v2 y Premium v2 (versión preliminar): Todas admiten varias unidades dentro de un único centro de datos. No admiten zonas de disponibilidad ni implementaciones de varias regiones.

• Nivel de desarrollador: Solo admite una sola unidad y no proporciona compatibilidad con zonas de disponibilidad ni con varias regiones. Este nivel está diseñado para escenarios de desarrollo y pruebas. No es adecuado para cargas de trabajo de producción.

• Nivel de consumo: Tiene funcionalidades de resistencia integradas y es resistente a una serie de errores dentro de un único centro de datos de Azure. Sin embargo, el nivel Consumo no proporciona compatibilidad con zonas de disponibilidad ni implementaciones de varias regiones. Para comprender el tiempo de actividad esperado de una instancia de API Management de nivel de consumo, revise el acuerdo de nivel de servicio (SLA).

Las unidades dentro de una instancia trabajan juntas para procesar solicitudes y equilibrar automáticamente la carga entre las unidades disponibles. Si una unidad deja de estar disponible, las unidades restantes siguen controlando el tráfico, pero con capacidad potencialmente reducida.

Recomendaciones de implementación de producción

Azure Well-Architected Framework proporciona recomendaciones sobre confiabilidad, rendimiento, seguridad, costo y operaciones. Para comprender cómo estas áreas influyen entre sí y contribuyen a una solución confiable de API Management, consulte Procedimientos recomendados de arquitectura para API Management.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que sus aplicaciones puedan administrar errores transitorios, generalmente reintentando las solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Al usar API Management delante de una API, es posible que tenga que reintentar solicitudes que produzcan un error debido a errores transitorios. Para proteger la API de back-end de ser sobrecargada por demasiadas solicitudes, API Management proporciona directivas de reintento, límite de velocidad y cuota. También puede configurar las funcionalidades de equilibrio de carga y disyuntor mediante el uso de recursos de backend.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

API Management proporciona dos tipos de compatibilidad con zonas de disponibilidad al implementar una instancia de API Management Premium (clásica) en una región admitida:

• Automático: API Management proporciona compatibilidad con zonas de disponibilidad automáticas cuando no se especifican las zonas de disponibilidad que se van a usar.

• Manual: API Management proporciona compatibilidad con la zona de disponibilidad manual cuando se especifican explícitamente las zonas de disponibilidad que se van a usar.

Con la compatibilidad con zonas de disponibilidad, API Management replica componentes de servicio entre zonas para lograr alta disponibilidad. En la región primaria, estos componentes incluyen la puerta de enlace (unidades de escalado), el plano de administración y el portal para desarrolladores. En regiones secundarias, solo se replican las unidades de puerta de enlace. Para más información sobre las regiones secundarias, consulte Resistencia a errores en toda la región.

Compatibilidad con zonas de disponibilidad automáticas

Puede usar la compatibilidad automática con zonas de disponibilidad para elegir una configuración de instancia de una sola unidad o de varias unidades con el fin de lograr la redundancia de zonas:

• Configuración de varias unidades (recomendado): si la instancia tiene dos o más unidades, API Management realiza un mejor intento de distribuir las unidades de la instancia entre las zonas de disponibilidad de la región. No hay ninguna manera de determinar en qué zonas de disponibilidad se colocan las unidades. Se recomienda implementar un mínimo de dos unidades, que se pueden distribuir entre dos zonas.

  En el diagrama siguiente se muestra una instancia de API Management con tres unidades configuradas para la compatibilidad automática con zonas de disponibilidad:

  

  En el diagrama se muestran tres cuadros con la etiqueta Unidad 1, Unidad 2 y Unidad 3 implementadas en una instancia de API Management. Cada cuadro de unidad contiene dos iconos que representan máquinas virtuales. Tres cuadros más grandes se etiquetan como Zona de disponibilidad 1, Zona de disponibilidad 2 y Zona de disponibilidad 3. La zona 1 contiene la unidad 1, la zona 2 contiene la unidad 2 y la zona 3 contiene la unidad 3.

• Configuración de una sola unidad: Si la instancia tiene una sola unidad, las máquinas virtuales subyacentes de la unidad se distribuyen a dos zonas de disponibilidad. No hay ninguna manera de determinar en qué zonas de disponibilidad se colocan las máquinas virtuales de la unidad.

  

  El diagrama muestra un cuadro con la etiqueta "Unidad 1" implementada en una instancia de API Management. El cuadro de unidad contiene dos iconos que representan máquinas virtuales. Tres cuadros más grandes se etiquetan como Zona de disponibilidad 1, Zona de disponibilidad 2 y Zona de disponibilidad 3. El cuadro Unidad 1 abarca las zonas 1 y 2. La zona 3 está vacía.

Compatibilidad con zonas de disponibilidad configuradas manualmente

Si desea seleccionar explícitamente las zonas de disponibilidad que se van a usar, puede elegir entre configuraciones con redundancia de zona y zonales:

• Redundancia de zona: Configure manualmente la redundancia de zona para una instancia de API Management en una región compatible con el fin de proporcionar redundancia a los componentes del servicio. Al seleccionar dos o más zonas de disponibilidad que se van a usar, Azure replica automáticamente los componentes de servicio en las zonas seleccionadas.

  

  En el diagrama se muestran tres cuadros con la etiqueta Unidad 1, Unidad 2 y Unidad 3 implementadas en una instancia de API Management. Cada cuadro de unidad contiene dos iconos que representan máquinas virtuales. Tres cuadros más grandes se etiquetan como Zona de disponibilidad 1, Zona de disponibilidad 2 y Zona de disponibilidad 3. La zona 1 contiene la unidad 1, la zona 2 contiene la unidad 2 y la zona 3 contiene la unidad 3.

• Zonal: Los componentes del servicio API Management se implementan en una sola zona que se selecciona dentro de una región de Azure. Todas las unidades se colocan en la misma zona de disponibilidad.

  

  En el diagrama se muestran dos cuadros con la etiqueta Unidad 1 y Unidad 2 implementada en una instancia de API Management. Cada cuadro de unidad contiene dos iconos que representan máquinas virtuales. Tres cuadros más grandes se etiquetan como Zona de disponibilidad 1, Zona de disponibilidad 2 y Zona de disponibilidad 3. La zona 1 contiene las cajas de la Unidad 1 y la Unidad 2. La zona 2 y la zona 3 no contienen ninguna unidad.

  Importante

  Ancle a una sola zona de disponibilidad solo si la latencia entre zonas es demasiado alta para sus necesidades y después de comprobar que la latencia no cumple sus requisitos. Por sí mismo, una instancia zonal no proporciona resistencia a una interrupción de zona de disponibilidad. Para mejorar la resistencia de una implementación de API Management zonal, debe implementar explícitamente instancias independientes en varias zonas de disponibilidad y configurar el enrutamiento y la conmutación por error del tráfico.

Requisitos

• Compatibilidad con regiones: API Management admite zonas de disponibilidad para el nivel Premium (clásico) en todas las regiones de Azure que admiten zonas de disponibilidad.

• Requisito de nivel: Debe usar el nivel Premium (clásico) para configurar la compatibilidad con zonas de disponibilidad. API Management no admite actualmente zonas de disponibilidad en los niveles consumo clásico, desarrollador, básico y estándar o en los niveles Básico v2, Estándar v2 y Premium v2. Para actualizar la instancia al nivel Premium (clásico), consulte Actualización al nivel Premium.

Consideraciones

• Número de unidades para instancias con redundancia de zona: Si configura manualmente la redundancia de zona para una instancia, también debe configurar una serie de unidades de API Management que se pueden distribuir uniformemente en todas las zonas de disponibilidad seleccionadas. Por ejemplo, si selecciona dos zonas, debe configurar al menos dos unidades. En su lugar, puede configurar cuatro unidades u otras varias de dos unidades. Si selecciona tres zonas de disponibilidad, debe configurar tres unidades, seis unidades u otro múltiplo de tres unidades.

  Si usa la compatibilidad con la zona de disponibilidad automática, no es necesario usar un número específico de unidades. Las unidades que implemente se distribuyen entre las zonas de disponibilidad de una manera más adecuada. Para obtener la redundancia máxima de zona, se recomienda usar al menos dos unidades para asegurarse de que una interrupción de zona de disponibilidad no afecte a la instancia.

  Para determinar el número de unidades que proporcionan el rendimiento necesario de su puerta de enlace, use las métricas de capacidad y sus propias pruebas. Para más información sobre el escalado y la actualización de la instancia de servicio, consulte Actualización y escalado de una instancia de API Management.

• Escalado automático: Si configura manualmente zonas de disponibilidad en una instancia de API Management configurada con el escalado automático, es posible que tenga que ajustar la configuración de escalado automático después de la configuración. En este caso, el número de unidades de API Management en reglas y límites de escalado automático debe ser un múltiplo del número de zonas. Si usa la compatibilidad con la zona de disponibilidad automática, no es necesario ajustar la configuración de escalado automático.

• Requisitos de dirección IP: Cuando habilita la compatibilidad con zonas de disponibilidad en una instancia de API Management implementada en una red virtual externa o interna, debe especificar un recurso de dirección IP pública para que lo utilice la instancia. En una red virtual interna, la dirección IP pública solo se usa para las operaciones de administración, no para las solicitudes de API. Para más información, consulte Direcciones IP en API Management.

Costos

Independientemente de la configuración de la zona de disponibilidad, si agrega más unidades, incurrirá en más costos. Para más información, consulte Precios de API Management.

Configurar soporte de zonas de disponibilidad

En esta sección se explica cómo configurar la compatibilidad con zonas de disponibilidad para la instancia de API Management.

• Cree una instancia de API Management que admita zonas de disponibilidad: Al crear una instancia de API Management Premium (clásica) en una región que admita zonas de disponibilidad, la instancia admite zonas de disponibilidad de forma predeterminada. Puede seleccionar la compatibilidad automática con zonas de disponibilidad o configurar manualmente el soporte zonal o el soporte con redundancia de zona.

• Habilite o vuelva a configurar la compatibilidad con la zona de disponibilidad: Puede cambiar la configuración de zona de disponibilidad de una instancia de API Management, incluida la adición de zonas de disponibilidad y el traslado de una instancia zonal entre zonas de disponibilidad. Para obtener información sobre cómo configurar la compatibilidad con zonas de disponibilidad en una instancia de API Management, consulte Habilitar la compatibilidad con zonas de disponibilidad en instancias de API Management. No hay requisitos de tiempo de inactividad para ninguna de las opciones de configuración.

  Al cambiar la configuración de la zona de disponibilidad, los cambios pueden tardar entre 15 y 45 minutos o más en aplicarse. La puerta de enlace de API Management puede seguir controlando las solicitudes de API durante ese tiempo.

  Cambiar la configuración de la zona de disponibilidad desencadena un cambio de dirección IP pública y privada.

Planeamiento y administración de capacidad

En un escenario de zona inactiva, no hay garantía de que las solicitudes de más capacidad en otra zona de disponibilidad tengan éxito. El reposición de unidades perdidas se produce de forma más adecuada. Si necesita capacidad garantizada cuando se produce un error en una zona de disponibilidad, debe crear y configurar la instancia de API Management para tener en cuenta la pérdida de una zona mediante la realización de todas las acciones siguientes:

• Aprovisionamiento excesivo de las unidades de la instancia de API Management.

• Use la configuración de zona de disponibilidad automática o redundante por zonas.

Para más información, consulte Administración de la capacidad con sobreaprovisionamiento.

Use métricas de capacidad y sus propias pruebas para determinar el número de unidades que proporcionan el rendimiento de la puerta de enlace necesaria. Para más información sobre cómo escalar y actualizar la instancia de servicio, consulte Actualización y escalado de una instancia de API Management.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando las instancias de API Management están configuradas con compatibilidad con zonas de disponibilidad y todas las zonas de disponibilidad están operativas.

• Enrutamiento de tráfico entre zonas: Durante las operaciones normales, el tráfico se enruta entre todas las unidades de API Management disponibles en todas las zonas de disponibilidad seleccionadas.

• Replicación de datos entre zonas: API Management almacena y replica los siguientes datos.

  • La configuración de la puerta de enlace, como las API y las definiciones de directiva, se sincronizan periódicamente entre las zonas de disponibilidad que seleccione para la instancia. La propagación de actualizaciones entre las zonas de disponibilidad normalmente tarda menos de 10 segundos.

  • Datos de la memoria caché interna, si usa la memoria caché interna que proporciona API Management. Las entradas de caché se distribuyen entre zonas de disponibilidad. La caché interna es volátil y no se garantiza que los datos se conserven. Considere la posibilidad de usar una caché externa si necesita conservar los datos almacenados en caché.

  • Contadores de límite de velocidad, si usa las funcionalidades de limitación de velocidad que proporciona API Management. Los contadores de límite de velocidad se replican de forma asíncrona entre las zonas de disponibilidad que seleccione para la instancia.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando las instancias de API Management están configuradas con compatibilidad con la zona de disponibilidad y hay una interrupción de zona de disponibilidad.

• Detección y respuesta: La responsabilidad de la detección y la respuesta depende de la configuración de zona de disponibilidad que usa la instancia.

  • Automático y con redundancia de zona: En el caso de las instancias configuradas para utilizar la compatibilidad automática con zonas de disponibilidad o configuradas manualmente para utilizar la redundancia de zona, la plataforma API Management se encarga de detectar los fallos en una zona de disponibilidad y responder a ellos. No es necesario hacer nada para iniciar una conmutación por error de la zona.

  • Zonal: para que las instancias configuradas sean zonales, debe detectar la pérdida de una zona de disponibilidad e iniciar una conmutación por error a una instancia secundaria que cree en otra zona de disponibilidad.

• Solicitudes activas: Cuando una zona de disponibilidad no está disponible, las solicitudes en curso que están conectadas a una unidad de API Management en la zona de disponibilidad defectuosa se finalizan y deben reintentarse.

• Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas. También puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

• Pérdida de datos esperada: API Management almacena los siguientes datos.

  • Cambios en la configuración de la puerta de enlace, y que se replican en cada zona de disponibilidad seleccionada en aproximadamente 10 segundos. Si se produce una interrupción de una zona de disponibilidad, puede perder los cambios de configuración que no se replican.

  • Datos de la memoria caché interna, si usa la característica de caché interna. La caché interna es volátil y no se garantiza que los datos se conserven. Durante una interrupción del servicio en una zona de disponibilidad, es posible que se pierda parte o la totalidad de los datos almacenados en caché. Considere la posibilidad de usar una caché externa si necesita conservar los datos almacenados en caché.

  • Contadores de límite de velocidad, si usa la característica de límite de velocidad. Durante una interrupción de zona de disponibilidad, es posible que los contadores de límite de frecuencia no estén actualizados en las zonas supervivientes.

• Tiempo de inactividad esperado: El tiempo de inactividad esperado depende de la configuración de zona de disponibilidad que usa la instancia.

  • Automático: Puede esperar que las instancias que usen compatibilidad con zonas de disponibilidad automáticas no tengan tiempo de inactividad durante una interrupción de la zona de disponibilidad. Las unidades de la zona o zonas no afectadas siguen funcionando.

    También puede esperar instancias que usen compatibilidad automática con zonas de disponibilidad, pero que tengan una sola unidad, sin tiempo de inactividad. En este caso, API Management distribuye las máquinas virtuales subyacentes de la unidad a dos zonas. La máquina virtual de la zona no afectada sigue funcionando.

  • Con redundancia de zona: Puede esperar que las instancias con redundancia de zona no sufran interrupciones durante una interrupción de la zona de disponibilidad.

  • Zonal: En el caso de las instancias zonales, cuando una zona no está disponible, la instancia no está disponible hasta que se recupere la zona de disponibilidad.

• Reenrutamiento del tráfico: El comportamiento de reenrutamiento del tráfico depende de la configuración de zona de disponibilidad que usa la instancia.

  • Automático y con redundancia de zona: En el caso de las instancias que están configuradas para utilizar la compatibilidad automática con zonas de disponibilidad o que están configuradas manualmente para utilizar la redundancia de zona, cuando una zona no está disponible, ninguna de las unidades de la zona afectada estará disponible. Puede optar por escalar la instancia para agregar más unidades.

  • Zonal: En el caso de las instancias zonales, cuando una zona no está disponible, la instancia no está disponible. Si tiene una instancia secundaria en otra zona de disponibilidad, es responsable de redirigir el tráfico a esa instancia secundaria.

Recuperación de zona

El comportamiento de recuperación de zona depende de la configuración de zona de disponibilidad que usa la instancia.

• Automático y con redundancia de zona: En el caso de las instancias que están configuradas para utilizar la compatibilidad automática con zonas de disponibilidad o que están configuradas manualmente para utilizar la redundancia de zona, cuando la zona de disponibilidad se recupera, API Management restaura automáticamente las unidades de la zona de disponibilidad y redirige el tráfico entre sus unidades con normalidad.

• Zonal: En el caso de las instancias zonales, usted es responsable de redirigir el tráfico a la instancia en la zona de disponibilidad original una vez que la zona de disponibilidad se haya recuperado.

Prueba de fallos de zona

Las opciones para probar errores de zona dependen de la configuración de zona de disponibilidad que usa la instancia.

• Automático y con redundancia de zona: En el caso de las instancias que están configuradas para utilizar la compatibilidad automática con zonas de disponibilidad o que están configuradas manualmente para utilizar la redundancia de zona, la plataforma API Management administra el enrutamiento del tráfico, la conmutación por error y la conmutación por recuperación. Esta característica está totalmente administrada, por lo que no es necesario iniciar ni validar los procesos de error de zona de disponibilidad.

• Zonal: En el caso de las instancias zonales, no hay ninguna manera de simular una interrupción de la zona de disponibilidad que contiene la instancia de API Management. Sin embargo, puede configurar manualmente puertas de enlace ascendentes o equilibradores de carga para redirigir el tráfico a una instancia diferente en una zona de disponibilidad diferente.

Resistencia a errores en toda la región

Con una 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 compatibles. La implementación en varias regiones ayuda a reducir la latencia de las solicitudes que perciben los consumidores de API distribuidos geográficamente. Una implementación de varias regiones también mejora la disponibilidad del servicio si una región se queda sin conexión.

Implementación multirregión administrada por Microsoft

API Management solo admite implementaciones de varias regiones en el nivel Premium (clásico). No admite implementaciones de varias regiones en los niveles Consumo, Desarrollador, Básico, Básico v2, Estándar, Estándar v2 y Premium v2 (versión preliminar). Para obtener más información, consulte los requisitos.

Al agregar una región, configure:

• Número de unidades que hospeda esa región.

• Resistencia a errores de zona de disponibilidad, si esa región proporciona zonas de disponibilidad.

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

Requisitos

• Compatibilidad con regiones: Puede crear implementaciones de varias regiones en el nivel Premium (clásico) con cualquier región de Azure que admita API Management. Para ver qué regiones admiten implementaciones de varias regiones, consulte Disponibilidad del producto por región.

• Requisito de nivel: Debe usar el nivel Premium (clásico) para configurar la compatibilidad con varias regiones. Para actualizar la instancia al nivel Premium (clásico), consulte Actualización al nivel Premium.

Consideraciones

• Solo puerta de enlace: Únicamente el componente de puerta de enlace de su instancia de gestión de API se replica en múltiples 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.

• Requisitos de red: Si desea configurar una ubicación secundaria para su instancia de API Management cuando se implementa (inyecta) en una red virtual, la red virtual y la región de la subred deben coincidir con la ubicación secundaria que configure. Si agrega, quita o habilita la zona de disponibilidad en la región primaria, o si cambia la subred de la región primaria, cambia la dirección IP virtual (VIP) de la instancia de API Management. Para obtener más información, consulte Cambios en las direcciones IP. Sin embargo, si se agrega una región secundaria, el VIP de la región principal no cambia, ya que cada región tiene su propio VIP privado.

• Nombres del sistema de nombres de dominio (DNS): 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.

Costos

Agregar regiones implica costos. Para más información, consulte Precios de API Management.

Configuración de la compatibilidad con varias regiones

Para configurar la compatibilidad con varias regiones en una instancia de API Management, consulte Implementar una instancia de API Management en varias regiones de Azure.

Para quitar una región de una instancia de API Management, consulte Eliminación de una región del servicio API Management.

Planeamiento y administración de capacidad

En un escenario de reducción regional, no hay ninguna garantía de que las solicitudes de más capacidad en otra región se realicen correctamente. Si necesita capacidad garantizada cuando se produce un error en una región, debe crear y configurar la instancia de API Management para que tenga en cuenta la pérdida de una región. Puede hacerlo mediante el aprovisionamiento excesivo de la capacidad de la instancia de API Management. Para más información sobre el principio de sobreaprovisionamiento, consulte Gestionar la capacidad con sobreaprovisionamiento.

En las implementaciones de varias regiones, el escalado automático solo se aplica a la región primaria. Las regiones secundarias requieren ajustes de escalado manual o herramientas personalizadas que controle.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué se puede esperar cuando las instancias de API Management se configuran con compatibilidad con varias regiones y todas las regiones están operativas.

• Enrutamiento del tráfico entre regiones: API Management enruta automáticamente las solicitudes recibidas a una puerta de enlace regional. Una solicitud se enruta a la puerta de enlace regional con la latencia más baja del cliente. Si necesita usar un enfoque de enrutamiento diferente, puede configurar su propio Administrador de tráfico con reglas de enrutamiento personalizadas. Para obtener más información, consulte Uso del enrutamiento personalizado en las puertas de enlace regionales de API Management.

  Cuando una solicitud llega a una puerta de enlace regional de API Management, se enruta a la API backend, a menos que una directiva devuelva una respuesta directamente desde la puerta de enlace, como una respuesta almacenada en caché o un código de error. En una solución de varias regiones, debe tener cuidado de enrutar a una instancia de la API de back-end que cumpla los requisitos de rendimiento. Para obtener más información, consulte Enrutamiento de llamadas API a servicios back-end regionales.

• Replicación de datos entre regiones: La configuración de puerta de enlace, como las API y las definiciones de directiva, se sincronizan periódicamente entre las regiones primarias y secundarias que agregue. La propagación de actualizaciones a las puertas de enlace regionales normalmente tarda menos de 10 segundos.

  Los contadores de límite de velocidad y los datos de la caché interna son específicos de la región, por lo que no se replican entre regiones.

Comportamiento durante una falla de región

En esta sección se describe qué puede ocurrir cuando las instancias de API Management se configuran con compatibilidad con varias regiones y se produce una interrupción del servicio en una de las regiones que utiliza.

• Detección y respuesta: La API Management se encarga de detectar un error en una región y de realizar automáticamente una conmutación por error a una puerta de enlace en una de las otras regiones que usted configure.

• Solicitudes activas: Cualquier solicitud activa que se esté procesando en la región defectuosa podría descartarse y el cliente debería volver a intentarla.

• Pérdida de datos esperada: API Management no almacena datos, excepto los contadores de configuración, caché y límite de velocidad.

  Los cambios de configuración se replican en cada región en aproximadamente 10 segundos. Si se produce una interrupción del servicio en su región principal, es posible que pierda los cambios de configuración que no se hayan replicado.

  Los contadores de límite de velocidad y los datos de la caché interna son específicos de la región, por lo que no se replican entre regiones.

• Tiempo de inactividad esperado: No se espera ningún tiempo de inactividad de puerta de enlace.

  Si la región principal se desconecta, el plano de administración de API Management y el portal para desarrolladores dejan de estar disponibles, pero las regiones secundarias continúan atendiendo las solicitudes de API utilizando la configuración de puerta de enlace más reciente.

• Reenrutamiento del tráfico: Si una región se queda sin conexión, las solicitudes de API se enrutan automáticamente evitando la región fallida hacia la siguiente puerta de enlace más cercana.

Recuperación de regiones

Cuando se recupera la región primaria, API Management restaura automáticamente las unidades de la región y vuelve a enrutar el tráfico entre las unidades.

Prueba de fallos de región

Para estar preparado ante interrupciones inesperadas en la región, le recomendamos que compruebe periódicamente sus respuestas ante errores en la región. Puede simular algunos aspectos de un error de región deshabilitando el enrutamiento a una puerta de enlace regional.

Copias de seguridad y restauración

API Management no almacena la mayoría de los datos en tiempo de ejecución. Sin embargo, puede realizar una copia de seguridad de la configuración del servicio API Management. También puede usar operaciones de copia de seguridad y restauración para replicar configuraciones del servicio API Management entre entornos operativos, por ejemplo, desarrollo y almacenamiento provisional.

La copia de seguridad se admite en los niveles Desarrollador, Básico, Estándar y Premium.

Para obtener más información, consulte Cómo implementar la recuperación ante desastres mediante la copia de seguridad y restauración del servicio en API Management.

Para realizar copias de seguridad o restaurar algunos componentes o recursos del servicio, también puede considerar opciones administradas por el cliente, como las herramientas APIOps y las soluciones de infraestructura como código (IaC).

Resistencia al mantenimiento del servicio

API Management realiza actualizaciones de servicio periódicas y otras formas de mantenimiento.

En los niveles Básico, Estándar y Premium (clásico), puede personalizar cuándo en el proceso de actualización la instancia recibe una actualización. Si necesita validar el efecto de las actualizaciones en la carga de trabajo, considere la posibilidad de configurar una instancia de prueba para recibir actualizaciones al principio de un ciclo de actualización y establecer la instancia de producción para recibir actualizaciones en un momento posterior al ciclo. También puede especificar una ventana de mantenimiento, que es la hora del día en la que desea que la instancia aplique las actualizaciones del servicio.

Para obtener más información, consulte Configurar los ajustes de actualización del servicio para sus instancias de API Management.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Al implementar una instancia de API Management en varias zonas de disponibilidad o regiones, aumenta el porcentaje de tiempo de actividad definido en el Acuerdo de Nivel de Servicio.

El servicio proporciona su propio Acuerdo de Nivel de Servicio, pero también debe tener en cuenta la confiabilidad prevista de otros componentes de carga de trabajo, como los back-end de API.

Contenido relacionado

• Recuperación ante desastres y continuidad empresarial para API Management
• Uso de zonas de disponibilidad en API Management
• Implementación en varias regiones de API Management
• Supervisar API Management
• Planeamiento de la capacidad de API Management
• Procedimientos recomendados de arquitectura para API Management