Load Balancer Algorithms
Load balancing algorithms define how incoming traffic is distributed across backend Virtual Machines (VMs).
In CloudRaya, Load Balancers operate at OSI Layer 4 (Transport Layer), which means traffic distribution is based on IP address and port information, not application-level content such as URLs, headers, or cookies.
How Load Balancing Works in CloudRaya
When a request reaches the Load Balancer’s Public IP and Public Port, CloudRaya:
- Receives the incoming connection
- Applies the selected load balancing algorithm
- Forwards the connection to one of the assigned backend VMs on the configured Private Port
Because CloudRaya Load Balancer works at Layer 4:
- Traffic is forwarded as raw TCP/UDP connections
- No inspection of HTTP headers or request paths
- No SSL termination at the Load Balancer level
Supported Load Balancing Algorithms
CloudRaya currently supports the following algorithms:
Round Robin
Round Robin distributes incoming connections evenly across all assigned backend VMs in a rotating order.
How it works
Each new connection is forwarded to the next VM in sequence, regardless of current load.
Best suited for
- Workloads with similar VM capacity
- Applications with short-lived or uniform requests
- General-purpose web or API services
Key characteristics
- Simple and predictable
- No awareness of VM load
- Works well when backend VMs are evenly sized
Least Connection
Least Connection forwards traffic to the VM with the fewest active connections at the time of the request.
How it works
The Load Balancer tracks active connections and selects the VM that is currently least busy.
Best suited for
- Workloads with uneven request duration
- Applications where some requests stay open longer
- Mixed workloads with variable processing time
Key characteristics
- Adapts to real-time load
- Helps prevent overload on busy VMs
- Slightly more dynamic than Round Robin
Source
Source algorithm routes traffic based on the source IP address of the client.
How it works
Requests coming from the same client IP will always be forwarded to the same backend VM, as long as the Load Balancer configuration remains unchanged.
Best suited for
- Basic session stickiness without application-level cookies
- Stateful applications that rely on in-memory session data
- Simple persistence requirements
Key characteristics
- Deterministic routing
- No awareness of VM load
- Session persistence is IP-based, not application-based
Algorithm Comparison Overview
| Algorithm | Load Awareness | Session Persistence | Typical Use Case |
|---|---|---|---|
| Round Robin | ❌ No | ❌ No | Even workloads, similar VM size |
| Least Connection | ✅ Yes | ❌ No | Long-lived or uneven requests |
| Source | ❌ No | ✅ Yes (IP-based) | Basic session stickiness |
Changing the Algorithm
- The load balancing algorithm can be updated after the Load Balancer is created
- Changes apply immediately to new incoming connections
- Existing active connections may continue until closed
Important Limitations
Because CloudRaya Load Balancer operates at Layer 4:
- No URL-based routing
- No header inspection
- No cookie-based session persistence
- No SSL offloading at the Load Balancer
For advanced Layer 7 features, these must be handled at the application level (for example, using NGINX, HAProxy, or application frameworks inside the VM).
When to Choose Each Algorithm
- Choose Round Robin for simplicity and predictable distribution
- Choose Least Connection for workloads with variable request time
- Choose Source when you need lightweight session persistence without application logic