11-10 Using Clusters for Oracle WebLogic Server
The Administration Server should not participate in a cluster. The Administration Server should be dedicated to the process of administering servers: maintaining
configuration data, starting and shutting down servers, and deploying and undeploying applications. If the Administration Server also handles client requests,
there is a risk of delays in accomplishing administration tasks.
There is no benefit in clustering an Administration Server; the administrative objects are not clusterable, and will not failover to another cluster member if the
administrative server fails. Deploying applications on an Administration Server can reduce the stability of the server and the administrative functions it provides. If an
application you deploy on the Administration Server behaves unexpectedly, it could interrupt operation of the Administration Server.
For these reasons, make sure that the Administration Servers IP address is not included in the cluster-wide DNS name.
11.7.3 Firewall Considerations
If your configuration includes a firewall, locate your proxy server or load-balancer in your DMZ, and the cluster, both Web and EJB containers, behind the firewall. Web
containers in DMZ are not recommended. See Section 9.5.1, Basic Firewall for Proxy
Architectures. If you place a firewall between the servlet cluster and object cluster in a multi-tier
architecture, bind all servers in the object cluster to public DNS names, rather than IP addresses. Binding those servers with IP addresses can cause address translation
problems and prevent the servlet cluster from accessing individual server instances.
If the internal and external DNS names of a WebLogic Server instance are not identical, use the ExternalDNSName attribute for the server instance to define the servers
external DNS name. Outside the firewall the ExternalDNSName should translate to external IP address of the server. Set this attribute in the Administration Console using
the Servers Configuration General page. See Servers Configuration General in Oracle WebLogic Server Administration Console Help.
In any cluster architecture that utilizes one or more firewalls, it is critical to identify all WebLogic Server instances using publicly-available DNS names, rather than IP
addresses. Using DNS names avoids problems associated with address translation policies used to mask internal IP addresses from untrusted clients.
Figure 11–1 describes the potential problem with using IP addresses to identify
WebLogic Server instances. In this figure, the firewall translates external IP requests for the subnet xxx to internal IP addresses having the subnet yyy.
Note: Use of ExternalDNSName is required for configurations in
which a firewall is performing Network Address Translation, unless clients are accessing WebLogic Server using t3 and the default
channel. For instance, ExternalDNSName is required for configurations in which a firewall is performing Network Address
Translation, and clients are accessing WebLogic Server using HTTP via a proxy plug-in.
Clustering Best Practices 11-11
Figure 11–1 Translation Errors Can Occur When Servers are Identified by IP Addresses
The following steps describe the connection process and potential point of failure:
1. The client initiates contact with the WebLogic Server cluster by requesting a
connection to the first server at 205.20.xxx.100:7001. The firewall translates this address and connects the client to the internal IP address of 205.20.yyy.100:7001.
2. The client performs a JNDI lookup of a pinned Object C that resides on the third
WebLogic Server instance in the cluster. The stub for Object C contains the internal IP address of the server hosting the object, 205.20.yyy.300:7001.
3. When the client attempts to instantiate Object C, it requests a connection to the
server hosting the object using IP address 205.20.yyy.300:7001. The firewall denies this connection, because the client has requested a restricted, internal IP address,
rather than the publicly-available address of the server.
If there was no translation between external and internal IP addresses, the firewall would pose no problems to the client in the above scenario. However, most security
policies involve hiding and denying access to internal IP addresses.
11.7.4 Evaluate Cluster Capacity Prior to Production Use
