IBM BS029ML, WebSphere Portal V6 Self Help Manual

Download

Front cover

IBM WebSphere Portal V6 Self Help Guide

Key recommendations for optimal configuration and use

Problem avoidance, determination, and resolution

Best practices for security and maintenance

Philip Monson

Fang Feng

Jerry Dancy

Shadi Albouyeh

Chakravarthy Kunapareddy

Stephanie Martin

James Roca

John Chambers

ibm.com/redbooks

Redpaper

International Technical Support Organization

IBM WebSphere Portal V6 Self Help Guide

January 2008

REDP-4339-00

Note: Before using this information and the product it supports, read the information in “Notices” on page vii.

First Edition (January 2008)

This edition applies to IBM WebSphere Portal Version 6.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

The team that wrote this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x

Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Purpose of this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 IBM WebSphere Portal Server overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 What is new in WebSphere Portal Version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Administration improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Structure of the Redpaper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 2. Architecture and planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Building the right Portal architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Addressing functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.2 Addressing integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.3 Technology choices for connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.4 The System Context Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.5 Addressing non-functional requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.6 Frequently asked questions about sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 The building blocks of an architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1 Logical Deployment Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.2 Node characterization at the specification level . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Operational architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.1 Adopting a tiered architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.2 Addressing scaleability and high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4 Portal deployment considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4.1 In-situ maintenance procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4.2 Two sets of production environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.3 The dual cluster with two lines of production architecture. . . . . . . . . . . . . . . . . . . 29

2.4.4 Moving a configuration between environments. . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.5 Architecting for performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.5.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.5.2 Guidance regarding vertical and horizontal scaling . . . . . . . . . . . . . . . . . . . . . . . 31

2.5.3 WebSphere queuing mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.5.4 Choosing a platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.5.5 Separation of WCM from Portal Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.5.6 Separation of Web servers and WebSphere Portal Servers. . . . . . . . . . . . . . . . . 34

