Deployment Planning

     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 AquaLogic User Interaction deployment.

The purpose of this chapter is to assist in planning hardware provisioning for AquaLogic User Interaction deployment. For further assistance in provisioning hardware, contact your BEA representative.

 

Component Host Requirements

The following table provides guidelines for provisioning host computers for AquaLogic Interaction 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 Networking and Authentication guide.
Security Guide
For details on security, see the Network Security section of the 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 AquaLogic User Interaction 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 Networking and Authentication guide.
Security Guide
For details on security, see the Network Security section of the 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 Networking and Authentication guide.
Security Guide
For details on security, see the Network Security section of the 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 Networking and Authentication guide.
Security Guide
For details on security, see the Network Security section of the 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.
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 Analytics service should be installed.
Security Guide
Enable Unicast UDP on port 31314 for communication between Analytics and the Portal component.
End-user access to Analytics is gatewayed by the Portal component, so the Analytics host computer can reside behind a DMZ firewall.
Collaboration
Minimum
  • Dual processor, 1 Ghz
  • 1 GB RAM
Can reside on same host computer as other components that generate portlets, such as the Publisher, Studio, and Analytics.
Recommended
Install 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 Networking and Authentication guide.
Security Guide
For details on security, see the Network Security section of the Networking and Authentication guide.
Publisher
Minimum
  • Dual processor, 1.2Ghz
  • 1 GB RAM
Can reside on same host computer as other components that generate portlets, such as the Collaboration, Studio, and Analytics.
Recommended
Install Publisher on a separate host computer from other components to preclude contention for the JVM.
Scaling Guide
No more than one Publisher service should be installed. If capacity is an issue, install 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 Publisher components still have access from within the firewall.
For more details on security, see the Network Security section of the Networking and Authentication guide.
Studio
Minimum
  • Dual processor, 1Ghz
  • 1 GB RAM
Can reside on same host computer as other components that generate portlets, such as the Collaboration, Publisher, and Analytics.
Recommended
Install Studio on a separate host computer from other components to preclude contention for the JVM.
Scaling Guide
No more than one Studio service should be installed. If capacity is an issue, install Studio on a separate host with premium hardware.
Security Guide
For details on security, see the Network Security section of the Networking and Authentication guide.
AquaLogic 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 AquaLogic Interaction API service should be installed.
Security Guide
You should not expose the SOAP API through the extranet. To protect it, install the AquaLogic Interaction API Service on a separate host from Portal components and locate the AquaLogic Interaction API Service host behind a firewall.
For details on security, see the Network Security section of the 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. AquaLogic 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 AquaLogic 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 backend 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 backend 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 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 ALUI 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 ALUI 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 AquaLogic 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 AquaLogic Interaction 6.5

It is important that the performance measurements in the following table not be compared directly with the performance data for releases earlier than AquaLogic Interaction 6.5. A new benchmark was created for AquaLogic Interaction 6.5 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 ALI 6.5.

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

Pages per Second on AquaLogic Interaction 6.1

The following table provides performance data for ALI 6.1. The benchmark used is different than that used in the previous section. Data from this table should not be compared to the ALI 6.5 performance data.

System
System Details
Pages/Second
Pentium III Xeon 1.4Ghz, 133 Mhz SDRAM
(Dell PowerEdge 1650)
1 x 1.4Ghz Processor 512K L2
33
2 x 1.4Ghz Processors 512K
44
Xeon 2.4Ghz to 3.06Ghz, 533Mhz system bus, HyperThreading enabled (Dell PowerEdge 1750)

Note: Mhz is less important than total processor cache for performance. Disabling HyperThreading decreases performance 12% with two CPUs and 25% with one.
1 x 2.4Ghz Processor 512K L2
56
2 x 2.4Ghz Processors 512K L2
71
1 x 2.8Ghz Processor 512K L2
58
2 x 2.8Ghz Processors 512K L2
73
1 x 3.06Ghz Processor 512K L21M L3
67
2 x 3.06Ghz Processor 512K L2 1M L3
82
Xeon 3.2Ghz, 800Mhz system bus, HyperThreading enabled (Dell PowerEdge 1850)

Note: The 800Mhz bus improves the performance of Xeon-based systems greatly. Disabling HyperThreading decreases performance by approximately 15% for dual-CPU systems and 25% for single CPU systems.
1 x 3.2Ghz Processor 1M L2
75
2 x 3.2Ghz Processors 1M L2
100
Xeon MP 2.7Ghz, 512K L2 2M L3 caches, 400Mhz system bus, HyperThreading enabled (Dell PowerEdge 6650)

Note: The 400Mhz bus of this system severely limits performance. This system is the only one with large differences in performance between .NET and Java platforms: .NET performs 25% better than the performance indicated here for the 4 processor node and performs equally well as Java for one processor.
1 x 2.7Ghz Processor 512K L2 2M L3
34
2 x 2.7Ghz Processors 512K L2 2M L3
53
4 x 2.7Ghz Processors 512K L2 2M L3
66
UltraSparc III 1.0Ghz
(Sun Fire 280R)

Note: Most Sun systems scale the memory bandwidth with each CPU, and will scale well with increased CPU count.
1 x 1Ghz CPU
27
2 x 1Ghz CPU
50
4 x 1Ghz CPU
90
Power 5 1.5Ghz
(IBM iSeries 520)

Note: Power 5 based IBM systems scale memory with each pair of CPUs, and performance will scale with CPU count as a result.
2 x 1.5Ghz CPU
70


  Back to Top       Previous  Next