Installation Planning Issues
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 each component instance 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.
Distributed Installations
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 a reliable portal service the architecture might require two instances of Portal 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.
Figure 3–1 Distributed Installation Procedure Example
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, for Access Manager to operate properly, it must have access to information about users and services that is provided by an LDAP directory. The installation and configuration procedure for Access Manager requires you to input URLs that enable Access Manager to interoperate with an already functioning directory service. Because of this dependency, you must install and configure Directory Server before you install and configure Access Manager.
-
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. You must plan to install a web container and start it up before you install and configure your web application components. You can use Web Server, Application Server, or some third-party web containers, but you must plan to have a web container on the computer when you install the web application component.
Tip –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.
-
Your architecture may call for components to 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 solution-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 solution-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, it provides a directory service that is available to all of the components in the solution. This type of dependency determines the solution-wide sequence for installing and configuring component instances-you must install and configure Directory Server before Access Manager. In your installation plan, solution-wide dependencies determine the overall sequence of installation and configuration steps. You can plan to install Directory Server first and then add components such as Access Manager that depend on the directory service.
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 web container services for the entire solution. If your distributed architecture specifies that you install Portal Server on a different computer than Access Manager, you must plan to install a web container on both computers. Each web container supports a different component locally. Therefore, in a distributed solution there is no single location for a web container to provide services for the entire solution, and you must plan to install web containers several times during your overall installation sequence.
To develop an installation plan for your solution, you analyze the deployment architecture that describes the 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 Your Installation Plan.
Table 3–1 Java ES Component Dependencies
Configuring for Interoperation
The goal of the installation and configuration process is a system of interoperating component instances. Since you install components and perform basic configuration on one computer at a time, you must determine in advance the configuration values that will result in successful interoperation with components on other computers.
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. 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 values that configure the Access Manager to interoperate with the LDAP directory you have already installed and configured.
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 determine in advance which installation and configuration values will lead to successful interoperation between your Access Manager instance and your Directory Server instance. You include these values in your installation plan. Then, when you are installing and configuring components, you type the values in your plan, and you successfully configure your components to interoperate with each other.
You might perform a sequence of installation and configuration tasks similar to the one illustrated in Figure 3–2.
Figure 3–2 Configuring Components to Interoperate
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.
Redundancy Strategies
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 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 STR1 and STR2, 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 data services for Messaging Server and Calendar Server. When the Sun Cluster data services are configured, the cluster nodes recognize the Messaging Server and Calendar Server instances.
-
Directory Server replication is also implemented in several steps. For example, when you implement multimaster replication 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, your installation plan must include procedures for installing multiple instances of a component and configuring the instances to operate as a single service.
LDAP Schema and LDAP Directory Tree Structure
Most Java ES solutions include Directory Server. When you install and configure a solution with Directory ServerDirectory Server you input values that establish both the directory schema and the directory tree structure. Your installation plan must list the input values that result in the correct LDAP schema and directory tree structure.
You specify you LDAP schema and your directory tree structure before you begin your installation plan. Your installation plan includes the values you type in when running the installer to create the specified schema and directory tree structure. For examples of schema and directory tree 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.
-
In solutions that include Communications Suite components, 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.
-
In solutions that include Communications Suite components, 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. You list the input values in 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. In your installation plan, you list 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. In your installation plan, you list 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. In your installation plan, you list the organization DN as one of the input values for all of the configuration wizards.
You take the names for the LDAP base suffix and email domain organization from your user management specification and add them to your installation plan. For more information about the user management specification, see Developing Your User Management Specifications.
Java ES Installer Behavior
This section describes some behaviors of the Java ES installer that affect installation planning.
The Installer is Local
The Java ES installer installs component software on one computer at a time. Most solutions are distributed, and you must run the installer more than once. Your installation plan must include procedures for each time you run the installer. This section describe how to analyze a deployment architecture and determine how many times you must run the installer to implement the architecture.
A few solutions are installed on one computer only, and the installation plans for these solutions provide procedures for running the installer only once. The solutions that require running the installer only once are the following:
-
A number of components 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:
-
In most cases, when you combine several components on one computer you run the installer only 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, your installation plan describes running the installer once on the computer and selecting all of the components specified for the computer.
Tip –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, you run the installer first. After you run installer, you complete the process by running the configuration wizards for the components not configured by the installer. In these cases, your 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, you must configure an instance of Web Server or Application Server before you can install any other component that will run in the web container. If your solution uses a third-party web container, you must install, start, and verify the web container, before you install the web-based Java ES components. Your installation plan must include procedures for 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. Your installation plan must include procedures for 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 Your Installation Plan.
Installer Operating Modes
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 configuration wizards. For components configured by the installer, your installation plan must include the configuration values you will input when you run the installer. For components that are configured after the installer runs, your installation plan must include procedures for running the configuration wizards and the configuration values you will input when you run the configuration wizards.
Tip –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. You create the instances after you run the installer, by running the component configuration wizards. Your installation plan must include procedures for running the configuration wizards and the configuration values you will input when you run the configuration wizards.
The configuration option you select applies to an entire installation session. If you want to install some components on the computer in Configure Now mode and some in Configure Later mode, you must run the installer more than once.
Installer Compatibility Checking
The Java ES installer performs some dependency and compatibility checking. However, the installer can only check the local computer. For example, if you are installing Access Manager in a distributed solution, the installer cannot check whether the remote Directory Server is compatible with the Access Manager you are installing.
Compatibility is unlikely to be an issue if you are installing and configuring an all-new solution, with all components from the same Java ES release. It might become an issue if you are adding a new component to an established solution, or building a Java ES solution around existing components. For example, if you are already using Directory Server, and you are building a solution using Access Manager and Portal Server around the existing Directory Server, compatibility among the components becomes an issue. You need to confirm that the components are compatible before you begin to install and configure new components.
-
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. In this situation, you are responsible for verifying that the remote component is compatible and in the proper running state.
-
Upgrading. The Java ES installer will check installed Application Server, Message Queue, HADB, and Java DB for compatibility with the components you are installing and ask if you want to upgrade the components 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 5 Installation Guide for UNIX.
Other Installation Issues
This section lists a number of specific issues that occur in some solutions with references to detailed information.
Table 3–2 Installation Issues to Consider|
Solution Requires |
Guidelines or Instructions |
|---|---|
|
Using Solaris 10 zones |
If you will be installing into Solaris 10 zones, refer to Appendix A, Java ES and Solaris 10 Zones. |
|
Using Directory Server encryption |
Configure LDAPS (SSL over LDAP) on the Directory Server instance. |
|
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 5 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 plug-in. In this case, the Apache Web Server must be installed and running before installing any Java ES components that depend on it. |
|
|
For a Schema 1 deployment, you cannot use Access Manager. |
|
|
Access Manager is required for single sign-on. |
|
|
Configuring High availability using HADB |
A summary of the procedures for setting up HADB for high availability is contained in Web and Application Services Example in Sun Java Enterprise System 5 Installation Guide for UNIX. |
|
Application Server load balancing |
An summary of the procedures for using the Application Server load balancing plug-in is contained inWeb and Application Services Example in Sun Java Enterprise System 5 Installation Guide for UNIX. |
|
Non-root ownership |
If non-root ownership will be required for Application Server or Web Server, refer to Non-Root Examples in Sun Java Enterprise System 5 Installation Guide for UNIX |
- © 2010, Oracle Corporation and/or its affiliates