Chapter 3 Preparing Your Installation Plan
After you have developed your implementation specifications, as described
in Chapter 2, Developing Your Implementation Specifications, you have the information you need to prepare your
installation plan. An installation plan lists all of the steps needed to install
and configure a Java ES solution. Your installation plan will list
all of the steps needed to implement your specific Java ES solution.
This chapter explains how to prepare your installation plan. You begin
with the information in the deployment architecture and the implementation
specifications, which describe the deployed state of your Java ES solution.
You analyze the information in these documents, and you determine how to use
the Java ES installer and the configuration wizards to implement
the solution described in the specification documents.
This chapter describes how to develop an installation plan in the following
sections:
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
|
Product Component
|
Dependencies
|
Nature of Dependency
|
Must be Local?
|
|
Access Manager
|
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 SDK
|
Access Manager
|
To provide the underlyingAccess 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
|
|
Access Manager Distributed Authentication
|
Access Manager
|
To provide the underlyingAccess 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
|
|
Access Manager Session Failover
|
Access Manager
|
To provide the underlyingAccess Manager services
|
No
|
|
Message Queue
|
To provide reliable asynchronous messaging
|
No
|
|
Application Server
|
Message Queue
|
To provide reliable asynchronous messaging
|
Yes
|
|
|
Web Server (optional)
|
To provide load balancing between Application Server instances
|
Yes
|
|
|
High Availability Session Store (optional)
|
To store session state, which supports failover between Application Server instances
|
Yes
|
|
Directory Proxy Server
|
Directory Server
|
To provide underlying LDAP directory services
|
No
|
|
Directory Server
|
None
|
|
|
|
High Availability Session Store
|
None
|
|
|
|
Java DB
|
None
|
|
|
|
Message Queue
|
Directory Server (Optional)
|
To store administered objects and persistent messages
|
No
|
|
|
J2EE web container, one of (Optional):
-Application Server
-Web Server
|
To support HTTP transport between clients and Message Broker
|
No
|
|
|
Sun Cluster (Optional)
|
To support use of Message Queue in high availability solutions
|
No
|
|
Portal Server
|
J2EE web container, one of:
-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
|
|
|
Service Registry Client
|
To provide libraries needed for compilation
|
No
|
|
Portal Server Secure Remote Access
|
Portal Server
|
To provide the underlying portal service.
|
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
|
|
Rewriter Proxy
|
Portal Server
|
To provide the underlying portal service.
|
No
|
|
Netlet Proxy
|
Portal Server
|
To provide the underlying portal service.
|
No
|
|
Service Registry
|
Application Server
|
To provide the necessary container service.
|
Yes
|
|
Service Registry Client
|
To provide the necessary client interface
|
Yes
|
|
Service Registry Client
|
None
|
|
|
|
Sun Cluster Software
|
None
|
|
|
|
Sun Cluster Agents
|
Sun Cluster
|
To provide underlying clustered services.
|
Yes
|
|
Sun Cluster Geographic Edition
|
Sun Cluster
|
To provide underlying clustered services.
|
Yes
|
|
Web Proxy Server
|
Web Server
|
To provide remote access to web applications running on Web Server
|
Yes
|
|
Directory Server (Optional)
|
To store user data used for authentication and authorization
|
No
|
|
Web Server
|
Directory Server (Optional)
|
To store user data used for authentication and authorization
|
No
|
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
Developing Your Installation Plan
Your deployment architecture and implementation specifications
describe the final state of your solution. The deployment architecture shows
you how many component instances are installed, which computer systems the
component instances are installed on, and how the component instances interoperate.
To reach the state described in the deployment architecture, you must install
and configure the component instances in your solution, one computer system
at a time, until you have installed and configured the complete solution.
Your installation plan must provide installation and configuration procedures
for every component instance in your solution, in the correct order.
To develop an installation and configuration plan, you must apply
your knowledge of component dependencies and other installation issues to
your Java ES deployment architecture and implementation specifications.
You must determine the correct sequence for installing and configuring the
component instances in your solution and the installation and the correct
configuration input values, which will achieve interoperation of the component
instances.
This section is a guide to analyzing a deployment architecture and set
of specifications and developing an installation plan. In general, you begin
as follows:
-
Open a text file, a blank sheet of paper, or some other medium
for recording your plan.
-
In your deployment architecture, examine the components on
each computer system and determine what component dependencies exist.
-
Identify the component instances that have no dependencies
on other components. These are typically instances of Directory Server.
You begin your installation plan with instructions for installing these component
instances on the specified computer systems. Begin your installation plan
by recording these computer systems, and the component instances installed
on them.
-
Determine the correct installation/configuration values in
your solution for these component instances on these specific computer systems.
Add these configuration values to your installation plan.
-
Among the remaining components, determine which components
have dependencies only on Directory Server. These are typically the computer
systems with Access Manager. List these computer systems next in your installation
plan.
-
Continue analyzing your specifications in order of component
dependencies. Determine the necessary configuration values, and record these
component instances in your plan.
For example, if you use this process to analyze the deployment architecture
illustrated in Figure 2–1, you develop
an installation plan that looks like Table 3–3.
Table 3–3 shows the first eight
steps of the installation plan. In order to make the structure of this plan
clear, the individual configuration values are not listed. In this plan, note
the following:
-
The plan lists the computers in the solution according to
the order in which the component instances will be installed and configured.
-
The sequence of installation is determined by applying both
solution-level dependencies and the local dependencies. Applying the solution-level
dependencies gives a basic sequence of Directory Server, Access Manager, Messaging Server,
and then Calendar Server. Applying the local Communications Express dependencies
to this sequence adds Web Server instances on computers AM1 and AM2, and
also Sun Cluster software and the Sun Cluster agents on computers mscs01
and mscs02.
-
The plan includes outlines of the installation and configuration
procedures for all of the redundancy strategies employed in Java ES solutions.
The list of tasks for DS1 and DS2 is an example of a plan for Directory Server multimaster
replication. The list of tasks for AM1 and AM2 is an example of a plan for
load balanced components. The list of tasks for STR1 and STR2 is an example
of a plan for components that run in a Sun Cluster configuration.
-
The tasks for STR1 and STR2 provide an example of installing
and configuring multiple components on one computer. The first time you run
the installer, you install the Sun Cluster core component. After you configure
the Sun Cluster core component, you run the installer again to install Messaging Server and Calendar Server.
These components are configured in order, according to their dependencies.
The third time you run the installer on the computer, it installs the Sun Cluster agents
for Messaging Server and Calendar Server, which depend on the presence
of Messaging Server and Calendar Server.
Table 3–3 Summary Installation Plan for the
Sample Deployment Architecture
|
Computer
|
Installation and Configuration Tasks
|
|
DS1
|
-
Run the Java ES installer on this computer. Install
and configure a Directory Server instance, using the configuration values
specified in the user management specification.
-
Start and verify the Directory Server instance.
|
|
DS2
|
-
Run the Java ES installer on this computer. Install
and configure a Directory Server instance with the configuration values
specified in the user management specification.
-
Start and verify the Directory Server instance.
-
Verify that the load balancer is working properly for both Directory Server instances.
-
Shut down the Directory Server instance in DS2. Leave the Directory Server instance
on DS1 running.
|
|
AM1
|
-
Run the Java ES installer on this computer. Install
and configure an Access Manager instance. Configure the Access Manager instance
to interoperate with the logical directory service created by the load balanced Directory Server instances.
-
Start and verify the Access Manager instance.
-
Configure the Access Manager instance for load balancing.
|
|
AM2
|
-
Run the Java ES installer on this computer. Install
and configure an Access Manager instance. Configure the Access Manager instance
to interoperate with the logical directory service created by the load balanced Directory Server instances.
-
Start and verify the Access Manager instance.
-
Configure the Access Manager instance for load balancing.
-
Use the Access Manager console to modify directory entries
for Access Manager.
-
Verify that the two Access Manager instances are working
correctly with load-balanced operation.
|
|
STR1
|
-
Run the Java ES installer. Install the Sun Cluster core
component.
-
Prepare the computer for Sun Cluster configuration. This
step includes creating and mounting file systems used by Sun Cluster software.
-
Run the Sun Cluster configuration wizard. Establish and
configure the cluster.
|
|
STR2
|
-
Run the Java ES installer. Install the Sun Cluster core
component.
-
Prepare the computer for Sun Cluster configuration. This
step includes creating and mounting file systems used by Sun Cluster software.
-
Run the Sun Cluster configuration wizard. Establish and
configure the cluster.
-
Complete the configuration of the Network Timing Protocol
(NTP) on STR1 and STR2.
-
Add the quorum device to the cluster (connected to both computers).
-
Create cluster file systems, and resource groups, set up virtual
host name and IP address.
-
Verify the cluster's failover capabilities.
|
|
STR1
|
-
Run the Java ES installer. Install Messaging Server and Calendar Server.
-
On computer DS1, run the Directory Server Preparation Tool.
-
Run the Messaging Server configuration wizard to create
a Messaging Server instance. Supply configuration values that create a
branch in the LDAP directory tree according to the user management specification.
Supply configuration values that configure the Messaging Server instance
to interoperate with the load-balanced Access Manager instances and load-balanced Directory Server instances.
-
Configure Messaging Server for single sign-on.
-
Start and verify the Messaging Server instance.
-
Run the Calendar Server configuration wizard to create
a Calendar Server instance. Supply configuration values that configure
the instance to use the LDAP branch created by Messaging Serverconfiguration
for user and group data. Supply configuration values that configure the Calendar Server instance
to interoperate with the load-balanced Access Manager instances and load-balanced Directory Server instances.
-
On computer STR2 create a Calendar Server user, user group,
and directory.
-
Edit the Calendar Server configuration file. Set configuration
parameters to use the virtual IP address instead of the computer's IP address.
-
Configure Calendar Server for single sign-on.
-
Start and verify the Calendar Server instance.
|
|
STR1
|
-
Run the Java ES installer. Install Sun Cluster Agent
for Messaging Server and Sun Cluster Agent for Calendar Server.
-
Using the Messaging Server agent, create and enable a Messaging Server resource.
-
Verify failover of the Messaging Server resource from STR1
to STR2.
-
Using the Calendar Server agent, create and enable a Calendar Server resource.
-
Verify failover of the Calendar Server resource from STR1
to STR2.
|
|
STR2
|
The instances you configured on mscs01 are automatically recognized
as shared resources.
|
Descargar este libro en PDF (755 KB)