Loading
Compute + Network + Storage - GoGrid Cloud Platform

Load Balancers

A next-generation design that is self-healing, designed to be highly available, and lets you dynamically manage your traffic load.

  • Prevent application downtime
  • High availability out-of-the-box
  • Rapid scaling and application uptime

Pricing

Dynamic Load Balancer pricing is based on two factors: usage and outbound transfer. The first 744 hours of usage are free. Any time used after that incurs a charge. All outbound transfer incurs a charge, which differs depending on whether you’re sending traffic to a GoGrid server or to one outside of GoGrid.

Dynamic Load Balancer Pricing
Load Balancing Type Per Unit Monthly
Dynamic Load Balancer Usage – first 744 hours Free Free
Dynamic Load Balancer Usage – first 745+ hours $0.03 per hour $21.90
Dynamic Load Balancer Transfer* $0.015 per GB N/A
Dynamic Load Balancer Non-GoGrid Transfer $0.13 per GB N/A
Dynamic Load Balancer Inbound Transfer Free N/A

*Load Balancer GoGrid transfer pricing is a surcharge on top of existing outbound transfer

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

Hello!

  • Welcome to GoGrid!
  • I'm a Cloud Infrastructure and Big Data Solutions expert.
  • What questions do you have today?
Call us at 1(877) 946-4743 (US & Canada)
IN THE NEWS

Big data gives power providers a better view of energy consumption

Power companies throughout the United States are now using data collection tools to gather the information from smart meters, substations and distributed resources in an effort to figure out how... Read more


GoGrid Customers
GoGrid Compliance