Un balanceador de carga de red de paso a través externo es un balanceador de carga de capa 4 regional. Los balanceadores de carga de red con paso a través externos distribuyen el tráfico TCP y UDP entre instancias de máquinas virtuales (VM) de backend en la misma región de una red de nube privada virtual (VPC). Un balanceador de carga de red de paso a través externo puede recibir tráfico de cualquiera de los siguientes elementos:
- Cualquier cliente de Internet
- Google Cloud Máquinas virtuales con IPs externas
- Google Cloud Máquinas virtuales que tienen acceso a Internet a través de Cloud NAT o NAT basado en instancias
En función de la configuración de la regla de reenvío, cada balanceador de carga basado en un grupo de destino admite uno de los siguientes tipos de tráfico de protocolo:
- TCP
- UDP
- TCP y UDP
El ámbito del balanceador de carga es regional, no global. Esto significa que todas las instancias de backend de un balanceador de carga de red de paso a través externo deben estar ubicadas en la misma región. Puedes colocar backends en cualquier zona de la región.
Los balanceadores de carga de red de paso a través externos admiten todos los puertos. Puedes usar un balanceador de carga de red de paso a través externo para balancear la carga del tráfico TCP o UDP. Como el balanceador de carga es un balanceador de carga de transferencia, tus backends terminan la conexión TCP balanceada o los paquetes UDP. Por ejemplo, puedes ejecutar un servidor web HTTPS en tus backends y usar un balanceador de carga de red pasante externo para enrutar las solicitudes a él, terminando TLS en tus propios backends.
Si vas a crear aplicaciones en GKE, te recomendamos que utilices el controlador de servicio de GKE integrado, que despliega balanceadores de carga en nombre de los usuarios de GKE. Google Cloud Es igual que la arquitectura de balanceo de carga independiente, excepto que su ciclo de vida está totalmente automatizado y controlado por GKE. Para obtener más información, consulta Exponer aplicaciones mediante servicios.
Arquitectura
El balanceador de carga se compone de varios componentes de configuración. Un solo balanceador de carga puede tener lo siguiente:
- Un grupo de destino
- Varias reglas de reenvío
Un balanceador de carga de red de paso a través 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 del balanceador de carga. Especifica las instancias de backend entre las que se equilibra la carga del tráfico. Cada regla de reenvío es un frontend del balanceador de carga. Ten en cuenta que hay límites en el número de reglas de reenvío y grupos de destino por proyecto.
Los balanceadores de carga de red de paso a través externos equilibran la carga de tus sistemas en función de los datos del protocolo IP entrantes, como la dirección, el puerto y el tipo de protocolo.
El balanceador de carga de red de paso a través externo es un balanceador de carga de paso a través, por lo que tus backends reciben la solicitud original del cliente. El balanceador de carga de red de paso a través externo no descarga ni proxyiza el protocolo de seguridad en la capa de transporte (TLS). El tráfico se dirige directamente a tus VMs.
Cuando creas una regla de reenvío para el balanceador de carga, recibes una dirección IP virtual (VIP) efímera o reservas una VIP que procede de un bloque de red regional.
Después, asocia esa regla de reenvío a tus grupos de destino. La dirección IP virtual se envía mediante Anycast desde los puntos de presencia globales de Google, pero los back-ends son regionales. El balanceador de carga no puede tener backends que abarquen varias regiones.
Puedes usar Google Cloud cortafuegos para controlar o filtrar el acceso a las VMs de backend.
El balanceador de carga de red de paso a través externo examina los puertos de origen y de destino, la dirección IP y el protocolo para determinar cómo reenviar los paquetes. En el caso del tráfico TCP, puede modificar el comportamiento de reenvío del balanceador de carga configurando la afinidad de sesión. El balanceador de carga de red de paso a través externo reenvía los paquetes a la primera interfaz de red (nic0) de las instancias del grupo de destino.
El balanceador de carga conserva las direcciones IP de origen de los paquetes entrantes. La dirección IP de destino de los paquetes entrantes es la dirección IP externa regional asociada a la regla de reenvío del balanceador de carga.
Algoritmo de distribución de carga
De forma predeterminada, para distribuir el tráfico a las instancias, el valor de afinidad de sesión se define como NONE. Cloud Load Balancing elige una instancia en función de 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 las instancias y que cada nueva conexión puede dirigirse a una instancia diferente. Todos los paquetes de 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 carga.
Independientemente del ajuste de afinidad de sesión, todos los paquetes de una conexión se dirigen a la instancia elegida hasta que se cierra la conexión. Una conexión ya establecida no influye en las decisiones de balanceo de carga de las nuevas conexiones entrantes. Esto puede provocar un desequilibrio entre los back-ends si se usan conexiones TCP de larga duración.
Puedes elegir otro ajuste de afinidad de sesión si necesitas que un cliente se conecte varias veces a la misma instancia.
Grupos de destino
Un recurso de grupo de destino define un grupo de instancias que deben recibir el tráfico entrante 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, así como de 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 a las instancias, consulte la sección Algoritmo de distribución de carga.
Los balanceadores de carga de red de paso a través externos no son proxies. Las respuestas de las VMs backend van directamente a los clientes, no vuelven a pasar por el balanceador de carga. El balanceador de carga conserva las direcciones IP de origen de los paquetes. La dirección IP de destino de los paquetes entrantes es la dirección IP externa regional asociada a la regla de reenvío del balanceador de carga. Por lo tanto:
Las instancias que participan como VMs de backend de balanceadores de carga de red de paso a través externos deben ejecutar el entorno de invitado de Linux, el entorno de invitado de Windows u otros procesos que proporcionen una función equivalente.
El entorno del SO invitado (o un proceso equivalente) es responsable de configurar las rutas locales en cada VM backend. Estas rutas permiten que la VM acepte paquetes cuyo destino coincida con la dirección IP de la regla de reenvío del balanceador de carga.
En las instancias de backend que aceptan tráfico balanceado de carga, debes configurar el software para que se enlace a la dirección IP asociada a la regla de reenvío del balanceador de carga (o a cualquier dirección IP,
0.0.0.0/0).
Los balanceadores de carga de red con paso a través externos admiten el autoescalador de Compute Engine, que permite a los usuarios realizar el autoescalado 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 Escalado basado en el uso de CPU.
Si quieres que tu grupo de destino contenga una sola instancia de VM, te recomendamos que utilices la función reenvío de protocolos.
Los grupos de destino solo se pueden usar con reglas de reenvío que gestionen el tráfico TCP y UDP. En el caso de 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 carga. Para usar el balanceo de carga, debes crear una regla de reenvío que dirija el tráfico a grupos de destino específicos. No es posible balancear la carga del tráfico sin una regla de reenvío.
Cada regla de reenvío relaciona una dirección IP, un protocolo y, opcionalmente, un intervalo de puertos concretos con un único grupo de destino. Cuando se envía tráfico a una dirección IP externa que sirve una regla de reenvío, esta regla dirige el tráfico al grupo de destino correspondiente.
Si vas a balancear la carga de paquetes UDP que probablemente se fragmenten antes de llegar a tu red de VPC, consulta Balanceo de carga y paquetes UDP fragmentados. Google Cloud
Los balanceadores de carga de red de paso a través externos basados en grupos de destino admiten los siguientes protocolos para cada regla de reenvío: TCP o UDP. Si quieres que el balanceador de carga reenvíe todo el tráfico del protocolo IP, debes usar un balanceador de carga de red de paso a través externo basado en servicios de backend.
Varias reglas de reenvío
Puede configurar varias reglas de reenvío externas regionales para el mismo balanceador de carga de red de paso a través externo. Opcionalmente, cada regla de reenvío puede tener una dirección IP externa regional diferente, o varias reglas de reenvío pueden tener la misma dirección IP externa regional.
Configurar varias reglas de reenvío externas regionales puede ser útil en los siguientes casos prácticos:
- Necesitas configurar más de una dirección IP externa para el mismo grupo de destino.
- Necesitas configurar intervalos de puertos o protocolos diferentes con la misma dirección IP externa para el mismo grupo de destino.
Cuando uses varias reglas de reenvío, asegúrate de configurar el software que se ejecuta en tus VMs de backend para que se enlace 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 carga es la dirección IP externa regional asociada a la regla de reenvío externa regional correspondiente.
Comprobaciones del estado
Las comprobaciones del estado aseguran que Compute Engine reenvíe las conexiones nuevas solo a las instancias que estén activas y preparadas para recibirlas. Compute Engine envía solicitudes de comprobación del estado a cada instancia con la frecuencia especificada. Cuando una instancia supera el número permitido de fallos de comprobación del estado, deja de considerarse apta para recibir tráfico nuevo.
Para permitir el cierre ordenado de las conexiones TCP, las conexiones existentes no se terminan de forma activa. Sin embargo, no se garantiza que las conexiones existentes a un backend no operativo sigan siendo viables durante largos periodos. Si es posible, debes iniciar un proceso de cierre ordenado lo antes posible para tu backend en mal estado.
El comprobador de estado sigue consultando las instancias incorrectas y devuelve una instancia al grupo cuando se produce el número especificado de comprobaciones correctas. Si todas las instancias están marcadas como UNHEALTHY, el balanceador de carga dirige el tráfico nuevo a todas las instancias.
Los balanceadores de carga de red de paso a través externos se basan en comprobaciones de estado HTTP antiguas para determinar el estado de las instancias. Aunque tu servicio no use HTTP, debes ejecutar un servidor web básico en cada instancia que pueda consultar el sistema de comprobación del estado.
Las comprobaciones de estado HTTPS antiguas no se admiten en los balanceadores de carga de red de paso a través externos y no se pueden usar con la mayoría de los demás tipos de balanceadores de carga.
Reglas de cortafuegos
Las comprobaciones del estado de los balanceadores de carga de red de paso a través externos se envían desde estos intervalos de IP. Deberás crear reglas de cortafuegos de entrada que permitan el tráfico de esos intervalos.
Los balanceadores de carga de red de paso a través externos son balanceadores de carga de paso a través, lo que significa que tus reglas de cortafuegos deben permitir el tráfico procedente de las direcciones IP de origen del cliente. Si tu servicio está abierto a Internet, lo más fácil es permitir el tráfico de todos los intervalos de IP. Si quieres restringir el acceso para que solo se permitan determinadas direcciones IP de origen, puedes configurar reglas de cortafuegos para aplicar esa restricción, pero debes permitir el acceso desde los intervalos de IPs de comprobación del estado.
Para ver un ejemplo de regla de cortafuegos y un ejemplo de configuración, consulta Reglas de cortafuegos para balanceadores de carga de red de transferencia externa.
Direcciones IP de los paquetes de solicitud y de respuesta
Cuando una VM de backend recibe un paquete con balanceo de carga de un cliente, el origen y el destino del paquete son los siguientes:
- Origen: la dirección IP externa asociada a una Google Cloud VM o la dirección IP de un sistema que se puede enrutar a través de Internet y que se conecta al balanceador de carga.
- Destino: la dirección IP de la regla de reenvío del balanceador de carga.
Como el balanceador de carga es de paso (no un proxy), los paquetes llegan con la dirección IP de destino de la regla de reenvío del balanceador de carga. Configura el software que se ejecuta en las VMs de backend para que haga lo siguiente:
- Escuchar (enlace a) la dirección IP de la regla de reenvío del balanceador de carga o cualquier dirección IP (
0.0.0.0o::) - Si el protocolo de la regla de reenvío del balanceador de carga admite puertos, escucha (enlace a) un puerto incluido en la regla de reenvío del balanceador de carga.
Los paquetes de retorno se envían directamente desde las VMs de backend del balanceador de carga al cliente. Las direcciones IP de origen y de destino del paquete de retorno dependen del protocolo:
- TCP está orientado a la conexión, por lo que las VMs de backend deben responder con paquetes cuyas direcciones IP de origen coincidan con la dirección IP de la regla de reenvío para que el cliente pueda asociar los paquetes de respuesta con la conexión TCP adecuada.
- UDP no tiene conexión, por lo que las VMs de backend pueden enviar paquetes de respuesta cuya dirección IP de origen coincida con la dirección IP de la regla de reenvío o con cualquier dirección IP asignada a la VM. En la práctica, la mayoría de los clientes esperan que la respuesta proceda de la misma dirección IP a la que enviaron los paquetes.
En la siguiente tabla se resumen las fuentes y los destinos de los paquetes de respuesta:
| Tipo de tráfico | Fuente | Destino |
|---|---|---|
| TCP | La dirección IP de la regla de reenvío del balanceador de carga | Origen del paquete solicitante |
| UDP | En la mayoría de los casos, la dirección IP de la regla de reenvío del balanceador de carga 1 | Origen del paquete solicitante |
1 Cuando una VM tiene una dirección IP externa o cuando usas Cloud NAT, también puedes definir la dirección IP de origen del paquete de respuesta como la dirección IPv4 interna principal de la NIC de la VM. Google Cloud o Cloud NAT cambia 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 un caso avanzado, ya que 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 especiales
Google Cloud usa rutas especiales que no están definidas en tu red de VPC para las comprobaciones de estado. Para obtener más información, consulta Rutas de comprobaciones del estado.
Arquitectura de VPC compartida
En la siguiente tabla se resumen los componentes de VPC compartida de los balanceadores de carga de red passthrough externos:
| Dirección IP | Regla de reenvío | Componentes de backend |
|---|---|---|
| Una dirección IP externa regional debe definirse en el mismo proyecto que las instancias que se van a balancear de carga. | Una regla de reenvío externa regional debe definirse en el mismo proyecto que las instancias del grupo de destino (el proyecto de servicio). | El grupo de destino debe definirse en el mismo proyecto y en la misma región en los que se encuentran las instancias del grupo de destino. Las comprobaciones de estado asociadas al grupo de destino también deben definirse en el mismo proyecto. |
Distribución del tráfico
La forma en que un balanceador de carga de red de paso a través externo basado en un grupo de destino distribuye las nuevas conexiones 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 cifrado con hash que se usa para distribuir las nuevas conexiones de los clientes a las VMs de backend del balanceador de carga. Los balanceadores de carga basados en grupos de destino usan el parámetro sessionAffinity para configurar la afinidad de sesión.
Para obtener más información, consulta Usar grupos de destino.
Balanceo de carga y paquetes UDP fragmentados
Si vas a balancear la carga de paquetes UDP, ten en cuenta lo siguiente:
- Los paquetes no fragmentados se gestionan normalmente en todas las configuraciones.
- Es posible que los paquetes UDP se fragmenten antes de llegar a Google Cloud. Las redes intermedias pueden esperar a que lleguen todos los fragmentos antes de reenviarlos, lo que provoca un retraso, o pueden descartar fragmentos. Google Cloud no espera a que lleguen todos los fragmentos, sino que reenvía cada fragmento en cuanto llega.
Como los fragmentos UDP posteriores no contienen el puerto de destino, pueden producirse problemas en estas situaciones:
- Si la afinidad de sesión de los grupos de destino se define como
NONE(afinidad de 5 tuplas), es posible que se eliminen los fragmentos posteriores porque el balanceador de carga 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 carga, es posible que los fragmentos posteriores lleguen a la regla de reenvío incorrecta.
- Si la afinidad de sesión de los grupos de destino se define como
Si esperas recibir paquetes UDP fragmentados, haz lo siguiente:
- Define la afinidad de sesión como
NONE,CLIENT_IP_PROTOoCLIENT_IP.- Si se define la afinidad de sesión en
NONE, significa que no es necesario mantener la afinidad. Por lo tanto, el balanceador de carga usa un hash de 5 tuplas para seleccionar un backend para los paquetes no fragmentados, pero un hash de 3 tuplas para los paquetes fragmentados. - Si se asigna el valor
CLIENT_IP_PROTOoCLIENT_IPa la afinidad de sesión, los puertos de origen y de destino no se usarán para el cifrado hash, por lo que se calculará el mismo hash para los paquetes fragmentados y no fragmentados.
- Si se define la afinidad de sesión en
- Usa solo una regla de reenvío UDP por dirección IP con balanceo de carga. De esta forma, se asegura de que todos los fragmentos lleguen a la misma regla de reenvío.
Con estos ajustes, los fragmentos UDP del mismo paquete se reenvían a la misma instancia para volver a ensamblarse.
Usar instancias de destino como backends
Si usas instancias de destino como backends del balanceador de carga de red de transferencia externo y esperas paquetes UDP fragmentados, usa solo una regla de reenvío UDP por dirección IP balanceada de carga y configura la regla de reenvío para que acepte tráfico en todos los puertos (0-65535). De esta forma, todos los fragmentos llegarán a la misma regla de reenvío aunque no tengan el mismo puerto de destino.
Limitaciones
- No puedes usar la consola de Google Cloud para crear balanceadores de carga de red externos de transferencia basados en grupos de destino. En su lugar, usa gcloud o la API REST.
- Los balanceadores de carga de red de paso a través externos basados en grupos de destino no admiten Cloud Logging.
Siguientes pasos
- Cloud Armor admite la protección de red avanzada contra DDoS para balanceadores de carga de red de pases externos. Para obtener más información, consulta Configurar la protección de red avanzada contra DDoS.
- Para configurar un balanceador de carga de red de paso a través externo y distribuir el tráfico entre un conjunto de instancias de Apache, consulta Configurar un balanceador de carga de red de paso a través externo con grupos de destino.
- Para saber cómo funcionan los balanceadores de carga de red de paso a través externos con servicios de backend regionales en lugar de grupos de destino, consulta los siguientes artículos:
- Descripción general del balanceador de carga de red de paso a través externo basado en el servicio de backend
- Configurar un balanceador de carga de red de paso a través externo con servicios de backend
- Pasar de los grupos de destino a los servicios de backend en los balanceadores de carga de red de paso a través externos