Los balanceadores de cargas de red de transferencia externos globales son balanceadores de cargas de transferencia de capa 4 que distribuyen el tráfico externo entre backends (grupos de instancias o grupos de extremos de red) que pueden residir en varias regiones Cloud de Confiance . Estos balanceadores de cargas se compilan en Maglevs que se distribuyen globalmente y operan juntos a través del plano de control y la red global de Google.
Un balanceador de cargas de red de transferencia externo global dirige automáticamente el tráfico a la región de backend más cercana al punto en el que el tráfico del usuario ingresa a la red global deS3NS.
Siempre que los backends aptos estén configurados en dos o más regiones, se aplicará lo siguiente:
Si una región está al máximo de capacidad, el balanceador de cargas automáticamente desborda algunas de las conexiones de usuarios nuevos que exceden la capacidad de la región hacia las regiones más cercanas en las que haya capacidad disponible, mientras mantiene las conexiones existentes en la región actual.
Si una región está inactiva, el balanceador de cargas automáticamente conmuta por falla el tráfico a la siguiente región más cercana con capacidad disponible.
Los balanceadores de cargas de red de transferencia externos globales pueden recibir tráfico de las siguientes fuentes:
- Cualquier cliente en Internet
- Cloud de Confiance VMs con IPs externas
- Cloud de Confiance VMs que tienen acceso a Internet a través de Cloud NAT o NAT basada en instancias
Usa un balanceador de cargas de red de transferencia externo global en las siguientes circunstancias:
Necesitas un balanceador de cargas de capa 4 de alto rendimiento y de transferencia para el tráfico de TCP, UDP, ESP, GRE, ICMP y ICMPv6. El balanceador de cargas puede controlar tráfico IPv4 e IPv6.
Úsalo si necesitas recibir los paquetes originales sin proxy. Por ejemplo, si necesitas que se conserve la dirección IP de origen de cliente.
Necesitas entregar tráfico a backends en varias Cloud de Confiance regiones con baja latencia, usando la misma dirección IP de difusión por IP.
Necesitas que tu implementación sea resistente a las fallas y sobrecargas regionales del backend, y que redireccione el tráfico de forma automática y correcta a la siguiente región más cercana con capacidad disponible.
Para usar un balanceador de cargas de red de transferencia externo global, tu implementación debe cumplir con el siguiente requisito:
- Si se entrega tráfico TLS (SSL), tus backends deben finalizar el tráfico SSL. El balanceador de cargas de red de transferencia externo global no admite la finalización de SSL.
Características clave
Los balanceadores de cargas de red de transferencia externos globales admiten las siguientes funciones clave.
Alta disponibilidad por diseño
El balanceador de cargas te proporciona dos direcciones IP Anycast externas globales, cada una de ellas entregada por una infraestructura de servidor de plano de datos y control de balanceo de cargas global aislada y disjunta (también conocida como grupo de disponibilidad) para proporcionar alta disponibilidad. Los clientes pueden usar cualquiera de las direcciones IP para conectarse al backend en buen estado más cercano con capacidad disponible.
El balanceador de cargas te permite mejorar la disponibilidad del servicio cuando creas servicios de backend globales con backends en varias Cloud de Confiance regiones. Si los backends en una región en particular están inactivos, el tráfico se conmuta por error a la siguiente región más cercana de forma correcta.
Te recomendamos que implementes backends en al menos tres Cloud de Confiance regiones para garantizar la resiliencia ante interrupciones regionales, aunque puedes configurar todos tus backends en una sola Cloud de Confiance región.
Balanceo adaptable a la latencia y la carga
Un balanceador de cargas de red de transferencia externo global usa exclusivamente el nivel Premium. Con el nivel Premium, el tráfico entrante de Internet ingresa a la red de alto rendimiento y baja latencia de S3NSen el punto de presencia (PoP) más cercano al usuario. De manera similar, el tráfico de salida se envía a través de la red de S3NSy sale por el PoP más cercano al usuario.
Los balanceadores de cargas de Maglev distribuidos a nivel global enrutan el tráfico entrante a la región deCloud de Confiance más cercana al PoP por el que ingresa el tráfico a la red deS3NS, siempre que la región tenga backends en buen estado con capacidad disponible. De lo contrario, el balanceador de cargas automáticamente y sin problemas desvía el tráfico a la siguiente región más cercana que tenga backends en buen estado con capacidad disponible.
Determinas las ubicaciones y las capacidades de backend para lograr una latencia de paquetes y una eficiencia de backend óptimas. Las capacidades del backend pueden basarse en la tasa máxima de PPS (paquetes por segundo) entrantes, el uso máximo de CPU o ambos. Las capacidades de backend que se configuran en un servicio de backend se comparten de manera equitativa entre las direcciones IP de todas las reglas de reenvío que hacen referencia al servicio de backend.
Cómo funcionan los balanceadores de cargas de red de transferencia externos globales
Un balanceador de cargas de red de transferencia externo global tiene un frontend (la regla de reenvío) y un backend (el servicio de backend y sus grupos de backend). Puedes usar grupos de instancias o NEG zonales de GCE_VM_IP como grupos de backends.
Arquitectura
En el siguiente diagrama, se muestra un balanceador de cargas de red de transferencia externo global que distribuye el tráfico a backends en varias regiones de Cloud de Confiance . Cuando se crea el balanceador de cargas, Cloud de Confiance le asigna dos direcciones IP externas globales de tipo Anycast, que se entregan a través de una infraestructura de plano de control y de datos aislada y disjunta (también conocida como grupos de disponibilidad, AG0 y AG1).
Los dos planos de control y de datos proporcionan alta disponibilidad, tolerancia a errores y resiliencia para cada balanceador de cargas de red de transferencia externo global. Una falla en el plano de control o de datos de un grupo de disponibilidad no afecta al otro grupo de disponibilidad. Los clientes configurados correctamente deben poder conectarse a ambas direcciones IP del balanceador de cargas. Por ejemplo, si un cliente no puede conectarse a la dirección IP de AG0, se debe configurar para que se conecte a la dirección IP de AG1.
El balanceador de cargas consta de los siguientes componentes de configuración.
Dos direcciones IP externas globales, una de cada grupo de disponibilidad (AG0 y AG1). Pueden ser estáticas o efímeras. Para obtener más información, consulta Direcciones IP.
Una regla de reenvío global que especifica las dos direcciones IP externas globales, una de cada grupo de disponibilidad (AG0 y AG1) Cuando creas esta regla de reenvío, Cloud de Confiance genera dos reglas de reenvío secundarias de solo lectura, una para cada grupo de disponibilidad, para garantizar la alta disponibilidad. Para obtener más información, consulta Reglas de reenvío.
Un servicio de backend global que define cómo se distribuye el tráfico a los backends en varias regiones deCloud de Confiance . Los grupos de backends pueden ser todos los grupos de instancias (grupos de instancias administrados zonales o grupos de instancias no administrados zonales) o todos los backends de NEG zonales (NEG zonales con extremos de
GCE_VM_IP). Para obtener más información, consulta Servicios de backend.Verificación de estado global asociada al servicio de backend. Para obtener más información, consulta Verificaciones de estado.
Reglas de firewall que permitan que el tráfico del balanceo de cargas y los sondeos de verificación de estado lleguen a las VMs de backend. Para obtener más información, consulta Reglas de firewall.
Retorno directo del servidor
Un balanceador de cargas de red de transferencia externo global, al igual que otros balanceadores de cargas de red de transferencia, no es un proxy. El balanceador de cargas no finaliza las conexiones de usuario. Los paquetes con balanceo de cargas se envían a las VMs de backend con las direcciones IP de origen y destino, el protocolo y, si corresponde, los puertos, sin cambios. Luego, las VMs de backend finalizan las conexiones de usuario y envían los paquetes que se muestran directamente a los clientes. Las respuestas no vuelven a pasar por el balanceador de cargas. Este proceso se conoce como retorno directo del servidor (DSR).
Enrutamiento local para la dirección IP del balanceador de cargas
El balanceador de cargas de red de transferencia externo global, al igual que otros balanceadores de cargas de red de transferencia, no realiza NAT de origen ni de destino de la dirección IP o los puertos.
El Cloud de Confiance entorno invitadoconfigura cada VM de backend con las direcciones IP del balanceador de cargas. Una entrada en la tabla de enrutamiento local de la VM configura el controlador de interfaz de red (NIC) con balanceo de cargas de la VM de backend para que acepte paquetes cuyas direcciones IP de destino coincidan con cada dirección IP de la regla de reenvío. Para obtener más información, consulta Cómo verificar la tabla de enrutamiento local para las direcciones IP del balanceador de cargas.
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 una dirección IP externa asociada con el cliente, una VM de Cloud de Confiance o un sistema en Internet.
- Destino: Una de las direcciones IP de la regla de reenvío del balanceador de cargas.
Si bien el entorno invitado configura automáticamente las rutas locales para que el sistema operativo de la VM acepte el tráfico destinado a la dirección IP del balanceador de cargas, el sistema operativo no puede entregar estos paquetes a tu aplicación si esta está configurada para detectar solo la dirección IP interna asignada a la VM.
Para asegurarte de que el sistema operativo entregue paquetes a tu aplicación, configura la aplicación que se ejecuta en las VMs de backend para que haga lo siguiente:
- Detecta (vincula) las direcciones 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, escucha (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. La dirección IP de origen del paquete de retorno depende 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 destino del paquete de solicitud para que el cliente pueda asociar los paquetes de respuesta con la conexión TCP adecuada.
- UDP, ICMP, ICMPv6, GRE y ESP no tienen conexión. Las VMs 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 externa 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 resumen las direcciones IP de origen y destino de los paquetes de respuesta:
| Tipo de tráfico | Fuente | Destino |
|---|---|---|
| TCP | Es el destino del paquete solicitante. | Es el origen del paquete solicitante. |
| UDP, ESP, GRE, ICMP y ICMPv6 | Para la mayoría de los casos de uso, el destino del paquete de solicitud1 | Es el origen del paquete solicitante. |
1 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. Cloud de Confiance 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 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.
Componentes
En las siguientes secciones, se describe en detalle cada componente de configuración de un balanceador de cargas de red de transferencia externo global.
Direcciones IP
Un balanceador de cargas de red de transferencia externo global requiere dos direcciones IP externas globales para proporcionar alta disponibilidad. Las reglas de reenvío del balanceador de cargas usan estas direcciones para aceptar el tráfico entrante y deben pertenecer a la misma versión de IP (IPv4 o IPv6). Cloud de Confiance anuncia las direcciones IP de tu balanceador de cargas desde todos los puntos de presencia en todo el mundo. Cada dirección IP del balanceador de cargas es una dirección IP Anycast global que solo se admite en el nivel Premium.
Cada una de las dos direcciones IP debe provenir de grupos de direcciones IP externas globales que pertenezcan a un grupo de disponibilidad distinto. Las direcciones IP no están asociadas a una subred en una red de VPC. En la API, los grupos de disponibilidad se representan con el campo purpose en el recurso globalAddresses:
PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP0: Para direcciones del grupo de disponibilidad 0.PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP1: Para las direcciones del grupo de disponibilidad 1.
El campo IPAddresses de un recurso de regla de reenvío especifica cero, una o dos direcciones IP:
- Si se omite, Cloud de Confiance asigna dos direcciones IP efímeras, una de cada grupo de disponibilidad.
- Si especificas una dirección IP que hace referencia a un recurso de dirección IP estática existente de un grupo de disponibilidad, Cloud de Confiance asigna una dirección IP efímera del otro grupo de disponibilidad.
- Si especificas dos direcciones IP que hacen referencia a recursos de direcciones IP estáticas existentes, deben pertenecer a diferentes grupos de disponibilidad.
Usa direcciones IP estáticas reservadas para la regla de reenvío si necesitas mantener las direcciones asociadas a tu proyecto para reutilizarlas después de borrar una regla de reenvío o si necesitas que varias reglas de reenvío hagan referencia a las mismas direcciones IP.
En el caso de una regla de reenvío del balanceador de cargas de red de transferencia externo global, las direcciones IP pueden ser una de las siguientes:
- Una dirección IPv4 estática o efímera de un grupo de direcciones IP globales propiedad de Google.
- Un rango
/96estático o efímero de direcciones IPv6 externas de un grupo de direcciones IP globales propiedad de Google. - Una dirección IPv4 de BYOIP estática de un prefijo delegado público global
Un balanceador de cargas de red de transferencia externo global admite la función Bring your own IP addresses (BYOIP) solo para direcciones IPv4. La compatibilidad se limita a la API de BYOIP v1. El aprovisionamiento de rangos de IPv4 nuevos puede tardar hasta 4 semanas, y no hay APIs que te permitan controlar el estado de tu anuncio de BGP. Para obtener más información, consulta Usa tus propios parámetros de configuración de IP.
El campo IPAddresses de una regla de reenvío solo se puede establecer en el momento de la creación y no se puede actualizar.
Independientemente de su origen (propiedad de Google o BYOIP), las direcciones IP externas globales en Cloud de Confiance se extraen de tres tipos distintos de grupos de direcciones IP externas globales:
- Son los grupos de direcciones IP que usan los balanceadores de cargas de red de transferencia externos globales para el grupo de disponibilidad, AG0.
- Son los grupos de direcciones IP que usan los balanceadores de cargas de red de transferencia externos globales para el grupo de disponibilidad, AG1.
- Grupos de direcciones IP que usan los balanceadores de cargas externos globales basados en proxy
Por lo tanto, los balanceadores de cargas de red de transferencia externos globales no pueden compartir direcciones IP con ningún otro balanceador de cargas global o regional.
Reglas de reenvío globales
Una regla de reenvío del balanceador de cargas de red de transferencia externo global forma el frontend del balanceador de cargas y especifica las direcciones IP de destino, el protocolo y los puertos en los que el balanceador de cargas acepta tráfico. Debido a que un balanceador de cargas de red de transferencia externo global no es un proxy, pasa el tráfico a los backends sin modificar sus direcciones IP de origen y destino, el protocolo y los puertos, si el protocolo lleva información del puerto.
Una regla de reenvío del balanceador de cargas de red de transferencia externo global que configures debe especificar lo siguiente:
- El esquema de balanceo de cargas se designa como
EXTERNAL_PASSTHROUGH. - Es el par de direcciones IP globales en el campo
IPAddresses[], una de cada grupo de disponibilidad. - El protocolo (
TCP,UDPoL3_DEFAULT) y los puertos.
Por cada regla de reenvío del balanceador de cargas de red de transferencia externo global que crees (también conocida como regla de reenvío principal), Cloud de Confiancegenera dos reglas de reenvío secundarias de solo lectura para cada pila de balanceo de cargas: AVAILABILITY_GROUP0 y AVAILABILITY_GROUP1. La regla de reenvío secundaria tiene la misma configuración de protocolo IP, puerto y servicio de backend que la regla de reenvío principal, pero solo tiene una de las dos direcciones IP de la regla de reenvío principal.
Las reglas de reenvío secundarias se pueden identificar de forma única, ya que tienen -ag0 y -ag1 anexados al nombre de la regla de reenvío principal. No consumen cuota adicional ni generan costos adicionales. Las métricas de supervisión y el estado de salud se registran a nivel de la regla de reenvío secundaria.
El tráfico entrante coincide con una regla de reenvío, que hace coincidir la dirección IP de destino, el protocolo y el puerto de un paquete con una combinación de campos de la regla de reenvío: dos direcciones IP, un protocolo y, si el protocolo se basa en puertos, uno de los puertos, un rango de puertos o todos los puertos. Luego, la regla de reenvío dirige el tráfico al servicio de backend del balanceador de cargas.
Las reglas de reenvío para un balanceador de cargas de red de transferencia externo global se pueden configurar con direcciones IPv4 o IPv6. Si deseas que el balanceador de cargas controle el tráfico IPv4 e IPv6, crea dos reglas de reenvío:
Una regla de reenvío para el tráfico IPv4 que apunta a backends solo IPv4 o de pila doble
Una regla de reenvío para el tráfico IPv6 que apunta a backends solo IPv6 o de pila doble
Es posible hacer que una regla de reenvío de IPv4 y una de IPv6 hagan referencia al mismo servicio de backend, pero el servicio de backend debe hacer referencia a los backends con interfaces de red de VM de pila doble.
La versión de IP de tu regla de reenvío debe coincidir con el tipo de pila de las interfaces de red de la VM de backend.
| Tipo de pila de las interfaces de red de la VM de backend | Regla de reenvío |
|---|---|
Interfaz de red de VM solo IPv4 (IPV4_ONLY) |
Solo pueden ser backends para reglas de reenvío IPv4. |
Interfaz de red de VM solo IPv6 (IPV6_ONLY) |
Solo pueden ser backends para reglas de reenvío IPv6. |
Interfaz de red de VM de doble pila (IPV4_IPV6) |
Pueden ser backends para reglas de reenvío de IPv4, reglas de reenvío de IPv6 o ambos. |
Protocolos de reglas de reenvío
Los balanceadores de cargas de red de transferencia externos globales admiten las siguientes opciones de protocolo para cada regla de reenvío: TCP, UDP y L3_DEFAULT.
Usa las opciones TCP y UDP para configurar el balanceo de cargas de TCP o UDP, respectivamente. La opción del protocolo L3_DEFAULT permite que un balanceador de cargas de red de transferencia externo global balancee las cargas de tráfico de TCP, UDP, ESP, GRE, ICMP y ICMPv6.
Además de admitir protocolos que no sean TCP ni UDP, L3_DEFAULT permite que una sola regla de reenvío entregue varios protocolos. Por ejemplo, los servicios IPSec suelen controlar una combinación de tráfico IKE y NAT-T basado en ESP y UDP. La opción L3_DEFAULT permite que se configure una sola regla de reenvío para procesar todos esos protocolos.
Si usas el protocolo L3_DEFAULT, debes configurar la regla de
reenvío para aceptar tráfico en todos los puertos. Dado que L3_DEFAULT es una regla de captura general, como práctica recomendada de seguridad, debes configurar reglas de firewall de permiso de entrada que solo permitan los protocolos y puertos IP que necesitas.
Varias reglas de reenvío
Puedes configurar varias reglas de reenvío, que pueden ser de dos tipos:
Varias reglas de reenvío para las mismas direcciones IP Puedes configurar varias reglas de reenvío para el mismo par de direcciones IP, siempre y cuando no haya dos reglas de reenvío que consuman las mismas combinaciones de protocolo y puerto. Cada regla de reenvío puede tener un servicio de backend diferente, o varias reglas de reenvío pueden tener el mismo servicio de backend.
Varias reglas de reenvío que hacen referencia al mismo servicio de backend. Puedes configurar varias reglas de reenvío que hagan referencia al mismo servicio de backend. Sujeto a las condiciones que se indican en el primer punto, dos o más reglas de reenvío pueden usar el mismo par de direcciones IP, o bien cada regla de reenvío puede usar un par de direcciones IP único. El tráfico de todas las direcciones IP de todas las reglas de reenvío que hacen referencia al mismo servicio de backend comparte las capacidades de destino del backend de manera equitativa.
Sin embargo, no puedes compartir la misma dirección IP externa global entre un balanceador de cargas de red de transferencia externo global y un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de red de proxy externo global.
Cuando uses varias reglas de reenvío, asegúrate de configurar la aplicación que se ejecuta en tus VMs de backend para que se vincule a todas las direcciones IP externas de las reglas de reenvío del balanceador de cargas.
Configurar varias reglas de reenvío puede ser útil para los siguientes casos de uso:
- Si debes configurar más de un par de direcciones IP externas para el mismo servicio de backend Por ejemplo, una regla de reenvío para direcciones IPv4 y otra para direcciones IPv6.
- Debes configurar varias reglas de reenvío para el mismo par de direcciones IP externas, pero con diferentes protocolos o puertos, o rangos de puertos no superpuestos. Las reglas de reenvío pueden usar los mismos servicios de backend o diferentes.
Restricciones de protocolos y puertos de varias reglas de reenvío
Cloud de Confiance Selecciona como máximo una regla de reenvío para procesar un paquete entrante. Dos o más reglas de reenvío que usan el mismo par de direcciones IP externas globales deben tener combinaciones de protocolo y puerto únicas de acuerdo con estas restricciones:Una regla de reenvío configurada para todos los puertos de un protocolo evita que se creen otras reglas de reenvío con el mismo par de protocolo y dirección IP.
Las reglas de reenvío que usan los protocolos
TCPoUDPse pueden configurar para usar todos los puertos, o bien se pueden configurar para puertos específicos.Por ejemplo, si creas una regla de reenvío con el par de direcciones IP
136.124.69.214y136.124.83.205, el protocoloTCPy todos los puertos, no puedes crear ninguna otra regla de reenvío con el mismo par de direcciones IP y el protocoloTCP.Puedes crear dos reglas de reenvío, ambas con el par de direcciones IP y el protocolo
TCP, si cada una tiene puertos únicos o rangos de puertos no superpuestos. Por ejemplo, puedes crear dos reglas de reenvío con el mismo par de direcciones IP y el protocoloTCP, en el que los puertos de una regla de reenvío son80,443y el otro usa el rango de puertos81-442.Solo se puede crear una regla de reenvío
L3_DEFAULTpor par de direcciones IP.Esto se debe a que el protocolo
L3_DEFAULTusa todos los puertos por definición. En este contexto, el término todos los puertos incluye protocolos sin información de puerto.Una sola regla de reenvío
L3_DEFAULTpuede coexistir con otras reglas de reenvío que usan protocolos específicos (TCPoUDP) y el mismo par de direcciones IP.Si tienes reglas de reenvío de TCP o UDP específicas asociadas a un par de direcciones IP, también puedes asociar una regla de reenvío de
L3_DEFAULTa ese mismo par de direcciones IP para que actúe como alternativa para cualquier tráfico que no coincida con las reglas de reenvío específicas. Una regla de reenvíoL3_DEFAULTprocesa los paquetes que se envían a su dirección IP de destino solo si la dirección IP, el protocolo y el puerto de destino del paquete no coinciden con una regla de reenvío específica del protocolo.A modo de ejemplo, considera estas dos situaciones. En ambas situaciones, las reglas de reenvío usan el mismo par de direcciones IP:
136.124.69.214y136.124.83.205.Situación 1. La primera regla de reenvío usa el protocolo
L3_DEFAULT. La segunda regla de reenvío usa el protocoloTCPy todos los puertos. La segunda regla de reenvío, que es más específica, procesa los paquetes de TCP enviados a cualquier puerto de destino de cualquiera de las direcciones IP. La primera regla de reenvío procesa los paquetes que usan diferentes protocolos.Situación 2. La primera regla de reenvío usa el protocolo
L3_DEFAULT. La segunda regla de reenvío usa el protocoloTCPy el puerto8080. La segunda regla de reenvío procesa los paquetes de TCP enviados al puerto 8080 de cualquiera de las direcciones IP. Todos los demás paquetes, incluidos los paquetes de TCP enviados a diferentes puertos de destino, se procesan mediante la primera regla de reenvío.
Selección de la regla de reenvío
Cloud de Confiance selecciona una o cero reglas de reenvío para procesar un paquete entrante con este proceso de eliminación, a partir del conjunto de opciones de reglas de reenvío que coinciden con la dirección IP de destino del paquete:
Elimina las reglas de reenvío cuyo protocolo no coincide con el protocolo del paquete, excepto las reglas de reenvío de
L3_DEFAULT. Las reglas de reenvío que usan el protocoloL3_DEFAULTnunca se borran en este paso porqueL3_DEFAULTcoincide con todos los protocolos. Por ejemplo, si el protocolo del paquete es TCP, solo se borran las reglas de reenvío que usan el protocoloUDP.Elimina las reglas de reenvío cuyo puerto no coincida con el puerto del paquete. Las reglas de reenvío de todos los puertos configuradas nunca se borran con este paso, ya que una regla de reenvío de todos los puertos coincide con cualquier puerto.
En este punto, las opciones de la regla de reenvío restante se dividen en una de las siguientes categorías:
Quedan dos reglas de reenvío, una regla de reenvío
L3_DEFAULTy una regla de reenvío específica del protocolo. Usa la regla de reenvío específica del protocolo para enrutar el paquete.Queda una sola regla de reenvío, ya sea una regla de reenvío
L3_DEFAULTo una regla de reenvío específica del protocolo. Se usa para enrutar el paquete.Los candidatos de la regla de reenvío cero permanecen y el paquete se descarta.
Servicios de backend globales
Un servicio de backend de un balanceador de cargas de red de transferencia externo global distribuye el tráfico entrante entre los backends adjuntos que pueden residir en varias Cloud de Confiance regiones. Cada backend está compuesto por un grupo de instancias o un grupo de extremos de red, además de información sobre la capacidad de entrega del backend. La capacidad de entrega del backend se puede basar en el uso de CPU, los paquetes entrantes por segundo (PPS) o ambos. El servicio de backend administra la distribución del tráfico según la configuración de afinidad y capacidad.
El servicio de backend define los siguientes parámetros de backend:
Esquema de balanceo de cargas Para designar un servicio de backend para un balanceador de cargas de red de transferencia externo global, el esquema de balanceo de cargas debe establecerse de forma explícita en
EXTERNAL_PASSTHROUGH.Protocol. El campo de protocolo del servicio de backend es redundante y solo se puede configurar en
UNSPECIFIED. Los servicios de backend con el protocoloUNSPECIFIEDse pueden usar con cualquier regla de reenvío, sin importar el protocolo de la regla de reenvío.Distribución del tráfico. Un servicio de backend distribuye el tráfico según la afinidad de sesión, la política de seguimiento de conexiones, el modo de balanceo de cargas y las capacidades de backend configurados, y la política de localidad del balanceo de cargas. El servicio de backend también se puede configurar para habilitar el vaciado de conexiones, reducir las capacidades del backend y designar backends preferidos. La mayoría de estos parámetros de configuración tienen valores predeterminados que te permiten comenzar con rapidez.
Verificación de estado. Un servicio de backend debe tener una verificación de estado asociada.
Backends. Los backends son los extremos reales que reciben tráfico con carga balanceada. Un balanceador de cargas de red de transferencia externo global puede distribuir el tráfico a grupos de instancias o NEG zonales ubicados en varias Cloud de Confiance regiones:
Si eliges grupos de instancias, puedes usar los administrados zonales, los no administrados zonales o una combinación de los tipos de grupos de instancias. Los grupos de instancias admiten
RATEyUTILIZATIONcomo modo de balanceo de cargas.Si eliges NEG zonales, debes usar NEG zonales de
GCE_VM_IP. Los NEG solo admitenRATEcomo modo de balanceo de cargas.
Compatibilidad de la interfaz de red de la VM con las reglas de reenvío
Dado que los balanceadores de cargas de red de transferencia externos globales no finalizan ni traducen el tráfico, el tipo de pila de la interfaz de red de la VM de backend debe ser compatible con la versión de la dirección IP de la regla de reenvío.
| Regla de reenvío | Tipo de pila de las interfaces de red de la VM de backend |
|---|---|
| Solo reglas de reenvío de IPv4 | Solo IPv4 (IPV4_ONLY) o pila doble (IPV4_IPv6) |
| Solo reglas de reenvío de IPv6 | Solo IPv6 (IPV6_ONLY) o pila doble (IPV4_IPv6) |
| Reglas de reenvío de IPv4 y IPv6 | Pila doble (IPV4_IPv6) |
Compatibilidad de la interfaz de red de la VM de backend con las subredes de VPC
Como se muestra en la tabla anterior, puedes configurar un balanceador de cargas de red de transferencia externo global para que tenga backends que contengan interfaces solo IPv4, interfaces de pila doble e interfaces solo IPv6. En la siguiente tabla, se resumen los tipos de interfaces de red de VM de backend que son compatibles con cada tipo de pila de subred de VPC.
| Tipo de pila de las subredes de VPC | Tipo de pila de la interfaz de red de la VM de backend |
|---|---|
IPV4_ONLY (pila única)Solo rangos de subred IPv4 |
Solo IPv4 (IPV4_ONLY) |
IPV4_IPV6 (pila doble)Rangos de subred IPv4 e IPv6 |
Solo IPv4 (IPV4_ONLY), pila doble (IPV4_IPv6) y solo IPv6 (IPV6_ONLY) |
IPV6_ONLY (pila única)Solo rangos de subred IPv6 |
Solo IPv6 (IPV6_ONLY) |
Ten en cuenta lo siguiente:
La dirección IP asignada a una interfaz de red de VM se asigna directamente desde la subred de VPC subyacente.
Para la conectividad IPv6, cuando se asigna una interfaz de red de VM a una subred
/64habilitada para IPv6, Cloud de Confiance asigna a la interfaz de red de VM un rango de direcciones/96de la primera mitad (/65) del rango de direcciones IPv6 externas/64de la subred. Para obtener más información, consulta Especificaciones de IPv6 externas.Cuando el tipo de pila de la interfaz de red de la VM es de pila doble (
IPV4_IPv6) o solo IPv6 (IPV6_ONLY), debes elegir cómo se puede acceder a la dirección IPv6 de la interfaz de red de la VM configurando el parámetro de configuración--ipv6-access-typeen la subred de VPC comoEXTERNALoINTERNAL. Si el--ipv6-access-typede la subred está establecido enEXTERNAL, también debes establecer el--ipv6-network-tieren la interfaz de red de la VM enPREMIUM. Para obtener más información, consulta Rangos de subredes IPv6.
Interfaces de red y backends de grupos de instancias
Dentro de un grupo de instancias determinado (administrado o no administrado), la interfaz de red nic0 de cada VM miembro siempre está en la misma red de VPC:
- En los grupos de instancias administrados (MIG), la red de VPC del grupo de instancias proviene de la interfaz
nic0definida en la plantilla de instancias. - En los grupos de instancias no administrados, la red de VPC del grupo de instancias se establece en la red de VPC que usa la interfaz de red
nic0de la primera instancia de VM que agregas al grupo de instancias no administrado. No puedes cambiar la red de VPC del grupo de instancias más adelante, incluso si quitas la primera instancia que agregaste al grupo.
Las VMs miembro pueden tener interfaces de red adicionales (vNIC o interfaces de red dinámicas).
Cada interfaz que no sea nic0 puede estar en la red de VPC del grupo de instancias (la red que usa la interfaz nic0) o en una red de VPC diferente.
nic0, no puedes usar backends de grupos de instancias. En su lugar, usa NEGs zonales con extremos GCE_VM_IP. Para obtener más información, consulta Servicios de backend y redes de VPC.
Interfaces de red y backends de NEG zonales
Cuando creas un NEG zonal nuevo con extremos GCE_VM_IP, debes asociar el NEG de forma explícita con una subred de una red de VPC para poder agregar extremos al NEG. Ni la subred ni la red de VPC se pueden cambiar después de que se crea el NEG.
Dentro de un NEG determinado, cada extremo GCE_VM_IP en realidad representa una interfaz de red. La interfaz de red debe estar en la subred asociada con el NEG. Desde la perspectiva de una instancia de Compute Engine, la interfaz de red puede usar cualquier identificador. Desde la perspectiva de ser un extremo en un NEG, la interfaz de red se identifica con su dirección IPv4 interna principal. Para obtener más información, consulta NEG con extremos GCE_VM_IP.
Existen dos maneras de agregar un extremo GCE_VM_IP a un NEG:
- Si especificas solo un nombre de VM (sin ninguna dirección IP) cuando agregas un extremo, Cloud de Confiance requiere que la VM tenga una interfaz de red en la subred asociada con el NEG. La dirección IP que Cloud de Confianceelige para el extremo es la dirección IPv4 interna principal de la interfaz de red de la VM en la subred asociada con el NEG.
- Si especificas un nombre de VM y una dirección IP cuando agregas un extremo, la dirección IP que proporciones debe ser una dirección IPv4 interna principal para una de las interfaces de red de la VM. Esa interfaz de red debe estar en la subred asociada con el NEG. Ten en cuenta que especificar una dirección IP es redundante porque solo puede haber una única interfaz de red que esté en la subred asociada con el NEG.
Servicios de backend y redes de VPC
El servicio de backend no está asociado con ninguna red de VPC; sin embargo, cada grupo de instancias de backend o NEG zonal está asociado con una red de VPC, como se indicó antes. Siempre que todos los backends estén ubicados en el mismo proyecto y sean del mismo tipo (grupos de instancias o NEG zonales), el balanceador de cargas y sus backends pueden estar en la misma red de VPC o en redes diferentes.
Para distribuir paquetes a interfaces que no son de nic0, debes cumplir con los siguientes requisitos:
Debes usar NEG zonales (con extremos
GCE_VM_IP), no grupos de instancias.Las interfaces de red
nic0y nonic0deben estar en diferentes redes de VPC. (La red de VPC del NEG no puede contener la interfaznic0y la interfaz nonic0deseada).
Backends preferidos
Puedes designar backends específicos como backends preferidos. Estos backends deben usarse en toda su capacidad (es decir, la capacidad objetivo especificada por el modo de balanceo del backend) antes de que se envíen las solicitudes a los backends restantes.
El servicio de backend de un balanceador de cargas de red de transferencia externo global puede tener, como máximo, un grupo de backend preferido y no permite backends preferidos y no preferidos en la misma región Cloud de Confiance .
Para obtener más información, consulta Optimizaciones avanzadas del balanceo de cargas.
Verificaciones de estado
La información de la verificación de estado se usa para determinar los backends aptos para las conexiones nuevas y para controlar si las conexiones existentes persisten en los backends en mal estado.El balanceador de cargas envía sondeos de verificación de estado para cada dirección IP de la regla de reenvío por separado. Por lo tanto, se sondea una regla de reenvío del balanceador de cargas de red de transferencia externo global con dos direcciones IP para cada dirección IP, lo que duplica la frecuencia de sondeo en cada backend. Para obtener más información, consulta Varios sondeos y frecuencia.
Tipo, protocolo y puerto de la verificación de estado
El servicio de backend del balanceador de cargas debe hacer referencia a una verificación de estado global con cualquier protocolo y puerto de verificación de estado admitidos. Los detalles del puerto y el protocolo de la verificación de estado no tienen que coincidir con la información del puerto y el protocolo de la regla de reenvío.
Dado que todos los protocolos de verificación de estado admitidos se basan en TCP (no se admiten las verificaciones de estado de UDP), cuando usas un balanceador de cargas de red de transferencia externo global para balancear las conexiones y el tráfico de otros protocolos, las VMs de backend deben ejecutar un servidor basado en TCP para responder a los verificadores de estado. Por ejemplo, puedes usar una verificación de estado HTTP combinada con la ejecución de un servidor HTTP en cada VM de backend. En este ejemplo, tus secuencias de comandos o software son responsables de configurar el servidor HTTP para que muestre el estado 200 solo cuando el software que escucha las conexiones balanceadas por carga esté en funcionamiento.
Para obtener más información sobre los protocolos y puertos de verificación de estado admitidos, consulta Categorías, protocolos y puertos de verificación de estado y Cómo funcionan las verificaciones de estado.
Paquetes de verificación de estado
En el caso de los backends de grupos de instancias, los verificadores de estado envían paquetes a la interfaz de red nic0 de cada VM de backend. Para los backends de NEG zonales de GCE_VM_IP, los verificadores de sondeo de verificación de estado envían paquetes a la interfaz de red en la subred de VPC del NEG. Los paquetes de verificación de estado tienen las siguientes características:
- Es la dirección IP de origen del rango de IP del sondeo de la verificación de estado pertinente.
- Dirección IP de destino que coincide con cualquiera de las dos direcciones IP de la regla de reenvío que hace referencia al servicio de backend del balanceador de cargas de red de transferencia externo global. Los paquetes de verificación de estado se envían a ambas direcciones IP.
- Es el puerto de destino que coincide con el número de puerto que especificas en la verificación de estado.
Las aplicaciones que se ejecutan en las VMs de backend deben vincularse y escuchar las combinaciones relevantes de direcciones IP y puertos. Para ello, configura la aplicación de modo que se vincule a los puertos pertinentes de cualquiera de las direcciones IP de la VM (0.0.0.0 o ::/0) y los escuche. Para obtener más información, consulta Destino para paquetes de sondeo.
Reglas de firewall
Debido a que un balanceador de cargas de red de transferencia externo global no es un proxy, pasa el tráfico a las VMs de backend sin modificar sus direcciones IP de origen y destino, el protocolo y los puertos, si el protocolo lleva información del puerto. Por lo tanto, debes crear reglas de firewall de permiso de entrada o una política de firewall jerárquica de permiso de entrada para controlar el acceso a las VMs de backend del balanceador de cargas, específicamente, para permitir las verificaciones de estado y el tráfico en el que realizas el balanceo de cargas. De lo contrario, la regla de firewall de entrada implícita de rechazo bloquea los paquetes entrantes de todas las direcciones IP de origen externas.
Las reglas de reenvío y las reglas de firewall de permiso de entrada o las políticas de firewall jerárquicas de permiso de entrada trabajan juntas de la siguiente manera: una regla de reenvío especifica la dirección IP de destino, el protocolo y, si están definidos, los requisitos del puerto que un paquete debe cumplir para que se lo reenvíe a una VM de backend. Las reglas de firewall de permiso de entrada controlan si el firewall entrega los paquetes reenviados a la VM o los descarta. La red de VPC Cloud de Confiance predeterminada incluye un conjunto limitado de reglas de firewall de permiso de entrada prepropagadas.
Para aceptar el tráfico de cualquier dirección IP en Internet, debes crear una regla de firewall de permiso de entrada con el rango de origen
0.0.0.0/0o::/0. Para permitir solo el tráfico de ciertos rangos de direcciones IP, usa rangos de origen más restrictivos.Como práctica recomendada de seguridad, las reglas de firewall de permiso de entrada solo deben autorizar los protocolos y puertos IP que necesitas. La restricción de la configuración del protocolo (y, si es posible, el puerto) es muy importante cuando se usan reglas de reenvío cuyo protocolo se establece en
L3_DEFAULT. Las reglas de reenvíoL3_DEFAULTreenvían paquetes para todos los protocolos IP admitidos (en todos los puertos si el protocolo y el paquete tienen información del puerto).Los balanceadores de cargas de red de transferencia externos globales usan verificaciones de estado Cloud de Confiance . Por lo tanto, siempre debes permitir el tráfico de los rangos de direcciones IP de verificación de estado. Puedes configurar estas reglas de firewall de permiso de entrada específicas para el protocolo y los puertos de la verificación de estado del balanceador de cargas.
Distribución del tráfico
Para un balanceador de cargas de red de transferencia externo global, la distribución del tráfico es una función de diferentes atributos, como la afinidad de sesión, la política de seguimiento de conexiones, el modo de balanceo de cargas y las capacidades de backend, los backends preferidos y la política de localidad del balanceo de cargas. Todos se unen como parte de un flujo de trabajo coordinado para optimizar la configuración del balanceo de cargas y lograr un rendimiento confiable y un uso eficiente de los recursos.
Arquitectura de VPC compartida
Ten en cuenta los siguientes puntos en relación con una arquitectura de VPC compartida para un balanceador de cargas de red de transferencia externo global:
A excepción de los recursos de direcciones IP, todos los demás recursos asociados con un balanceador de cargas de red de transferencia externo global (regla de reenvío, servicio de backend, verificación de estado y grupos de backend [grupos de instancias o NEG]) deben existir en el mismo proyecto, y este proyecto puede ser un proyecto host o un proyecto de servicio.
Si los recursos de balanceo de cargas existen en el proyecto host, los recursos de direcciones IP también deben existir en el proyecto host.
Si los recursos de balanceo de cargas existen en un proyecto de servicio, los recursos de dirección IP pueden estar en el mismo proyecto de servicio o en el proyecto host.
En la siguiente tabla, se describe dónde existen los diferentes componentes de un balanceador de cargas de red de transferencia externo global en una arquitectura de VPC compartida.
| Ubicación de los recursos de balanceo de cargas1 | Ubicación obligatoria de los recursos de direcciones IP |
|---|---|
| Proyecto host | Proyecto host |
| Proyecto de servicio | Proyecto de servicio o proyecto host |
1 Incluye la regla de reenvío, el servicio de backend, la verificación de estado y los backends (grupos de instancias o NEG)
Limitaciones
Los backends solo se pueden implementar en las siguientes Cloud de Confiance regiones:
- Norteamérica:
us-west1,us-west4,us-east4,us-east5 - Europa:
europe-west2,europe-west3 - Asia:
asia-southeast1,asia-south1,asia-northeast1 - Sudamérica:
southamerica-east1 - África:
africa-south1 - Australia:
australia-southeast1
- Norteamérica:
El balanceador de cargas de red de transferencia externo global solo se puede configurar en el nivel Premium.
No puedes configurar un balanceador de cargas de red de transferencia externo global con la consola Cloud de Confiance . Usa Google Cloud CLI o la API de REST.
No puedes usar backends de grupos de instancias administrados regionales. Puedes usar grupos de instancias administrados zonales, grupos de instancias no administrados zonales y NEG zonales con extremos de
GCE_VM_IP.Las restricciones y orientaciones existentes para usar grupos de instancias en servicios de backend también se aplican al balanceador de cargas de red de transferencia externo global. Un grupo de instancias que se comparte entre un balanceador de cargas de red de transferencia externo global y balanceadores de cargas de red de transferencia regionales (balanceador de cargas de red de transferencia externo regional o balanceador de cargas de red de transferencia interno) debe configurarse para usar el modo de balanceo
RATEen el balanceador de cargas de red de transferencia externo global. Los balanceadores de cargas de red de transferencia regionales siempre usan el modo de balanceoCONNECTION.Puedes compartir la misma dirección IP externa global entre varias reglas de reenvío del balanceador de cargas de red de transferencia externo global, siempre y cuando los protocolos y puertos configurados no entren en conflicto. Sin embargo, no puedes compartir la misma dirección IP externa global entre un balanceador de cargas de red de transferencia externo global y un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de red de proxy externo global.
Un balanceador de cargas de red de transferencia externo global admite la función Bring your own IP addresses (BYOIP) solo para direcciones IPv4. La compatibilidad se limita a la API de BYOIP v1. El aprovisionamiento de rangos de IPv4 nuevos puede tardar hasta 4 semanas, y no hay APIs que te permitan controlar el estado de tu anuncio de BGP. Para obtener más información, consulta Usa tus propios parámetros de configuración de IP.
No puedes crear más de 10 reglas de reenvío en un proyecto ni agregar más de 25 grupos de backend a un servicio de backend. Para obtener más detalles, consulta Cuotas y límites.
Un servicio de backend de balanceador de cargas de red de transferencia externo global puede tener, como máximo, un grupo de backend
PREFERRED. No puedes tener un grupo de backendPREFERREDy uno que no seaPREFERREDen la misma región de Cloud de Confiance .No puedes implementar un balanceador de cargas de red de transferencia externo global en GKE.
No puedes usar Google Cloud Armor para proporcionar protección avanzada contra DSD de red para los balanceadores de cargas de red de transferencia externos globales. Para obtener más detalles, consulta Configura la protección avanzada contra DSD de red.
La política de localidad de balanceo de cargas, configurada en el servicio de backend del balanceador de cargas, no admite la opción
WEIGHTED_MAGLEV. En el caso de los balanceadores de cargas de red de transferencia externos globales, solo se admiteMAGLEV.No se admite el modo de seguimiento de conexiones
PER_SESSION. Solo se admite el modo de seguimiento de conexionesPER_CONNECTION.Solo se admiten los siguientes modos de balanceo de cargas:
RATEyUTILIZATION. La frecuencia no se define en términos de solicitudes por segundo, sino de paquetes entrantes por segundo. Los grupos de instancias admitenRATEyUTILIZATION, mientras que los NEG solo admitenRATE.No se admiten las reglas de reenvío de dirección (direccionamiento del tráfico basado en IP de origen).
Todos los backends adjuntos a un servicio de backend deben ser del mismo tipo. Un servicio de backend no puede tener una combinación de grupos de instancias y NEG zonales.
Las métricas de supervisión no se pueden consultar ni filtrar con las reglas de reenvío globales principales; se deben consultar con las reglas de reenvío secundarias generadas por Cloud de Confiance.
Precios
Para obtener información sobre los precios, consulta Precios de red: Cloud Load Balancing.
¿Qué sigue?
- Configura un balanceador de cargas de red de transferencia externo global con backends de grupos de instancias de VM
- Configura un balanceador de cargas de red de transferencia externo global con backends de NEG zonales
- Modos de balanceo para los balanceadores de cargas de red de transferencia
- Especificaciones de capacidad de destino para balanceadores de cargas de red de transferencia externos globales
- Referencias de la API de Cloud Load Balancing y gcloud CLI gcloud