Acerca del estado de Private Service Connect para la conmutación por error automática entre regiones
El estado de Private Service Connect permite que los productores de servicios definan estados de salud que admitan la conmutación por error automática entre regiones para los consumidores de servicios que usan backends de Private Service Connect. Estos estados de salud se basan en la salud agregada de los backends del productor de servicios (VMs o extremos de red), lo que proporciona a los consumidores un indicador de conmutación por error más preciso que la detección de valores atípicos, que infiere la salud a partir de las fallas en las respuestas.
Para habilitar la conmutación por error entre regiones, tanto el productor como el consumidor del servicio deben usar una implementación multirregional. Cuando configuras el estado de Private Service Connect, el estado de cada servicio publicado regional se propaga automáticamente al balanceador de cargas del consumidor. Si una instancia de servicio en una región deja de estar en buen estado, el balanceador de cargas del consumidor deja de enrutar el tráfico a ese servicio y, en cambio, lo enruta a una instancia de servicio en buen estado en una región alternativa.
Requisitos de Deployment
Para usar la verificación de estado de Private Service Connect para la conmutación por error automática, tanto el productor como el consumidor del servicio deben configurar sus recursos para una implementación multirregional, como se describe en esta sección. Para obtener más información sobre los requisitos de los tipos de balanceador de cargas y backends, consulta Especificaciones.
Configuración del productor:
- Implementa el servicio en cada región. Cada instancia regional del servicio debe configurarse en un balanceador de cargas regional que admita el acceso mediante un backend.
- Crea un adjunto de servicio para publicar cada instancia regional del servicio.
Configuración del consumidor:
- Crea un backend de Private Service Connect para acceder a los servicios publicados. El backend
debe basarse en un
balanceador de cargas que admita la conmutación por error entre regiones
y debe incluir la siguiente configuración:
- Un NEG de Private Service Connect en cada región que apunte al adjunto de servicio de esa región
- Un servicio de backend global que contiene los backends de NEG

