Copyright 2013 EMC Corporation. All Rights Reserved.

Transcription

1 White Paper INSTALLING AND CONFIGURING AN EMC DOCUMENTUM CONTENT TRANSFORMATION SERVICES 7.0 CLUSTER TO WORK WITH A DOCUMENTUM CONTENT SERVER 7.0 CLUSTER IN SECURE SOCKETS LAYER Abstract This white paper explains how to install and configure D7 CTS cluster against a D7 Content Server cluster setup. This paper is organized in a set of steps that needs to be followed in sequence. It also covers configuring CTS cluster to work with a Content Server cluster in SSL. October 2013

2 Copyright 2013 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. Part Number H

3 Table of Contents Executive summary... 4 Audience... 4 Abbreviations... 4 Content Transformation Server cluster set up for Load balancing and Failover... 4 Pre-requisites... 6 Setup Steps... 6 Install CTS in the first machine... 6 CONFIGURE CTS IN FIRST MACHINE... 9 INSTALL CTS IN SECOND MACHINE CONFIGURE CTS IN SECOND MACHINE Update the dfc.properties files in the CTS Cluster Basic steps to verify Changes required in both CTS nodes to support complete failover Setting up Proximity in the CS cluster Basic steps to verify complete failover Steps to configure CTS cluster to work with CS Cluster in SSL Secure Socket Layer Pre-requisites for configuring CTS cluster to work with CS cluster in SSL Steps to configure CTS cluster for CS cluster SSL CTS SSL Exception Importing CS certificates in CTS machine Conclusion References

4 Executive summary This white paper covers the following points for D7 CTS: Installing two Content transformation servers in cluster Configuring two Content transformation servers against the same logical repository Manual configuration steps for to achieve complete failover between both CS and CTS nodes Configuring CTS cluster setup to work with CS cluster in SSL Audience This white paper is intended for EMC customers, partners, internal developers and engineers. It is organized in a set of steps that are easy to follow. Whenever required, a reference to other published guide is provided in order to avoid the duplication of information Abbreviations CS Content Server CTS Content Transformation Services SSL Secure Socket Layer DA Documentum Administrator Content Transformation Server cluster set up for Load balancing and Failover Cluster consists of a set of physical or virtual machines that work together to achieve high availability and reduce down time. Load balancing is a method to distribute load evenly across multiple nodes and failover is the technique to switch over automatically when one node fails to a second node which is setup as redundant or standby. Documentum Content Transformation Server load balancing means that subsequent client requests are distributed among two or more CTS Servers in order to share the load. The order in which the requests are forwarded to CTS Servers is chosen randomly. CTS Failover addresses three situations: One of the CTS nodes of the CTS server cluster fails One of the CS nodes of the CS server cluster fails One of the CS and CTS nodes of the clusters fails 4

5 Failover of CTS means that if one CTS Server has failed, the entire rendition requests is processed by second CTS server working in parallel to first CTS server. In the current load balance setup we will provide instruction FILESTORE DATABASE for load balance and Failover simultaneously. Failover of CS means that if one Content Server has failed, all the client requests is switched to second content server and thereby the second content Transformation server which is logically configured to LOGICAL the second REPO CS server will handle the entire client requests. CTSREPO Complete Failover of both CS and CTS means that if any one of the CS nodes and CTS nodes fails simultaneously the client requests will be handled by the running CS and the rendition requests will be handled by the running CTS server. Additional manual configuration is required to achieve this in D7 CTS. CTS cluster load balance setup This document is for achieving CTS cluster load balancing & failover for single repository which is a logical repository shared by two separate CS host machines. Figure 1.1 CSONE DOCBROKER CSONE PROXIMITY TO CSONE 1 PROXIMITY TO CSTWO 2 CTSONE FIGURE 1.1 CSTWO DOCBROKER CSTWO PROXIMITY TO CSTWO 1 CTSTWO FIGURE 1.1 5

