Deployment Planning Guide

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Provisioning Computers

This chapter summarizes host configuration and sizing requirements for an Oracle WebCenter deployment.

The purpose of this chapter is to assist in planning hardware provisioning for Oracle WebCenter deployment. For further assistance in provisioning hardware, contact your Oracle representative.

 

Component Host Requirements

The following table provides guidelines for provisioning host computers for Oracle WebCenter components.

Component
Host Requirements
Portal Service
Estimate hardware needs specific to anticipated load. For details, see Evaluating Hardware Requirements for the Portal.
Scaling Guide
For large deployments, install multiple Portal components and configure load balancing and failover.
For details on load balancing and failover, see the “Load Balancing” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Security Guide
For details on security, see the “Network Security” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Administrative Portal
Minimum
  • Can additionally function as a Portal component in a Web farm.
  • Can be installed on the same host as Portal component and/or Image Service.
  • If not functioning as a Portal component, can be on the same host as Automation Service.
Recommended
A dedicated CPU. Some administrative actions are CPU-intensive.
Scaling Guide
No more than one Administrative Portal should be installed.
Security Guide
The Administrative Portal can be installed in a network environment that is only accessible by the Oracle WebCenter administrator.
Image Service
Minimum
256 MB RAM
Can be installed on the same host computer as the Portal component.
Recommended
512 MB RAM
More processing power is required if you use SSL or compression.
Scaling Guide
For details on load balancing and failover, see the “Load Balancing” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Security Guide
For details on security, see the “Network Security” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Document Repository
Service
Minimum
256 MB RAM
Recommended
  • 512 MB RAM
  • Fault tolerant disk for document storage.
Scaling Guide
For details on load balancing and failover, see the “Load Balancing” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Security Guide
For details on security, see the “Network Security” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Automation
Service
Minimum
Should be on a separate host from the Portal component. If installed on the same host as the Portal, schedule all jobs to run in off-peak hours.
Recommended
  • Dual processor, 1 Ghz or greater
  • 1 GB RAM
Scaling Guide
If you anticipate intensive use of identity service and content service jobs, install multiple automation services and configure load balancing.
Because search performs document indexing and cannot be horizontally scaled, adding multiple automation services for the sole purpose of crawling content does not greatly improve system performance.
For details on load balancing and failover, see the “Load Balancing” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Security Guide
For details on security, see the “Network Security” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Search
Minimum
Small (up to 250,000 documents)
Dual CPU, 2 GB RAM
Medium (up to 500,000 documents)
Dual CPU, 4GB RAM
Two Search Partitions
Larger (more than 500,000 documents, or very high search query load)
4 or more Search Partitions with dedicated Dual CPU, 4GB RAM Servers.
Or 64-bit Solaris or AIX host (s), Dual CPU 1.3 Ghz or greater; 4-8 GB RAM, high performance I/O.
Recommended
Two or more x86 Dual CPU Servers with 3GB RAM each configured as a cluster.
64-bit Solaris or AIX host, Dual CPU 1.2 Ghz or greater; 4-8 GB RAM, high performance I/O.
Scaling Guide
CPU requirements are directly proportional to the search request throughput the component can support.
Indexing speed is proportional to the speed of an individual CPU, per Search Partition.
RAM supports internal caching done by Search. RAM requirements are proportional to the size and number of documents indexed.
Oracle WebCenter Analytics
Minimum
  • Dual processor, 1 Ghz
  • 1 GB RAM
Recommended
Install on a separate host from the Portal component.
Scaling Guide
No more than one Oracle WebCenter Analytics service should be installed.
Security Guide
Enable Unicast UDP on port 31314 for communication between Oracle WebCenter Analytics and the Portal component.
End-user access to Oracle WebCenter Analytics is gatewayed by the Portal component, so the Oracle WebCenter Analytics host computer can reside behind a DMZ firewall.
Oracle WebCenter Collaboration
Minimum
  • Dual processor, 1 Ghz
  • 1 GB RAM
