Before you install and configure the Sun ONE Application Server, use this section as a checklist in conjunction with “Data Service Configuration Worksheets and Examples” in Sun Cluster 3.1 Release Notes.
Consider the following restrictions and requirements before you start your installation.
Store static files and data on the local file system of each cluster node. Dynamic data should reside on the cluster file system so that you can view or update the data from any cluster node. The Sun ONE Application Server binaries and configuration files must be highly available and accessible to application server instances that are running on all nodes.
If you plan to use the Sun ONE Application Server as a service mastered on multiple nodes, you must set the HTTP and IIOP listeners to listen to the appropriate network resource. This setting is necessary because, by default, the Sun ONE Application Server behavior binds to all IP addresses on the node.
If you use the Solstice DiskSuiteTM/Solaris Volume Manager, configure the Sun ONE Application Server software to use UNIX®° file system (UFS) logging or raw-mirrored metadevices. See the Solstice DiskSuite/Solaris Volume Manager documentation for information on how to configure raw-mirrored metadevices.
You must set up the hostnames in your name services before you begin the Sun ONE Application Server installation. You must specify a network resource (IP address) that can fail over between nodes.
You must not remove or relocate any of the installed files or directories that the Sun ONE Application Server installation places on the cluster file system. For example, do not relocate any of the binaries that are installed with the Sun ONE Application Server software.
You must install the binaries on the local disks.
You must configure the network resources that clients use to access the data service and bring the logical hostnames online.
If you run the Sun ONE Application Server with another application server that uses the same network resources, configure the servers to listen on different ports. Configuring the listeners on different ports prevents a port conflict between the two servers.