A Detailed Review Abstract The objective of this white paper is to present a typical enterprise deployment of the EMC Documentum 6 Web Development Kit (WDK) application. The focus will be on the WDK level, detailing how to use a hardware load balancer, a web server cluster, and an application cluster to achieve load balancing and failover. July 2008
Copyright 2008 EMC Corporation. All rights reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com All other trademarks used herein are the property of their respective owners. Part Number h5589 A Detailed Review 2
Table of Contents Executive summary...4 Introduction...4 Audience... 4 Architecture description...4 WebLogic installation...6 Application server cluster configuration...6 WDK application deployment...8 Web server configuration...8 Load-balancer configuration...9 Service configuration... 9 Content rule configuration... 10 Conclusion...11 References...11 A Detailed Review 3
Executive summary EMC Documentum Web Development Kit (WDK) is a developer toolkit based on industry standards that facilitates the development of complex web-based applications connecting to EMC Documentum Content Server and content repositories. The deployment of a web application based on WDK to a simple application server environment with a single node is straightforward and covered in the EMC Documentum Web Development Kit and Webtop Version 6 Deployment Guide. In this white paper, we will walk through a relatively complex enterprise deployment of the WDK application in order to provide better performance through load balancing and high availability through failover support. Introduction This white paper is designed to help a user facing the challenge to deploy and configure a WDK application for high performance and high availability by walking through a complex enterprise deployment involving an application server cluster, web server cluster, and hardware load balancer. One of the main objectives is to show that there is a large variety of choices for the deployment of the WDK application as far as the technology is concerned. Note that only some typical configurations are discussed in this white paper and there are many other ways to deploy a WDK-based application. Although the discussed enterprise deployment should provide better performance and high availability, this white paper is focused on how to deploy a WDK application rather than on performance tuning or on how to achieve a specific high availability. Because specific products will be used in order to provide step-by-step instructions, this white paper can only be used as a reference guide if other products are used. Audience This white paper is written for system administrators who want to deploy Documentum 6 products at the enterprise level. Architecture description Figure 1 depicts a possible enterprise deployment of Documentum 6 products. This deployment involves the following components/products: Firewalls, forward/reverse proxies Distributed content (ACS Accelerated Content Services Server, BOCS Branch Office Caching Server, DMS Documentum Messaging Server) Single sign-on using etrust Siteminder and LDAP Many documents are available for the enterprise deployment of Documentum 6 products. For example, the EMC Documentum Distributed Content Configuration Guide provides detailed instructions on how to deploy the EMC Documentum Distributed Content solution. A Detailed Review 4
Netegrity (etrust SiteMinder) App Server Cluster Forward Proxy FWSM DMZ Reverse Proxy FWSM Load Balancer Web Server Cluster 8 8 Client Client LDAP Directory LDAP Directory CS/ACS Internet/Intranet Full Full Text Text Index Index Server Server Storage DB Forward Proxy FWSM Client Client 8 VPN BOCS Reverse Proxy FWSM Storage RCS/ACS DMZ 8 BOCS Figure 1. Enterprise deployment with Documentum 6 products In this paper, we will focus on the deployment at the WDK layer and Documentum Webtop will be used. In Figure 2, we have a hardware load balancer in front of a web server cluster that is in front of an application server cluster. Figure 2. Enterprise deployment with the WDK application A Detailed Review 5
In this particular deployment, we will use a hardware load balancer (Cisco s CSS 11506) and two Solaris machines with hostnames plesys203 and plesys204. As for software, Sun Java System Web Server 7.0 and WebLogic 9.2 MP1 will be used. WebLogic installation The first step is to install WebLogic on plesys203 and plesys204. For the installation on one of the machines: At the step Choose Install Type, select Custom instead of the default Complete. At the next step Choose Components, ensure that WebLogic Server/Web Server Plug-Ins is selected as shown in Figure 3. When we configure Sun Java System Web Server, we need web server plug-ins. Figure 3. WebLogic installation For other steps, the default configuration can be used. The WebLogic 9.2 Installation Guide provides details. Application server cluster configuration For the cluster configuration, we will need the WebLogic Configuration Wizard and the WebLogic Server Administration Console. We will run the admin server on plesys203 and start the configuration from there: 1. Start the WebLogic Configuration Wizard ($BEA_HOME/weblogic92/common/bin/config.sh). 2. Select Create a new WebLogic configuration on the initial screen. A Detailed Review 6
3. Select Generate a domain configured automatically to support the following BEA products on the Select a Domain Source screen. 4. Enter User password and Confirm user password on the Configure an Administrator Username and Password screen. 5. Select Production Mode for WebLogic Domain Start Mode on the Specify the Server Start Mode and JDK screen. 6. Select Yes on the Customize Environment and Services Settings screen. 7. Retain the default settings on the Configure the Administration Server screen. 8. Add a managed server named ManagedServer_1 with Listen port 7002 on the Configure Managed Servers. 9. Add a cluster named Cluster_1 while keeping the default values for the rest on the Configure Clusters screen. 10. Assign ManagedServer_1 to Cluster_1 on the Assign Managed Servers to Clusters screen. 11. Click Next on other screens until the Review the Domain Settings screen opens. 12. Type cluster_domain for Domain name and click Create on the Review the Domain Settings screen. 13. Click Done on the last screen to complete the configuration. On plesys204, repeat these steps with the following two exceptions: At step 8, use ManagedServer_2 for the managed server. Skip steps 9 and 10. (We do not create a cluster on plesys204.) After starting the admin server on plesys203, access the WebLogic Server Administration Console at http://plesys203:7001/console. The first task with the WebLogic Server Administration Console is to configure ManagedServer_2 using the WebLogic Server Administration Console: 1. Click cluster_domain/environment/servers. 2. Click Lock & Edit. 3. Click New. 4. Type ManagedServer_2 for Server Name. 5. Type 10.8.2.37 for Server Listen Port. (10.8.2.37 is the IP address of plesys204.) 6. Select Yes, make this server a member of an existing cluster and select Cluster_1. 7. Click Finish to complete the configuration. 8. Click Activate Changes. The next task is to perform additional configuration for the cluster Cluster_1: 1. Click cluster_domain/environment/clusters. 2. Click Lock & Edit. 3. Click Cluster_1. 4. Type 10.8.2.36:7002, 10.8.2.37:7002 for Cluster Address. (10.8.2.36 is the IP address of plesys203.) 5. Click Save. A Detailed Review 7
6. Click Activate Changes. We have now completed the cluster configuration and can start the managed servers on plesys203 and plesys204. To start the managed server on plesys203, go to: $WL_HOME/user_projects/domains/cluster_domain/bin Run:./startManagedWebLogic.sh ManagedServer_1 On plesys204, we have to tell the managed server to communicate with the admin server on plesys203 and we should run:./startmanagedweblogic.sh ManagedServer_2 t3://plesys203:7001 If we go back to the WebLogic Server Administration Console, we should see that both managed servers are in RUNNING state. WDK application deployment The EMC Documentum Web Development Kit and Webtop Version 6 Deployment Guide provides most of the deployment steps. The following describes one additional step and what should be done when selecting the deployment target: In order to enable failover, we need to enable session replication with WebLogic. Before deploying the application, unpack the WAR file and modify weblogic.xml to uncomment. <session-descriptor> <session-param> <param-name>persistentstoretype</param-name> <param-value>replicated</param-value> </session-param> </session-descriptor> On the Select targets for this application screen, a step when using the WebLogic Server Administration Console to deploy the application, select Cluster_1 from the list of clusters and ensure that the All servers in the cluster option is selected. After completing the deployment of the WDK application (assuming that the application is Webtop), we should be able to access the application through either http://plesys203:7002/webtop or http://plesys204:7002/webtop. Web server configuration In order to enable load balancing or failover with a WebLogic cluster, the following three options, among others, can be used: BEA s HttpClusterServlet External web server such as Sun Java System Web Server Hardware load balancer such as Cisco s CSS 11506 In this deployment, Sun Java System Web Server 7.0 is used as external web server. Sun Java System Web Server 7.0 is to be installed and configured on both plesys203 and plesys204. For installation, consult Sun Java System Web Server 7.0 Installation and Migration Guide. In the following, we cover the configuration on plesys203 and the same procedure should be repeated on plesys204: A Detailed Review 8
1. Create a folder bea_plugin under Sun Java System Web Server 7.0 installation directory (for example, /sun/webserver7). 2. Copy libproxy.so and libproxy128.so from $WL_HOME/server/plugin/solaris/sparc to the directory created at the previous step. 3. Navigate to /sun/webserver7/https-plesys203/config. 4. Open magnus.conf and add the following lines to the beginning of the file. These lines instruct Sun Java System Web Server to load the plug-in as a module. Init fn="load-modules" funcs="wl_proxy,wl_init"\ shlib=/sun/webserver7/bea_plugin/libproxy.so Init fn="wl_init" 5. Open obj.conf and add the following lines at the end of the file. Notes: <Object name="webtop" ppath="*/webtop/*"> Service fn=wl_proxy WebLogicCluster="10.8.2.86:8001,10.8.2.87:8001" </Object> There are several ways to proxy requests: proxying requests by URL (also called proxying by path), proxying requests by MIME type, or combinations of the two. Here proxying by path is used. There are many other configuration options. For detail, consult WebLogic s documentation at http://edocs.bea.com/wls/docs92/plugins/index.html. After completing the configuration, we should now be able to access http://plesys203/webtop. With the same configuration completed on plesys204, we should be able to access http://plesys204/webtop. Note that if we use a single web server and an application server cluster, we already provide high availability at the application server layer. Depending on the requirement on high availability, it could be a satisfactory solution without adding more resource and making the configuration complex. Using a web server cluster provides high availability at the web server layer. A possible configuration is to use a hardware load balancer in front of the web server cluster. The load-balancer configuration is covered in the next section. Load-balancer configuration The load-balancer configuration is highly dependent on the load balancer used, and the detailed procedure using Cisco s CSS 11506 is described in this paper. The procedure can be used as a reference/guideline if other load balancers are used. Note: The documentation on Cisco s CSS 11506 can be found at http://www.cisco.com/en/us/products/hw/contnetw/ps792/products_installation_and_configuration_guides_list.ht ml. Contact Cisco for assistance with any of the steps involving CSS. Service configuration With Cisco s CSS, each Sun Java System Web Server instance is modeled as a service along with the following mandatory parameters: IP address and port. The following describes the steps to create a service: 1. Create a service. 2. Specify a IP address. 3. Specify a port. A Detailed Review 9
4. Activate the service. 5. Exit the service configuration. In the following example, a service named plesys203 is created. CSS(config)# service plesys203 Create service <plesys203>, [y/n]:y CSS(config-service[plesys203])# ip address 10.8.2.36 CSS(config-service[plesys203])# port 80 CSS(config-service[plesys203])# active CSS(config-service[plesys203])# exit The final configuration is as follows: service plesys203 ip address 10.8.2.86 port 80 active The same procedure should be repeated (with a different service name, IP address, and possibly different port) for the second Sun Java System Web Server instance on plesys204. Content rule configuration For each high-availability deployment, an owner along with a content rule should be created. The following describes the mandatory steps using default configuration parameters: 1. Create an owner. 2. Create a content rule. 3. Specify a VIP address. 4. Specify a port. 5. Add the first web server instance. 6. Add the second web server instance. 7. Activate content rule. In the following example, an owner named GM with a content rule named GM_LAB_TEST is created. CSS(config)# owner GM Create owner <GM>, [y/n]:y CSS(config-owner[GM])# content GM_LAB_TEST Create content < GM_LAB_TEST>, [y/n]:y CSS(config-owner-content[GM_LAB_TEST])# vip address 10.8.31.3 CSS(config-owner-content[GM_LAB_TEST])# port 80 %% Content Rule Protocol Defaulting to TCP. CSS(config-owner-content[GM_LAB_TEST])# add service plesys203 CSS(config-owner-content[GM_LAB_TEST])# add service plesys204 CSS(config-owner-content[GM_LAB_TEST])# active CSS(config-owner-content[GM_LAB_TEST])# exit CSS(config-owner[GM])# exit Now we should have an owner with the following configuration: owner GM content GM_LAB_TEST vip address 10.8.31.3 protocol tcp port 80 A Detailed Review 10
add service plesys204 add service plesys203 active In this example, the default configuration parameters are used and depending on the requirements, the configuration can be modified accordingly. For example, the load-balancing algorithm can be changed from the default (round robin) to another algorithm. However, it is out of scope of this white paper. In order to do a quick test, use a browser and access http://10.8.31.3/webtop for this particular example. The Webtop login page should be displayed. Conclusion In this white paper, prepared as a reference guide, we have gone through a relatively complex enterprise deployment and configuration of the EMC Documentum WDK application. Depending on requirements on performance and high availability, a similar configuration should be considered for deploying a WDK application. References The following can be found on Powerlink: EMC Documentum Distributed Content Configuration Guide EMC Documentum Web Development Kit and Webtop Version 6 Deployment Guide The following can be found on the respective company s websites: WebLogic 9.2 Installation Guide Sun Java System Web Server 7.0 Installation and Migration Guide Sun Java System Web Server 7.0 Administrator's Guide A Detailed Review 11