Un balanceador de cargas distribuye el tráfico del usuario en varias instancias de tus aplicaciones. Si se distribuye la carga, el balanceo de cargas reduce el riesgo de que la aplicación experimente problemas de rendimiento.
Acerca de Cloud Load Balancing
Con Cloud Load Balancing, puedes entregar contenido lo más cerca posible a tus usuarios en un sistema que pueda responder a más de un millón de consultas por segundo.
Cloud Load Balancing es un servicio administrado completamente distribuido y definido por software. No se basa en hardware, por lo que no es necesario que administres una infraestructura física de balanceo de cargas.
Google Cloud ofrece las siguientes funciones de balanceo de cargas:
- Una sola dirección IP para usar como frontend
- Ajuste de escala automático inteligente de tus backends
- Balanceo de cargas externo para cuando tus usuarios lleguen a tus aplicaciones desde Internet
- Balanceo de cargas interno para cuando tus clientes se encuentren dentro de Google Cloud
- Balanceo de cargas regional para cuando tus aplicaciones estén disponibles en una sola región
- Balanceo de cargas global para cuando tus aplicaciones estén disponibles en todo el mundo
- Balanceo de cargas de traspaso (consulta también retorno directo del servidor [DSR] o enrutamiento directo)
- Balanceo de cargas basado en proxy (como alternativa al traspaso)
- Balanceo de cargas basado en la capa 4 para dirigir el tráfico según los datos de protocolos de red y capa de transporte, como TCP, UDP, ESP o ICMP
- Balanceo de cargas basado en la capa 7 para agregar decisiones de enrutamiento de solicitudes en función de atributos, como el encabezado HTTP y el identificador uniforme de recursos
- Integración con Cloud CDN para la publicación de contenido en caché
Para obtener una lista más completa de funciones, consulta Funciones del balanceador de cargas.
Tipos de Cloud Load Balancing
En la siguiente tabla, se resumen las funciones de cada balanceador de cargas de Google Cloud, incluido si el balanceador de cargas usa una dirección IP interna o externa, si el balanceador de cargas es regional o global y los tipos de tráfico y niveles de servicio de red admitidos.
| Interna o externa | Regional o global | Niveles de red admitidos | Proxy o de traspaso | Tipo de tráfico | Tipo de balanceador de cargas |
|---|---|---|---|---|---|
| Interna | Regional | Premium solamente | De traspaso | TCP o UDP | TCP/UDP interno |
| Regional | Premium solamente | Proxy | HTTP o HTTPS | HTTP(S) interno | |
| Externo | Regional | Premium o Estándar | De paso | TCP, UDP, ESP o ICMP (Vista previa) | Red TCP/UDP externa |
| Global en el nivel Premium Efectivamente regional 1 en el nivel Estándar |
Premium o Estándar | Proxy | TCP | Proxy TCP | |
| Premium o Estándar | Proxy | SSL | Proxy SSL | ||
| Premium o Estándar | Proxy | HTTP o HTTPS | HTTP(S) externo |
Diferencias entre el balanceo de cargas global y el regional
Usa el balanceo de cargas global cuando tus backends se distribuyan en varias regiones, tus usuarios necesiten acceso a las mismas aplicaciones y contenido, y quieras proporcionar acceso mediante una sola dirección IP anycast. El balanceo de cargas global también puede proporcionar la terminación de IPv6.
Usa el balanceo de cargas regional cuando tus backends se encuentren en una región y solo necesites la terminación de IPv4.
Diferencias entre el balanceo de cargas interno y el externo
Los balanceadores de cargas de Google Cloud se pueden dividir en balanceadores de cargas internos y externos:
Los balanceadores de cargas externos distribuyen el tráfico proveniente de Internet a tu red de nube privada virtual (VPC) de Google Cloud. El balanceo de cargas global requiere que uses el nivel Premium de los Niveles de servicio de red. Para el balanceo de cargas regional, puedes usar el nivel Estándar.
Los balanceadores de cargas internos distribuyen el tráfico a instancias dentro de Google Cloud.
En el siguiente diagrama, se ilustra un caso práctico común: cómo usar el balanceo de cargas interno y externo al mismo tiempo. En la ilustración, el tráfico se distribuye de la siguiente manera:
- El tráfico de los usuarios en San Francisco, Iowa y Singapur se dirige a un balanceador de cargas externo (
1.1.1.1). - El balanceador de cargas externo distribuye ese tráfico a diferentes regiones en una red de Google Cloud.
- Una vez que el tráfico está dentro de Google Cloud, dos balanceadores de cargas internos (
10.10.10.10) y (10.20.1.1), cada uno distribuye el tráfico dentro de sus respectivas regiones:us-central1yasia-east1. - Dentro de
us-central1, ese balanceador de cargas interno (10.10.10.10) distribuye el tráfico entre dos zonas:us-central1-ayus-central1-b. - Dentro de
asia-east1, el balanceador de cargas interno (10.20.1.1) distribuye el tráfico dentro de una zona:asia-east1-a.
Tipo de tráfico
El tipo de tráfico que necesitas que controle tu balanceador de cargas es otro factor para determinar qué balanceador de cargas usar:
- Para el tráfico HTTP y HTTPS, puedes usar lo siguiente:
- Balanceo de cargas HTTP(S) externo
- Balanceo de cargas HTTP(S) interno
- Para el tráfico de TCP, puedes usar lo siguiente:
- Balanceo de cargas del proxy de TCP
- Balanceo de cargas de red
- Balanceo de cargas TCP/UDP interno
- Para el tráfico de UDP, puedes usar lo siguiente:
- Balanceo de cargas de red
- Balanceo de cargas TCP/UDP interno
- Para el tráfico de ESP o ICMP, puedes usar:
- Balanceo de cargas de red (vista previa)
Región y red de backend
La siguiente tabla resume la compatibilidad con backends que residen en diferentes redes de VPC. En la tabla, también se proporciona información sobre la compatibilidad con el balanceo de cargas de varios NIC.
| Tipo de balanceador de cargas | Región y red de backend | Notas de varios NIC |
|---|---|---|
| Balanceo de cargas TCP/UDP interno | Todos los backends deben estar en la misma red de VPC y en la misma región que el servicio de backend. El servicio de backend también debe estar en la misma región y red de VPC que la regla de reenvío. | Si usas varios balanceadores de cargas, puedes realizar un balanceo de cargas a varios NIC en el mismo backend. |
| Balanceo de cargas HTTP(S) interno | Todos los backends deben estar en la misma red de VPC y en la misma región que el servicio de backend. El servicio de backend también debe estar en la misma región y red de VPC que la regla de reenvío. | La nic0 de la VM de backend debe estar en la misma red y región que usa la regla de reenvío. |
| Balanceo de cargas de HTTP(S), balanceo de cargas del proxy SSL, balanceo de cargas del proxy TCP | En el nivel Premium: los backends pueden estar en cualquier región y cualquier red de VPC. En el nivel Estándar: los backends deben estar en la misma región que la regla de reenvío, pero pueden estar en cualquier red de VPC. |
El balanceador de cargas solo envía tráfico a la primera interfaz de red (nic0), independientemente de la red de VPC en la que esté nic0. |
Reglas de firewall
En la siguiente tabla, se resumen las reglas de firewall mínimas requeridas para el acceso del balanceador de cargas.
| Tipo de balanceador de cargas | Reglas de firewall de entrada mínimas requeridas | Resumen | Ejemplo |
|---|---|---|---|
| Balanceo de cargas HTTP(S) externo |
|
Descripción general | Ejemplo |
| Balanceo de cargas HTTP(S) interno |
|
Descripción general | Ejemplo |
| Balanceo de cargas TCP/UDP interno |
|
Descripción general | Ejemplo |
| Balanceo de cargas del proxy SSL |
|
Descripción general | Ejemplo |
| Balanceo de cargas del proxy TCP |
|
Descripción general | Ejemplo |
| Balanceo de cargas de red |
|
Descripción general | Ejemplo |
Protecciones contra DSD para balanceadores de cargas externos
Google Cloud proporciona diferentes protecciones contra DSD, según el tipo de balanceador de cargas.
Balanceadores de cargas externos basados en proxy
Todos los balanceadores de cargas externos basados en proxy de Google Cloud heredan automáticamente la protección contra DSD de Google Front End (GFE), que forma parte de la infraestructura de producción de Google.
Además de la protección contra DSD automática que proporcionan los GFE, puedes configurar Google Cloud Armor para balanceadores de cargas HTTP(S) externos.
Balanceadores de cargas externos de traspaso
El único balanceador de cargas externo de traspaso es el balanceador de cargas de red. Estos balanceadores de cargas se implementan con la misma infraestructura de enrutamiento de Google que se usa a fin de implementar direcciones IP externas para las VM de Compute Engine. Para el tráfico entrante a un balanceador de cargas de red, Google Cloud limita los paquetes entrantes por VM.
Para obtener más información, consulta entrada a destinos de direcciones IP externas.
Tecnología subyacente de los balanceadores de cargas de Google Cloud
En esta sección, se proporciona más información sobre cada tipo de balanceador de cargas de Google Cloud, incluidos los vínculos a la documentación general para comprenderlos mejor.
- Google Front End (GFE) son sistemas distribuidos definidos por software que se ubican en puntos de presencia de Google (PoP) y realizan balanceo de cargas global junto con otros sistemas y planos de control.
- Andromeda es una pila de virtualización de red definida por software de Google Cloud.
- Maglev es un sistema distribuido para el balanceo de cargas de red.
- El proxy Envoy es un proxy de servicio y de código abierto, diseñado para aplicaciones nativas de la nube.
Balanceo de cargas HTTP(S) interno
El balanceo de cargas HTTP(S) interno se basa en la pila de virtualización de red de Andromeda y es un servicio administrado basado en el proxy Envoy de código abierto. Este balanceador de cargas proporciona un balanceo de cargas basado en proxy para los datos de aplicación de la capa 7. Especificas cómo se enruta el tráfico con mapas de URL. El balanceador de cargas usa una dirección IP interna que actúa como frontend para tus backends.
Balanceo de cargas HTTP(S) externo
El balanceo de cargas HTTP(S) se implementa en los GFE. Los GFE se distribuyen globalmente y operan juntos mediante el uso del plano de control y de la red global de Google. En el nivel Premium, los GFE ofrecen balanceo de cargas multirregional, lo que dirige el tráfico al backend más cercano que tenga capacidad y termina el tráfico HTTP(S) lo más cerca posible de tus usuarios.
Balanceo de cargas TCP/UDP interno
El Balanceo de cargas TCP/UDP interno se basa en la pila de virtualización de red de Andromeda. El balanceo de cargas TCP/UDP interno te permite balancear la carga del tráfico de TCP/UDP detrás de una dirección IP de balanceo de cargas interno a la que solo pueden acceder tus instancias de máquinas virtuales (VM) internas. Mediante el uso del balanceo de cargas TCP/UDP interno, se configura una dirección IP de balanceo de cargas interno para actuar como frontend en tus instancias de backend internas. Solo usas direcciones IP internas para tu servicio con balanceo de cargas. En general, tu configuración es más simple.
El balanceo de cargas TCP/UDP interno admite grupos de instancias administrados regionales, para que puedas realizar un ajuste de escala automático en una región, y así proteger tu servicio de fallas zonales.
Balanceo de cargas de redes TCP/UDP externo
El balanceo de cargas de red se basa en Maglev. Este balanceador de cargas te permite balancear las cargas de tráfico en tus sistemas en función de los datos del protocolo de IP entrante, que incluyen la dirección, el protocolo y el puerto (opcional). Es un sistema de balanceo de cargas sin proxy regional. Es decir, un balanceador de cargas de red es un balanceador de cargas de traspaso que no permite las conexiones de proxy de los clientes.
Los balanceadores de cargas de red basados en servicios de backend admiten el tráfico de TCP, UDP, ICMP y ESP.
Los balanceadores de cargas de red basados en grupos de destino admiten tráfico TCP o UDP.
Balanceo de cargas del proxy de SSL
El balanceo de cargas del proxy SSL se implementa en los GFE distribuidos globalmente. Si eliges el nivel Premium de los niveles de servicio de red, el balanceador de cargas del proxy SSL es global. En el nivel Premium, puedes implementar backends en varias regiones y el balanceador de cargas dirige automáticamente el tráfico del usuario a la región más cercana que tenga capacidad. Si eliges el nivel Estándar, un balanceador de cargas del proxy SSL solo puede dirigir el tráfico entre backends en una sola región.
Balanceo de cargas del proxy de TCP
El balanceo de cargas de proxy TCP se implementa en los GFE que se distribuyen globalmente. Si eliges el nivel Premium de los niveles de servicio de red, el balanceador de cargas del proxy TCP es global. En el nivel Premium, puedes implementar backends en varias regiones y el balanceador de cargas dirige automáticamente el tráfico del usuario a la región más cercana que tenga capacidad. Si eliges el nivel Estándar, un balanceador de cargas del proxy TCP solo puede dirigir el tráfico entre backends en una sola región.
Interfaces
Puedes configurar y actualizar tus balanceadores de cargas mediante las siguientes interfaces:
La herramienta de línea de comandos de
gcloud: Es una herramienta de línea de comandos que se incluye en el SDK de Cloud. La documentación de balanceo de cargas HTTP(S) llama a esta herramienta con frecuencia para realizar tareas. Para obtener una descripción general completa de la herramienta, consulta la guía de la herramienta degcloud. Puedes encontrar comandos relacionados con el balanceo de cargas en el grupo de comandosgcloud compute.También puedes obtener ayuda detallada para cualquier comando de
gcloudmediante la marca--help:gcloud compute http-health-checks create --helpGoogle Cloud Console: Las tareas de balanceo de cargas se pueden realizar con Cloud Console.
API de REST: Todas las tareas de balanceo de cargas pueden realizarse con la API de Google Cloud Load Balancing. En los documentos de referencia de la API, se describen los recursos y métodos disponibles.
¿Qué sigue?
- Si deseas obtener ayuda para determinar qué balanceador de cargas de Google Cloud satisface mejor tus necesidades, consulta Elige un balanceador de cargas.