Can reside on same host computer as other components that generate portlets, such as the Oracle-BEA AquaLogic Interaction Publisher, Oracle-BEA AquaLogic Interaction Studio, and Oracle WebCenter Analytics.
Recommended
Install Oracle WebCenter Collaboration on a separate host computer from other components to preclude contention for the JVM.
Scaling Guide
For details on load balancing and failover, see the “Load Balancing” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Security Guide
For details on security, see the “Network Security” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Oracle-BEA AquaLogic Interaction Publisher
Minimum
  • Dual processor, 1.2Ghz
  • 1 GB RAM
Can reside on same host computer as other components that generate portlets, such as the Oracle WebCenter Collaboration, Oracle-BEA AquaLogic Interaction Studio, and Oracle WebCenter Analytics.
Recommended
Install Oracle-BEA AquaLogic Interaction Publisher on a separate host computer from other components to preclude contention for the JVM.
Scaling Guide
No more than one Oracle-BEA AquaLogic Interaction Publisher service should be installed. If capacity is an issue, install Oracle-BEA AquaLogic Interaction Publisher on a separate host with premium hardware.
Security Guide
Important! Configure your network to block port 8083 so that end users cannot access the port directly but Oracle-BEA AquaLogic Interaction Publisher components still have access from within the firewall.
For more details on security, see the “Network Security” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Oracle-BEA AquaLogic Interaction Studio
Minimum
  • Dual processor, 1Ghz
  • 1 GB RAM
Can reside on same host computer as other components that generate portlets, such as the Oracle WebCenter Collaboration, Oracle-BEA AquaLogic Interaction Publisher, and Oracle WebCenter Analytics.
Recommended
Install Oracle-BEA AquaLogic Interaction Studio on a separate host computer from other components to preclude contention for the JVM.
Scaling Guide
No more than one Oracle-BEA AquaLogic Interaction Studio service should be installed. If capacity is an issue, install Oracle-BEA AquaLogic Interaction Studio on a separate host with premium hardware.
Security Guide
For details on security, see the “Network Security” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Oracle WebCenter Interaction API Service
Minimum
Can be on the same host as a Portal component.
Recommended
Install on its own host.
Scaling Guide
No more than one Oracle WebCenter Interaction API service should be installed.
Security Guide
You should not expose the SOAP API through the extranet. To protect it, install the Oracle WebCenter Interaction API Service on a separate host from Portal components and locate the Oracle WebCenter Interaction API Service host behind a firewall.
For details on security, see the “Network Security” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Database Server
Minimum
  • 1 CPU, 1Ghz
  • 1 GB RAM
Recommended
  • 2-8 CPU
  • 4 GB RAM
Install on separate host computer.
Scaling Guide
Database Server Load Balancing
The database server can be scaled using any database-compatible clustering technology. Currently, this means that scaling can only be provided by a larger machine. If necessary, each portal database can be placed on a separate computer and scaled separately. If running on Windows, failover of databases can be provided with Microsoft Cluster Services, and geographic load balancing and failover can be provided using SQL Server replication. However, this method is technically and administratively challenging and is not recommended unless availability requirements cannot be met otherwise.
Oracle databases can be deployed for high availability. Oracle WebCenter Interaction supports both client-side connection and server-side connection failover with Oracle RAC.
Security Guide
Install the database server behind a firewall and restrict access so that only computers that host Oracle WebCenter Interaction components can access the database server host. End users do not need access to the database server host.
Remote Server - Identity Services (IDS)
Minimum
  • Dual processor, 1Ghz
  • 1 GB memory
  • 2 GB disk space
