Chapter 3   Planning the Deployment


Before installing the iPlanet Market Maker software, it is highly recommended that the implementation team define a deployment plan to ensure optimal performance of the system. The deployment plan should identify the following:

• The appropriate development setup to accommodate modifications to the iPlanet Market Maker software and testing of the software before moving it into the production environment.

• The requirements of the marketmaker organization in terms of usage, availability, and security.

• Initial hardware estimates.

• The appropriate production setup to accommodate the security and availability requirements of the marketmaker organization.

This chapter provides information to help you identify these elements.

Determining the Appropriate Development Setup

---

It is recommended that the implementation team set up one of the following to provide an environment in which to customize the iPlanet Market Maker software to meet specific requirements and test the software before porting it to the production environment:

• The basic development setup provides a platform for modifying the software and performing minimal testing after modifications are made. Typically, this setup consists of a single machine where all the components (iPlanet Market Maker software, iPlanet Web Server, LDAP database, and Oracle database) are installed.

• The advanced development setup expands on the basic development setup by adding a quality assurance function to validate expected performance on a configuration that accounts for the fact that user load will be distributed among several servers and that the database will run on separate machines. This setup consists of the following:
  • At least one server where the iPlanet Web Server and iPlanet Market Maker software are installed.

  • At least one server where the LDAP and Oracle databases are installed.

Note: The advanced development setup is recommended over the basic setup.

Identifying the Marketmaker's Requirements

---

The next step in planning the deployment is to determine the requirements of the marketmaker organization. This involves discussion of the following:

• Availability requirements in terms of how important it is for the marketplace to remain up and running.

• Security requirements in terms of the necessity for security features, such as SSL decryption.

• Expected usage of the different modules of the iPlanet Market Maker software in terms of the following:
  • Number of simultaneous users. The most common variable in determining the scalability of any e-commerce platform is the number of simultaneous users that the platform can support.

    Note: Simultaneous users are users actively running the software at one time, which is not necessarily equal to the number of users logged into the marketplace at one time.

  • Intensity of usage for different iPlanet Market Maker functions. In order to size a production setup and tune an installation for better performance, the implementation team should quantify the intensity of usage for individual functions in terms of numbers of simultaneous users. The most commonly used functions, which were included in the mixed scenarios tested in our performance test labs, include the following:
    1. Catalog: Users browsing and searching.

    2. Auction: Users bidding.

    3. RFx: Buyers creating requests and sending the requests through distribution lists and sellers creating responses.

    4. Order Management System: Buyers creating requisitions and submitting purchase orders for approval; sellers approving or rejecting purchase orders.

  • Size of the database. Although the iPlanet Market Maker software is designed to work with large databases, it is normal to expect that a substantial increase in the size of a database could have an impact on the response times of the software. However, there is only a weak relationship between the size of the database and performance of the software in terms of response times.

Deriving Initial Hardware Requirement Estimates

---

Based on the performance tests conducted using the development setup, the implementation team can work out a sizing calculator to derive an initial estimate of the size of the hardware configuration to meet the marketmaker's requirements. Please consult iPlanet Market Maker professional services for further assistance in deriving a sizing calculator.

The following table represents a typical sizing calculator.

Table 3-1    Sizing Calculator

			CPUs
Scenario	Users	Response Time	Web Server	LDAP	Oracle
Catalog Search
Community Registration
Auction
OMS
RFx
Total
Total with Load Factor (x 1.5)

In the fields provided in the second (Users) column of the sizing calculator, you enter the number of users you expect to be actively performing each of the commonly-used functions listed in the first column simultaneously. Remember that simultaneous use means that the users are actually performing the function, not just logged in to the marketplace. After entering the numbers, click the Submit button. This displays the following in the table:

• Response Time: This column gives the number of seconds it takes for the software to respond to user requests submitted in each functional module.

• CPUs: Web Server: This column provides the following hardware requirements for the web server:
  • The number of CPUs required for the web server for each functional module.

  • The total number of CPUs required for the web server for all modules.

  • The total number of CPUs required for the web server for all modules, considering a reasonable load factor.

