| _create_time |
Timestamp of resource creation |
EpochMsTimestamp |
Readonly
Sortable |
| _create_user |
ID of the user who created this resource |
string |
Readonly |
| _last_modified_time |
Timestamp of last modification |
EpochMsTimestamp |
Readonly
Sortable |
| _last_modified_user |
ID of the user who last modified this resource |
string |
Readonly |
| _links |
References related to this resource
The server will populate this field when returing the resource. Ignored on PUT and POST. |
array of ResourceLink |
Readonly |
| _protection |
Indicates protection status of this resource
Protection status is one of the following:
PROTECTED - the client who retrieved the entity is not allowed
to modify it.
NOT_PROTECTED - the client who retrieved the entity is allowed
to modify it
REQUIRE_OVERRIDE - the client who retrieved the entity is a super
user and can modify it, but only when providing
the request header X-Allow-Overwrite=true.
UNKNOWN - the _protection field could not be determined for this
entity.
|
string |
Readonly |
| _revision |
Generation of this resource config
The _revision property describes the current revision of the resource. To prevent clients from overwriting each other's changes, PUT operations must include the current _revision of the resource, which clients should obtain by issuing a GET operation. If the _revision provided in a PUT request is missing or stale, the operation will be rejected. |
int |
|
| _schema |
Schema for this resource |
string |
Readonly |
| _self |
Link to this resource |
SelfResourceLink |
Readonly |
| _system_owned |
Indicates system owned resource |
boolean |
Readonly |
| active_monitor_ids |
active monitor identifier list
In case of active healthchecks, load balancer itself initiates new
connections (or sends ICMP ping) to the servers periodically to check
their health, completely independent of any data traffic. Active
healthchecks are disabled by default and can be enabled for a server
pool by binding a health monitor to the pool. If multiple active
monitors are configured, the pool member status is UP only when the
health check status for all the monitors are UP.
|
array of string |
|
| algorithm |
pool balancing algorithm for backend pool members
Load balancing algorithm, configurable per pool controls how the
incoming connections are distributed among the members.
|
PoolAlgorithm |
Default: "ROUND_ROBIN" |
| description |
Description of this resource |
string |
Maximum length: 1024
Sortable |
| display_name |
Identifier to use when displaying entity in logs or GUI
Defaults to ID if not set |
string |
Maximum length: 255
Sortable |
| id |
Unique identifier of this resource |
string |
Sortable |
| member_group |
Load balancer member setting with grouping object
Load balancer pool support grouping object as dynamic pool members.
When member group is defined, members setting should not be specified.
|
PoolMemberGroup |
|
| members |
load balancer pool members
Server pool consists of one or more pool members. Each pool member
is identified, typically, by an IP address and a port.
|
array of PoolMember |
|
| min_active_members |
minimum number of active pool members to consider pool as active
A pool is considered active if there are at least certain
minimum number of members.
|
integer |
Minimum: 1
Maximum: 2147483647
Default: "1" |
| passive_monitor_id |
passive monitor identifier
Passive healthchecks are disabled by default and can be enabled by
attaching a passive health monitor to a server pool.
Each time a client connection to a pool member fails, its failed count
is incremented. For pools bound to L7 virtual servers, a connection is
considered to be failed and failed count is incremented if any TCP
connection errors (e.g. TCP RST or failure to send data) or SSL
handshake failures occur. For pools bound to L4 virtual servers, if no
response is received to a TCP SYN sent to the pool member or if a TCP
RST is received in response to a TCP SYN, then the pool member is
considered to have failed and the failed count is incremented.
|
string |
|
| resource_type |
Must be set to the value LbPool |
string |
|
| snat_translation |
snat translation configuration
Depending on the topology, Source NAT (SNAT) may be required to ensure
traffic from the server destined to the client is received by the load
balancer. SNAT can be enabled per pool. If SNAT is not enabled for a
pool, then load balancer uses the client IP and port (spoofing) while
establishing connections to the servers. This is referred to as no-SNAT
or TRANSPARENT mode.
|
LbSnatTranslation
(Abstract type: pass one of the following concrete types)
LbSnatAutoMap
LbSnatIpPool |
|
| tags |
Opaque identifiers meaningful to the API user |
array of Tag |
Maximum items: 30 |
| tcp_multiplexing_enabled |
TCP multiplexing enable flag
TCP multiplexing allows the same TCP connection between load balancer
and the backend server to be used for sending multiple client requests
from different client TCP connections.
|
boolean |
Default: "False" |
| tcp_multiplexing_number |
maximum number of TCP connections for multiplexing
The maximum number of TCP connections per pool that are idly kept alive
for sending future client requests.
|
integer |
Minimum: 0
Maximum: 2147483647
Default: "6" |