|
| |
| Sun Java Enterprise System 2005Q4 Deployment Example: Telecommunications Provider Scenario | |
Chapter 5
The Installation and Configuration PlanThe goal of the installation and configuration process is the distributed system described in the deployment architecture. The distributed system is composed of component instances that run on multiple computers and interoperate with each other. To achieve a functioning distributed system, you must install the component instances on multiple computers and perform the basic configuration required to establish interoperation among the component instances.
To ensure that you achieve a functioning distributed system, you must develop an installation plan that uses the installer appropriately and considers the requirements of the components in the deployment. Your plan must describe the correct order for installing the component instances and performing basic configuration. The plan must also specify the configuration values that configure the components to interoperate.
This chapter describes the installation and configuration plan for the Telco deployment.
Installation and Configuration IssuesYou install Java ES components with the Java ES installer. The installer is able to configure some of the Java ES components at installation time. The other components are configured by running separate configuration tools after installation is complete.
Your installation and configuration procedures depend on the following factors:
Each of these factors is described in the following sections.
Installer Behavior
The Java ES installer uses Solaris pkgadd to transfer Java ES software to your computer system. The installer can install any number of Java ES components during a single installation session. The installer does not perform distributed installations. Therefore, to install and configure Java ES components on multiple computers, as called for in the Telco deployment architecture (Figure 3-6), you must run the installer on each computer used in your deployment until all of the components have been installed and configured.
Distributed Installations
The quality of service requirements for Java ES solutions lead to architectures that place component instances on more than one computer. For example, the Telco deployment achieves a reliable portal service by installing two instances of Portal Server on two computers (jesPAM1 and jesPAM2) and using a load balancer to establish a failover relationship between the two instances.
The Java ES installer, however operates on only one computer at a time. Therefore, when you install a distributed solution you must run the installer on every computer used in the solution.
In many cases you must install a component or components on a computer and then run a configuration tool to perform the basic configuration of the component. For example, in the Telco deployment, on the computer jesIMR1, you run the installer to install the Messaging Server software, and then you run a Messaging Server configuration program to configure an instance of the Message Transfer Agent.
Configuring for Interoperation
The goal of the installation process is a set of interoperating component instances. When you install components and perform basic instance configuration, you supply configuration values that result in component instance interoperation.
The configuration values that result in interoperation include such values as the URLs or port numbers that one component instance uses to communicate with another component instance and the administrator account IDs and password that one component instance uses to gain access to another component instance. For example, in the Telco deployment, the Access Manager instances must communicate with the Directory Server instances, so you configure the Access Manager instances with the URLs, administrator account ID, and password for the directory service instances in the deployment.
When you run the Java ES installer, it does not know what components are installed on other computers used in the deployment. For example, when you install Access Manager, the installer does not know where the appropriate LDAP directory is located. To ensure the success of your installation and configuration process, you must plan ahead and develop the information that you need to configure each component instance. For example, when you configure the Access Manager instances on jesPAM1 and jesPAM2, you will need the URLs, administrator IDs, and administrator passwords for the jesDPA directory service.
Configure Now and Configure Later
The Java ES installer is capable of configuring runnable instances of some components. To use the installer this way, you must run the installer in “configure now” mode and supply the necessary configuration values.
For components that cannot be configured at install time, you run the installer in configure later mode. After installation is complete, you run a configuration program for each component instance you are creating. For example, in the Telco deployment, on MCS1b, you run the installer in configure later mode to install Messaging Server and Calendar Server software. Then you run the Messaging Server configuration program to create an instance of the Message Store. Then you run the Calendar Server configuration program to configure and instance of the calendar store.
When you plan how to install and configure a solution, you need to plan the correct sequence of running the Java ES installer and running the configuration programs.
The installation and configuration plan for the Telco deployment uses the configure now option whenever it is possible to do so.
Component Dependencies
Some Java ES components cannot be installed and configured unless other components are installed and configured first. Dependencies occur for several reasons:
- Some components cannot function unless certain other components are installed and configured. For example, Portal Server Secure Remote Access functions as a gateway for a specific Portal Server instance. The configuration process for Portal Server Secure Remote Access requires input of URLs that enable Portal Server Secure Remote Access to interoperate with an already functioning Portal Server. Because of this dependency, Portal Server must be installed, configured, and running before Portal Server Secure Remote Access is installed and configured. In the Telco installation plan, this type of dependency determines the installation sequence for the Portal Server and Portal Server Secure Remote Access instances.
- A number of components require an LDAP directory for authentication and authorization. When you install and configure instances of these components you input the URL for the LDAP directory service. Because of this dependency, Directory Server must be installed and configured before the components that use the LDAP directory service. In the Telco installation plan, Directory Server is the first component installed and configured.
- Some components modify the configuration of an existing component. For example, installing and configuring Access Manager modifies the LDAP directory schema. If your solution uses Access Manager, you must plan to install and configure Directory Server before you install and configure Access Manager. In the Telco installation plan, Access Manager instances are installed and configured after the Directory Server instances.
- A number of Java ES components are web applications. These components must be deployed into web containers to function. The Telco deployment uses Web Server as a web container. The Java ES installer can install Web Server and the web application component in one installation session and automatically deploy the component to Web Server. This is how the components on jesPAM1 and PAM2 are installed.
- Java ES components can be installed in a high-availability cluster provided by Sun Cluster software. The Sun Cluster software must be installed and running before the other components are installed and configured. Then, after the Java ES components are installed and configured, you must install and configure the appropriate Sun Cluster agents for the Java ES components. In the Telco installation plan, this is how the components on jesMCS1b, jesMCS2b, jesMS1c, and jesMS2c are installed and configured.
The Telco deployment has examples of all these types of dependency.
Notice that some of these dependencies are solution-wide and some are local. You consider solution-wide dependencies and local dependencies differently when you plan how to install and configure a solution. The difference is described in the following example:
- The dependency of Access Manager on Directory Server is a system-wide dependency. When you install Access Manager, you supply a URL for a directory service that is provided by one more instances of Directory Server. Once Directory Server is installed and configured, the directory service is available to all components in the solution. This type of dependency is determines the system-wide sequence for installing and configuring component instances: the computers running Directory Server are installed and configured before the computers running Access Manager. System-wide dependencies determine the overall sequence of installation and configuration steps.
- The dependency of Access Manager on a web container is a local dependency. To satisfy this dependency, a web container must be installed on the computer that runs Access Manager. This web container, however, does not provide services for the entire solution. In a distributed solution, web containers are typically installed on multiple computers. You do not install a single web container that supports the entire deployment. You install web container instances where they are needed locally. Each web container supports a different component locally. Therefore, in a distributed solution there is no single location for web container installation, and there is no single point in the installation procedure installing the web container.
To develop an installation plan, you analyze the deployment architecture and identify the dependencies among the components. Your plan must install and configure the components in a sequence that satisfies all of the dependencies. In general, you can develop an overall sequence of installation steps from the solution-wide dependencies. Then you consider the local dependencies that might exist on each computer.
Distributed Subcomponents
Some Java ES components have subcomponents that can be separately installed and configured. For example, Messaging Server has four subcomponents, the Message Transfer Agent (MTA), the Message Multiplexor (MMP), Messenger Express Multiplexor (MEM), and Message Store. If the deployment architecture calls for these subcomponents to be installed on different computers, you must run the installer on each computer, in the correct sequence, and configure the subcomponents to interoperate.
The Telco deployment architecture places the Messaging Server subcomponents on separate computers to satisfy quality of service requirements. The Telco installation and configuration plan describes the correct sequence for installing and configuring these subcomponents.
Component Redundancy
The sequence of installation sessions and configuration procedures depends on how redundancy is being used in a deployment architecture. Redundancy can be used to achieve high availability, scalability, serviceability, or any combination of these service qualities. There are three technologies for using redundant components in the Java ES Telecommunications Provider architecture: load balancing, Sun Cluster, and Directory Server multimaster replication. Each has recommended configuration procedures that affect the sequence of installation sessions, as outlined briefly in the following paragraphs:
- Load balancing is best set up by installing and configuring one instance of a load-balanced component, testing that the service provided by the instance is accessible through the load balancer, and then installing and configuring additional instances of the same component. This phased approach facilitates troubleshooting of configuration problems.
- Sun Cluster software is set up by first installing the Sun Cluster core software on all cluster nodes before installing other components. For the Telco architecture, for example, Sun Cluster core must be installed and configured before installing and configuring Messaging Server and Calendar Server on the cluster nodes. Likewise, Messaging Server and Calendar Server must be configured before Sun Cluster agents are configured.
- Directory Server multimaster replication is best implemented by first installing and configuring one of the multimaster replicas, then installing and configuring all components that depend on Directory Server. Once such installations and configurations are completed, replicas of Directory Server can be installed and the system configured to provide synchronization and failover.
Each of these redundancy implementations implies a specific scoping and sequencing of installation sessions and configuration procedures.
LDAP Directory Tree
Installing and configuring a Java ES solution requires configuration values that establish the correct directory schema and directory tree structure. The schema and tree structure specified for the Telco deployment are described in The User Management Specification.
The installation and configuration plan contains the procedures for implementing the specified schema and directory tree.
Installation and Configuration Plan for the Telco DeploymentThis section summarizes the sequence of installation sessions and configuration procedures for the Telco deployment. The sequence is determined by considering all of the issues discussed in Installation and Configuration Issues.
The installation and configuration steps are grouped into modules. Each module contains the installation and configuration steps for one component subsystem in the Telco deployment architecture. The installation and configuration modules for the Telco deployment are listed in Table 5-1.
The configuration values that you input in each module are listed the detailed procedures for the modules, which are described in Software Installation and Configuration Procedures.
The sequencing of the modules is described below. The sequence is determined by the issues described in Installation and Configuration Issues.
Module 1a The Directory Server module is first, because other components are dependent on the directory service. Notice this module is actually in two parts, with the multimaster replication being implemented in Module 1b after all other services have been installed and configured. For more information see Component Redundancy.
Module 2 The Directory Proxy Server module comes next, because all other components access the directory through the directory proxy service.
Module 3 The Portal Server and Access Manager module comes next, because Messaging Server and Calendar Server depend upon the directory schema (Schema 2) that Access Manager sets up in the directory.
Module 4 Following the Directory Proxy Server module, a test user is created and a corresponding entry placed in the directory. A test user helps verify the remaining modules.
Modules 5 and 6 The two Messaging Server and Calendar Server back end modules are next because these service are accessed by most of the remaining components. This module is also complicated, because it includes Sun Cluster, and should be done early on to reduce risk.
Following the first six modules, the ordering of the remaining modules is more arbitrary.
Module 7 Portal Server Secure Remote Access.
Module 8 Delegated Administrator Console.
Modules 9 and 10 In these two modules, the various Message Transfer Agent instances are installed and configured. These instances are similar to each other. The have no dependencies on each other, so the order of these modules is not significant.
Each module, including its corresponding installation and configuration steps, is described more fully in Software Installation and Configuration Procedures.
Configuring Single Sign-on
There are two mechanisms by which single sign-on behavior is achieved in the Telco deployment: Access Manager SSO and proxy authentication. Both of these mechanisms are activated by the installation and configuration process.
- Access Manager SSO. Access Manager SSO is a mechanism that supports single sign-on for all web-based services. When Access Manager authenticates an end user successfully, the end-user's browser gets a cookie. If that end user subsequently tries to access another service, the browser passes the cookie, after confirming with Access Manager that the user session is still open, and Access Manager provides access to the service in question. To set up Access Manager SSO for the Telco deployment, you have to configure Messaging Server and Calendar Server components to use Access Manager SSO instead of their legacy authentication mechanisms. For detailed instructions on configuring Access Manager SSO, see Configure Messaging Server to support Access Manager single sign-on., and Configure Calendar Server to support Access Manager single sign-on..
- Proxy authentication. Proxy authentication means that some proxy user is authenticated on behalf of an end user that has logged in to the system.
Proxy authentication is used for populating the mail and calendar channels that appear in the portal desktop. A proxy user is authenticated by the Messaging Server and the Calendar Server on behalf of an end user who has logged in to Portal Server. For the Telco deployment, the proxy users are the Messaging Server administrator (admin) and the Calendar Server administrator (calmaster), respectively. To set up Portal Server proxy authentication, you use the Access Manager administration console to configure a Portal Server SSO adapter for each of these two Portal Desktop channels. You must also populate user entries with the attributes needed to support the Portal Server SSO adapter service. For detailed instructions on configuring proxy authentication, see Set up the SSO Adapter for the portal mail channel., and Set up the SSO Adapter for the portal calendar channel. In the Access Manager console:.
Proxy authentication is also used by the Messaging Server MEM component as an adjunct to Access Manager SSO. The user name is extracted from a valid cookie and access to Messaging Server is performed by the Messaging Server administrator (admin) on behalf of the user.
Protocols and Port Numbers Used
The following table shows the protocols used in the Telco deployment.
When the Java ES installer requests that you enter a port number, the installer performs a runtime check on the ports in use and displays an appropriate default value. If the default port number is being used by another component or by another instance of the same component, the installer presents an alternative value.
The following table lists the Java ES components used in the Telco deployment, the port numbers that each component uses, and the purpose of each port used. Standard ports that are not used in the deployment, such as those for secure SSL protocols, are not included in the table.
Note
Access Manager and Portal Server are not listed in this table because they use the port numbers of the web container into which they are deployed.