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]](../images/ngzos.svg)
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.
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: .
-
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.