hi
with the upcoming opensource of all SC and QFS
it seem that we have the opps to build a VMS cluster like  cluster solutions
it is my understanding that in that environment there is no  HA-agents.
the infrastracture take care of the movement of the VIP and 
V-disk-group, mastered by the primary or secondary node.
using SMF, one should be able to take care of the interdependence of 
various resources.
One should able to integrate QFS into the base opensolaris and many SC 
feature like globaldevices could all be in opensolaris.
Is this possible?
As for live migration of xen, there seems work to achive this without SC 
framework:-(
my 2c


Neil Garthwaite wrote:

>Hi Ashu, 
>
>Concerning migration it would be triggered by a "clrg switch" command, 
>although migration or live migration would be resource specific. By this I 
>mean that when a "DomU resource" is registered with OHAC, the switchover 
>method will be determined, i.e. migration, live migration or just failover 
>(stop/relocate/start). However whatever method is chosen, the appropriate 
>method would be triggered by a "clrg switch" and implemented by the HA-Xen 
>agent. 
>
>There are some restrictions for migration, in that the DomU's virtual block 
>devices (VBD) need to be accessible by both nodes that are participating in 
>such a migration. One could think of "accessible" in terms of a global file 
>system. If a Zpool/ZFS was being used by a DomU's VBD list, then that 
>Zpool/ZFS would only be available to both nodes participating in a migration 
>and not accessible. In this regard, it's my belief that migration or live 
>migration would not be possible for a DomU using a Zpool/ZFS VBD. However, my 
>belief my change once we are engaged with the Xen community.
>
>Concerning placing a DomU offline. For those familiar with Solaris Cluster, 
>this is akin to RG_affinities and in particular a strong negative affinity. 
>For those not familiar with this terminology please see 
>http://blogs.sun.com/SC/entry/how_does_sun_cluster_decide for an informative 
>article about affinities. 
>
>With the above in mind, "Allow for important DomUs where lesser DomUs are 
>"offlined" means that using HA-Xen with OHAC and assuming a 2-node cluster, 
>under normal operations both nodes could be running several domUs. However, 
>some DomUs maybe more important than others and in the event of a node failure 
>it maybe desirable to favor an important DomU over another DomU. 
>
>Utilizing RG_affinities it would be possible to offline a less important DomU 
>in favor or an important DomU to free up system resources so that upon 
>failover the important DomU maintains a specific service level. 
>
>In summary, this is an important feature and one that already exists within 
>Solaris Cluster and therefore OHAC. However, in my opinion perhaps the 
>greatest strength of RG_affinities is the knowledge that one could utilize all 
>nodes thereby not having any idle nodes with the comfort of knowing that in 
>the event of a node failure, OHAC + HA-Xen will favor important DomUs over 
>lesser DomUs when using RG_affinities.
>
>Many thanks for your support with the remainder.
>
>Regards
>Neil
>--
>
>This message posted from opensolaris.org
>
>_______________________________________________
>ha-clusters-discuss mailing list
>ha-clusters-discuss at opensolaris.org
>http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>  
>

-- 
Hung-Sheng Tsao, Ph.D. (LaoTsao)       Sr. System Engineer
US, State Local & Education East        Data Center Ambassador
400 Atrium Dr, 1ST FLOOR                P/F:1877 319 0460 (x67079)
Somerset, NJ 08873                      C: 973 495 0840
http://blogs.sun.com/hstsao/            E:Hung-Sheng.Tsao at sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




Reply via email to