Out of Sync: Maddy's Blog

One of the coolest features in Solaris in my opinion is the "zoned" property of the ZFS. 

What does it do?

ZFS datasets can be exported to non-global zones using the "add dataset" property in zonecfg command. Now the user in the non-global zone may set setuid/symbolic links which are o.k. inside the non-global zone but not acceptable in global zone.  So zfs sets the "zoned" property automatically once the dataset is delegated to the non-global zone.   It doesn't get cleared automatically once you remove the delegation.  It has to be manually removed. If the property is not set off, sharing and other operations don't succeed on the global zone!

bash-3.00# zonecfg -z sparse-zone
zonecfg:sparse-zone> add dataset
zonecfg:sparse-zone:dataset> set name=test/testfs
zonecfg:sparse-zone:dataset> end
zonecfg:sparse-zone> exit
bash-3.00# zoneadm -z sparse-zone reboot
bash-3.00# zlogin sparse-zone
[Connected to zone 'sparse-zone' pts/1]
Last login: Tue Nov  3 00:09:04 on pts/1
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
# bash
bash-3.00# zfs list
NAME          USED  AVAIL  REFER  MOUNTPOINT
test          122K  19.6G    23K  /test
test/testfs    22K  19.6G    22K  /global/test
bash-3.00# exit
exit
# exit

[Connection to zone 'sparse-zone' pts/1 closed]
bash-3.00# zonecfg -z sparse-zone
zonecfg:sparse-zone> remove dataset
zonecfg:sparse-zone> exit
bash-3.00# zoneadm -z sparse-zone reboot
bash-3.00# zlogin sparse-zone
[Connected to zone 'sparse-zone' pts/1]
Last login: Tue Nov  3 01:58:01 on pts/1
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
# bash
bash-3.00# zfs list
no datasets available
bash-3.00# exit
# ^D
[Connection to zone 'sparse-zone' pts/1 closed]
bash-3.00# zfs sharenfs=on test/testfs
cannot set property for 'test/testfs': 'sharenfs' cannot be set on dataset in a non-global zone
bash-3.00# zfs set zoned=off test/testfs
bash-3.00# zfs sharenfs=on test/testfs
bash-3.00# dfshares
RESOURCE                                  SERVER ACCESS    TRANSPORT
   xxxxx:/global/test                  xxxxx  -         -

Really

Standalone QFS 4.6 FCS and later is supported as a failover filesystem in Solaris Containers managed by SC HA agent for Solaris Container 
with Solaris Cluster 3.2 2/08 and later.

This configuration is supported with Solaris 10 5/08 and later, on SPARC and x64, with HA Solaris Containers and HAStoragePlus. 

Zones as the choice of virtualization offers many benefits in Solaris Cluster by virtue of the many options available to suit every need.  But for some new users, it would be a tad confusing with all the options and which one to use for which situation.  I have tried to summarize my views in this blog on the best fit.

To start with, we'll list the options:

1. Failover Zone/ HA Zone

2. Zone node

3. Zone Cluster

How did we end up with so many solutions? The concept of zones is fairly new in Solaris, i.e, starting with Solaris 10.  As the feature matures, more features are added and accordingly the Sun Cluster product starts taking advantage of it.

Now, let us dive into the details!

FAILOVER ZONE/HA ZONE:

The first supported solution for zones on Solaris 10 with Sun Cluster was introduced with the Sun Cluster 3.1u4 release. It is a GDS agent that makes the zone failover from one cluster node to the other. Of course, it requires that the zone configuration on the nodes be identical and the zone be installed on the shared storage for enabling failover.  This solution also has an option of monitoring the applications running inside the zone using SMF. 

It also supports branded zones apart from native zone.  Solaris8, Solaris9 and lx branded zones can also be made HA. The SMF based monitoring is particularly useful for legacy applications that don't have a Sun Cluster agent but still requires HA. This solution has been used in the now famous "Flying Containers" presentations at various events!  GUUG-Frühjahrsfachgespräch 2008 Tutorium Teil 2: Flying Container (German). For over view on the technical implementation, refer to Sun Cluster and Solaris 10 Containers.

ZONE NODE:

The Sun Cluster 3.2 release, enabled zones to be treated like physical nodes to be part of RGs. On 3.2, cluster services are automatically started on any native zone installed and configured on a Sun Cluster node. For those applications that were supported on Solaris Containers, it provided HA out of the box! Hence it is best for those applications which are supported with containers and have a Sun Cluster agent but don't have the requirement of the zone itself failing over in case of a failure.

It is very helpful if you have the application running in a combination of physical nodes and zones. Also those applications which are scalable and have to hosted exclusively in zones.

ZONE CLUSTER:

The feature released in the latest Sun Cluster release SC 3.2u2, introduces a new brand of zone called "cluster".  It enables the administrator to create a set of identical "cluster" zones on various physical cluster nodes that form a virtual cluster.  The administrator can delegate devices and other resources to the Zone Cluster.

This solution is very useful in hosted environments.  A single physical cluster can be partitioned and many virtual clusters can  be created for hosting different applications/isolate the application and data. Refer to the blue print on Deploying Oracle RAC in Zone Clusters.

In summary, there are many options available in Sun Cluster for taking care of your application deployment in Solaris zones.  You can choose which is the best fit once you can understand the benefits of each and hopefully this article was helpful introduction!

Solaris Cluster 3.2 1/09 and later now supports the following application agents in Zone Clusters:

 -- Failover Apache and Scalable Apache versions packaged with Solaris 10u6, and later.

-- MySQL 5.0.77 and later 5.1.x versions as qualified with Solaris Cluster.

note: to deploy MySQL in a Zone Cluster, patch 126032-06 or later is required on SPARC; patch 126033-07 or later is required on x86.

These agents are all supported on SPARC and x86. They can be deployed alone on a cluster, or combined together (any number of each application, each instance in its own Solaris Container Cluster) to deploy one or more SAMP stacks on one physical cluster.

**The SUNW.gds resource type is supported in Zone Clusters. 

It means that you can create your own agent to run the application inside Zone Clusters.

The Solaris9 container support for Solaris Cluster 3.2 has been completed with the release of  patch 126020-02. With this all the 3 types of branded zones  -  Linux, Solaris8 and Solaris9  are supported on Solaris Cluster!