Estos contenidos se han traducido de forma automática para su comodidad, pero Huawei Cloud no garantiza la exactitud de estos. Para consultar los contenidos originales, acceda a la versión en inglés.
Cómputo
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Redes
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Gestión y gobernanza
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
Cloud Operations Center
Resource Governance Center
Migración
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Análisis
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
IoT
IoT Device Access
Otros
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Seguridad y cumplimiento
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Blockchain
Blockchain Service
Servicios multimedia
Media Processing Center
Video On Demand
Live
SparkRTC
Almacenamiento
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Contenedores
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Bases de datos
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Aplicaciones empresariales
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Data Lake Factory
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Distribución de contenido y cómputo de borde
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Soluciones
SAP Cloud
High Performance Computing
Servicios para desarrolladores
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
Cloud Application Engine
aPaaS MacroVerse
KooPhone
KooDrive

Cómo funciona ELB

Actualización más reciente 2025-02-10 GMT+08:00
Figura 1 Cómo funciona ELB

A continuación se describe cómo funciona ELB:

  1. Un cliente envía una solicitud a su aplicación.
  2. Los oyentes agregados a su balanceador de carga utilizan los protocolos y puertos que ha configurado para recibir la solicitud.
  3. El oyente reenvía la solicitud al grupo de servidores backend asociado en función de su configuración. Si ha configurado una política de reenvío para el oyente, el oyente evalúa la solicitud basándose en la política de reenvío. Si la solicitud coincide con la política de reenvío, el oyente reenvía la solicitud al grupo de servidores backend configurado para la política de reenvío.
  4. Los servidores backend sanos del grupo de servidores backend reciben la solicitud basada en el algoritmo de equilibrio de carga y las reglas de enrutamiento especificadas en la política de reenvío, gestionan la solicitud y devuelven un resultado al cliente.

La forma en que se enrutan las solicitudes depende de los algoritmos de equilibrio de carga configurados para cada grupo de servidores backend. Si el oyente utiliza HTTP o HTTPS, la forma en que se enrutan las solicitudes también depende de las políticas de reenvío configuradas para el oyente.

Algoritmos de equilibrio de carga

