Sun Java™ System Portal Server 6 Deployment Planning Guide 2005Q1 Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A.
Copyright © 2005 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved. Sun Microsystems, Inc. has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed at http://www.sun.com/patents and one or more additional patents or pending patent applications in the U.S.
Contents List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Before You Read This Book . . . . . . . . . . . .
Portal Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Portal Server Software Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Packaging . . . . . . . . . . . . . . . . . . . .
Personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Aggregation and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Understanding User Behaviors and Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Chapter 4 Pre-Deployment Considerations . . . . . . . . . . . . . .
Using Platform Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using a Demilitarized Zone (DMZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Portal Server and Access Manager on Different Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Designing SRA Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tuning Parameters for /etc/system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Appendix C Portal Server and Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction to Application Server Support in Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Portal Server on an Application Server Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Portal Server 6 2005Q1 • Deployment Planning Guide
List of Figures Figure 1-1 Portal Server in Open Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Figure 1-2 Portal Server in Secure Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Figure 1-3 High-level Architecture for a Business-to-Employee Portal . . . . . . . . . . . . . . . . . . . . . . 34 Figure 1-4 SRA Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Portal Server 6 2005Q1 • Deployment Planning Guide
List of Tables Table 1 Typographical Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Table 3-1 Identity Management Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Table 3-2 SRA Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Table 3-3 Search Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .
Portal Server 6 2005Q1 • Deployment Planning Guide
Preface This Administration Guide explains how to plan for and deploy Sun Java™ System Portal Server 6 2005Q1 software. Portal Server Secure Remote Access provides a platform to create portals for your organization’s integrated data, knowledge management, and applications. The Portal Server platform offers a complete infrastructure solution for building and deploying all types of portals, including business-to-business, business-to-employee, and business-to-consumer.
How This Book Is Organized • Java™ Web Server • JavaServer Pages™ technology • Lightweight Directory Access Protocol (LDAP) • Hypertext Markup Language (HTML) • Extensible Markup Language (XML) How This Book Is Organized Chapters 1 through 5 provide information on Portal Server Secure Remote Access deployment. The following table summarizes the content of this book..
How This Book Is Organized Chapter Description Appendix C, “Portal Server and Application Servers” on page 153 This appendix describes the support for application servers. Appendix D, “Troubleshooting Your Portal Deployment” on page 159 This appendix describes how to troubleshoot the Portal Server software and the Portal Server Secure Remote Access (SRA) product. Appendix E, “Portal Deployment Worksheets” on page 167 This appendix provides various worksheets to help in the deployment process.
Related Documentation Typeface Meaning Examples AaBbCc123 (Italic) Book titles, new terms, words to be emphasized. Read Chapter 6 in the User’s Guide. A placeholder in a command or path name to be replaced with a real name or value. These are called class options. Do not save the file. The file is located in the install-dir/bin directory. Related Documentation The http://docs.sun.com web site enables you to access Sun technical documentation online.
Related Documentation Book Title Description Portal Server Technical Reference Guide Provides detailed information on the Portal Server technical concepts (such as Display Profile, Rewriter), command line utilities, tag libraries (in the software), and files (such as templates and JSPs). This guide serves as a single source for such essential background information. http://docs.sun.
Accessing Sun Resources Online • Application Server documentation http://docs.sun.com/coll/s1_asseu3_en • Web Proxy Server documentation http://docs.sun.com/prod/s1.webproxys#hic Accessing Sun Resources Online For product downloads, professional services, patches and support, and additional developer information, go to the following: • Download Center http://wwws.sun.com/software/download/ • Professional Services http://www.sun.com/service/sunps/sunone/index.
Sun Welcomes Your Comments Sun Welcomes Your Comments Sun is interested in improving its documentation and welcomes your comments and suggestions. To share your comments, go to http://docs.sun.com and click Send Comments. In the online form, provide the document title and part number. The part number is a seven-digit or nine-digit number that can be found on the title page of the book or at the top of the document.
Sun Welcomes Your Comments 20 Portal Server Secure Remote Access 6 2005Q1 • Administration Guide
Chapter 1 Portal Server Architecture This chapter contains the following sections: • What is a Portal? • Types of Portals • Portal Server Capabilities • Sun Java System Portal Server • Secure Remote Access • Security, Encryption, and Authentication • Portal Server Deployment Components • Portal Server Architecture • Identity Management • A Typical Portal Server Installation What is a Portal? Portals provide the user with a single point of access to a wide variety of content, data, and
Types of Portals Portals serve as a unified access point to web applications. Portals also provide valuable functions like security, search, collaboration, and workflow. A portal delivers integrated content and applications, plus a unified, collaborative workplace. Indeed, portals are the next-generation desktop, delivering e-business applications over the web to all kinds of client devices.
Portal Server Capabilities Collaborative services allow users to do the following: • Chat • Organize meetings • Share calendaring information • Define user communities • Participate in net meetings • Share information in discussion groups and on white boards Business Intelligence Portals Business intelligence portals provide executives, managers, and business analysts with access to business intelligence for making business decisions.
Sun Java System Portal Server • Secure access and authorized connectivity, optionally using encryption between the user’s browser and the enterprise • Authentication of users before allowing access to a set of resources that are specific for each user • Support for abstractions that provide the ability to pull content from a variety of sources and aggregate and personalize it into an output format suitable for the user’s device • A search engine infrastructure to enable intranet content to be organi
Secure Remote Access Each enterprise assesses its own needs and plans its own deployment of Java Enterprise System technology. The optimal deployment for each enterprise depends on the type of applications that Java Enterprise System technology supports, the number of users, the kind of hardware that is available, and other considerations of this type. Portal Server is able to work with previously installed software components.
Secure Remote Access If the portal does not contain sensitive information (deploying public information and allowing access to free applications), then responses to access requests by a large number of users is faster than secure mode. Figure 1-1 shows Portal Server configured for open mode. In this figure, Portal Server is installed on a single server behind the firewall.
Secure Remote Access The main advantage of SRA is that only the IP address of the Gateway is published to the Internet. All other services and their IP addresses are hidden and never published to a Domain Name Service (DNS) that is running on the public network (such as the Internet). The Gateway resides in the demilitarized zone (DMZ). The Gateway provides a single secure access point to all intranet URLs and applications, thus reducing the number of ports to be opened in the firewall.
Security, Encryption, and Authentication You can add additional servers and Gateways for site expansion. You can also configure the components of SRA in various ways based on your business requirements. Security, Encryption, and Authentication Portal Server system security relies on the HTTPS encryption protocol, in addition to UNIX system security, for protecting the Portal Server system software. Security is provided by the web container, which you can configure to use SSL, if desired.
Portal Server Architecture ❍ • Java Development Kit™ (JDK™)--Java Development Kit software provides the Java run-time environment for all Java software in Portal Server and its underlying components. Portal Server depends on the JDK software in the web container.
Identity Management • Access Manager node.The server where Access Manager can reside. Access Manager does not have to reside on the same node as Portal Server. • Search node. Optional. The server you use for the Portal Server Search service. You can install the Portal Server Search service on its own server for performance, scalability and availability reasons. • Gateway nodes. Optional. The server where the SRA Gateway resides. You can install the Gateway on the portal node.
Portal Server Software Deployment • Access Manager console SDK • Authentication daemons that support the web applications See the Access Manager Deployment Planning Guide for more information. Portal Server Software Deployment This section provides information on software deployed on Portal Server.This section provides information on the software packaging mechanism, the software categories within the system, and compatibility with Java software.
Portal Server Software Deployment • Static web content. These include static HTML files, images, applet JAR files, and other items that can be served up directly by the web server without using the Web Server container. For Portal Server, these files are also installed in the web server. NOTE Static web content and dynamic web applications are all grouped together into a single WAR file. • Configuration data.
A Typical Portal Server Installation A Typical Portal Server Installation Figure 1-3 on page 34 illustrates some of the components of a portal deployment but does not address the actual physical network design, single points of failure, nor high availability. See Chapter 5, “Creating Your Portal Design”, for more detailed information on portal design. This illustration shows the high-level architecture of a typical installation at a company site for a business-to-employee portal.
A Typical Portal Server Installation Figure 1-3 High-level Architecture for a Business-to-Employee Portal Portal Server Search Gateway Telecommuter PCs/ Workstations PCs Desktops Proxy/ Cache Airport/Hotel Kiosks Portal Server Internet Web Server Branch Offices Remote Offices Customers/Suppliers Behind Firewall Portal Server 6 2005Q1 • Deployment Planning Guide Mail Server Mail Gateway Legacy Server DMZ 34 Directory Server
A Typical Portal Server Installation Figure 1-4 shows a Portal Server deployment with SRA services. See Chapter 2, “Portal Server Secure Remote Access Architecture” for details.
A Typical Portal Server Installation 36 Portal Server 6 2005Q1 • Deployment Planning Guide
Chapter 2 Portal Server Secure Remote Access Architecture This chapter describes the Sun Java™ System Portal Server Secure Remote Access (SRA) architecture. You administer the configuration information through the Access Manager administration console.
SRA Gateway • Netlet request. Routes the request (traffic) to the server specified in the Netlet rule that the user clicked in the Portal Desktop. • HTTP(S) traffic. Routes the request to the server as specified by the HTTP header. Upon receiving a response from the server, the Gateway translates the response so that all intranet links within the response work on the extranet. All the Gateway configuration information is stored in the Access Manager’s LDAP database as a profile.
SRA Gateway NOTE Session stickiness is not required in front of a Gateway (unless you are using Netlet), however performance is improved with session stickiness. On the other hand, session stickiness to the Portal Server instances is enforced by SRA. Proxy Configuration The Gateway uses proxies that are specified in its profile to retrieve contents from various web servers within the intranet and extranet. You can dedicate proxies for hosts and DNS subdomains and domains.
SRA Gateway • Mandatory server authentication. The client must authenticate the server. • Optional authentication. The server is configured to authenticate the client. Personal Digital Certificate (PDC) authentication is a mechanism that authenticates a user through SSL client authentication. The Gateway supports PDC authentication with the support of Access Manager authentication modules. With SSL client authentication, the SSL handshake ends at the Gateway.
Netlet Gateway Logging You can monitor the complete user behavior by enabling logging on the Gateway. The Gateway uses the Access Manager logging API for creating logs. Using Accelerators with the Gateway You can configure accelerators, which are dedicated hardware co-processors, to off-load the SSL functions from a server's CPU. Using accelerators frees the CPU to perform other tasks and increases the processing speed for SSL transactions.
Netlet Dynamic applications agree upon a port for communication as part of the handshake. You can include the destination server port as part of the Netlet rule. The Netlet needs to understand the protocol and examine the data to find the port being used between the client and the server. FTP is a dynamic port application. In FTP, the port for actual data transfer between the client and server is specified through the PORT command.
Netlet Netlet and Application Integration Netlet works with many third parties such as Graphon, Citrix, and pcAnywhere. Each of these products provides secure access to the user’s Portal Desktop from a remote machine using Netlet. Split Tunneling Split tunneling allows a VPN client to connect to both secure sites and non-secure sites, without having to connect or disconnect the VPN—in this case, the Netlet—connection.
Netlet Proxy Netlet Proxy A Netlet Proxy helps reduce the number of open ports needed in the firewall to connect the Gateway and the destination hosts. For example, consider a configuration where users need Netlet to connect with a large number of Telnet, FTP, and Microsoft Exchange servers within the intranet. Assume that the Gateway is in a DMZ. If it routes the traffic to all the destination servers, a large number of ports would need to be open in the second firewall.
NetFile • NetFile servlet(s). Two NetFile servlets are present in the web container, one for each kind of NetFile applet. The servlets are responsible for connecting to different types of file systems, carrying out the operations that NetFile is configured to handle, and sending the information back to the applets for display. NetFile is internationalized and provides access to file systems irrespective of their locale (character encodings).
NetFile Access Control NetFile provides various means of file system access control. You can deny access to users to a particular file system based on the protocol. For example, you can deny a particular user, role, or organization access to file systems that are accessible only over NFS. You can configure NetFile to allow or deny access to file systems at any level, from organization, to suborganization, to user. You can also allow or deny access to specific servers.
Rewriter NetFile also enables users to select multiple files and compress them by using GZIP and ZIP compression. Users can select multiple files and send them in a single email as multiple attachments. NetFile also uses the SSO token of Access Manager to access the user’s email settings (such as IMAP server, user name, password, and reply-to address) for sending email. Double-clicking a file in the NetFile window launches the application corresponding to the MIME type and opens the file.
Rewriter Proxy according to a Document Type Definition (DTD). Using the generic ruleset that ships with the Rewriter, you can rewrite most URLs (but not all) without any additional rules. You can also associate rulesets with domains for domain-based translations. See the Portal Server Secure Remote Access 6 Administration Guide for more information. An external ruleset identifies the URI in the content. Any request that needs to be served by SRA follows this route: 1.
Proxylet NOTE You can run multiple Rewriter Proxies to avoid a single point of failure and achieve load balancing. Proxylet Proxylet is a dynamic proxy server that runs on a client machine. Proxylet redirects a URL to the Gateway. It does this by reading and modifying the proxy settings of the browser on the client machine so that the settings point to the local proxy server or Proxylet. It supports both HTTP and SSL, inheriting the transport mode from the Gateway.
Proxylet 50 Portal Server 6 2005Q1 • Deployment Planning Guide
Chapter 3 Identifying and Evaluating Your Business and Technical Requirements The first step in planning your deployment is identifying your Sun Java™ System Portal Server business and technical requirements.. You need to gather both business and technical requirements before you can address architecture and design issues.
Business Objectives The business goals of your portal affect deployment decision. Understand your objectives. If you do not understand your business requirements, you can easily make erroneous assumptions that could affect the accuracy of your deployment estimates.
Technical Goals Technical Goals Your technical requirement (often called functional requirement) discuss the details of your organization’s system needs and desired results, and include such factors as: • Performance • Security • Reliability • Expected performance criteria of the portal The technical requirements define all functions required of an architecture and provide guidelines for how each component works and integrates to form an entire system.
Mapping Portal Server Features to Your Business Needs Mapping Portal Server Features to Your Business Needs The previous sections posed questions to you about the various areas of the Portal Server system from a high-level perspective of business and technical needs. This section reviews specific technology features with the goal of determining which technologies are most important for your organization. Review these features while keeping in mind your organization’s short-, mid-, and long-term plans.
Mapping Portal Server Features to Your Business Needs Table 3-1 Identity Management Features and Benefits (Continued) Feature Description Benefit User, policy, and provisioning management Access Manager enables you to manage many users spanning a variety of different roles across the organization and sometimes outside the organization while accessing content, applications, and services.
Mapping Portal Server Features to Your Business Needs SRA Table 3-2 shows the Sun Java System Portal Server Secure Remote Access (SRA) features and their benefits Table 3-2 SRA Features and Benefits Feature Description Benefit Integrated security Extranet or Virtual Private Network capabilities “on demand” while providing user, policy, and authentication services.
Mapping Portal Server Features to Your Business Needs Feature Description Benefit Rewriter Proxy Redirects HTTP requests to the Rewriter Proxy instead of directly to the destination host. The Rewriter Proxy in turn sends the request to the destination server.
Mapping Portal Server Features to Your Business Needs Table 3-3 Search Features and Benefits (Continued) Feature Description Benefit Subscriptions Enables the user to track new or changed material in different areas of interest. Discussions, search categories, and free-form searches (saved searches) can be tracked. Personalization Personalization is the ability to deliver content based on selective criteria and offer services to a user.
Understanding User Behaviors and Patterns Table 3-5 shows the aggregation and integration features and their benefits. Table 3-5 Aggregation Features and Benefits Feature Description Benefit Aggregated information The Portal Desktop provides the primary end-user interface for Portal Server and a mechanism for extensible content aggregation through the Provider Application Programming Interface (PAPI).
Understanding User Behaviors and Patterns 60 • Will users login to the portal at the same time each day? Will they use the portal at work or somewhere else? • Are users in the same time zone or in different time zones? • How long do you expect the typical user to be connected, or have a valid portal session open? What use statistics do you have for existing applications? Do you have web traffic analysis figures for an existing portal? • How many visitor sessions, or number of single-visitor visits,
Chapter 4 Pre-Deployment Considerations This chapter contains the following sections: • Determine Your Tuning Goals • Portal Sizing Tips • Establish Performance Methodology • Portal Sizing • SRA Sizing Determine Your Tuning Goals Before tuning you portal, work with portal system administrators and portal developers to set the portal performance objectives based upon the projected requirements of your portal.
Portal Sizing Tips time, the number of Portal desktop activity requests, the amount of portal channel usage, acceptable response time for the end-user which is determined by your organization, and an optimal hardware configuration to meet the criteria. Portal Sizing Tips This section contains a few tips to help you in the sizing process. • A business-to-consumer portal requires that you deploy SRA to use the Gateway and SSL. Make sure you take this into account for your sizing requirements.
Portal Sizing 2. Setup a controlled environment to minimize the margin of error (defined as less than ten percent variation between identical runs). By knowing the starting data measurement baseline, you can measure the differences in data performance between sample gathering runs. Be sure measurements are taken over an adequate period of time and that you are able to capture and evaluate the results of these tests.
Portal Sizing Establish Baseline Sizing Figures Once you have identified your business and technical requirements, and mapped Portal Server features to your needs, your sizing requirements emerge as you plan your overall Portal Server deployment. Your design decisions help you make accurate estimates regarding Portal Server user sessions and concurrency.
Portal Sizing maximum number of concurrent sessions = expected percent of users online * user base To identify the size of the user base or pool of potential users for an enterprise portal, here are some suggestions: • Identify only users who are active. Do not include users who are, for example, away on vacation, or on leave. • Use a finite figure for user base. For an anonymous portal, estimate this number conservatively. • Study access logs. • Identify the geographic locations of your user base.
Portal Sizing Calculate maximum number of concurrent users after you calculate maximum number of concurrent sessions. To calculate the maximum number of concurrent users, use this formula: concurrent users = number of concurrent sessions / average time between hits For example, consider an intranet Portal Server example of 50,000 users. The number of connected sessions under its peak loads is estimated to be 80% of its registered user base.
Portal Sizing The average size adjusts for variations in sizes of RDs. A collection of long, complex RDs with many indexed terms and a list of short RDs with a few indexed terms require different search times, even if the complex RDs have the same number of RDs. RDs are stored in a hierarchical database format, where the intrinsic size of the database must be accounted for, even when no RD is stored.
Portal Sizing Hardware and Applications CPU speed and size of the virtual machine for the Java™ platform (Java™ Virtual Machine or JVM™ software) memory heap affect Portal Server performance. The faster the CPU speed, the higher the throughput. The JVM memory heap size, along with the heap generations tuning parameters, can also affect Portal Server performance. Back-End Servers Portal Server aggregates content from external sources.
Portal Sizing When you calculate transaction time, size your Portal Server so that processing time under regular or peak load conditions does not exceed your performance requirement threshold and so that you can sustain processing time over time. Workload Conditions Workload conditions are the most predominantly used system and JVM software resources on a system. These conditions largely depend on user behavior and the type of portal you deploy.
Portal Sizing After you have an estimate of your sizing, consider: • LDAP Transaction Numbers • Application Server Requirements LDAP Transaction Numbers Use the following LDAP transaction numbers for an out-of-the-box portal deployment to understand the impact of the service demand on the LDAP master and replicas. These numbers change once you begin customizing the system.
Portal Sizing Use a trial deployment to determine your final sizing estimates. A trial deployment helps you to size back-end integration, to avoid potential bottlenecks with Portal Server operations. Refine Baseline Sizing Figures Your next step is to refine your sizing figure. In this section, you build in the appropriate amount of headroom so that you can deploy a portal site that features scalability, high availability, reliability and good performance.
SRA Sizing ❍ Maintenance demands Considering these factors enables you to develop a sizing figure that is flexible and enables you to avoid risk when your assumptions regarding your portal change following deployment.
SRA Sizing Identifying Gateway Key Performance Requirements Key performance factors are metrics that your technical representative uses as input to an automated sizing tool. The sizing tool calculates the estimated number of Gateway instances your SRA deployment requires. Identifying these key performance factors and giving them to your technical representative is the first step in formulating your baseline sizing figure.
SRA Sizing • Session average time This determines how many logins per second that the Gateway must sustain for a given number of concurrent users. Netlet Usage Characteristics Consider the following Netlet characteristics of the Gateway, which can have a impact in calculating the number of Gateway instances: • Netlet is enabled in the Access Manager administration console. If Netlet is enabled, the Gateway needs to determine whether the incoming traffic is Netlet traffic or Portal Server traffic.
SRA Sizing Advanced Gateway Settings Use the settings in this section to obtain more accurate results when estimating the number of Gateway instances for your deployment. These advanced Gateway settings are used as input to the automated sizing tool.
SRA Sizing • Regular-JSP. Describes a configuration of two tabs with seven channels each. • Heavy—JSP. Describes a configuration of three tabs with seventeen channels each. Scalability You can choose between one, two, and four CPUs per Gateway instance. The number of CPUs bound to a Gateway instance determines the number of Gateway instances required for the deployment.
SRA Sizing See the Portal Server Secure Remote Access 6 Administration Guide for more information on the Sun Crypto Accelerator 1000 board and other accelerators. NOTE The Sun Crypto Accelerator 1000 board supports only SSL handshakes and not symmetric key algorithms. This is not generic to all other cryptographic accelerators. Other cryptographic accelerators are on the market and some of them can support symmetric key encryption. See the following URL for more information: http://www.zeus.
SRA Sizing 78 Portal Server 6 2005Q1 • Deployment Planning Guide
Chapter 5 Creating Your Portal Design This chapter describes how to create your high-level and low-level portal design and provides information on creating specific sections of your design plan.
Portal Design Approach Your high-level portal design communicates the architecture of the system and provides the basis for the low-level design of your solution. Further, the high-level design needs to describe a logical architecture that meets the business and technical needs that you previously established. The logical architecture is broken down according to the various applications that comprise the system as a whole and the way in which users interact with it.
Portal Design Approach Overview of Low-Level Portal Design The low-level design focuses on specifying the processes and standards you use to build your portal solution, and specifying the actual hardware and software components of the solution, including: • The Portal Server complex of servers. • Network connectivity, describing how the portal complex attaches to the “outside world.
Portal Design Approach • Usage estimates, which include your assumptions on the total number of registered users, average percentage of registered users logged in per day, average concurrent users that are logged in per day, average login time, average number of content channels that a logged in user has selected, and average number of application channels that a logged in user has selected. Additionally, you need to consider how the following three network zones fit into your design: • Internet.
Portal Server and Scalability Portal Server and Scalability Scalability is a system’s ability to accommodate a growing user population, without performance degradation, by the addition of processing resources. The two general means of scaling a system are vertical and horizontal scaling. The subject of this section is the application of scaling techniques to the Portal Server product.
Portal Server and High Availability The section “Working with Portal Server Building Modules” on page 89, discusses an approach to a specific type of configuration that provides optimum performance and horizontal scalability. Portal Server and High Availability High Availability ensures that your portal platform is accessible 24 hours a day, seven days a week. Today, organizations require that data and applications always be available.
Portal Server and High Availability System Availability System availability is often expressed as a percentage of the system uptime. A basic equation to calculate system availability is: Availability = uptime / (uptime + downtime) * 100 For instance, a service level agreement uptime of four digits (99.99 percent) means that in a month the system can be unavailable for about seven hours. Furthermore, system downtime is the total time the system is not available for use.
Portal Server System Communication Links • Gateway. A load balancer used with the Gateway detects a failed Gateway component and routes new requests to other Gateways. A load balancer also has the ability to intelligently distribute the workload across the server pool. Routing is restored when the failed Gateway recovers. Gateway components are stateless (session information is stored on the client in an HTTP cookie) so rerouting around a failed Gateway is transparent to users. • Portal Server.
Portal Server System Communication Links Figure 5-1 Portal Server Communication Links Browser Gateway HTTP(s) Authentication Service (servlet) Access Manager Admin Console (servlet) Portal Desktop Service (servlet) Comm Channel Service (servlet) Search Service (servlet) LDAP Module Access Manager SSO SDK SDK SSO Access Manager Logging SDK Access Manager Mgmt SDK Portal Server instance running on a web container LDAP LDAP Authentication Server LDAP User/Policy/Service Profile Database Server D
Portal Server System Communication Links • Figure 5-1 on page 87 shows that if the following processes or communication links fail, the portal solution becomes unavailable to end users: Portal Server Instance. Runs in the context of a web container. Components within an instance communicate through the JVM™ using Java™ APIs. An instance is a fully qualified domain name and a TCP port number. Portal Server services are web applications that are implemented as servlets or JSP™ files.
Working with Portal Server Building Modules SRA includes other Java technology processes called Netlet Proxy and Rewriter Proxy. You use these proxies to extend the security perimeter from behind the firewall, and limit the number of holes in the DMZ. You can install these proxies on separate nodes.
Working with Portal Server Building Modules Building Modules and High Availability Scenarios Portal Server provides three scenarios for high availability: • Best Effort The system is available as long as the hardware does not fail and as long as the Portal Server processes can be restarted by the watchdog process. • No Single Point of Failure The use of hardware and software replication creates a deployment with no single point of failure (NSPOF).
Working with Portal Server Building Modules Table 5-1 summarizes these high availability scenarios along with their supporting techniques.
Working with Portal Server Building Modules Best Effort In this scenario, you install Portal Server and Directory Server on a single node that has a secured hardware configuration for continuous availability, such as Sun Fire UltraSPARC® III machines. (Securing a Solaris™ Operating Environment system requires that changes be made to its default configuration.
Working with Portal Server Building Modules No Single Point of Failure Portal Server natively supports the no single point of failure (NSPOF) scenario. NSPOF is built on top of the best effort scenario, and in addition, introduces replication and load balancing.
Working with Portal Server Building Modules As stated earlier, a building module consists of a a Portal Server instance, a Directory Server master replica for profile reads and a search engine database. As such, at least two building modules are necessary to achieve NSPOF, thereby providing a backup if one of the building modules fails. These building modules consist of four CPUs by eight GB RAM.
Working with Portal Server Building Modules Redundancy is equally important to the directory master so that profile changes through the administration console or the Portal Desktop, along with consumer replication across building modules, can always be maintained. Portal Server and Access Manager support MMR. The NSPOF scenario uses a multi-master configuration. In this configuration, two suppliers can accept updates, synchronize with each other, and update all consumers.
Working with Portal Server Building Modules Transparent Failover Transparent failover uses the same replication model as the NSPOF scenario but provides additional high availability features, which make the failover to a backup server transparent to end users. Figure 5-5 on page 96 shows a transparent failover scenario. Two building modules are shown, consisting of four CPUs by eight GB RAM.
Working with Portal Server Building Modules The session repository is provided by the application server software. Portal Server is running in an application server. Portal Server supports transparent failover on application servers that support HttpSession failover. See Appendix C, “Portal Server and Application Servers” for more information. With session failover, users do not need to reauthenticate after a crash.
Working with Portal Server Building Modules • If you use multiple machines, or if your Portal Server machine is running a large number of instances, use a fast network interconnect. • On servers with more than eight CPUs, create processor sets or domains with either two or four CPUs. For example, if you choose to install two instances of Portal Server on an eight CPU server, create two four-CPU processor sets.
Designing Portal Use Case Scenarios • You can install Search on a machine separate from Portal Server, to keep the main server dedicated to portal activity. When you do so, you use the searchURL property of the Search provider to point to the second machine where Search is installed. The Search instance is a normal portal instance. You install the Search instance just as you do the portal instance, but use it just for Search functionality.
Designing Portal Use Case Scenarios Use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain. Use case scenarios are an instance of a use case, representing a single path through the use case. Thus, there may be a scenario for the main flow through the use case and other scenarios for each possible variation of flow through the use case (for example, representing each option).
Designing Portal Use Case Scenarios Example Use Case: Authenticate Portal User Table 5-2 describes a use case for a portal user to authenticate with the portal. Table 5-2 Use Case: Authenticate Portal User Item Description Priority Must have. Context of Use Only authenticated users are allowed to gain access to the portal resources. This access restriction applies to all portal resources, including content and services. This portal relies on the user IDs maintained in the corporate LDAP directory.
Designing Portal Security Strategies Table 5-2 Item Use Case: Authenticate Portal User (Continued) Description Description 1. User enters the portal URL. 2. If the customization parameter [remember login] is set, then automatically login the user and provide a session ID. 3. If first time user, prompt for LDAP user ID and password. 4. User enters previously assigned user ID and password. 5. Information is passed to Access Manager for validation. 6.
Designing Portal Security Strategies • Minimize the size of the operating environment installation. When installing a Sun server in an environment that is exposed to the Internet, or any untrusted network, reduce the Solaris installation to the minimum number of packages necessary to support the applications to be hosted. Achieving minimization in services, libraries, and applications helps increase security by reducing the number of subsystems that must be maintained.
Designing Portal Security Strategies The user nobody does not have a password, which prevents a regular user from becoming nobody. Only the superuser can change users without being prompted for a password. Thus, you still need root access to start and stop Portal Server services. See the Java Enterprise System Installation Guide for more information. • Non-root user. You can run Portal Server as a regular UNIX user.
Portal Server and Access Manager on Different Nodes Portal Server and Access Manager on Different Nodes Portal Server and Access Manager can be located on different nodes. This type of deployment provides the following advantages: • Identity services can be deployed separately from portal services. Portal Server can be one of many applications using identity services. • Authentication and policy services can be separate from provider applications including Portal Server related applications.
Portal Server and Access Manager on Different Nodes Federation Management API–adds functionality based on the Liberty Alliance Project specifications. Figure 5-6 illustrates Access Manager and Portal Server residing on separate nodes.
Portal Server and Access Manager on Different Nodes Figure 5-7 shows two Portal Server instances configured to work with a single Access Manager and two Directory Servers where both the Access Manager and the Directory Servers operate in a Java Enterprise System Sun Clustered environment. This configuration is ideal when Access Manager and Directory Server instances are not the bottleneck.
Portal Server and Access Manager on Different Nodes Figure 5-8 shows configuration allowing authentication throughput coming from Portal Server to be load-balanced across the two Access Managers. This configuration could be implemented when the Portal Server resides on a high-end medium to large server (that is 1 to 4 processors) with a very wide bandwidth network connection. The Access Managers with the policy and authentication services could be on two medium-size servers.
Portal Server and Access Manager on Different Nodes Figure 5-9 shows a configuration for maximum horizontal scalability and higher availability achieved by a horizontal server farm. Two Portals Servers can be fronted with a load balancer for maximum throughput and high availability. Another load balancer can be put between Portal Servers and Access Managers to achieve authentication and policy processes as a load distributor and failover mechanism for higher availability.
Portal Server and Access Manager on Different Nodes 1. Modify the following areas in AMConfig.properties to be in sync with the first installed instance of Portal Server and Access Manager servers: #The key that will be used to encrypt and decrypt passwords. am.encryption.pwd=t/vnY9Uqjf12NbFywKuAaaHibwlDFNLO <== REPLACE THIS STRING WITH THE ONE FROM FIRST PORTAL INSTALL /* The following key is the shared secret for application auth module */ com.iplanet.am.service.
Designing SRA Deployment Scenarios Designing SRA Deployment Scenarios The SRA Gateway provides the interface and security barrier between the remote user sessions originating from the Internet and your organization’s intranet. The Gateway serves two main functions: • Provides basic authentication services to incoming user sessions, including establishing identity and allowing or denying access to the platform.
Designing SRA Deployment Scenarios Basic SRA Configuration Figure 5-10 shows the most simple configuration possible for SRA. The figure shows a client browser running NetFile and Netlet. The Gateway is installed on a separate machine in the DMZ between two firewalls. The Portal Server is located on a machine beyond the second firewall in the intranet. The other application hosts that the client accesses are also located beyond the second firewall in the intranet.
Designing SRA Deployment Scenarios Disable Netlet Figure 5-11 shows a scenario similar to the basic SRA configuration except that Netlet is disabled. If the client deployment is not going to use Netlet for securely running applications that need to communicate with intranet, then use this setup for performance improvement. You can extend this configuration and combine it with other deployment scenarios to provide better performance and a scalable solution.
Designing SRA Deployment Scenarios Proxylet Figure 5-12 Proxylet enables users to securely access intranet resources through the Internet without exposing these resources to the client. It inherits the transport mode (either HTTP or HTTPS) from the Gateway.
Designing SRA Deployment Scenarios Multiple Gateway Instances Figure 5-13 shows an extension of the SRA basic configuration. Multiple Gateway instances run on the same machine or multiple machines. You can start multiple Gateway instances with different profiles. See Chapter 2, “Configuring the Gateway,” in the Portal Server Secure Remote Access 6 Administration Guide for details.
Designing SRA Deployment Scenarios The disadvantage to this configuration is that multiple ports need to be opened in the second firewall for each connection request. This could cause potential security problems. Netlet and Rewriter Proxies Figure 5-14 shows a configuration with a Netlet Proxy and a Rewriter Proxy on the intranet. With these proxies, only two open ports are necessary in the second firewall.
Designing SRA Deployment Scenarios Figure 5-14 Netlet and Rewriter Proxies Portal Server Client Gateway Rewriter Proxy NetFile Netlet Proxy Netlet Portal Server Client NetFile Netlet Gateway Rewriter Proxy Netlet Proxy Host Host Host Host Host Host Host HTTP traffic Netlet traffic Chapter 5 Creating Your Portal Design 117
Designing SRA Deployment Scenarios Netlet and Rewriter Proxies on Separate Nodes To reduce the load on the Portal Server node and still provide the same level of security at increased performance, you can install Netlet and Rewriter Proxies on separate nodes. This deployment has an added advantage in that you can use a proxy and shield the Portal Server from the DMZ. The node that runs these proxies needs to be directly accessible from the DMZ.
Designing SRA Deployment Scenarios Using Two Gateways and Netlet Proxy Load balancers provide a failover mechanism for higher availability for redundancy of services on the Portal Servers and Access Managers.
Designing SRA Deployment Scenarios Using an Accelerator You can configure an external SSL device to run in front of the Gateway in open mode. It provides the SSL link between the client and SRA. For information on accelerators, see the Portal Server Secure Remote Access 6 Administration Guide.
Designing SRA Deployment Scenarios Netlet with 3rd Party Proxy Figure 5-18 illustrates using a third-party proxy to limit the number of ports in the second firewall to one. You can configure the Gateway to use a third-party proxy to reach the Rewriter and the Netlet Proxies.
Designing SRA Deployment Scenarios Reverse Proxy A proxy server serves Internet content to the intranet, while a reverse proxy serves intranet content to the Internet. Certain deployments of reverse proxy are configured to serve the Internet content to achieve load balancing and caching. Figure 5-19 illustrates how you can configure a reverse proxy in front of the Gateway to serve both Internet and intranet content to authorized users.
Designing for Localization Designing for Localization Localization is the process of adapting text and cultural content to a specific audience. Localization can be approached in two different ways: 1. Localization of the entire product into a language that we don’t provide. This is usually done by a professional service organization. 2.
Content and Design Implementation See the Portal Server 6 Developer’s Guide and Portal Server 6 Desktop Customization Guide for more information. Placement of Static Portal Content Place your static portal content in the web-container-install-root/SUNWam/public_html directory or in a subdirectory under the web-container-install-root/SUNWam/public_html directory (the document root for the web container).
Content and Design Implementation • Portlet. Pluggable web component that processes requests and generates content within the context of a portal. In Portal Server software, a portlet is managed by the Portlet Container. Conceptually, a portlet is equivalent to a Provider. • Portal application. Launched from a channel in its own browser window; the Portal Server hosts the application; an example is NetMail; created as an Access Manager service; accesses Portal and Access Manager APIs.
Content and Design Implementation • Portal capability augmentation. This integration enables products to add functionality to Portal Server. Examples include Altio, Bowstreet, rule engines to add group capability, and dynamic standard Portal Desktop and provider contents (HNC). • Integratable portal stack. This integration includes products that replace elements of Portal Server. Examples include Access Manager and LDAP. NOTE Portal Server cannot currently integrate another LDAP solution.
Identity and Directory Structure Design JavaMail provides a common uniform API for managing mail. It enables service providers to provide a standard interface to their standards based or proprietary messaging systems using Java programming language. Using this API, applications can access message stores and compose and send messages. Identity and Directory Structure Design A major part of implementing your portal involves designing your directory information tree (DIT),.
Identity and Directory Structure Design See the Portal Server 6 Administration Guide, Directory Server Deployment Guide, and the Access Manager Deployment Guide for more information on planning your Access Manager and Directory Server structure. Implementing Single Sign-On Single sign-on (SSO) to Portal Server is managed by Access Manager. SSO provides a user with the ability to use any application that has its access policy managed by Access Manager, if allowed through the policy.
Identity and Directory Structure Design Choosing and Implementing the Correct Aggregration Strategy The options for implementing portal channels for speed and scalability include: • Keeping processing functions on back-end systems and application servers, not on the portal server. The portal server needs to optimize getting requests from the user. Push as much business logic processing to the back-end systems. Whenever possible, use the portal to deliver customized content to the users, not to process it.
Identity and Directory Structure Design To use URLScraperProvider as a file scraper provider, specify the URL as follows: String name="url" value="file://path/filename" This is the best performing provider, in terms of how fast it retrieves content. On the first fetch of content, performance for this provider is usually in the low teen milliseconds. On subsequent requests, using a built-in caching mechanism, this provider can usually deliver content in one millisecond or less.
Identity and Directory Structure Design large amount of processing to display the data in the Portal Desktop. If you use this type of provider, push as much data processing logic to the database as possible. Also, benchmark your portal performance with and without database channels in the user profile. Client Support Portal Server supports the following browsers as clients: • Internet Explorer 5.5 and 6.0 • Netscape™ Communicator 4.
Identity and Directory Structure Design 132 Portal Server 6 2005Q1 • Deployment Planning Guide
Chapter 6 The Production Environment This chapter describes how to monitor and tune Sun Java™ System Portal Server software, including the Sun Java System Portal Server Secure Remote Access product. This chapter contains the following sections: • Moving to a Production Environment • Monitoring Portal Server Moving to a Production Environment Moving to a production environment occurs after you have thoroughly tested your portal and operated it as a trial deployment to test and refine your design.
Moving to a Production Environment • Determine whether your current physical infrastructure is capable of supporting the transaction volume requirement you have defined. Identify services that are the first to max out as you increase the activity to the portal. This indicates the amount of headroom you have as well as identify where to expend your energies. • Measure and monitor your traffic regularly to verify your model. • Use the model for long-range scenario planning.
Monitoring Portal Server Monitoring Portal Server This section describes the variables that affect portal performance, as well as the portal monitoring you can perform.
Monitoring Portal Server Most applications suggest using a larger percentage of the total heap for the new generation, but in the case of Portal Server, using only one eighth the space for the young generation is appropriate, because most memory used by Portal Server is long-lived. The sooner the memory is copied to the old generation the better the garbage collection (GC) performance.
Monitoring Portal Server Expect peak loads to be four to eight times higher than the average load, but over short periods of time. Access Manager Cache and Sessions The performance of a portal system is affected to a large extent by the cache hit ratio of the Access Manager cache. This cache is highly tunable, but a trade-off exists between memory used by this cache and the available memory in the rest of the heap.
Monitoring Portal Server Portal Usage Information Portal Server does not include a built-in reporting mechanism to monitor portal usage information by portal users. This includes which channels are accessed, how long the channels are accessed, and the ability to build a user behavioral pattern of the portal.
Appendix A Installed Product Layout This appendix describes the Sun Java™ System Portal Server directory structure and properties files used to store configuration and operational data. Directories Installed for Portal Server Table A-1 shows the platform-specific directory structures that are installed for Sun Java System Portal Server.
Directories Installed for SRA Table A-1 Portal Server Directories (Continued) Description Location HTML template files /etc/portal-server-install-root/SUNWps/desktop/default/channelname.templat e JSP template files /etc/portal-server-install-root/SUNWps/desktop/default/JSPchannelname Command-line utilities portal-server-install-root/SUNWps/bin/ Tag library definitions /etc/portal-server-install-root/SUNWps/desktop/default/tld/*.
Configuration Files Configuration Files All Portal Server and SRA configuration data is stored using the Sun Java System Access Manager Services Management function. Access Manager provides the bootstrap configuration file that is needed to find the Sun Java System Directory Server. The platform.conf file contains the details that the Gateway needs. By default, the platform.
Configuration Files 142 Portal Server 6 2005Q1 • Deployment Planning Guide
Appendix B Analysis Tools The Sun Java™ Enterprsie System and SDK include default setting options to ensure a satisfactory out-of-the-box experience. However these options might not provide optimal performance for your web applications in the Sun Java System Portal Server production environment. This section describes some alternative options and basic tuning techniques. NOTE The tuning settings discussed in this section focus on Portal Server residing on the Solaris platform.
mpstat Table B-1 Performance Analysis Tools Category Type Tuning Parameters Name Parameters Usage -a|grep hostname|wc-1 Socket connection count Portal Server on App Server container verbose:gc Garbage collection Solaris 8 and Solaris 9 /etc/system Various Performance /etc/rc2.
mpstat What to Look For Note the much higher intr and ithr values for certain CPUs. Solaris will select some CPUs to handle the system interrupts. The CPUs and the number that are chosen depend on the I/O devices attached to the system, the physical location of the devices, and whether interrupts have been disabled on a CPU (psradmin command). • intr - interrupts • intr - thread interrupts (not including the clock interrupts) ❍ ❍ ❍ ❍ csw - Voluntary Context switches.
iostat iostat The iostat tool gives statistics on the disk I/O subsystem. The iostat command has many options. More information can be found in the man pages. The following typical options provide information on locating I/O bottlenecks. Output #iostat -xn 10 extended device statistics r/s w/s kr/s 0.0 0.0 0.0 2.7 58.2 47.3 kw/s wait actv wsvc_t asvc_t %w %b device 0.0 0.0 0.0 0.0 0.0 0 14.6 2507.0 0.0 1.4 0.0 23.0 0 52 d0 0.0 0.4 0.0 8.8 0 30 d1 0.0 2465.6 0.
netstat netstat The netstat tool gives statistics on the network subsystem. It can be used to analyze many aspects of the network subsystem, two of which are the TCP/IP kernel module and the interface bandwidth. An overview of both uses follow. netstat -I hme0 10 These netstat options are used to analyze interface bandwidth. The upper bound (max) of the current throughput can be calculated from the output.
netstat • errs - errors. The presence of errors could indicate device errors. If your network is switched, errors indicate that you are nearly consuming the bandwidth capacity of your network. The solution to this problem is to give the system more bandwidth, which can be achieved through more network interfaces or a network bandwidth upgrade. This is highly dependent on your particular network architecture.
netstat tcpListenDrop = 0 tcpListenDropQ0 = 0 tcpHalfOpenDrop = 0 tcpOutSackRetrans = 56 What to look for • tcpListenDrop - If after several looks at the command output the tcpListenDrop continues to increase, it could indicate a problem with queue size. Considerations: • A possible cause of increasing tcpListenDrop is the application throughput being bottlenecked by the number of executing threads. At this point increasing application threads may be a good thing to try.
Tuning Parameters for /etc/system Tuning Parameters for /etc/system Table B-2 is a list of /etc/system tuning parameters used during the performance study. The changes are applied by appending each to the /etc/system file. Table B-2 /etc/system Options /etc/system Option Description set rlim_fd_max= "Hard" limit on file descriptors that a single process might have open. To override this limit requires superuser privilege.
Tuning Parameters for /etc/system Table B-3 TCP/IP Options TCP/IP Options Description ndd -set /dev/tcp tcp_cwnd_max 65535 The maximum value of TCP congestion window (cwnd) in bytes. ndd -set /dev/tcp tcp_rexmit_interval_min 3000 The default minimum retransmission timeout (RTO) value in milliseconds. The calculated RTO for all TCP connections cannot be lower than this value. ndd -set /dev/tcp tcp_rexmit_interval_ max 10000 The default maximum retransmission timeout value (RTO) in milliseconds.
Tuning Parameters for /etc/system 152 Portal Server 6 2005Q1 • Deployment Planning Guide
Appendix C Portal Server and Application Servers This appendix provides an overview of the Sun Java™ System Portal Server product and its support for application servers.
Portal Server on an Application Server Cluster Running Portal Server on an application server enables you to: • Decouple the portal platform from the application server platform, allowing you to choose the best combination of Portal Server and application server for your organization • Call Enterprise JavaBeans™ architechture and other J2EE™ technologies that run in the application server container • Use application server clustering, which provides scalability and high availability • Use session fa
Portal Server on an Application Server Cluster 2. Deploy the three web applications (portal, amserver, and amconsole) to the cluster. The following sections explain what it means to enable Portal Server to run on an application server cluster. Overview of Application Server Enterprise Edition The Sun Java System Application Server Enterprise Edition 8 provides a robust J2EE platform for the development, deployment, and management of enterprise applications.
Portal Server on an Application Server Cluster See the following documentation for more information: http://edocs.beasys.com/wls/docs61/cluster/index.html You start the Administration Server with the following command: install_dir/config/domain_name/startWeblogic.sh The local server takes its configuration from the install_dir/config/domain_name/config.xml file. To start a Managed Server, use the following command: install_dir/config/domain_name/startManagedWebLogic.
Portal Server on an Application Server Cluster To install a BEA cluster, your BEA license for each machine participating in the cluster must be a special BEA cluster license. See the BEA documentation for the procedure to get the license and set up a BEA cluster with HttpClusterServlet. Overview of IBM WebSphere Application Server The IBM WebSphere Application Server product uses the following definitions: • Administrative domain.
Portal Server on an Application Server Cluster 158 Portal Server 6 2005Q1 • Deployment Planning Guide
Appendix D Troubleshooting Your Portal Deployment This appendix describes how to troubleshoot the Sun Java™ System Portal Server software and the Sun Java System Portal Server Secure Remote Access (SRA) software. This appendix contains the following sections: • Troubleshooting Portal Server • Troubleshooting SRA Troubleshooting Portal Server This sections contains troubleshooting information for Sun Java System Portal Server.
Troubleshooting Portal Server ./uxwdog -d portal-server-install-root/SUNWam/servers/https-server/config ns-httpd -d portal-server-install-root/SUNWam/servers/https-server/config Admin Web Server (optional, but usually running): ./uxwdog -d web-container-install-root/SUNWam/servers/https-admserv/config ns-httpd -d web-container-install-root/SUNWam/servers/https-admserv/config Log Files Examine the following log files for errors.
Troubleshooting Portal Server ➤ To Extract the Display Profile 1. Login as administrator. 2. Use the dpadmin command to extract the display profile. For example: ./dpadmin list -u "uid=amAdmin,ou=People,o=sesta.com,o=isp" -w password -d "o=sesta.com,o=isp" > /tmp/displayxml This example puts the contents of the display profile into the /tmp/displayxml file. ➤ To Reload the Display Profile 1. Login as administrator. 2. Use the dpadmin command to reload the display profile. For example: .
Troubleshooting SRA Configuring a Sun Java System Portal Server Instance to Use an HTTP Proxy If the Portal Server software is installed on a host that cannot directly access certain portions of the Internet or your intranet, you can receive errors. For example, when using the SampleSimpleWebService provider, you might see the following error when the proxy has not been configured: java.net.UnknownHostException: services.xmethods.net ➤ To Configure Usage of an HTTP Proxy for a Portal Server Instance 1.
Troubleshooting SRA gateway-install-root/SUNWam/config/AMConfig-instance-name.properties 2. Set the debug level: com.iplanet.services.debug.level= The debug levels are: error - Only serious errors are logged in the debug file. Rewriter usually stops functioning when such errors occur. warning - Warning messages are logged. message - All debug messages are logged. off - No debug messages are logged. 3. Specify the directory for the debug files in the following property of the AMConfig-instance-name.
Troubleshooting SRA • The settings in the Gateway script such as the JVM™ settings including heap usage, and library path • Gateway service settings • Tuning settings in various files used for configuring Sun Java System Access Manager, Sun Java System Directory Server, and Sun Java System Web Server.
Troubleshooting SRA NOTE Before running gctool, ensure that you include -verbose:gc in the Gateway script in the “CMD” section. The Gateway script resembles the following: -server -verbose:gc -Xms1G -Xmx2G -XX:+OverrideDefaultLibthread -XX:ThreadStackSize=128 -XX:MaxPermSize=128M -XX:PermSize=128M -XX:MaxNewSize=256M -XX:NewSize=256M At the end of the test period, run shooter to collect the output of gctool along with other data. memfoot.sh This script tracks the memory footprint of a process.
Troubleshooting SRA /var/opt/SUNWps/debug/srapNetFile Netlet: /var/opt/SUNWps/debug/srapNetlet_Gateway-hostname_Gateway-profile-name 166 Portal Server 6 2005Q1 • Deployment Planning Guide
Appendix E Portal Deployment Worksheets This appendix provides worksheets to help with the portal deployment process. This appendix contains the following sections: • Portal Assessment Worksheets • Portal Design Task List Portal Assessment Worksheets Use these worksheets to learn more about your organization’s business needs and potential areas of concern around deploying portals. Table E-1 General Questions 1.
Portal Assessment Worksheets Table E-1 General Questions 2. How many portals does your organization already have? 3. What types are they (business-to-employee, business-to-consumer, business-to-business, ISP)? 4. If you have more than one, do you have a need to reduce the number? Integrate? Federate? 5. Do you have departmental portals? 6. What is the extent of your Web presence? How many web sites do you have? 7.
Portal Assessment Worksheets Table E-3 Business Service-level Expectations Questions 1. Are your development projects consistent? Do you manage their risk? 2. How does your development team work with your test, deployment, and operations groups? 3. How many different platforms does your organization currently support? 4. How secure is your information? How consistent is the security? 5. Are these challenges getting better, or getting worse? 6.
Portal Assessment Worksheets Table E-5 User Management and Security Questions 1. How would you segment, categorize, and relate (hierarchically) your user community? 2. What are your current and future security policies? 3. Do various departments own or maintain their private view of the customer? 4. Do you have an enterprise directory? Table E-6 Business Intelligence Questions 1. Do you have a need to gather, store, analyze, and provide information for enterprise decision-making? 2.
Portal Design Task List Table E-7 Architecture Questions (Continued) 9. What is the size of the target user community? 10. How many concurrent users? 11. What is the range of portal usage? 12. What is the geographical distribution of your user base? 13. Do you currently have or have a future need for non-Web access (Wireless, Voice/IVR) 14. Would your customer base require internationalization of content and services? 15. What server platform technologies do you use? 16.
Portal Design Task List Table E-8 Design Task List (2 of 7) Major Phases and Tasks Subtasks Project Plan Review • Review pre-implementation • Review business requirements • Review technical requirements • Review architectural documents • Review hardware and infrastructure • Identify skills required • Identify resources • Schedule resources • Assemble project team members • Review work plan with project team members • Collect business requirements • Summarize requirements • Con
Portal Design Task List Table E-8 Design Task List (3 of 7) Major Phases and Tasks Subtasks Directory Design • Design organizations, suborganizations, roles, and users • Define privileges • Review shared data requirements • Establish data transfer protocols • Create temporary or intermediate tables • Test temporary or intermediate tables • Document design approach • Deliver design document • Obtain appropriate stakeholder and organizational consensus • Install Sun Java System Portal
Portal Design Task List Table E-8 Design Task List (4 of 7) Major Phases and Tasks Subtasks Sun Java System Portal Server, Sun Java System Application Server, and • Review your organization’s requirements and expectations • Establish modifications for software • Establish methods for software modifications • Create software modification plan • Design software modifications • Establish software modification teams • Create modifications • Test modifications • Obtain appropriate stakehol
Portal Design Task List Table E-8 Design Task List (5 of 7) Major Phases and Tasks Subtasks Reporting • Establish reporting requirements for organization • Create reporting plan • Establish reporting team • Design reports • Create reports • Test reports • Review reports with customer • Provide information and training on report tool Test • Establish test plan Plan User Acceptance Test • Identify user acceptance test manager • Develop user acceptance test strategy and procedures
Portal Design Task List Table E-8 Design Task List (6 of 7) Major Phases and Tasks Subtasks Conduct Integration and System Test • Ensure establishment of integration test environment • Identify test team and assign test scenario ownership • Train team on integration test procedures, roles, and responsibilities • Review and revise integration test execution schedule, as required • Execute integration test • Identify and document integration test discrepancies • Resolve integration test dis
Portal Design Task List Table E-8 Design Task List (7 of 7) Major Phases and Tasks Subtasks Training • Confirm organization commitment and expectations • Establish training requirements for all personnel • Establish training schedules • Establish training staff • Prepare materials for training • Train administrators • Train maintenance providers • Capture training feedback • Incorporate feedback for training improvement • Create “run book” for system administrators Document Portal
Portal Design Task List 178 Portal Server 6 2005Q1 • Deployment Planning Guide
Appendix F Portal Server on the Linux Platform Sun Java™ System Portal Server supports RedHat 3.0 Linux platform, however, please note the differences between the Solaris and Linux platforms. Limitations Using Linux Please note the following: • Portal Server and Access Manager must reside on the same server. • The sample Portal does not support the Linux platform. • IBM and BEA web containers are not supported.
Comparison of Solaris and Linux Path Names 180 Portal Server 6 2005Q1 • Deployment Planning Guide
Glossary Refer to the Java Enterprise System Glossary (http://docs.sun.com/doc/816-6873) for a complete list of terms that are used in this documentation set.
Portal Server 6 2005Q1 • Deployment Planning Guide
Index SYMBOLS /etc/opt/SUNWps directory 139 /etc/system tuning parameters 150 /opt/SUNWps directory 139 /opt/SUNWps/sdk directory 139 A accelerators and Gateway 41, 76 access control Gateway 40 limiting 104 NetFile 46 Netlet 43 Access Control Instructions 127 Access Manager administration console 28 and Linux 179 cache and sessions 137 components 28 customizing 124 description 54 description and benefits 55 organization tree 127 single sign-on 28 Web Agent 128 Access Manager SDK, components 105 administra
Section B average session time 66 average time between page requests 65 B back-end servers 68 banner 82 baseline portal performance analysis 133 basic authentication 39 BEA WebLogic 155 bottlenecks and building modules 98 and tuning 133 building modules 89 and Directory Server 94 and high availability 90 and Search Engine 98 and transparent failover 96 contraints 97 deploying 97 description 89 business objectives 51 business requirements 51 business-to-consumer portal 62 business-to-employee portal 62 se
Section E requirements 51 software 31 deployment scenarios 92 and SRA 92 building modules 92 no single point of failure 93 SRA 111–122 transparent failover 96 designing for integration 124 for localization 123 security strategies 102 SRA deployment scenarios 111–122 use case scenarios 99 Desktop type 75 directories installed for Portal Server 139 installed for SRA 140 Directory Information Tree 127 directory replica 94 Directory Server and building modules 94 clustering 91 description 29 requirements 98 st
Section H high availability 86 HTTP and HTTPS 38 logging 41 multihomed 38 multiple instances 38 Netlet traffic 40 overview 37 page configuration 75 performance requirements 73 profile 39 proxies 39 session information, Gateway 40 session stickiness 39 SSL 39 SSL hardware accelerators 76 Gateway profile 39 gateway profile 38 gctool.
Section M and Portal Server failures 94 and Rewriter 49 and SRA 95 with SRA 86 locale file 140 localization 123 log files and troubleshooting 160 location 139 SRA 165 logging errors 134 Gateway 41 number of active sessions 137 login type 75 LoginProvider 130 low-level portal design, overview 81 M memfoot.
Section O O open mode 25 Outlook client 42 P packaging 31 pcAnywhere 52 PDC authentication 40 peak numbers 64 performance Access Manager cache and sessions 137 analysis tools 143 baseline analysis 135 building modules 97 CPU utilization 136 establishing methodology 62 garbage collection 135 memory consumption 135 TCP kernel 150 thread usage 137 tuning parameters 150 personalization description and benefits 58 retrieval 130 placement of portal content 124 platform security 103 Portal Desktop configuration
Section Q Q questions business objectives 51 techincal goals 53 user behaviors and patterns 59 R rdmgr command 160 recovering, Search database 160 reloading the display profile 161 requirements, identifying 51 resource bundles 123 reverse proxy description 122 offloading requests 82 Rewriter load balancing 49 overview 47 rulesets 48 Rewriter Proxy and accelerators 77 and software crash 86 overview 48 robot 57 Role-Based Access Control 104 roles 127 rulesets, Rewriwter 48 S sample Portal Server on Linux 1
Section T patches 18 support 18 Solaris Operating Environment minimizing size of installation 102 securing 102 split tunneling 43 SRA and load balancing 86, 95 and NetFile 46 and reverse proxy 122 and Sun Enterprise Midframe Line 77 components 37 debugging 162 directory structure 140 features and benefits 56 log files 165 overview 25 session characteristics 73 sizing 72 troubleshooting 162 SSL and Gateway 27 encryption 102 Gateway 39 modes 39 v2 and v3 39 SSL hardware accelerators 76 state data, and Portal
Section W VPN 56 VPN client 43 W WAR file 32 and application servers 154 to deploy software 31 web containers supported 153 workload conditions 69 worksheets 167 X XMLProvider 130 Index 191
Section X 192 Portal Server 6 2005Q1 • Deployment Planning Guide
