Logical Host Configuration Issues

A data service is made highly available by exploiting the Sun Cluster concept of a logical host. The data service's data is placed on a logical host's diskset. A diskset is dual-ported, making the data accessible by a surviving server in the event that one server fails. For network access by clients on the network, the data service advertises the logical host name as the server name that clients should use. A logical network IP address failover causes network clients of the data service to move with the logical host.

Data Service Use of Single or Multiple Logical Hosts

In Sun Cluster, there can be any number of logical hosts, so your data service implementation should not depend on a certain quantity. You must decide whether your data service will keep its data in just one or in multiple logical hosts.

Generally, it is easier to design and implement a data service that uses just one logical host. In that case, all of the data service's data is placed only on that logical host's diskset. The data service needs just one set of daemons. A physical host runs the daemons for that data service only if the physical host currently masters the single logical host that the data service uses. When the physical host takes over mastery of the logical host, the data service's start method can start up the daemons. When the physical host is giving up mastery of the logical host, the data service's stop method can stop the daemons. In some cases, killing the daemons by sending a kill signal will suffice.

If you use multiple logical hosts, you must be able to split the data service's data into disjoint sets. The sets must be split so that no operation the data service needs to perform requires data from more than one set.

Consider Sun's HA-NFS product, which has multiple file systems with different data residing in each file system. For HA-NFS, each logical host has its own set of NFS^(TM) file systems. Each physical host NFS shares the file systems that belong to the logical hosts that it masters. The sets of NFS file systems belonging to the two logical hosts are disjoint.

Using multiple logical hosts enables some rudimentary load balancing: when both physical hosts are up, each physical host can master one of the logical hosts and handles the data service's traffic for that logical host. Thus, both physical hosts are doing useful work in addition to acting as standbys for each other.

For some data services, splitting the data into disjoint collections such that no data service operation requires more than one collection is not feasible. The in.named example described in Chapter 2 "Sample Data Service", is such a data service. It has only one set of interdependent data files, and it would be difficult to split them into disjoint sets.

Configure the data service to use just one of the logical hosts, unless the data is easily split into disjoint collections and there is significant benefit to the rudimentary load balancing enabled by use of multiple logical hosts.

Required File System for Each Logical Host

Each Sun Cluster logical host has at least one diskset containing one or more file systems or raw partitions. Sun Cluster requires that each logical host has one file system that is special, in that it must exist and must have a particular name (that is, it must be mounted on a particular directory name in the name space hierarchy). When Sun Cluster is first installed and configured, the scconf(1M) program assists the administrator in creating the required file system, thus following the required convention. Sun Cluster uses the term administrative file system to refer to this special required file system.

Required Administrative File System Conventions

If your data service uses the administrative file system, it must adhere to the conventions described in this section.

Per Data-Service Subdirectory

Each data service should place its administrative data in its own subdirectory of the administrative file system. For example, if the data service uses Solaris packages, then the subdirectory should have a name of the form /administrative_file_system/PkgName, where PkgName is the name of your data service package.

If the package mechanism is not used, then the data service should use the same name that it supplied as its data service name when it registered with Sun Cluster using hareg(1M). The hareg(1M) utility detects and prohibits naming conflicts. If your implementation uses logical host "hahost1," and calls hareg(1M) with the name "hainnamed," you create the administrative subdirectory /hahost1/hainnamed.

Small Amount of Data

The administrative file system is relatively small. Each data service should limit the amount of administrative data it keeps in the administrative file system to a few kilobytes. If a larger amount of administrative data is required, use the administrative file system to point at another directory in one of the logical host's file systems. The data service's user data should not be stored in the administrative file system, because for most data services, that data would be too large.