Los balanceadores de carga de red proxy son balanceadores de carga de proxy inverso de capa 4 que distribuyen el tráfico TCP a los back-ends de tu red de Google Cloud nube privada virtual (VPC) Google Cloud o de otros entornos de nube. El tráfico se termina en la capa de balanceo de carga y, a continuación, se reenvía al backend disponible más cercano mediante TCP.
Los balanceadores de carga de red de proxy están diseñados para el tráfico TCP únicamente, con o sin SSL. Si el tráfico es HTTP(S), te recomendamos que uses un balanceador de carga de aplicaciones.
Los balanceadores de carga de red proxy admiten las siguientes funciones:
- Descarga de TLS/SSL para balanceadores de carga externos. Puedes usar un balanceador de carga de red de proxy externo global o un balanceador de carga de red de proxy clásico para delegar TLS en la capa de balanceo de carga mediante un proxy SSL.
- Compatibilidad con todos los puertos. Estos balanceadores de carga permiten cualquier puerto válido del 1 al 65535. Para obtener más información, consulta las especificaciones de los puertos.
- Reasignación de puertos. El puerto que usa la regla de reenvío del balanceador de carga no tiene por qué coincidir con el puerto que se usa al establecer conexiones con sus backends. Por ejemplo, la regla de reenvío podría usar el puerto TCP 80, mientras que la conexión a los back-ends podría usar el puerto TCP 8080.
- Transmite la dirección IP de origen original. Puede usar el protocolo PROXY para reenviar la dirección IP de origen y la información del puerto del cliente a los back-ends del balanceador de carga.
En el siguiente diagrama se muestra una arquitectura de balanceador de carga de red de proxy de ejemplo.
Los balanceadores de carga de red de proxy están disponibles en los siguientes modos de implementación:
Balanceador de carga de red de proxy externo: balancea la carga del tráfico procedente de clientes de Internet. Para obtener información sobre la arquitectura, consulta el artículo Arquitectura del balanceador de carga de red con proxy externo.
Modo de despliegue Nivel de servicio de red Esquema de balanceo de carga † Dirección IP Puertos de frontend Global external Nivel premium EXTERNAL_MANAGED IPv4
IPv6Puede hacer referencia a un puerto entre 1 y 65535. Clásico Global en el nivel Premium
Regional en el nivel Estándar
EXTERNO IPv4
IPv6 (requiere el nivel Premium)Regional externa Nivel Premium o Estándar EXTERNAL_MANAGED IPv4 Balanceador de carga de red de proxy interno: balancea la carga del tráfico dentro de tu red de VPC o de las redes conectadas a tu red de VPC. Para obtener información sobre la arquitectura, consulta el artículo Arquitectura del balanceador de carga de red de proxy interno.
Modo de despliegue Nivel de servicio de red Esquema de balanceo de carga † Dirección IP Puertos de frontend Regional interna Nivel premium INTERNAL_MANAGED IPv4 Puede hacer referencia a un puerto entre 1 y 65535. Interno entre regiones Nivel premium INTERNAL_MANAGED IPv4
† El esquema de balanceo de carga es un atributo de la regla de reenvío y del servicio de backend de un balanceador de carga, e indica si el balanceador de carga se puede usar para el tráfico interno o externo. El término *_MANAGED
en el esquema de balanceo de carga indica que el balanceador de carga se implementa como un servicio gestionado en Google Front Ends (GFEs) o como un servicio gestionado en el proxy Envoy de código abierto. En un esquema de balanceo de carga *_MANAGED
, las solicitudes se enrutan al GFE o al proxy de Envoy.
Balanceador de carga de red del proxy externo
El balanceador de carga de red del proxy externo distribuye el tráfico procedente de Internet a los back-ends de tu red de VPC Google Cloud , on-premise o en otros entornos de nube. Estos balanceadores de carga se pueden implementar en uno de los siguientes modos: global, regional o clásico.
Los balanceadores de carga de red de proxy externo admiten las siguientes funciones:
- Cancelación de IPv6. Los balanceadores de carga externos admiten direcciones IPv4 e IPv6 para el tráfico de clientes. Las solicitudes IPv6 de los clientes se terminan en la capa de balanceo de carga y, a continuación, se envían a tus backends a través de IPv4.
Descarga de TLS/SSL. Puedes usar un balanceador de carga de red con proxy externo global o un balanceador de carga de red con proxy clásico para descargar TLS en la capa de balanceo de carga mediante un proxy SSL. Las nuevas conexiones se reenvían a los back-ends disponibles más cercanos mediante SSL (opción recomendada) o TCP. Puedes configurar los siguientes aspectos de tu implementación:
- Mejor aprovechamiento de los back-ends. El procesamiento de SSL puede requerir una gran cantidad de recursos de la CPU si los cifrados utilizados no son eficientes. Para maximizar el rendimiento de la CPU, usa certificados SSL ECDSA y TLS 1.2, y prefiere el paquete de cifrado
ECDHE-ECDSA-AES128-GCM-SHA256
para SSL entre el balanceador de carga y tus instancias de backend. - Políticas de SSL. Las políticas de SSL te permiten controlar las funciones de SSL que tu balanceador de carga negocia con los clientes.
- Mejor aprovechamiento de los back-ends. El procesamiento de SSL puede requerir una gran cantidad de recursos de la CPU si los cifrados utilizados no son eficientes. Para maximizar el rendimiento de la CPU, usa certificados SSL ECDSA y TLS 1.2, y prefiere el paquete de cifrado
Integración con Cloud Armor. Puedes usar las políticas de seguridad de Cloud Armor para proteger tu infraestructura frente a ataques de denegación de servicio distribuido (DDoS) y otros ataques dirigidos.
Control geográfico sobre dónde se termina TLS. El balanceador de carga finaliza TLS en ubicaciones distribuidas por todo el mundo para minimizar la latencia entre los clientes y el balanceador de carga. Si necesitas controlar geográficamente dónde se termina TLS, puedes usar el nivel de red estándar para obligar al balanceador de carga a terminar TLS solo en los backends que se encuentren en una región específica. Para obtener más información, consulta Configurar el nivel Estándar.
Asistencia para App Hub. Los recursos que usan los balanceadores de carga de red de proxy externos regionales se pueden designar como servicios en las aplicaciones de App Hub.
En el siguiente diagrama, el tráfico de los usuarios de la ciudad A y la ciudad B finaliza en la capa de balanceo de carga y se establece una conexión independiente con el backend seleccionado.
Para obtener más información, consulta el artículo sobre el balanceador de carga de red del proxy externo.
Balanceador de carga de red de proxy interno
El balanceador de carga de red de proxy interno es un balanceador de carga regional de capa 4 basado en proxy Envoy que te permite ejecutar y escalar el tráfico de tu servicio TCP mediante una dirección IP interna a la que solo pueden acceder los clientes que estén en la misma red de VPC o que estén conectados a tu red de VPC.
El balanceador de carga distribuye el tráfico TCP a los backends alojados enGoogle Cloud, on-premise o en otros entornos de nube. Estos balanceadores de carga se pueden implementar en uno de los siguientes modos: entre regiones o regional.
Los balanceadores de carga de red de proxy interno admiten las siguientes funciones:
- Políticas de localidad. En un grupo de instancias de backend o en un grupo de puntos de conexión de red, puedes configurar cómo se distribuyen las solicitudes a las instancias o los endpoints miembros.
- Acceso global. Cuando el acceso global está habilitado, los clientes de cualquier región pueden acceder al balanceador de carga.
- Acceso desde redes conectadas. Puedes hacer que tu balanceador de carga interno sea accesible para los clientes de redes que no sean su propia red de VPC Google Cloud. Las otras redes deben conectarse a la red de VPC del balanceador de carga mediante el emparejamiento entre redes de VPC, Cloud VPN o Cloud Interconnect.
- Asistencia para App Hub. Los recursos que usan los balanceadores de carga de red con proxy internos regionales se pueden designar como servicios en las aplicaciones de App Hub.
Para obtener más información, consulta el artículo Descripción general del balanceador de carga de red de proxy interno.
Alta disponibilidad y conmutación por error entre regiones
Puedes configurar un balanceador de carga de red con proxy interno entre regiones en varias regiones para disfrutar de las siguientes ventajas:
Si los backends de una región concreta no funcionan, el tráfico se redirige correctamente a los backends de otra región.
En el ejemplo de implementación de conmutación por error entre regiones se muestra lo siguiente:
- Un balanceador de carga de red de proxy interno multirregional con una dirección IP virtual de frontend en la región A de tu red de VPC. Tus clientes también se encuentran en la región A.
- Un servicio backend global que hace referencia a los backends de la Google Cloud región A y la región B.
- Cuando los back-ends de la región A no funcionan, el tráfico se redirige a la región B.
Balanceador de carga de red de proxy interno entre regiones con una implementación de conmutación por error entre regiones (haz clic en la imagen para ampliarla). Los balanceadores de carga de red con proxy internos entre regiones también pueden proteger tu aplicación frente a interrupciones regionales completas sirviendo tráfico a tu cliente desde proxies y back-ends de otra región.
En el ejemplo de implementación de alta disponibilidad se muestra lo siguiente:
- Un balanceador de carga de red con proxy interno entre regiones con IPs virtuales de frontend en las regiones A y B de tu red de VPC. Tus clientes se encuentran en la región A.
Puedes hacer que el balanceador de carga sea accesible mediante VIPs de frontend de dos regiones.
Balanceador de carga de red de proxy interno multirregional con despliegue de alta disponibilidad (haz clic para ampliar).
Para obtener información sobre cómo configurar una implementación de alta disponibilidad, consulta los siguientes artículos:
- Configurar un balanceador de carga de red de proxy interno multirregional con backends de grupos de instancias de VM
- Configurar un balanceador de carga de red de proxy interno multirregional con conectividad híbrida