The 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 that establishes interoperation among the component instances.
The procedures for installation and configuration are determined by the behavior of the Java ES installer and the requirements of the individual components. 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 used in the solution. 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 component instances to interoperate.
This section describes the major issues you must consider when developing an installation plan.
The quality-of-service requirements for production Java ES solutions lead to architectures that place component instances on more than one computer. For example, to achieve reliable messaging services the architecture might require two instances of Messaging Server on two different computers and use load balancing 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 configuration wizards to perform the basic configuration. You typically complete installation and configuration on one computer before you proceed to install and configure another set of components on another computer. To install and configure distributed component instances, you might perform a sequence of tasks similar to the one illustrated in Figure 3–1.
The goal of the installation process is a system of interoperating component instances. When you install components and perform basic 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 passwords that one component instance uses to authorize access to another component instance. For example, if your solution uses Access Manager, you must first install and configure an LDAP repository, such as a Directory Server instance. Then, when you install and configure an Access Manager instance, you must provide configuration values that tell the instance where to find the LDAP directory you prepared.
The Java ES installer does not know what components are installed on the other computers used in the solution. 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 in advance which components are installed on each computer. As you add a components to the solution, you configure them to interoperate with the components already installed on the other computers.
You might perform a sequence of installation and configuration tasks similar to the one illustrated in Figure 3–2.
Whatever the architecture of your solution, you must develop an installation plan that includes all the configuration values needed to configure the components and achieve an interoperating, distributed solution.
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, the Communications Express interface needs data supplied by messaging and/or calendar services. The configuration procedure for Communications Express requires input of URLs that enable Communications Express to interoperate with already functioning messaging and calendar services. Because of this dependency, Messaging Server and/or Calendar Server must be installed and configured before Communications Express is installed and configured.
A number of components require an LDAP directory for authentication and authorization. The installation and configuration procedures for instances of these components require input of URLs for the LDAP directory service. Because of this dependency, Directory Server (or some other identity repository) must be installed before the components that use the LDAP directory service.
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, your installation plan must specify that an LDAP directory is installed and configured before Access Manager is installed.
A number of Java ES components are web applications. These components must be deployed into web containers to function. A web container must be installed and running before the components are installed and configured. You can use Web Server, Application Server, or some third-party web containers, but a web container must be present on the computer when you install the web application component.
If the solution uses Web Server or Application Server, the Java ES installer can install the web container and the web application component at the same time and automatically deploy the web application component to the web container.
Components may 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. Additionally, the Sun Cluster Agents for the other components must be installed and configured.
Notice that some of these dependencies are solution-wide and some are local. You consider system-wide dependencies and local dependencies differently when you develop your installation plan. 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 provided by one or 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 determines the solution-wide sequence for installing and configuring component instances: Directory Server is installed and configured before Access Manager. In your installation plan, solution-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. 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 sequence for installing the web container.
To develop an installation plan for a solution, you analyze the deployment architecture that describes a solution and identify dependencies among the components. Your plan must install and configure components in a sequence that satisfies all of the dependencies. In general, you develop the overall installation sequence from the solution-wide dependencies. Then you consider the local dependencies that might exist on each computer.
The component dependencies are listed in Table 3–1. For more information about working with these dependencies, see the descriptions of the individual components in Developing an Installation Plan.
Table 3–1 Java ES Component Dependencies
Dependencies |
Nature of Dependency |
Must be Local? |
|
---|---|---|---|
Directory Server |
To store configuration data; to store and enable lookup of user data |
No |
|
J2EE web container, one of: -Application Server -Web Server -BEA WebLogic Server -IBM WebSphere Application Server |
Access Manager must be deployed to one of these web containers |
Yes |
|
Access Manager |
To provide Access Manager services |
No |
|
J2EE web container, one of: -Application Server -Web Server -BEA WebLogic Server -IBM WebSphere Application Server |
Access Manager SDK must be deployed to one of these web containers |
Yes |
|
Directory Server |
To provide a configuration directory |
No |
|
To provide reliable asynchronous messaging |
Yes |
||
To provide load balancing between Application Server instances |
Yes |
||
To store session state, which supports failover between Application Server instances |
Yes |
||
To store user data used for authentication and authorization |
No |
||
Prepares the LDAP directory for use with Calendar Server |
No |
||
Required if your solution uses single sign-on |
No |
||
To provide email notifications |
No |
||
To mange LDAP schema; to provision users of calendar services |
No |
||
-Application Server -Web Server |
Communications Express must be deployed to a web container |
Yes |
|
To store user data, such as address books |
No |
||
To prepare the LDAP directory for Communications Express |
No |
||
To provide authentication and authorization services and single sign-on; a local Access Manager SDK provides access to remote Access Manager |
Yes |
||
To provide underlying messaging service |
No |
||
To provide underlying calendar service |
No |
||
J2EE web container, one of: -Application Server -Web Server |
Delegated Administrator must be deployed to one of these web containers |
Yes |
|
Directory Server |
To store the LDAP data that Delegated Administrator works with |
No |
|
Directory Preparation Tool |
To prepare the LDAP directory for Delegated Administrator |
No |
|
Either Access Manager or Access Manager SDK |
To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager |
Yes |
|
Directory Server |
Directory Preparation Tool prepares the directory for use with Java ES communications components |
Yes |
|
Administration Server |
To configure Directory Proxy Server |
No |
|
Directory Server |
To provide underlying LDAP directory services |
No |
|
Administration Server |
To configure Directory Server |
No |
|
High Availability Session Store |
None | ||
Directory Server |
To store user, conference room, and news channel data |
No |
|
Access Manager or Access Manager SDK (optional) |
To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager |
Yes |
|
J2EE Web Container, one of: -Application Server -Web Server (required for delivery of Instant Messenger client resources) |
To support distribution and downloading of Instant Messenger client resources. |
Yes |
|
Calendar Server (optional, if calendar pop-ups feature is used) |
To support Calendar Server pop-ups |
No |
|
Messaging Server (optional, if offline delivery of instant messages is used) |
To support offline delivery of instant messages as email messages |
No |
|
Message Queue |
None | ||
Directory Server |
To store configuration data; To store and lookup user data for authentication and authorization |
No |
|
Administration Server |
To store configuration data in Directory Server configuration directory |
Yes |
|
Directory Preparation Tool |
To prepare the LDAP directory for Messaging Server |
No |
|
Access Manager (if your solution uses single sign-on) |
To provide single sign-on authentication and authorization service |
No |
|
Delegated Administrator (optional) |
To manage user and group data; to manage the directory schema |
No |
|
-Application Server -Web Server -BEA WebLogic Server -IBM WebSphere Application Server |
Portal Server must be deployed to one of these web containers |
Yes |
|
Directory Server |
To store user data used for authentication and authorization |
No |
|
Access Manager or Access Manager SDK |
To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager |
Yes |
|
Communications Express |
To provide messaging and calendar channels for the portal desktop |
No |
|
Portal Server |
To provide the underlying portal service. |
Yes |
|
Either Access Manager or Access Manager SDK |
To provide Access Manager services; a local Access Manager SDK provides access to a remote Access Manager |
Yes |
|
Service Registry |
Application Server |
Yes |
|
Sun Cluster Software |
None | ||
Sun Cluster |
To recognize components installed on Sun Cluster nodes |
Yes |
|
Web Server |
To provide remote access to web applications |
Yes |
|
Web Server |
None |
Most solutions intended for production use include some type of redundancy. Redundancy strategies use multiple instances of a component to provide a single service. Redundancy is used to satisfy quality of service requirements. For example, redundancy is used to increase throughput in order to satisfy performance requirements, or to avoid a single point of failure to in order satisfy reliability requirements.
Three strategies are available for using redundant instances of Java ES components: load balancing, clustering with Sun Cluster software, and Directory Server multi-master replication. The recommended installation and configuration procedure for each of these strategies is outlined briefly in the following paragraphs:
Load balancing can be implemented either in hardware or software. Load balancing is best set up by installing and configuring one instance of the load-balanced component, and then testing that the service provided by the first instance is available through the load balancer. After verifying that the service is available, you install and configure the additional instances of the component required by your deployment architecture. This phased approach to installing and configuring facilitates troubleshooting configuration problems.
Clustering is implemented in several steps. The first step is to install the Sun Cluster software and establish and configure the cluster. The next step is to install the components that run in the cluster. For example, the first step towards implementing the cluster shown in Figure 2–1 is installing Sun Cluster software on computers mscs01 and mscs02, and establishing and configuring the cluster. The second step is installing and configuring Messaging Server and Calendar Server. The third, and final, step is installing and configuring the Sun Cluster Agents for Messaging Server and Calendar Server. When the Sun Cluster Agents are configured, the cluster nodes recognize the Messaging Server and Calendar Server instances.
Directory Server multimaster replication is also implemented in several steps. The first step is installing, configuring, and verifying all of the Directory Server instances. The second step is shutting down all but one of the Directory Server instances. The third step is installing and configuring the other components in the solution. Any changes to the schema or directory structure are made to the single running Directory Server instance. The final step, after all component instances in the solution are installed, configured, and verified, is restarting the other instances of Directory Server and using the replication feature to configure synchronization and failover. This copies the modified and updated directory data to all of the Directory Server instances.
When your deployment architecture uses any of these redundancy strategies, you must develop a plan for installing multiple instances of a component and configuring the instances to operate as a single service.
Some Instant Messaging components have subcomponents that can be separately installed and configured. For example, Messaging Server has four subcomponents, Message Transfer Agent, Message Multiplexor (MMP), Messenger Express Multiplexor (MEM), and Message Store. A deployment architecture might place these subcomponents on separate computer systems to satisfy quality of service reasons. For example, the sample architecture in Figure 2–1 places instances of MEM on computer systems CX1 and CX2, outbound Message Transfer Agent on computer systems MTA1 and MTA2, the inbound Message Transfer Agent on computer systems MTA3 and MTA4, the MMP on computer systems MMP1 and MMP2, and the message store on computer systems STR1 and STR2.
Table 3–2 lists the Java ES components that have separately installable subcomponents. Analyze the deployment architecture for your solution and determine whether it uses distributed subcomponents. If your solution uses distributed subcomponents, you need to develop a plan to install the subcomponents on the correct computer systems, in the correct order, and configure the subcomponents to interoperate. For more information on configuring distributed subcomponents, see the descriptions of individual components in Developing an Installation Plan.
Table 3–2 Components with subcomponents
Component |
Subcomponent |
---|---|
Instant Messaging Multiplexor Instant Messaging Resources Instant Messaging Server |
|
Message Transfer Agent (MTA) Message Store Messaging Multiplexor (MMP) Messenger Express Multiplexor (MEM) |
Subcomponents are separately installable. If your deployment architecture calls for distributed subcomponents, run the installer on each computer and select the subcomponents specified in the architecture. The input values required by the installer or configuration wizard are a subset of values for the complete component. For the components that are not configured by the installer, start the configuration wizard, select the subcomponents to be configured on the computer and supply the input values required by the configuration wizard.
Most Java ES solutions include Directory Server. Installing and configuring a solution requires input values that establish both the directory schema and the directory tree structure. Your installation plan must list input values that result in the correct LDAP schema and directory tree structure.
The LDAP schema and directory tree structure are specified before you begin the installation plan. For examples of specifications, see Developing Your User Management Specifications.
The LDAP schema is established by the following installation and configuration processes:
Installing Directory Server automatically establishes a directory with Schema 1. No input is required to select the schema.
Installing Access Manager automatically modifies the directory, and converts it to Schema 2. No input is required to select the schema.
Running the Directory Preparation Tool extends the schema for use with Messaging Server, Calendar Server, and Communications Express. The Directory Preparation Tool extends both Schema 1 and Schema 2 directories. Input values for the Directory Preparation Tool are listed in your installation plan.
Running Delegated Administrator extends the schema with object classes and attributes used to authorize and authenticate users for specific services. The input values depend on the service provided by your solution. The input values are listed in your installation plan. For more information on the input values, see Adding Procedures for Delegated Administrator to Your Installation Plan.
The installation and configuration process also establishes the basic directory tree structure:
Installing Directory Server creates the base suffix, or directory tree root. The base suffix is a required input value when the Java ES installer installs Directory Server. Your installation plan lists the base suffix as one of the input values for the installation process.
Installing and configuring Messaging Server branches the directory tree and creates an LDAP organization. This organization represents the email domain managed by the Messaging Server instance. The name of the organization is a required input for the Messaging Server configuration wizard. Your installation plan lists the organization DN as one of the input values for the Messaging Server configuration process.
Installing and configuring Calendar Server, Communications Express, Delegated Administrator, and Instant Messaging specifies where in the directory these components look up user data. An LDAP DN is required input for each component's configuration wizard, and your installation plan lists the DN as an input value for each configuration wizard. If the solution uses Access Manager single sign-on, all of these components must be configured to use the same location for user data, which is the organization that the Messaging Server configuration wizard created. The same LDAP DN is input in all of these configuration wizards. Your installation plan lists the organization DN as one of the input values for all of the configuration wizards.
The names for the LDAP base suffix and email domain organization are taken from the user management specification and added to the installation plan. For more information about the user management specification, see Developing Your User Management Specifications. For more information about adding the LDAP base suffix to your installation plan, see Table 3–5. For more information about adding the email domain organization to your installation plan, see Table 3–9, Table 3–10, Table 3–11, Table 3–13, and Table 3–14.
This section describes some behaviors of the Java ES installer that affect installation planning.
The Java ES installer installs component software on one computer at a time. For most solutions, this means the installer runs more than once. The installation plan must indicate how many times to run the installer. This section describe how to analyze a deployment architecture and determine how many times the installer is run to install and configure a solution.
A few solutions are installed on one computer only, and the installation plans for these solutions provide procedures for running the installer runs only once. The solutions that require running the installer only once are the following:
A number of component are installed on one computer to evaluate Java ES features
One component instance is added to an established solution. This includes adding component instances that have dependencies on existing components.
Most solutions are distributed across several computers. Installation plans for these solutions must describe running the installer multiple times to install and configure the complete solution. To analyze these solutions, use the following guidelines:
Most combinations of components on a computer can be installed by running the installer once. This is particularly true if the installer runs in configure now mode, because in configure now mode, the installer can install both a web container and the component that runs in the web container. In these cases, the installation plan describes running the installer once on the computer and selecting all of the components specified for the computer.
Some components cannot be configured by the installer, even in configure now mode. When these components are installed on a computer, the configuration process is completed by running a configuration wizard for each component. When these components are installed in combination with components that are configured by the installer, the installer runs first. After the installer runs, the process is completed by running the configuration wizards for those components not configured by the installer. In these cases, the installation plan must describe running the installer and the correct sequence for running the configuration wizards.
Some combinations of components can only be installed by running the installer more than once on a computer. These combinations include the following:
Some component combinations that include a web container. If Web Server or Application Server is installed in configure later mode, an instance of Web Server or Application Server must be configured and verified before the component that runs in the web server can be installed. If the solution uses third-party web containers, the web container must be installed with its own installer, started, and verified, before the Java ES components are installed. The installation plan must describe running the installer multiple times on each computer.
Component combinations that use Sun Cluster software. If the components installed into the cluster are installed on a cluster file system, the Sun Cluster software must be installed and the cluster file system created before other components can be installed in the cluster nodes. The installation plan must describe running the installer multiple times on each computer.
The purpose of this section is to introduce the idea that installation plans must sometimes describe running the installer and the configuration wizards on one computer, or running the installer multiple times on one computer. For more information on the actual installation procedures for different component combinations, see Developing an Installation Plan.
The installer runs in two different modes, known as configure now and configure later. The modes differ in the following ways:
In configure now mode, the installer configures runnable instances of some, but not all, components. The components configured in configure now mode can be started and verified as soon as the installer completes. Runnable instances of the remaining components are created after the installer runs, by running component product configuration wizards. For components configured by the installer, the installer requires input of the configuration values, and the installation plan lists the configuration values as part of the instructions for running the installer. For components configured after the installer runs, the configuration values are required input for the configuration wizards, and the configuration values are listed as part of the instructions for running the configuration wizards.
A significant feature of configure now mode is its ability to install a web container and components that run in the web container at the same time. The installer automatically deploys the components to the web container.
In configure later mode, the installer copies component software files to the computer but does not create runnable instances. Instances are created after the installer runs, by running the component product configuration wizards. The configuration values are required input for the configuration wizards, and the configuration values are listed as part of the instructions for running the configuration wizards.
The selected configuration option applies to an entire installation session. If you need to select different configuration options for some components, you might need to run additional installation sessions.
The installer performs some dependency and compatibility checking. Can only check what is installed locally. For example, if your solution is using a remote Directory Server instance, the installer cannot check whether the remote Directory Server is compatible with the Access Manager you are installing. If you are installing and configuring an all-new solution. It might be an issue if you are adding a new component to an established solution, or building a Sun Java System around existing components. For example, if you are already using Directory Server, and you are building a solution using Access Manager, Messaging Server, Calendar Server, and Communications Express around the existing Directory Server, compatibility among the components becomes an issue.
Component Dependency Checking. The Java ES installer will prevent you from omitting components that are required by other components you have selected for installation, but only on the local host. In a distributed solution, the installer does not check the remote host to verify that the remote component is there. You are responsible for verifying that the remote component is compatible and in the proper running state.
Upgrading. The Java ES installer does not perform any component upgrading except when Application Server and Message Queue have already been installed with the Solaris OS. In this case, the installer asks if you want to upgrade Application Server and Message Queue during installation.
The Java ES installer does perform upgrade of shared components. For more information of this topic, see Surveying Existing Hosts in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.
This section lists a number of specific issues that occur in some solutions with references to detailed information.
Table 3–3 Installation Issues to Consider
Solution Requires |
Guidelines or Instructions |
---|---|
Using Solaris 10 zones |
If you will be installing into Solaris 10 zones, refer to Solaris 10 Zones in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX. |
Using Directory Server encryption |
Configuring LDAPS (SSL over LDAP) on the Directory Server instance Note: If Directory Server encryption is a requirement, Administration Server must be installed when Directory Server is installed. |
Third-party web containers (BEA WebLogic Server or IBM WebSphere Application Server) can be used with Portal Server and Access Manager. These containers must be installed and running before installing any Java ES components that depend on them. To use a third-party web container for Access Manager SDK, you must configure Access Manager SDK manually after installation. See Access Manager SDK With Container Configuration Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX Note: Portal Server can only use third-party web containers on Solaris OS. Note: Access Manager and Portal Server should use the same type of web container. |
|
The Apache Web Server can be used with the Application Server load balancing plugin. In this case, the Apache Web Server must be installed and running before installing any Java ES components that depend on it. For additional information, refer to Installation Prerequisites in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX. |
|
An installation example based on LDAP Schema 1 is described in Calendar-Messaging Schema 1 Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX. For a Schema 1 deployment, you cannot use Access Manager. |
|
Procedures for setting up single sign-on, can be found in the Chapter 8, Configuring and Using Single Sign-On, in Sun Java Enterprise System 2005Q1 Deployment Example Series: Evaluation Scenario. Access Manager is required for single sign-on. |
|
Configuring High availability using HADB |
An example of setting up HADB for high availability is contained in Web and Application Services Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX. |
Application Serverload balancing |
An example that includes using the Application Server load balancing plugin is contained inWeb and Application Services Example in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX. |
Non-root ownership |
If non-root ownership will be required for Application Server or Web Server, refer to one of the following examples: |