Classes summary
AbstractResource |
Class that represents abstract functionality for Load Balancer resources |
Access |
The access list management feature allows fine-grained network access controls
to be applied to the load balancer's virtual IP address. A single IP address,
multiple IP addresses, or entire network subnets can be added as a networkItem.
Items that are configured with the ALLOW type will always take precedence over
items with the DENY type. To reject traffic from all items except for those with
the ALLOW type, add a networkItem with an address of "0.0.0.0/0" and a DENY
type. |
Algorithm |
All load balancers utilize an algorithm that defines how traffic should be
directed between back-end nodes. The default algorithm for newly created load
balancers is RANDOM, which can be overridden at creation time or changed after
the load balancer has been initially provisioned. The algorithm name is to be
constant within a major revision of the load balancing API, though new
algorithms may be created with a unique algorithm name within a given major
revision of the service API. |
AllowedDomain |
The allowed domains are restrictions set for the allowed domain names used for
adding load balancer nodes. In order to submit a domain name as an address for
the load balancer node to add, the user must verify that the domain is valid by
using the List Allowed Domains call. |
ConnectionLogging |
The connection logging feature allows logs to be delivered to a Cloud Files
account every hour. For HTTP-based protocol traffic, these are Apache-style
access logs. For all other traffic, this is connection and transfer logging. |
ConnectionThrottle |
The connection throttling feature imposes limits on the number of connections
per IP address to help mitigate malicious or abusive traffic to your
applications. The attributes in the table that follows can be configured based
on the traffic patterns for your sites. |
ContentCaching |
When content caching is enabled, recently-accessed files are stored on the load
balancer for easy retrieval by web clients. Content caching improves the
performance of high traffic web sites by temporarily storing data that was
recently accessed. While it's cached, requests for that data will be served by
the load balancer, which in turn reduces load off the back end nodes. The result
is improved response times for those requests and less load on the web server. |
ErrorPage |
An error page is the html file that is shown to the end user when an error in
the service has been thrown. By default every virtual server is provided with
the default error file. It is also possible to submit a custom error page via
the Load Balancers API. Refer to Section 4.2.3, “Error Page Operations” for
details (http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/List_Errorpage-d1e2218.html). |
HealthMonitor |
Active health monitoring is a technique that uses synthetic transactions
executed at periodic intervals to determine the condition of a node. One of the
advantages of active health monitoring is that it does not require active
transactions to be processed by the load balancer to determine whether or not a
node is suitable for handling traffic. Active health monitoring is not applied
by default and must be enabled per load balancer. |
LoadBalancer |
A load balancer is a logical device which belongs to a cloud account. It is used
to distribute workloads between multiple back-end systems or services, based on
the criteria defined as part of its configuration. |
Metadata |
Sub-resource to manage Metadata |
Node |
The nodes defined by the load balancer are responsible for servicing the
requests received through the load balancer's virtual IP. By default, the load
balancer employs a basic health check that ensures the node is listening on its
defined port. The node is checked at the time of addition and at regular
intervals as defined by the load balancer health check configuration. If a
back-end node is not listening on its port or does not meet the conditions of
the defined active health check for the load balancer, then the load balancer
will not forward connections and its status will be listed as "OFFLINE". Only
nodes that are in an "ONLINE" status will receive and be able to service traffic
from the load balancer. |
NodeEvent |
This class will retrieve a list of events associated with the activity between
the node and the load balancer. The events report errors found with the node. |
NonIdUriResource |
Represents a resource that cannot be queried based on its ID. Instead, it uses
its parent URL, plus a generic path name, to determine its state. |
Protocol |
All load balancers must define the protocol of the service which is being load
balanced. The protocol selection should be based on the protocol of the back-end
nodes. When configuring a load balancer, the default port for the given protocol
will be selected unless otherwise specified. |
ReadOnlyResource |
Represents a read-only resource: one that cannot be created, updated or deleted. |
SessionPersistence |
Session persistence is a feature of the load balancing service that forces
multiple requests, of the same protocol, from clients to be directed to the same
node. This is common with many web applications that do not inherently share
application state between back-end servers. Two session persistence modes are
available, as described in the following table: |
SSLTermination |
The SSL Termination feature allows a load balancer user to terminate SSL traffic
at the load balancer layer versus at the web server layer. A user may choose to
configure SSL Termination using a key and an SSL certificate or an
(Intermediate) SSL certificate. |
Stats |
Returns statistics about the load balancer. |
UsageRecord |
Reports all usage for a Load Balancer recorded within the preceding 24 hours. |
VirtualIp |
A virtual IP (VIP) makes a load balancer accessible by clients. The load
balancing service supports either a public VIP, routable on the public Internet,
or a ServiceNet address, routable only within the region in which the load
balancer resides. |