6 For load balancing we need to configure two Content Servers and two Content Transformation servers as defined in figure1.1. The two content servers are installed in Cluster and the primary and secondary content servers are called CSONE and CSTWO. Please refer to the CS cluster and failover document to install the CS in cluster The two CTS servers Primary and secondary are called CTS1 and CTS2. CTS1 and CTS2 are installed and configured against the content servers CSONE and CSTWO respectively. This document explains how CTS1 and CTS2 are installed against the same logical repository CTSrepo, which is also the global repository. After installation, CTS1 and CTS2 are then configured against the same repository using the server configuration objects CTSrepo and CSTWO_CTSRepo respectively. Prerequisites Install two D7 Content Server in cluster Install CTS DAR files before configuring CTS against the logical Repository that both the CTS servers CTS1 and CTS2 are installed and configured against 1. Rich_Media_Services_7.0_dar 2. CTSAspects_7.0_dar 3. Transformation_7.0_dar Install Ghost Script (x64), version 9.05 for Image3 and DOc3 plugins Setup Steps Install CTS in the first machine To install CTS in the first machine log in to the first CTS host machine CTS1 and run the ctswinsuitesetup.exe as an administrator user. Follow the instructions provided in the D7 Documentum CTS Installation Guide for detailed steps 6

7 Provide the host name or the ip address of the first content server host machine CSONE as below. 7

8 In the DFC Global Registry designation screen select Designate the global registry repository to use. Enter the logical repository name and password which is shared by both the Content servers CSONE and CSTWO. Select Test Connection, if desired. 8

9 CONFIGURE CTS IN FIRST MACHINE To complete the Content Transformation Services installation in the first CTS machine, configure the instance to the repository. Navigate to the Content Transformation Services Configurator located under Start -> Programs -> Documentum -> CTS Configuration Utility and click the CTS Configuration Utility Select Add a content Transformation services instance to a docbase option. Select the repository to be served by the both the Content Transformation Servers CTS1 and CTS2 9

10 INSTALL CTS IN SECOND MACHINE Follow the same steps as in installing CTS1 to install CTS2 against CSTWO. Please make a note of the changes in the following screens. While installing CTS2 against the second Content server CSTWO provide the ip or the hostname of the content server CSTWO as the Primary connection broker 10

11 In the DFC Global Registry designation screen select Designate the global registry repository to use. Enter the logical repository name and password which is shared by both the Content servers CSONE and CSTWO. Select Test Connection, if desired 11

12 CONFIGURE CTS IN SECOND MACHINE Follow the same steps as in configuring CTS1 to configure CTS2 against CSTWO. CTS2 is also configured against the same logical repository. 12

13 While configuring CTS2 against the second Content server CSTWO select the server configuration object for CSTWO Update the dfc.properties files in the CTS Cluster Select the file dfc.properties file present in C:\Documentum\config of CTS1 machine and add the host and port of the CSTWO machine as below. dfc.docbroker.host[1]=cstwo dfc.docbroker.port[1]=1489 Similarly in the dfc.properties file of the CTS2 machine add the host and port of the CSONE machine as below. dfc.docbroker.host[1]=csone dfc.docbroker.port[1]=

14 Below is the screenshot of CTS1 dfc.properties Basic steps to verify 1. CTS failover With CSONE, CSTWO and CTS1 up and running and CTS2 down, if a user logged into DA by selecting CSONE and request a rendition for a supported file format, it should be processed by CTS1. With CSONE, CSTWO and CTS2 up and running and CTS1 down, if a user logged into DA by selecting CSTWO and request a rendition for a supported file format, it should be processed by CTS2. 2. CTS Load balancing With CSONE, CSTWO,CTS1 and CTS2 up and running, if a user logged into DA by selecting any running server send multiple rendition request for supported file formats, it should be processed by both CTS1 and CTS2. 3. CS failover With CTS1, CTS2 and CSONE up and running and CSTWO down, if a user logged into DA by selecting CSONE and request a rendition for a supported file format, it should be processed by CTS1. With CTS1, CTS2 and CSTWO up and running and CSONE down, if a user logged into DA by selecting CSTWO and request a rendition for a supported file format, it should be processed by CTS2. 14

15 Changes required in both CTS nodes to support complete failover The above set up will not work if there is cross failure between both CS and CTS in the cluster as below. 1. If CSONE and CTS2 failed at the same time 2. If CSTWO and CTS1 failed at the same time CTS1 is configured to CTSREPO repository using CTSREPO config object and CTS2 is configured to CTSREPO repository using CSTWO_CTSREPO. To achieve failover in such situation a user needs to edit the following files manually in both CTS1 and CTS2 from the location %CTS%\config. 1. CTSProfileService.xml 2. CTSServerService.xml 3. SessionService.xml Once the CTS is installed and configured using the installer utility CTSServerService.xml will have two QueueProcessorContext tags for each of the repository that is configured. In this case since CTS1 is configured to CTSREPO repository alone, there are two QueueProcessorContext tag one for dm_mediaserver queue and other for dm_autorender_win31 queue. DocbaseName in both cases is CTSREPO.CTSREPO to specify that the repository CTSREPO is accessed using the server configuration CTSREPO and not CSTWO_CTSREPO. To achieve complete failover, modify the two queueprocessorcontext tags and edit the DocbaseName to have only repository name CTSREPO. This is to ensure that both CSONE and CSTWO can be accessed by CTS1 and it is not bound to any specific docbase service. Repeat the same in CTS2 machine also. 15

