Sun Cluster provides automatic failover of the domain administration server, node agents, Enterprise Serverinstances, and Message Queue. For more information, see the Sun Cluster Data Service for Sun Java System Application Server Guide for Solaris OS on docs.sun.com.
Use standard Ethernet interconnect and a subset of Sun Cluster products. This capability is included in Java ES.
You can use various techniques to manually recover individual subcomponents:
Loss of the Domain Administration Server (DAS) affects only administration. Enterprise Server clusters and applications will continue to run as before, even if the DAS is not reachable
Use any of the following methods to recover the DAS:
Run asadmin backup commands periodically, so you have periodic snapshots. After a hardware failure, install App Server on a new machine, with the same network identity and run asadmin restore from the back up created earlier. For more information, see Recreating the Domain Administration Server.
Put the domain installation and configuration on a shared and robust file system (NFS for example). If the primary DAS machine fails, a second machine is brought up with the same IP address and will take over with manual intervention or user supplied automation. Sun cluster uses a similar approach for making DAS fault-tolerant.
Zip the Enterprise Serverinstallation and domain root directory. Restore it on the new machine, assigning it the same network identity. This may be the simplest approach if you are using the file-based installation.
Restore from DAS backup. See the AS8.1 UR2 patch 4 instructions
There are two methods for recovering node agents and sever instances.
Keep a backup zip file. There are no explicit commands to back up the node agent and server instances. Simply create a zip file with the contents of the node agents directory. After failure, unzip the saved backup on a new machine with same host name and IP address. Use the same install directory location, OS, and so on. A file-based install, package-based install, or restored backup image must be present on the machine.
Manual recovery. You must use a new host with the same IP address.
Install the Enterprise Server with node agent on the machine.
Recreate the node agents. You do not need to create any server instances.
Synchronization will copy and update the configuration and data from the DAS.
There are no explicit commands to back up only a web server configuration. Simply zip the web server installation directory. After failure, unzip the saved backup on a new machine with the same network identity. If the new machine has a different IP address, update the DNS server or the routers.
This assumes that the web server is either reinstalled or restored from an image first.
The load balancer plugin (plugins directory) and configurations are in the web server installation directory, typically /opt/SUNWwbsvr. The web-install/web-instance/config directory contains the loadbalancer.xml file.
Message Queue (MQ) configurations and resources are stored in the DAS and can be synchronized to the instances. Any other data and configuration information is in the MQ directories, typically under /var/imq, so backup and restore these directories as required. The new machine must already contain the MQ installation. Be sure to start the MQ brokers as before when you restore a machine.
The HADB software is supplied with the Enterprise Server standalone distribution of Sun GlassFish Enterprise Server. For information about available distributions of Sun GlassFish Enterprise Server, see Distribution Types and Their Components in Sun GlassFish Enterprise Server 2.1 Installation Guide. HADB features are available only in the enterprise profile. For information about profiles, see Usage Profiles in Sun GlassFish Enterprise Server 2.1 Administration Guide.
If you have two active HADB nodes, you can configure two spare nodes (on separate machines), that can take over in case of failure. This is a cleaner method because backup and restore of HADB may result in stale sessions being restored.
For information on creating a database with spare nodes, see Creating a Database. For information on adding spare nodes to a database, see Adding Nodes. If recovery and self-repair fail, then the spare node takes over automatically.
This procedure has not been tested by Sun QA.
Use Veritas Netbackup to save an image of each machine. In the case of BPIP backup the four machines with web servers and Application Servers.
For each restored machine use the same configuration as the original, for example the same host name, IP address, and so on.
For file-based products such as Enterprise Server, backup and restore just the relevant directories. However, for package-based installs such as the web server image, you must backup and restore the entire machine. Packages are installed into the Solaris package database. So, if you only back up the directories and subsequently restore on to a new system, the result will be a "deployed" web server with no knowledge in the package database. This may cause problems with future patching or upgrading.
Do not manually copy and restore the Solaris package database. The other alternative is to backup an image of the machine after the components are installed, for example, web server. Call this the baseline tar file. When you make changes to the web server, back up these directories for example, under /opt/SUNWwbsvr. To restore, start with the baseline tar file and then copy over the web server directories that have been modified. Similarly, you can use this procedure for MQ (package-based install for BPIP). If you upgrade or patch the original machine be sure to create a new baseline tar file.
If the machine with the DAS goes down there will be a time when it is unavailable until you restore it.
The DAS is the central repository. When you restore server instances and restart them they will be synchronized with information from the DAS only. Hence, all changes must be performed via asadmin or Admin Console.
Daily backup image of HADB may not work, since the image may contain old application session state.
If the machine hosting the domain administration server (DAS) fails, you can recreate the DAS if you have previously backed up the DAS. To recreate a working copy of the DAS, you must have:
One machine (machine1) that contains the original DAS.
A second machine (machine2) that contains a cluster with server instances running applications and catering to clients. The cluster is configured using the DAS on the first machine.
A third backup machine (machine3) where the DAS needs to be recreated in case the first machine crashes.
You must maintain a backup of the DAS from the first machine. Use asadmin backup-domain to backup the current domain.
The following steps are required to migrate the Domain Administration Server from the first machine (machine1) to the third machine (machine3).
Install the Enterprise Server on the third machine just as it is installed on the first machine.
This is required so that the DAS can be properly restored on the third machine and there are no path conflicts.
Install the Enterprise Server administration package using the command-line (interactive) mode.
To activate the interactive command-line mode, invoke the installation program using the console option:
You must have root permission to install using the command-line interface.
Deselect the option to install default domain.
Restoration of backed up domains is only supported on two machines with same architecture and exactly the same installation paths (use same as-install and domain-root-dir on both machines).
Copy the backup ZIP file from the first machine into the domain-root-dir on the third machine.
You can also FTP the file.
Restore the ZIP file onto the third machine.
asadmin restore-domain --filename domain-root-dir/sjsas_backup_v00001.zip --clienthostname machine3 domain1
By specifying the --clienthostname option, you avoid the need to modify the jmx-connector element's client-hostname property in the domain.xml file.
You can backup any domain. However, while recreating the domain, the domain name should be same as the original.
Change domain-root-dir/domain1/generated/tmp directory permissions on the third machine to match the permissions of the same directory on first machine.
The default permissions of this directory are: drwx------ (or 700).
chmod 700 domain-root-dir/domain1/generated/tmp
The example above assumes you are backing up domain1. If you are backing up a domain by another name, you should replace domain1 above with the name of the domain being backed up.
In the domain-root-dir/domain1/config/domain.xml file on the third machine, update the value of the jms-service element's host attribute.
The original setting of this attribute is as follows:
Modify the setting of this attribute as follows:
Start the restored domain on machine3:
asadmin start-domain --user admin-user --password admin-password domain1
The DAS contacts all running node agents and provides the node agents with information for contacting the DAS. The node agents use this information to communicate with the DAS.
For any node agents that are not running when the DAS is restarted, change agent.das.host property value in as-install/nodeagents/nodeagent/agent/config/das.properties on machine2.
This step is not required for node agents that are running when the DAS is restarted.
Restart the node agent on machine2.
Start the cluster instances using the asadmin start-instance command to allow them to synchronize with the restored domain.