The 3.2 release of Solaris Cluster introduces an all-new Command
Line Interface (CLI) for managing the cluster. The new
command set includes many features that make it both easier
to use and more powerful than the command set found in earlier
releases of the product.
Of course, the familiar command set from earlier releases is still there in
3.2 and is still fully supported for those users who are not ready to
switch. All commands are still located in /usr/cluster/bin, so users
need not modify their PATH settings to find commands from either
set. Command names in the older command set all begin with the
prefix "sc", and command names in the new CLI all begin with the prefix
"cl". The two command sets are fully compatible with one another, so
users can intermix commands from both sets in the same shell script or
on the command line.
Early response from users of the new command set has been
overwhelmingly positive. But, we are sometimes asked, "Why a new CLI
for Solaris Cluster? What was wrong with the old one?" Not
too long ago, Sun conducted a comprehensive survey of Solaris Cluster
system administrators. The study revealed that the top set of issues
which administrators had with the cluster were mostly to do with the
command set. Sun felt that the best solution to the issues raised in
the study was to introduce an altogether new command set. Data from
that study, along with other customer feedback, was used to begin
design of a new CLI. The design underwent several phases of refinement
as we went back to customers with our ideas. And, finally, in-depth
usability studies were conducted before the final design was ready for
The new command set is "object-oriented". That is, there is a
different command for each type of cluster object that an administrator
might need to manage. For example, a user managing just resource
groups need only use the new "clresourcegroup" command to manage
groups. The "clresourcegroup" command can be used to create/delete
groups, set group properties, perform resource group switchovers, print
configuration and status reports, etc... Each new command supports
full management of all objects of the type that it controls.
The new command interfaces all use the same basic format:
cl<object_type> [<subcommand>] [<options>] [<objects>]
So, for example, to create a new resource group "rg1", one
might use either one of the following commands:
clresourcegroup create rg1
clresourcegroup create --property Description="My rg" rg1
Users will rely on subcommands for most things, although some options,
such as --help and --version, can be used without subcommands.
Most of the new commands also have built-in "aliases", or "short names".
Our customers told us that they wanted command names that were
descriptive and meaningful. But, they also told us that they
wanted command names that were short and easy to type. The Solaris
Cluster team felt that the best solution was to provide both. So,
most commands actually have two names to choose from, a descriptive
name and a short name. For example, "clrg" is the same as
clresourcegroup create rg1
clrg create rg1
From the examples above, you might have noticed that the new commands
accept long option names (e.g., --property, --help,
--version, ...). Long option names are useful, especially in
shell scripts, as they tend to be self-documenting. But, they can also
get in the way when issuing commands directly from the command line.
All of the new commands support both long-names and single-letters for
options. When specifying options, users may either use long option
names, with a double dash (--), or short option letters, with a
single dash (-). As an example, the following two commands do
exactly the same thing:
clrg create --property Description="My rg" rg1
clrg create -p Description="My rg" rg1
By now, you may thinking that this is pretty basic stuff and is very
similar to other commands that you have used. And, that is exactly
what we intended. The new Solaris Cluster command line interface is
designed to present a familiar interface. Commands are GNU-like, but
actually conform to the slightly stricter conventions of Sun's "Command
Line Interface Paradigm" (CLIP).
There isn't enough space here to describe all of the useful features
packed into the new command set. But, let's use a couple of simple
examples to quickly illustrate some of the other features that
we haven't yet touched upon.
Our first example deletes, then re-creates, all resources and groups
in a cluster:
# cluster export >clusterconfig.xml
# clrg delete --force +
# clrg create --input clusterconfig.xml +
# clrs create --input clusterconfig.xml +
# clrg online +
The first command in this example is "cluster export". Most of the
new commands support an "export" subcommand for exporting a copy
of selected cluster configuration data in XML format. The "cluster"
command is something of an "umbrella" command and can,
among other things, generate status and configuration reports for the
entire cluster by using it with its "status", "show",
or "export" subcommands.
Next, "clrg delete --force +" is used to delete all resources
and resource groups from the cluster. The force option tells the
command to delete all resource groups, even if groups still contain
resources. The "+" symbol can be used as an operand to most
commands as a sort of "wildcard character", to indicate all
objects of the type managed by the command.
The next two commands, "clrg create" and "clrs create" are used
to re-create all of the resource groups and resources described
in the "clusterconfig.xml" file created in the first step. As a
different approach, we could have actually left out this "clrg"
step and used the "--automatic" option in the "clrs" step to
automatically create any groups needed by the new resources.
Finally, all resource groups in the cluster are brought online
using "clrg online +".
This next example shows how a "string array" resource property
can be updated:
# clrs list-props --verbose myresource
Property Name Description
myuserlist This is a list of user names
# clrs set -p myuserlist+=user9,user10 myresource
"list-props" is a fairly helpful subcommand. It is used to list
property names and, if used with --verbose, their descriptions.
With "clrs", the default is to just list extension properties;
but, options are available to list standard properties as well.
In this example, we have used "clrs list-props" to list descriptions
of all extension properties for the resource called "myresource".
Finally, "clrs set" is used to update the "myuserlist" extension
property of resource "myresource". Notice that it is no longer
necessary to distinguish between "extension" and "standard"
properties when updating them on the command line (unless a resource
type uses an "extension" property name which collides with
a "standard" property name). Another useful feature is
that "string array" properties can now be updated without
having to re-specify the unchanged portion of the array.
The --property (-p) option to "clrs" supports all of the
following syntax for updating a "string array" resource
--property <property name>=<property value list>
--property <property name>+=<property value list>
--property <property name>-=<property value list>
Online man pages for the the new Solaris Cluster CLI can be found in
the "1CL" section of the
Sun Cluster Reference Manual for Solaris OS.
There are many more powerful features in the new command set that we
have not been able to touch on here. Let us know what you like best
about the new command set. And, of course, send us your suggestions
for improvements, too.
Sr. Staff Engineer
Solaris Cluster Engineering