Recommended
Install on a separate host from the Portal component.
To maximize performance, install in a network location that is in close proximity to back-end components.
Scaling Guide
Install additional Automation Services, as necessary, to accommodate a large number of IDS jobs.
Security Guide
End-user access to IDS portlets is gatewayed by the Portal component, so the IDS host computer can reside behind a DMZ firewall.
Remote Server - Content Services
Minimum
Install on a separate host from the Portal component.
Recommended
To maximize performance, install in a network location that is in close proximity to back-end data sources.
Scaling Guide
Install additional automation services, as necessary, to accommodate a large number of Content Service jobs.
Security Guide
End-user access to Content Service portlets is gatewayed by the Portal component, so the Content Service host computer can reside behind a DMZ firewall.
Remote Server - Portlets
Minimum
Can share a host with other portlets and Web services.
Recommended
Install on a separate host from the portal component.
To maximize performance, install in a network location that is in close proximity to back-end components.
Scaling Guide
In general, caching enables static portlets with minimal personalization to scale very well to any number of users. Dynamic portlets with more personalization cannot be as effectively cached and so require more processing power. If necessary, improve performance by installing dynamic portlets on hosts with premium hardware.
Remote Server Load Balancing
Remote servers can be load balanced using Parallel Portal Engine load balancing.
For details on load balancing and failover, see the “Load Balancing” section of the Oracle WebCenter Interaction Networking and Authentication Guide.
Security Guide
End-user access to portlets is gatewayed by the Portal component, so the remote server host computer for portlets can reside behind a DMZ firewall.

 

Optimization Strategies

The following table characterizes optimization strategies you might consider when you provision computer resources for your site.

Goal
Approach
Low initial hardware cost
Organizations optimizing for low initial hardware cost seek to buy the least expensive machines necessary to make the software work reliably. Given a choice between repurposing two existing single processor servers and spending $7,000 on a new multi-processor, multi-core server, they would choose the former.
Low hardware maintenance cost
Organizations optimizing for low hardware maintenance costs seek to reduce the number of machines needed to host the software. Because each additional computer incurs a minimum fixed cost in terms of administrative overhead, power consumption, space, and operating system license, these organizations would rather combine multiple Oracle WebCenter components on a single, more powerful computer than distribute those components over multiple, less expensive machines.
High availability
Organizations optimizing for high availability are willing to spend extra money and effort to ensure that the portal and other Oracle WebCenter components are available reliably to their users at all times. Such organizations typically purchase more computers and load balance them where possible, creating redundant configurations.
Low software maintenance cost
Organizations optimizing for low software maintenance cost assume that at some point in the life of the system, some part of the software will malfunction, and they seek both to lessen the chance that malfunctions will occur and lessen their impact when they do occur. Such organizations would typically purchase more individual computers to ensure that system components do not interfere with one another, and to reduce the risk that taking a computer out of the system to install new software will impact multiple system functions.
Scalability
Organizations optimizing for scalability assume that their deployments will be required to handle a large number of users. Such organizations would typically purchase extra hardware, and more expensive hardware, in order to create excess capacity in the system.
Performance
Organizations optimizing for performance seek to make their systems operate as fast as possible, especially in their ability to render pages quickly for end-users. Like organizations seeking to lower software maintenance costs, these organizations would distribute system components across a larger number of computers to ensure that each component has unrestricted access to the computing power it needs to perform its tasks the moment those tasks are called for.
Network Security
Organizations optimizing for network security seek to ensure that end-users touch only machines hosting the smallest amount of code and data. Such organizations also typically install firewalls between layers of their deployment, to ensure that if an intruder compromises one layer, the potential damage is limited. Such organizations tend to purchase more computers in order to isolate the Portal component, which end-users touch directly, from other components.

 

Evaluating Hardware Requirements for the Portal

Complete the steps in the following worksheet to evaluate hardware options.