16 Once the CTS is installed and configured using the installer utility CTSProfileService.xml will have one ProfileManagerContext tag for each of the repository that is configured. In this case since CTS1 is configured to CTSREPO repository alone, there is only one ProfileManagerContext tag. The DocbaseName is 16

17 CTSREPO.CTSREPO to specify that the repository CTSREPO is accessed using the server configuration CTSREPO and not CSTWO_CTSREPO. To achieve complete failover, modify the ProfileManagerContext tag and edit the DocbaseName to have only repository name CTSREPO. This is to ensure that both CSONE and CSTWO can be accessed by CTS1 and it is not bound to any specific docbase service. Repeat the same in CTS2 machine also. Once the CTS is installed and configured using the installer utility SessionService.xml will have one LoginContext tag for each of the repository that is configured. In this case since CTS1 is configured to CTSREPO repository alone, there is only one LoginContext tag. The DocbaseName is CTSREPO.CTSREPO to specify that the repository CTSREPO is accessed using the server configuration CTSREPO and not CSTWO_CTSREPO. To achieve complete failover, modify the LoginContext tag and edit the DocbaseName to have only repository name CTSREPO. This is to ensure that both CSONE and CSTWO can be accessed by CTS1 and it is not bound to any specific docbase service. Repeat the same in CTS2 machine also. After making the above changes verify that on starting CTS1 and CTS2 the CTS logs (%CTS%\logs) has the below lines on startup indicating that CTS1 and CTS2 is installed and configured against CTSREPO using both the server config objects. Setting up Proximity in the CS cluster The [DOCBROKER_PROJECTION_TARGET] and [DOCBROKER_PROJECTION_TARGET_n] sections in server.ini of content server define the connection brokers to which the server sends its connection information. The proximity value is used to represent the server s physical proximity to the DocBroker. The CSONE machine will have projection target set with the host and port name, the user can add proximity values as 1 to the docbroker located on CSone host and 2 to the docbroker located on CStwo host respectively to have better control on how the repository queue will be accessed. Since CTS1 is installed and configured to CSONE (host[0] in dfc.properties points to CSone host)below proximity is ideal for CSONE [DOCBROKER_PROJECTION_TARGET] 17

18 host = CSONE port = 1489 proximity = 1 [DOCBROKER_PROJECTION_TARGET_1] host = CSTWO port = 1489 proximity = 2 Since the proximity of CSOne is lower to docbroker on CSOne host, and CTS1 has host[0] = CSOne, CTS1 will try to connect to CSOne as a first preference. In the above case if the docbroker on CSONE is not up and running, CTS would still be able to access the CTSHA docbase using docbroker on CSTWO. Since CTS2 is installed and configured to CSTWO Below proximity is ideal for CSTWO [DOCBROKER_PROJECTION_TARGET] host = CSTWO port = 1489 proximity = 1 [DOCBROKER_PROJECTION_TARGET_1] host = CSONE port = 1489 proximity = 2 We can verify the same in the docbase logs of both the CS machines. (C:\Documentum\dba\config\CTSREPO) Basic steps to verify complete failover 1. Stop CSONE and CTS2 With CSTWO and CTS1 up and running and CSONE and CTS2 down, if a user logged into DA by selecting CSTWO and request a rendition for a supported file format, it should be processed by CTS1. 2. Stop CSTWO and CTS1 With CSONE and CTS2 up and running and CSTWO and CTS1 down, if a user logged into DA by selecting CSONE and request a rendition for a supported file format, it should be processed by CTS2. 18

