SIMS 3.5 requires that a SunDS 1.0 server with the proper schema run on the same host. This means that the SunDS server must also have the High Availability capability. Since SunDS 1.0 does not support the High Availability capability, SIMS/HA has incorporated a mechanism to have SunDS highly available. To accomplish this by default, SIMS installs SunDS on a shared disk. It then changes the /etc/rc?.d links so that start and stop operations are under the control of the SIMS/HA scripts.As an alternative, you may consider another method for installing SIMS/HA. That is, rather than considering SunDS as part of the Sun_Internet_Mail service and switching it back and forth between the two hosts in the cluster, you could install SunDS on each host, and set up SunDS replication to keep the two hosts in synchronization. To implement this configuration, you could make the SunDS on one of the hosts as the primary and the other host as the secondary.
A more symmetrical approach, however, would be to make both hosts secondaries of the primary that is not part of the cluster. In this configuration, however, a SIMS fail-over may cause the cached copy of the directory that SIMS not to match the directory on the new node (since there is no synchronization between SunDS and its replications).
To avoid this, installations should see that a full dirsync be run soon after a fail-over occurs. To restore the services as quickly as possible, however, the SIMS/HA interface scripts will not run a full dirsync automatically.
To allow installations to create directory configurations like this, SIMS/HA follows the same practice established in earlier releases of SIMS. That is, if SunDS is already installed when SIMS/HA installation is started, SIMS installation leaves the SunDS installation alone.
You have learned about the Sun High Availability configurations in this chapter. You may now follow the instructions covered in Chapter "Installing SIMS 3.5," to install your SIMS/HA system.