Step
Calculation
Step 1
Estimate peak load using the following calculation:
Pages/sec = ((Power user pages/hr * #power users + Normal user pages/hr * #normal users + Infrequent user pages/hr * #infrequent users pages/hr) / (3600 sec/hr) * fraction of users who could log on who are actually connected

Note: Base your calculations on historical data for existing Web sites that serve a similar function. Use the following conventions to identify users:

  • Power users. A power user is one who routinely adds or deletes portal content.
  • Normal users. A normal user is one who routinely reads content.
  • Infrequent users. An infrequent user is one who does not routinely use the portal.
Record your estimated peak load here: ____________ pages/sec
Step 2
  • Review the benchmark charts on Portal Performance on Various Hardware Hosts.
  • Choose a configuration that supports the peak load calculation from Step 1. In general, you want to provision a number of portal components that support a total of 2 to 3 times the estimated peak load from Step 1. For example, if you estimate peak load to be 15 pages/sec, you want to provision either:
    • One (1) portal component that can support 30-45 pages/sec
    • Two (2) or three (3) portal components that each support 15 pages/sec.
  • Record the benchmark capacity here: ____________ pages/sec
  • Follow the steps described in Steps 3-10 to adjust this benchmark capacity to a real-life estimate of expected use.
Step 3
If users use My Pages more than communities, revise the number upward by approximately 5%.
Step 4
If users use the Knowledge Directory more than 20% of the time, revise the number downward by approximately 10%.
Step 5
If the deployment runs under SSL (security mode 2) on the portal component, without an SSL accelerator, subtract 10%.
Step 6
IF the deployment will use SSL to communicate to the majority of Portlets and Web Services, subtract 10%.
Step 7
If this portal also serves the administrative portal, revise the number downward by 5%.
Step 8
If you use a virus scanner on the portal, subtract 0-10%, depending on the virus scanner settings.
Step 9
If you use Tomcat as the Application Server and do not use the non-blocking Java connector (org.apache.coyote.http11.Http11NioProtocol), subtract 20%.
Step 10
If the system is deployed as a VMWare Virtual Machine, subtract 15%.
Step 11
After you have made the adjustments in Steps 3-10, does the configuration you selected in Step 2 still meet your capacity requirements?

 

Portal Performance on Various Hardware Hosts

Portal performance demonstrates the following general trends:

The performance data in the table that follows is indicative of these general trends. This table provides benchmark data for the current version of the Oracle WebCenter Interaction portal component. For each representative system, the load shown is the maximum sustainable load on the server with an average mix of page views on an uncustomized system. Various factors will influence the maximum sustainable load of individual deployments such as UI customizations, effective use of portlet caching, and different mixes of page types.

Pages per Second on Oracle WebCenter Interaction 10.3.0

It is important that the performance measurements in the following table not be compared directly with the performance data for releases earlier than Oracle WebCenter Interaction 10.3.0. A new benchmark was created for Oracle WebCenter Interaction 10.3.0 that does more work per request and serves more sophisticated content than the previous benchmarks. In addition to richer content and more data in the system, HTTP compression is enabled and approximately 25% of the portlet request occur via HTTPS. Adaptive Layout mode is enabled for the benchmark.

The page distribution in the benchmark is approximately:

The following table provides performance data for Oracle WebCenter Interaction 10.3.0.

System
System Details
Pages/Second
Xeon 2.4Ghz to 3.06Ghz, 533Mhz system bus, HyperThreading enabled (Dell PowerEdge 1750)
2 x 2.8Ghz Processors 512K L2
41
Xeon 3.2Ghz, 800Mhz system bus, HyperThreading enabled (Dell PowerEdge 1850)
2 x 3.2Ghz Processors 1M L2
67
Xeon MP 2.7Ghz, 400Mhz system bus, HyperThreading enabled (Dell PowerEdge 6650)
4 x 2.7Ghz Processor 512K L2 2M L3
67
Xeon 2.66Ghz, 1333Mhz system bus (Dell PowerEdge 1950)
4x2.66 Ghz Core 2 Xeon Dual Core
125
Opteron 2.2Ghz, 1000 MHz
2x2.2 Ghz Opteron Dual Core
105
UltraSparc IV 1.5Ghz Sun Fire V490
2 x 1.5 Ghz CPU
71
UltraSPARC-T1 1 GHz Sun Fire T1000
8 cores 32 threads 1GHz
74


  Back to Top       Previous  Next