Compellent Technologies has partnered with Sun to offer Solaris Cluster certification on their Storage Center arrays. The interoperability matrix for Compellent is now listed at:
http://www.sun.com/software/cluster/osp/compellent_interop.xml
Compellent Technologies has partnered with Sun to offer Solaris Cluster certification on their Storage Center arrays. The interoperability matrix for Compellent is now listed at:
http://www.sun.com/software/cluster/osp/compellent_interop.xml
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!
This blog copyright 2009 by maddy