19 Steps to configure CTS cluster to work with CS Cluster in SSL Secure Socket Layer Servers and browsers rely on the Secure Sockets Layer (SSL) protocol to help users protect their data during transfer by creating a uniquely encrypted channel for private communications over the public Internet. Each SSL Certificate consists of a key pair as well as verified identification information. When a client points to a secured server, the server shares the public key with the client to establish an encryption method and a unique session key. The client confirms that it recognizes and trusts the issuer of the SSL Certificate. This process is known as the SSL handshake and it begins a secure session that protects message privacy and message integrity. When the user logs into DA or any client application like webtop and request a rendition the application will create a transformation request. The CS creates a queue items and appends them to the dm_mediaserver queue or dm_autorender_win31 queue based on the request. The CTS servers CTS1 and CTS2 poll the queue at regular intervals. Either CTS1 or CTS2 export the object, create the rendition and sent the new rendition back to the content server repository and updates the original object with the new rendition and its associated media properties, which are stored as attributes of the rendition in the shared repository. If the CS cluster is in SSL mode the both the CTS nodes will not be able to access the CS without the certificates installed. This results in SSL handshake exception. Pre-requisites for configuring CTS cluster to work with CS cluster in SSL Setup defined in figure1.1 (CTS cluster configured against CS cluster) Enable SSL on both the CS nodes. For enabling SSL on CS nodes please follow the white paper Distributed content SSL config troubleshooting guide. 19

20 Shared DataBase and FileStore CTSRepo Repo shared by CS1 & CS2 CS1 CS2 SSL SSL CTS1 CTS2 FIGURE

21 Steps to configure CTS cluster for CS cluster SSL 1. The user should create keystores and certificates in CSONE and CSTWO using the below commands. CSone.cer is the certificate created and installed in CSONE and CStwo.cer is the certificate created in CSTWO keytool.exe -genkey -alias acskey1 -keyalg RSA -keystore acsone.keystore keytool.exe -genkey -alias acskey2 -keyalg RSA -keystore acstwo.keystore keytool.exe -export -alias acskey1 -file acsone.cer -keystore acsone.keystore keytool.exe -export -alias acskey2 -file acstwo.cer -keystore acstwo.keystore 2. Change the acs_base_urls of the dm_acs_config objects of both the CS nodes to use https connections by using the following query. update dm_acs_config object set acs_base_url = where object_name = 'CSONEACSONE' update dm_acs_config object set acs_base_url = where object_name = 'ACSTWO_CTSRepo' CTS SSL Exception Once the above URLs are set if a user logs into DA or any WDK client by selecting ACS location and request for rendition, the user will get an SSL handshake exception in the CTS logs as CS is configured in SSL and CS certificates are not installed in any of the CTS cluster machines. Below SSL exception will be thrown and the same will be present in the CTS logs. 03:06:28,375 WARN [ Thread-48] CTSOperationsUtils - [BOCS/ACS] exportcontentfiles error - javax.net.ssl.sslhandshakeexception: sun.security.validator.validatorexception: PKIX path building failed: java.security.cert.certpathbuilderexception: Could not build a validated path. User should import CSONE and CSTWO certificates in the CTS1 and CTS 2 to resolve the above issue. 21

22 Importing CS certificates in CTS machine Import the CSONE and CSTWO certificates into each running java in CTS1 machine by using the below command through command line. In CTS1 machine, import the certificates created in CSONE and CSTWO into documentum bundled java (<Documentum>\java64, <C:\ProgramFiles\Documentum>\java) and any other external java if that is running. keytool.exe -import -noprompt -trustcacerts -alias acskey1 -file "C:\certificate\aCSone.cer" -keystore "<java>/jre/lib/security/cacerts" keytool.exe -import -noprompt -trustcacerts -alias acskey2 -file "C:\certificate\aCStwo.cer" -keystore "<java>/jre/lib/security/cacerts" It will prompt for keystore password. Give the default password for java truststore cacerts that is changeit. In CTS2 machine, import the certificates created in CSONE and CSTWO into documentum bundled java (<Documentum>\java64, <C:\ProgramFiles\Documentum>\java) and any other external java if that is running. keytool.exe -import -noprompt -trustcacerts -alias acskey1 -file "C:\certificate\aCSone.cer" -keystore "<java>/jre/lib/security/cacerts" keytool.exe -import -noprompt -trustcacerts -alias acskey2 -file "C:\certificate\aCStwo.cer" -keystore "<java>/jre/lib/security/cacerts" It will prompt for keystore password. Give the default password for java truststore cacerts that is changeit. Conclusion This white paper provided complete procedure for achieving CTS cluster and load balance. It makes the Content Transformation Server load balance setup very easy and quick to achieve and eliminate a lot of confusion. It is also useful in configuring SSL on CTS. References For CS Cluster Configuration-Guide.pdf?language=en_US For enabling SSL on CS 22