Last updated on: 2019-01-15
Authored by: Rackspace Support
Your business’s website, applications, and web-based workloads depend on high availability. Rackspace Cloud Load Balancers enable you to quickly balance the workload of multiple Rackspace Cloud Servers for optimal traffic management and maximum failover protection. Load balancers distribute workloads across two or more servers, network links, or other resources to maximize throughput, minimize response time, and avoid network overload.
X-Forwarded-For HTTP header stores a visitor’s
originating Internet Protocol (IP) address by default. For more information,
see the API documentation for creating a Cloud Load
Secure Sockets Layer (SSL) termination enables you to terminate your secure traffic at the load balancer with centralized certificate management. This service has the following features:
Note: You should not use SSL termination when you are transferring certain types of Personally Identifiable Information (PII).
You can quickly configure SSL termination for an existing Cloud Load Balancer by using the following steps:
Note: If you see the message
service unavailable when you test your
website in your browser or health monitoring on the load balancer is removing
your web server node, ensure that your firewall allows connections on port 80.
Also verify that your virtual host is configured to listen on port 80.
To modify imposed API rate limits, contact Rackspace Support.
A single Cloud Load Balancer is connected through a 10 GB per second network to both the public network and Rackspace’s internal network, which has been tested to achieve about 9 GB per second of actual throughput. Some limiting factors might influence the actual throughput at any given time.
How long does it take to provision a load balancer?
In most cases, it takes less than one minute to provision a load balancer after the API request is submitted. During periods of extreme system load, it should take no more than a few minutes to complete the provisioning process.
You should not use SSL termination when transferring certain types of sensitive customer data classified as Personally Identifiable Information (PII). Examples of PII include information protected by the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and Gramm-Leach-Bliley acts, credit card information, or any personal data that might result in identity theft if it is disclosed.
Each load balancer comes with one public IPv4 address and one public IPv6 address.
A single load balancer is capable of consistently handling 20,000 concurrent connections with support for periodic spikes estimated at up to 100,000 concurrent connections. Because Cloud Load Balancers are implemented in a multi-tenant environment, estimates are not guaranteed and might vary depending on the number of concurrent connections that other customer load balancers are processing.
Yes, but we recommend using RackConnect® to include dedicated servers except in low-traffic scenarios, due to the potential for significant bandwidth charges. If you don’t use RackConnect, you are billed bandwidth charges for outbound requests from the load balancer, outbound responses to the load balancer from the dedicated firewall, and also for outbound messages from the load balancer to the user.
You can use the RackConnect Cisco® Adaptive Security Appliance (ASA) solution to connect dedicated servers and Cloud Servers while leveraging Cloud Load Balancers to balance the workload between the Cloud Servers. Charges apply for outgoing bandwidth through the dedicated environment, as well as inbound and outbound traffic associated with the load balancers.
To include dedicated and cloud servers in the same resource pools (to balance the workload between both platforms), use the RackConnect F5® BIG-IP® Local Traffic Manager (LTM) solution.
Yes, you can implement and manage Cloud Load Balancers through the Rackspace Cloud Control Panel and the API. To use the Cloud Load Balancers API, you should have a general understanding of the load balancing service and be familiar with the following technologies:
Following are the bandwidth charges for public and private traffic:
See Rackspace Cloud Load Balancers for detailed information about pricing. If you enable log delivery to your Cloud Files account, standard charges for Cloud Files apply. In addition, standard charges apply for additional (unique) virtual IP addresses per load balancer.
When you are using SSL termination on your load balancers, you should understand the following requirements:
Additional fees apply when SSL termination is enabled.
SSL termination is available to Rackspace Cloud Load Balancer customers in the US and UK with a valid SSL certificate or intermediate certificate and an associated private key.
You cannot enable SSL termination when a Cloud Load Balancer is provisioned. You must configure it on existing load balancers by issuing a command through the API.
To learn how to complete this process by using the API, see SSL termination.
To learn how to complete this process by using the Cloud Control Panel, see “How do I configure SSL termination by using the Cloud Control Panel?” in this FAQ.
ServiceNet is an internal-only, multi-tenant network connection within a Rackspace data center. ServiceNet IP addresses are not accessible from the public Internet and are local to each data center.
Note: You can configure your account resources, such as Cloud Servers and Cloud Load Balancers, to use a ServiceNet IP address instead of the public IP address. Any traffic that occurs between your cloud resources on the Rackspace network does not incur bandwidth charges.
If you filter traffic to your servers by using a firewall, the best practice is to allow the subnet range in which your load balancer resides. For more information about how to filter traffic from a load balancer on your servers, see Using Cloud Load Balancers with RackConnect.
After SSL termination decrypts the data at the Cloud Load Balancer, it passes the unencrypted data to any nodes that are configured for that device. If you have nodes that are not in the same data center as the SSL-enabled load balancer, that unencrypted data is sent over the public Internet to those nodes. Therefore, we recommend that you use an SSL-enabled load balancer only with nodes that reside in the same data center as the load balancer. The proximity allows the load balancer to use the nodes' private IP addresses (the ServiceNet) to limit unencrypted traffic to within the data center’s network.
With SSL termination, traffic is decrypted at the Cloud Load Balancer, and unencrypted traffic can be distributed to one or more Cloud Servers to be processed.
Following are other benefits:
Secure traffic comes in to your site over an encrypted SSL connection, and it must be decrypted by the web server that holds the SSL certificate. The Cloud Load Balancer passes all of the traffic directly to the Cloud Server with the corresponding SSL certificate, placing the burden of the decryption on that server alone. This occurs because each device (Cloud Server or Cloud Load Balancer) that is handling traffic through an SSL connection requires either its own SSL certificate or a Licensed Certificate Option.
©2020 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License