2.5.7 JVM recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.5.8 Portlet application JVM considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.5.9 High availability and HTTPSession failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.6.1 WebSphere Portal Server security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.6.2 Using External Security Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.6.3 Single Sign-On (SSO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.6.4 Trust Association with WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.6.5 LTPA token generation with WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.6.6 Other Tivoli Access Manager considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.6.7 LDAP Directory Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.7 Database considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.7.1 WebSphere Portal Server database disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.7.2 Database domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.7.3 Distinct databases or distinct schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.7.4 Database high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.8 Portal planning recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.8.1 Recommendations for a successful implementation. . . . . . . . . . . . . . . . . . . . . . . 51

Chapter 3. WebSphere Portal installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.1.1 How do I prepare my system for installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.1.2 What is about to happen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.1.3 Where do I begin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.1.4 Is it working . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.2 Database transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.2.1 Planning and considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.2.2 How do I prepare for the database transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.2.3 What is about to happen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.2.4 Is it working . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.3 Enable security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.3.1 Planning and considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.3.2 How do I prepare for WebSphere Portal Server LDAP security . . . . . . . . . . . . . . 74

3.3.3 What is about to happen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

3.3.4 Is it working . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.4 Problem determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.4.1 Installation problem determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.4.2 Database transfer problem determination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

3.4.3 LDAP security problem determination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Chapter 4. WebSphere Portal security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.1 Planning and considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.1.1 The basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.1.2 WebSphere Member Manager (WMM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.1.3 User registry and member repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.1.4 Single sign-on (SSO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.1.5 WebSphere Portal login process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.1.6 Portal Access Control (PAC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

4.1.7 Secure communications over SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.1.8 Integration with Tivoli Access Manager and WebSEAL . . . . . . . . . . . . . . . . . . . . 96

4.2 Security configurations and customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4.2.1 The default security configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4.2.2 Reconfigure security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.2.3 Change user IDs and passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.2.4 Adding application specific attributes to users and groups . . . . . . . . . . . . . . . . . . 99

4.2.5 Integration with Tivoli Access Manager (TAM) . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.3 Problem determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.3.1 General problem determination recommendations. . . . . . . . . . . . . . . . . . . . . . . 102

4.3.2 Typical portal traces for different security scenarios . . . . . . . . . . . . . . . . . . . . . . 105

4.3.3 Tools for troubleshooting security problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

4.3.4 Anatomy of configuration files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

iv IBM WebSphere Portal V6 Self Help Guide

4.3.5 Reading portal runtime logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.3.6 Typical security configuration problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Chapter 5. WebSphere Portal runtime and services . . . . . . . . . . . . . . . . . . . . . . . . . . 137

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

5.1.1 Portal runtime architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

5.1.2 Portal foundation and framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

5.1.3 Portal Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

5.2 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

5.2.1 Knowing where to start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

5.2.2 Tuning advice for the IBM Java Virtual Machine. . . . . . . . . . . . . . . . . . . . . . . . . 143

5.2.3 Tuning advice for the SUN Microsystems Java Virtual Machine (JVM) . . . . . . . 145

5.2.4 WebSphere resource pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

5.2.5 Web container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

5.2.6 Data source tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

5.2.7 WebSphere security tuning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

5.2.8 WebSphere session management tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

5.2.9 WebSphere Member Manager tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

5.2.10 Portal configuration services tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

5.3 Problem determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

5.3.1 Identify the failing component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

5.3.2 JVM problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

5.3.3 Some common problems and workarounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

5.4 Portal administration tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

5.5 Runtime monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

5.5.1 What to monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

5.5.2 Useful resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Appendix A. Using IBM tools to find solutions and promote customer self-help . . 169

IBM Support Assistant (ISA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

How does ISA help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

How do I obtain, install, and access ISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Use case examples - Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Use case examples - Product Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Use case examples - Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Use case examples - Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

IBM support site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

How does the support site help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

How can I access the support site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

IBM online communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

How do online communities help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

How can I access the online communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

IBM RSS feeds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

How do RSS feeds help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

How can I access the IBM RSS feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

IBM Support Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

How does the IBM Support Toolbar help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

How can I obtain the IBM Support Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Contents v

IBM Education Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

How does the IBM Education Assistant help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

How can I access the IBM Education Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

IBM Guided Activity Assistant (IGAA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

How does the IBM Guided Activity Assistant help . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

How can I access the IBM Guided Activity Assistant (IGAA) . . . . . . . . . . . . . . . . . . . . 205

Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Appendix B. Maintenance: Fix strategy, backup strategy, and migration strategy. . 207

Backup strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Overview of the backup process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Our approach to backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Some additional best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Fix strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Overview of the maintenance strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Our approach to maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Overview of the fix strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Our approach to fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Some additional best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Migration strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

What is about to happen: a simple overview of the migration process . . . . . . . . . . . . . 219

Where do you start: planning and considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Is it working: verify the migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

When a problem occurs: troubleshooting techniques to help identify the problem . . . . 221

Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Post migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

How to find a solution: using IBM Self-Help tools and support . . . . . . . . . . . . . . . . . . . 223

What is next: typical next steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

vi IBM WebSphere Portal V6 Self Help Guide

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION

PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.

Trademarks

The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

AIX 5L™ AIX® Cloudscape™ developerWorks® Domino® DB2® Electronic Service Agent™ HACMP™ i5/OS®

IBM® Lotus® OS/390® Passport Advantage® pSeries® Rational® Redbooks® Redbooks (logo) ® RDN™

System i5™ System x™ System z™ Tivoli® WebSphere® Workplace™ Workplace Web Content

Management™

z/OS®

The following terms are trademarks of other companies:

Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation and/or its affiliates.

Enterprise JavaBeans, EJB, Java, JavaBeans, JavaScript, JDBC, JMX, JNI, JSP, JVM, J2EE, Solaris, Sun, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Active Directory, Internet Explorer, Microsoft, SQL Server, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

viii IBM WebSphere Portal V6 Self Help Guide

Preface

This IBM® Redpaper focuses on considerations for the optimal configuration and use of IBM WebSphere® Portal Server. We provide you with the information you need to deploy and manage your WebSphere Portal infrastructure, with the goal of problem avoidance. However, if issues occur, the reader is introduced to the various tools and techniques for problem determination and problem solving, including obtaining and installing fixes, how to contact support, and what type of information you should provide before engagement.

This guide is a must have resource for IT architects and administrators throughout the life cycle of a WebSphere Portal environment, from conception and planning to use and maintenance

The team that wrote this Redpaper

This Redpaper was produced by a team of specialists from around the world working at the International Technical Support Organization, Cambridge, MA.Center.

Philip Monson is a Project Leader at the ITSO Lotus® Center in Cambridge MA. Phil has been with Lotus / IBM for 17 years, joining the company when the early versions of Notes were rolled out for internal use only. He has served in management, technical, and consulting roles in the IT, Sales, and Development organizations.

Fang Feng is an Advisory Software Engineer in the IBM Software Group. He joined the WebSphere Portal Level 2 support team in Research Triangle Park, North Carolina, in 2002. His areas of expertise include Portal security, system administration, WebSphere Member Manager, and XMLaccess. He has been working with IBM for 11 years. He holds a Doctor of Philosophy in Computer Science from Texas A&M University.

Jerry Dancy is a Senior IT Specialist who works as a Technical Lead for the WebSphere Portal Server Level 2 Support team. He has five years of experience in WebSphere Portal Server support and previously worked as an Oracle® DBA for four years. He holds a degree in Accounting and CIS from Appalachian State University. His areas of expertise include installation, upgrading, configuration, and clustering of WebSphere Portal. He also has worked on and has led many projects to improve WebSphere Portal Server serviceability. He has written extensively on WebSphere Portal Server installation, configuration, and clustering. Jerry is also an author of the IBM Redbooks® publications WebSphere Portal V5.0

Production Deployment and Operations Guide, SG24-6391 and WebSphere Portal Version 6 Enterprise Scale Deployment Best Practices, SG24-7387.

Shadi Albouyeh is an experienced WebSphere Portal Software Engineer. She has been working in WebSphere Portal support for over four years since graduating with a B.S degree in Computer Science from North Carolina State University (Raleigh). She is currently the Team Lead of the Portal-Install L2 support team and has previously worked on the WebSphere Portal-API L2 support team. She focuses now on the WebSphere Portal Installation and Configuration aspect of the product, supporting customers with installation and configuration, clustering, enabling security, database transfer, Fix Pack installs, and upgrades.

Chakravarthy Kunapareddy is a Senior technical consultant and an IBM certified professional working with Ascendant Technology (http://www.atech.com), a premier IBM Business Partner. He has over six years of consulting experience with the IBM suite of products of WebSphere Portal, WebSphere Application Server, Tivoli® Access Manager, DB2®, and WebContent Management. He is an experienced infrastructure consultant with expertise in planning, architecture, installation, configuration, deployment, and troubleshooting. He holds a Bachelors Degree in Computer Science and Engineering from Bharathidasan University, India.

Stephanie Martin is a Systems Integration Professional in IBM Integrated Technology Division. Since joining IBM in 2001, she has worked in the IBM Early Deployment Center (EDC), designing and implementing beta, proof of concept, and enterprise scale solutions of Lotus software offerings. She currently acts as the EDC's Infrastructure and Administration lead for the award-winning IBM Workplace™ for Customer Support Portal.

James Roca is a Senior Consulting IT Architect with the IBM Software Group. He has spent the last two and a half years assigned to the Asia Pacific region to build and promote technical skills, and to champion leading edge Portal architectures. Previously, James worked at the IBM China Software Development Lab and the IBM Hursley Development Lab, in the capacity of IT Architect and Solution Consultant. He jointly developed the Portal Perform guide for the IBM EMEA geography. He is also credited with developing the Portal Build & Validate method, which, when adopted, minimizes implementation failure. Most recently, James took over as the Leader at Large of the IBM Worldwide Portal Community. James previously co-authored the WebSphere V3.5 Handbook, SG24-6161 and IBM WebSphere V4.0 Advanced Edition Security, SG24-6520.

John Chambers is a Knowledge Engineer for IBM WebSphere Portal support in the US. He has been supporting WebSphere Portal for more than six years and is currently focusing on improving the quality of support content, self-help information, and tools available to customers. John has been with IBM support for 12 years, since receiving his degree in Geology from Guilford College in North Carolina.

Thanks to the following people for their contributions to this project:

Thomas Hurek, WebSphere Portal Chief Programmer Fix Packs and Architectural Lead L3, IBM Software Group

William Trotman, WebSphere Portal L2 Support, IBM Software Group

Lauren Wendel, Product Manager - WebSphere Portal, IBM Software Group

Flemming T Christensen, Technical Quality Champion - Lotus, IBM Software Group

Walter Haenel, Portal Architect for Deployment and Operations, IBM Software Group

Yen Li Yong, IBM Software Services, IBM Software Group, IBM Malaysia.

Brett Gordon, WebSphere Portal L2 Support, IBM Software Group

Become a published author

Join us for a two- to six-week residency program! Help write a book dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You will have the opportunity to team with IBM technical professionals, Business Partners, and Clients.

x IBM WebSphere Portal V6 Self Help Guide

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you will develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at:

ibm.com/redbooks/residencies.html

Comments welcome

Your comments are important to us!

We want our papers to be as helpful as possible. Send us your comments about this paper or other IBM Redbooks publications in one of the following ways:

򐂰 Use the online Contact us review form found at:

ibm.com/redbooks

򐂰 Send your comments in an e-mail to:

redbooks@us.ibm.com

򐂰 Mail your comments to:

IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400

Preface xi

xii IBM WebSphere Portal V6 Self Help Guide

Chapter 1. Introduction

This chapter provides you with an overview of this Redpaper, highlights some of the new features in IBM WebSphere Portal Version 6, and provides a general description of what will be covered in each chapter.

1.1 Purpose of this Redpaper

The WebSphere Portal Self Help Guide focuses on the who, what, where, when, and why of a WebSphere Portal Server Version 6 deployment. The goal of this guide is to introduce and explain the various scenarios that you should consider before, during, and after the installation of WebSphere Portal Server. Our mission as authors is to arm you with the conceptual information that you need to deploy and manage your portal infrastructure, with the goal of problem avoidance. We do recognize that even in the best of circumstances problems can occur, so we also introduce you to various tools and techniques for problem determination and problem solving, including obtaining and installing fixes, how to contact support, and what type of information you should provide before engagement.

For the purposes of this Redpaper, our concentration is focused on the underlying framework that composes the WebSphere Portal Server core (that is, access control, integration, administration, and presentation). Our goal is to assist you in answering such questions as:

򐂰 What tools can I use to obtain sizing estimates for my portal environment?

򐂰 When/Why should I convert my portal server(s) from Cloudscape™ to an external

database?

򐂰 What can I do to optimize the runtime in my portal environment?

򐂰 How do I convert my portal server(s) from a test LDAP to a production LDAP?

򐂰 Why are dual lines of production important in a portal cluster?

For customers looking to leverage the additional services and features that WebSphere Portal offers, we do provide information about recommended supplemental materials that help make up WebSphere Portal’s portfolio, such as WebSphere Content Management, Portal Document Manager, and Personalization, among others.

For customers who are looking to install and configure a enterprise deployment of WebSphere Portal Server Version 6, refer to the IBM Redbooks publication, WebSphere Portal Version 6 Enterprise Scale Deployment Best Practices, SG24-7387.

For existing customers looking for a step-by-step guide to migrate their WebSphere Portal Server environment from Version 5.1 to Version 6, we encourage you to read the Redpaper IBM WebSphere Portal V6: Best Practices for Migrating from V5.1, REDP-4227.

This Redpaper is oriented toward Portal Administrators and IT Architects at all levels of administration and architectural design. A working knowledge of J2EE™ Architecture and WebSphere Application Server administration, as well as a basic understanding of Java™ programming concepts, are assumed.

2 IBM WebSphere Portal V6 Self Help Guide

1.2 IBM WebSphere Portal Server overview

Figure 1-1 shows an overview of IBM accelerators for WebSphere Portal.

Figure 1-1 IBM Accelerators for WebSphere Portal

IBM WebSphere Portal Version 6 is an enterprise portal solution with the complete portal services that are necessary to deliver a single point of personalized interaction to applications, content, business processes, and people for a unified user experience. WebSphere Portal improves overall productivity and customer satisfaction. WebSphere Portal provides for improved operational efficiency and productivity, as well as accelerated application and content deployment, by integrating some of the best technology that IBM has to offer. WebSphere Portal is a responsive and reliable portal platform, with a wealth of solutions available to address the needs of your On Demand Business, all from a recognized leader in the enterprise portal market.

Chapter 1. Introduction 3

1.3 What is new in WebSphere Portal Version 6

Figure 1-2 shows an example of a business portal solution.

Figure 1-2 Example of business portal solution

IBM WebSphere Portal Version 6.0 delivers new features, functions, and performance that helps to improve the efficiency of your organization, the speed of your application deployment, and the utilization of your IT assets.

Some of the new features in Version 6 include:

򐂰 A new user interface featuring AJAX and drag and drop customizations to help portal

users accomplish more with fewer clicks.

򐂰 Portal Applications can be enhanced with orchestrated flow and electronic forms services

that allow employees, partners, and customers to execute transactions faster.

򐂰 Application templating and easier portlet development accelerates application deployment

and customization through the innovative use of services-oriented architecture (SOA).

򐂰 Inline content editing and powerful personalization help increase employee productivity

and customer satisfaction.

򐂰 Intuitive administration tools and performance improvements deliver responsiveness and

reliability at lower cost.

򐂰 A set of add-on business-ready packages or “accelerators” that support a quicker ROI and

shorter implementation for specific business problems.

򐂰 Improved operational efficiency and productivity by linking the right people, process, and

information so transactions are executed quickly and accurately.

򐂰 Accelerated application and content deployment through new tools and the innovative use

of services oriented architecture (SOA).

򐂰 Lower overall cost of portal deployment with faster performance and easier administration.

4 IBM WebSphere Portal V6 Self Help Guide

򐂰 Responsiveness and reliability, delivered by a leader in the enterprise portal market.

1.4 Administration improvements

There are a number of enhancements and new features in Version 6 that are central to administration. Some of the highlights include:

򐂰 Portal configuration management integrated with WebSphere Application Server

configuration management for easier operation of clustered portal installation, less manual steps, and reduced risk for failure.

򐂰 Attribute Based Administration: Provides the option Use Personalization Rules to show or

hide pages and portlets based on user attributes. Visibility Rules allows administrators the option to display Web content based on any type of information, including LDAP attributes, time of day, or session information.

򐂰 Multiple LDAP support: Realms can now be pointed to one user registry or multiple user

registries, reducing the need for investing and implementing a directory consolidation solution.

򐂰 Data Domains: Portal now allows the separation of portal data into multiple domains.

Domains can be shared across multiple independent lines of production, aligning with the 24/7 requirements of an enterprise scale deployment.

򐂰 Web Content Management Clustering: Multiple nodes can share the same repository

(JCR), providing a single point of administration for multiple WCM servers.

򐂰 Policies: Simple management by assigning policies to control the behavior of a resource.

򐂰 Domino® and Extended products: Configuration of Domino and Extended Products and

portlets is now automated by the Domino-Portal Integration Wizard, saving manual steps for the administrator.

򐂰 WebSphere Process Server support for most platforms: As of WebSphere Process Server

Version 6.0.2, remote connectivity through the process server client can now be done from WebSphere Portal Server; also, single server installations of process portal can now be federated and clustered.

Chapter 1. Introduction 5

1.5 Structure of the Redpaper

Figure 1-3 gives an overview of the structure of this Redpaper.

Planning

and

Architecture

Maintenance

Installation

and

Configuration

Self Help

Tools and Additional

Resources

Performance

and

Runtime

Figure 1-3 Structure of this guide

This section describes how the Redpaper was constructed and provides a summary of the information that is contained within the chapters.

Regardless of the complexity of your deployment, the greatest factor in how successful a customer solution will be is how well it is planned. In Chapter 2, “Architecture and planning” on page 9, we provide a roadmap discuss the planning and design of your WebSphere Portal environment. Project Managers, Business Sponsors, Software Developers, and other key stakeholders in your organization are strongly encouraged to review the material covered here.

Security

Chapter 3, “WebSphere Portal installation” on page 55” covers the installation and configuration of WebSphere Portal Server using the flexible deployment options for the most common topologies.

WebSphere Portal Server provides a number of mechanisms to help keep your assets protected. In Chapter 4, “WebSphere Portal security” on page 85, we discuss the different components in WebSphere Portal that provide the security features and how they can be integrated into your infrastructure to provide a secure solution.

A Web portal is an integrated solution that requires the collaboration of many teams to implement. Any low-peforming part of the integrated solution can cause overall portal performance degradation. In Chapter 5, “WebSphere Portal runtime and services” on page 137”, we discuss how topology, application design, back- and front-end resources, and other factors can greatly impact the user experience and provide information about monitoring tools that can help to prevent bottlenecks.

6 IBM WebSphere Portal V6 Self Help Guide

Functional challenges, can affect even the best thought out and executed deployments. In Appendix A, “Using IBM tools to find solutions and promote customer self-help” on page 169, we discuss the usage of the various support tools to enable customers to self- recover from operational challenges more quickly.

Appendix B, “Maintenance: Fix strategy, backup strategy, and migration strategy” on page 207 is broken up into three parts: maintenance, backup, and migration. For the maintenance portion, we show you how staying current with the latest maintenance releases to leverage the included fixes to preventively fixes issues, and when to switch to later releases to introduce additional features. Performing regular backups is the surest way to protect your systems and critical data from loss due to hardware/software failure. The information and guidelines presented in Appendix B, “Maintenance: Fix strategy, backup strategy, and migration strategy” on page 207 on backup strategy are provided to help you to understand your backup software and hardware options, and encourage you to perform system backups regularly. Finally, in the Migration section, we briefly discuss the migration path for WebSphere Portal Server Version 5.1 customers looking to migrate to WebSphere Portal Server Version 6 and the tools and resources available to help you in planning and implementation.

Chapter 1. Introduction 7

8 IBM WebSphere Portal V6 Self Help Guide

Chapter 2. Architecture and planning

IBM understands and recognizes that many customers need to make important decisions about their WebSphere Portal Server solution, both prior to and during a deployment.

With intimate knowledge of the challenges and pitfalls that go hand in hand with managing many large scale WebSphere Portal deployments, this chapter sets out to provide the reader with an informed approach to planning, architecting, and implementing a successful Portal deployment.

Although this chapter is written with a bias towards enterprise scale WebSphere Portal Server deployments, the principles nevertheless remain applicable to smaller deployments.

2.1 Building the right Portal architecture

WebSphere Portal Server architectures come in many shapes and forms. This is in part attributed to the demands of modern day e-business, where the need to establish a robust, open, scalable, and strategic infrastructure platform to set the standard for system reuse and interoperability exists. WebSphere Portal Server achieves all of these goals through the establishment of an extensible framework of services, and then, by being deployed as an Enterprise Application on top of either WebSphere Application Server or WebSphere Process Server (certain restrictions apply).

Leveraging upon the strengths of the underlying WebSphere technology make it possible for WebSphere Portal Server to support everything from the small workgroup (WebSphere Portal Express) to the high-volume enterprise, to the geographically distributed Portal. Indeed, IBM recognizes that “one size does not fit all” when it comes to planning and architecting a Portal solution.

To the experienced Portal Solution team, functional and operation aspects need to be considered with equal rigor and importance when implementing a successful Portal solution.

It is acknowledged that the principles of good architectural design and development go hand in hand with the adoption of a suitable methodology. Indeed, the IBM Global Services Method (GS-Method or GSM) has been the basis for many successful WebSphere Portal Server deployments. However, the merits and application of such methodologies are beyond the scope of this particular Redpaper.

2.1.1 Addressing functionality

Functionality remains the main driving force behind many of the systems and solutions that we use each day. Without functionality, a system or solution fast becomes obsolete. Portals are no exception to this rule.

Although no specific functional requirements are documented within this chapter, as attempting to do so would prove futile given the uniqueness of many WebSphere Portal Server deployments, one can dramatically improve the success factor of a deployment by accurately capturing conditions such as the following:

򐂰 What the specific applications, services, or products are that a WebSphere Portal Server

implementation should support.

򐂰 What the high level capabilities are that an implementation should have, for example,

security, user collaboration, user interface, and so on.

򐂰 What the general use cases are that best describe the business functionality required from

the implementation.

2.1.2 Addressing integration

Integration is not a trivial issue and requires time and effort to accurately establish the most appropriate solution. A good WebSphere Portal Server architecture, therefore, addresses integration as early on in a project as possible.

WebSphere Portal Server integration can be loosely classified into the following three categories.

10 IBM WebSphere Portal V6 Self Help Guide

Presentation Integration

This integration approach represents the simplest method of incorporating content into a WebSphere Portal Server deployment and is based solely upon the ability to screen scrape, either through the deployment of an iFrame or Web Clipping Portlet, existing visual content served by one or more back-end servers. This approach, however, has the severe drawback that content cannot be personalized or manipulated in any shape or form. Furthermore, in terms of overall performance, presentation integration does not normally sit well with enterprise scale deployments due to the lack of any type of brokerage or connection pooling mechanism for reducing the amount of back-end requests. For example, a Portal page containing two iFrame portlets will result in two separate back-end calls for a single Portal page request. This is irrespective of whether the content is served by the same back-end server or not.

Application or Programmatic Integration

At a high-level, Application or Programmatic Integration provides for the very dexterity that Presentation Integration does not. Furthermore, because Application or Programmatic Integration lets you represent information in whatever shape or form is most appropriate to your target audience, it is the perfect solution for most implementations. The key to achieving this is the ability to dictate, through a custom coding effort, what happens to the actual data of a request. This extends to both the presentation and business logic aspects of an application, for which the Model-View-Controller (MVC) pattern is arguably the most well known programming concept. One drawback with this integration approach is the amount of effort required to create such custom developed components. This can be particularly challenging when an organization’s core business is other than software development. Indeed, most organizations can no longer afford the time or the cost of development to write new applications each time their business requirements change. Instead, they prefer to purchase Commercial-Off-The-Shelf (COTS) portlets or to use wizard driven development, as found in IBM Rational® Application Developer and IBM Portlet Factory.

Middleware Integration

In a subtle distinction from Application or Programmatic Integration, Middleware Integration commonly involves the deployment of an intermediary. Such an intermediary may perform queuing, routing, transformation, workflow, or even business choreography. In addition, an intermediary maybe used to attain a specific QoS (Quality of Service) or to provide a layer of abstraction between participants in an implementation. Middleware can also be used to bridge the gap between different technologies, standards, and even vendors.

2.1.3 Technology choices for connectivity

When considering the various types of integration applicable to a WebSphere Portal Server deployment, it is also often helpful to understand which type of connectivity best suits the actual approach. It is also worth remembering that non-technical factors, such as available skill set and standards within an organization, may influence the choice of a particular type of connectivity.

Web Services

Web Services are based on an open-standards way of defining and invoking a service. The implementation of the requestor and provider are hidden from each other, allowing portability in implementation. The coupling is based on the service interface and a variety of transport protocols can be used. Both synchronous and asynchronous communication is possible, but each service defines the mode it supports. The basic stack is comprised of HTTP, XML, SOAP, WSDL, UDDI, and WSFL. Web Services can employ XML as an encoding schema that is widely adopted. They are relatively “heavy” to implement, and are best suited to

Chapter 2. Architecture and planning 11

inter-enterprise communication, or adopted as an enterprise wide standard for leveraging an ESB, for example. Web services are not built to be high performing, so are not suitable for transactions that require very large throughput.

Messaging

Messaging interfaces such as WebSphere MQ and JMS are based on the asynchronous exchange of messages between producers and consumers. Point-to-Point and Publish-Subscribe communication patterns are provided. Messages are placed on a queue by the sending application, and those messages are then consumed by a receiving application. With messaging, you take advantage of a simple and common API. You adopt industry-standard programming models and you make these available on a selection of operating systems. Messaging provides assured delivery for business critical information. Messaging provides asynchronous (as well as synchronous) processing for loose coupling of applications and control of the rate at which information is processed.

Adapters

Adapters provide access to business logic in a tightly coupled manner. An adapter is specific to a particular Enterprise Information System (EIS) and generally requires client code to be written to parse the proprietary format of the data provided by the EIS. However, this tight coupling allows an adapter to map security, transaction information, and other Quality of Service information between the client and the EIS based on the well-established capabilities of EIS gateways. While adapters typically provide a synchronous interface, the latest specifications define an asynchronous mode as well, and some adapters implement this mode.

Table 2-1 gives you some comparisons between the connectivity types.

Table 2-1 Connectivity comparisons

Web Services Messaging Adapters

Interface Coupling Tight. No. An application may

process a variety of messages.

Transport Coupling Loose. Tight. Tight.

Implementation Portability

Security Standards defined -

Transaction Support Standards defined -

Synchronous Invocation

Asynchronous Invocation

Event Driven Ye s . Ye s . E I S - s p e c i f i c .

Ye s . Ye s . N o .

Vendor-specific. EIS-specific. Not universally implemented.

Limited in scope to Not universally implemented.

Yes. Custom

Ye s . Ye s . E I S - s p e c i f i c .

queue entry point.

implementation.

Tight.

Ye s .

No.

Reliable Payload Delivery

12 IBM WebSphere Portal V6 Self Help Guide

Standard Defined. Yes. EIS-specific -

Functionality provided by actual adapters.

The following recommendations are made with regards to the selection of the most appropriate connectivity technology:

򐂰 Use Web Services when portability or interface standardization is a prime concern.

򐂰 Use Messaging when high QoS constraints and loose coupling or asynchronous

invocation is needed.

򐂰 Use JCA when high QoS constraints and synchronous invocation are needed.

2.1.4 The System Context Diagram

If there is one diagram that can simplistically represent a WebSphere Portal Server implementation, or for that matter any other generic software implementation, then it is the System Context Diagram, as shown in Figure 2-1.

Authenticated

Users

Anonymous

Users

Administrators

Content Authors

Content

Developers

….

Figure 2-1 System Context Diagram

Portal

Implementation

PDM

WCM

TAM

System A

System B

….

Figure 2-1 illustrates the various system components and most significant roles of the system. Besides that, it helps to identify in high level terms the systems to which a deployment interfaces. Table 2-2 further explains the various system components and roles.

Table 2-2 System Context Diagram

System Component / Roles Description

Anonymous Users An Anonymous User has access to the limited external Portal

Authenticated Users An Authenticated User is a user that has logged into the Portal

pages, but never signs into the Portal. Anonymous users can become authenticated users by logging in.

during their current user session.

Chapter 2. Architecture and planning 13

System Component / Roles Description

Administrators Administrators are responsible for the management of the

Portal. They are responsible for adding new portlets, new pages, new administrative users, and so on.

Content Developers Content Developers are responsible for creating Web Content

Management (WCM) design artifacts, such as site frameworks, and authoring and presentation templates.

Content Authors Content Authors are a subset of Authenticated Users that are

delegated the responsibility of creating WCM content.

Content Approver Content Approvers are a subset of Authenticated Users that are

delegated the responsibility of approving WCM content. Such users approve or reject content prior to releasing the content for delivery.

PDM Portal Document Manager (PDM) is a subcomponent of

WebSphere Portal Server responsible for archiving and managing documents.

WCM Web Content Management (WCM) is a subcomponent of

WebSphere Portal Server responsible for the complete life cycle of Web content information.

TAM Tivoli Access Manager (TAM) is an External Security Manager

responsible for providing enterprise wide security.

System A System A is responsible for function X.

System B System B is responsible for function Y.

2.1.5 Addressing non-functional requirements

Capturing the non-functional requirements is a preliminary task that not only provides a starting point for selecting and sizing the physical components of a Portal solution, but also establishes such key aspects as availability, backup and recovery, disaster recovery, and systems management. In terms of the former aspects, a resulting sizing estimate is normally calculated based on those non-functional requirements giving an approximation of the physical resources required to support the proposed implementation. Of course, many factors influence the selection of the physical resources and actual experiences will vary from that of the sizing estimate for many reasons; the degree of variability can range from the small to the very significant. For those latter aspects, which by no means are exhaustive, the required solution characteristics and capabilities take shape and drive the selection of the hardware and software technologies needed to deliver the proposed implementation, within the constraints of technology, skills, and budget.

Unfortunately, the non-functional requirements of a solution also tend to be treated as "second-class citizens" because they do not add any new or improved functionality. Thus, they typically do not receive the proper attention of executives, the project manager, or even the technical team. However, a project must address the likes of availability and performance in all phases of a project life cycle to be successful.

For those customers finding themselves in the unfortunate situation of having selected and purchased “bare metal: systems, without having undertaken a thorough non-functional requirements study, the degree of usefulness attributed to fully capturing the non-functional requirements at a later stage is somewhat limited. There remain a number of key objectives that the implementation should strive to meet.

14 IBM WebSphere Portal V6 Self Help Guide

The following non-functional requirements are documented to articulate the critical elements of a successful implementation:

򐂰 Availability

򐂰 Backup and Recovery

򐂰 Capacity Estimates and Planning

򐂰 Disaster Recovery

򐂰 Extensibility/Flexibility

򐂰 Failure Management

򐂰 Performance

򐂰 Scalability

򐂰 Security

򐂰 Service Level Agreements

򐂰 Standards

򐂰 System Management

򐂰 Usability

Tip: A non-functional requirement is not well specified if it is not specific or measurable. Attainability and measurability are checks that should be performed against each requirement. A requirement should only be included if it is attainable and realizable.

2.1.6 Frequently asked questions about sizing

The most frequently asked questions in terms of non-functional requirements are typically those regarding sizing or capacity planning. For example, given a specific Portal deployment and an anticipated traffic load, what kind of configuration will satisfy the sizing requirements? For example, Customer X has an initial registered user base of 20,000 potential users. This figure is however envisaged to rise to 40,000 users in two years time and potentially to an upper bound of around 60,000 registered users after that. Therefore, the need to architect a platform that can scale to accommodate the growth forecasted for the next two to five years exists.

It is important to understand that the definition of the registered user base does not actually impact the number of users or clients concurrently accessing the solution. Rather, the registered user base is just the user population that may access the solution at any given point in time. Internally, WebSphere Portal Server maintains a database entry for all registered users after their initial login. No constraint, other than the size of the database table and the size of the selected LDAP user repository, should impede the growth of the registered user base. A more meaningful metric when sizing any WebSphere Portal Server solution is the anticipated number of concurrent users or clients. Typically, such values for the number of concurrent clients are calculated as a percentage of the registered user base.

For example, based on the current metrics supplied by Customer X for their existing Web deployment, this figure averages at about 2,500 unique user sessions per hour. This would imply that only 12.5% of the current registered user base actually interacts with the current solution. By the same calculation, the number of concurrent clients would increase to 5,000 for the projected growth in the registered user base to 40,000. This assumes that the percentage of clients using the Portal remains stable at 12.5%. However, careful consideration needs to be taken into account, as this figure may increase once more applications and functions are brought online within the Portal solution. As such, for Customer

Chapter 2. Architecture and planning 15

X, the actual anticipated estimated rises to 7,500 concurrent clients after two years time, which then increases the percentage to 18.75%.

Normally, it is common for business requirements to state that a Portal should be able to handle X number of clients concurrently.

It is important to distinguish between concurrent clients and concurrent active clients; as such, terminology is often misinterpreted between different parties. Concurrent active clients have both an active connection to the HTTP server as well as at least one thread of execution running in the application server. At any point in time, many of the clients connected to the Portal are not active; they may be thinking, reading, or even drinking coffee. These are considered as inactive concurrent clients, or more generically as concurrent clients. Based on our experience, a good starting point is to assume that for every single concurrent active client there are approximately 10 concurrent inactive clients (1:10). Theoretically, therefore, an application server capable of supporting 100 active clients will support approximately 1000 concurrent clients (active + inactive).

This assumption breaks down somewhat when the characteristics of WebSphere Portal Server shift away from that of being a traditional Web-based solution. For example, a Portal performing more back-end work will effectively shift the assumed work pattern from that of being a traditional Web-based solution to that of an On-Line Transaction Processing (OLTP) solution. Such an OLTP solution will place greater demands on system resources, with a reduced supporting ratio of approximately 1:5 or less.

A further point of debate between different parties is the understanding of Peak Load or Arrival Rate. It is important to recognize that it may be necessary to plan for such situations when many users simultaneously access the Portal solution at the same time. This generally breaks any rule of thumb for concurrency and is indicative of such situations as logins, each morning between 8am and 9am, or campaign launches. Under such circumstances, is it only possible to honor each request by

Planning for the Peak.

Attention: A sizing estimate should only ever be used as an approximation of the hardware resources required to support the proposed implementation. Actual experiences may vary from the sizing estimate for many reasons. The degree of variability can range from small to very significant. As such, there is no substitute for not undertaking a full capacity planning and performance tuning exercise. Failing to implement this critical part of any project plan is planning to fail.

2.2 The building blocks of an architecture

When faced with the challenge of architecting a WebSphere Portal Server implementation, it is often useful to take a high-level approach to first define the logical components that comprise the very architecture that is about to be designed.

For the experienced IT Architect and Portal Practitioner, this commonly embraces two aspects of design; the component model and the operational model. Component models are typically focused on identifying the components, their responsibilities, and characteristics required to deliver the solution requirements. At a conceptual level, the component model documents the technical architecture at a very high level and does so in a technology agnostic manner. At a specification level, the component model documents the required specifications and corresponding realization of all components, which ultimately will be placed on the operational model, together with a description of their interfaces, dependencies and collaborations. In common terminology, the component model addresses the logical

16 IBM WebSphere Portal V6 Self Help Guide

aspects of a solution architecture. By contrast, the operational model provides the description and configuration of the hardware and software technologies needed to deliver the required solution characteristics and capabilities, within the constraints of technology, skills, and budget. It describes the distribution of the solution components onto geographically distributed nodes, together with the connections necessary to achieve the solution functional and non-functional requirements.

Typically, the development of both the component and operational models follow various recognized paths using standard techniques or approaches. However, with the advent of Commercially-Off-The-Shelf (COTS) packages, such as WebSphere Portal Server, the demands on the IT Architect and Portal Practitioner have been reduced. Nevertheless, our experience tells that making mistakes during the architectural phase of an implemention can lead to major consequences later on in a project. As such, it is strongly recommended that IBM is engaged during this crucial period of any implementation, if not at any other time during a project.

2.2.1 Logical Deployment Units

The following Deployment Units are considered in regards to a WebSphere Portal Server architecture. The list, however, is by no means exhaustive and provides only a starting point in recognizing the primary Commercially-Off-The-Shelf (COTS) packages associated with such an architecture.

Internet Browser

The Internet Browser component is a standard Web browser, such as Internet Explorer® or Mozilla Firefox. This component communicates with the solution through the HTTP / HTTPS protocol, receives responses in HTML format, and renders them for the user. The Internet Browser has general characteristics that include Graphical Presentation, HTML, Applet Execution within a Java Virtual Machine (JVM™), JavaScript™ Execution, Plug-In Support, Caching, Security and encryption Services, and Content Persistence (cookies).

Tivoli WebSEAL (Optional)

Tivoli WebSEAL is a high-performance, multi-threaded Web Proxy server that applies fine-grained security policy to the Tivoli Access Manager protected Web object space. WebSEAL can provide single sign-on solutions and incorporate back-end Web application server resources into its security policy. WebSEAL normally acts as a reverse Web proxy by receiving HTTP/HTTPS requests from a Web browser and delivering content from its own Web server or from junctioned back-end Web application servers. Requests passing through WebSEAL are evaluated by the Tivoli Access Manager authorization service to determine whether the user is authorized to access the requested resource.

Tivoli Access Manager Policy Server (Optional)

The Tivoli Access Manager Policy Server for e-business is an authorization and management solution that scales across the entire enterprise. A robust and secure policy management tool for e-business and distributed applications, it addresses the challenges of escalating security costs, growing complexity, and the need for uniform security policies across platforms. Tivoli Access Manager unites core security technologies around common security policies to help reduce implementation time and management complexity, thereby lowering the total cost of security-enhanced computing.

Chapter 2. Architecture and planning 17

HTTP Server

The HTTP Server provides the front end to the solution. It allows for greater concurrency and resource off loading from the Portal Server tier, by serving static content (HTML pages, for example) and dynamic content (JSP™ fragments) by way of WebSphere plug-in caching capability. With the Network Deployment configuration, the plug-in provides load balancing among Portal Server cluster members.

WebSphere Application Server

WebSphere Application Server is a Web application server that provides J2EE services for the WebSphere Portal environment. It executes the Java portlets, JavaBeans™, Java Server Pages (JSP) files, and Enterprise JavaBeans™ (EJBs) that are used by WebSphere Portal. In conjunction with two other products in the WebSphere Application Server family of interoperable products (WebSphere Business Integration Server Foundation and WebSphere Application Server Network Deployment), this component is the platform on which WebSphere Portal runs.

WebSphere Portal Server

WebSphere Portal Server is a J2EE application that runs on WebSphere Application Server. Its main function is to serve the WebSphere Portal Server framework to the desktops and mobile devices of portal users. WebSphere Portal Server creates an environment that provides the connectivity, administration, and presentation services that are required. WebSphere Portal Server V6.0.1 includes several new functions and enhancements that make it easier to design, administer, and use.

Web Content Management Server (Subcomponent)

The Web Content Management subcomponent of WebSphere Portal Server empowers a knowledgeable workforce by providing an environment that allows them to create, edit, and publish Web content. Because knowledge owners have less dependence on technical resources, they can publish content in a more timely and efficient way by using the Web Content Management component. It is often helpful to think of a WCM server as a stand-alone component due to performance issues. However, licensing restrictions should be checked.

WebSphere Member Manager (Subcomponent)

WebSphere Member Manager is the subcomponent of WebSphere Portal Server responsible for accessing the user registries for user and group management and authentication. The user registries may be LDAP servers, a Custom User Registry, or the Member Manager database user registry.

WebSphere Process Server (Optional)

WebSphere Process Server (WPS) is a business process integration server that is built on top of the WebSphere Application Server. It is built to support solutions created based on service-oriented architecture (SOA). WPS provides services that enable traditional business integration such as enterprise application integration; it also provides services that enable business process automation, such as choreographing business processes as well as human workflows, and management of those business processes. WPS uses the Service Component Architecture programming model and Service Data Object (SDO) data model. SDO business objects can be defined, transformed, routed, and mapped using SCA components. The connectivity to back-end Enterprise Information Systems (EIS) is provided by the resource adapters. In the outbound mode, WPS uses adapter to send data to the EIS system from the integration application. In inbound mode, WPS uses adapters to trigger the integration application by the event occurring in the EIS system. For example, an adapter can be deployed on WPS to synchronize product information across multiple enterprise

18 IBM WebSphere Portal V6 Self Help Guide

information systems. A modification of the product information on one EIS triggers a business application that processes the data and propagates it to the other enterprise information systems.

LDAP Directory Server

A directory is often described as a database, but it is in fact a specialized database that has unique characteristics that set it apart from that of general purpose relational databases. One special characteristic of directories is that they are accessed (read or searched) much more often than they are updated (written). Hundreds of people might look up an individual's phone number, or thousands of print clients might look up the characteristics of a particular printer, but the phone number or printer characteristics rarely ever change.

Database Server

The Database Server's function is to provide persistent data storage and retrieval in support of the user-to-business transactional interaction. The data stored is relevant to the specific business interaction, for example, bank balance, insurance information, current purchase by the user, and so on.

Portlet applications

Portlets are a central part of WebSphere Portal Server. Portlets are small Portal applications that are independently developed, deployed, managed, and displayed. Portlets have multiple states and view modes, plus event and messaging capabilities. Portlets run inside the Portlet container of WebSphere Portal Server, similar to the way a servlet runs on a WebSphere Application Server. The Portlet container provides a runtime environment where Portlets are instantiated, used, and finally destroyed. Portlets rely on the WebSphere Portal Server infrastructure to access user profile information, participate in window and action events, communicate with other Portlets, access remote content, look up credentials, and store persistent data.

J2EE Enterprise Applications

An Enterprise Application is a J2EE deployment unit that bundles together Web Applications, EJBs, and Resource Adaptors into a single deployable unit.

Chapter 2. Architecture and planning 19

2.2.2 Node characterization at the specification level

It is strongly advised that the specification level attributes for each node in a contending WebSphere Portal Server architecture are clearly defined and documented. As such, each node should be described in terms of the functional and non-functional requirements and how those requirements are met. Table 2-3 gives an overview of node specifications.

Table 2-3 Node specification

Specification Level Node

Attributes

Example: System x™

Presentation Deployment Units

Execution Deployment Units

Data Deployment Units

Environments Example: Production - Based on 100% of the required NFR capacity.

Hardware Example: pSeries®.

Operating System

Non-Functional Requirements

Availability Example: Minimum of two physical nodes, one in each data center, configured

Capacity Example: Each node should be able to handle 50% of the required capacity.

This section identifies and describes the major DUs (Deployment Units) associated with a node. A DU is considered as a single unit for placement considerations. Furthermore, it is often important to distinguish between the placement of presentation, execution, and data DUs.

Example: J2EE artifacts, such as .ear files and .jar files, may be considered as Data DUs, while WebSphere Application Server remains an Execution DU.

It is important to recognize that multiple DUs may be grouped together on the same node, where practical.

Example: AIX® 5L™ V5.3.0.0-0.3.

as a single active-active cluster across both data centers.

However, as this component is part of the shared common network infrastructure core, the total consolidated capacity must be capable of delivering a guaranteed Quality of Service.

Scalability Example: Implied horizontal scalability through the addition of extra physical

Disaster Recovery and Resilience

System Management

20 IBM WebSphere Portal V6 Self Help Guide

nodes in each data center. Implied vertical scalability for Java based components, hardware resources permitting.

Example: In the case of the failure of one physical node, the others will continue to function with a reduction in total capacity. In the case of the failure of a software component on one of the physical nodes, the other collocated software components will continue to function. Depending on the type of failure the recovery characteristics will be different. For example, the failover from a network connection failure has different fail-over characteristics from that of a WebSphere Portal Server cluster member JVM crash.

Example: Integration of system event monitoring with client X’s enterprise monitoring infrastructure.

2.3 Operational architectures

Increasingly, WebSphere Portal Server customers are interested in deploying a Portal in a business critical environment. However, such a requirement raises the question about how best to address such needs in terms of selecting the most appropriate operational architecture. Fundamentally, these are all aspects that should be defined under the non-functional requirements of a solution. For example, availability requirements should be captured and agreed upon, as early on in a project as possible, as they dictate the high-availability and recovery aspects that an architecture must meet.

The purpose of this section, therefore, is to take a look at how a business critical deployment can be accomplished using today's WebSphere Portal Server V6.0.1 product, and the advantages and disadvantages of each architectural design. It should be noted that regardless of the operational architecture chosen, that there are also a number of high-availability considerations regarding the associated database backup/replication, maintenance procedures, etc. which must be considered in developing a complete operational solution for a WebSphere Portal Server deployment.

2.3.1 Adopting a tiered architecture

A common architectural principle is that of adopting a tiered or segregrated topology. This well practiced approach is in keeping with the J2EE mandate that prescribes the separation of applications into client, presentation, business, and enterprise system tiers. The approach is, however, most beneficial in terms of overall enterprise security and performance optimization.

As such, it is strongly suggested that a n-tier approach is adopted as the topology of choice for all high-volume WebSphere Portal Server deployments. This is regardless of the selected platform. Differentiating between the functional components of the solution allows each physical server to be specifically sized to the task in hand. For example, placing the Web server on a separate physical machine from the WebSphere Portal Server allows each machine to run with different OS characteristics. The same holds true for other server types, such as database servers.

2.3.2 Addressing scaleability and high availability

A major concern with any architecture is the ability to address the needs of scalability and redundancy. Furthermore, it is important to recognize that the operational aspects of just such an architecture, such as availability, also influence the overall design of a solution.

The ability to scale WebSphere Portal Server V6.0.x, or any other WebSphere Application Server for that matter, is essentially achieved by clustering. Clustering allows requests to be Workload Managed (WLM'ed) between a number of cloned copies of the concerned application. In addition, when architected correctly, clustering addresses redundancy and fault tolerance.

The most important factors of a mission-critical production environment are redundancy and fault tolerance, ensuring that there is no single point of failure in an architecture. The most important aspect of fault tolerance is to have at least two of members or replicas of each component. These can either be in a primary-to-backup formation or a peer-to-peer configuration. This thought can even be extended to the data center itself.

Chapter 2. Architecture and planning 21

There are several approaches for clustering a WebSphere Portal Server Version 6.0.1 implementation. The following section outlines each in detail.

The single clustered architecture

In a standard WebSphere Portal Server V6.0.x clustered architecture, two or more separate WebSphere Portal Server nodes are clustered together to form a single WebSphere Portal Server instance. In turn, each node is capable of supporting multiple vertical cluster members to better leverage the available system resources and to achieve the demands of scaleability. High Availability is thus accomplished not only through the vertical clustering of WebSphere Portal Server, but also by way of horizontal clustering of WebSphere Portal Server to safeguard against the outage of an actual physical node, and the replication of the database and LDAP directory servers, respectively.

As such an architecture utilizes the same user customization, community, and release data throughout an environment, any user customization made against one Portal cluster member by a user would then be available to the same user, as and when that user accesses any of the other cluster members participating in the same Portal cluster. It is acknowledged that under normal conditions, session affinity is maintained against the same Portal cluster member until such time that a user terminates his or her session, or the Portal cluster member becomes unavailable, either through a deliberate or an unscheduled outage.

In isolation, this architecture should be considered the V6.0.x architecture of choice.

However, maintaining continuous operation during periods of scheduled or unscheduled maintenance requires careful consideration. As this implementation does not typically include any redundant hardware, either in the form of a fully redundant production environment or a "double duty" staging environment, maintenance requiring an uninterrupted level of service (also referred to as 24x7 availability) must be performed as a multi-step process.

As such, this involves disabling the automatic file synchronization service from the WebSphere Deployment Manager administrative admin console and then stopping the node agent on each of the nodes participating in the cluster. Maintenance is then performed on each node in turn, starting with the primary node, by first gracefully quiescing user requests from each node by modifying the WebSphere Web server plug-in load balancing weighting (when multiple cluster members exist on the same node, all must be stopped at the same time) while the remaining node or nodes in the cluster continue to honor user requests. The final step is to synchronize and restart all of the nodes one at a time, not forgetting to re-enable the automatic file synchronization service.

While this approach represents a distinct improvement over the 24x7 maintenance procedures applicable to previous versions of WebSphere Portal Server, the complexities of performing maintenance and maintaining an uninterrupted level of service arguably remain high risk for many organizations. As such, the decision to implement this approach rests with the comfort factor of each particular organization.

de facto WebSphere Portal Server

Figure 2-2 on page 23 illustrates the system topology needed for a WebSphere Portal Server V6.0.x single clustered architecture.

22 IBM WebSphere Portal V6 Self Help Guide

Firewall

Load Balancer Load Balancer

Firewall

HTTP Cluster

Portal Cluster

WAS Cell

HTTP Server

node: ebizWS01

WebSphere_Portal_3

WebSphere_Portal_2

WebSphere_Portal_1

WebSphere_Portal

node: PORTAL01 node: PORTAL02 node : PORTAL03 node: PORTAL04

HTTP Server

node: ebizWS02

WebSphere_Portal _7

WebSphere_Portal _6

WebSphere_Portal _5

WebSphere_Portal _4

ReleaseAusr

Instance: PSPROD

(shared)

Community

Customization

node: ebizWS01

WebSphere_Portal_3

WebSphere_Portal_2

WebSphere_Portal_1

WebSphere_Portal

wmm

fdbkusr

(shared)

HTTP Server

fdbkusr

(shared)

HTTP Server

node: ebizWS02

WebSphere_Portal_ 7

WebSphere_Portal_ 6

WebSphere_Portal_ 5

WebSphere_Portal_ 4

jcr

(shared)

Instance: JCRPROD

WAS Cell A

Deployment Manager

DMGR

Figure 2-2 A single clustered architecture

Key features of this architecture are:

򐂰 A single load balanced HTTP Server cluster (HTTP Cluster) that spans two or more

physical nodes.

򐂰 A single WebShere Portal Server cluster (Portal Cluster) deployed in a single WebSphere

Cell.

򐂰 The WebShere Portal Server cluster consists of two of more horizontal cluster members

and any number of vertical cluster members per node (resources permitting).

򐂰 A dedicated stand-alone WebSphere Deployment Manager is responsible for the

management of the entire WebSphere Cell (Cell A).

򐂰 As the environment only consists of a single WebShere Portal Server cluster, only a single

release database domain is required.

򐂰 The remaining database domains (communityusr, customizationusr, wmmusr, fdbkusr,

lmdbusr, and jcr) are deployed alongside the release database domain. Note that the JCR Repository exists in a different database.

򐂰 The environment also hosts a LDAP directory server (not shown), which is highly

available, for maintaining the registered user base.

node: PORTDB01

node: PORTDB02

node: WSND01

Chapter 2. Architecture and planning 23

The multiple clustered architecture

New to WebSphere Portal Server Version 6.0.1 is the ability to architect multiple Portal clusters within the same WebSphere cell. Indeed, the WebSphere Portal Server Version 6.0 Information Center describes just such an architecture and the necessary configuration tasks needed to implement such a deployment.

It is, however, important to understand that such an architecture is subject to a number of inherent limitations. Most important, despite the fact that the Information Center states that it is possible to federate multiple, independently configured Portals into the same WebSphere cell and that it is possible to manage such clusters from the same cell, it must be recognized that only a single J2EE enterprise application, of a unique name, can be deployed into a given WebSphere cell at any one time. Furthermore, all J2EE enterprise applications are cell-scoped. This limitation makes it impossible to deploy different versions of the same enterprise application against the different Portal clusters within the same cell, as the case might be during periods of 24x7 maintenance. This extends to WebSphere Portal Server itself, which consists of a number of enterprise applications that make up the effective runtime and also to the very Portlet applications deployed within the solution.

In other words, enterprise applications are shared across the WebSphere cell, regardless of the presence of multiple Portal clusters or not. As a consequence, it is not possible to upgrade one Portal cluster in isolation from another, as the underlying enterprise applications and supporting class libraries are common to both. Attempting to do so runs the risk that incompatibilities will result, potentially bringing down the complete environment.

It is plausible that such a WebSphere Portal Server architecture is practical for the purposes of providing different applications and services between Portal clusters, which might be the case with each Portal cluster supporting a different line of business.

The dual cluster with two lines of production architecture

Deploying either a single clustered instance or a multiple clustered instance within the same WebSphere Cell of WebSphere Portal Server V6.0.x would at first glance appear to be the most logical architectural choice for most implementations.

However, when 24x7 availability is considered as a non-functional requirement, both architectures fall short of the mark. This is not to say that both architectures are not capable of maintaining a continuous level of operation during periods of either scheduled or unscheduled maintenance. Indeed, WebSphere Portal Server V6.0.x has introduced considerable improvements over previous versions in this very respect. Rather, the considerations are associated with the comfort factor demanded by the very organizations that typically manage such implementations. For those organizations that do not mandate 24x7 availability, which should not be confused with high availability, deploying a single clustered instance of WebSphere Portal Server remains an acceptable choice.

The deployment, therefore, of a WebSphere Portal Server V6.0.x dual clustered architecture represents a significant architectural enhancement for the majority of organizations looking to meet the needs of continuous operation with a 24x7 availability requirement. Indeed, such an architecture represents the new WebSphere Portal Server V6.0.x Gold Availability Standard. The primary enabling feature of this capability is the presence of two distinct WebSphere Portal Server clusters, each deployed within separate WebSphere cells. This makes it possible to perform maintenance on one Portal cluster, while the other continues to service user requests. The benefits of adopting such an architecture are that there are effectively two “Lines of Production”. This allows for continuous operation during periods of maintenance, albeit at reduced capacity, without the need for a dedicated failover environment. One “Line of Production” can effectively be taken off line, as and when required, without impacting the remaining “Line of Production”. Critically, the ability to share user customization and

24 IBM WebSphere Portal V6 Self Help Guide

Firewall

community data between different Portal clusters, and the cluster members that participate in each, ensures consistency at the user interaction level (new to Portal Server V6.0.x). That is, any user customization made against one Portal cluster member, by a user, is now available to the same user, as and when that user accesses any of the other cluster members participating in the same or different Portal cluster. Each Portal cluster, in turn, maintains a separate release repository, which provides a mechanism for maintaining all Portal resource definitions, rules, and rights specific to that cluster.

Again, this is an acknowledged product improvement from the limitations associated with WebSphere Portal Server V5.1.x and earlier. Failing to implement such an architecture would otherwise necessitate deploying a single clustered instance of WebSphere Portal Server and adopting either the IBM documented 24x7 Portal maintenance procedure or the use of a secondary maintenance environment.

Figure 2-3 illustrates the system topology needed for a Portal Server V6.0.x dual cluster architecture.

Load Balancer Load Balancer

HTTP Cluster A

Line of Production A Line of Production B

Firewall

Portal Cluster A Portal Cluster B

Line of Production A Line of Production B

WAS Cell A

HTTP Server

node: ebizWS01

WebSphere_Portal _3

WebSphere_Portal _2

WebSphere_Portal _1

WebSphere_Portal

node: PORTAL01 node: PORTAL02 node: PORTAL0 3 node: PORTAL04

HTTP Server

node: ebizWS02

WebSphere_Portal _7

WebSphere_Portal _6

WebSphere_Portal _5

WebSphere_Portal _4

ReleaseAusr

Instance: PSPROD

node: PORTDB01

HTTP Server

node: ebizWS01

WebSphere_Portal _3

WebSphere_Portal_ 2

WebSphere_Portal_ 1

WebSphere_Portal

fdbkusr

(shared)

node: PORTDB02

jcr

(shared)

wmm

(shared)

Community

ReleaseBusr

Customization

HTTP Server

node: ebizWS02

WebSphere_Portal _7

WebSphere_Portal _6

WebSphere_Portal _5

WebSphere_Portal _4

Instance: JCRP ROD

WAS Cell A

Deployment Manager

WAS Cell B

Deployment Manager

node: WSND01

HTTP Cluster B

WAS Cell B

Shared DMGR

Figure 2-3 Dual cluster architecture illustrating two lines of production

Key features of this architecture are:

򐂰 Two independent HTTP Server clusters (HTTP Cluster A and HTTP Cluster B), consisting

of at least two physical nodes per cluster (so that each cluster is highly available in its own right).

򐂰 Two independent WebSphere Portal Server clusters (Portal Cluster A and Portal Cluster

B), one per WebSphere Cell.

Chapter 2. Architecture and planning 25

򐂰 Two independent WebSphere Cells (Cell A and Cell B).

򐂰 Each WebSphere Portal Server cluster consists of at least two physical nodes per cluster

or cell (so that each cluster is in highly available its own right).

򐂰 The WebSphere Plug-in resident in each HTTP Server only routes requests to the cluster

members for the immediate Portal Cluster.

򐂰 Two independent WebSphere Network Deployment Manager (Deployment Manager)

instances, one per WebSphere Cell, are collocated on the same physical node.

򐂰 A separate release database domain (releaseAusr and releaseBusr) exists for each

WebSphere Portal Server cluster or “Lines of Production” (Portal Cluster A and Portal Cluster B), maintaining indenpendant configuration data for each.

򐂰 The remaining database domains (communityusr, customizationusr, wmmusr, fdbkusr,

lmdbusr, and jcr) are shared between each WebSphere Portal Server cluster or “Lines of Production” to maintain a consistent user experience. Note that the JCR Repository exists in a different database.

򐂰 The environment also hosts a LDAP directory server (not shown), which is highly

available, for maintaining the registered user base.

It is worth noting that a dual clustered architecture will require twice as much administration as a single clustered deployment. Furthermore, in order to keep each “Line of Production” in synchronization, a staging environment plays an important part for preparing build promotions. Such tools as XMLAccess and Release Builder must be utilized to ensure consistency between the different “Lines of Production” or clusters.

The geographically deployed architecture

As WebSphere Portal Server has evolved, one requirement that has continually been requested has been the ability to deploy an architecture in geographically distributed fashion. With the release of WebSphere Portal Server V6.0.x, this requirement is now a possibility.

Such a requirement, however, raises the question about how best to design an operational architecture that caters for such a "global deployment".

Not every WebSphere Portal Server deployment with a geographically scattered workforce requires that the physical servers themselves are geographically dispersed. Indeed, many internet facing Portals may be country or region specific, but by the very nature of the internet are accessible worldwide. However, when the demands of an implementation start to include the very integration points that a Portal brings together, partitioning across geographies becomes a necessity. Aspects, such as high availability and disaster recovery, are also influencers for considering a distributed implementation. For example, partitioning a WebSphere Portal Server deployment between Europe and North America becomes a prerequisite when each major geography maintains the local services and back-end systems that are effectively accessed through the Portal. The idea of a geographically deployed architecture can also be considered in terms of a split between multiple data centers, even when those data centers exist within close proximity to one another (across the street or across a city).

With the introduction of database domains in WebSphere Portal Server V6.0.x, greater flexibility was made possible in terms of the permissible operational architecture. As such, the distinction between release, community, and user customization data has made it possible to achieve a truly "global deployment". Readers familiar with previous versions of WebSphere Portal Server will recall that it was not possible to split the Portal database between multiple redundant clusters, located potentially in different geographies, and to maintain a consistent user experience. Indeed, such an architecture when deployed sacrificed the ability for a user to make any customization or personalization modifications, as the changes simply could not

26 IBM WebSphere Portal V6 Self Help Guide

be propagated between clusters. This in part was attributed to the fact that the internal object IDs associated with the various elements of a deployment could not be guaranteed to be unique. Any attempt, therefore, to deploy a bi-directional database replication technique was further hindered. To overcome this constraint, it was mandatory that all Portal cluster members, participating in the same Portal instance, accessed the same centralized database. However, the performance considerations of accessing a centralized database across the WAN from geographically dispersed Portal servers made this approach impractical in many environments.

In addition to the separation of Portal data into distinct database domains with WebSphere Portal Server V6.0.x, which represents an acknowledged product improvement, it should also be recognized that Portal data can now be shared between different Portal clusters and the very cluster members that exist within them. Such database domains can now be deployed in a peer-to-peer manner using techniques like queue replication or 2-way SQL replication in order to provide a global deployment capability, where user personalization is automatically made available to all Portal clusters in all geographies. In this manner, WebSphere Portal Server V6.0.x also allows users to experience portability should they temporarily access the Portal solution from another geo (branch or office location).

Important: The implementation of a multi-clustered WebSphere Portal Server V6.0.x architecture that sees the deployment of individual clusters in each geography to support a truly "global deployment" mandates the use of the same LDAP directory server in all geographies. The LDAP directory server may, however, be replicated for redundancy purposes. This requirement is necessary to maintain uniqueness between Portal users.

The WebSphere XD deployment architecture

The latest WebSphere Portal Server V6.0.1 deployment option includes support for WebSphere Extended Deployment V6.0.2, or WebSphere XD for short. Such an architecture makes it possible to dynamically start and stop additional WebSphere Portal Server cluster members, or dynamic clusters in the WebSphere XD sense, as and when workload demands. In addition, the On-demand Router (ODR) component of WebSphere XD can be utilized to route requests based on priority and user rules.

For more information about WebSphere Extended Deployment refer to:

򐂰 WebSphere Extended Deployment (XD) 6.0.2 support for WebSphere Portal Server, found

at:

http://www.ibm.com/support/docview.wss?uid=swg21264596

򐂰 WebSphere Extended Deployment (XD) 6.0.x Information Center, found at:

http://www.ibm.com/software/webservers/appserv/extend/library/library60x.html

2.4 Portal deployment considerations

Three principle methods exist for implementing maintenance in a WebSphere Portal Server V6.0.x production environment.

2.4.1 In-situ maintenance procedures

As the name suggests, in-situ maintenance describes the process of undertaking maintenance in a target environment without the inclusion of an additional environment for providing operational continuity. For the most part, such maintenance may simply be

Chapter 2. Architecture and planning 27

undertaken during a period of scheduled outage, such as during the weekend or overnight, when the respective users of the solution may be unaffected by any downtime. Alternatively, in-situ maintenance can be performed by adhering to the IBM documented 24x7 maintenance procedure. However, while this latter approach represents a distinct improvement over the 24x7 maintenance procedures applicable to previous versions of WebSphere Portal Server, the complexities of performing such maintenance, and maintaining an uninterrupted level of service, arguably remain high risk for many organizations. As such, the decision to implement the 24x7 maintenance procedure in a single clustered WebSphere Portal Server V6.0.x environment can only rest with the comfort factor required by each particular organization.

The key differentiator between this and the other maintenance methods described in this section is that the in-situ procedure does not require an additional environment during the period of maintenance. Full details for this procedure, including the IBM documented 24x7 maintenance proceedure, can be found in the WebSphere Portal Server Version 6.0 Information Center.

2.4.2 Two sets of production environments

This option considers two sets of production environments, each supporting duplicate WebSphere Portal Server configurations. It is not implied that either environment shares the same user community, customization, and wmm database domains in a peer-to-peer fashion, as is now achieveable with WebSphere Portal Server V6.0.x. Instead, it is characterized by the replication of all data and artifacts between hosting environments prior to undertaking maintenance.

As such, the deployment of two sets of production environments has long been an acknowledged approach for maintaining operational continuity and for addressing disaster recovery. However, unlike the approach detailed in 2.4.3, “The dual cluster with two lines of production architecture” on page 29, such a deployment does not normally see both sets of production servers actively handling the load. It is what is commonly referred to as an active/passive implementation. Furthermore, the passive environment may also serve the purpose of addressing disaster recovery.

When considering an architecture based on the selection of two sets of production environments, there are two sub approaches that are most commonly implemented.

The Flip-Flop approach

One approach for maintaining a continuous level of operation in a WebSphere Portal Server environment has been with the adoption of a Flip-Flop architecture. Such an architecture utilizes a second WebSphere Portal Server instance identical to the primary instance. Each environment is normally clustered and highly available in its own right. During scheduled maintenance, user requests are first gracefully quiesced over to the secondary instance, or Flip environment, before Fix Packs and updates are applied to primary instance. With the successful completion of all maintenance activities to the primary instance, the decision can be made to Flop the users back or to retain the users against the current secondary instance. If the latter option is selected, the secondary WebSphere Portal Server environment effectively becomes the primary instance.

Unfortunately, there are several weaknesses associated with the Flip-Flop architecture that make the approach somewhat less than straight forward to implement. First, it should be fairly evident that the procedure requires an additional physical environment. Typically, many organizations address this issue by collocating the secondary instance, or Flip environment, on the same hardware hosting their staging environment. Secondly, there is the requirement to transfer all configurational data, including the very Portlets deployed within the Portal, and the need to carry across any user customization data between Portal instances. With the

28 IBM WebSphere Portal V6 Self Help Guide

caveat that WebSphere Portal Server prior to V6.0.x did not support database domains, the possibility that such data could be readily shared between Portal instances was not feasible; the only option was the one-way transfer of such data between environments. Finally, the need to undertake any so-called backend plumping, to those systems and services being integration through Portal, warranted significant time and effort to ensure a satisfactory outcome.

Environments with multiple personalities

This implementation deploys both a production and a staging environment. The staging environment, however, has multiple personalities and pulls "double duty". It is primarily the staging environment but also acts as a standby pseudo-production environment for times of scheduled maintenance to the production environment. There is obviously some planning required to ensure that the environment is up to date with configurational data from the production environment, prior to being put into service. The same limitations regarding the replication of data between environments, as described under the Flip-Flop approach, also hold true. Furthermore, this approach is really only viable if the staging environment mimics the production environment in terms of overall system resources and capacity.

It is also vitally important to recognize that it is not the actual staging instance of WebSphere Portal Server, as such, that handles the temporary production load. Rather, such an implementation necessitates the installation of a secondary instance of WebSphere Portal Server alongside that of the staging instance. Without such a configuration, production and staging data would merge and impact the underlying integrity of the entire solution.

2.4.3 The dual cluster with two lines of production architecture

The deployment of a dual clustered WebSphere Portal Server V6.0.x architecture with “Two Lines of Production” brings about distinct advantages when maintenance and operational continuity are concerned. Indeed, the architecture sets the new Gold Standard for Availability with WebSphere Portal Server V6.0.x. The approach makes full use of the WebSphere Portal Server V6.0.x product enhancements that introduce the concept of database domains. As such, one “Line of Production” can be effectively taken off line, as and when required, without impacting the remaining “Line of Production”. Furthermore, as each “Line of Production” has its own release database domain, while the user community and customization database domains are shared, this makes it possible to have two different releases in production.

The deployment of a dual clustered WebSphere Portal Server V6.0.x based architecture usually consists of a minimum of four physical nodes. The nodes are split into two halves (each half will consist of two physical nodes and will host what will effectively be a separate but identical Portal cluster). Customization and community data is shared between each peer cluster permitting user customization updates made in one cluster to be available to the peer. However, release data is maintained on a per cluster basis. Further details can be found in “The dual cluster with two lines of production architecture” on page 24.

Attention: It is important to recognize that the deployment of a dual clustered WebSphere Portal Server V6.0.x architecture with “Two Lines of Production” introduces special considerations in terms of code deployment and release management. Such a requirement is needed to ensure that each “Line of Production” remains consistent and identical in terms of overall user experience. This is achieved by assembling a build, or release, first in a staging environment and then by promoting the build, or release, to each Line of Production.

Chapter 2. Architecture and planning 29

2.4.4 Moving a configuration between environments

A common deployment approach in any IT implementation is to provide separate environments for development, quality assurance, performance testing, pre-production, and production (or some subset of these). As applications move through this life cycle, there is the need to repeatedly promote code and configuration data between environments. Furthermore, the need becomes even more important with the exploitation of a dual clustered WebSphere Portal Server V6.0.x architecture with “Two Lines of Production”.

As such, there are several methods for replicating WebSphere Portal Server configuration data between environments. However, it is important to understand the limitations and assumptions associated with each method.

To get an exact replica of one environment to another, it is first necessary to make a full XMLAccess export from the source environment. At this point, you could import the XML file resulting from the previous XMLAccess export action into another Portal instance to create what would at first seem to be a duplicate configuration. However, as the import action by default applies the literal object IDs associated with the resources from the source environment, there is a high likelihood that these object IDs will clash with any existing object IDs in the target environment. You could avoid this by using the ID generating mode (see the XML reference documentation for detail). When you use the ID generating mode, the object IDs in the input are not taken literally; instead, during the import process, the resources obtain new object IDs when they are created on the target system. However, while this prevents any clash in terms of the object IDs, it does not yield an exact replica. In certain situations, this may be sufficient for a number of customers.

The recommended approach, therefore, for creating an exact replica of one environment to another involves the additional task of “cleaning” the target environment. As such, the target environment needs to be an empty Portal void of any object IDs. Importantly, this must only be undertaken on the target environment after it has been configured completely (including activating security, WCM, and so on). This then allows the literal object IDs from the source environment to be restored as is. Using literal object IDs only makes sense if you really want to create two instances of the same resource, and if you have a controlled environment where you can guarantee that all object IDs that your resources depend on have exactly the required values.

In addition to any XMLAccess and Release Builder tasks, it is necessary to manually copy the associated Portal artifacts between environments. For example, it is necessary to copy the Portlet WAR (Web Archive) to the installableApps directory of the target environment.

2.5 Architecting for performance

WebSphere Portal Server architectures that perform and scale are not accidental. They are the result of proper design development and rigorous assurance processes that include iterative performance verification and re-verification during the entire solution life cycle.

The importance of addressing performance as early in the project as possible is crucial to project success. A positive result requires a strong effort to ensure that performance maintains visibility and importance throughout the project life cycle. Performance, like security, is a secondary consideration on too many projects, resulting in failure, lower capabilities, or frequent critical situations (that IBM must often help to resolve). Such results need not occur if performance is correctly handled and supported from the outset of the project.

30 IBM WebSphere Portal V6 Self Help Guide

2.5.1 Scalability

As mentioned previously, the ability to scale WebSphere Portal Server V6.0.1, or any other WebSphere Application Server for that matter, is essentially achieved by clustering. Clustering allows requests to be Workload Managed (WLM'ed) between a number of cloned copies of the concerned application. In addition, when architected correctly, clustering addresses redundancy and fault tolerance.

Overall Portal scalability will be accomplished by clustering at the various different tiers of the architecture, both horizontally and vertically where permitted. Usually, a platform’s capacity must be capable of handling a realistic amount of transactions over a projected time frame.

2.5.2 Guidance regarding vertical and horizontal scaling

Ultimately, as client load increases, even a properly tuned WebSphere Portal Server will reach a point at which throughput reaches a maximum. After this point, throughput remains fairly constant while response times degrade as further clients attempt to access the solution. Eventually, a saturation point will be reached. The number of concurrent active clients at the saturation point represents the maximum active client concurrency for the solution. Adding more nodes into a cluster is one way of scaling an application to achieve the goals defined by the non-functional requirements (NFRs).

Vertical clustering

Vertical clustering should be considered for a number of reasons:

򐂰 To fully utilize the processing power of modern SMP servers

򐂰 Local redundancy

Horizontal clustering

By contrast, horizontal clustering should be considered for the following reasons:

򐂰 To achieve scalability beyond the limitation of individual servers

򐂰 Redundancy and reliability

򐂰 Hardware failover

Horizontal scaling is especially effective in environments that contain many smaller, less powerful machines. Client requests that would overwhelm a single small machine can be distributed over several machines in the solution. Failover is another benefit of horizontal scaling. If a machine becomes unavailable, its work can be routed to other machines containing cluster members.

By contrast, vertical cloning benefits Symmetric Multi-Processing (SMP) systems and should be implemented when system resources are found to be underutilized. For Java, systems with multiple processors typically outperform multiple systems with fewer processors, when comparing the total number of processors.

A general rule of thumb has always been to allocate a single Java Virtual Machine (JVM) to a single processor. Traditionally, this was based on the constraint that the compaction phase of Garbage Collection (GC) was single threaded. Recent versions of the JVM have, however, minimized this restriction, potentially allowing a greater number of JVMs to run given the total number of available processors. It is also worth remembering that there are a number of JVMs associated with the Deployment Manager and NodeAgent (a NodeAgent is required for each individual physical node participating in the cell) when running Portal Server V6.0.1 in a clustered environment.

Chapter 2. Architecture and planning 31

Tip: Our experience has shown that many customers fail to implement vertical clustering when horizontal clustering is implemented to address the needs of high availability. As such, it is an IBM recommended best practice that both vertical and horizontal clustering are implemented to address the needs of scalability, high availability, and operational availability.

2.5.3 WebSphere queuing mechanism

In order to understand how to maximize performance, it is necessary to understand the WebSphere queuing mechanism. WebSphere implements a componentized architecture, channeling requests through a number of queues. These queues or pools include a Proxy server and Web server (considered even though they are external components), the WebSphere Application Server embedded Web Container, the EJB™ container, data sources, and possibly other connection pooling mechanisms to various custom back-end systems. Each of these resources sustains a queue of requests waiting to use the resource in question. The overall queuing mechanism is designed to converge towards the back end, where resources are deemed more expensive. For example, out front it is not uncommon for the Web server queue to be configured to handle an inordinately large number of requests. This contrasts to a data source pool, which by nature is more expensive (both in terms of CPU and memory) and thus usually only configured to handle a maximum of 10-20 connections simultaneously. Each queue has the potential to become saturated. There also exists the possibility that if one of the back-end queues saturates, that it will have an effect on the other queues in front. For example, it is not unusual that if a data source connection pool saturates, that the Web container will also eventually overload (simply due to the fact that requests cannot be processed further downstream). This can be particularly confusing when investigating performance. In which case, it is recommended that you take a holistic approach to performance tuning and determine which queue saturates first.

Figure 2-4 WebSphere queuing mechanism

32 IBM WebSphere Portal V6 Self Help Guide

Web Server

Web Container

EJB Container

Data Source

The ability to queue requests in the network layer is a critical part of the WebSphere queuing mechanism. For example, if there are more connection requests than available Web container threads, then connections start to backlog, waiting for threads to be freed. If the maximum number of backlog connections is reached, new connections will be refused. Increasing the MaxConnectBacklog queue can extend the number requests queued in the network layer. However, the full implication of increasing the MaxConnectBacklog queue should be understood, as an increased value can effectively lead to latency problems with the WebSphere plug-in resident in the chosen Web server not immediately detecting that an application server has ceased operation (either through a deliberate stoppage or on the occasion of a JVM crash). Choosing the most appropriate value is therefore dependant on the results you wish to achieve.

2.5.4 Choosing a platform

The selection of a suitable platform has many factors that need to be taken into account. The precedent is, however, usually set by cost and the immediate skill set of the team that will install and administer the solution.

The following points should be carefully considered when making choices between hardware platforms:

򐂰 Cross platform benchmark comparisons should be done with caution. Hardware and

software differences between platforms may result in inappropriate comparisons.

򐂰 If comparisons are made, pay special attention to clock speed, number of CPUs used, and

hardware manufacturer benchmarking data.

򐂰 Take into account aspects beyond raw clock speed, including threading models, network

and disk I/O, instruction cache hit/miss ratios, memory speeds, and so on.

򐂰 AIX and Solaris™ platforms both have much better scalability than non-UNIX platforms.

򐂰 The Linux® version is a factor. The most recent versions have incorporated scheduler

changes that contribute to performance.

򐂰 To achieve increased Linux performance, it has been found necessary to update to the

latest kernel and to reduce the number of Web Container threads.

Of course, actual performance depends on complex interrelationships among many variables, including the underlying operating system characteristics.

It is strongly suggested that a three-tier approach is adopted for the solution. This is regardless of the selected platform. Differentiating between the functional components of the solution allows each server to be specifically tailored to the task in hand. For example, placing the Web server on a separate physical machine from the application server allows each machine to run with different OS characteristics. The same holds true for other server types, such as the database servers.

It is also worth considering the licensing implications associated with choosing the platform, as WebSphere Portal Server is typically licensed, at the time of writing, by user or by CPU. As such, there is no distinction regarding the actual performance of a CPU.

Chapter 2. Architecture and planning 33

2.5.5 Separation of WCM from Portal Servers

Although WCM is an integrated sub-component of WebSphere Portal Server V6.0.1, for reasons attributed to performance and scalability, one IBM recommended best practice is that WCM is externalized in its own instance. This approach allows the primary WebSphere Portal Server instance, which maybe clustered, to concentrate on performing the core Portal tasks without WCM resource impact. When WCM is installed in such a manner, you still need to install an underlying WebSphere Portal Server runtime specifically for WCM. However, such a WebSphere Portal Server runtime does not participate in the primary Portal Server instance. Note that this additional WCM Portal Server instance does not participate in the same WebSphere Cell as the primary WebSphere Portal Server instance. As such, if WCM clustering is a requirement, it is also necessary to install an additional instance of WebSphere Network Deployment Manager to overcome this restriction.

Separating the functional aspects of the primary WebSphere Portal Server instance and the WCM instance allows for loose coupling between components. As such, one immediate benefit comes about when upgrading either component; there is no interdependency and each component can be upgraded in isolation. WCM is intended first and foremost as a Web content management system (Web-CMS). As such, it is primarily designed for creating, managing, and publishing Web content consisting of text and images. This should not be confused with the functionality provided by Enterprise Content Management (ECM) solutions.

Deciding to run WCM as an integrated sub-component of Portal Server V6.0.x remains a valid and supported IBM option. However, care should be taken as this approach may place a higher demand on processor utilization and the JVM heap.

Unlike previous versions of WebSphere Portal Server, prior to V6.0.x, which ran WCM as an integrated sub-component, there is no longer the need to create a separate WCM JCR database repository for each Portal Server cluster member. For a cluster consisting of six members there is only the need for a single shared JCR repository. As such, storage capacity requirements are reduced when compared to previous releases.

2.5.6 Separation of Web servers and WebSphere Portal Servers

In most cases, unless the hardware cost is a limiting factor, it is an IBM recommended best practice to architect the Web server and WebSphere Portal Server on separate physical nodes. This allows the greatest level of availability and performance. The Web server nodes may be specifically tuned for static content serving. The major architectural advantage, however, of such a configuration is that the Web server nodes may be placed within a DMZ, and the WebSphere plug-in can communicate through the internal firewall to the WebSphere Portal Server nodes located within another segment of the corporate LAN. Separating the Web server from the WebSphere Portal Server also reduces any contention between resource utilization. Potentially, this would allow a dedicated WebSphere Portal Server to perform without the impact attributed to the co-location of the Web server and vice versa.

However, despite these limitations, co-location remains a valid option in low volume environments within an architecture for intranet applications requiring Web server facilities over and above those provided by the embedded Web container. It is not recommended that the embedded Web container is accessed directly.

Surpassing the saturation imposed by a single Web server is easily and cheaply achieved by architecting additional Web servers. These nodes are typically commodity based machines (in comparison to mid and high-end UNIX® servers). Linux is well suited here, although at a price’ AIX also offers the benefit of the Fast Response Cache Accelerator (FRCA) kernel based caching mechanism.

34 IBM WebSphere Portal V6 Self Help Guide

Architecting a minimum of three Web servers is also recommended from the point of view that, if a Web server should fail or be taken out of service in a two-server model, then the remaining server has the potential to become overloaded. Load balancing is most effective with three or more servers in a cluster. As such, applications that require load balancing should ideally be spread across three or more servers.

2.5.7 JVM recommendations

One common misnomer is that setting a large JVM heap size improves performance. This is simply not the case. It is strongly advised that the Java maximum heap setting is chosen carefully and then only based on a thorough Java garbage collection (GC) analysis.

Remember:

򐂰 If you use a big heap, then garbage collection will be less frequent but much slower, as

there is a lot of memory to search through.

򐂰 If you use a small heap, then garbage collection will be more frequent but very fast, as

there is less memory to search through.

The Java garbage collection (GC) cycle, which is a “stop-the-world” implementation, will prevent the application server from handling loads for a short period of time. All threads are effectively suspended, with the exception of the garbage collection threads, while GC completes to protect the Java heap from corruption. WebSphere Portal Server vertical clustering can be used to ensure that the CPU is able to provide execution time for at least one cluster member server that can handle the load. Since Version 1.3.x, the IBM JVM has supported multiple garbage collection (GC) helper threads to improve performance during the mark phase of GC.

A major concern for IBM is when customers configured WebSphere Portal Server with a large JVM heap and a high Web Container thread pool. In keeping with the IBM Proven Performance Tuning Methodology, the recommendation is to reduce the JVM heap and the Web Container thread pool and to distribute the load over additional cluster members. The larger the number of Web Container threads, the higher the number of concurrent requests allowed to enter the Web Container. At some point, however, the number of concurrent threads being processed by the Web Container may overwhelm the ability of the JVM. To prevent such an occurrence, a smaller Web Container thread pool can be used. Pending requests will be queued in the network layer.

The rationale behind this recommendation is that smaller discrete cluster members will generally outperform one larger single occurrence, so sharing the load equally guarantees better concurrency. In addition, the benefit from running a single JVM on a large multi-processor machine does not always benefit from all of the resident CPUs. Of course, there are many other factors that influence performance. It should be remembered that adding additional cluster members is the method by which WebSphere and WebSphere Portal Server scales.

It is important to mention that garbage collection (GC) is one of the strengths of Java. By taking the burden of memory management away from the application developer, Java applications tend to be much more robust than applications written in non-garbage collected languages. However, this does not mean that the Java developer can totally neglect memory management. Failing to dereference Java objects after use will prevent the Java garbage collector (GC) from freeing the memory back to the Java heap (this constitutes a memory leak). Likewise, fetching large resultsets and placing them into an array, so that they can be passed as a single variable between objects, also has memory implications.

Chapter 2. Architecture and planning 35

2.5.8 Portlet application JVM considerations

Portlet applications, like any other Java based applications, when deployed into WebSphere Portal Server, reside within the same JVM and therefore share resources, such as JVM heap space and the Web container thread pool. In this way, Portlet applications are limited to the following constraints:

򐂰 Shared JVM resources may become constrained if one Portlet application experiences

runaway memory consumption.

򐂰 The JVM cannot be tuned specifically for any one Portlet application's requirements.

򐂰 Individual Portlet applications cannot be guaranteed a QoS above that of the WebSphere

Portal Server proper.

򐂰 Poorly written Portlet applications cannot be isolated and potentially run the risk of

impacting other Portlet applications deployed within the Portal.

򐂰 Of course, Portlet applications that perform and scale are not accidental. They are the

result of proper development and processes that include iterative performance verification and re-verification during the entire application life cycle, including post-production maintenance.

2.5.9 High availability and HTTPSession failover

User interactions with WebSphere Portal Server are maintained through the use of a HttpSession. This provides a way to preserve data across multiple pages or requests on an individual user basis. The failure or outage, either scheduled or unscheduled, of a WebSphere Portal Server cluster member will result in the termination of the user's HttpSession. As such, it is possible to enable HttpSession failover support to facilitate maintaining a user's session when requests are failed over to a subsequent cluster member.

However, arguably one of the most misunderstood subjects is that of the HttpSession. First, for WebSphere Portal Server, the HttpSession should not be confused with the LTPA token. It is the actual LTPA token and not the HttpSession that maintains the delegated authentication credential. Without such a credential, a user would be challenged to reauthenticate with the solution each time he or she initiates a subsequent request. The HttpSession is also subject to an inactivity timeout. However, it is possible to configure Portal Server to create a new HttpSession should the initial HttpSession expire. Secondly, the use of the HttpSession as a mechanism within WebSphere Portal Server for persisting user attributes for the duration of a user's session is generally discouraged, as there are alternative methods for achieving the same goal more efficiently.

It should be noted that HttpSession failover does not provide transaction failover. In-flight transactions would need to roll back in the event of a cluster member outage, regardless of whether HttpSession failover was enabled or not. It is, however, worth remembering that the underlying WebSphere Application Server instance of WebSphere Portal Server includes a Transaction Manager that can be leveraged. Finally, it follows that the size of the HttpSession object and the size of the permissible Java heap directly influence the number of users that Portal can concurrently support. Of course, scalability issues can be addressed by WebSphere clustering.

36 IBM WebSphere Portal V6 Self Help Guide

2.6 Security

Security within the enterprise has become increasingly more important and complex as distributed systems and Internet technology have merged. The issue can hardly be ignored, as security breaches are announced in the news on a daily basis. While security is becoming increasingly more complex, technology has also provided us with better ways to implement and maintain security within an organization.

2.6.1 WebSphere Portal Server security

WebSphere Portal Server leverages the underlying security mechanisms of WebSphere Application Server for authenticating users. That is, when a user logs into the Portal, it is actually the underlying WebSphere Application Server that performs the authentication task (assuming that no Reverse Authenticating Proxy Server, such as Tivoli WebSEAL or CA SiteMinder are being used). WebSphere Portal Server then goes on to retrieve the security context from WebSphere Application Server and processes the login. Then, the integrated WebSphere Member Manager component of WebSphere Portal Server must perform an additional LDAP query to retrieve a further number of user attributes and to determine the group membership for the concerned user.

Successfully authenticated users also receive a Lightweight Third-Party Authentication (LTPA) token, containing a delegable credential in the form of an encrypted transient cookie, from the underlying WebSphere Application Server instance. This cookie is only valid for the duration of a user's browser session and is used by way of the embedded LTPA token, to honor subsequent requests which would otherwise require re-authentication. However, the LTPA token is in itself subject to expiry even if a user's browser session is maintained. The LTPA token effectively starts to time out immediately upon creation.

WebSphere Portal Server also includes all the functionality for controlling access to resources based on a number of predefined roles. This involves the process of both determining if the identified requester has permission to access the requested resource and the ability to make fine-grained authorization decisions.

2.6.2 Using External Security Managers

Although not a mandatory requirement for a WebSphere Portal Server solution, the use of an External Security Manager remains a fully supported option. In most cases, the decision to include such a component is based not only on the security of the immediate system, but on the value of deploying an “enterprise wide” calibre security solution. WebSphere Portal Server and the underlying WebSphere Application Server are secure in their own right and benefit less than one might expect from an External Security Manager. However, when many systems are consolidated within an organization, enterprise security adds significant value.

A maximum security policy would, however, dictate that additional security software adds to a solution by providing another layer that must be cracked; if not for anything else, then for fending off DoS (Denial of Service) attacks.

The implications of not architecting an External Security Manager, such as Tivoli Access Manager (TAM), should be fully understood. Most notably, without TAM, WebSphere Portal Server user accounts cannot be automatically locked after a certain number of invalid password attempts (three times) and concurrent logins using the same user account cannot be prevented. Unless, that is, a custom coding effort is undertaken to develop a Custom User Registry (CUR) for fulfilling such a purpose.

Chapter 2. Architecture and planning 37

External Security Managers also address much larger problems, such as enterprise SSO (Single Sign-On), complex authentication, and centralized authorization.

2.6.3 Single Sign-On (SSO)

Single Sign-On (SSO) is the term used to describe a system or mechanism where users need to undergo a minimum number of explicit authentication steps in order to be given access to multiple systems or services. SSO enhances user convenience by automating access to all authorized servers and services through a single authentication process. This capability eliminates the need to remember multiple sign-on processes, user IDs, or passwords. Moreover, by this single action, user authentication errors are reduced.

The purpose of SSO is to:

򐂰 Provide a SSO capability for all Web-based applications. A user should only need to log in

one time to one entity to obtain access to all authorized applications and content, which may reside on various servers.

򐂰 Provide a centralized point of authentication, generating a valid credential (ticket, cookie,

and so on).

򐂰 Remove the need for application developers to specifically authenticate users within their

application code. The intricacies of security can be abstracted from such applications.

򐂰 Provide a cross-platform security solution. Experience has shown that there is a need to

maintain operating system independence for Web-based application security.

򐂰 Provide the ability to control access to Web applications and content, which may be

hosted through multiple Web servers, at the URL level.

򐂰 Provide the ability to make fine-grained authorization decisions within applications. While

this is not an immediate deployment requirement, the solution must allow for this capability to be added.

򐂰 Support browser based access to applications from both customers and employees. From

their desks, internal users may access both internet-hosted applications and internal applications. At this time, there is no requirement for employees to have access to internal applications from the internet.

What SSO is not:

򐂰 An Identity Management Solution.

򐂰 A Federated Identity Management Solution.

Out-of-the-box SSO with WebSphere Portal Server

WebSphere Portal Server, or rather the underlying WebSphere Application Server instance, provides SSO functionality out-of-the-box. However, it is important to understand the capabilities and constraints associated with such a deployment. This statement is made in as much that the out-of-the-box SSO functionality may be insufficient for some enterprise-wide implementations, but also in the context that the adoption of an External Security Manager may simply be overkill.

Key points to note about the out-of-the-box SSO provided with WebSphere Portal Server are:

򐂰 SSO is based on the Lightweight Third-Party Authentication (LTPA) token, which is an IBM

proprietary standard. It is suitable for achieving SSO between WebSphere and Domino based products only.

38 IBM WebSphere Portal V6 Self Help Guide

򐂰 SSO is a function of the underlying WebSphere Application Server instance. As such,

there is no concept of a Reverse Authenticating Proxy Server, which could otherwise be place in a DMZ for added security.

򐂰 Pseudo-SSO is achieveable with the use of the Credential Vault. However, a user is

required to manually enter his or her user ID and password prior to accessing the back-end system, as the user registries are typically not synchronized.

򐂰 SSO functionality does not extend to any fancy password expiry or user session handling.

That is, concurrent logins using the same user account are not barred.

Enterprise SSO with an External Security Manager

The decision, therefore, to deploy an External Security Manager for a given implementation is usually based on a number of factors. However, one main requirement that often dictates the inclusion of such a product is the demand for an enterprise-wide SSO capability. As mentioned previously, Tivoli Access Manager is just one such product that represents the IBM strategic enterprise-wide security offering. TAM consists of two main components: the Policy Server and the WebSEAL Reverse Authenticating Proxy server. That is, when a user logs into a WebSphere Portal Server solution protected by TAM, it is actually the Tivoli WebSEAL server that performs the authentication task.

As such, the key points for deciding to deploy TAM above the out-of-the-box SSO provided by WebSphere Portal Server, are listed below:

򐂰 TAM provides enterprise-wide SSO capabilities.

򐂰 Basic Authentication SSO support.

򐂰 Forms-based SSO (FSSO) support.

򐂰 Lightweight Third-Party Authentication (LTPA) SSO support.

򐂰 HTTP Header based SSO support.

򐂰 Global SSO support.

򐂰 SPNEGO (Desktop SSO) support.

And in addition, the following aspects are provided:

򐂰 Centralized administration at an organizational level.

򐂰 Expired password handling.

򐂰 Password reset and password strength policy management.

򐂰 Delegated security administration for portal.

򐂰 Session duration or inactivity timeout.

򐂰 Account lockout (possibly for a specified period of time) after a specific number of

successful authentication attempts.

Attention: It should be noted that the deployment of an External Security Manager, such as Tivoli Access Manager, does not necessarily address every aspect of SSO. For example, SSO is generally considered to be homogenous between all participants in a solution. Should the participants in a solution utilize different user repositories, there may well be the need to deploy an Identity Management Solution or a Federated Identity Management Solution.

Chapter 2. Architecture and planning 39

Single sign-off

One often neglected aspect of SSO is the allied sign-off or sign out action associated with a user session. This is especially important because it is not uncommon for the back-end servers participating in the SSO realm to create and issue their own authentication cookies as part of the transparent SSO process. Unfortunately, if a user explicitly logs out of WebSEAL, but does not close or terminate the browser session, the back-end server cookies will remain active within the browser session. This, then creates a security threat by raising the risk that an unauthorized user may gain access to restrictive information, although it should be acknowledged that this kind of threat is only applicable to shared desktops and workstations, such as kiosks.

To overcome this threat, the recommendation is to embed JavaScript code capable of searching and destroying all applicable cookies in the page that WebSEAL redirects to after logging out a user.

2.6.4 Trust Association with WebSEAL

In this configuration, the underlying WebSphere Application Server instance of WebSphere Portal Server needs to be configured to explicitly "trust" the WebSEAL server so that if WebSEAL has already authenticated a user, WebSphere Application Server will not challenge the user to authenticate again. WebSphere Application Server provides a Trust Association Interceptor (TAI) framework for this purpose. Based on the established trust, WebSphere Application Server can map the delegated credential from WebSEAL to a valid WebSphere Application Server credential. The identification of the user must be passed to the TAI in a header called iv-user, which is inserted by WebSEAL into the HTTP Header of the request sent from WebSEAL to the WebSphere Application Server. Note that while WebSEAL can be configured to pass the user identity in other ways, the iv-user header is the only one supported by the TAI. Also note that the user password is not passed in the HTTP Header (for security reasons). After the TAI processing is successful, WebSphere Application Server creates a user authentication cookie called an LTPA token (we recommend using the LTPA token2). This is identical to the process that occurs when the out-of-the-box SSO with WebSphere Portal Server is enabled.

With the availability of the new TAI++, TAI now does not query the User Registry (LDAP) directly for Trust Association Interceptor processing. Instead, the new Interceptor class TAMTrustAssociationInterceptorplus contacts the Tivoli Access Manager (TAM) Authorization Server, which then proceeds to check the User Registry (LDAP). The benefit that this brings to a solution is that the TAM Authorization Server does not have to be the actual TAM Policy Server. As such, a local TAM Authorization Server replica can be installed, either alongside each WebSphere Portal Server node, or on an additional number of dedicated servers. As one might expect, this requires an additional amount of effort and planning, not to mention system resources. However, this is very beneficial when overall performance is a concern, as requests can be offloaded and cached at the TAM Authorization Server replicas, which may or may not be local to each WebSphere Portal Server node, greatly improving performance. After successful processing, TAI++ adds the PDPrincipal to the WebSphere subject or context, which can be retrieved by downstream applications. Furthermore, with the new TAI++, one can add custom attributes to the subject or context in the form of Java sets.

After the TAI++ has accepted the user identification and WebSphere Application Server has created the LTPA token, the WebSphere Member Manager component of WebSphere Portal Server performs additional queries against the User Registry (LDAP). In particular, WebSphere Member Manager does an LDAP search to get group and additional attribute information from the LDAP. WebSphere Portal Server also queries the resource mappings from the Portal database, before displaying the applicable Portal pages.

40 IBM WebSphere Portal V6 Self Help Guide

All communication should be over SSL; the link from WebSEAL to the Web server must use client certificate authentication, and the same must be true for the link from the Web server to the embedded Web Container of the underlying WebSphere Application Server instance of WebSphere Portal Server. Should either link be insecure, the TAI will continue to work, but the link will not be secure.

2.6.5 LTPA token generation with WebSEAL

With this option, one does not need to configure the Trust Association Interceptor (TAI) framework in WebSphere Application Server at all. Instead, one configures an LTPA junction in WebSEAL, and Tivoli Access Manager issues the LTPA token. The junction from WebSEAL to the WebSphere Application Server is configured to pass the iv-user and iv-groups information, and the LTPA token that is created by TAM. At the WebSphere Application Server, TAI is not enabled and the Application Server simply receives the LTPA token in the HTTP header request. The underlying WebSphere Application Server only creates the session cookie for the user and assumes that this user has already been authenticated.

It should be noted that just like the approach outlined in 2.6.4, “Trust Association with WebSEAL” on page 40, the WebSphere Member Manager component of WebSphere Portal Server must perform an addition LDAP query to retrieve a further number of user attributes and to determine the group membership for the concerned user.

2.6.6 Other Tivoli Access Manager considerations

The following recommendations are made with respect to integrating Tivoli Access Manager V6.0, both the Policy Server and WebSEAL components, with WebSphere Portal Server V6.0.1.

WebSphere Portal Server login with Tivoli WebSEAL

Most WebSphere Portal Server deployments include a number of anonymously accessible Portal pages. Advanced configurations may even see the default Portal Login page replaced with a Login Portlet. When WebSphere Portal Server is used in conjuction with Tivoli Access Manager, special consideration needs to be exercised to ensure that both products work in unison.

By default, the standard WebSEAL configuration is to intercept each new client request and to challenge a user to sign-in against a login form before accessing, through a proxy, the actual requested content. Unfortunately, what is not clearly documented in many publications is that this login form is actually the WebSEAL login page. Furthermore, unlike a WebSphere Portal Server page, the WebSEAL page is only capable of supporting static HTML content. Potentially, this page could be customized to mimic the same look and feel as the Portal. However, this may then lead to inconsistencies if WebSEAL is deployed as an enterprise wide security solution.

An alternative approach to the above would be to configure WebSEAL to allow unauthenticated requests to reach, through a proxy, the anonymous pages of WebSphere Portal Server. In this manner, it would be possible to use WebSphere Portal Server to display dynamic Portlet based anonymous content. A user could also interact with a Login Portlet when attempting to register and authenticate him or herself into the solution. In such a situation, the Login Portlet would simply post the supplied user ID/password to the WebSEAL pkmslogin Servlet. The post command may, or may not, include a string containing the URL of the page to redirect to after successful authentication.

Chapter 2. Architecture and planning 41

WebSEAL high availability

The failure or outage, either scheduled or unscheduled, of a WebSEAL server will result in the need for a user to re-authenticate unless a suitable mechanism is configured to handle such conditions. Load balancer affinity normally ensures that subsequent requests from a client go to the same WebSEAL server for enhanced performance. However, when a WebSEAL server fails, the Load Balancer will redirect the user's request to the next available WebSEAL server. However, the WebSEAL-to-user session is maintained on an individual WebSEAL cache basis and when one such WebSEAL goes down, all other WebSEAL servers treat this as a new request and require re-authentication to be done by the user.

To overcome these issues, and to achieve seamless failover between multiple WebSEAL server, one of two mechanisms can be deployed:

򐂰 The Failover Cookie approach is a mechanism by which an additional cookie is created

(and updated every time) and sent by WebSEAL during authentication to the user. When a request is failed over to another WebSEAL server, that server decrypts the cookie to understand that the user was a pre-authenticated against the initial WebSEAL server.

򐂰 The Session Management Server, newly introduced in TAM V6.0, is a useful alternative for

maintaining the failover sessions of WebSEAL in a persistent manner. As such, the Session Management Server exposes a Web service to persist the user sessions to a database.

WebSEAL load balancing

WebSEAL includes the built-in capability for providing load balancing and failover when two or more back-end systems participate in the same junction definition. However, it is important to recognize that such a configuration does not extend to gracefully quiescing user requests, from one or more back-end systems, when those systems need to be taken down for scheduled maintenance. This is in contrast to the feature rich functionality provided by most commercially available load balancers. The requirement to be able to gracefully quiesce users, from one or more back-end systems, is especially important when deploying a dual clustered WebSphere Portal Server architecture with Two Lines of Production.

Session Management Server

The Session Management Server, as discussed previously in “WebSEAL high availability” on page 42, is a newly introduced feature of Tivoli Access Manager V6. In addition to the ability to handle session failover between multiple WebSEAL servers, the Session Management Server can also be deployed to restrict the number of concurrent logins or sessions each user can have at one time. Such a requirement is often in demand when WebSphere Portal Server is deployed in the Financial Services sector.

However, using the Session Management Server requires additional resources, as the component runs as a WebSphere Application Server based application. Furthermore, at the current time of the writing this document, the Session Management Server does not support any database server other than DB2.

Common Auditing and Reporting Service (CARS)

Tivoli Access Manager Version 6 also includes the new IBM Common Auditing and Reporting Service (CARS) platform, which provides a consistent way to collect audit events and report on the collected data. However, like the newly included Session Management Server, the CARS event server also demands consideration during the early stages of a project, as the component also runs as a WebSphere Application Server based application. Likewise, at the current time of the writing this document, the component only supports DB2 for data storage.

42 IBM WebSphere Portal V6 Self Help Guide

One may wish to consider CARS as an alternative to exploiting the generic UNIX syslogd for centrally collecting audit events in a distributed environment, as the standard syslogd does not provide encryption or any guarantee of delivery by being based on UDP.

2.6.7 LDAP Directory Servers

There are several aspects to LDAP Directory Server design that make the topic a non-trivial issue. Two of the most important aspects are described below.

LDAP directory structure

There are potentially a number of issues and considerations concerning the structure of the Directory Information Tree (DIT) when using WebSphere Portal Server, particularly when an existing populated LDAP directory is required to be used or when a new structure is to be defined from scratch.

DIT example

The suffix of an LDAP directory server is usually defined as part of the installation and configuration process. In the example illustrated in Figure 2-5 on page 44, the suffix has been fixed as dc=uk, dc=acme, dc=com, which adheres to the domain name syntax-based convention. Potentially, this could be revised to just dc=acme, dc=com or even dc=acme, dc=co, dc=uk.

It is anticipated that a number of organizational units (OU) would be needed at the topmost level to provide a degree of granular isolation between subordinate categories. As such, ou=people and ou=groups are normally created. It is intended that ou=people will contain all user entries and that the ou=groups will contain all the subordinate sub-groups that relate to the various functional departments of an organization.

The ou=people organizational unit directly contains the many user identities for the Portal solution. The hierarchy is totally flat with no boundaries between the users. The distinction is not made as to which department or Line of Business (LOB) a users belong under ou=people. Instead, the ou=groups organizational unit contains further sub-organizational units representing the different departments of an organization, such as ou=GroupA or ou=GroupB. This approach allows for greater flexibility when a user is assigned to work in a new department and so on.

Users are required to be associated with a group depending on their Portal "Role". Membership of a specific group therefore maps to a specific Portal "Role" and determines what access the user will be privileged to experience.

Chapter 2. Architecture and planning 43

com

(dc)

dc=uk, dc=acme, dc=com

ou=people ou=groups

uid=user1 cn=groupA

uid=user2

uid=user3

uid=user4

uid=…….. cn=………..

Figure 2-5 LDAP Basic DIT Design

LDAP schema design

By default, the WebSphere Portal Server configuration assumes that the underlying LDAP directory schema uses the object class applicable to the selected LDAP directory version, for example, InetOrgPerson when using IBM Tivoli Directory Server (TDS) V6.0. This is sufficient for most organizations, as it was defined to meet the requirements found in today's internet and intranet directory service deployments. However, in some cases it may not be sufficient enough. For example, it may be necessary to add the information of an employee's Account Number, Insurance Number, and Employment Band. These attributes do not exist in the standard InetOrgPerson object class.

cn=groupB

cn=groupC

cn=groupD

acme

uk de hk

people groups

user1

user2

user3

user4

……..

(uid) (cn)

groupA

groupB

groupC

groupD

……..

(dc)

(ou)

Modifying the default object class, in an attempt to add or change an attribute, is not recommended. If the definition of one of the default attributes, for example, givenName, needs to be changed, then we recommend that a new attribute be created. However, such an attribute should only ever be created in a new custom object class. Objects can be derived from other objects. This is known as sub classing. An object class of AbcPerson could be defined as a subclass of the inetOrgPerson object class. The AbcPerson object class would have the same attributes as the inetOrgPerson object class and could add other attributes such as Account Number, Insurance Number, and Employment Band. This prevents potential conflicts when a new version of the directory is installed and the default schema is refreshed. One special object class, called top, has no superiors. The top object class includes the mandatory object Class attribute. Therefore, the attributes in top object class appear in all directory entries.

LDAP directory server selection

Make no mistake, all LDAP directory servers are not created equal. Tivoli Directory Server (TDS) was designed as standards-compliant enterprise directory server from inception. One of the main strengths that TDS has over other directories is that data is retained in an underlying DB2 database. Here, the DB2 database engine provides scalability to tens of millions of entries, as well as groups of hundreds of thousands of members. When this alone is compared to directories that store data as metadata on a file system, there is a distinct performance and integrity advantage.

The Lotus Domino LDAP implementation only supports the indirect method to locate the group memberships for a user. As such, it is not possible to determine the group membership of a given user by querying the user object directly. Instead, group membership is achieved by

44 IBM WebSphere Portal V6 Self Help Guide

iteratively searching through the member list of all groups. A second limitation of the Lotus Domino LDAP implementation is that the number of members in a group is limited by the size of the field. To work around this issue, nested groups can be implemented, whereby members are divided across two or more groups and then each of these groups are added as members to the original group. Unfortunately, both these limitations impact the amount of time it takes to perform the Portal login step. For situations where large LDAP deployments have been configured within excess of 900 groups and 80,000 users, it is commonly acknowledged that the Portal login action will take a longer than usual time.

LDAP directory server high availability

WebSphere Portal Server V6.0.x introduced support for multiple LDAP directory servers with respect to new multi-realm capabilities. Not surprisingly, this has lead to some confusion when deploying multiple LDAP directory servers in response to the requirements of high-availability. As such, when multiple LDAP directory servers are deployed in support of a multi-realm deployment, often used in conjuction with Virtual Portals, these LDAP directory servers need to be highly available in their own right.

For Tivoli Directory Server based implementations, high availability is achieveable through the deployment of two directory servers that operate in a master peer-to-peer topology. However, in a slight deviation from the standard peer-to-peer practice, which works on a concept that there are multiple master peers in an environment each being capable of processing read and write requests, the recommend solution is to utilize a load balancer to preference one master peer as the active member for all read and write requests. The reason for this decision is to eliminate any potential conflicts that would otherwise result from two-way replication.

As such, the load balancer should be configured to always route read and write requests to the nominated master peer during normal operation. However, should the load balancer detect a failure of the master peer, the load balancer will re-route all requests to the alternate master peer. During write requests, there will be replication from 'node 1' to 'node 2', not the other way round, as there should not be any write requests being distributed across both LDAP servers or peers. It follows that read only requests can be evenly distributed to both peer LDAP servers. This can be achieved by configuring a second load balancer cluster group, with a different virtual host name to make a distinction from the first load balancer cluster group and virtual host name.

Note: It is not implied that by deploying a load balancer as a mechanism for handling LDAP directory server failover that it is possible to distinguish between the actual read and write requests of a particular application. For example, this technique does not imply that it is possible to determine which requests originating from WebSphere Portal Server are of a read nature and which are of a write nature, on a per request basis.

For those software products that include built-in LDAP redundancy, such as the Authorization Server and WebSEAL components of Tivoli Access Manager, there is no requirement for a dedicated load balancer. Moreover, the inclusion of a load balancer could impact the ability of the built-in fail-over mechanism to work effective.

It is not uncommon for the same load balancer, as mentioned above, to also serve a critical part in the overall solution architecture. That is, the load balancer or, more accurately, the back-end load balancer, is responsible for load balancing the many requests that originate from the WebSphere Portal Server cluster members to the various back-end servers. For example, it should be apparent that user requests do not bypass Portal Server to directly access the various back-end servers. Rather, it is the actual Portlet applications deployed within WebSphere Portal Server that invoke the services provided by the back-end servers. A Portal page, as such, may aggregate the response from several back-end servers. In such circumstances, it is important to ensure that the load balancer itself does not become a

Chapter 2. Architecture and planning 45

bottleneck, as this will have the potential to impact the overall performance of WebSphere Por tal Server.

When using LDAP over SSL (LDAPS), care should be taken when utilizing a load balancer as described above. LDAPS not only establishes a JNDI context against the target server, but also implements SSL handshaking between the client and target server (including key negotiation). Whether the load balancer simply just redirects the SSL connection to the target directory server or whether the SSL connection is terminated at the load balancer, with the load balancer re-negotiating a secondary SSL connection to the target directory server, needs to be decided.

LDAP directory servers and firewalls

Problems can arise if a firewall is placed between WebSphere Portal Server and the chosen LDAP directory server. Under such circumstances, authentication can appear to stall after a long period of inactivity. This typically manifests itself in the morning after a night of inactivity, whereupon users may wait up to 30 minutes before authenticating into the Portal solution (unless the Portal is restarted or the LDAP Reuse Connection parameter is disabled from the WebSphere administrative console and WMM connection pooling mechanism is disabled). After this initial period, subsequent users are authenticated in the normal fashion.

The origin of this problem is not with WebSphere Portal Server or the underlying WebSphere Application Server instance, but with the firewall idle timeout. System Administrators should ensure that the tcp_keepidle system setting on each of the servers is smaller than the firewall idle timeout. Failing this, when a client is left to idle for longer than the firewall idle timeout, a communications error will be encountered. Usually, a keepAlive packet is sent according to the tcp setting of tcp_keepidle.

2.7 Database considerations

The deployment of a suitable database is probably one of the single most critical factors in a WebSphere Portal Server implementation. As several choices and combinations are available, selecting the most optimal architecture involves careful consideration of many factors.

2.7.1 WebSphere Portal Server database disclaimer

Details of the actual underlying data storage layouts are abstracted and hidden from the WebSphere Portal Server administrator. The WebSphere Portal Server schema is not published and IBM reserves the right to make modifications to the schema in future Portal Fix Packs. Any manual manipulation of the underlying data store is strongly discouraged, to the point that it will not be supported by IBM.

2.7.2 Database domains

With the introduction of database domains in WebSphere Portal Server V6.0.x, greater flexibility was made possible in terms of the permissible operational architecture. A full description of each of the database domains can be found in the WebSphere Portal Server Version 6.0 Information Center. In addition, further information including worked examples can be found in the WebSphere Portal Version 6 Enterprise Scale Deployment Best Practices, SG24-7387, found at:

http://www.redbooks.ibm.com/abstracts/sg247387.html

46 IBM WebSphere Portal V6 Self Help Guide

In this section, we provide a high-level overview of the two of the most common deployment options.

The dual cluster with Two Lines of Production architecture

Figure 2-6 depicts a dual clustered WebSphere Portal Server V6.0.x architecture supporting “Two Lines of Production”. Each “Line of Production” consists of multiple WebSphere Portal Server cluster members and accesses that are effectively the same community, customization. and wmm database domains. Such domains are said to be “shared” and are responsible for ensuring a consistent user experience. The sharing of the database domains ensures that data is automatically available to both “Lines of Production”. The one exception to this is the release database domain associated with each “Line of Production”, as each release domain maintains unique data specific to that “Line of Production” or cluster.

Database Server

Portal Cluster

Community

Line of Production A

Customization

Portal

WMM

Portal

Release A

Portal

Release B

Portal

Database Server

JCR

Figure 2-6 Database domains in a dual clustered WebSphere Portal Server V6.0.x architecture

Portal Cluster

Line of Production B

Portal

Any user customization made against one cluster member, regardless of the “Line of Production” or cluster, by a user, is now available to the same user, as and when that user accesses any of the other cluster members participating in the same or different “Line of Production”. It should be acknowledged, however, that under normal conditions session affinity is maintained against the same cluster member for the duration of a user's session. The only exception to this is when a cluster member becomes unavailable, either through a deliberate or an unscheduled outage.

Figure 2-6 also shows a separate database server containing a shared JCR database. Although not mandatory, it should be acknowledged that a JCR database will have very different growth rates and performance characteristics from the main Portal domain databases. Architecting a separate database, as such, possibly in a different database instance or on a different physical database server, is one common option.

Chapter 2. Architecture and planning 47

The geographically deployed architecture

In a geographically deployed WebSphere Portal Server V6.0.x architecture, as shown in Figure 2-7, each geography maintains its own set of databases. Each database would be highly available in its own right. However, the subtle difference between this implementation and that shown in Figure 2-6 on page 47 is that the shared database domains are replicated across a Wide Area Network (WAN) using such techniques as queue replication or 2-way SQL replication.

Geo A Geo B

Portal Cluster

Line of Production A

Portal

Database Server

Community

Customization

WMM

Release A

Database Server

JCR

2-way Sync

JCR Replication

Database Server

Community

Customization

WMM

Release B

Database Server

JCR

Figure 2-7 Database domains in a geographically deployed WebSphere Portal Server architecture

Portal Cluster

Line of Production B

Portal

2.7.3 Distinct databases or distinct schemas

The WebSphere Portal Server architecture allows each of the required database domains to exist in the same database instance. However, for availability and performance reasons, it is strongly recommended that due diligence is performed. If, for example, one database domain has different access characteristics and growth rates, differentiating between distinct databases would allow any DBA to specifically tune and size that database accordingly.

A DB2 instance is a logical database server environment. DB2 databases are created within DB2 instances on the database server. The creation of multiple instances on the same physical server provides a unique database server environment for each environment or sub-system. For example, the primary WebSphere Portal Server instance and the

48 IBM WebSphere Portal V6 Self Help Guide

WebSphere Portal Server instance associated with a stand-alone WCM deployment can be managed on the same machine in isolation.

Tip: For those organizations using Oracle as their preferred database, the DB2 terminology described in the WebSphere Portal Server Version 6.0 Information Center can lead to confusion. In Oracle terms, a WebSphere Portal Server database domain should be considered an Oracle schema. As such, multiple schemas can exist within the same Oracle database. However, for the reasons outlined previously, it may on occasion prove beneficial to architect a separate Oracle database for a particular schema, for example, when considering the JCR Repository requirements of WCM and PDM.

2.7.4 Database high availability

To safeguard against catastrophic failure of the proposed WebSphere Portal Server solution, it is essential that the database tier is highly available. When using DB2, two principle methods exist for achieving high availability.

High Availability Cluster Multiprocessing

High Availability Cluster Multiprocessing (HACMP™), can be used to implement hardware clustering. That is, HACMP can automatically switch over from a failing server to another server, thus minimizing unscheduled down time. As such, the HACMP software detects that there is a problem with the initially active node and initiates the following actions on the standby node:

򐂰 Take over the applicable IP addresses.

򐂰 Take over the shared disks.

򐂰 Start the necessary application processes.

This is commonly known as a cold-standby configuration; only one node is actively running workload at a time. Furthermore, it is important to recognize that HACMP does not offer data redundancy.

Appendix B, “7x24 Maintenance” in the HACMP for AIX 5L V5.2 Administration and Troubleshooting Guide, SC23-4862 has the most current and comprehensive information about maintaining a cluster in a 24X7 environment. It can be found along with the other documentation for HACMP at the following Web site:

http://www.ibm.com/servers/eserver/pseries/library/hacmp_docs.html

HADR

DB2 High Availability Disaster Recovery (HADR) provides a new alternative for delivering a high availability solution by replicating data from a source database, called the Primary, to a target database, called the Standby. HADR provides protection for both partial and complete site failures. Combined with the new Automatic Client Reroute (ACR) capability, HADR provides transparency to the application regardless of the failure type, from hardware, network, or software issues to disaster scenarios like fire. HADR provides multiple levels of protection allowing flexibility in the environment. Additionally, DB2 provides an easy to use wizard that allows the entire configuration to be set up in a matter of minutes.

HADR functionality is available as part of the DB2 UDB Enterprise Server Edition at no extra charge. Users of DB2 UDB Express and DB2 UDB Workgroup Server Editions can add HADR function to their servers by purchasing the DB2 UDB High Availability Disaster Recovery Option.

Chapter 2. Architecture and planning 49

Figure 2-8 gives an overview of the DB2 HADR.

Ethernet (Service Network)

DB01

DB2 UDB ESE V8.2 FP 10 (primary)

hba0

Tape Library

Figure 2-8 DB2 HADR

pSeries 570 4x 1.65 Ghz AIX 5.3.0.0 + HACMP 5.3 8 Gb RAM

hba1

hba2

SAN Storage

Area for Node 1

Data

Logs

en0

en2

en1

en4 en4

en3

tty1

Gigabit Ethernet

(for HADR Log transfer)

RS232C (for HACMP)

DB02

en0

en2

en1

en3

tty1

SAN Storage

Area for Node 2

pSeries 550 2x 1.65 Ghz AIX 5.3.0.0 + HACMP 5.3 4 Gb RAM

DB2 UDB ESE V8.2 FP 10 (standby)

Data

Logs

hba2

hba1

hba0

Tape Library

Without HADR, the length of time it takes to cut over from a database failure is unpredictable. It can take several minutes or hours before the failure is solved and the database is available. HADR enables failover and fallback between the two systems. The Standby database can take over as the Primary database with full DB2 functionality. After the failed old Primary is repaired, it can rejoin the HADR pair as a Standby database if the two copies of the database can be made consistent. After the original Primary database is reintegrated into the HADR pair as the Standby database, a failback operation can be performed so that the original Primary database is once again the Primary database. HADR requires the same hardware, OS, and DB2 software on the two systems (except for some minor differences).

A high availability mechanism is still a requirement, as DB2 HADR does not have a fault tolerant detection feature. In addition, if the Log transfer network is down, HADR takeover cannot be done. So this network is very important. In this configuration, a dedicated Gigabit Ethernet segment is used in conjunction with Network Interface Backup (NIB) for redundancy.

Note that an outage at the Log transfer network would cause the Primary to drop out of communication with the Standby (and if in Peer state, would cause the Primary to drop out of Peer state and run independent of the Standby). Once the network is repaired, the Primary and Standby would be able to eventually come back into Peer. Thus, a network outage at the Log transfer network would not result in a failure to process transactions, as seen by clients.

An alternative to HACMP is Tivoli System Automation (TSA). TSA is now bundled with DB2 for AIX (as of DB2 ESE 8.2 FP 13) in the same manner, and same licensing terms, as Linux (TSA bundled with DB2 ESE 8.2 on Linux). All HACMP or TSA has to do is detect a node

50 IBM WebSphere Portal V6 Self Help Guide

failure and issue the TAKEOVER HADR command. There is no requirement to configure it to do any disk takeover, IP address takeover, or anything else, so the configuration is straightforward. When it detects that the Primary has failed, HACMP or TSA will run the TAKEOVER HADR ON DATABASE prod BY FORCE command, which will cause the Standby to become the Primary. Client requests are automatically redirected to the new Primary server using the Automatic Client Reroute (ACR) capability in the DB2 Client.

The real difference between instance failover and HADR failover is the time taken to be back up and running after a failure. With HADR, this can be under 30 seconds, but with HACMP instance failover, this is typically around one to two minutes.

Data redundancy is an additional benefit of deploying HADR when compared to HACMP instance failover alone. If the primary storage fails in a HADR configuration, failover can occur to the redundant storage. In the case of just HACMP, loss of the shared storage means catastrophic failure, with the only course of action being the restoration from a previous backup. Any incremental data will be lost.

2.8 Portal planning recommendations

As acknowledged at the beginning of this chapter, WebSphere Portal Server architectures come in many shapes and forms. A common requirement of any implementation, therefore, is the amount of attention and detail given to adequately planning such a project. Indeed, in order to minimize implementation risk, good planning is essential; failing to plan is planning to fail.

2.8.1 Recommendations for a successful implementation

We strongly recommend that a WebSphere Portal Server based implemention is treated as a complex infrastructure project from the outset. For anything other than an out-of-the-box implementation, which only encompasses laying down the core WebSphere Portal Server runtime, the complexity and length of time a project will need will grow significantly as more products or integration points are introduced. For example, an architecture incorporating an External Security Manager, such as Tivoli Access Manager, will demand extra resources with the appropriate skill set and additional time to both plan and implement.

In large WebSphere Portal Server solution projects, as with any other large scale based projects, it is crucial to have proper project management and governance mechanisms in place. Beside the large amount of work that is caused by the various workstreams, the demands in managing such undertakings are increased dramatically.

Assemble a multidisciplinary team

It takes a multidisciplinary team to successfully deploy a large scale WebSphere Portal Server implementation. As such, the two most important leaders on a delivery project are the Solution Architect and Project Manager. It should further be recognized that while the Solution Architect remains ultimately responsible for the overall solution design, it is possible that there are other architects under his or her command. For example, it is not uncommon that there is an architect assigned to each of the following categories: application, enterprise, integration, information, infrastructure, and operations.

Adoption of a methodology, pattern, or reference architecture

Although not mandated by any means, the adoption of a methodology, pattern, or reference architecture is strongly recommended when setting out on a WebSphere Portal Server

Chapter 2. Architecture and planning 51

project. For a complete listing of available patterns, consult the IBM Patterns for e-business Web site at:

http://www.ibm.com/developerworks/patterns

Adopt the Portal Build & Validate Methodology

In establishing a Portal Build & Validate Methodology, we acknowledge that there are key milestones associated with any Portal deployment. Adopting such a methodology thus reduces the likelihood that an incorrectly installed component will go undetected, until such a time that a significant Portal failure results. Our experience tells that among the most common causes of Portal deployment failures is the adoption of a big-bang approach. By contrast, the Portal Build & Validate Methodology breaks down the Portal deployment into discrete steps, each requiring validation. Failure to do so often results in ripping apart the solution, in an attempt to eliminate the various components of the architecture until the culprit is found.

Distinguish between COTS packages and proprietary code

With the availability of Commercially-Off-The-Shelf (COTS) packages, such as WebSphere Portal Server and Portlet applications that deliver specific functionality, the duration of a Portal implementation has been greatly reduced. However, it is important to recognize when custom development is needed, as in our experience Project Managers have not always been able to distinguish between COTS and custom developed applications.

Address performance as early as possible

Performance should be addressed as early on in a project as possible and then as an ongoing concern. All too often performance is disregarded until the performance tuning phase of a project, resulting in a critical situation. Consider performance testing those back-end systems prior to starting WebSphere Portal Server performance testing, as it is acknowledged that WebSphere Portal Server can never improve on the performance of any back-end system. Due to the iterative nature of performance tuning, no less than one month should be set aside for this important phase of any project.

Important: Performance testing requires dedicated hardware and software. The expectation that performance testing can be performed using employee mobile computers or desktops is a serious misjudgment.

Include provisions for when things go wrong

On a regular basis, project teams neglect to make any provision for when things go wrong. A well thought out project plan includes such a provision. After all, it is far better to complete a deployment before the target date than to keep shifting the go-live target date. Plan on increasing any time set aside for this important facet of any project, when the level of complexity and the number of integrated systems increases.

Adopt a proper build mechanism

During the course of an implementation, there will be many versions of the components developed and deployed. As such, versioning is required when code and artifacts are promoted between the various environments of an implementation. For those deployments implementing a dual clustered architecture, with “Two Lines of Production”, it is especially important to have a proper build and deployment mechanism in place. This is to ensure that each line of production is identical, albeit when both lines of production are operational and not undergoing any incremental upgrade.

52 IBM WebSphere Portal V6 Self Help Guide

Deployment and cutover plan

Deployment can impose a great deal of change and stress for any organization. Therefore, ensuring a smooth deployment is a key factor in satisfying any stakeholder. A deployment and cutover plan, as such, should minimize the impact of the cutover with the stakeholder's staff, existing production systems and overall business routine. Creating a good deployment plan helps to identify most of the issues, vulnerabilities, and unforeseen glitches.

Chapter 2. Architecture and planning 53

54 IBM WebSphere Portal V6 Self Help Guide

Chapter 3. WebSphere Portal installation

This chapter contains information that will guide you through the installation of your WebSphere Portal Server. This chapter includes the following topics:

򐂰 Installation

򐂰 Database Transfer

򐂰 Enable Security

򐂰 Problem Determination

3.1 Installation

There is a great deal of information contained in this chapter so in an effort to prevent you from feeling overwhelmed, we recommend that you review the content that most relates to your environment.

3.1.1 How do I prepare my system for installation

This section highlights the minimum product levels that need to be installed before opening a problem report with the WebSphere Portal Support team. Because other products frequently ship fixes, updates, and new releases, testing every configuration is not possible. In general, you can install and run updates to supported products if those updates are forward compatible and are covered by the generic support statement found at:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wpf/i nst_req_supt.html

The list below identifies the supported products that work with the WebSphere Portal on the various operating systems. The supported product can run, but does not need to run, on the same machine or operating system where the WebSphere Portal runs. Check product-specific software requirements to determine whether the software runs native or connected to the WebSphere Portal.

Supported hardware and software

򐂰 WebSphere Portal V6.0 software requirements:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/inst_req60.html

򐂰 WebSphere Portal V6.0.0.1 software requirements:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/inst_req6001.html

򐂰 WebSphere Portal V6.0.1 software requirements:

http://www-1.ibm.com/support/docview.wss?rs=688&uid=swg27009608

򐂰 WebSphere Portal V6.0.1.1 software requirements:

http://www-1.ibm.com/support/docview.wss?rs=688&context=SSHRKX&context=SSBRWT&c ontext=SSQKRQ&context=SS3NNG&context=SSYJ99&context=SSRUWN&context=SS6JVW&q1=so ftware+requirements&uid=swg27010005&loc=en_US&cs=utf-8&lang=en

Prepare the operating system

This section includes information for setting up your operating system for WebSphere Portal with Cloudscape. Other components might require additional steps; see the product documentation for the specific components you want to install for information.

򐂰 Preparing an AIX machine:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/os_aix.html

򐂰 Preparing an HP-UX machine:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/os_hpux.html

56 IBM WebSphere Portal V6 Self Help Guide

򐂰 Preparing a Linux machine:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/os_linux.html

򐂰 Preparing a Solaris machine:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/os_solaris.html

򐂰 Preparing a Windows® machine:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/os_win.html

򐂰 Preparing a System i5™ machine:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/is_os_iseries.html

3.1.2 What is about to happen

The installation program provides a layered approach to building your environment by initially allowing you to start with WebSphere Portal as the base and then incrementally add other components.

Methods to install/uninstall

The following three methods are available to install or uninstall WebSphere Portal:

򐂰 Graphical User Interface (Installation Wizard):

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/conf_gui.html

򐂰 Console Interface:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/conf_console.html

򐂰 Response File:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/conf_response.html

Installation types

This section describes the different installation options for WebSphere Portal from the Quick installation scenario that gets WebSphere Portal up and running quickly with a completely integrated IBM Cloudscape database to the advanced installation scenarios that address special situations that might arise in your environment.

Stand-alone server

The most basic installation scenario is to install WebSphere Portal as a stand-alone server along with the WebSphere Application Server. If you currently do not have an existing WebSphere Application Server installed on your system, then this is the scenario you want to pursue. The typical installation sequence that occurs behind the scenes, which is traced in the wpsinstall.log, is as follows:

򐂰 Validation

– Detects any currently installed versions of WebSphere Application Server.

– Checks for the space requirements for WebSphere Application Server, Process Server,

and for IHS (Web server).

Chapter 3. WebSphere Portal installation 57

– Validates the operating system.

򐂰 Installs WebSphere Application Server base.

򐂰 WebSphere Application Server base is upgraded to V6.0.2.9.

򐂰 WebSphere Application Server fixes installed:

http://www-1.ibm.com/support/docview.wss?rs=688&context=SSHRKX&context=SSBRWT&c ontext=SSQKRQ&context=SS3NNG&context=SSYJ99&context=SSRUWN&context=SS6JVW&q1=Re quired+interim+fixes+for+WebSphere+Application+Server&uid=swg21245283&loc=en_US &cs=utf-8&lang=en

򐂰 Profile creation.

򐂰 WebSphere Portal Installation.

򐂰 Enable WebSphere Application Server Security.

򐂰 Configure BPE.

򐂰 Stop and start the WebSphere Portal Server.

For an in-depth analysis of the wpsinstall.log and for troubleshooting of the installation program, refer to Chapter 8, “Problem Determination”, in the WebSphere Portal Version 6 Enterprise Scale Deployment Best Practices, SG24-7387:

http://www.redbooks.ibm.com/abstracts/sg247387.html

Custom

A more custom type of installation is to install a new version of WebSphere Portal Server on an existing instance of WebSphere Application Server.

Once you launch the install program, you will select the Custom install radio button.

The installer will detect if you have one or more existing WebSphere Application Server instances installed and display them by the location. You must select the instance that you want to use from the list.

Tip: If the installation program does not detect a WebSphere Application Server instance, but you know that it is present on the machine, exit the install and pass the location using the command line:

./install.sh -W was.undetectedWas="/my/WAS/location/"

Ensure the Install on a managed node option is checked when you are installing to a node that is already under deployment manager control. Also, you should already have a profile created if pursuing this installation option; however, if you do not, then you will need to specify all the WebSphere Application Server information in order for the install program to create the profile at this time.

58 IBM WebSphere Portal V6 Self Help Guide

The key difference between the custom installation scenario and the typical install is seen during the validation phase when the currently installed WebSphere Application Server version is detected and a check is done to see if any WebSphere Application Server instance was installed with Portal, as shown in Figure 3-1 on page 61.

Example 3-1 Custom Install trace output

(Jul 30, 2007 5:32:44 PM), MultiPlatform.install, com.ibm.wps.install.WasSelectPanel, msg2, Number of currently installed WAS:1 (Jul 30, 2007 5:32:44 PM), MultiPlatform.install, com.ibm.wps.install.WasSelectPanel, msg2, installed WAS 0: {Location=C:\IBM\WebSphere\AppServer, Version=6.0.2.19.0} (Jul 30, 2007 5:32:48 PM), MultiPlatform.install, com.ibm.wps.install.WasSelectPanel, msg1, WAS validation result for C:/IBM/WebSphere/AppServer: true (Jul 30, 2007 5:32:48 PM), MultiPlatform.install, com.ibm.wps.install.SetUserInputPanelPropertyAction, msg2, Attempting to set user input panel bean 'was' property 'location' to 'C:\IBM\WebSphere\AppServer' (Jul 30, 2007 5:32:48 PM), MultiPlatform.install, com.ibm.wps.install.SetUserInputPanelPropertyAction, msg2, Setting bean property successful (Jul 30, 2007 5:32:48 PM), MultiPlatform.install, com.ibm.wps.install.DetectWpsAction, msg2, WAS Location: C:\IBM\WebSphere\AppServer (Jul 30, 2007 5:32:48 PM), MultiPlatform.install, com.ibm.wps.install.DetectWpsAction, msg2, Number of currently installed WPS:0

(Jul 30, 2007 5:32:48 PM), MultiPlatform.install, com.ibm.wps.install.DetectWpsAction, msg2, No WAS with WPS detected

After the system completes validation, the installer proceeds with the WebSphere Application Server profile creation, the WebSphere Portal Installation, and the enable security configuration task.

For more information regarding the step by step procedure for the custom installation scenario, refer to the WebSphere Portal Information Center topic “Installing with an existing instance of WebSphere Application Server”, found at:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wpf/i nst_wp_exwas.html

Co-existence installation

The co-existence installation scenario allows you to install more than one copy of WebSphere Portal on the same machine, where each server operates independently of the others. Each copy of WebSphere Portal is installed on a separate WebSphere Application Server profile and since all copies share the same system resources, such as processor capacity and memory, the multiple copies will impact performance.

When installing co-existing WebSphere Portal servers, you have the option to install each copy of WebSphere Portal with a new copy of WebSphere Application Server, as outlined in “Stand-alone server” on page 57, or to install each copy of WebSphere Portal on an existing version of WebSphere Portal, as in “Custom” on page 58.

Note: In order to avoid port conflicts with this installation scenario, you need to review the configuration methods outlined in the Information Center:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wp f/inst_ports.html

Chapter 3. WebSphere Portal installation 59

Empty install

The empty portal installation scenario installs WebSphere Portal without the installation and deployment of default portlets and without the pages that are normally created with the typical and custom installation scenarios.

The empty portal installation is most often used when a transfer of the entire configuration, for example, from test environment to production environment is required.The XML configuration interface will allow you to export content from a test environment, for example, and import the content into a production environment.

The key point to remember in the empty portal installation is that the install program actually does removal of all WebSphere Portal resources, as noted in Example 3-2.

Example 3-2 Empty Portal Install trace output

(Jul 31, 2007 3:39:45 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction, msg2, Beginning install step: Removing all Portal resources (Jul 31, 2007 3:39:45 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction, msg2, Executing command: cmd /c ""C:\IBM\WebSphere\PortalServer\config\WPSconfig.bat" action-empty-portal -DPortalAdminPwd=PASSWORD_REMOVED -DWasPassword=PASSWORD_REMOVED

-DLTPAPassword=PASSWORD_REMOVED -DskipWTP=true" (Jul 31, 2007 3:39:45 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction, msg2, Working directory:

Upon completion of this task, you need to confirm the task completes with a BUILD SUCESSFUL message, as noted in Example 3-3.

Example 3-3 Empty Portal Install trace output

BUILD SUCCESSFUL (Jul 31, 2007 3:47:07 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction$OutputWatcher, msg2, StdOut: Total time: 7 minutes 12 seconds (Jul 31, 2007 3:47:08 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction, msg2, Return code = 0 (Jul 31, 2007 3:47:08 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction, msg2, Executing command: completed (Jul 31, 2007 3:47:08 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction, msg2, Completed install step: Removing all Portal resources

Attention: After installing an empty portal, expect messages indicating that no content can be displayed or that some components are not yet configured. Adding content into the portal will prevent these messages from rendering.

Figure 3-1 on page 61 shows what the user should see when accessing the Portal Server directly after completing an empty portal installation scenario.

60 IBM WebSphere Portal V6 Self Help Guide

Figure 3-1 Empty Portal default page

Attention: IBM is no longer supporting the "action-empty-portal" to clean out the Portal system and build it up from there since this has resulted in too many unresolveable issues. This procedure goes outside of what "action-empty-portal" was intended for, so the "action-empty-portal" task is only to be used when preparing to import another Portal configuration. It is not to be used to clean out a Portal server for performance reasons or anything of that nature.

If you are attempting to improve Portal startup performance, you may try to stop applications that are not needed. Another area where startup performance (and memory usage) could be saved is to disable applications that may not be needed in your environment, such as Composite Applications and Templates (also known as "CAI/TAI") and Workplace Web Content Management™ (WCM). Some of the possible applications to stop are:

򐂰 ServletInvoker.war 򐂰 pickerPortlet.war 򐂰 JspServer.war 򐂰 mylist.war 򐂰 QuickLinks.war 򐂰 newsgroup.war 򐂰 docviewer.war 򐂰 FileServer.war 򐂰 reminder.war 򐂰 worldclock.war

Chapter 3. WebSphere Portal installation 61

򐂰 Bookmarks.war 򐂰 xslt.war 򐂰 sql.war 򐂰 CPPMail.war 򐂰 bannerad.war 򐂰 csv.war 򐂰 domdoc.war 򐂰 Exchange3.war 򐂰 MarketWatch.war 򐂰 WelcomePortlet.war 򐂰 Blurb.war 򐂰 SpellCheckerService.war 򐂰 LotusDocViewer.war 򐂰 Exchange2003.war 򐂰 QuickplaceInline.war 򐂰 LWP_CAI 򐂰 LWP_TAI 򐂰 content_j2ee 򐂰 dmdesktop 򐂰 icmjcrear 򐂰 ilwwcm_wcmsearchseed 򐂰 wcm

3.1.3 Where do I begin

Before you can begin the installation, you must choose the installation source that best fits your environment.

Installation source

The installation media for WebSphere Portal is distributed in two ways:

1. Electronically in the form of download images

2. Physically in the form of media CDs

Using discs to perform the installation is recommended if you have the CDs and plan on performing a limited number of installations, as little setup is required.

As an alternative to using discs, you can download WebSphere Portal software images onto a workstation or networked drive and then use those images to install the software. The primary delivery mechanism for retrieving the files necessary to install WebSphere Portal and its supporting software are the electronic Service Delivery (eSD) sites. These sites include Passport Advantage® and Partner World, which are linked directly to the IBM Customer Entitlement systems so visitors to the site will only see what they have purchased and are entitled to see. The files on the eSD site are arranged together in solution purchased by customers by platform. The term e-Assembly or e-Assy refers to a compilation of software images. Use one of these phrases to locate all the images that are packaged with the WebSphere Portal offering that you want to download. You can also search the software site for the part number of the product you wish to install rather then the e-Assembly. The part number can also be found in the TechNote mentioned in this section, for example, WebSphere Portal V6.0 - WebSphere Portal Enable Linux on x86, V6.0 eAssembly (CR45KML).

e-Assemblies reflecting the

This is one of the choices that downloads the WebSphere Portal Enable V6.0 image for the Linux OS. If you are a customer using Passport Advantage to download images from the Web, or if you have access to the appropriate IBM internal software through Business Partner

62 IBM WebSphere Portal V6 Self Help Guide

download sites, then refer to the WebSphere Portal V6.0 components outlined in this document:

http://www-1.ibm.com/support/docview.wss?rs=688&uid=swg24012969

Now that you have the appropriate e-Assembly or e-Assy image name, perform the following steps to locate images for download:

򐂰 Access the search mechanism on the Web site that you use to download software images.

– IBM Passport Advantage:

http://www.ibm.com/software/howtobuy/passportadvantage/pao_customers.htm

– IBM Passport Advantage - Direct Link To Customer Login:

https://www.ibm.com/software/howtobuy/passportadvantage/paocustomer

򐂰 Type the e-Assembly or e-Assy to locate the offering.

򐂰 View and accept the license terms.

򐂰 Select the correct images from the list of downloadable images that are displayed.

For steps on how to properly extract the CD images, refer to the "Choosing an installation source" topic in the WebSphere Portal Information Center, found at:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wpf/i nst_source.html

3.1.4 Is it working

In order to ensure a successful installation of WebSphere Portal, we recommend that the following steps are verified.

Accessing the WebSphere Portal URL

First, you will need to open a browser and access the Portal Server with the following URL:

http://example.com:port_number/wps/portal

where example.com is the fully qualified host name of the machine that is running WebSphere Portal and port_number is the port number that is displayed on the confirmation panel. For example:

http://www.ibm.com:10038/wps/portal

Logging into WebSphere Portal

Perform the following instructions for logging in to your portal:

򐂰 Click the Log In button in the banner (upper right hand corner).

򐂰 Type the administrator user ID and password in the appropriate fields since this is your first

time logging into the WebSphere Portal Server after installation and additional users have not been created.

Note: Users must sign up to receive a user ID and password to log in to the portal.

򐂰 Click Log in to continue, or click Cancel to return to the default portal page.

Chapter 3. WebSphere Portal installation 63

For more information about Self Registration of users, refer to the WebSphere Portal Information Center section titled “Signing up to the Portal” and “Adding new Users” located at:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wps/s ign_up.html

wpsinstall.log

You will need to open the <wp_root>/log/wpsinstall.log and check for the following trace output, which confirms that the install and starting of WebSphere Portal has completed with no outstanding errors, as shown in Example 3-4

Example 3-4 wpsinstall.log trace output

(Jul 30, 2007 6:11:03 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction$OutputWatcher,

msg2, StdOut: BUILD SUCCESSFUL

(Jul 30, 2007 6:11:03 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction$OutputWatcher, msg2, StdOut: Total time: 2 minutes 55 seconds (Jul 30, 2007 6:11:04 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction, msg2, Return code = 0 (Jul 30, 2007 6:11:04 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction, msg2, Executing command: completed (Jul 30, 2007 6:11:04 PM), MultiPlatform.install, com.ibm.wps.install.ExternalCommandAction, msg2, Completed install step: Starting WebSphere Portal

ConfigTrace.log

Most commonly, the installation failures result from the configuration tasks that are executed during installation. The <wp_root>/log/ConfigTrace.log contains the generated trace output for each configuration task that executed during installation, so you will need to open this file and check for the output, as shown in Example 3-5.

Example 3-5 ConfigTrace.log trace output

start-portal-server: [logmsg] 2007.07.30 18:08:14.609 start-portal-server [logmsg] EJPCA3163I: Starting Server "WebSphere_Portal"

[echo] 'WebSphere_Portal' seems to be stopped. [echo] Starting 'WebSphere_Portal' [exec] ADMU0116I: Tool information is being logged in file [exec] C:\ibm\WebSphere\profiles\wp_profile\logs\WebSphere_Portal\startServer.log [exec] ADMU0128I: Starting tool with the wp_profile profile [exec] ADMU3100I: Reading configuration for server: WebSphere_Portal [exec] ADMU3200I: Server launched. Waiting for initialization status. [exec] ADMU3000I: Server WebSphere_Portal open for e-business; process id is 2228 Target finished: start-portal-server Mon Jul 30 18:11:03 EDT 2007 Target started: action-post-config action-post-config: [delete] Deleting: C:\IBM\WEBSPH~1\PORTAL~1\config\work\was\wp_portal.properties [delete] Deleting: C:\IBM\WEBSPH~1\PORTAL~1\config\wpconfig_ascii.properties Target finished: action-post-config---- Begin dump of properties ---* listing of all properties are seen in this section *

---- End dump of properties ---BUILD SUCCESSFUL

64 IBM WebSphere Portal V6 Self Help Guide

SystemOut.log

The loading of WebSphere Portal begins with the trace output, as shown in Example 3-6.

Example 3-6 SystemOut.log trace output

[7/30/07 18:09:03:781 EDT] 00000016 WebGroup A SRVE0169I: Loading Web Module: WebSphere Portal

Server.

[7/30/07 18:09:04:219 EDT] 00000016 WebApp A SRVE0180I: [WebSphere Portal Server] [/wps] [Servlet.LOG]: ServiceManager: Loading from file:/C:/IBM/WebSphere/PortalServer/shared/app/config/services.properties [7/30/07 18:09:04:266 EDT] 00000016 LogManagerDef I com.ibm.wps.logging.LogManagerDefaultImpl init

-------------------------------------------------------------------------------IBM WebSphere Portal 6.0

Licensed Materials - Property of IBM 5724-E76 and 5724-E77 (C) Copyright IBM Corp. 2001, 2006 - All Rights Reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP

Schedule Contract with IBM Corp.

-------------------------------------------------------------------------------Build Level:

wp600_244 (2006-07-18 17:02)

-------------------------------------------------------------------------------which follows with the confirmtaion that WebSphere Portal has been initialized : [7/30/07 18:09:33:578 EDT] 00000016 ServletWrappe A SRVE0242I: [wps] [/wps] [portal]: Initialization successful.

The remaining lines of output will indicate the loading and initialization of all the WebSphere Portal applications. You will need to verify that the applications are loaded and initialized with no errors. Directly after this information, you should see the “Server WebSphere_Portal open for e-business”, which confirms your WebSphere Portal Server is now up and running.

3.2 Database transfer

By default, WebSphere Portal Server automatically installs and stores its predefined data in the IBM Cloudscape Database, as shown in Figure 3-2. While the IBM Cloudscape Database may be the suitable choice in small scale deployments, organizations looking to leverage the enterprise-wide capacity attributes of a database management system should continue with the following sections.

Installation

Database

Transfer

Figure 3-2 Database transfer

Chapter 3. WebSphere Portal installation 65

3.2.1 Planning and considerations

WebSphere Portal V6 provides new options to address scalability and redundancy in your enterprise deployments. If you choose to transfer to an external database, we recommend that you do so before you add a large amount of content and preferably during the installation and configuration process. Figure 3-3 shows some points to consider before you transfer you data to a database of enterprise scale.

Cloudscape

Action Set 1Admin @ Content Node

Action Set 2User @ MyPortal

Feedback

Resource 1abc

Resource 3Resource1

Resource 3Resource1 Resource 2..

Resource 2..

Resource 3Resource 2

Resource 3Resource 2 Resource x..

Resource x..

....

Weak References

Resource yResource x

Referential IntegrityReferential Integrity

DB Schema

valueResource1

valueResource 2

....

valueResource x

Portal

Portlets Content Nodes Templates

Wps.content.root

Applications

Wps.content.root

Applications

My Portal

…..

My Portal

…..

Action Set 1Admin @ C o nt ent N od e

Resource

Action Set 2User @ MyPortal

prod.

Resource

Resource 2

JCR Domain

Resource 1abc

Resource 3Reso urce 1

Resource 3Reso urce 1 Resource 2..

Resource 2..

Resource 3Reso urce 2

Resource 3Reso urce 2 Resource x..

Resource x..

....

Weak Referenc es

Resource yReso urce x

Referential IntegrityReferential Integrity

LikeMinds

DB Schema

Resource

prod

Resource 3

valueResource1

valueResource 2

....

valueResource x

Weak Reference s

DB Schema

Action Set 1Admin @ Content Node

Action Set 2User @ MyPortal

valueResource1

valueResource1 Resource 1abc

Resource 1abc

Resource 3Resource1

valueResource 2

valueResource 2 Resource 2..

Resource 2..

Resource 3Resource 2

....

Resource x..

....

valueResource x

Resource yResource x

Referential IntegrityReferential Integrity

Customization Domain

Portal

Portlets Content Nod es Templates

Wps.content.root

Applications

Wps.content.root

Applications

My Portal

…..

My Portal

…..

Action Set 1Admin @ Content Node

Resource

Action Set 2User @ MyPortal

prod.

Release Domain

prod.

Resource

Resource 2

Resource 1abc

Resource 3Resource1

Resource 3Resource1 Resource 2..

Resource 2..

Resource 3Resource 2

Resource 3Resource 2 Resource x..

Resource x..

....

Weak Refere nc es

Resource yResource x

Referential IntegrityReferential Integrity

Portal

Portlets Co nt e nt No d e s Templates

Schema

Wps.content.root

Applications

Wps.content.root

Applications

Resource

My Portal

…..

My Portal

…..

Action Set 1Admi n @ C o ntent N o de

Resource

Action Set 2User @ My Po rtal

prod

Resourc e 3

prod.

Resource

Resource 2

valueRe so urc e1

valueRe so urc e1 Resource 1abc

Resource 1abc

Resource 3Resource1

valueRe sou rce 2

valueRe sou rce 2 Resource 2..

Resource 2..

Resource 3Resource 2

....

Resource x..

....

valueRe sou rce x

Weak Refere nc es

Resource yResource x

Referential IntegrityReferential Integrity

DB Schema

Resource

prod

Resource 3

valueResource1

valueResource 2

....

valueResource x

Release Customization

Database Domains

JCR Community

Figure 3-3 Transferring to an external database

Audit of your database infrastructure

The database is typically the heart of any Web-based application. For the success of your deployment, it is critical that the hardware and software that will be used to house the portal database(s) be not only highly optimized but resilient. Before you begin the database transfer process, review the prerequisites discussed below.

System requirements

It is important to conduct a preliminary review of the hardware and software of your system in both the new and existing database infrastructures to ensure they meet the supported levels for WebSphere Portal Server. The InfoCenter is routinely updated with specific versions and recommended compatible levels of configuration. If your are considering an upgrade to your database implementation, we advise you to refer to 3.1.1, “How do I prepare my system for installation” on page 56

Performance and availability

WebSphere Portal Server provides you with the option of installing the database server on the same server that the WebSphere Portal Server will be housed; however, if performance is of utmost importance for your portal application(s), we recommend that you provide a separate physical database server for your RDBMS. Performance tools should be utilized continuously to monitor the state of the database server(s) and the databases themselves, with mechanisms instituted to tune the entities as needed.

For additional information about planning for your database infrastructure, refer to 2.7, “Database considerations” on page 46.

66 IBM WebSphere Portal V6 Self Help Guide

before attempting an upgrade of your environment.

Database domains

With WebSphere Portal Server V6, the content repository has been separated into database domains. The separation of domains increases the flexibility for organizations by permitting:

򐂰 Single instances of WebSphere Portal Server to share portal data without clustering.

򐂰 Sharing of portal data among portal clusters allowing for multiple lines of production,

allowing organizations to comply with high availability requirements.

򐂰 Partition of portal data not just among database management systems, but database

software types (that is, DB2 and Oracle)

Note: Release, LikeMinds, and Feedback Data cannot be shared between databases. The Sync and Designer Databases are supposed to stay on Cloudscape and therefore are not part of the database transfer process.

While you have the liberty in WebSphere Portal Server V5.1 to create all portal data under one database for performance, availability, and scalability purposes, we recommend that you create separate physical databases for each of your database domains.

Authorization

WebSphere Portal Server does not require an ID with plenipotentiary authority on the server(s) that will house your external portal database(s). For the purposes of system to system communication, we recommend that you create a user on your database servers and assign to the group those user who have been granted DBADM authority (or its equivalent) in your database management system.

3.2.2 How do I prepare for the database transfer

To prepare for the transfer of your database(s) from Cloudscape to an external database, you should execute the following steps:

1. If you have not done so already, the first thing you should do before attempting to transfer your portal data is to make a file system level backup of the portal server(s) you have installed up to this point.

2. After the file system backup has completed, make a secondary backup of your wpconfig.properties, wpconfig_dbdomain.properties, and wpconfig_dbtype.properties files located in your WP_root/config directory. These files will be modified for the database transfer process, so it is good to have a secondary backup readily available without having to have the files restored.

Note: You should always create a backup of files at each step of the installation process and at any point in time when the files will need to be modified.

3. Whether your database management system is installed locally (on the same system as WebSphere Portal Server) or remote, the installation and configuration of your database server (s) should be complete and your database servers should be tuned for optimal performance, as noted in 3.2.1, “Planning and considerations” on page 66. The database admin ID that WebSphere Portal Server will use to access data should be created and assigned to the appropriate database administrative group.

Chapter 3. WebSphere Portal installation 67

4. If you are connecting to an external database remotely, create the database(s) you plan to utilize as instructed in the InfoCenter instructions. Users of DB2 have the convenience of having WebSphere Portal Server create the databases locally by running ./WPSconfig.sh/WPSconfig.bat create-local-database-db2 from the command line.

5. WebSphere Portal Server V6 allows for the use of the Type 4 JDBC™ driver for all supported databases, eliminating the need to install a local database client on the WebSphere Portal Server for those distributed environments. Before you begin the database transfer process, copy the required Type 4 jar file(s) for your database management system server over to your WebSphere Portal Server(s). Should you choose to have the local client installed for remote connection (required for supported platforms in which will use the Type 2 JDBC driver), you should install the database client on all WebSphere Portal Servers beforehand. Catalog the databases on the WebSphere Portal machine. Note that this is not required for those environments in which the database server will be installed locally. For more information about driver support, refer to “Supported hardware and software” on page 56.

6. For most platforms, you have the option of transferring the database manually using the command line, or transferring the database using the configuration wizard. Regardless of the process you choose, you will need to modify the wpconfig_dbdomain.properties, wpconfig_dbtype.properties, and wpconfig.properties with the values required in order to perform the database transfer, as both methods will pull the information from these files. Do not provide values for other parameters in the properties files other than those specified in the InfoCenter instructions.

Note: If you are planning to use the optional LookAside feature in your portal implementation, do not set this value during the database transfer process. This value is set as a part of enabling security.

7. Verify the database connections from WebSphere Portal Server to your database(s) by running the validate database connection configuration tasks for the individual domains you will be transferring to your external database. If you receive failures, do not continue with the additional steps until the tasks run successfully.

8. Check the InfoCenter to re-confirm that you have followed all instructions for your Database Management system, including any system requirements or other modifications necessary for your database management system. You can access the InfoCenter at:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp

9. Using support tools effective method of problem avoidance. By utilizing a tool such as IBM Support Assistant you can perform a search for “database transfer with WebSphere Portal Version 6” and review all TechNotes surrounding this topic. Refer to Appendix A, “Using IBM tools to find solutions and promote customer self-help” on page 169 for more information.

10.Stop WebSphere Portal Server if it is running. In a clustered environment, Deployment Manager and

Table 3-1 on page 69 gives you a checklist of all the required items for the database transfers preparation.

before you run installation and configuration tasks are another

all node agents should be running and synchronized.

68 IBM WebSphere Portal V6 Self Help Guide

Table 3-1 Database Transfer Preparation Checklist

Step Task Completed

1 Install, configure, and tune your database management system.

2 Assign an ID or privilege that will be used by WebSphere Portal Server(s)

for system to system communications from the portal to the database.

3 Create the WebSphere Portal database(s) on the database server.

4 If you are using the Type 4 JDBC driver, copy the required files from your

database server to your WebSphere Portal Server(s).

5 If you are using the Type 2 JDBC driver, install the database client on the

WebSphere Portal Server(s).

6 Make a file system backup of WebSphere Portal Server.

7 Make a secondary backup of wpconfig_properties,

wpconfig_dbdomain.properties, and wpconfig_dbtype.properties.

8 Enter database values in wpconfig.properties,

wpconfig_dbdomain.properties, and wpconfig_dbtype.properties.

9 Validate the database configuration by running the Validate database

connection tasks.

10 Check the InfoCenter to reconfirm that you have met all the prerequisites

for hardware, software, and configuration for your database server and client.

11 Problem Avoidance: Use the IBM Support Assistant to perform a search on

“database transfer and WebSphere Portal V6” to review all TechNotes and solutions associated with this task.



12 Stop all WebSphere Portal Server(s): In a clustered environment, verify the

Deployment Manager is started and all node agents are running and synchronized.

3.2.3 What is about to happen

We recommend that you perform the database transfer before you use WebSphere Portal extensively if you choose to transfer data to another supported database, since large amounts of data in the databases can cause the database transfer to fail if your Java heap size is not large enough. Since data is added to the database as you use WebSphere Portal, you should perform the database transfer as soon as it is practical to do so to avoid problems due to the amount of data you are transferring.

You can transfer data from any supported database type to any other supported database type, which means the source database does not have to be the default database that is created during installation. In order to transfer data between supported databases, you must edit the wpconfig_sourceDb.properties file and update it with the source databases’ information. This file is a copy of wpconfig_dbdomain.properties that is created automatically during installation.



Chapter 3. WebSphere Portal installation 69

Attention: Data can be transferred from a Cloudscape database, but cannot be transferred to a Cloudscape database, so if you are transferring from a database other than the default database, you will need to edit the wpconfig_sourceDb.properties file. This file is a copy of the wpconfig_dbdomain.properties file, so the default values will be for Cloudscape if it is not modified.

If you want to transfer your data to another supported database, you will need to follow the steps specific to the type of database you are using, for example, DB2, Oracle, or SQL Server™. By this point, you should have planned for the database you wish to use, installed the database for use with WebSphere Portal, and set up the database to work with WebSphere Portal that is, creating users and creating local or remote databases. Once these steps have been followed (per 3.2.2, “How do I prepare for the database transfer” on page 67), you should be ready to transfer the data.

You may choose to transfer data manually or by using the configuration wizard and you may transfer all the data at once or by individual domains. When transferring data manually, you want to first validate the configuration properties with the following task:

򐂰 For UNIX:

./WPSconfig.sh validate-database-connection-wps -Drelease.DbPassword=password

-Dcustomization.DbPassword=password -Dcommunity.DbPassword=password

-Djcr.DbPassword=password ./WPSconfig.sh validate-database-connection-jcr -Djcr.DbPassword=password ./WPSconfig.sh validate-database-connection-feedback

-Dfeedback.DbPassword=password ./WPSconfig.sh validate-database-connection-likeminds

-Dlikeminds.DbPassword=password ./WPSconfig.sh validate-database-connection-wmm -Dwmm.DbPassword=password ./WPSconfig.sh validate-database-driver

򐂰 Windows:

WPSconfig.bat validate-database-connection-wps -Drelease.DbPassword=password

-Dcustomization.DbPassword=password -Dcommunity.DbPassword=password

-Djcr.DbPassword=password WPSconfig.bat validate-database-connection-jcr -Djcr.DbPassword=password WPSconfig.bat validate-database-connection-feedback

-Dfeedback.DbPassword=password WPSconfig.bat validate-database-connection-likeminds

-Dlikeminds.DbPassword=password WPSconfig.bat validate-database-connection-wmm -Dwmm.DbPassword=password WPSconfig.bat validate-database-driver

This task will begin by validating a connection with each domain by running a separate set of subtasks for each one. Once this task is complete, you will need to stop the WebSphere Portal server and server1 and, upon stopping the servers, you will be ready to run the database transfer command as follows:

򐂰 For UNIX:

./WPSconfig.sh database-transfer

-Drelease.DbPassword=password-Dcustomization.DbPassword=password

-Dcommunity.DbPassword=password -Djcr.DbPassword=password

-Dwmm.DbPassword=password -Dfeedback.DbPassword=password

-Dlikeminds.DbPassword=password

70 IBM WebSphere Portal V6 Self Help Guide

򐂰 For Windows:

WPSconfig.bat database-transfer -Drelease.DbPassword=password

-Dcustomization.DbPassword=password-Dcommunity.DbPassword=password

-Djcr.DbPassword=password -Dwmm.DbPassword=password

-Dfeedback.DbPassword=password -Dlikeminds.DbPassword=password

The task will prepare for the configuration by deleting the existing /work directory, creating it, and then copying the relevant files for each domain into the directory. The task will then attempt to stop the WebSphere Portal server and admin server in order to proceed with the copying of the database properties. The task then begins the transfer part by attempting to make a connection to each domain using the jdbc providers. Once the connections have been validated, the task will proceed with a series of SQL scripts that first do a drop of each table and then a create of each table. At this point, all the tables should be created and ready for the transfer of data, which is performed next. If you view the ConfigTrace.log, at this point you will see the Transfer started output followed by a series of Transferring table traces that indicate the transfer of data from the default source database tables to the new destination database tables. This process repeats a few more times for each domain.

After running this task, a message indicating success, BUILD SUCESSFUL, should result. You should check the log ConfigTrace.log file to verify that this task was successful. If the configuration fails, verify the values in the wpconfig.properties, wpconfig_dbdomain.properties, wpconfig_sourceDb.properties, and wpconfig_dbtype.properties files, since problems with the transfer result mostly from incorrect values in these property files. Once you have corrected the values, then you may repeat this step. If the problem you are facing is not related to incorrect values and you wish to troubleshoot the exceptions, then refer to 3.4, “Problem determination” on page 80 for additional guidance.

3.2.4 Is it working

In WebSphere Portal V5.1 or earlier, one of the ways to verify the database connectivity was to test the JDBC connections using the WebSphere Application Server console or through the WebSphere Deployment Manager in a clustered environment. Due to architectural changes in WebSphere Portal Server V6, you cannot test the data sources successfully through either console right after the database transfer process has completed. Attempting to test the connection will fail, but this is not an indication of a problem with the database transfer process itself or with your WebSphere Portal Server Installation.

Here are the steps to verify that the transfer of your portal data from Cloudscape to an external database is successful. For clustered environments, the verification steps should in it ally be performed on the primary node. If you encounter problems during any of the steps in the recommended validation process below, refer to 3.4, “Problem determination” on page 80.

1. After the database transfer completes, you should receive a BUILD SUCCESSFUL message indicating that the transfer process has now completed. Review the ConfigTrace.log located in WP_root/log for any errors.

2. Shut down your WebSphere Portal Server and back up the SystemErr.log and SystemOut.log files located in the WP_root/log directory. Once the logs have been backed up, delete the existing SystemErr.log and SystemOut.log files so that fresh log files are created when the server is started. For those in a clustered environment, verify that all your nodeagents are in sync through the Deployment Manager. Restart the WebSphere Portal Server (the primary node only for a clustered environment) and check the SystemErr.log and SystemOut.log files to verify you do not receive any errors upon startup.

Chapter 3. WebSphere Portal installation 71

3. Once WebSphere Portal Server is up and running and you have verified that there are no errors, open a Web browser and direct it to one of the following URL (depending on your deployment configuration):

– Single server deployment: http://hostname.example.com:10038/wps/portal – Cluster deployment: http://primarynode.example.com:9080/wps/portal

After that your are able to authenticate successfully, click the different links in the portal to make sure that no errors are received both in the browser and in the SystermErr.log and SystemOut.log files.

Note: Again, do not proceed any further if you have encountered errors during the database transfer process. If you are not able to determine the cause of the error, refer to

3.4, “Problem determination” on page 80 for tips on how to pinpoint the problem.

3.3 Enable security

Figure 3-4 shows the LDAP transfer’s part in the installation process.

Installation

Database

Transfer

LDAP

Transfer

Figure 3-4 LDAP transfer

In this section, we will discuss the steps needed to connect your portal environment using an LDAP registry. The discussion focuses on enabling portal security with realms and without realms. The sections below provide a subset of points of consideration for your LDAP infrastructure, and restrict its focus to considerations before running the enable security targets. For a discussion on external authentication solutions, such as Tivoli Access Manager or Computer Associates eTrust Siteminder, as well as other topics surround LDAP planning, refer to 2.6.7, “LDAP Directory Servers” on page 43.

3.3.1 Planning and considerations

A number of organizations use LDAP to manage authentication and authorization for business applications. WebSphere Portal Server allows administrators to configure connections to an existing LDAP. The following sections highlight some of the important considerations that require review before connecting a portal to an LDAP user repository.

Audit of your LDAP infrastructure

The LDAP infrastructure should be reviewed and assessed before you connect WebSphere Portal Server to it. Like the database, the performance of the LDAP is vital to the usability of your portal and poor LDAP performance can render your portal inoperable. In this section, we discuss some inspection points that should be made.

72 IBM WebSphere Portal V6 Self Help Guide

System requirements

It is important to conduct a preliminary review of your system hardware and software in both new and existing LDAP infrastructures to ensure that they meet the supported levels for WebSphere Portal Server. The InfoCenter is routinely updated with specific versions and recommended compatible levels of configuration, If you are considering an upgrade to your LDAP implementation, we advise you to refer to 3.1.1, “How do I prepare my system for installation” on page 56

before attempting an upgrade of your environment.

Performance and availability

WebSphere Portal Server provides you with the option of installing the LDAP server on the same server that WebSphere Portal Server will be housed; however, if performance is of utmost importance for your portal application(s), we recommend that you provide a separate physical server for your LDAP.

򐂰 High Availability: Single LDAP servers provide a single point of failure and therefore are

not a feasible option for deployment on an enterprise scale. For many environments, high availability is not a option or exception. The goal of high availability without performance impact are challenges organizations continue to face. High availability for the LDAP server is best achieved by having an LDAP proxy that will forward back-end requests. WebSphere Portal Server provides the option of configuring fail-over capability natively through the WebSphere Member Manager component. If you plan to configure WebSphere Portal Server for LDAP failover, you should enable security with realms and modify the wmm.xml as part of the post configuration steps in the InfoCenter. By default, the Reuse connection parameter should be enabled in the WebSphere Application Server console, or failover will not occur successfully should the primary server suffer an outage.

򐂰 LDAP Schema Design: While it is possible to set up WebSphere Portal Server with only

one user and one group, this is not advisable. The LDAP Schema Design and Directory Information Tree (DIT) should ideally be thoughtfully planned and agreed to by all stake holders in your organization before you even attempt installation, and certainly before this phase in your deployment. Improper design of your LDAP Schema can affect the lookup performance in your LDAP, which will directly affect your portal implementation.

򐂰 Read-Only LDAP: LDAP uses existing users in your registry, meaning the users and

groups will need to be created before they can access the portal. Authentication with read-only LDAP is performed using LDAP binding. Connection to a read-only LDAP WebSphere Portal Server requires an LDAP bind ID with the ability to read and search for the users in the subset of the DIT.

򐂰 LDAP that allow write permissions: Allows users to create and modify their personal

attributes in a directory. When write access is allowed, WebSphere Portal Server users can use such features as Self Registration and self-care to register accounts for themselves. Write privileges to the LDAP requires an LDAP bind ID to be created with the ability to write and search for the users in the subset of the DIT.

Note: In both instances, the LDAP Bind ID created for use with WebSphere Portal Server does not need to be the root ID for the directory server; in fact, it should not be.

LDAP Servers are oriented toward read-only operations and assume that information will be read from the LDAP server more than it is updated. Write operations will naturally be more expensive then read-only operations as a result and may require infrastructure changes to accommodate the cost. Review the documentation for your LDAP Server for discussion topics in this area.

Chapter 3. WebSphere Portal installation 73

򐂰 Filtering group information: The default filter information provided with your LDAP server is

very generic in nature and geared toward searching and entire directory. Custom filters should be used to drill down to the subset of users in the LDAP tree to reduce the number of LDAP calls and improve overall performance of your portal.

LDAP security options

򐂰 Enabling a WebSphere Portal Server connection to an LDAP registry with realms

Realms allow you to create group users from one or more LDAP Directory Information Trees and present them as a single entity to WebSphere Portal Server. Realms were introduced in WebSphere Portals Server Version 5.1, but support was limited to one registry. WebSphere Portal Sever V6 allows for the usage of multiple registries with realm enablement.

򐂰 Enabling WebSphere Portal Server connection to an LDAP Registry without realms

When you enable security without realm support, only one user registry can be created. If your user information is contained in one LDAP, then you have the option of enabling security without realm support. For scalability and flexibility purposes, we recommend that you enable security with realm support.

Note: At the time of the writing of this Redpaper, Web Content Management does not currently support WebSphere Portal Server environments with multiple realms. So you can either configure without realms or configure one realm in the WMM configuration files. Web Content Management is supported to use multiple registries, but they all need to be configured in the default realm. Planned support for multi-realms with WCM will be made available in a future release.

LookAside

LookAside is a repository that resides in the WebSphere Member Manager database. The purpose of LookAside is to provide the option to add additional attributes that do not correspond to a typical LDAP database. The LookAside option is available when configuring LDAP security with realms or without. Enabling LookAside can be done by setting the parameter LookAside=true in the wpconfig.properties file.

Note: If you are planning to use Web Content Management, the LookAside database is required.

3.3.2 How do I prepare for WebSphere Portal Server LDAP security

The following presents the general steps you should take before you perform the enable security process.

1. LDAP installation, configuration and validation: The installation and configuration of your LDAP server should be completed by this phase. Performance tuning should be completed according to the recommendations in the LDAP server’s documentation and monitoring tools. A good way to test your LDAP configuration is to perform a search using the ldapsearch utility to confirm that your LDAP is operational.

– Anonymous search:

ldapsearch -s base -h ldaphostname “objectClass=*”

– Using a Bind ID:

ldapsearch -h ldaphostname -D “cn=wpsbind,o=co” -w “wpsbind” -s base “objectClass=*”

74 IBM WebSphere Portal V6 Self Help Guide

Note: Performing LDAP searches using an utility is one of the initial ways to troubleshoot directory problems. If you do not receive results and have confirmed that the problem is not user based (typos or extra spaces), it may indicate an underlying problem with the LDAP directory or network. Resolve these issues before proceeding with the enablement of directory security.

2. LDAP Design: While it is possible to set up WebSphere Portal Server with only one user and one group, this is not advisable. The LDAP Schema Design and Directory Information Tree (DIT) should ideally be thoughtfully planned and agreed to by all stake holders in your organization before you even attempt installation, and certainly before this phase in your deployment. Changing the LDAP Schema design during mid- or post-deployment could have unintended consequences.

3. LDAP requirements for WebSphere Portal Server: Before you can perform the connection to your user registry, the elements for user and group membership must be met. WebSphere Portal Server requires a minimum of one user and group to be created in LDAP before you can connect to it:

– wpsadmin (Portal Administration User)

– wpsadmins

It is recommended that the wpsadmin user be a member of the wpsadmins group. If you are going to be using features such as Portal Document Manager (PDM) and WebSphere Content Management (WCM), we recommend creating the following groups ahead of time:

– wasadmin (WebSphere Administration User; required if it will be different from the

wpsadmin ID. The wasadmin user and wasadminGroup should be set ahead of time regardless of whether features such as PDM and WCM are utilized in your deployment.)

– wpsContentAdminstrators

– wpsDocReviewer

– WcmAdminGroupId

Once all the users and groups are created, perform queries through the ldapsearch utility to validate the membership information used later to enable LDAP security.

4. Connectivity check (PING): From the server in which you will enable security, perform a ping test to verify the connection to your LDAP host(s). In addition to confirming that there is no packet loss, you should also verify that the round trip time is acceptable from destination to host based on your organization’s topology. Intermittent connectivity failures to your LDAP can cause not only your enablement of security task to fail, but can degrade the performance of WebSphere Portal Server. You should resolve all connectivity issues before attempting to run the enablement of security targets.

5. Connectivity check (TELNET): The next test that you should run from your WebSphere Portal Server(s) is to verify that you can telnet to the ports that are open and accessible from your LDAP Server(s). The default LDAP ports are 389 and 636. Port 636 is the default port used for Secure Socket Layer (SSL) connections. When performing the initial enablement of security for your user registry, the recommended sequence is to enable security connecting to the non-SSL port (389), then, after validating that your portal is able to connect to your LDAP successfully (link to the validation steps), follow the post configuration steps to connect your LDAP through SSL.

Chapter 3. WebSphere Portal installation 75

6. For most platforms, you have the option of enabling security manually using the command line, or transferring the database using the configuration wizard. Regardless of the process you choose, you will need to modify the wpconfig.properties and the helper file (optional) for your LDAP type. Take a secondary backup of these files before going through the enablement security process in order to avoid having to recover them from the file system backup.

Note: You should always create a backup of files at each step of the installation process and at any point in time where the files will need to be modified.

7. Stop WebSphere Portal Server if it is running. In a clustered environment, Deployment Manager and

all node agents should be running and synchronized.

8. Check the InfoCenter to re-confirm that you have followed all instructions for your LDAP server, including any system requirements or other modifications necessary for your environment. You can access the InfoCenter at:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp

9. Using support tools

before you run installation and configuration tasks are another

effective method of problem avoidance. By utilizing a tool such as IBM Support Assistant, you can perform a search for “enable security with WebSphere Portal Version 6” and review all TechNotes surrounding this topic. Refer to Appendix A, “Using IBM tools to find solutions and promote customer self-help” on page 169 for more information.

10.Disable Security: Run the disable security task using the command line or the wizard. After the disable security task completes, you should receive a BUILD SUCCESSFUL message indicating that the transfer process has now completed. Review the ConfigTrace.log file located in WP_root/log for any errors. Start WebSphere Portal Server (if it is not already started) and verify that you can access the portal without credential validation.

Table 3-2 shows a checklist for the LDAP security preparation steps.

Table 3-2 LDAP security preparation checklist

Step Tasks Completed

1 Install, configure, and tune your LDAP Server(s).

2 Design your LDAP Schema and arrange the entries in the organization

tree.

3 Perform a basic LDAP query using the ldapsearch utility to verify that your

LDAP is functional.

4 Create wasadmin and wpsadmin (users) and wpsadmins (group) in your

LDAP registry.

5 Perform a search for the wasadmin, wpsadmin, and the wpsadmins group

by using the ldapsearch utility.

6 From your WebSphere Portal Server(s), perform an PING test to verify you

connection to your LDAP host(s).

7 From your WebSphere Portal Server(s), perform a telnet test to port 389

(or 636 if 389 is closed) to confirm accessibility to the LDAP ports.

8 Make a file system backup of WebSphere Portal Server.

9 Make a backup of your portal data with the same time stamp as the

WebSphere Portal Server(s).



76 IBM WebSphere Portal V6 Self Help Guide

Step Tasks Completed

10 Take a secondary backup of your wpconfig.properties file and the helper

file (optional) for your LDAP Server.

11 Stop all WebSphere Portal Servers. In a clustered environment, verify that

Deployment Manager is started and all node agents are running and synchronized.

12 Check the InfoCenter to reconfirm that you have met all prerequisites for

hardware, software, and configuration for your LDAP, including the latest WebSphere Member Manager fixes.

13 Problem Avoidance: Use the IBM Support Assistant to perform a search for

“enabling security and WebSphere Portal V6” to review all TechNotes and solutions associated with this task.

14 Proceed with the steps to disable security.

3.3.3 What is about to happen

After installation, WebSphere Portal Version 6 is installed with security enabled so the WebSphere Portal is functional right after installation and the configuration is suitable for a simple environment like unit tests or development. If you wish to configure a different type of security, other then the out-of-the-box configuration, then you have the option to configure WebSphere Portal to use a database registry, a custom registry, or an LDAP user registry to store user information and to authenticate users.



Although you can configure WebSphere Portal to use a database user registry to store user information and to authenticate users, this is not recommended for production scenarios due to performance constraints and the difficulty associated with managing a large number of users and groups. If still you wish to pursue this goal, you should refer to the InfoCenter, which discusses the issues to consider and the procedures to follow if you plan to use a database user registry as the WebSphere Application Server security type with WebSphere Portal. You can find the InfoCenter at:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wpf/s ec_was_en.html

The other option that provides considerable flexibility in adapting WebSphere Portal and security to various environments where some form of a user registry, other than LDAP or a Member Manager database, already exists in the operational environment is configuration of security with a custom user registry.

Attention: Implementing a custom user registry is a software development effort and will not be covered here.

At this point, you should be ready to configure security having WebSphere Portal installed and having completed the database transfer. In order to change the security configuration, you must first disable security and then re-enable it with the appropriate security configuration. Since installing an LDAP server is not part of the default WebSphere Portal installation, you must then install, set up, and configure the LDAP user registry. The InfoCenter outlines the procedures for each LDAP type, so reference the information to select the appropriate LDAP type to set up for your environment:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wpf/l dap_u_reg.html

Chapter 3. WebSphere Portal installation 77

Once you have selected the type of LDAP for which you wish to configure security, proceed with the installation, the creation of required users and groups, the setup, disabling security, configuring, and verification of the LDAP.

Note: Domino Directory is the LDAP user registry that will be discussed in this paper; you may reference the link above for information about the other types.

When configuring Domino Directory, you can choose to have one-realm support or multiple-realm support. Having realm support means one or more user registries (realms) can be created. Since a realm must be mapped to a Virtual Portal, having realm support will allow you to configure Virtual Portals in your environment as opposed to no realm support, which allows only one user registry (one realm) to be created. We recommend enabling security with realm support in the event that you wish to configure Virtual Portals in the environment at a later time.

The appropriate portal configuration tasks that are designed to configure portal security to work with an LDAP server can be run upon editing the entries in the file wpconfig.properties.

Note: These instructions can apply to either a stand-alone server installation or a cluster environment. When performing these steps in a cluster, it is only necessary to perform them on the primary node.

For security purposes, we do not recommend that you store passwords in the wpconfig.properties file. Instead, you should edit the file with the passwords prior to running the configuration task and then remove the passwords from the file once the task has completed with success.

You also have the option to specify the password as a parameter when running the task through the command line, as shown in Example 3-7.

Example 3-7 Specifying the password as a parameter

WPSconfig.{sh|bat} task_name -Dpassword_property_key=password_value

Once you have located the wpconfig.properties file, you will need to create a backup before changing any values. Then using a text editor enter the values appropriate for your environment, such as the values in the following sections of the file:

򐂰 IBM WebSphere Application Server properties

򐂰 WebSphere Portal Security LTPA and SSO Configuration

򐂰 WebSphere Portal configuration properties

򐂰 LDAP Properties Configuration

򐂰 Advanced LDAP Configuration

򐂰 IBM Workplace Web Content Management Properties (If you wish to configure WCM in

your WebSphere Portal environment)

You will also need to locate the wpconfig_dbdomain.properties file, which you will also need to create a backup of before changing any values. Then, using a text editor, enter the values appropriate for your environment, such as the values in the following sections of the file:

򐂰 Database properties

For detailed information about what needs to be added to the properties file, including examples, select WebSphere Portal → Configuring → Configuring Security → LDAP

78 IBM WebSphere Portal V6 Self Help Guide

user registry → Tivoli Directory Server/IBM SecureWay/Domino Directory/Active Directory/Novell eDirectory/Sun™ System Directory Server → Configuring (your specific LDAP user registry name here) → non-realm/realm support in the InfoCenter at:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp

Once the files have been modified, you will need to save them and stop the WebSphere Por tal server.

Note: If this is a clustered environment, you will need to make sure the deployment manager and all the node agents are active.

To validate the configuration before enabling security, you can run the following tasks for:

򐂰 UNIX/Windows:

./WPSconfig.sh (bat) validate-wmmur-ldap -DWasPassword=password

-DPortalAdminPwd=password -DLTPAPassword=password -DLDAPAdminPwd=password

򐂰 i5/OS®:

WPSconfig.sh - profileName profile_root -DWasPassword=password

-DPortalAdminPwd=password -DLTPAPassword=password -DLDAPAdminPwd=password

where profile_root is the name given to the WebSphere Application server profile in use.

Important: Before enabling or disabling security in a clustered environment, using the appropriate tasks mentioned, you must stop all cluster members.

To configure WebSphere Portal security, you can run one of the following two tasks for UNIX/Windows:

򐂰 Realm Support:

./WPSconfig.sh(bat) enable-security-wmmur-ldap

򐂰 i5/OS:

WPSconfig.sh -profileName profile_root -DPortalAdminPwd=password

-DLTPAPassword=password -DLDAPAdminPwd=password

򐂰 Non-Realm Support:

./WPSconfig.sh(bat) enable-security-ldap

3.3.4 Is it working

Below are the steps listed to verify that portal security enablement using an LDAP user registry is successful. For clustered environments, the verification steps should in it ally be performed on the primary node. If you encounter problems during any of the steps in the recommended validation process below, refer to 3.4, “Problem determination” on page 80.

Verification

1. After the enabling security task completes, you should receive a BUILD SUCCESSFUL message indicating that the transfer process has now completed. Review the ConfigTrace.log file located in WP_root/log for any errors.

Chapter 3. WebSphere Portal installation 79

2. Shut down your WebSphere Portal Server and back up the SystemErr.log and SystemOut.log files located in the WP_root/log directory. Once the logs have been backed up, delete the existing SystemErr.log and SystemOut.log files so that fresh log files are created when the server is started. For those in a clustered environment, verify that all your nodeagents are in sync through the Deployment Manager. Restart the WebSphere Portal Server (primary node only for a clustered environment), and check the SystemErr.log and SystemOut.log files to verify that you do not receive any errors upon startup.

3. Once WebSphere Portal Server is up and running and you have verified that there are no errors, open a Web browser and direct it to one of the following URLs, depending on your deployment configuration:

– Single server deployment: http://hostname.example.com:10038/wps/portal – Cluster deployment: http://primarynode.example.com:9080/wps/portal

If you configured your LDAP registry to allow users to create and modify attributes through features such as self-registration, create a user through self-registration and verify that the user appears in LDAP by using the ldapsearch utility.

3.4 Problem determination

Figure 3-5 shows problem determination’s part in the installation process.

Installation

Database

Transfer

LDAP

Transfer

Figure 3-5 Problem determination

The following sections outline the recommended problem determination methods for solving issues related to WebSphere Portal installation as well as the database transfer and enabling security.

Problem

Determination

3.4.1 Installation problem determination

The most common installation failures occur during the configuration tasks that are run behind the scenes during the installation program. The initial sections of this chapter outline the contents of the wpsinstall.log for each installation scenario so you should be familiar with the events that take place during the installation of WebSphere Portal. This understanding

80 IBM WebSphere Portal V6 Self Help Guide

should help you determine at what point the installation is failing to get a better idea of how to go about correcting the issue on your system. In addition to the wpsinstall.log, you will also need to review the logs that can be found in the system defined /temp directory or in the portal_root/log directory, which is created and the files copied into during the installation.

The recommended approach to troubleshooting an installation failure is start with the BUILD FAILED message output in the PortalServer/log/ConfigTrace.log file, which indicates a failure has occurred and analysis is needed. You will need to follow the general approach outlined in Chapter 8, “Troubleshooting and monitoring“, of WebSphere Portal Version 6 Enterprise Scale Deployment Best Practices, SG24-7387, found at:

http://www.redbooks.ibm.com/redbooks/SG247387/wwhelp/wwhimpl/js/html/wwhelp.htm

The general approach described in that IBM Redbooks publication can, if followed, help you determine the failures for many different error messages that can occur during the installation of WebSphere Portal.

3.4.2 Database transfer problem determination

This section shows some common problems with the database transfer process, and provides you with some ideas on how to solve them.

Incorrect Fix Pack levels

One of the most common causes of database transfer failures is not meeting the supported hardware or software requirements for your database management system. If you are installing a local client on the WebSphere Portal Server for remote connection to your databases, your client should match the same levels as your database server. If your server and clients are not at the required levels, refer to 3.1.1, “How do I prepare my system for installation” on page 56 and repeat the database transfer steps.

The fixes/Fix Pack issue is not isolated to the database servers. Not applying the required fixes/Fix Packs for your portal environment can cause errors during the database process and affect the operability of your portal environment.

Missing Jar file for Type 4 JDBC DRIVER

For database systems using the Type 4 JDBC Driver, you must copy the driver from the database server over to your WebSphere Portal Server. We recommend that if you have a local database client on your WebSphere Portal Server that you back up the jar file(s) created during the client install and replace them with the ones from the database server.

Incorrect entries in the wpconfig.properties files

This is perhaps the most common cause of database transfer errors. These types of errors are usually attributed to the following:

򐂰 Typos or extra spaces: Be certain to look over your properties files for misspellings and

extra spaces. Ensure that the values entered are the same case throughout. Running the validate database connection targets before you conduct the database transfer may help you find some of the errors before you begin the procedure.

򐂰 Incorrect Driver specification: Ensure that you enter the correct format for the database

drivers. For example, with DB2, if you are using the Type 2 JDBC driver, the format should be jdbc:db2:databasename. For Type 4 JDBC drivers, the format should look like the following: jdbc:db2://db2server.domain.com:50000/databasename:returnAlias=0;.

Chapter 3. WebSphere Portal installation 81

Note: Consult with your database server’s documentation to confirm the correct format.

Multiple domains

If the DbUser, DbUrl, and DbPassword properties are not the same values across domains, the dbdomain.DataSourceName value should be changed for those domains that differ from the rest.

The value for the dbdomain.DataSourceName should not be the same value as

dbdomain.DbName.

If you are unsuccessful after reviewing your configuration and using various support tools to help you debug, you may need to engage support. Refer to Appendix A, “Using IBM tools to find solutions and promote customer self-help” on page 169 for information about how to prepare your logs before engagement.

3.4.3 LDAP security problem determination

This section shows some common problems with the enable security process, and provides you with some ideas on how to solve them.

Failing to install the required and recommended fixes/Fix Packs for your platform

One of the most common causes of security failures is not meeting the supported hardware or software requirements for your LDAP infrastructure. In addition to meeting the requirements for LDAP, you should ensure that all required and recommended fixes/Fix Packs WebSphere Portal Server have been installed for your platform (refer to 3.1.1, “How do I prepare my system for installation” on page 56).

The fixes/Fix Pack issue is not isolated to the LDAP servers. Not applying the required fixes/Fix Packs for your portal environment can also cause errors during the enablement of security process and can affect the overall operability of your portal environment. To enable security, you should also ensure that you apply the latest WebSphere Member Manager fixes:

http://www-1.ibm.com/support/docview.wss?rs=688&fdoc=wplcwspm&uid=swg24013740

Incorrect entries in the wpconfig.properties files

This is perhaps the most common cause of errors with enabling LDAP security. The types of errors are usually attributed to the following:

򐂰 Typos or extra spaces: Be certain to look over your properties files for misspellings and

extra spaces. Ensure that the values entered are the same case throughout. Running validation ldap targets before you conduct the enable security task may help you find some of the errors before you begin the procedure.

򐂰 Providing incorrect values for LDAP entries: Because the entries in the Advanced LDAP

Configuration section are organization specific, validation ldap targets does not check these entries for errors. Take special care to ensure that the values entered here are correct for your LDAP design, as this is one of the most common causes of failure when enabling security. Verify that you can search for users and groups using the information specified in the Advanced LDAP Configuration using the ldapsearch utility.

82 IBM WebSphere Portal V6 Self Help Guide

Incorrect privileges for the LDAPBindID

Unless anonymous searches are allowed, the LDAPBindID should have, at a minimum, permission to read and search a subset of the Directory Information Tree specified in the LDAP suffix entry. Confirm the privileges of your LDAPBind user if anonymous access is not allowed.

Failure to disable security before enabling security

Before you can run the enable security task, you must disable WebSphere Application Server Global Security by running the disable security task through the command line or the wizard. If you are encountering problems with running the security tasks, you must disable security each time before you try to reenable security.

Chapter 3. WebSphere Portal installation 83

84 IBM WebSphere Portal V6 Self Help Guide

Chapter 4. WebSphere Portal security

IBM WebSphere Portal provides personalized access to applications and processes, ranging from small and simple applications to complex enterprise information systems. It aggregates the content from different data sources to provide a single user interface for centralized display and management. These different applications and systems may require their own security controls with different level of complexities. To accommodate such a wide range of security requirements, WebSphere Portal has provided a rich set of configuration options that integrate with different security infrastructure components for authentication, authorization, single sign-on (SSO), and user management, and the customers can choose the combination that best matches their security needs.

In this chapter, we will cover issues in:

򐂰 Planning and designing solutions for portal security

򐂰 Configuring and customizing settings in portal security to suit special requirements

򐂰 Troubleshooting security related problems encountered during configuration and runtime

of a portal deployment

4.1 Planning and considerations

In this section, we will address the basic concepts, planning issues, and considerations while configuring WebSphere Portal security.

4.1.1 The basics

IBM WebSphere Portal provides personalized access to applications and processes, ranging from small and simple applications to complex enterprise information systems. It aggregates the content from many different data sources to provide a single user interface for centralized management. These different applications and systems may require their own security controls with different level of complexities. To accommodate such a wide range of security requirements, WebSphere Portal must integrate with different security infrastructure components for authentication, authorization, single sign-on (SSO), and user management, so that the customers can choose the solution that best suits their security needs.

WebSphere Portal is a J2EE application deployed onto an application server, called WebSphere_Portal within a WebSphere Application Server. It can leverage the underlying application server's powerful security infrastructure. In addition, WebSphere Portal security extended the security configuration provided by the Application Server, and presented a flexible set of options for customers to choose. It also provides the Credential Vault mechanism for supporting Single Sign-On solutions with back-end enterprise systems.

WebSphere Portal security consists of authentication and authorization. Authentication answers question of confidentiality, that is, the user submits the credentials to let the system know who he or she is and the server then verifies whether the user’s credentials are correct against a user registry. Authorization is more commonly referred to as Access Control. Once the user’s identity is established during the authentication phase, the authorization mechanism of the system checks what the authenticated user can do on which resources on the site. WebSphere Portal utilizes WebSphere Member Manager (WMM) for its user and group management, through an abstraction layer called Portal User Management Architecture (PUMA).

Figure 4-1 on page 87 gives a general overview of the deployment of the WebSphere Portal solution.

86 IBM WebSphere Portal V6 Self Help Guide

IBM BS029ML, WebSphere Portal V6 Self Help Manual

Specifications and Main Features

Frequently Asked Questions

User Manual