En este ejemplo, se muestra un balanceador de cargas de aplicaciones externo global del consumidor que se conecta a un servicio que se publica en varias regiones. Acceder a un servicio multirregional con un balanceador de cargas global o interregional compatible permite que el consumidor de servicios aproveche el estado de Private Service Connect para la conmutación por error automática en todas las regiones (haz clic para agrandar).
Componentes de estado de Private Service Connect
El estado de Private Service Connect usa los siguientes componentes para admitir la conmutación por error automática entre regiones.
En este diagrama, se muestran los componentes clave del estado de Private Service Connect. Las políticas de agregación de estado definen las condiciones para que las fuentes de información de salud se consideren en buen estado. Las verificación de estado compuestas combinan los estados de salud de las fuentes individuales en un solo estado, y el resultado se entrega a un destino de salud.
Política de agregación de estado
Una política de agregación de estado es un recurso que creas para definir las condiciones que debe cumplir un servicio de backend para considerarse en buen estado. Una política agrega los estados de salud de los backends de un servicio de backend (VMs en un grupo de instancias o extremos de red en un NEG), según lo determinan las verificaciones de estado periódicas.
Un servicio de backend se considera en buen estado si se cumplen dos condiciones configurables:
Porcentaje de extremos en buen estado: Es el porcentaje mínimo de backends que deben estar en buen estado. El valor predeterminado es 60%.
Cantidad mínima de extremos en buen estado: Es la cantidad mínima de backends que deben estar en buen estado. El valor predeterminado es 1.
Por ejemplo, puedes crear una política que especifique que un servicio de backend debe tener al menos el 75% de sus backends en buen estado y, al menos, tres backends en buen estado. Si la cantidad de backends en buen estado cae por debajo de cualquiera de esos umbrales, se considera que el servicio de backend está en mal estado.
Fuente de información de salud
Una fuente de estado es un recurso que hace que el estado de un solo servicio de backend esté disponible para la agregación como parte de una verificación de estado compuesta. Cuando creas una fuente de datos de salud, especificas lo siguiente:
- Un servicio de backend para supervisar
- Una política de agregación de estado que determina el estado del servicio de backend
La fuente de estado usa las condiciones definidas en la política de agregación de estado para determinar el estado del servicio de backend asociado.
Verificación de estado compuesta
Una verificación de estado compuesta es un recurso que agrega los estados de salud de una o más fuentes de salud para producir un solo estado de salud compuesto para un servicio publicado regionalmente. El servicio publicado se considera en buen estado si cada una de las fuentes de estado asociadas se encuentra en buen estado. Si alguna de las fuentes de estado no está en buen estado, se considera que el servicio no está en buen estado.
Destino de salud
Un destino de estado recibe el estado de salud compuesto final de una verificación de estado compuesta. En el caso de un servicio publicado, el destino de la verificación de estado es la regla de reenvío del balanceador de cargas del productor. El estado de salud se propaga automáticamente a los balanceadores de cargas del consumidor que se conectan a esta regla de reenvío.
Especificaciones
El estado de Private Service Connect tiene las siguientes especificaciones.
Comportamiento:
- El estado de los backends individuales dentro de un servicio de backend se determina mediante verificaciones de estado estándar.
- Una política de agregación de estado configurable determina el estado general de un servicio de backend en función del estado de sus backends individuales.
- Una verificación de estado compuesta agrega los estados de buen estado de uno o más servicios de backend configurados como fuentes de buen estado, lo que crea un estado de buen estado compuesto.
- El estado de salud compuesto se proporciona a un destino de verificación de estado, que debe ser la regla de reenvío de un servicio publicado.
- El estado de salud compuesto se propaga automáticamente a los balanceadores de cargas del consumidor conectados, en los que los estados no saludables activan la conmutación por error automática entre regiones.
Configuración:
- El productor y el consumidor del servicio deben configurar recursos en una implementación multirregional.
- Cada instancia de servicio publicada debe publicarse con un balanceador de cargas que admita la conmutación por error entre regiones.
- Los servicios de backend que usas como fuentes de estado deben tener un esquema de balanceo de cargas de
INTERNAL
oINTERNAL_MANAGED
. - Las instancias de servicio publicadas deben tener uno de los siguientes tipos de backend:
- Se debe acceder a las instancias de servicio publicadas a través de backends de Private Service Connect basados en balanceadores de cargas que admitan la verificación de estado de Private Service Connect.
- Todos los recursos de estado de Private Service Connect son regionales y deben estar en la misma región que el servicio que supervisas.
- Un recurso de fuente de estado debe hacer referencia exactamente a un servicio de backend.
- Un recurso de verificación de estado compuesta debe hacer referencia a entre 1 y 10 fuentes de estado.
- Una regla de reenvío solo puede ser el destino de la verificación de estado de una verificación de estado compuesta.
Limitaciones
El estado de Private Service Connect tiene las siguientes limitaciones:
- Los estados de salud compuestos que produce la verificación de estado de Private Service Connect solo son visibles para el balanceador de cargas del consumidor y no se pueden ver en los registros.
- Todos los recursos de estado de Private Service Connect, incluidos los servicios de backend y las reglas de reenvío a los que hacen referencia, deben existir en el mismo proyecto.
- No puedes usar el estado de salud compuesto de un servicio como fuente de salud para otro servicio.
- No hay ningún modo para probar una configuración de verificación de estado que no afecte a los consumidores conectados. Cualquier verificación de estado compuesta configurada puede activar la conmutación por error de inmediato.
- El estado de Private Service Connect solo admite backends de Private Service Connect que acceden a servicios publicados.
Precios
No se aplican cargos adicionales por usar el estado de Private Service Connect. Sin embargo, se te cobra por los recursos y el tráfico de red en tu red de VPC.
Para obtener más información, consulta Precios de VPC.
¿Qué sigue?
- Para configurar el estado de Private Service Connect, consulta Configura el estado de Private Service Connect para la conmutación por error automática entre regiones.