Hi Geoff,
As an introduction I work on the Sun Cluster development team.
Questions about how to support the existing Sun Cluster product
can be sent to
sunclus...@sun.com
There are people that answer questions about the existing product.
Sun Cluster today supports non-global zone in two ways:
1) HA-Containers - this approach makes it look like the
non-global zone can fail over between machines. However,
this approach is NOT based upon detach a zone from one machine
and then attach the zone to another machine.
2) Another approach treats a non-global zone as a place where
applications can be started/halted under sun cluster control.
However, this approach does not provide isolation.
Sun Cluster will very, very, very soon ship SC3.2 update 2,
which introduces a new zone feature:
Zone Cluster - this is a virtual cluster where each virtual node
is a non-global zone. The application inside the Zone Cluster sees
the Zone Cluster as a dedicated private cluster. This feature
provides application fault isolation, security isolation,
resource management, and license fee cost containment. We provide
many ease-of-use features. I would be happy to provide details on
this new feature.
Sun Cluster supports the use of ZFS as the root file system with SC3.2u2.
Sun Cluster supports several approaches for changing software.
1. Halt all nodes. Install new software on each node. Boot all nodes.
2. Rolling Upgrade - halt one node at a time.
While in non-cluster mode, install new software on that
node. Reboot that node into cluster mode. Repeat process for each node
until done. A portion of the cluster remains up at all times.
3. Quantum Leap - Halt half the cluster and install new software
in non-cluster mode. The Quantum Leap then does a very quick handoff
of services from the partition with old software to the partition with
new software. Next upgrade this second partition.
Reboot the second partition in cluster mode, and the full cluster reforms.
We also support Live Upgrade.
So it is possible to change software with minimal down time.
All of these approaches can be used with patches, as well as update releases.
Approaches 1 & 3 always run a cluster with all nodes at the same release level.
Rolling Upgrade supports the situation where the different nodes
are at different OS & SC patch levels
(but does nothing for application patches).
Quantum Leap can be used to upgrade:
OS,
Sun Cluster,
3rd party File System or Volume Manager,
application software,
and any other software that you can put on a cluster.
At this point Sun Cluster does not have any need "patch on attach" function.
If you still believe that there is an important upgrade scenario,
that Sun Cluster does not support, please let me know.
I am the Technical Lead for the infrastructure area, which includes
both Zone Clusters and upgrade technology.
Regards,
Ellard Roush
On 01/22/09 11:40, Geoff Lane wrote:
> We are in the process of setting up a service consisting of SAN based global
> storage which will host a number of ZFS based zones, each running an
> application that must be nade highly avalable. The zones are made highly
> available using Solaris Cluster and failover. This is all rather standard
> and is
> described in the Sun zone/cluster docs. For technical reasons all the zones
> will be full root zones.
>
> However, we are having trouble finding a safe patching procedure that
> minimises application downtime. The zone docs tell us that a zone should be
> maintained as the same patch level as the global zone, but in a cluster this
> seems impossible without a total break in service. At some point the app
> zones will be running on one of the global zones forming the cluster but
> with mismatched patches.
>
> The "patch on attach" facility will be nice but is it going to work in a
> cluster. Will the cluster notice that the zone is very slow booting up and
> treat it as a failure? Even if cluster doesn't care, the apps are still down
> while the zone is being patched.
>
> Is there a soution that I've missed?
>
> Thanks,
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
