Un balanceador de cargas de red de transferencia externo es un balanceador de cargas regional de capa 4. Los balanceadores de cargas de red de transferencia externos distribuyen el tráfico de TCP y UDP entre instancias de máquina virtual (VM) de backend en la misma región en una red de nube privada virtual (VPC). Un balanceador de cargas de red de transferencia externo puede recibir tráfico de cualquiera de los siguientes:
- Cualquier cliente en Internet
- VM de Google Cloud con IP externas
- VM de Google Cloud que tienen acceso a Internet a través de Cloud NAT o NAT basada en la instancia
Según la configuración de la regla de reenvío, cada balanceador de cargas basado en grupos de destino admite uno de los siguientes tipos de tráfico de protocolo:
- TCP
- UDP
- TCP y UDP
El alcance del balanceador de cargas es regional, no global. Esto significa que todas las instancias de backend de un balanceador de cargas de red de transferencia externo deben estar ubicadas en la misma región. Puedes colocar backends en cualquier zona de la región.
Los balanceadores de cargas de red de transferencia externos admiten todos los puertos. Puedes usar un balanceador de cargas de red de transferencia externo para balancear las cargas de tráfico de TCP o UDP. Debido a que el balanceador de cargas es un balanceador de cargas de paso, tus backends finalizan la conexión TCP o los paquetes UDP balanceados. Por ejemplo, puedes ejecutar un servidor web HTTPS en tus backends y usar un balanceador de cargas de red de transferencia externo para enrutar solicitudes a él, y finalizar la TLS en los backends.
Si compilas aplicaciones en GKE, te recomendamos que uses el controlador de servicios de GKE integrado, que implementa balanceadores de cargas de Google Cloud en nombre de los usuarios de GKE. Esto es lo mismo que la arquitectura de balanceo de cargas independiente, excepto que su ciclo de vida está completamente automatizado y controlado por GKE. Para obtener más información, consulta cómo exponer apps mediante servicios.
Arquitectura
El balanceador de cargas está compuesto por varios componentes de configuración. Un solo balanceador de cargas puede tener lo siguiente:
- Un grupo de destino
- Varias reglas de reenvío
Un balanceador de cargas de red de transferencia externo siempre tiene un grupo de destino. Varias reglas de reenvío pueden hacer referencia al grupo de destino.
El grupo de destino es un backend para el balanceador de cargas. Especifica las instancias de backend entre las que se balancea las cargas del tráfico. Cada regla de reenvío es un frontend para el balanceador de cargas. Ten en cuenta que hay límites en la cantidad de reglas de reenvío y grupos de destino por proyecto.
Los balanceadores de cargas de red de transferencia externos balancean la carga en tus sistemas en función de los datos del protocolo IP entrante, como la dirección, el puerto y el tipo de protocolo.
El balanceador de cargas de red de transferencia externo es un balanceador de cargas de transferencia, por lo que tus backends reciben la solicitud original del cliente. El balanceador de cargas de red de transferencia externo no aplica ninguna descarga o proxy de seguridad de la capa de transporte (TLS). El tráfico se enruta directamente a tus VM.
Cuando creas una regla de reenvío para el balanceador de cargas, recibes una dirección IP virtual (VIP) efímera o reservas una VIP que se origina en un bloque de red regional.
Luego debes asociar esa regla de reenvío con tus grupos de destino. La VIP se enruta mediante anycast desde los puntos de presencia globales de Google, pero los backends son regionales. El balanceador de cargas no puede tener backends que abarquen múltiples regiones.
Puedes usar firewalls de Google Cloud para controlar o filtrar el acceso a las VM de backend.
El balanceador de cargas de red de transferencia externo examina los puertos de origen y de destino, la dirección IP y el protocolo para determinar cómo reenviar paquetes. Para el tráfico de TCP, puedes modificar el comportamiento de reenvío del balanceador de cargas mediante la configuración de la afinidad de sesión. El balanceador de cargas de red de transferencia externo reenvía los paquetes a la primera interfaz de red (nic0) de las instancias en el grupo de destino.
El balanceador de cargas conserva las direcciones IP de origen de los paquetes entrantes. La dirección IP de destino para los paquetes entrantes es la dirección IP externa regional asociada con la regla de reenvío del balanceador de cargas.
Algoritmo de distribución de cargas
De forma predeterminada, el valor de afinidad de sesión se establece en NONE para distribuir el tráfico a las instancias. Cloud Load Balancing selecciona una instancia según un hash de la IP y el puerto de origen; la IP y el puerto de destino, y el protocolo. Esto significa que las conexiones TCP entrantes se distribuyen entre instancias y cada conexión nueva puede ir a una instancia diferente. Todos los paquetes para una conexión se dirigen a la misma instancia hasta que se cierra la conexión. Las conexiones establecidas no se tienen en cuenta en el proceso de balanceo de cargas.
A pesar de la configuración de afinidad de sesión, todos los paquetes para una conexión se dirigen a la instancia elegida hasta que se cierra la conexión. Una conexión existente no tiene impacto en las decisiones de balanceo de cargas para las nuevas conexiones entrantes. Esto puede provocar una pérdida de balance entre backends si se usan conexiones TCP de larga duración.
Puedes elegir una configuración de afinidad de sesión diferente si necesitas que varias conexiones de un cliente vayan a la misma instancia.
Grupos de destino
Un recurso de grupo de destino define un grupo de instancias que deben recibir tráfico entrante a partir de las reglas de reenvío. Cuando una regla de reenvío dirige el tráfico a un grupo de destino, Cloud Load Balancing elige una instancia de estos grupos de destino en función de un hash de la IP y el puerto de origen, y la IP y el puerto de destino. Cada grupo de destino opera en una sola región y distribuye el tráfico a la primera interfaz de red (nic0) de la instancia de backend. Para obtener más información sobre cómo se distribuye el tráfico en las instancias, consulta la sección algoritmo de distribución de cargas.
Los balanceadores de cargas de red de transferencia externos no son proxies. Las respuestas de las VM de backend van directo a los clientes, no pasan a través del balanceador de cargas. El balanceador de cargas conserva las direcciones IP de origen de los paquetes. La dirección IP de destino para los paquetes entrantes es la dirección IP externa regional asociada con la regla de reenvío del balanceador de cargas. Por lo tanto, sucede lo siguiente:
Las instancias que participan como VMs de backend para los balanceadores de cargas de red de transferencia externos deben ejecutar el entorno invitado de Linux o el entorno invitado de Windows adecuados, o algún otro proceso que proporcione una función equivalente.
El entorno de SO invitado (o un proceso equivalente) es responsable de configurar las rutas locales en cada VM de backend. Estas rutas permiten que la VM acepte paquetes con un destino que coincida con la dirección IP de la regla de reenvío del balanceador de cargas.
En las instancias de backend que aceptan el tráfico con balanceo de cargas, debes configurar el software para que se vincule con la dirección IP asociada a la regla de reenvío del balanceador de cargas (o a cualquier dirección IP,
0.0.0.0/0).
Los balanceadores de cargas de red de transferencia externos admiten el escalador automático de Compute Engine, que permite a los usuarios realizar ajuste de escala automático en los grupos de instancias de un grupo de destino en función de la utilización del backend. Para obtener más información, consulta la sección sobre Escalamiento según el uso de CPU.
Si deseas que tu grupo de destino contenga una sola instancia de VM, deberías considerar usar la característica de reenvío de protocolos en su lugar.
Los grupos de destino solo se pueden usar con reglas de reenvío que controlen el tráfico de TCP y UDP. Para todos los demás protocolos, debes crear una instancia de destino. Debes crear un grupo de destino antes de poder usarlo con una regla de reenvío. Cada proyecto puede tener hasta 50 grupos de destino.
Reglas de reenvío
Las reglas de reenvío funcionan junto con los grupos de destino para admitir el balanceo de cargas. Para usar el balanceo de cargas, debes crear una regla de reenvío que dirija el tráfico hacia grupos de destino específicos. No es posible balancear la carga de tu tráfico sin una regla de reenvío.
Cada regla de reenvío coincide con una dirección IP específica, un protocolo y, opcionalmente, un rango de puertos en un solo grupo de destino. Cuando el tráfico se envía a una dirección IP externa entregada por una regla de reenvío, esta dirige ese tráfico al grupo de destino correspondiente.
Si aplicas el balanceo de cargas a paquetes UDP que pueden fragmentarse antes de llegar a tu red de VPC de Google Cloud, consulta la sección sobre balanceo de cargas y paquetes UDP fragmentados.
Los balanceadores de cargas de red de transferencia externos basados en grupos de destino admiten los siguientes protocolos para cada regla de reenvío: TCP o UDP. Si deseas que el balanceador de cargas reenvíe todo el tráfico del protocolo IP, debes usar un balanceador de cargas de red de transferencia externo basado en servicios de backend.
Varias reglas de reenvío
Puedes configurar múltiples reglas de reenvío externas regionales para el mismo balanceador de cargas de red de transferencia externo. Opcionalmente, cada regla de reenvío puede tener una dirección IP externa regional diferente, o múltiples reglas de reenvío pueden tener la misma dirección IP externa regional.
La configuración de múltiples reglas de reenvío externas regionales puede ser útil para estos casos prácticos:
- Si debes configurar más de una dirección IP externa para el mismo grupo de destino.
- Debes configurar diferentes protocolos o rangos de puertos con la misma dirección IP externa para el mismo grupo de destino.
Cuando uses múltiples reglas de reenvío, asegúrate de configurar el software que se ejecuta en tus VM de backend para que se vincule a todas las direcciones IP necesarias. Esto es necesario porque la dirección IP de destino de los paquetes enviados a través del balanceador de cargas es la dirección IP externa regional asociada con la respectiva regla de reenvío externa regional.
Verificaciones de estado
Las verificaciones de estado garantizan que Compute Engine reenvíe las conexiones nuevas solo a las instancias que están activas y listas para recibirlas. Compute Engine envía solicitudes de verificación de estado a cada instancia según la frecuencia especificada. Una vez que una instancia supera la cantidad permitida de fallas de verificación de estado, ya no se la considera apta para recibir tráfico nuevo.
Para permitir un cierre y apagado ordenados de conexiones TCP, las conexiones existentes no se terminan de forma activa. Sin embargo, no se garantiza que las conexiones existentes a un backend en mal estado sigan siendo viables durante períodos prolongados. Si es posible, deberás iniciar un proceso de cierre ordenado lo antes posible para tu backend en mal estado.
El verificador de estado continúa realizando consultas a instancias en mal estado y muestra una instancia al grupo cuando se produce la cantidad especificada de verificaciones correctas. Si todas las instancias están marcadas como UNHEALTHY, el balanceador de cargas dirige el tráfico nuevo a todas las instancias existentes.
Los balanceadores de cargas de red de transferencia externos se basan en verificaciones de estado HTTP heredadas para determinar el estado de la instancia. Incluso si tu servicio no usa HTTP, debes ejecutar un servidor web básico en cada instancia que el sistema de verificación de estado pueda consultar.
Las verificaciones de estado HTTPS heredadas no son compatibles con los balanceadores de cargas de red de transferencia externos y no se pueden usar con la mayoría de los demás tipos de balanceadores de cargas.
Reglas de firewall
Las verificaciones de estado de los balanceadores de cargas de red de transferencia externos se envían desde estos rangos de IP. Deberás crear reglas de firewall de entrada permitida que acepten el tráfico de esos rangos.
Los balanceadores de cargas de red de transferencia externos son balanceadores de cargas de paso, lo que significa que las reglas de firewall deben permitir el tráfico de las direcciones IP de origen del cliente. Si tu servicio está abierto a Internet, es más fácil permitir el tráfico de todos los rangos de IP. Si deseas restringir el acceso a fin de que solo se permitan ciertas direcciones IP de origen, puedes configurar reglas de firewall para hacer cumplir esa restricción, pero debes permitir el acceso desde los rangos de IP de verificación de estado.
Si deseas ver un ejemplo de regla de firewall y de configuración, consulta las reglas de firewall para los balanceadores de cargas de red de transferencia externos.
Direcciones IP para paquetes de solicitud y devolución
Cuando una VM de backend recibe un paquete con balanceo de cargas de un cliente, el origen y el destino del paquete son los siguientes:
- Fuente: Es la dirección IP externa asociada con una VM de Google Cloud o una dirección IP enrutable por Internet de un sistema que se conecta al balanceador de cargas.
- Destino: Es la dirección IP de la regla de reenvío del balanceador de cargas.
Debido a que el balanceador de cargas es un balanceador de cargas de paso (no un proxy), los paquetes llegan a la dirección IP de destino de la regla de reenvío del balanceador de cargas. El software que se ejecuta en las VM de backend se debe configurar para hacer lo siguiente:
- Detecta (vincula) la dirección IP de la regla de reenvío del balanceador de cargas o cualquier dirección IP (
0.0.0.0o::) - Si el protocolo de la regla de reenvío del balanceador de cargas admite puertos: Detecta (vincula a) un puerto que se incluye en la regla de reenvío del balanceador de cargas.
Los paquetes de retorno se envían directamente desde las VM de backend del balanceador de cargas al cliente. Las direcciones IP de origen y destino del paquete de retorno dependen del protocolo:
- TCP está orientado a la conexión, por lo que las VM de backend deben responder con paquetes cuyas direcciones IP de origen coincidan con la dirección IP de la regla de reenvío. De esta forma, el cliente puede asociar los paquetes de respuesta con la conexión TCP adecuada.
- UDP no tiene conexión, por lo que las VM de backend pueden enviar paquetes de respuesta cuyas direcciones IP de origen coincidan con la dirección IP de la regla de reenvío o con cualquier dirección IP asignada para la VM. En términos prácticos, la mayoría de los clientes esperan que la respuesta provenga de la misma dirección IP a la que enviaron paquetes.
En la siguiente tabla, se muestra un resumen de los orígenes y destinos de los paquetes de respuesta:
| Tipo de tráfico | Fuente | Destino |
|---|---|---|
| TCP | Es la dirección IP de la regla de reenvío del balanceador de cargas. | Es el origen del paquete solicitante. |
| UDP | En la mayoría de los casos prácticos, la dirección IP de la regla de reenvío del balanceador de cargas † | Es el origen del paquete solicitante. |
† Cuando una VM tiene una dirección IP externa o cuando usas Cloud NAT, también es posible establecer la dirección IP de origen del paquete de respuesta a la dirección IPv4 interna principal de la NIC de la VM. Google Cloud o Cloud NAT cambian la dirección IP de origen del paquete de respuesta a la dirección IPv4 externa de la NIC o a una dirección IPv4 externa de Cloud NAT para enviar el paquete de respuesta a la dirección IP externa del cliente. No usar la dirección IP de la regla de reenvío como origen es una situación avanzada porque el cliente recibe un paquete de respuesta de una dirección IP externa que no coincide con la dirección IP a la que envió un paquete de solicitud.
Rutas de acceso de enrutamiento especiales
Google Cloud usa rutas especiales no definidas en tu red de VPC para las verificaciones de estado. Si deseas obtener más información, consulta Rutas de acceso para las verificaciones de estado.
Arquitectura de VPC compartida
En la siguiente tabla, se resumen los componentes de la VPC compartida para los balanceadores de cargas de red de traspaso externos:
| Dirección IP | Regla de reenvío | Componentes de backend |
|---|---|---|
| Debe definirse una dirección IP externa regional en el mismo proyecto que las instancias cuya carga se balancea. | Debe definirse una regla de reenvío regional externa en el mismo proyecto que las instancias en el grupo de destino (el proyecto de servicio). | El grupo de destino debe definirse en el mismo proyecto y en la misma región donde existen las instancias en el grupo de destino. Las verificaciones de estado asociadas con el grupo de destino también deben definirse en el mismo proyecto. |
Distribución del tráfico
La forma en que un balanceador de cargas de red de transferencia externo basado en grupos de destino distribuye conexiones nuevas depende de cómo se haya configurado la afinidad de sesión.
Afinidad de sesión
La afinidad de sesión controla el método de hash usado para distribuir conexiones nuevas de clientes a las VM de backend del balanceador de cargas. Los balanceadores de cargas de red basados en grupos de destino usan el parámetro sessionAffinity para configurar la afinidad de sesión.
Para obtener más información, consulta cómo usar grupos de destino.
Balanceo de cargas y paquetes UDP fragmentados
Si aplicas el balanceo de cargas a paquetes UDP, ten en cuenta lo siguiente:
- Los paquetes sin fragmentar se manejan con normalidad en todas las configuraciones.
- Los paquetes UDP pueden fragmentarse antes de llegar a Google Cloud. Las redes que intervienen pueden esperar a que lleguen todos los fragmentos antes de reenviarlos (esto causa demoras), o pueden descartar fragmentos. Google Cloud no espera que lleguen todos los fragmentos; los envía en cuanto llegan.
Debido a que los fragmentos UDP posteriores no contienen el puerto de destino, pueden ocurrir problemas en las siguientes situaciones:
- Si la afinidad de sesión de los grupos de destino se establece en
NONE(afinidad de 5 tuplas), los fragmentos posteriores se podrían descartar, porque el balanceador de cargas no puede calcular el hash de 5 tuplas. - Si hay más de una regla de reenvío de UDP para la misma dirección IP con balanceo de cargas, los fragmentos posteriores podrían llegar a una regla de reenvío incorrecta.
- Si la afinidad de sesión de los grupos de destino se establece en
Si se esperan paquetes UDP fragmentados, haz lo siguiente:
- Establece la afinidad de sesión en
NONE,CLIENT_IP_PROTOoCLIENT_IP.- Establecer la afinidad de sesión en
NONEindica que no es necesario mantener la afinidad. Por lo tanto, el balanceador de cargas usa un hash de 5 tuplas a fin de seleccionar un backend para paquetes no fragmentados, pero un hash de 3 tuplas para paquetes fragmentados. - Establecer la afinidad de sesión en
CLIENT_IP_PROTOoCLIENT_IPsignifica que los puertos de origen y destino no se utilizan para el hash y, por lo tanto, el mismo hash se calcula para paquetes fragmentados y no fragmentados.
- Establecer la afinidad de sesión en
- Usa una sola regla de reenvío de UDP por dirección IP con balanceo de cargas. Esto garantiza que todos los fragmentos lleguen a la misma regla de reenvío.
Con esta configuración, los fragmentos UDP del mismo paquete se reenvían a la misma instancia para su reensamblaje.
Usa instancias de destino como backends
Si usas instancias de destino como backends para el balanceador de cargas de red de transferencia externo y esperas paquetes UDP fragmentados, usa solo una regla de reenvío UDP por dirección IP con balanceo de cargas y configura la regla de reenvío para aceptar tráfico en todos los puertos 0-65535. Esto garantiza que todos los fragmentos lleguen a la misma regla de reenvío, incluso si no tienen el mismo puerto de destino.
Limitaciones
- No puedes usar la consola de Google Cloud para crear balanceadores de cargas de red de transferencia externos basados en grupos de destino. En su lugar, usa gcloud o la API de REST.
- Los balanceadores de cargas de red de transferencia externos no admiten el intercambio de tráfico entre redes de VPC.
¿Qué sigue?
- Google Cloud Armor admite la protección avanzada contra DSD de las redes para balanceadores de cargas de red de transferencia externos. Para obtener más información, consulta Configura la protección contra DSD de red avanzada.
- Para configurar un balanceador de cargas de red de transferencia externo y distribuir tráfico entre un conjunto de instancias de Apache, consulta Configura un balanceador de cargas de red de transferencia externo con grupos de destino.
- Para obtener información sobre cómo funcionan los balanceadores de cargas de red de transferencia externos con servicios de backend regionales en lugar de grupos de destino, consulta:
- Descripción general del balanceador de cargas de red de transferencia externa basado en servicios de backend.
- Configura un balanceador de cargas de red de transferencia externo con servicios de backend
- Transición de balanceadores de cargas de red de traspaso externos de grupos de destino a servicios de backend