PK
FjCoa, mimetypeapplication/epub+zipPK FjC iTunesMetadata.plistX
A TCP Proxy handles TCP requests through TCP listeners for traffic tunnelling. While a TCP Proxy can have several TCP listeners associated with it, a TCP listener can be associated with only one TCP Proxy.
This chapter describes how to create, view, modify, and delete TCP proxies. It contains the following topics:
This section describes how you can set up a load-balanced service using Oracle Traffic Director with the minimum necessary configuration. The purpose of this section is to reinforce and illustrate the concepts discussed earlier in this chapter and to prepare you for the configuration tasks described in the remaining chapters.
This section contains the following topics:
Section 1.8.2, "Creating the Load Balancer for the Example Topology"
Section 1.8.3, "Verifying the Load-Balancing Behavior of the Oracle Traffic Director Instance"
In this example, we will create a single instance of Oracle Traffic Director that will receive HTTP requests and distribute them to two origin servers in the back end, both serving identical content.
Figure 1-4 shows the example topology.
Figure 1-4 Oracle Traffic Director Deployment Example
The example topology is based on the following configuration:
Administration server host and port: bin.example.com:8989
Administration node host and port: apps.example.com:8900
Virtual server host and port to receive requests from clients: hr-apps.example.com:1905
Host and port of origin servers (web servers in this example):
hr-1.example.com:80
hr-2.example.com:80
In the real world, both origin servers would serve identical content. But for this example, to be able to see load balancing in action, we will set up the index.html
page to which the DocumentRoot
directive of the web servers points, to show slightly different content, as follows:
For hr-1.example.com:80
: "Page served from origin-server 1"
For hr-2.example.com:80
: "Page served from origin-server 2"
Load-balancing method: Round robin
This section describes how to set up the topology described in Section 1.8.1, "Example Topology."
Install Oracle Traffic Director on the hosts bin.example.com
and apps.example.com
, as described in the Oracle Traffic Director Installation Guide.
On bin.example.com
create the administration server instance by using the configure-server
CLI command.
> $ORACLE_HOME/bin/tadm configure-server --port=8989 --user=admin
--instance-home=/production/otd/
This command will create an Administration Server. The password that is
provided will be required to access the Administration Server.
Enter admin-user-password>
Enter admin-user-password again>
OTD-70214 The Administration Server has been configured successfully.
The server can be started by executing: /production/otd/admin-server/bin/startserv
The Administration Console can be accessed at https://bin.example.com:8989 using user name 'admin'.
Start the administration server.
> /production/otd/admin-server/bin/startserv
Oracle Traffic Director 11.1.1.7.0 B01/14/2013 09:08
[NOTIFICATION:1] [OTD-80118] Using [Java HotSpot(TM) 64-Bit Server VM, Version 1.6.0_29] from [Sun Microsystems Inc.]
[NOTIFICATION:1] [OTD-80000] Loading web module in virtual server [admin-server] at [/admin]
[NOTIFICATION:1] [OTD-80000] Loading web module in virtual server [admin-server] at [/jmxconnector]
[NOTIFICATION:1] [OTD-10358] admin-ssl-port: https://bin.example.com:8989 ready to accept requests
[NOTIFICATION:1] [OTD-10487] successful server startup
On the apps.example.com
host, run the configure-server
command to register the host with the remote administration server as an administration node.
> $ORACLE_HOME/bin/tadm configure-server --user=admin --port=8989
--host=bin.example.com --admin-node --node-port=8900
--instance-home=/home/otd-instances
This command will create an Administration Node and register it with the remote Administration Server: https://bin.example.com:8989.
Enter admin-user-password>
OTD-70215 The Administration Node has been configured successfully.
The node can be started by executing: /home/otd-instances/admin-server/bin/startserv
Start the administration node.
> /home/otd-instances/admin-server/bin/startserv
Oracle Traffic Director 11.1.1.7.0 B01/14/2013 09:08
[NOTIFICATION:1] [OTD-80118] Using [Java HotSpot(TM) 64-Bit Server VM, Version 1.6.0_29] from [Sun Microsystems Inc.]
[NOTIFICATION:1] [OTD-80000] Loading web module in virtual server [admin-server] at [/jmxconnector]
[NOTIFICATION:1] [OTD-10358] admin-ssl-port: https://apps.example.com:8900 ready to accept requests
[NOTIFICATION:1] [OTD-10487] successful server startup
On the administration server (bin.example.com
), create a configuration named hr-config
, by using the create-config
CLI command.
> $ORACLE_HOME/bin/tadm create-config --user=admin --port=8989
--listener-port=1905 --server-name=hr-apps.example.com
--origin-server=hr-1.example.com:80,hr-2.example.com:80 hr-config
Enter admin-user-password>
OTD-70201 Command 'create-config' ran successfully.
Create an instance of the configuration hr-config
on the administration node apps.example.com
, by running the create-instance
CLI command from the administration server.
> $ORACLE_HOME/bin/tadm create-instance --user=admin --port=8989
--config=hr-config apps.example.com
Enter admin-user-password>
OTD-70201 Command 'create-instance' ran successfully.
Start the Oracle Traffic Director instance that you just created on apps.example.com
, by running the start-instance
CLI command from the administration server.
> $ORACLE_HOME/bin/tadm start-instance --config=hr-config
CLI204 Successfully started the server instance.
Note: The steps in this procedure use only the CLI, but you can perform step 6 onward by using the administration console as well. |
We have now successfully created an Oracle Traffic Director configuration, instantiated it on an administration node, and started the instance.
The Oracle Traffic Director instance that we created and started earlier is now listening for HTTP requests at the URL http://hr-apps.example.com:1905
.
This section describes how you can verify the load-balancing behavior of the Oracle Traffic Director instance by using your browser.
Note:
|
Enter the URL http://hr-apps.example.com:1905
in your browser.
A page with the following text is displayed:
"Page served from origin-server 1"
This indicates that the Oracle Traffic Director instance running on the apps.example.com
administration node received the HTTP request that you sent from the browser, and forwarded it to the origin server hr-1.example.com:80
.
Send another HTTP request to http://hr-apps.example.com:1905
by refreshing the browser window.
A page with the following text is displayed:
"Page served from origin-server 2"
This indicates that Oracle Traffic Director sent the second request to the origin server hr-2.example.com:80
Send a third HTTP request to http://hr-apps.example.com:1905
by refreshing the browser window again.
A page with the following text is displayed:
"Page served from origin-server 1"
This indicates that Oracle Traffic Director used the simple round-robin load-distribution method to send the third HTTP request to the origin server hr-1.example.com:80
.
You can add an origin server to an origin-server pool by using either the administration console or the CLI.
Note:
|
Before You Begin
Before you begin adding an origin server to a pool, decide the following:
The origin-server pool to which you want to add the origin server.
The host name or IP address of the origin server. It is recommended that the IP address that you provide is the InfiniBand interface IP address (IPoIB) or Socket Director Protocol (SDP) address.
Note: SDP is a native Infiniband protocol. With SDP, performance is very specific to work load. Hence, it is important to evaluate and compare the performance with SDP and IPoIB, and then select the one that meets your requirement. |
The port number at which the origin server listens for requests.
Whether the server is a backup origin server.
Oracle Traffic Director forwards requests to a backup origin server only when the health check indicates that none of the primary origin servers is available.
The proportion of the total request load that Oracle Traffic Director should distribute to the origin server. You define this proportion as a weight number that is relative to the weights assigned to the other origin servers in the pool.
You can use weights to get Oracle Traffic Director to distribute the request load based on the relative capacities of the origin servers in a pool.
Consider a pool consisting of three origin servers—os1
, os2
, and os3
, with the weights 1, 2, and 2 respectively. The total of the weights assigned to all the servers in the pool is 1+2+2=5. Oracle Traffic Director distributes a fifth (1/5) of the total load to os1
, and two-fifths (2/5) of the load to each of os2
and os3
.
Adding an Origin Server to a Pool Using the Administration Console
To add an origin server to a pool by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to create an origin server.
In the Common Tasks pane, click New Origin Server.
The New Origin Server wizard starts.
Follow the on-screen prompts to complete creation of the origin-server pool by using the details—origin-server pool, host, port, and so on—that you decided earlier.
After the origin server is created, the Results screen of the New Origin Server wizard displays a message confirming successful creation of the origin server.
Click Close on the Results screen.
The details of the origin server that you just defined are displayed on the Origin Servers page.
In addition, the Deployment Pending message is displayed at the top of the main pane. You can either deploy the updated configuration immediately by clicking Deploy Changes, or you can do so later after making further changes as described in Section 4.3, "Deploying a Configuration."
Adding an Origin Server to a Pool Using the CLI
To add an origin server to a pool, run the create-origin-server
command.
For example, the following commands adds soa-app.example.com:80
as origin server os1
in the pool osp1
of the configuration soa
.
tadm> create-origin-server --config=soa --origin-server-pool=osp1 soa-app.example.com:80 OTD-70201 Command 'create-origin-server' 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
, see the Oracle Traffic Director Command-Line Reference or run the command with the --help
option.
You can create an origin-server pool by using either the administration console or the CLI.
Note:
|
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 Section 6.5, "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:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to create a virtual server.
In the Common Tasks pane, click New Origin-Server Pool.
The New Origin-Server Pool wizard starts.
Follow the on-screen prompts to complete creation of the origin-server pool by using the details—name, load balancing method, origin servers, and so on—that you decided earlier.
After the origin-server pool is created, the Results screen of the New Origin-Server Pool wizard displays a message confirming successful creation of the origin-server pool.
Click Close on the Results screen.
The details of the origin-server pool that you just created are displayed on the Origin-Server Pools page.
In addition, the Deployment Pending message is displayed at the top of the main pane. You can either deploy the updated configuration immediately by clicking Deploy Changes, or you can do so later after making further changes as described in Section 4.3, "Deploying a Configuration."
Creating an Origin-Server Pool Using the CLI
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.
When you create a configuration, the configuration files—server.xml
and vs_name
-obj.conf
—are created in the configuration store on the administration server.
When you create instances of the configuration, the configuration files are copied from the configuration store to the instance-specific configuration directories on the nodes, as in the following examples:
INSTANCE_HOME/net-soa.example.com/config INSTANCE_HOME/net-dev.example.com/config
So the configuration files in the instance-specific configuration directories are usually identical to the configuration files stored in the configuration store on the administration server. In the following situations, a configuration stored on the administration server can be different from that of its instances.
You modified a configuration on the administration server, by using the administration console or CLI, but have not yet deployed the modified configuration to its instances.
You can rectify this out-of-sync situation by deploying the configuration as described in Section 4.3, "Deploying a Configuration."
You changed the configuration of an instance manually, by editing a configuration file directly in the instance's config
directory.
If you change the configuration of an instance manually by editing a configuration file—server.xml
or vs_name
-obj.conf
in the INSTANCE_HOME/net-
config_name
/config
directory, the next time you log in to the administration console and view the configuration, the alert Instance Configuration Modified is displayed. The alert indicates that the configuration stored on the administration server is different from the current configuration settings of one or more instances. The alert continues to be displayed till you synchronize the configuration stored on the administration server with that of all its instances, by doing one of the following:
Pull the modified configuration from one of the modified instances back into the configuration store of the administration server.
Discard the instance-specific configurations by redeploying the configuration from the administration server to the modified instances.
You can synchronize a configuration on the administration server with its instances by using either the administration console or the CLI.
Note: The CLI examples in this section are shown in shell mode ( |
Synchronizing Configurations on the Administration Server and Administration Nodes Using the Administration Console
To synchronize a configuration stored on the administration server with that of its instances by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which one or more instances have been modified. You can identify the configuration from its status, which would be Instance Configuration Modified.
The Instances page of the configuration is displayed, with the Instance Configuration Modified button at the top of the main pane.
Click the Instance Configuration Modified button.
The Deploy Configuration dialog box is displayed.
If you want to discard all of the instance-specific configurations and deploy the configuration that is currently stored on the administration server to all the instances, select the Discard Instance Changes option.
If you want to pull the configuration of a modified instance to the administration server, select Pull and Deploy Configuration from Node, and select the appropriate administration node.
For each administration node, you can review the names of the configuration files that are different from the configuration store on the administration server, by clicking View Details.
Click OK.
A message is displayed confirming that the configuration was successfully deployed.
Click Close.
Synchronizing Configurations on the Administration Server and Administration Nodes Using the CLI
To discard the instance-specific configurations and deploy the configuration that is currently stored on the administration server to all the instances, run the following command:
tadm> deploy-config -- force config_name
To pull configuration files from an instance to the configuration store on the administration server, run the following commands:
tadm> pull-config --config=config_name node tadm> deploy-config config_name
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.
When you redeploy a modified configuration to its instances, a backup of the previous configuration is created. For information about viewing a list of the available backups, see Section 4.8, "Viewing a List of Configuration Backups."
You can restore a configuration from a backup by using either the administration console or the CLI.
Note: The CLI examples in this section are shown in shell mode ( |
Restoring a Configuration from a Backup Using the Administration Console
To restore a configuration from a backup, by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to view a list of backups.
In the navigation pane, select Advanced Settings.
The Advanced Settings page is displayed.
Scroll down to the Configuration Backups section of the page.
Identify the backup that you want to restore, and click the icon displayed in the Restore column.
Restoring a Configuration from a Backup Using the CLI
To restore a configuration from a backup by using the CLI, run the following command:
tadm> restore-config --config=config_name --verbose --all
The Oracle Traffic Director administration server provides the interfaces that you can use to perform all of the administrative tasks for Oracle Traffic Director.
To create the administration server, do the following:
Run the configure-server
CLI command as shown in the following example:
> $ORACLE_HOME/bin/tadm configure-server --port=8989 --user=admin
--instance-home=/production/otd/
ORACLE_HOME
is the directory in which you installed Oracle Traffic Director.
Note: The user name can contain a maximum of 100 characters and must not contain spaces. |
The following message and prompt are displayed.
This command will create the administration server. The password that is provided will be required to access the administration server. Enter admin-user-password>
Enter the administrator password.
You will later use this password to log in to the Oracle Traffic Director administration console.
A prompt to enter the password again is displayed.
Enter admin-user-password again>
Confirm the administrator password by entering it again.
The files and resources pertaining to the administration server (configuration artifacts, executable commands, and so on) are located in the admin-server
subdirectory within the instance-home
directory specified with the configure-server
command.
For each of the Oracle Traffic Director configurations that you subsequently instantiate on the host that contains the administration server, a directory named net-
config_name
is created within the instance-home
directory, as shown in the following example:
/production/otd admin-server net-test net-soa net-adf
For more information about the configure-server
command, see the Oracle Traffic Director Command-Line Reference or run the command with the --help
option.
When you want to create a configuration that is similar to an existing configuration, you can copy the existing configuration and make the required changes later.
You can copy a configuration by using either the administration console or the CLI.
Note: The CLI examples in this section are shown in shell mode ( |
Copying a Configuration Using the Administration Console
To copy a configuration by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration that you want to copy.
In the Common Tasks pane, click Duplicate Configuration.
In the resulting dialog box, enter a name for the new configuration, and then click Duplicate
A message is displayed confirming that the configuration was copied.
Click Close.
Copying a Configuration Using the CLI
To copy a configuration, run the copy-config
command.
For example, the following command copies the configuration soa.example.com
to a new configuration named soa2.example.com
.
tadm> copy-config --config=soa.example.com soa2.example.com
OTD-70201 Command 'copy-config' ran successfully.
For more information about copy-config
, see the Oracle Traffic Director Command-Line Reference or run the command with the --help
option.
When you create a configuration, a virtual server is automatically created with the listener that you specified while creating the configuration. For the automatically created virtual server, as well as for any virtual server that you add subsequently in the configuration, a default route is created. The default route rule specifies that all requests to the virtual server should be routed to the origin-server pool that you specified while creating the virtual server. The default route of a virtual server cannot be deleted, but you can change its properties.
You can create additional routes for the virtual server, to route requests that satisfy specified conditions to specific origin-server pools. For example, in a banking software solution, if customer transactions for loans and deposits are processed by separate applications, you can host each of those applications in a separate origin-server pool behind an Oracle Traffic Director instance. To route customer requests to the appropriate origin-server pool depending on whether the request pertains to the loans or deposits applications, you can set up two routes as follows:
Route 1: If the request URI starts with /loan
, send the request to the origin-server pool that hosts the loans application.
Route 2: If the request URI starts with /deposit
, send the request to the origin-server pool that hosts the deposits application.
When a virtual server that is configured with multiple routes receives a request, it checks the request URI against each of the available routes. The routes are checked in the order in which they were created.
If the request satisfies the condition in a route, Oracle Traffic Director sends the request to the origin-server pool specified for that route.
If the request does not match the condition in any of the defined routes, Oracle Traffic Director sends the request to the origin-server pool specified in the default route.
WebSocket upgrade is enabled by default. In the Administration Console, use the WebSocket Upgrade check box to enable or disable WebSocket protocol for a route. Similarly, WebSocket protocol can also be enabled or disabled using the websocket-upgrade-enabled
property, which can be set using the set-route-prop CLI command. For more information, see Oracle Traffic Director Command-Line Reference.
You can configure routes in a virtual server by using either the administration console or the CLI.
Note:
|
Configuring Routes Using the Administration Console
To configure routes by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to configure routes.
In the navigation pane, expand Virtual Servers, expand the name of the virtual server for which you want to configure routes, and select Routes.
The Routes page is displayed. It lists the routes that are currently defined for the virtual server.
Creating a Route
Click New Route.
The New Route dialog box is displayed.
In the Name field, enter a name for the new route.
In the Origin Server Pool field, select the origin-server pool to which requests that satisfy the specified condition should be routed.
Click Next.
In the Condition Information pane, select a Variable/Function and an Operator from the respective drop-down lists, and provide a value in the Value field.
Select the and
/or
operator from the drop-down list when configuring multiple expressions. Similarly, use the Not
operator when you want the route to be applied only when the given expression is not true.
Click Ok.
To enter a condition manually, click Cancel and then click Edit Manually. In the Condition field, specify the condition under which the routing rule should be applied. For information about building condition expressions, click the help button near the Condition field or see "Using Variables, Expressions, and String Interpolation" in the Oracle Traffic Director Configuration Files Reference.
Click Next and then click Create Route.
The route that you just created is displayed on the Routes page.
In addition, the Deployment Pending message is displayed at the top of the main pane. You can either deploy the updated configuration immediately by clicking Deploy Changes, or you can do so later after making further changes as described in Section 4.3, "Deploying a Configuration."
Editing a Route
To change the settings of a route, do the following:
Click the Name of the route.
The Route Settings page is displayed.
Specify the parameters that you want to change.
On-screen help and prompts are provided for all of the parameters.
When you change the value in a field or tab out of a text field that you changed, the Save button near the upper right corner of the page is enabled.
At any time, you can discard the changes by clicking the Reset button.
After making the required changes, click Save.
A message, confirming that the updated configuration was saved, is displayed in the Console Messages pane.
In addition, the Deployment Pending message is displayed at the top of the main pane. You can either deploy the updated configuration immediately by clicking Deploy Changes, or you can do so later after making further changes as described in Section 4.3, "Deploying a Configuration."
Deleting a Route Rule
To delete a route rule, click the Delete button. At the confirmation prompt, click OK.
Configuring Routes Using the CLI
To create a route, run the create-route
command.
Examples:
The following command creates a route named loan-route
in the virtual server soa.example.com
of the configuration soa
, to send requests for which the URI matches the pattern /loan
to the origin-server pool loan-app
.
tadm> create-route --config=soa --vs=soa.example.com --condition="$uri='/loan'" --origin-server-pool=loan-app loan-route
OTD-70201 Command 'create-route' ran successfully.
The following command creates a route named images-route
in the virtual server soa.example.com
of the configuration soa
, to send requests for which the URI path matches the pattern /images
to the origin-server pool images-repo
.
tadm> create-route --config=soa --vs=soa.example.com --condition="$path='/images/*'" --origin-server-pool=images-repo images-route
OTD-70201 Command 'create-route' ran successfully.
The following command creates a route named subnet-route
in the virtual server soa.example.com
of the configuration soa
, to send requests from any client in the subnet 130.35.46.*
to the origin-server pool dedicated-osp
.
tadm> create-route --config=soa --vs=soa.example.com --condition="$ip='130.35.45.*'" --origin-server-pool=dedicated-osp subnet-route
OTD-70201 Command 'create-route' ran successfully.
The following command creates a route named body-route
in the virtual server soa.example.com
of the configuration soa
, to route requests to the origin-server pool dedicated-osp
if the request body contains the word alpha.
tadm> create-route --config=soa --vs=soa.example.com --condition="$body ='alpha'" --origin-server-pool=dedicated-osp body-route
OTD-70201 Command 'create-route' ran successfully.
Note that the value of the --condition
option should be a regular expression. For information about building condition expressions, see "Using Variables, Expressions, and String Interpolation" in the Oracle Traffic Director Configuration Files Reference.
To view a list of the routes defined for a virtual server, run the list-routes
command, as shown in the following example:
tadm> list-routes --config=soa --vs=soa.example.com
route condition
-------------------------
loan-route "$uri = '/loan'"
default-route -
To view the properties of a route, run the get-route-prop
command, as shown in the following example:
tadm> get-route-prop --config=soa --vs=soa.example.com --route=loan-route
keep-alive-timeout=15
sticky-cookie=JSESSIONID
condition="$uri = '/loan'"
validate-server-cert=true
always-use-keep-alive=false
origin-server-pool=origin-server-pool-1
sticky-param=jsessionid
route-header=Proxy-jroute
rewrite-headers=location,content-location
use-keep-alive=true
route=loan-route
log-headers=false
route-cookie=JROUTE
timeout=300
To change the properties of a route, run the set-route-prop
command.
Examples:
The following command changes the keep-alive timeout setting for the route named loan-route
in the virtual server soa.example.com
of the configuration soa
to 30 seconds.
tadm> set-route-prop --config=soa --vs=soa.example.com --route=loan-route keep-alive-timeout=30
The following command enables logging of the headers that Oracle Traffic Director sends to, and receives from, the origin servers associated with the route named default-route
in the virtual server soa.example.com
of the configuration soa
.
tadm> set-route-prop --config=soa --vs=soa.example.com --route=default-route log-headers=true
To delete a route, run the delete-route
command, as shown in the following example:
tadm> delete-route --config=soa --vs=soa.example.com loan-route
OTD-70201 Command 'delete-route' ran successfully.
To disable WebSocket support, run the set-route-prop
command with the websocket-upgrade-enabled
property, as shown in the following example:
tadm> set-route-prop --config=soa --vs=soa.example.com --route=default-route websocket-upgrade-enabled=false OTD-70201 Command 'set-route-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 CLI commands mentioned in this section, see the Oracle Traffic Director Command-Line Reference or run the commands with the --help
option.