Designing Disaster Tolerant High Availability Clusters, 10th Edition, March 2003 (B7660-90013)

Building a Continental Cluster
Designing a Disaster Tolerant Architecture for use with ContinentalClusters
Chapter 5 195
• ContinentalClusters product is only responsible for the following:
ContinentalClusters configuration and management commands, the
monitoring of remote cluster status, and the notification of remote
cluster events.
• ContinentalClusters product provides a single recovery command to
start all recovery packages that are configured in the
ContinentalClusters configuration file. These recovery packages are
typical ServiceGuard's packages. ContinentalClusters recovery
command does not do any checking on the status of the devices and
data that are used by the application prior to starting the recovery
package. The user is responsible for checking the state of the devices
and the data before executing ContinentalClusters recovery
command.
Table 5-3 Data Replication and ContinentalClusters
Replication
Type
How it Works
ContinentalClusters
Implication
Logical
Database
Replication
Transactions from the
primary application are
applied from logs to a
copy of the application
running on the recovery
site. (This is an example
only; there are other
methods.)
Requirements on CPU and
I/O may limit or prevent the
Recovery Cluster from
running additional
applications.
Logical
Filesystem
Replication
Writes to the filesystem
on the primary cluster
are duplicated
periodically on the
recovery cluster.
CPU issues are the same as
for Logical Database
Replication. The software
may have to be managed as
a separate
MC/ServiceGuard package.
Physical
Replication of
Data Volumes
via Software
Disk mirroring via LVM
software. Mirroring is
done on disk links
(SCSI or
FibreChannel).
Requirements on CPU are
less than for logical
replication, but there is still
some CPU use. Distance
limits may make this type
of replication inappropriate
for ContinentalClusters.