Los balanceadores de carga dedicados admiten cuatro algoritmos de balanceo de carga: round robin ponderado, conexiones mínimas ponderadas, hash IP de origen e ID de conexión. Los balanceadores de carga compartidos admiten tres algoritmos de balanceo de carga: round robin ponderado, conexiones mínimas ponderadas y hash IP de origen.

  • Round robin ponderado: las solicitudes se enrutan a los servidores backend utilizando el algoritmo round robin. Los servidores back-end con mayores pesos reciben proporcionalmente más solicitudes, mientras que los servidores con igual peso reciben el mismo número de solicitudes. Este algoritmo se utiliza a menudo para conexiones cortas, como conexiones HTTP.

    La siguiente figura muestra un ejemplo de cómo se distribuyen las solicitudes usando el algoritmo round robin ponderado. Dos servidores backend están en la misma AZ y tienen el mismo peso, y cada servidor recibe la misma proporción de solicitudes.

    Figura 2 Distribución del tráfico utilizando el algoritmo de round robin ponderado
  • Conexiones mínimas ponderadas: Además del peso asignado a cada servidor, también se tiene en cuenta el número de conexiones procesadas por cada servidor backend. Las solicitudes se enrutan al servidor con la relación de conexiones a ponderación más baja. Además del número de conexiones, a cada servidor se le asigna una ponderación basada en su capacidad. Las solicitudes se enrutan al servidor con la relación de conexiones a ponderación más baja. Este algoritmo se utiliza a menudo para conexiones persistentes, como conexiones a una base de datos.

    La siguiente figura muestra un ejemplo de cómo se distribuyen las solicitudes usando el algoritmo de conexiones mínimas ponderadas. Dos servidores de backend están en la misma AZ y tienen la misma ponderación, se han establecido 100 conexiones con el servidor backend 01, y se han conectado 50 conexiones con el servidor backend 02. Las nuevas peticiones se encaminan preferentemente al servidor de backend 02.

    Figura 3 Distribución del tráfico utilizando el algoritmo de conexiones mínimas ponderadas
  • Hash IP de origen: La dirección IP de origen de cada solicitud se calcula utilizando el algoritmo de hash consistente para obtener una clave de hash única, y todos los servidores backend están numerados. La clave generada se utiliza para asignar el cliente a un servidor en particular. Esto permite que las solicitudes de diferentes clientes se enruten en función de las direcciones IP de origen y garantiza que un cliente se dirija al mismo servidor que estaba usando anteriormente. Este algoritmo funciona bien para conexiones de TCP de balanceadores de carga que no usan cookies.

    La siguiente figura muestra un ejemplo de cómo se distribuyen las solicitudes utilizando el algoritmo hash IP de origen. Dos servidores backend están en la misma AZ y tienen la misma ponderación. Si el servidor backend 01 ha procesado una solicitud desde la dirección IP A, el balanceador de carga encaminará nuevas solicitudes desde la dirección IP A al servidor backend 01.

    Figura 4 Distribución del tráfico mediante el algoritmo de hash IP de origen
  • ID de conexión: El ID de conexión en el paquete se calcula utilizando el algoritmo hash consistente para obtener un valor específico, y los servidores backend se numeran. El valor generado determina a qué servidor backend se enrutan las solicitudes. Esto permite que las solicitudes con diferentes ID de conexión se enruten a diferentes servidores backend y garantiza que las solicitudes con el mismo ID de conexión se enruten al mismo servidor backend. Este algoritmo se aplica a las solicitudes de QUIC.
    NOTA:

    Actualmente, solo los balanceadores de carga dedicados admiten el algoritmo de ID de conexión.

    Figura 5 muestra un ejemplo de cómo se distribuyen las solicitudes usando el algoritmo de ID de conexión. Dos servidores backend están en la misma AZ y tienen la misma ponderación. Si el servidor de backend 01 ha procesado una solicitud del cliente A, el balanceador de carga encaminará nuevas solicitudes desde el cliente A al servidor backend 01.

    Figura 5 Distribución del tráfico mediante el algoritmo de ID de conexión

Factores que afectan el equilibrio de carga

Además del algoritmo de equilibrio de carga, los factores que afectan al equilibrio de carga generalmente incluyen el tipo de conexión, la adherencia de sesión y los pesos del servidor.

Suponga que hay dos servidores backend con la misma ponderación (no cero), se selecciona el algoritmo de conexiones mínimas ponderadas, las sesiones adhesivas no están habilitadas, y se han establecido 100 conexiones con el servidor backend 01, y 50 conexiones con el servidor backend 02.

Cuando el cliente A desea acceder al servidor backend 01, el balanceador de carga establece una conexión persistente con el servidor backend 01 y encamina continuamente las solicitudes desde el cliente A al servidor backend 01 antes de que se desconecte la conexión persistente. Cuando otros clientes acceden a servidores backend, el balanceador de carga encamina las solicitudes al servidor backend 02 usando el algoritmo de conexiones mínimas ponderadas.

NOTA:

Si los servidores backend se declaran no sanos o sus ponderaciones se establecen en 0, el balanceador de carga no enrutará ninguna solicitud a los servidores backend.

Para obtener detalles sobre el algoritmo de menos conexiones ponderadas, consulte Algoritmos de equilibrio de carga.

Si las solicitudes no se enrutan uniformemente, solucione el problema realizando las operaciones descritas en el documento ¿Cómo puedo comprobar si el tráfico está distribuido uniformemente?

Utilizamos cookies para mejorar nuestro sitio y tu experiencia. Al continuar navegando en nuestro sitio, tú aceptas nuestra política de cookies. Descubre más

Comentarios

Comentarios

Comentarios

0/500

Seleccionar contenido

Enviar el contenido seleccionado con los comentarios