Chat with Us
Get a Call
Load Balancers
GoGrid provides fully integrated, redundant load balancers that you can provision using our web-based management console or GoGrid’s API. This is a software-defined network-style architecture that takes advantage of the scalability and elasticity of our cloud environment. Its next-generation design is self-healing, designed to be highly available, and lets you dynamically manage your traffic load. You can also build fault tolerance into your network so the load is distributed across resources and even across data centers when demand increases.
- Prevent Application Downtime
Use load balancing to spread Internet traffic across two or more web servers. In the event a server becomes unavailable, the load balancer will detect the issue and direct all traffic to the remaining online servers. - Rapid Scaling and Application Uptime
You can use Dynamic Load Balancers to scale infrastructure by adding additional servers to an existing pool of load-balanced web servers to handle all incoming requests. - Dynamically Manage Your Load
Edit your Load Balancer, shift servers in and out of the pool, and even dictate traffic patterns—all on-the-fly. - High Availability Out-of-the-Box
GoGrid’s Dynamic Load Balancers are designed to be self-healing. If a Load Balancer fails, the system manages the failover while maintaining the same virtual IP (VIP), minimizing disruption. - Free 24x7 Support and Strong SLAs
When you need access to talented, helpful Support pros, you want to be able to contact them without worrying about the cost. GoGrid provides access to our knowledgeable team members 24 hours per day, 7 days per week by phone, email, or chat.
Pricing
The first Dynamic Load Balancer is free (first 744 hours every month)
- – $0.03 per hour after the first Dynamic Load Balancer
- – $0.015 per GB surcharge for outbound traffic traveling through the Dynamic Load Balancer
- – $0.13 per GB outbound traffic for non-GoGrid IPs
- – Free inbound data transfer
- – Free data transfer on your private VLAN within a single data center
- – Free 24x7 Support
Additional charges may include:
- – Standard outbound data transfer
- – Additional services such as Cloud Storage, CDN, or CloudLink
- – Data transfer from your provider for non-GoGrid servers
Load Balancer Algorithm
This is the algorithm the Load Balancer will use to distribute traffic to the real servers. Select the algorithm that is best suited for the type of traffic that is sent to the Load Balancer. All GoGrid algorithms take advantage of weights assigned to the real server.
- Weighted Round Robin
"Weighted Round Robin" load balancing takes all incoming connections and routes them one at a time, server by server, based on the weight assigned to the server, with each server taking turns. This algorithm is dynamic, which means server weights may be adjusted on the fly to manage newly spun up servers, for example. If you have two servers with equal weight, incoming connections will alternate between them. If you have four servers, and server 1 has double the weight of the other servers, then connections will be routed to server 1 more often than server 2, server 3, and server 4 before beginning the cycle again. This is a good balancing method for routing HTTP traffic or other types of connections with short durations. - Weighted Least Connect
"Weighted Least Connect" load balancing will route incoming connections to the server with the lowest load on it based on the weight assigned to the server. Connections are sent to each server depending on the total number of concurrent sessions on the servers and the weight. If you have two servers, the first with 24 sessions running and the second with 12 sessions running, then incoming connections will be routed to server 2 until the ratio of connections changes, assuming equal weight on both servers. This algorithm is dynamic, which means server weights may be adjusted on the fly. Use of this algorithm is recommended where very long sessions are expected, but is not well suited for protocols using short sessions such as HTTP. - Source Address Hashing
The source IP address is hashed and divided by the total weight of the running servers to designate which server will receive the request. This setup ensures the same client IP address will always reach the same real server as long as no server goes down or up. If the hash result changes because the number of running servers changing, many clients will be directed to a different server. This algorithm is generally used in TCP mode where no cookie may be inserted. It is also used when load balancing FTP traffic or attempting to maintain customer details stored in a particular real server to the same source IP address. - Notes on Weighting
All our algorithms use weighting. Weighted algorithms choose a server proportionally to its weight divided by the total of all servers' weights relative to the Dynamic Load Balancer. For example, if there are two servers—"A" with weight 2 and "B" with weight 1—then the algorithm will choose "A" 2/3 of the time and select "B" 1/3 of the time. The order in which the servers are selected is unspecified and subject to change, so no particular pattern should be expected or counted on. If you want an even distribution, you must assign an equal weight to all your servers. The management console has a feature that displays the % weight of a particular server relative to the other servers in the pool. This number changes as the real server weight is changed.
Persistence
Use this option if you want to send all requests in a session to the same real server. You can set persistence based on either destination or source addresses.
- None
None is the default option and will cause the selected algorithm to determine the routing. - Session Cookie
Persist based on server cookie. This option is only valid for Load Balancers with "protocol" set to "http" and will set persistence based on the destination address. You can set the name of the cookie if you want something other than “lbcookie.” - IP Subnet
Clients in the same /24 IP subnet will be routed to the same server for a limited period of time. This option sets persistence based on source address and is the only persistence method you can use if you cannot accept cookies.
Health Checker
The Health Checker is used to determine the health of the real servers. If the test against the server fails, the server is assumed to be unavailable and is moved out of rotation. If the next test is successful, the server is then put back into the rotation.
- HTTP
This test verifies the web server is responding. It checks both the port and the path specified in the health check. This option works well for regular non-encrypted traffic. - Connect
This test is for a successful IP connection. It does not use the Health Checker parameters (such as the path and hostname) because it is only checking the port. This is a good choice for non-web servers such as databases or email. - SSL
This test is for an SSL connection on the real server. It verifies that clients can open an encrypted connection to the server, but not that the server is returning correct results (such as successfully serving web pages). Use this option if you’re doing SSL pass-through.
Monitoring
GoGrid also provides monitoring statistics for Dynamic Load Balancers via the API and through the management console. The following statistics are available by previous hour, day, week, month, and year:
- – Inbound traffic
- – Outbound traffic
- – Current sessions
- – Failed health checks
