- Public - Standard bandwidth rates apply for outbound transfers. There is no charge for inbound transfers.
- Private - No charges apply for inbound or outbound bandwidth transfers over the Rackspace internal network.
Cloud Load Balancers: FAQs
See the pricing page for details. If you enable log delivery to your Cloud Files account, standard charges for Cloud Files apply. Additionally, standard charges apply for additional (unique) virtual IP addresses per load balancer.
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 Cloud Servers for optimal traffic management and maximum failover protection. Load balancers distribute workloads across two or more servers, network links, and other resources to maximize throughput, minimize response time, and avoid network overload.
When using SSL Termination on your load balancers, the following requirements should be understood.
- 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/intermediate certificate and associated private key.
- SSL Termination cannot be enabled when a Cloud Load Balancer is provisioned; it must be configured on existing load balancers by issuing a command through the API. Read our Developer's Guide to learn how to configure SSL Termination on an existing load balancers through the API.
For information about how to do this in the Control Panel, see SSL Termination - How to set it up.
ServiceNet is an internal only, multi-tenant network connection within each 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 utilize 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 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 IInternet 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, as illustrated in the following diagram.
SSL Termination on Cloud Load Balancers is supported via the API and through the Cloud Control Panel. SSL Termination allows users to have their secure traffic terminate at the load balancer with centralized certificate management. Features of this service are as follows:
- SSL acceleration for improved throughput
- Reduced CPU load at the application level for better performance
- HTTP/HTTPS session persistence
Note: SSL Termination should not be used when transferring certain types of Personally Identifiable Information (PII).
With SSL Termination the traffic is decrypted at the Cloud Load Balancer, and unencrypted traffic can now be distributed to one or more Cloud Servers to be processed
Following are other benefits:
- The ability to configure a load balancer that accepts both secure & unsecured traffic, or secure traffic only
- Can be a less expensive than a dedicated F5 load balancer solution
- Another alternative to using HA Proxy with Cloud Servers
Secure traffic comes in to your site over an encrypted SSL connection, and it must be decrypted by the webserver which holds the SSL certificate. The Cloud Load Balancer passes all traffic directly to the Cloud Server with the corresponding SSL certificate, placing the burden of the decryption on that server alone. This is because each device (Cloudserver or Cloud Load Balancer) handling traffic through an SSL connection requires either its own SSL certificate or a Licensed Certificate Option.
X-Forwarded-For HTTP header stores a visitor's originating IP address by default. For more information, see the API documentation for creating a Cloud Load Balancer.
You can quickly configure SSL termination for an existing Cloud Load Balancer by using the Cloud Control Panel.
- Click on an existing load balancer to open its Details Page.
- Scroll to the Optional Features section.
- Click the Edit pencil to the right of the Secure Traffic (SSL) option.
- In the pop-up dialog box, enter and save your SSL configuration.
To modify imposed API rate limits, contact Support.
A single Cloud Load Balancer is connected through a 10Gb/second network to both the public network and Rackspace's internal network, which has been tested to achieve about 9Gb/second of actual throughput. Some limiting factors might influence the actual throughput at any given time.
In most cases, it should take 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 for complete provisioning.
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 HIPAA and Gramm-Leach-Bliley acts, credit card information, or any personal data that can result in identity theft if disclosed.
Each load balancer comes with one public IPv4 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, because of the potential for significant bandwidth charges. Without RackConnect, you are billed for bandwidth charges for requests outbound from the load balancer, and responses outbound from the dedicated firewall, inbound to the load balancer, and outbound again from the load balancer returning to the user.
You can use the RackConnect Cisco 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 for 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 solution.
Yes, implementation and management of the Cloud Load Balancer solution is currently available through the Rackspace Cloud Control Panel and the API. To use the Cloud Load Balancer API, you should have a general understanding of the load balancing service and be familiar with the following technologies:
- RESTful web services
- HTTP/1.1 conventions
- JSON and serialization formats
- Atom Syndication Format