• CPUs: LDAP: This column provides the following hardware requirements for the LDAP database:
  • The number of CPUs required for the LDAP database for each functional module.

  • The total number of CPUs required for the LDAP database for all modules.

  • The total number of CPUs required for the LDAP database for all modules, considering a reasonable load factor.

• CPUs: Oracle: This column provides the following hardware requirements for the Oracle database:
  • The number of CPUs required for the Oracle database for each functional module.

  • The total number of CPUs required for the Oracle database for all modules.

  • The total number of CPUs required for the Oracle database for all modules, considering a reasonable load factor.

From the Total with Load Factor (x 1.5) values in the table, you can derive an initial estimate of hardware requirements for the web server, directory server, and Oracle database.

Note: Formulas for the sizing calculator were derived from the version 1.0 iPlanet Market Maker software. The calculator is intended to be a rough guide; additional parameters should be considered when estimating hardware requirements.

Example 1: Auction Company

This example describes the deployment of the iPlanet Market Maker software in a company that plans to use the marketplace mostly for hosting auctions. If you enter the numbers shown below in the second (Users) column and click the submit button on the calculator, you see the numbers shown in the table.

Table 3-2    Sizing Calculator Results for Example 1

			CPUs
Scenario	Users	Response Time	Web Server	LDAP	Oracle
Catalog Search	280.0	1.085	3.08	0.112	5.8
Community Registration	20.0	17.488	0.096	0.88	0.0145
Auction	100.0	2.8	2.6	0.02	0.853
OMS	50.0	8.7	1.2	0.025	1.05
RFx	50.0	24.5	2.2	0.21	1.15
Total	500.0		9.176	1.247	8.867
Total with Load Factor (x 1.5)			13.764	1.8705	13.30

From this example, you can estimate the hardware requirements as follows:

• Web Server = 14 CPUs

• LDAP (Directory Server) = 2 CPUs

• Oracle = 14 CPUs

Example 2: RFx Company

This example describes the deployment of iPlanet Market Maker in a company that plans to use the marketplace mostly for procurement (RFx). If you enter the numbers shown below in the second (Users) column and click the submit button on the calculator, you see the numbers shown in the table.

Table 3-3    Sizing Calculator Results to Example 2

			CPUs
Scenario	Users	Response Time	Web Server	LDAP	Oracle
Catalog Search	280	1.085	3.08	0.112	5.8
Community Registration	20	17.488	0.096	0.88	0.0145
Auction	0.0	2.8	0.0	0.0	0.0
OMS	75.0	8.7	1.8	0.038	1.58
RFx	125.0	24.5	5.5	0.525	2.88
Total	500.0		10.476	1.555	10.264
Total with Load Factor (x 1.5)			15.714	2.332	15.397

From this example, you can estimate the hardware requirements as follows:

• Web Server = 16 CPUs

• LDAP (Directory Server) = 3 CPUs

• Oracle = 16 CPUs

Comparing this example with Example 1, you can see that the total number of simultaneous users is the same. But because the RFx module requires more processing power than the Auctions module, the number of CPUs required in Example 2 is greater.

Determining the Appropriate Production Setup

---

Based on the policy considerations of the marketmaker organization and levels of security and availability required, the implementation team should select from the following production setups:

• The basic production setup includes facilities for balancing the load and connecting the web servers to a single port. This provides a level of security acceptable for marketmaker organizations that have separate enterprise security mechanisms or that run the software on intranets or virtual private networks (VPNs). If the enterprise security group at a marketmaker organization is not concerned with the security of data as it travels along the wire, this setup should be sufficient.

  The basic production setup includes the following elements:

  • Several web servers (iPlanet Web Server) in which the iPlanet Market Maker software will be installed.

  • A server for the LDAP database.

  • A server for the Oracle database.

  • A layer of proxy servers for added security.

  • At least one firewall to protect the iPlanet Web Servers from the Internet.

  • A load-balancing application (for example, Resonate Central Dispatch^TM) installed on the web servers to help balance the load across the servers.

    Note: The Resonate Internet Service Management (ISM) platform is a distributed software and services solution that maximizes service levels of e-business applications, including iPlanet Market Maker Open Digital Marketplaces, to ensure optimum user satisfaction. Resonate Central Dispatch, the foundation of Resonate's ISM platform, ensures maximum service levels by automatically routing traffic to the best available resource based on customer-specified criteria, resource capacity, or resource response speed. Central Dispatch minimizes the need for immediate, constant human intervention by automating problem avoidance features to meet the 24X7 uptime requirements of business-to-business service.

    Go to www.resonate.com/alliances/iplanet/eval today to request an evaluation copy of Resonate Central Dispatch. See how Resonate Central Dispatch provides reliable availability and performance for your iPlanet Market Maker environment. Information on Resonate Internet Services Management software and services can be found on www.resonate.com.

