This chapter contains the following sections:
All Oracle Fusion Middleware enterprise deployments are designed to demonstrate the best practices for installing and configuring an Oracle Fusion Middleware production environment.
A best practices approach starts with the basic concept of a multi-tiered deployment and standard communications between the different software tiers.
Figure 1-1 shows a typical enterprise deployment, including the Web tier, application tier and data tier.
For a description of each tier and the standard protocols used for communications within a typical Oracle Fusion Middleware enterprise deployment see Section 1.2, "Understanding the Typical Enterprise Deployment Topology Diagram".
The following sections provide a detailed description of the typical enterprise topology diagram:
The topology is divided into several security zones, which are separated by firewalls:
The firewalls are configured to allow data to be transferred only through specific communication ports. Those ports (or in some cases, the protocols that will need open ports in the firewall) are shown on each firewall line in the diagram.
On the firewall protecting the Web tier, only the HTTP ports are open: 443 for HTTPS and 80 for HTTP.
On the firewall protecting the Application tier, Oracle WebLogic Server Node manager, HTTP ports, and MBean proxy port are open.
Applications that require external HTTP access can use the Oracle HTTP Server instances as a proxy. Note that this port for outbound communications only and the proxy capabilities on the Oracle HTTP Server must be enabled.
On the firewall protecting the Data tier, the database listener port (typically, 1521) must be open.
The LDAP ports (typically, 389 and 636) are also required to be open for communication between the authorization provider and the LDAP-based identity store.
The ONS port (typically, 6200) is also required so the application tier can receive notifications about workload and events in the Oracle RAC Database. These events are used by the Oracle WebLogic Server connection pools to adjust quickly (creating or destroying connections), depending on the availability and workload on the Oracle RAC database instances.
For a complete list of the ports you must open for a specific Oracle Fusion Middleware enterprise deployment topology, see the chapter that describes the topology you want to implement, or refer to the Enterprise Deployment Workbook for the topology you are implement. For more information, see LINK TO CHAPTER.
The enterprise deployment topology consists of the following high-level tiers:
A hardware load balancer that routes requests from the Internet to the Web servers in the Web tier. It also routes requests from internal clients or other components that are performing internal invocations within the corporate network.
A Web tier, consisting of two or more physical computers that are hosting Web server instances (for load balancing and high availability).
The Web server instances are configured to authenticate users (via an external identity store and a single sign-on server) and then route the HTTP requests to the Oracle Fusion Middleware products and components running in the Application tier.
The Web server instances also host static Web content that does not require application logic to be delivered. Placing such content in the Web tier reduces the overhead on the application servers and eliminates unnecessary network activity.
An Application tier, consisting of two or more physical computers that are hosting a cluster of Oracle WebLogic Server Managed Servers, and the Administration Server for the domain. The Managed Servers are configured to run the various Oracle Fusion Middleware products, such as Oracle SOA Suite and Oracle Service Bus.
A Data tier, consisting of two or more physical hosts that are hosting an Oracle RAC Database.
In a typical enterprise topology, a hardware load balancer directs incoming HTTP and HTTPS requests from the Internet to the Web tier. In addition, the hardware load balancer routes specific communications between the Oracle Fusion Middleware components and applications on the application tier. The internal-only requests are also routed through the load balancer, using a unique virtual host name. For more information, see the following:
The hardware load balancer routes the following types of requests:
The hardware load balancer balances the load on the Web tier by receiving requests to a single virtual host name and then routing each request to one of the Web server instances, based on a load balancing algorithm. In this way, the load balancer ensures that no one Web server is overloaded with HTTP requests.
For more information about the purpose of specific virtual host names on the hardware load balancer, see Section 188.8.131.52, "Summary of the Typical Load Balancer Virtual Server Names."
In the reference topology, only HTTP requests are routed from the hardware load balancer to the Web tier. Secure Socket Layer (SSL) requests are terminated at the load balancer and only HTTP requests are forwarded to the Oracle HTTP Server instances. This guide does not provide instructions for SSL configuration between the load balancer and the Oracle HTTP Server instances or between the Web tier and the Application tier.
The load balancer provides high availability by ensuring that if one Web server goes down, requests will be routed to the remaining Web servers that are up and running.
Further, in a typical highly available configuration, two hardware load balancers are configured in an active-passive configuration such that, the passive load balancer acts as a hot standby and is ready to resume service in case a failure occurs in the main load balancing appliance. This is important because for many types of services and systems, the hardware load balancer becomes the unique point of access to make invocations and, as a result, becomes a single point of failure for the whole system if it is not protected.
In addition, the hardware load balancer routes specific communications between the Oracle Fusion Middleware components and applications on the application tier. The internal-only requests are also routed through the load balancer, using a unique virtual host name.
In order to balance the load on servers and to provide high availability, the hardware load balancer is configured to recognize a set of virtual server names. As shown in the diagram, the following virtual server names are recognized by the hardware load balancer in this topology:
<product>.example.com - This virtual server name is used for all incoming traffic.
Users enter this URL (
http://myapplication.example.com) to access the Oracle Fusion Middleware products and custom applications available on this server. The load balancer then routes these requests (using a load balancing algorithm) to one of the servers in the Web tier. In this way, the single virtual server name can be used to route traffic to multiple servers for load balancing and high availability of the Web servers instances.
edginternal.example.com - This virtual server name is for internal communications only.
The load balancer uses its Network Address Translation (NAT) capabilities to route any internal communication from the Application tier components that are directed to the
http://edginternal.example.com/ Intranet URL. This URL is not exposed to external customers or users on the Internet.
admin.example.com - This virtual server name is for administrators who need to access the Oracle Enterprise Manager Fusion Middleware Control and Oracle WebLogic Server Administration Console interfaces.
This URL is known only to internal administrators. It also uses the NAT capabilities of the load balancer to route administrators to the active Administration Server in the domain.
For the complete set of virtual server names you must define for your topology, see the chapter that describes the product-specific topology.
Any request on port 80 (non-SSL protocol) is redirected to port 443 (SSL protocol). Exceptions of this rule include requests from public WSDLs. For more information, see Section 6.1, "Configuring Virtual Hosts on the Hardware Load Balancer."
Shared storage is an allocation of disk space that is accessible by all of the subscribers in a network, intended for file storage and allowing simultaneous access by multiple subscribers without the need to duplicate files to their computers. Shared storage is typically delivered from a Storage Area Network (SAN) or a network attached storage server (NAS).
A Disk Volume or Share is an area of a disk which has been allocated on the SAN/NAS, which usually contains a file system. This volume is mounted onto individual host computers as necessary.
If an application uses a number of disk shares then these can be grouped together into a Project or Volume Group. Shares can then be managed on a share by share basis or collectively as part of the project. For example, if your SAN or NAS provides snapshots for backup and recovery, you can snapshot an entire project, allowing you to backup everything to do with an application in a single unit, or you can snapshot it at the individual share/volume level to provide more precise backups. This could be used as part of a backup strategy for backing up the entire Project each month, or each day, for example, for the share containing configuration information.
Shares can be mounted exclusively or shared.
If you mount a share exclusively, you are extending the local storage, meaning, it is mounted on only one host at a time and dedicated to it. This is slower than using local disk directly, but does provide the benefit of SAN/NAS backup and recovery.
Shared mounts are mounted on several hosts, all of which have the ability to write to and read from the share. If you have a shared mount where each host is trying to write to the same file at the same time you may experience issues with service.
The Web tier of the reference topology consists of two Oracle HTTP Server instances.
For more information about the Web tier, see the following sections:
A Web tier with Oracle HTTP Server is not a requirement for many of the Oracle Fusion Middleware products. You can route traffic directly from the hardware load balancer to the WLS servers in the Application Tier. However, a Web tier does provide several advantages, which is why it is recommended as part of the reference topology:
The Web tier provides DMZ public zone, which is a common requirement in security audits. If a load balancer routes directly to the WebLogic Server, requests move from the load balancer to the application tier in one single HTTP jump, which can cause security concerns.
The Web tier allows the WebLogic Server cluster membership to be reconfigured (new servers added, others removed) without having to change the Web server configuration (as long as at least some of the servers in the configured list remain alive).
Oracle HTTP Server delivers static content more efficiently and faster than WebLogic Server; it also provides FTP services, which are required for some enterprise deployments, as well as the ability to create virtual hosts and proxies via the Oracle HTTP Server configuration files.
Oracle HTTP Server provides HTTP redirection over and above what WebLogic Server provides. You can use Oracle HTTP Server as a front end against many different WebLogic Server clusters, and in some cases, control the routing via content based routing.
Oracle HTTP Server provides the ability to integrate single sign-on capabilities into your enterprise deployment. For example, you can later implement single sign-on for the enterprise deployment, using Oracle Access Manager, which is part of the Oracle Identity and Access Management family of products.
Oracle HTTP Server provides support for WebSocket connections deployed within WebLogic Server.
Some deployments, such as those on Exalogic, may use Oracle Traffic Director instead of Oracle HTTP Server.
For more information about Oracle HTTP Server, see "Introduction to Oracle HTTP Server" in Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.
Although Oracle HTTP Server provides a variety of benefits in an enterprise topology, Oracle also supports routing requests directly from the hardware load balancer to the Managed Servers in the middle tier.
This approach provide the following advantages:
Lower configuration and processing overhead than using a front-end Oracle HTTP Server Web tier front-end.
Monitoring at the application level since the load balancer can be configured to monitor specific URLS for each Managed Server (something that is not possible with OHS).
As shown in the diagram, the Oracle HTTP Server instances use the WebLogic Proxy Plug-In (
mod_wl_ohs) to proxy HTTP requests from Oracle HTTP Server to the Oracle WebLogic Server Managed Servers in the Application tier.
For more information, see "Overview of Web Server Proxy Plug-Ins 12.1.3" in Oracle Fusion Middleware Using Web Server 1.1 Plug-Ins with Oracle WebLogic Server.
The application tier consists of two physical host computers, where Oracle WebLogic Server and the Oracle Fusion Middleware products are installed and configured. The application tier computers reside in the secured zone between firewall 1 and firewall 2.
For more information, see the following sections:
Unlike the Managed Servers in the domain, the Administration Server uses an active-passive high availability configuration. This is because only one Administration Server can be running within an Oracle WebLogic Server domain.
In the topology diagrams, the Administration Server on HOST1 is in the active state and the Administration Server on HOST2 is in the passive (inactive) state.
To support the manual fail over of the Administration Server in the event of a system failure, the typical enterprise deployment topology includes:
A Virtual IP Address (VIP) for the routing of Administration Server requests
The configuration of the Administration Server domain directory on a shared storage device.
In the event of a system failure (for example a failure of HOST1), you can manually reassign the Administration Server VIP address to another host in the domain, mount the Administration Server domain directory on the new host, and then start the Administration Server on the new host.
However, unlike the Administration Server, there is no benefit to storing the Managed Servers on shared storage. In fact, there is a potential performance impact when Managed Server configuration data is not stored on the local disk of the host computer.
As a result, in the typical enterprise deployment, after you configure the Administration Server domain on shared storage, a copy of the domain configuration is placed on the local storage device of each host computer, and the Managed Servers are started from this copy of the domain configuration. You create this copy using the Oracle WebLogic Server pack and unpack utilities.
The resulting configuration consists of separate domain directories on each host: one for the Administration Server (on shared storage) and one for the Managed Servers (on local storage).
For more information about the structure of the Administration Server domain directory and the Managed Server domain directory, as well as the variables used to reference these directories, see Section 7.5.
In a typical enterprise deployment, you configure the Managed Servers in a cluster on two or more hosts in the application tier. For specific Oracle Fusion Middleware products, the enterprise deployment reference topologies demonstrate best practices for the number of Managed Servers, the number of clusters, and what services are targeted to each cluster.
These best practices take into account typical performance, maintenance, and scale-out requirements for each product. The result is the grouping of Managed Servers into an appropriate set of clusters within the domain.
Variations of the enterprise deployment topology allow the targeting of specific products or components to additional clusters or hosts for improved performance and isolation.
For another example, you can host the Administration Server on a separate and smaller host computer, which allows the FMW components and products to be isolated from the Administration Server.
These variations in the topology are supported, but the enterprise deployment reference topology uses the minimum hardware resources while keeping high availability, scalability and security in mind. You should perform the appropriate resource planning and sizing, based on the system requirements for each type of server and the load that the system needs to sustain. Based on these decisions, you must adapt the steps to install and configure these variations accordingly from the instructions presented in this guide.
In a typical Enterprise Deployment, there is one node manager per host. This node manager can start managed servers from any domain. This is the Node Manager configuration recommended for an Enterprise Deployment.
In a typical enterprise deployment, you configure a Per Domain Node Manager, and you start two Node Manager instances on the Administration Server host: one from the Administration Server domain directory and one from the Managed Servers domain directory.
Starting the Node Manager from each domain directory creates two isolated Node Manager processes that can be used independently to control each type of server. The separate Node Manager processes allow you to use different features for the Administration Server Node Manager and the Managed Servers Node Manager.
Oracle recommends the unicast communication protocol for communication between the Managed Servers and hosts within the Oracle WebLogic Server clusters in an enterprise deployment. Unlike multicast communication, unicast does not require cross-network configuration and it reduces potential network errors that can occur from multicast address conflicts as well.
When you consider using the multicast or unicast protocol for your own deployment, consider the type of network, the number of members in the cluster, and the reliability requirements for cluster membership. Also consider the following benefits of each protocol.
Uses a group leader that every server sends messages directly to. This leader is responsible for retransmitting the message to every other group member and other group leaders, if applicable.
Works out of the box in most network topologies
Requires no additional configuration, regardless of the network topology.
Uses a single missed heartbeat to remove a server from the cluster membership list.
Multicast uses a more scalable peer-to-peer model where a server sends each message directly to the network once and the network makes sure that each cluster member receives the message directly from the network.
Works out of the box in most modern environments where the cluster members are in a single subnet.
Requires additional configuration in the router(s) and WebLogic Server (i.e., Multicast TTL) if the cluster members span more than one subnet.
Uses three consecutive missed heartbeats to remove a server from the cluster membership list.
Depending on the number of servers in your cluster and on whether the cluster membership is critical for the underlying application (for example in session-replication intensive applications or clusters with intensive RMI invocations across the cluster), each model may behave better.
Consider whether your topology is going to be part of an Active-Active disaster recovery system or if the cluster is going to traverse multiple subnets. In general, unicast will behave better in those cases.
For more information see the following resources:
"Configuring Multicast Messaging for WebLogic Server Clusters" in the Oracle Fusion Middleware High Availability Guide
"One-to-Many Communication Using Unicast" in Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.
Many of the Oracle Fusion Middleware products and components require an Oracle Platform Security Services (OPSS) security store for authentication providers (an identity store), policies, credentials, keystores, and for audit data. As a result, communications must be enabled so the Application tier can send requests to and from the security providers.
When you configure an Oracle Fusion Middleware domain, the domain is configured by default to use the WebLogic Authentication provider. However, for an enterprise deployment, you must use a dedicated, centralized LDAP-compliant authentication provider.
For authorization (and the policy store), the location of the security store varies, depending up on the tier:
For the application tier, the authorization store is database-based, so frequent connections from the Oracle WebLogic Server Managed Servers to the database are required for the purpose of retrieving the required OPSS data.
For the Web tier, the authorization store is file-based, so connections to the database are not required.
For more information about OPSS security stores, see the following sections of Oracle Fusion Middleware Application Security Guide:
In the Data tier, an Oracle RAC database runs on the two hosts (DBHOST1 and DBHOST2). The database contains the schemas required by the Oracle SOA Suite components and the Oracle Platform Security Services (OPSS) policy store.
You can define multiple services for the different products and components in an enterprise deployment to isolate and prioritize throughput and performance accordingly. In this guide, one database service is used as an example. Furthermore, you can use other high availability database solutions to protect the database:
Oracle Data Guard; for more information, see the Oracle Data Guard Concepts and Administration
Oracle RAC One Node; for more information, see "Overview of Oracle RAC One Node" in the Oracle Real Application Clusters Administration and Deployment Guide
These solutions above provide protection for the database beyond the information provided in this guide, which focuses on using an Oracle RAC Database, given the scalability and availability requirements that typically apply to an enterprise deployment.
For more information about using Oracle Databases in a high availability environment, see "Database Considerations" in the Oracle Fusion Middleware High Availability Guide.