| Oracle® Fusion Applications Enterprise Deployment Guide 11g Release 1 (11.1.2) Part Number E16684-04 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Enterprise Deployment Guide 11g Release 1 (11.1.2) Part Number E16684-04 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of the enterprise topology for Oracle Fusion Customer Relationship Management.
This chapter includes the following topics:
An enterprise deployment is an Oracle guidelines blueprint based on proven Oracle high-availability and security technologies and recommendations for Oracle Fusion Applications. The guidelines described in these blueprints span all Oracle products across the entire technology stack: Oracle Database, Oracle Fusion Middleware, Oracle Fusion Applications, and Fusion Middleware Control.
An Oracle Fusion Applications enterprise deployment:
considers various business Service Level Agreements (SLA) to make high-availability guidelines as widely applicable as possible
leverages database grid servers and storage grid with low-cost storage to provide highly resilient, lower cost infrastructure
uses results from extensive performance impact studies for different configurations to ensure that the high-availability architecture is optimally configured to perform and scale to business needs
enables control over the length of time to recover from an outage and the amount of acceptable data loss from a natural disaster
uses Oracle guidelines and recommended architecture, which are independent of hardware and operating systems.
Note:
This document focuses on enterprise deployments in Linux environments. Enterprise deployments can also be implemented in UNIX and Windows environments.
Oracle Fusion Applications are a unified suite of business applications designed to unify personal and enterprise processes. It unifies transactional Oracle SOA Suite and business processes, business intelligence, and collaborative technologies in a seamless user experience. Oracle Fusion Applications can be easily integrated into a service-oriented architecture and made available as software as a service.
Oracle Fusion Applications offer a strong functional value by providing:
Installed based demand (for example, unified global payroll module)
Competitive differentiation (for example, Distributed Order Orchestration)
Revenue generation (for example, sales territory management)
Oracle Fusion Applications incorporate best practice business processes, including those from Oracle E-Business Suite, PeopleSoft, Oracle On Demand, JD Edwards, and Siebel.
Oracle Fusion Applications are standards-based, making them highly adaptable. This standards-based technology allows you to respond effectively to change with flexible, modular, user-driven business software that is powered by best-in-class business capabilities built on open standards. Its technology framework includes the following products:
Oracle WebCenter provides design time and runtime tools for building enterprise portals, transactional websites, and social networking sites.
Oracle Business Intelligence 11g provides a full range of business intelligence capabilities that allow you to collect, present, and deliver organizational data.
Hyperion extends Oracle's business intelligence capabilities to offer the most comprehensive system for enterprise performance management.
Oracle Universal Content Management enables you to leverage document management, Web content management, digital asset management, and records retention functionality to build and complement your business applications.
Oracle SOA Suite provides an enterprise architecture that supports building connected enterprise applications to provide solutions to business problems.
Oracle WebLogic Server is a scalable, enterprise-ready Java Platform, Enterprise Edition (Java EE) application server.
Oracle JDeveloper is an integrated development environment with end-to-end support for modeling, developing, debugging, optimizing, and deploying Java applications and Web services.
Oracle Enterprise Manager Fusion Middleware Control offers business-driven applications management, integrated application to disk management, and integrated systems management and support experience.
Oracle Identity Management enables organizations to manage the end-to-end life cycle of user identities and to secure access to enterprise resources and assets.
For more information, see the Oracle Fusion Applications Concepts Guide.
The Oracle Fusion Applications configurations discussed in this guide are designed to ensure security of all invocations, maximize hardware resources, and provide a reliable, standards-compliant system for enterprise computing with a variety of applications.
The security and high-availability benefits of the Oracle Fusion Applications configurations are realized through isolation in firewall zones and replication of software components.
The enterprise deployment architectures are secure because every functional group of software components is isolated in its own demilitarized zone (DMZ), and all traffic is restricted by protocol and port. The following characteristics ensure security at all needed levels, as well as a high level of standards compliance:
Configure external load balancers to redirect all external communication received on port 80 to port 443.
Note:
The Oracle Technology Network (http://www.oracle.com/technology/index.html) provides a list of validated load balancers and their configuration at http://www.oracle.com/technology/products/fusionapps/ias/hi_av/Tested_LBR_FW_SSLAccel.html.
Communication from external clients does not go beyond the Load Balancing Router (LBR) level.
Components are separated in different protection zones: the Oracle Web Tier, application tier, and the data tier. Moreover, Oracle Identity Management (IDM) has its own protection zones like Oracle Web Tier, Applications tier and Data tier
No direct communication from the Load Balancing Router to the data tier is allowed.
Direct communication between two firewalls at any one time is prohibited.
If a communication begins in one firewall zone, it must end in the next firewall zone.
Oracle Internet Directory (OID) is isolated in the data tier.
All communication between components across protection zones is restricted by port and protocol, according to firewall rules.
The enterprise deployment architectures are highly available, because each component or functional group of software components is replicated on a different computer, and configured for component-level high availability.
The following terminology is used in this enterprise deployment guide:
Oracle home: An Oracle home contains installed files necessary to host a specific product. For example, the SOA Oracle home contains a directory that contains binary and library files for Oracle SOA Suite. An Oracle home resides within the directory structure of the Middleware home. Each Oracle home can be associated with multiple Oracle instances or Oracle WebLogic Server domains.
ORACLE_BASE: An alternate way of specifying the path /u01/oracle.
WebLogic Server home: A WebLogic Server home contains installed files necessary to host a WebLogic Server. The WebLogic Server home directory is a peer of Oracle home directories and resides within the directory structure of the Middleware home.
Middleware home: A Middleware home consists of the Oracle WebLogic Server home, and, optionally, one or more Oracle homes. A Middleware home can reside on a local file system or on a remote shared disk that is accessible through NFS.
Oracle instance: An Oracle instance contains one or more active middleware system components, for example Oracle Web Cache, Oracle HTTP Server or Oracle Internet Directory. You determine which components are part of an instance, either at install time or by creating and configuring an instance at a later time. An Oracle instance contains files that can be updated, such as configuration files, log files, temporary files.
Domain: The basic administrative unit of Oracle WebLogic Server.
Managed Server: Hosts business applications, application components, Web services, and their associated resources. To optimize performance, Managed Servers maintain a read-only copy of the domain's configuration document. When a Managed Server starts, it connects to the domain's Administration Server to synchronize its configuration document with the document that the Administration Server maintains.
failover: When a member of a high availability system fails unexpectedly (unplanned downtime), in order to continue offering services to its consumers, the system undergoes a failover operation. If the system is an active-passive system, the passive member is activated during the failover operation and consumers are directed to it instead of the failed member. The failover process can be performed manually, or it can be automated by setting up hardware cluster services to detect failures and move cluster resources from the failed node to the standby node. If the system is an active-active system, the failover is performed by the load balancer entity serving requests to the active members. If an active member fails, the load balancer detects the failure and automatically redirects requests for the failed member to the surviving active members. See Oracle Fusion Middleware High Availability Guide for information on active-active and active-passive systems.
failback: After a system undergoes a successful failover operation, the original failed member can be repaired over time and be re-introduced into the system as a standby member. If desired, a failback process can be initiated to activate this member and deactivate the other. This process reverts the system back to its pre-failure configuration.
hardware cluster: A hardware cluster is a collection of computers that provides a single view of network services (for example: an IP address) or application services (for example: databases, Web servers) to clients of these services. Each node in a hardware cluster is a standalone server that runs its own processes. These processes can communicate with one another to form what looks like a single system that cooperatively provides applications, system resources, and data to users.
A hardware cluster achieves high availability and scalability through the use of specialized hardware (cluster interconnect, shared storage) and software (health monitors, resource monitors). The cluster interconnect is a private link used by the hardware cluster for heartbeat information to detect node death. Due to the need for specialized hardware and software, hardware clusters are commonly provided by hardware vendors such as HP, IBM, and Dell. While the number of nodes that can be configured in a hardware cluster is vendor dependent, for the purpose of Oracle Fusion Applications high availability, only two nodes are required. Hence, this document assumes a two-node hardware cluster for high availability solutions employing a hardware cluster.
cluster agent: The software that runs on a node member of a hardware cluster that coordinates availability and performance operations with other nodes. Clusterware provides resource grouping, monitoring, and the ability to move services. A cluster agent can automate the service failover.
clusterware: Software that manages the operations of the members of a cluster as a system. It allows one to define a set of resources and services to monitor via a heartbeat mechanism between cluster members and to move these resources and services to a different member in the cluster as efficiently and transparently as possible.
shared storage: Shared storage is the storage subsystem that is accessible by all the computers in the enterprise deployment domain. Among other things, the following is located on the shared disk:
Middleware Home software
AdminServer Domain Home
Java Message Service (JMS)
Tlogs (where applicable)
Managed server homes can also be optionally located in the shared disk. The shared storage can be a Network Attached Storage (NAS), a Storage Area Network (SAN) or any other storage system that multiple nodes can access simultaneously and can read/write.
primary node: The node that is actively running an Oracle Fusion Applications instance at any given time and has been configured to have a backup/secondary node. If the primary node fails, Oracle Fusion Applications instance is failed over to the secondary node. This failover can be manual or automated using the Clusterware for Administration Server. For a server migration based scenario, WebLogic Whole Server Migration is used for automated failover.
secondary node: The node that is the backup node for an Oracle Fusion Applications instance. This is where the active instance fails over when the primary node is no longer available. See the definition for primary node in this section.
network host name: Network host name is a name assigned to an IP address either through the /etc/hosts file or through DNS resolution. This name is visible in the network that the computer to which it refers to is connected. Often, the network host name and physical host name are identical. However, each computer has only one physical host name but may have multiple network host names. Thus, a computer's network host name may not always be its physical host name.
physical host name: This guide differentiates between the terms physical host name and network host name. This guide uses physical host name to refer to the "internal name" of the current computer. On UNIX, this is the name returned by the hostname command.
Physical host name is used by Oracle Fusion Middleware to reference the local host. During installation, the installer automatically retrieves the physical host name from the current computer and stores it in the Oracle Fusion Middleware configuration metadata on disk.
physical IP: Physical IP refers to the IP address of a computer on the network. In most cases, it is normally associated with the physical host name of the computer (see the definition of the physical host name). In contrast to a virtual IP, it is always associated with the same computer when on a network.
switchover: During normal operation, active members of a system may require maintenance or upgrading. A switchover process can be initiated to allow a substitute member to take over the workload performed by the member that requires maintenance or upgrading, which undergoes planned downtime. The switchover operation ensures continued service to consumers of the system.
switchback: When a switchover operation is performed, a member of the system is deactivated for maintenance or upgrading. When the maintenance or upgrading is completed, the system can undergo a switchback operation to activate the upgraded member and bring the system back to the pre-switchover configuration.
virtual host name: Virtual host name is a network addressable host name that maps to one or more physical computers via a load balancer or a hardware cluster. For load balancers, the name "virtual server name" is used interchangeably with virtual host name in this book. A load balancer can hold a virtual host name on behalf of a set of servers, and clients communicate indirectly with the computers using the virtual host name. A virtual host name in a hardware cluster is a network host name assigned to a cluster virtual IP. Because the cluster virtual IP is not permanently attached to any particular node of a cluster, the virtual host name is not permanently attached to any particular node either.
Note:
Whenever the term "virtual host name" is used in this document, it is assumed to be associated with a virtual IP address. In cases where just the IP address is needed or used, it will be explicitly stated.
virtual IP: (Cluster virtual IP, load balancer virtual IP.) Generally, a virtual IP can be assigned to a hardware cluster or load balancer. To present a single system view of a cluster to network clients, a virtual IP serves as an entry point IP address to the group of servers which are members of the cluster. A virtual IP can be assigned to a server load balancer or a hardware cluster.
A hardware cluster uses a cluster virtual IP to present to the outside world the entry point into the cluster (it can also be set up on a standalone computer). The hardware cluster's software manages the movement of this IP address between the two physical nodes of the cluster while clients connect to this IP address without the need to know which physical node this IP address is currently active on. In a typical two-node hardware cluster configuration, each computer has its own physical IP address and physical host name, while there could be several cluster IP addresses. These cluster IP addresses float or migrate between the two nodes. The node with current ownership of a cluster IP address is active for that address.
A load balancer also uses a virtual IP as the entry point to a set of servers. These servers tend to be active at the same time. This virtual IP address is not assigned to any individual server but to the load balancer which acts as a proxy between servers and their clients.
The instructions and diagrams in this guide describe a reference enterprise deployment topology for Oracle Fusion Applications:
Figure 1-1 shows the overall Oracle Fusion Customer Relationship Management reference enterprise deployment topology, to which variations may be applied. The graphic illustrates how all components are deployed together.
In the topology, the primary node (also known as a host, and is CRMHOST1 in the diagram) is actively running the Oracle Fusion Applications instance. The secondary node (CRMHOST2) is the redundant (HA) node for the Oracle Fusion Applications instance. The primary node consists of an Administration Server and applications that have been deployed to Managed Servers. Managed Servers can be grouped together in clusters to provide scalability and high availability for applications. Together, the primary and secondary nodes form a domain.
As shown in Figure 1-1, the overall Oracle Fusion Applications reference enterprise deployment topology comprises several domains:
Oracle Fusion Customer Relationship Management Domain
Oracle Fusion Common Domain
Oracle Fusion Financials Domain
Oracle Fusion Human Capital Management Domain
Oracle Fusion Supply Chain Management Domain
Oracle Fusion Incentive Compensation Domain
Oracle Business Intelligence Domain
Figure 1-2 shows each of the domains in detail.
The scale out of these domains is described in the chapters that follow.
For information about installing the Oracle Identity Management stack for Oracle Fusion Applications, see Section 4.2, "Prerequisites for Using the Provisioning Process."
Nodes in the Oracle Web Tier are located in the demilitarized zone (DMZ) public zone. In this tier, two nodes WEBHOST1 and WEBHOST2 run Oracle HTTP Server configured with WebGate and FusionVirtualHost_domain.conf.
Through FusionVirtualHost_domain.conf, which allows requests to be proxied from Oracle HTTP Server to WebLogic Server, Oracle HTTP Server forwards the requests to WebLogic Server running in the application tier.
WebGate (which is an Oracle Access Manager component) in Oracle HTTP Server uses Oracle Access Protocol (OAP) to communicate with Oracle Access Manager running on OAMHOST1 and OAMHOST2, in the Identity Management DMZ. WebGate and Oracle Access Manager are used to perform operations such as user authentication.
The Oracle Web Tier also includes a load balancer router to handle external requests. External requests are sent to the virtual host names configured on the load balancer. The load balancer then forwards the requests to Oracle HTTP Server.
The WebGate module in Oracle HTTP Server uses Oracle Access Protocol (OAP) to communicate with Oracle Access Manager to perform operations such as querying user groups.
On the firewall protecting the Oracle Web Tier, only the HTTP ports are open: 443 for HTTPS and 80 for HTTP.
Load Balancer Requirements
This enterprise topology uses an external load balancer. This external load balancer should have the following features:
Ability to load-balance traffic to a pool of real servers through a virtual host name: Clients access services using the virtual host name (instead of using actual host names). The load balancer can then load-balance requests to the servers in the pool.
Port translation configuration should be possible so that incoming requests on the virtual host name and port are directed to a different port on the back-end servers.
Monitoring of ports on the servers in the pool to determine availability of a service.
Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:
The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for Oracle HTTP Server in the Oracle Web Tier, the load balancer needs to be configured with a virtual server and ports for HTTP and HTTPS traffic.
The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.
Ability to detect node failures and immediately stop routing traffic to the failed node.
Fault-tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.
It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the back-end services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client computer.
Sticky routing capability: Ability to maintain sticky connections to components. Examples of this include cookie-based persistence, IP-based persistence, and so on.
The load balancer should be able to terminate SSL requests at the load balancer and forward traffic to the back-end real servers using the equivalent non-SSL protocol (for example, HTTPS to HTTP). Typically, this feature is called SSL acceleration and it is required for this enterprise deployment.
Nodes in the application tier are located in the DMZ secure zone.
CRMHOST1 and CRMHOST2 run all the managed servers in the Oracle Fusion Customer Relationship Management, Oracle Business Intelligence, Oracle Incentive Compensation, Oracle Fusion Financials, Oracle Fusion Supply Chain Management, and Oracle Fusion Human Capital Management domains.
CRMHOST1 and CRMHOST2 run the managed and C/C++ servers from different domains in an active-active or active-passive implementation. C/C++ components are managed by Oracle Process Manager and Notification Server (OPMN), and all the managed servers are managed by Administration Server within the domain.
CRMHOST1 and CRMHOST2 also run the Oracle WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control, but in an active-passive configuration. You also can fail over the Administration Server manually. Alternatively, you can configure the Oracle WebLogic Server Administration Console with CFC/CRS to fail over automatically on a separate hardware cluster.
Oracle Web Services Manager (Oracle WSM) provides a policy framework to manage and secure Web services in the enterprise deployment topology. WSM Policy Manager also runs in active-active configuration in every Fusion domain where Web Services are hosted.
On the firewall protecting the application tier, the HTTP ports, OAP port, and proxy port are open. The OAP port is for the WebGate module running in Oracle HTTP Server in the Oracle Web Tier to communicate with Oracle Access Manager. Applications requiring external HTTP access use Oracle HTTP Server as the proxy. (The proxy on the Oracle HTTP Server must be enabled to allow this access.)
Nodes in the data tier are located in the most secured network zone (the intranet).
In this tier, an Oracle RAC database runs on the nodes FUSIONDBHOST1 and FUSIONDBHOST2. The database contains the schemas needed by the Oracle Fusion Applications components. The components running in the application tier access this database.
On the firewall protecting the data tier, the database listener port (typically, 1521) is required to be open. The LDAP ports (typically, 389 and 636) are also required to be open for the traffic accessing the LDAP storage in the IDM enterprise deployment.
This section provides recommended hardware for the Oracle Fusion Applications reference enterprise deployment topology on Linux operating systems.
The recommended hardware for the Oracle Fusion Applications reference enterprise deployment topology consists of six 96 GB Intel Westmere, six dual-core CPU servers (excluding Oracle HTTP Server and Oracle Database servers). Table 1-1 describes the typical hardware requirements.
Table 1-1 Example Hardware Requirements - 200 Concurrent Users
| Server | Processor | Memory | TMP | SWAP |
|---|---|---|---|---|
|
|
6 core 2 CPU Westmere |
96 GB |
default |
default |
|
|
6 core 2 CPU Westmere |
96 GB |
default |
default |
|
|
2 core 2 CPU |
4 GB |
default |
default |
|
|
2 core 2 CPU |
4 GB |
default |
default |
|
|
4 core 4 CPU |
48 GB |
default |
default |
|
|
4 core 4 CPU |
48 GB |
default |
default |
The Oracle Identity Management stack for Oracle Fusion Applications should already be installed prior to starting a deployment. Note, however, that the provisioning process described in Chapter 4, "Using the Provisioning Process to Install Components for an Enterprise Deployment," cannot proceed without it. Follow the instructions in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management to install and configure these components.
Oracle recommends the following approach when implementing the Oracle Fusion Applications topology outlined in Section 1.5, "Reference Enterprise Deployment Topology":
Using the Provisioning Process to Install Components for an Enterprise Deployment
Scaling Out the Oracle Fusion Customer Relationship Management Domain
Scaling Out the Oracle Fusion Human Capital Management Domain
Scaling Out the Oracle Fusion Supply Chain Management Domain
Additional Configuration Procedures for Scaling Out Oracle SOA Suite Server
Oracle recommends this modular approach in order to facilitate the verification of individual components one by one. This building block approach simplifies the troubleshooting during the setup process and facilitates the configuration in smaller steps.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
