This chapter describes how to create and manage origin-server pools. It contains the following sections:
You can create an origin-server pool by using either the administration console or the CLI.
Note:
When you create an origin-server pool, you are, in effect, modifying a configuration. So for the settings of the new origin-server pool to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Deploying a Configuration.
The CLI examples in this section are shown in shell mode (tadm>
). For information about invoking the CLI shell, see Accessing the Command-Line Interface.
Oracle Java Cloud Service creates the initial origin server pool when you create an Oracle Java Cloud Service instance with a load balancer or add a load balancer to an Oracle Java Cloud Service instance. You need to create an origin server pool only if you require additional origin server pools.
Before You Begin
Before you begin creating an origin-server pool, decide the following:
A unique name for the origin-server pool. Choose the name carefully; after creating an origin-server pool, you cannot change its name.
host:port
combinations for the servers in the origin-server pool.
Note:
If the origin servers for which you want to create a pool are Oracle WebLogic Server managed servers in a cluster, it is sufficient to create the pool with any one of the managed servers as the origin server. You can then configure Oracle Traffic Director to discover the other managed servers in the pool dynamically. For more information, see Configuring an Oracle WebLogic Server Cluster as an Origin-Server Pool.
The communication protocol—HTTP, HTTPS or TCP—of the servers in the pool.
The address family that the servers in the origin-server pool use to listen for requests.
The supported address families are:
inet
(IPv4)
inet6
(IPv6)
inet-sdp
(Sockets Direct Protocol): Select this family if the servers in the origin-server pool are on the InfiniBand fabric and listen on an SDP interface, such as Oracle WebLogic Servers deployed on Oracle Exalogic machines.
Note:
For Oracle Traffic Director to communicate with WebLogic Server over SDP, further configuration steps are required on the WebLogic Server. For more information about these configuration steps, see "Enabling Cluster-Level Session Replication Enhancements" in the Oracle Fusion Middleware Exalogic Enterprise Deployment Guide.
Creating an Origin-Server Pool Using the Administration Console
To create an origin-server pool by using the administration console, do the following:
To create an origin-server pool, run the create-origin-server-pool
command.
For example, the following command creates an origin-server pool osp-soa
containing two origin servers http://soa.example.com:1901
and http://soa.example.com:1902
in the configuration soa
.
tadm> create-origin-server-pool --config=soa --type=http --origin-server=soa.example.com:1901,soa.example.com:1902 osp-soa OTD-70201 Command 'create-origin-server-pool' ran successfully.
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the deploy-config
command.
For more information about create-origin-server-pool
, see the Oracle Traffic Director Command-Line Reference or run the command with the --help
option.
You can view a list of origin-server pools by using either the administration console or the CLI.
Note:
The CLI examples in this section are shown in shell mode (tadm>
). For information about invoking the CLI shell, see Accessing the Command-Line Interface.
Viewing a List of Origin-Server Pools Using the Administration Console
To view a list of origin-server pools by using the administration console, do the following:
You can view the properties of an origin-server pool in detail by clicking on its name.
To view a list of origin-server pools, run the list-origin-server-pools
command, as shown in the following example:
tadm> list-origin-server-pools --config=soa --verbose --all name type load-distribution ------------------------------------------------- osp1 http least-connection-count osp2 http round robin osp3 https least-connection-count
You can view the general properties and health-check settings of an origin-server pool by running the get-origin-server-pool-prop
and get-health-check-prop
command respectively.
For more information about the CLI commands mentioned in this section, see the Oracle Traffic Director Command-Line Reference or run the commands with the --help
option.
You can change the properties of an origin-server pool by using either the administration console or the CLI.
Note:
When you modify an origin-server pool, you are, in effect, modifying a configuration. So for the updated origin-server pool settings to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Deploying a Configuration.
The CLI examples in this section are shown in shell mode (tadm>
). For information about invoking the CLI shell, see Accessing the Command-Line Interface.
Changing the Properties of an Origin-Server Pool Using the Administration Console
To change the properties of an origin-server pool by using the administration console, do the following:
To change the network protocol and load-balancing method for an origin-server pool, run the set-origin-server-pool-prop
command.
For example, the following command changes the load-balancing method for the origin-server pool osp1
in the configuration soa
to the round-robin method.
tadm> set-origin-server-pool-prop --config=soa --origin-server-pool=osp1 load-distribution=round-robin OTD-70201 Command 'set-origin-server-pool-prop' ran successfully.
To change the health-check parameters for an origin-server pool, run the set-health-check-prop
command.
For example, the following command changes the health-check ping interval for servers in the origin-server pool osp1
of the configuration soa
to 60 seconds.
tadm> set-health-check-prop --config=soa --origin-server-pool=osp1 interval=60 OTD-70201 Command 'set-origin-server-pool-prop' ran successfully.
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the deploy-config
command.
For a list of the properties that you can set or change by using the set-origin-server-pool-prop
and set-health-check-prop
commands, see the Oracle Traffic Director Command-Line Reference or run the command with the --help
option.
You can delete an origin-server pool by using either the administration console or the CLI.
Note:
You cannot delete an origin-server pool that is associated with one or more routes in virtual servers.
To delete an origin-server pool that is associated with routes, you must first delete the referring routes, as described in Configuring Routes.
When you delete an origin-server pool, you are, in effect, modifying a configuration. So for the updated configuration to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Deploying a Configuration.
The CLI examples in this section are shown in shell mode (tadm>
). For information about invoking the CLI shell, see Accessing the Command-Line Interface.
Deleting an Origin-Server Pool Using the Administration Console
To delete an origin-server pool by using the administration console, do the following:
To delete an origin-server pool, run the delete-origin-server-pool
command, as shown in the following example:
tadm> delete-origin-server-pool --config=soa osp1
OTD-70201 Command 'delete-origin-server-pool' ran successfully.
Note:
If the specified origin-server pool is associated with one or more routes in virtual servers, the following error message is displayed:
OTD-67108 Cannot delete the origin-server pool. It is referred by virtual server(s): vs1_name,vs1_name,[...]
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the deploy-config
command.
For more information about delete-origin-server-pool
, see the Oracle Traffic Director Command-Line Reference or run the command with the --help
option.
Note:
Oracle Traffic Director has built-in support for some common functionality offered by the WebLogic Server plug-in. Hence Oracle Traffic Director does not require any other plug-in to inter-operate with WebLogic Server.
If you want to create an origin-server pool that represents a cluster of Oracle WebLogic Server managed servers, you need not specify each managed server in the cluster as an origin server. It is sufficient to specify any one of the managed servers as the sole origin server in the pool. You can configure Oracle Traffic Director to discover the presence of other Oracle WebLogic Server instances in the cluster dynamically, and distribute client requests to the managed server that is configured as an origin server and to the dynamically discovered managed servers in the same cluster.
So when dynamic discovery is enabled, if any of the managed servers in the cluster is stopped, added, or removed, you need not update the definition of the origin-server pool. However, for detecting changes in the Oracle WebLogic Server cluster, Oracle Traffic Director sends health-check requests at a specified interval, which causes some overhead.
When dynamic discovery is enabled for an origin-server pool, Oracle Traffic Director discovers the remaining Oracle WebLogic Server managed servers in the cluster, by doing the following:
When an Oracle Traffic Director instance starts, it checks whether the origin servers specified in the pool are Oracle WebLogic Server managed servers and whether the servers belong to a cluster, by sending an HTTP health-check request to each configured origin server.
The origin server's response indicates whether the server is an Oracle WebLogic Server managed server. If the origin server is an Oracle WebLogic Server managed server that belongs to a cluster, the response also includes a list of the managed servers in the cluster.
Oracle Traffic Director uses the information in the response from the origin server to update the configuration with the discovered managed servers.
The dynamically discovered origin servers inherit all of the properties—weight, maximum connections, and so on—that are specified for the configured origin server.
Subsequently, at each health-check interval (default: 30 seconds) configured for the origin-server pool, Oracle Traffic Director attempts to detect changes in the cluster, by sending dynamic-discovery health-check requests to the Oracle WebLogic Server instances that are configured as origin servers in the pool.
If the response indicates a change—removal or addition of a managed server—in the cluster since the previous health check, Oracle Traffic Director updates the configuration with the new set of dynamically discovered origin servers.
Note:
Dynamically discovered origin servers are not stored permanently in the origin-server pool definition of the instance's configuration. So when you restart an Oracle Traffic Director instance, the process of dynamic discovery starts afresh.
The HTTP request type that Oracle Traffic Director sends for dynamic discovery is the health-check request type that is currently configured for the origin-server pool—OPTIONS
(default) or GET
. For more information, see Configuring Health-Check Settings for Origin-Server Pools.
Oracle Java Cloud Service enables dynamic discovery for the initial origin server pool when you create an Oracle Java Cloud Service instance with a load balancer or add a load balancer to an Oracle Java Cloud Service instance.
If you create additional origin server pools, you must enable dynamic discovery for these origin server pools yourself. Dynamic discovery of Oracle WebLogic Server managed servers in a cluster is not enabled by default for any origin server pools that you add yourself. You can enable dynamic discovery by using either the administration console or the CLI.
Note:
When you modify an origin-server pool, you are, in effect, modifying a configuration. So for the updated origin-server pool settings to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Deploying a Configuration.
The CLI examples in this section are shown in shell mode (tadm>
). For information about invoking the CLI shell, see Accessing the Command-Line Interface.
Enabling Dynamic Discovery Using the Administration Console
To enable dynamic discovery of WebLogic Server managed servers in a cluster by using the administration console, do the following:
To enable dynamic discovery of Oracle WebLogic Server managed servers in a cluster, run the set-health-check-prop
command.
For example, the following command enables dynamic discovery of managed servers in the Oracle WebLogic Server cluster that the wls-1
origin-server pool represents.
tadm> set-health-check-prop --config=soa.example.com --origin-server-pool=wls-1 dynamic-server-discovery=true OTD-70201 Command 'set-health-check-prop' ran successfully.
Note:
If the current health-check protocol is TCP, an error message is displayed indicating that the protocol must be changed to HTTP in order to enable dynamic discovery.
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the deploy-config
command.
For more information about set-health-check-prop
, see the Oracle Traffic Director Command-Line Reference or run the command with the --help
option.
To ensure that requests are distributed to only those origin servers that are available and can receive requests, Oracle Traffic Director monitors the availability and health of origin servers by sending health-check requests to all of the origin servers in a pool.
You can configure health-check parameters for an origin-server pool by using either the administration console or the CLI.
Note:
When you configure health-check settings for an origin-server pool, you are, in effect, modifying a configuration. So for the updated configuration to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Deploying a Configuration.
The CLI examples in this section are shown in shell mode (tadm>
). For information about invoking the CLI shell, see Accessing the Command-Line Interface.
When Does Oracle Traffic Director Send Health-Check Requests?
When an Oracle Traffic Director instance starts, it performs an initial health check for all the origin servers in all of the configured origin-server pools.
If the initial health check indicates that an origin server is healthy, Oracle Traffic Director sends further health-check requests to an origin server only in the following situations:
The server has not served any request successfully for the entire duration of the previous health-check interval.
Dynamic discovery is enabled for this origin server pool. For more information, see Configuring an Oracle WebLogic Server Cluster as an Origin-Server Pool.
If a health check—either initial or subsequent—indicates that an origin server is not available, Oracle Traffic Director repeats the health check at the specified health-check interval.
Configurable Health-Check Settings
Table 6-1 lists the health-check settings that you can configure for each origin-server pool in a configuration.
Table 6-1 Health-Check Parameters
Parameter | Default Value |
---|---|
The type of connection—HTTP or TCP—that Oracle Traffic Director should attempt with the origin server to determine its health.
|
HTTP |
The frequency at which health-check requests should be sent. |
30 seconds |
The duration after which a health-check request should be timed out if no response is received from the origin server. |
5 seconds |
The number of times that Oracle Traffic Director should attempt to connect to an origin server in the pool, before marking it as unavailable. |
5 |
The HTTP request method—GET or OPTIONS—that should be sent. |
OPTIONS |
The URI that should be sent for HTTP requests. |
/ |
The HTTP response codes that Oracle Traffic Director can accept as indicators of a healthy origin server. By default, Oracle Traffic Director accepts response codes from |
|
For HTTP GET health-check requests, a regular expression for the response body that Oracle Traffic Director can accept as the indicator of a healthy origin server |
|
For HTTP GET health-check requests, the maximum number of bytes in the response body that Oracle Traffic Director should consider when comparing the response body with the specified acceptable response body. |
2048 |
When Is an Origin Server Considered Available and Healthy?
If the configured health-check connection type is TCP, an origin server is considered available if the connection is successfully established, indicating that the server is actively listening on its service port.
If the configured health-check connection type is HTTP, an origin server is considered available and health when all of the following conditions are fulfilled:
There is no error while sending the HTTP request.
The response is received before timeout period is reached.
The status code in the response matches any of the acceptable response codes, if specified.
By default, Oracle Traffic Director accepts response codes from 1xx
to 4xx
as indicators of a healthy origin server.
The response body matches the acceptable response body, if specified.
Configuring Health-Check Settings for Origin Servers Using the Administration Console
To view and change health-check settings origin servers in a pool by using the administration console, do the following:
To view the current health-check settings for an origin-server pool in a configuration, run the get-health-check-prop
command, as shown in the following example:
tadm> get-health-check-prop --config=soa --origin-server-pool=osp1
response-body-match-size=2048
protocol=HTTP
interval=30
request-method=OPTIONS
failover-threshold=3
request-uri=/
dynamic-server-discovery=false
timeout=5
To change the health-check settings for an origin-server pool in a configuration, run the set-health-check-prop
command.
For example, the following command changes the health-check interval to 60 seconds and the health-check timeout period to 10 seconds for the origin-server pool osp1
in the configuration soa
.
tadm> set-health-check-prop --config=soa --origin-server-pool=osp1 interval=60 timeout=10
OTD-70201 Command 'set-health-check-prop' ran successfully.
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the deploy-config
command.
For more information about the commands mentioned in this section, see the Oracle Traffic Director Command-Line Reference or run the commands with the --help
option.