• The production setup with SSL expands on the basic production setup by encrypting all communication sent over the Internet, ensuring that the data is secure. In addition to the elements used in the basic production setup, the production setup with SSL includes the following elements:
  • More powerful servers at the proxy layer, so that SSL decryption can be performed on the data before they reach the web servers.

  • A separate web server for static content. This reduces the encryption overhead by removing static content that is not sensitive (for example, images).

• The high-availability production setup expands on the SSL production setup by taking measures to ensure the highest levels of security and availability. In addition to the elements used in the production setup with SSL, the high-availability production setup includes elements such as the following:
  • An Oracle Parallel Server for database replication, so that the iPlanet Market Maker software can work on a replica, which can be synchronized with the master nightly. This makes sense in cases where the Oracle database is part of a larger database containing critical data.

  • Sun Cluster technologies to ensure that a hardware failure does not affect the marketplace.

    Note: This level of complexity is not necessary for the web server layer, because if one of the web servers or proxy servers goes down, the load-balancing software removes it from the loop.

  • An iPlanet Directory Server using the Directory Server Replication configuration for directory server replication and high availability.

    Note: Alternatively, you can use the iPlanet Directory Access Router implementation, which offers a complete 7X24 solution for high availability of the directory. For more details, consult your sales representative.

Note: Only the basic production setup has been tested in our performance labs. For details of the hardware configuration and parameters of the performance tests, see "Summary".

Determining the Hardware Configuration

---

The iPlanet Market Maker software consists of a set of JSPs, Java servlets, and Java classes that are deployed on an iPlanet Web Server. Consequently, when deploying the iPlanet Market Maker software, it is necessary to consider the scalability of both the iPlanet Web Server and the Oracle and LDAP databases. Additionally, it is important to achieve an optimized balance between the processing power assigned to the servers where the iPlanet Market Maker software is installed and the processing power assigned to the database servers. In all production setups, the iPlanet Market Maker software runs on servers that are separate from the database and directory servers where the data are stored.

Notes:

• The iPlanet Market Maker software was tested in the performance labs under the following conditions:
  • A catalog containing no more than 100,000 items.

  • A community containing no more than 25,000 users.

  If these values are exceeded, you need to resize your hardware configuration to achieve better performance.

• In the hardware configurations described below, we use mostly servers with four CPUs. Although you can use different machine configurations, you should consider the advantages of machine redundancy and machine similarity for load balancing and maintenance.

This section describes the hardware configurations for each of the three production setups described in "Determining the Appropriate Production Setup". Because the two examples presented in "Deriving Initial Hardware Requirement Estimates" are so similar in hardware requirements, we present only one configuration for each setup. These configurations should be acceptable for both examples.

Basic Production Setup

The basic production setup for the companies would include a firewall layer and a layer of proxy servers to isolate the servers running the application from the Internet.

The following table summarizes the hardware recommended for the basic production setup.

Table 3-4    Hardware Recommended for Basic Production Setup

Function	Machines	CPUs per machine	RAM per machine	Storage per machine
Directory Server	1 - Enterprise 450	4 - 450 MHz/4 MB UltraSparcIIs	4 GB	4 X 18 GB
Oracle	1 - Enterprise 6500	16 - 450 MHz/4 MB UltraSparcIIs	8 GB	StorEdge A1000 12 X 18 GB
Web Server	4 - Enterprise 450s (can start with 2 and phase in additional machines)	4 - 450 MHz/4 MB UltraSparcIIs	4 GB	2 X 18 GB
Proxy	4 - Ultra 60s (can start with 2 and phase in additional machines)	2 - 450 MHz/4 MB UltraSparcIIs	1 GB	2 X 18 GB

