[AIX Solaris HP-UX Linux Windows][z/OS]

Creating and configuring ODRs

The on demand router (ODR) is an intelligent HTTP and Session Initiation Protocol (SIP) proxy server in Intelligent Management. The ODR is the point of entry into an Intelligent Management environment and is a gateway through which HTTP requests and Session Initiation Protocol (SIP) messages flow to back-end application servers. You can configure the ODR to determine how it handles failure scenarios and how it tunes certain work requests.

[z/OS]

Before you begin

SIP is not supported on the z/OS® operating system.

Avoid trouble: The SIP ODR is stabilized, and is currently not recommended. Use the SIP proxy server instead.
[z/OS]Restriction: Intelligent Management requires that all configurations support User Datagram Protocol (UDP) traffic. However, Sysplex Distributor does not support UDP traffic in all configurations. When you use Sysplex Distributor for a mobile deployment manager in a configuration that includes Intelligent Management, the TCP/IP stack of the deployment manager must own Sysplex Distributor. This setup allows UDP traffic to flow and Intelligent Management to work properly. You can change the ownership of Sysplex Distributor by issuing a VARY TCPIP,,SYSPLEX,DEACTIVATE command.

We now support a subset of ODR functions in an Apache or IBM HTTP web server plug-in. Read about Intelligent Management for web servers for more information.

About this task

The ODR can momentarily queue requests for less important applications to allow requests from more important applications to be handled more quickly or to protect back-end application servers from being overloaded. The ODR is aware of the current location of a dynamic cluster instance so that requests can be routed to the correct endpoint. The ODR can also dynamically adjust the amount of traffic that is sent to each individual server instance based on process utilization and response times. The ODR performs WLOR (Weighted Least Outstanding Request) load balancing for selecting a server within a cluster when there is no affinity or when affinity is broken.

By default, the ODR binds to ports 80 and 443 for listening on HTTP and HTTPS, which requires running the ODR as a root user. If you want to run the ODR as a non-root user, you must change the PROXY listening ports to values greater than 1024.

The ODR is fully aware of the dynamic state of the cell, so that if one server in the cell fails, the requests are routed to another server. When the ODR is notified that the application has initialized on the restarted server, the ODR routes requests to that server again.

The ODR does not route any requests to the application on the application server until the application completes starting or initializing. If the application is started on other application servers, then the requests are routed to them. If the application is not started on any other servers, then the ODR still does not route to the starting-in-progress application server. Instead, a 503 message is returned.

Procedure

  • For more information about ODRs, read about creating ODRs.

    An ODR is a proxy server with advanced capabilities that are used to route work to server nodes. The configuration of the ODR in the DMZ is not supported. To configure ODRs to perform an SSL offload, read about configuring SSL offload for all HTTPS traffic. For information about other custom properties, read about the on demand router system and custom properties.

  • Follow the WebSphere® Application Server Network Deployment instructions in the proxy server settings topic to configure ODRs. For more information about Intelligent Management specific fields, read about configuring ODRs.
    Avoid trouble: In the Intelligent Management administrative console, use the following path to define the configuration of the ODR: Servers > Server types > On demand routers > odr_name > On demand router settings > On demand router properties.
  • By default, the ODR matches the incoming protocol to the outgoing protocol. For inbound HTTP requests, the request is forwarded over outbound HTTP. For inbound HTTPS, the request is forwarded over outbound HTTPS. This default behavior can either be changed for all HTTP and HTTPS traffic that is handled by the ODR, or on a per-Web module basis. For more information, read about configuring the SSL offload for all HTTPS traffic.
  • You can use ODR custom properties to change the behavior of your ODR. For example, you can change the error code that the ODR returns when messages are rejected because of processor or memory overload. For more information, read about the on demand router system and custom properties.
  • A web server should be configured as a trusted secure proxy because a trusted security proxy is allowed to pass information such as the virtual host name, or user identity to the ODR in private HTTP headers. For more information, read about configuring a web server as a trusted proxy server.
  • Define routing policies for generic server clusters.
  • Routing and service policies for SIP are defined at the ODRs. For more information, read about defining a service policy.
  • Optionally, create routing rules using scripting. For more information, see Intelligent Management: rules for ODR routing policy administrative tasks and manageODR.py script.

What to do next

Configure the middleware servers and dynamic clusters for your environment.