Acerca de los servicios publicados
En este documento se ofrece una descripción general de cómo usar Private Service Connect para que un servicio esté disponible para los consumidores de servicios.
Como productor de servicios, puedes usar Private Service Connect para publicar servicios mediante direcciones IP internas en tu red de VPC. Los consumidores de servicios pueden acceder a los servicios publicados mediante direcciones IP internas en sus redes de VPC.
Para que un servicio esté disponible para los consumidores, debes crear una o varias subredes dedicadas. A continuación, crea un archivo adjunto de servicio que haga referencia a esas subredes. El adjunto de servicio puede tener diferentes preferencias de conexión.
Tipos de consumidores de servicios
Hay dos tipos de consumidores que pueden conectarse a un servicio de Private Service Connect:
Los endpoints se basan en una regla de reenvío.
Un punto final permite que los consumidores de servicios envíen tráfico desde su red de VPC a los servicios de la red de VPC del productor de servicios (haz clic para ampliar).
Los backends se basan en un balanceador de carga.
Un backend que usa un balanceador de carga de aplicaciones externo global permite que los consumidores de servicios con acceso a Internet envíen tráfico a los servicios de la red de VPC del productor de servicios (haz clic para ampliar).
Subredes de NAT
Los adjuntos de servicio de Private Service Connect se configuran con una o varias subredes NAT (también denominadas subredes de Private Service Connect). Los paquetes de la red de VPC del consumidor se traducen mediante la NAT de origen (SNAT) para que sus direcciones IP de origen originales se conviertan en direcciones IP de origen de la subred de NAT de la red de VPC del productor.
Los adjuntos de servicio pueden tener varias subredes NAT. Se pueden añadir subredes NAT adicionales al adjunto de servicio en cualquier momento sin interrumpir el tráfico.
Aunque una vinculación de servicio puede tener configuradas varias subredes NAT, una subred NAT no se puede usar en más de una vinculación de servicio.
Las subredes NAT de Private Service Connect no se pueden usar para recursos como instancias de máquina virtual o reglas de reenvío. Las subredes solo se usan para proporcionar direcciones IP para la SNAT de las conexiones de consumidores entrantes.
Tamaño de la subred NAT
El tamaño de la subred determina cuántos consumidores pueden conectarse a tu servicio. Si se consumen todas las direcciones IP de la subred NAT, se producirá un error en cualquier conexión adicional de Private Service Connect. Ten en cuenta lo siguiente:
Se consume una dirección IP de la subred NAT por cada punto final o backend que esté conectado al adjunto de servicio.
El número de conexiones TCP o UDP, clientes o redes de VPC de consumidor no afecta al consumo de direcciones IP de la subred NAT.
Si los consumidores usan la propagación de conexiones, se consumirá una dirección IP adicional por cada VPC de radio a la que se propaguen las conexiones y por cada endpoint.
Puedes controlar cuántas conexiones propagadas se crean configurando el límite de conexiones propagadas.
Cuando calcules cuántas direcciones IP necesitas para los puntos finales y los backends, ten en cuenta los servicios multiinquilino o los consumidores que usen el acceso multipunto para Private Service Connect.
Monitorización de subredes NAT
Para asegurarte de que las conexiones de Private Service Connect no fallen debido a que no hay direcciones IP disponibles en una subred NAT, te recomendamos que hagas lo siguiente:
- Monitoriza la
private_service_connect/producer/used_nat_ip_addressesmétrica de adjunto de servicio. Asegúrate de que el número de direcciones IP de NAT utilizadas no supere la capacidad de las subredes de NAT de un adjunto de servicio. - Monitoriza el estado de la conexión de las conexiones de los acoplamientos de servicio. Si una conexión tiene el estado Requiere atención, es posible que no haya más direcciones IP disponibles en las subredes NAT del archivo adjunto.
- En el caso de los servicios multiarrendatario, puedes usar los límites de conexión para asegurarte de que un solo consumidor no agote la capacidad de las subredes NAT de un adjunto de servicio.
Si es necesario, se pueden añadir subredes NAT al adjunto de servicio en cualquier momento sin interrumpir el tráfico.
Especificaciones de NAT
Ten en cuenta las siguientes características de NAT de Private Service Connect al diseñar el servicio que vas a publicar:
El tiempo de espera inactivo de la asignación UDP es de 30 segundos y no se puede configurar.
El tiempo de espera de inactividad de la conexión TCP establecida es de 20 minutos y no se puede configurar.
Para evitar que se agote el tiempo de espera de las conexiones de los clientes, haz una de las siguientes acciones:
Asegúrate de que todas las conexiones duren menos de 20 minutos.
Asegúrate de que se envíe tráfico con una frecuencia superior a una vez cada 20 minutos. Puedes usar un latido o un keepalive en tu aplicación, o keepalives de TCP. Por ejemplo, puedes configurar un keepalive en el proxy de destino de un balanceador de carga de aplicaciones interno regional o de un balanceador de carga de red con proxy interno regional.
El tiempo de espera de conexión inactiva transitoria de TCP es de 30 segundos y no se puede configurar.
Hay un retraso de dos minutos antes de que se pueda reutilizar cualquier quíntupla (dirección IP de origen y puerto de origen de la subred NAT, además del protocolo, la dirección IP y el puerto de destino).
SNAT para Private Service Connect no admite fragmentos de IP.
Número máximo de conexiones
Una sola VM de productor puede aceptar un máximo de 64.512 conexiones TCP simultáneas y 64.512 conexiones UDP de un solo consumidor de Private Service Connect (endpoint o backend). No hay límite en el número total de conexiones TCP y UDP que puede recibir un endpoint de Private Service Connect en conjunto en todos los back-ends de productores. Las VMs cliente pueden usar los 65.536 puertos de origen al iniciar conexiones TCP o UDP con un punto final de Private Service Connect. Toda la traducción de direcciones de red se realiza de forma local en el host del productor, lo que no requiere un grupo de puertos NAT asignado de forma centralizada.
Vinculaciones de servicio
Los productores de servicios exponen sus servicios a través de una vinculación de servicio.
- Para exponer un servicio, un productor de servicios crea una vinculación de servicio que hace referencia a un servicio de destino. El servicio de destino puede ser uno de los siguientes:
- La regla de reenvío de un balanceador de carga
- Una instancia de Secure Web Proxy
El URI de la vinculación de servicio tiene este formato:
projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME
Un adjunto de servicio solo puede tener un servicio de destino. Sin embargo, varios service attachments pueden compartir el mismo servicio de destino.
Los adjuntos de servicio te permiten controlar el acceso a tu servicio publicado, ver las conexiones y configurar límites de conexión. Para obtener más información, consulta Información sobre el control del acceso a los servicios publicados.
Estados de conexión
Los adjuntos de servicio tienen estados de conexión que describen el estado de sus conexiones. Para obtener más información, consulta Estados de la conexión.
Configuración de DNS
Para obtener información sobre la configuración de DNS de los servicios y los endpoints publicados que se conectan a servicios publicados, consulta Configuración de DNS de los servicios.
Configuración de varias regiones para la conmutación por error
Puedes hacer que un servicio esté disponible en varias regiones creando las siguientes configuraciones.
Configuración del productor:
- Implementa el servicio en cada región. Cada instancia regional del servicio debe configurarse en un balanceador de carga regional que admita el acceso por parte de un backend.
- Crea un archivo 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 carga que admita la conmutación por error entre regiones
e incluir la siguiente configuración:
- Un NEG de Private Service Connect en cada región que apunte a la vinculación de servicio de esa región
- Un servicio de backend global que contiene los backends de NEG
Esta configuración admite la conmutación por error automática entre regiones. Con la conmutación automática por error, si una instancia de servicio de una región deja de estar en buen estado, el balanceador de carga del consumidor deja de enrutar el tráfico a ese servicio y, en su lugar, lo enruta a una instancia de servicio en buen estado de otra región.
Para obtener más información, consulta las siguientes secciones:
- Información sobre el estado de Private Service Connect
- Conmutación por error automática entre regiones para los consumidores
Si usas un balanceador de carga de aplicaciones externo global, los consumidores de servicios con acceso a Internet pueden enviar tráfico a los servicios de la red de VPC del productor de servicios. Como el servicio se ha desplegado en varias regiones, el balanceador de carga del consumidor puede enrutar el tráfico a una instancia de servicio en buen estado de una región alternativa (haz clic para ampliar la imagen).
Traducción de la versión de IP
En el caso de los puntos finales de Private Service Connect que se conectan a servicios publicados (vinculaciones de servicio), la versión de IP de la dirección IP de la regla de reenvío del consumidor determina la versión de IP del punto final y el tráfico que sale de él. La dirección IP puede proceder de una subred solo IPv4, solo IPv6 o de pila dual. La versión de IP del endpoint puede ser IPv4 o IPv6, pero no ambas.
En el caso de los servicios publicados, la versión de IP del adjunto de servicio se determina mediante la dirección IP de la regla de reenvío o la instancia de Secure Web Proxy asociadas. Esta dirección IP debe ser compatible con el tipo de pila de la subred NAT del adjunto de servicio. La subred NAT puede ser una subred solo IPv4, solo IPv6 o de doble pila. Si la subred NAT es una subred de doble pila, se usa el intervalo de direcciones IPv4 o IPv6, pero no ambos.
Private Service Connect no admite la conexión de un punto final IPv4 con una vinculación de servicio IPv6. En este caso, la creación del endpoint falla y se muestra el siguiente mensaje de error:
Private Service Connect forwarding rule with an IPv4 address
cannot target an IPv6 service attachment.
Estas son las combinaciones posibles para las configuraciones compatibles:
- Endpoint IPv4 a adjunto de servicio IPv4
- Endpoint IPv6 a adjunto de servicio IPv6
-
Endpoint IPv6 a adjunto de servicio IPv4
En esta configuración, Private Service Connect traduce automáticamente entre las dos versiones de IP.
En el caso de las conexiones entre los backends de Private Service Connect y las vinculaciones de servicio, las reglas de reenvío del consumidor y del productor deben usar IPv4.
Funciones y compatibilidad
En las tablas siguientes, una marca de verificación indica que una función es compatible, y un símbolo de no indica que una función no es compatible.
En función del balanceador de carga de productor que se elija, el servicio de productor puede admitir el acceso mediante endpoints, backends o ambos.
Compatibilidad con endpoints
En esta sección se resumen las opciones de configuración disponibles para los consumidores y productores al usar endpoints para acceder a servicios publicados.
Configuración del consumidor
En esta tabla se resumen las opciones de configuración y las funciones admitidas de los endpoints que acceden a servicios publicados en función del tipo de productor de destino.
Configuración del productor
En esta tabla se resumen las opciones de configuración y las funciones admitidas de los servicios publicados a los que acceden los endpoints.
| Tipo de productor | Configuración del productor (servicio publicado) | |||
|---|---|---|---|---|
| Back-ends de productores admitidos | Protocolo PROXY (solo tráfico TCP) | Versión de IP | ||
| Balanceador de carga de aplicación interno entre regiones |
|
|
||
| Balanceador de carga de red de paso a través interno |
|
|
||
| Reenvío de protocolos interno (instancia de destino) |
|
|
||
| Servicios de asignación de puertos |
|
|
||
| Balanceador de carga de aplicación interno regional |
|
|
||
| Balanceador de carga de red de proxy interno regional |
|
|
||
| Secure Web Proxy |
|
|
||
Los distintos balanceadores de carga admiten diferentes configuraciones de puertos. Algunos admiten un solo puerto, otros admiten un intervalo de puertos y otros admiten todos los puertos. Para obtener más información, consulta las especificaciones de los puertos.
Compatibilidad con back-ends
Un backend de Private Service Connect para servicios publicados requiere dos balanceadores de carga: un balanceador de carga de consumidor y un balanceador de carga de productor. En esta sección se resumen las opciones de configuración disponibles para los consumidores y productores al usar back-ends para acceder a los servicios publicados.
Configuración del consumidor
En esta tabla se describen los balanceadores de carga del consumidor que admiten los backends de Private Service Connect para los servicios publicados, así como los protocolos de servicio de backend que se pueden usar con cada balanceador de carga del consumidor. Los balanceadores de carga de consumidor pueden acceder a los servicios publicados que se alojan en balanceadores de carga de productor compatibles.
| Balanceador de carga de consumidor | Protocolos | Versión de IP | Conmutación por error entre regiones |
|---|---|---|---|
|
IPv4 | ||
|
IPv4 | ||
|
Balanceador de carga de aplicación externo global Nota: No se admite el balanceador de carga de aplicaciones clásico. |
|
IPv4 | |
|
Balanceador de carga de red con proxy externo global Para asociar este balanceador de carga a un NEG de Private Service Connect, usa la CLI de Google Cloud o envía una solicitud de API. Nota: No se admite el balanceador de carga de red de proxy clásico. |
|
IPv4 | |
|
IPv4 | ||
|
IPv4 | ||
|
IPv4 | ||
|
IPv4 |
Configuración del productor
En esta tabla se describe la configuración de los balanceadores de carga de productores que admiten los backends de Private Service Connect para los servicios publicados.
| Tipo de productor | Configuración del productor (servicio publicado) | |||||
|---|---|---|---|---|---|---|
| Back-ends de productores admitidos | Protocolos de reglas de reenvío | Puertos de reglas de reenvío | Protocolo PROXY | Versión de IP | Asistencia de Private Service Connect | |
| Balanceador de carga de aplicación interno entre regiones |
|
|
Admite uno, varios o todos los puertos | IPv4 | ||
| Balanceador de carga de red de paso a través interno |
|
|
Consulta Configuración de puertos de productores. | IPv4 | ||
| Balanceador de carga de aplicación interno regional |
|
|
Admite un solo puerto | IPv4 | ||
| Balanceador de carga de red de proxy interno regional |
|
|
Admite un solo puerto | IPv4 | ||
| Secure Web Proxy |
|
|
No aplicable | IPv4 | ||
Configuración de puertos de productores
Cuando se publica un balanceador de carga de red interno de tipo pasarela mediante Private Service Connect, los consumidores que usan backends de Private Service Connect para acceder al servicio deben saber qué puerto usar para comunicarse con él. Ten en cuenta lo siguiente al crear la regla de reenvío del balanceador de carga de red de paso a través interno del productor:
- Te recomendamos que comuniques a los consumidores qué puerto se usa en la regla de reenvío del productor para que puedan especificarlo al crear un NEG.
Si los consumidores no especifican un puerto de productor al crear sus NEGs, el puerto de productor se determina en función de la configuración de la regla de reenvío del productor:
- Si la regla de reenvío del productor usa un solo puerto, el backend del consumidor usa el mismo puerto.
Si la regla de reenvío del productor usa varios puertos, se aplica lo siguiente:
- Si se incluye el puerto
443, el backend del consumidor usa el puerto443. - Si no se incluye el puerto
443, el backend del consumidor usará el primer puerto de la lista, después de que se haya ordenado alfabéticamente. Por ejemplo, si especificas el puerto80y el puerto1111, el backend del consumidor usará el puerto1111. Si cambias los puertos que usan los back-ends del productor, es posible que se interrumpa el servicio para los consumidores.
Por ejemplo, supongamos que creas un servicio publicado con una regla de reenvío que usa los puertos
443y8443, y VMs de backend que responden en los puertos443y8443. Cuando un backend de consumidor se conecta a este servicio, utiliza el puerto443para comunicarse.Si cambias las VMs de backend para que solo respondan en el puerto
8443, el backend del consumidor ya no podrá acceder al servicio publicado.
- Si se incluye el puerto
Si la regla de reenvío del productor usa todos los puertos, el consumidor del servicio debe especificar un puerto del productor al crear el NEG. Si no especifican un puerto, el backend del consumidor usa el puerto
1, que no funciona.
VPC compartida
Los administradores de proyectos de servicio pueden crear adjuntos de servicio en proyectos de servicio de VPC compartida que se conecten a recursos de redes de VPC compartida.
La configuración es la misma que la de un adjunto de servicio normal, excepto por lo siguiente:
- La regla de reenvío del balanceador de carga del productor está asociada a una dirección IP de la red de VPC compartida. La subred de la regla de reenvío debe compartirse con el proyecto de servicio.
- La vinculación de servicio usa una subred de Private Service Connect de la red de VPC compartida. Esta subred debe compartirse con el proyecto de servicio.
Almacenamiento de registros
Puedes habilitar los registros de flujo de VPC en las subredes que contengan las VMs de backend. Los registros muestran los flujos entre las VMs backend y las direcciones IP de la subred de Private Service Connect.
Controles de Servicio de VPC
Controles de Servicio de VPC y Private Service Connect son compatibles entre sí. Si la red de VPC en la que se ha implementado el punto final de Private Service Connect está en un perímetro de Controles de Servicio de VPC, el punto final forma parte del mismo perímetro. Cualquier servicio compatible con Controles de Servicio de VPC al que se acceda a través del endpoint está sujeto a las políticas de ese perímetro de Controles de Servicio de VPC.
Cuando creas un endpoint, se realizan llamadas a la API del plano de control entre los proyectos de consumidor y productor para establecer una conexión de Private Service Connect. Para establecer una conexión de Private Service Connect entre proyectos de consumidor y productor que no estén en el mismo perímetro de Controles de Servicio de VPC, no es necesario tener una autorización explícita con políticas de salida. La comunicación con los servicios compatibles con Controles de Servicio de VPC a través del endpoint está protegida por el perímetro de Controles de Servicio de VPC.
Ver la información de conexión de los consumidores
De forma predeterminada, Private Service Connect traduce la dirección IP de origen del consumidor a una dirección de una de las subredes de Private Service Connect de la red de VPC del productor de servicios. Si quieres ver la dirección IP de origen original del consumidor, puedes habilitar el protocolo PROXY cuando publiques un servicio. Private Service Connect admite la versión 2 del protocolo PROXY.
No todos los servicios admiten el protocolo PROXY. Para obtener más información, consulta Funciones y compatibilidad.
Si el protocolo PROXY está habilitado, puedes obtener la dirección IP de origen del consumidor y el ID de conexión de PSC (pscConnectionId) del encabezado del protocolo PROXY.
El formato de los encabezados del protocolo PROXY depende de la versión de IP del endpoint del consumidor. Si el balanceador de carga de tu adjunto de servicio tiene una dirección IPv6, los consumidores pueden conectarse con direcciones IPv4 e IPv6. Configure su aplicación para recibir y leer encabezados del protocolo PROXY para la versión IP del tráfico que debe recibir.
En el caso del tráfico de consumidores que fluye a través de una conexión propagada, la dirección IP de origen del consumidor y el ID de conexión de PSC hacen referencia al punto final de Private Service Connect que se propaga.
Cuando habilitas el protocolo PROXY en un adjunto de servicio, el cambio solo se aplica a las conexiones nuevas. Las conexiones actuales no incluyen el encabezado del protocolo PROXY.
Si habilita el protocolo PROXY, consulte la documentación del software del servidor web backend para obtener información sobre cómo analizar y procesar los encabezados del protocolo PROXY entrantes en las cargas útiles TCP de la conexión del cliente. Si el protocolo PROXY está habilitado en el adjunto de servicio, pero el servidor web backend no está configurado para procesar los encabezados del protocolo PROXY, las solicitudes web pueden estar mal formadas. Si las solicitudes tienen un formato incorrecto, el servidor no podrá interpretarlas.
El ID de conexión de Private Service Connect (pscConnectionId) se codifica en el encabezado del protocolo PROXY en formato de tipo, longitud y valor (TLV).
| Campo | Longitud del campo | Valor de campo |
|---|---|---|
| Tipo | 1 byte | 0xE0 (PP2_TYPE_GCP)
|
| Duración | 2 bytes | 0x8 (8 bytes) |
| Valor | 8 bytes | El pscConnectionId de 8 bytes en orden de red |
Puede ver el valor pscConnectionId de 8 bytes en la regla de reenvío del consumidor o en el archivo adjunto del servicio del productor.
El valor pscConnectionId es único a nivel global para todas las conexiones activas en un momento dado. Sin embargo, con el tiempo, es posible que se reutilice un pscConnectionId en los siguientes casos:
En una red de VPC determinada, si eliminas un punto final (regla de reenvío) y creas otro con la misma dirección IP, es posible que se utilice el mismo valor de
pscConnectionId.Si eliminas una red de VPC que contiene puntos finales (reglas de reenvío), después de un periodo de espera de siete días, el valor
pscConnectionIdque se usó para esos puntos finales se podrá usar para otro punto final de otra red de VPC.
Puede usar los valores de pscConnectionId para depurar y rastrear las fuentes de los paquetes.
El servicio de productor
attachment tiene un ID de vinculación de servicio de Private Service Connect de 16 bytes independiente (pscServiceAttachmentId).
El valor pscServiceAttachmentId es un ID único global que identifica una vinculación de servicio de Private Service Connect. Puedes usar el valor pscServiceAttachmentId para la visibilidad y la depuración. Este valor no se incluye en el encabezado del protocolo PROXY.
Precios
Los precios de Private Service Connect se describen en la página de precios de VPC.
Cuotas
El número total de puntos finales de Private Service Connect y conexiones propagadas, de cualquier consumidor, que pueden acceder a tu red de VPC de productor se controla mediante la PSC ILB consumer forwarding rules per producer VPC networkcuota.
Los endpoints contribuyen a esta cuota hasta que se eliminan, aunque se elimine el adjunto de servicio asociado o se configure para rechazar la conexión. Las conexiones propagadas contribuyen a esta cuota hasta que se elimina el endpoint asociado, aunque la propagación de conexiones esté inhabilitada en el centro de conectividad de red o se elimine el spoke de la conexión propagada.
Acceso in situ
Los servicios de Private Service Connect se ponen a disposición mediante puntos finales. Se puede acceder a estos endpoints desde hosts locales conectados compatibles. Para obtener más información, consulta Acceder al endpoint desde hosts locales.
Limitaciones
Los servicios publicados tienen las siguientes limitaciones:
- No se admiten los balanceadores de carga configurados con
varios protocolos (protocolo definido como
L3_DEFAULT). - Packet Mirroring no puede replicar paquetes del tráfico de servicios publicados de Private Service Connect.
- Debes usar la CLI de Google Cloud o la API para crear una vinculación de servicio que apunte a una regla de reenvío que se use para el reenvío de protocolo interno.
Para ver los problemas y las soluciones alternativas, consulta la sección Problemas conocidos.