The following diagram illustrates a basic production setup for the example companies. Although the sizing calculator indicated that the web server and proxy layers would require four machines each, the diagram shows that you can start with two machines and phase in additional machines as the user load increases. When phasing in additional machines, you should always add machines to the proxy and web server layers in pairs, maintaining a 1:1 ratio between proxy servers and web servers to maintain proper fail-over.

Production Setup With SSL

The production setup with SSL for the companies would include a firewall layer, an upgraded layer of proxy servers to handle SSL decryption, and a separate web server for static content. The following table summarizes the hardware recommended for the production setup with SSL.

Table 3-5    Hardware Recommended for Production Setup with SSL

Function	Machines	CPUs per machine	RAM per machine	Storage per machine
Directory Server	1 - Enterprise 450	4 - 450 MHz/4 MB UltraSparcIIs	4 GB	4 X 18 GB
Oracle	1 - Enterprise 6500	16 - 450 MHz/4 MB UltraSparcIIs	8 GB	StorEdge A1000 12 X 18 GB
Web Server	4 - Enterprise 450s	4 - 450 MHz/4 MB UltraSparcIIs	4 GB	2 X 18 GB
Proxy	4 - Enterprise 450s	4 - 450 MHz/4 MB UltraSparcIIs	4 GB	2 X 18 GB
Static Web Server	1 - Enterprise 450	4 - 450 MHz/4 MB UltraSparcIIs	4 GB	2 X 18 GB

The following diagram illustrates a production setup with SSL for the example companies.

High-Availability Production Setup

The high-availability production setup for the companies would include a firewall layer, an upgraded layer of proxy servers to handle SSL decryption, and a separate web server for static content. The Oracle database should host a replica, and the LDAP server should be a producer-consumer configuration. The following table summarizes the hardware recommended for the high-availability production setup.

Table 3-6    Hardware Recommended for Production Setup with SSL

Function	Machines	CPUs per machine	RAM per machine	Storage per machine
Directory Server	Directory Server Replication Configuration or Directory Access Router Implementation	Please consult Professional Services for recommendations.
Oracle	Oracle Cluster	Please consult Professional Services for recommendations.
Web Server	4 - Enterprise 450s	4 - 450 MHz/4 MB UltraSparcIIs	4 GB	2 X 18 GB
Proxy	4 - Enterprise 450s	4 - 450 MHz/4 MB UltraSparcIIs	4 GB	2 X 18 GB
Static Web Server	1 - Enterprise 450	4 - 450 MHz/4 MB UltraSparcIIs	4 GB	2 X 18 GB

The following diagram illustrates a high-availability production setup for the example companies.

Summary

---

The following tables provide details of the development and production setups tested in our labs. Please note that the production setup with SSL and the high-availability production setup have not been through all our performance tests.

Table 3-7    Details of the Development Setups

	Basic Development Setup	Advanced Development Setup
Purpose	Application development and functionality validation. (Use all components running a single server.)	Application development and functionality validation. Validate performance with multiple web servers using a load-balancing configuration.
Hardware	1 - Enterprise 450	2 - Enterprise 450s for the web server 1 - Enterprise 6500 for the database
Users	50	200
Catalog Items	4,000	16,000
Community Users	1,000	8,000

Table 3-8    Details of the Production Setups

	Basic Production Setup	Production Setup With SSL	High-Availability Production Setup
Purpose	Use a firewall layer and a layer of proxy servers to secure the servers.	Use an upgraded proxy layer, so that it can also handle SSL decryption, and a separate web server for static content.	The Oracle database should host a replica, and the LDAP server should be configured for replication.
Hardware	1 - Enterprise 450 for the directory server 1 - Enterprise 6500 for the database 4 - Enterprise 450s for the web server 4 - Ultra 60s for the proxy	1 - Enterprise 450 for the directory server 1 - Enterprise 6500 for the database 4 - Enterprise 450s for the web server 4 - Enterprise 450s for the proxy 1 - Enterprise 450 for the static content	Directory Server Replication Configuration for the directory server Oracle cluster for the database 4 - Enterprise 450s for the web server 4 - Enterprise 450s for the proxy 1 - Enterprise 450 for the static content
Users	400	400	400
Catalog Items	32,000	32,000	32,000
Community Users	16,000	16,000	16,000