Developing New Data Services
Sun supplies configuration files and management methods templates that
enable you to make various applications operate as failover or scalable services
within a cluster. If Sun does not offer the application that you want to run
as a failover or scalable service, you have an alternative. Use a Sun Cluster
API or the DSET API to configure the application to run as a failover or scalable
service. However, not all applications can become a scalable service.
Characteristics of Scalable Services
A set of criteria determines whether an application can become a scalable
service. To determine if your application can become a scalable service, see Analyzing the Application for Suitability in Sun Cluster Data Services Developer’s Guide for Solaris OS.
This set of criteria is summarized as follows:
-
First, such a service is composed of one or more server instances. Each instance runs on a different node or zone. Two
or more instances of the same service cannot run on the same node or zone.
-
Second, if the service provides an external logical data store,
you must exercise caution. Concurrent access to this store from multiple server
instances must be synchronized to avoid losing updates or reading data as
it's being changed. Note the use of “external” to distinguish
the store from in-memory state. The term “logical” indicates that
the store appears as a single entity, although it might itself be replicated.
Furthermore, in this data store, when any server instance updates the data
store, this update is immediately “seen” by other instances.
The Sun Cluster software provides such an external storage through its
cluster file system and its global raw partitions. As an example, suppose
a service writes new data to an external log file or modifies existing data
in place. When multiple instances of this service run, each instance has access
to this external log, and each might simultaneously access this log. Each
instance must synchronize its access to this log, or else the instances interfere
with each other. The service could use ordinary Solaris file locking through fcntl and lockf to achieve the synchronization
that you want.
Another example of
this type of store is a back-end database, such as highly available Oracle Real Application Clusters Guard for
SPARC based clusters or Oracle. This type of back-end database server provides
built-in synchronization by using database query or update transactions. Therefore,
multiple server instances do not need to implement their own synchronization.
The Sun IMAP server is an example of a service that is not a scalable
service. The service updates a store, but that store is private and when multiple
IMAP instances write to this store, they overwrite each other because the
updates are not synchronized. The IMAP server must be rewritten to synchronize
concurrent access.
-
Finally, note that instances can have private data that is
disjoint from the data of other instances. In such a case, the service does
not need synchronized concurrent access because the data is private, and only
that instance can manipulate it. In this case, you must be careful not to
store this private data under the cluster file system because this data can
become globally accessible.
Data Service API and Data Service Development Library
API
The Sun Cluster software provides the following to make applications
highly available:
The Sun Cluster Data Services Planning and Administration Guide for Solaris OS describes
how to install and configure the data services that are supplied with the
Sun Cluster software. The Sun Cluster 3.1 9/04 Software Collection
for Solaris OS (SPARC Platform Edition) describes how to instrument
other applications to be highly available under the Sun Cluster framework.
The Sun Cluster APIs enable application developers to develop fault
monitors and scripts that start and stop data service instances. With these
tools, an application can be implemented as a failover or a scalable data
service. The Sun Cluster software provides a “generic” data service.
Use this generic data service to quickly generate an application's required
start and stop methods and to implement the data service as a failover or
scalable service.