|
Replies:
11
-
Last Post:
Aug 28, 2007 3:55 PM
by: Prasad Dharmava...
|
|
|
Posts:
137
From:
GB
Registered:
6/1/07
|
|
|
|
Proposal: Project HA-Xen
Posted:
Aug 2, 2007 6:16 AM
To: Communities » ha-clusters » discuss
|
|
Hello everyone,
I would like to propose developing an agent to failover Xen Guest Domains ontop of OHAC.
The purpose of the agent is to provide workload management and high availability for supported Xen Guest Domains (DomU) ontop of OHAC. Currently supported configurations can be found here,
http://opensolaris.org/os/community/xen/docs/specs.html
We expect that the workload management aspect of the agent will allow a DomU to use migration or live migration.
We expect that the high availability aspect of the agent will failover a DomU in the event of a node failure.
More specifically if a DomU is being moved from one node to another, workload management will be performed first followed by high availability if a node fails while workload management is being performed.
Furthermore, we expect that the agent will,
- Allow start/stop and restart dependencies for DomUs across nodes.
- Allow for important DomUs where lesser DomUs are "offlined".
for both workload management and high availability.
If this proposal is approved, my intention is to also engage with the OpenSolaris Xen community.
Many thanks in advance for considering this proposal.
Regards
Neil
|
|
|
Posts:
241
From:
Registered:
5/29/07
|
|
|
|
Re: Proposal: Project HA-Xen
Posted:
Aug 2, 2007 7:05 AM
in response to: neilg
|
|
Hi Neil et al,
you have my +1 vote for this proposal.
Greets
Thorsten
Neil Garthwaite wrote:
> Hello everyone,
>
> I would like to propose developing an agent to failover Xen Guest Domains ontop of OHAC.
>
> The purpose of the agent is to provide workload management and high availability for supported Xen Guest Domains (DomU) ontop of OHAC. Currently supported configurations can be found here,
>
> http://opensolaris.org/os/community/xen/docs/specs.html
>
> We expect that the workload management aspect of the agent will allow a DomU to use migration or live migration.
>
> We expect that the high availability aspect of the agent will failover a DomU in the event of a node failure.
>
> More specifically if a DomU is being moved from one node to another, workload management will be performed first followed by high availability if a node fails while workload management is being performed.
>
> Furthermore, we expect that the agent will,
>
> - Allow start/stop and restart dependencies for DomUs across nodes.
> - Allow for important DomUs where lesser DomUs are "offlined".
>
> for both workload management and high availability.
>
> If this proposal is approved, my intention is to also engage with the OpenSolaris Xen community.
>
> Many thanks in advance for considering this proposal.
>
> Regards
> Neil
> --
>
> This message posted from opensolaris.org
>
> _______________________________________________
> ha-clusters-discuss mailing list
> ha-clusters-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
75
From:
Registered:
3/9/05
|
|
|
|
Re: Proposal: Project HA-Xen
Posted:
Aug 2, 2007 2:34 PM
in response to: frueauf
|
|
Hi Neil,
Could you expand a bit more on the interaction of the proposed
Agent with Xen DomU migration? The proposal says:
>> We expect that the workload management aspect of the agent will
allow a DomU to use migration or live migration.
Was the proposal that migration would be triggered by a "clrg
switchover" command and the Agent implementation would then perform the
migration underneath. Or, would the implementation actually support the
migration being done directly via the Xen admin commands?
Also, did not understand this point:
>> - Allow for important DomUs where lesser DomUs are "offlined".
Was that plugging into some existing Xen workload management
tools and essentially the proposal then is that the domUs under the
control of such a workload management facility would be "compatible"
in some fashion with the proposed Agent? Concretely, perhaps that may
mean that the Agent would be smart enough that it would understand the
fact that the domU has been offlined "intentionally" and hence would
not failover/restart it?
Rest looks good.
Thanks,
-ashu
> Neil Garthwaite wrote:
>> Hello everyone,
>>
>> I would like to propose developing an agent to failover Xen Guest Domains ontop of OHAC.
>>
>> The purpose of the agent is to provide workload management and high availability for supported Xen Guest Domains (DomU) ontop of OHAC. Currently supported configurations can be found here,
>>
>> http://opensolaris.org/os/community/xen/docs/specs.html
>>
>> We expect that the workload management aspect of the agent will allow a DomU to use migration or live migration.
>>
>> We expect that the high availability aspect of the agent will failover a DomU in the event of a node failure.
>>
>> More specifically if a DomU is being moved from one node to another, workload management will be performed first followed by high availability if a node fails while workload management is being performed.
>>
>> Furthermore, we expect that the agent will,
>>
>> - Allow start/stop and restart dependencies for DomUs across nodes.
>> - Allow for important DomUs where lesser DomUs are "offlined".
>>
>> for both workload management and high availability.
>>
>> If this proposal is approved, my intention is to also engage with the OpenSolaris Xen community.
>>
>> Many thanks in advance for considering this proposal.
>>
>> Regards
>> Neil
> _______________________________________________
> ha-clusters-discuss mailing list
> ha-clusters-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
137
From:
GB
Registered:
6/1/07
|
|
|
|
Re: Proposal: Project HA-Xen
Posted:
Aug 3, 2007 2:06 AM
in response to: ashu
To: Communities » ha-clusters » discuss
|
|
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
|
|
|
|
|
Posts:
69
From:
US
Registered:
8/8/05
|
|
|
|
Re: Proposal: Project HA-Xen
Posted:
Aug 3, 2007 3:11 AM
in response to: neilg
|
|
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 dot 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 dot Tsao at sun dot 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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
137
From:
GB
Registered:
6/1/07
|
|
|
|
Re: Proposal: Project HA-Xen
Posted:
Aug 3, 2007 3:59 AM
in response to: hstsao
|
|
Hi Dr. Tsao,
One could argue that anything is possible on OpenSolaris. I personally
like the recent quotes from Jonathan, i.e.
http://blogs.sun.com/jonathan/entry/sun_solaris_and_virtualization
"The objective of virtualization is to increase the level of utilization
in pursuit of more value, efficiency and affordability."
"Because this is all about efficiency - and the most efficient
virtualization solution is the one you didn't have to pay extra to use."
Concerning live migration, please note that I am _not_ suggesting that
SC/OHAC is required for live migration. If I may quote from the Xen v3.0
User Manual,
"To perform a live migration, both hosts must be running Xen / xend and
the destination host must have sufficient resources (e.g. memory
capacity) to accommodate the domain after the move.
Furthermore we currently require both source and destination machines to
be on the same L2 subnet.
Currently, there is no support for providing automatic remote access to
filesystems stored on local disk when a domain is migrated.
Administrators should choose an appropriate storage solution (i.e. SAN,
NAS, etc.) to ensure that domain filesystems are also available on their
destination node. GNBD is a good method for exporting a volume from one
machine to another. iSCSI can do a similar job, but is more complex to
set up."
Just to be clear, I am simply articulating that should a filesystem be
"accessible" to the destination node then if configured appropriately
the HA-Xen DomU resource would perform migration or live limgration as
the method for switchover. In this regard, a global file system could be
used as perhaps could shared QFS.
Regards
Neil
LaoTsao(Dr. Tsao) wrote:
> 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 dot org
>> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>>
>>
>
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
75
From:
Registered:
3/9/05
|
|
|
|
Re: Proposal: Project HA-Xen
Posted:
Aug 3, 2007 12:45 PM
in response to: neilg
|
|
Hi Neil,
Very cool. Glad that i asked about the "lesser DomUs being
offlined" thingie because, as you can see, i was taking it as
a completely different beast then what you had in mind.
Vote approval.
PS: For others in the community who might have similar questions such as
mine, is there a way to deposit a more detailed description of the
project somewhere on the community site? I didn't see a URL for this
proposed project anywhere in this e-mail thread, which leads me to
believe that this project exists only in this thread so far.
Thanks,
-ashu
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 dot org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Prasad Dharmava...
Prasad.Dharmavaram@S...
|
|
|
|
Re: Proposal: Project HA-Xen
Posted:
Aug 3, 2007 2:30 PM
in response to: ashu
|
|
Ashu,
Once the project gets the approval by the community leaders then it
will be sent to one of the opensolaris leaders who will create
a project page. From then on all the project documents can be
put in that web page.
e.g: you can see the HA-Informix community page here
http://opensolaris.org/os/project/ha-informix
Neil can add all this discussion later when the project page
is available.
--prasad
Ashutosh Tripathi wrote:
> Hi Neil,
>
> Very cool. Glad that i asked about the "lesser DomUs being
> offlined" thingie because, as you can see, i was taking it as
> a completely different beast then what you had in mind.
>
> Vote approval.
>
> PS: For others in the community who might have similar questions such as
> mine, is there a way to deposit a more detailed description of the
> project somewhere on the community site? I didn't see a URL for this
> proposed project anywhere in this e-mail thread, which leads me to
> believe that this project exists only in this thread so far.
>
> Thanks,
> -ashu
>
>
> 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 dot org
>> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
> _______________________________________________
> ha-clusters-discuss mailing list
> ha-clusters-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
75
From:
Registered:
3/9/05
|
|
|
|
Re: Proposal: Project HA-Xen
Posted:
Aug 6, 2007 1:10 PM
in response to: Prasad Dharmava...
|
|
Thanks Prasad,
Makes sense that the project page goes up AFTER it is
approved.
-ashu
Prasad Dharmavaram wrote:
> Ashu,
>
> Once the project gets the approval by the community leaders then it
> will be sent to one of the opensolaris leaders who will create
> a project page. From then on all the project documents can be
> put in that web page.
>
> e.g: you can see the HA-Informix community page here
>
> http://opensolaris.org/os/project/ha-informix
>
> Neil can add all this discussion later when the project page
> is available.
>
> --prasad
>
> Ashutosh Tripathi wrote:
>> Hi Neil,
>>
>> Very cool. Glad that i asked about the "lesser DomUs being
>> offlined" thingie because, as you can see, i was taking it as
>> a completely different beast then what you had in mind.
>>
>> Vote approval.
>>
>> PS: For others in the community who might have similar questions such as
>> mine, is there a way to deposit a more detailed description of the
>> project somewhere on the community site? I didn't see a URL for this
>> proposed project anywhere in this e-mail thread, which leads me to
>> believe that this project exists only in this thread so far.
>>
>> Thanks,
>> -ashu
>>
>>
>> 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 dot org
>>> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>> _______________________________________________
>> ha-clusters-discuss mailing list
>> ha-clusters-discuss at opensolaris dot org
>> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
> _______________________________________________
> ha-clusters-discuss mailing list
> ha-clusters-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
122
From:
DE
Registered:
5/30/07
|
|
|
|
Re: Proposal: Project HA-Xen
Posted:
Aug 28, 2007 4:12 AM
in response to: neilg
|
|
Hi Neil,
here is my +1 vote.
Detlef
Neil Garthwaite wrote:
> Hello everyone,
>
> I would like to propose developing an agent to failover Xen Guest Domains ontop of OHAC.
>
> The purpose of the agent is to provide workload management and high availability for supported Xen Guest Domains (DomU) ontop of OHAC. Currently supported configurations can be found here,
>
> http://opensolaris.org/os/community/xen/docs/specs.html
>
> We expect that the workload management aspect of the agent will allow a DomU to use migration or live migration.
>
> We expect that the high availability aspect of the agent will failover a DomU in the event of a node failure.
>
> More specifically if a DomU is being moved from one node to another, workload management will be performed first followed by high availability if a node fails while workload management is being performed.
>
> Furthermore, we expect that the agent will,
>
> - Allow start/stop and restart dependencies for DomUs across nodes.
> - Allow for important DomUs where lesser DomUs are "offlined".
>
> for both workload management and high availability.
>
> If this proposal is approved, my intention is to also engage with the OpenSolaris Xen community.
>
> Many thanks in advance for considering this proposal.
>
> Regards
> Neil
> --
>
> This message posted from opensolaris.org
>
> _______________________________________________
> ha-clusters-discuss mailing list
> ha-clusters-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Posts:
267
From:
US
Registered:
11/22/06
|
|
|
|
Re: Proposal: Project HA-Xen
Posted:
Aug 28, 2007 2:48 PM
in response to: ulherr
|
|
Neil,
Sorry for the delay in responding to this proposal -- I was on vacation
for three weeks.
I have some questions about the details, mostly stemming from my lack of
experience with Xen. However, I think it will be more appropriate to
discuss those questions once this project is instantiated. For now, I
think there's enough potential that we should definitely start a project
in this area.
So +1 from me.
It looks like we now have four +1s and no -1s almost four weeks after
the proposal went out. I don't think you set a timeout on the
discussion, but it certainly seems like this is long enough :-) If no
one objects, I think we can consider the proposal to be approved. Neil,
you can notify the OGB at your convenience.
Thanks,
Nick
detlef.ulherr wrote:
> Hi Neil,
>
> here is my +1 vote.
>
> Detlef
>
> Neil Garthwaite wrote:
>> Hello everyone,
>>
>> I would like to propose developing an agent to failover Xen Guest Domains ontop of OHAC.
>>
>> The purpose of the agent is to provide workload management and high availability for supported Xen Guest Domains (DomU) ontop of OHAC. Currently supported configurations can be found here,
>>
>> http://opensolaris.org/os/community/xen/docs/specs.html
>>
>> We expect that the workload management aspect of the agent will allow a DomU to use migration or live migration.
>>
>> We expect that the high availability aspect of the agent will failover a DomU in the event of a node failure.
>>
>> More specifically if a DomU is being moved from one node to another, workload management will be performed first followed by high availability if a node fails while workload management is being performed.
>>
>> Furthermore, we expect that the agent will,
>>
>> - Allow start/stop and restart dependencies for DomUs across nodes.
>> - Allow for important DomUs where lesser DomUs are "offlined".
>>
>> for both workload management and high availability.
>>
>> If this proposal is approved, my intention is to also engage with the OpenSolaris Xen community.
>>
>> Many thanks in advance for considering this proposal.
>>
>> Regards
>> Neil
>> --
>>
>> This message posted from opensolaris.org
>>
>> _______________________________________________
>> ha-clusters-discuss mailing list
>> ha-clusters-discuss at opensolaris dot org
>> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>>
>
> _______________________________________________
> ha-clusters-discuss mailing list
> ha-clusters-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
--
Nicholas Solter, Solaris Cluster Development
http://blogs.sun.com/nsolter
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
Prasad Dharmava...
Prasad.Dharmavaram@S...
|
|
|
|
Re: Proposal: Project HA-Xen
Posted:
Aug 28, 2007 3:55 PM
in response to: nsolter
|
|
+1 from me too for this project.
Thanks,
--prasad
Nicholas Solter wrote:
> Neil,
>
> Sorry for the delay in responding to this proposal -- I was on vacation
> for three weeks.
>
> I have some questions about the details, mostly stemming from my lack of
> experience with Xen. However, I think it will be more appropriate to
> discuss those questions once this project is instantiated. For now, I
> think there's enough potential that we should definitely start a project
> in this area.
>
> So +1 from me.
>
> It looks like we now have four +1s and no -1s almost four weeks after
> the proposal went out. I don't think you set a timeout on the
> discussion, but it certainly seems like this is long enough :-) If no
> one objects, I think we can consider the proposal to be approved. Neil,
> you can notify the OGB at your convenience.
>
> Thanks,
> Nick
>
> detlef.ulherr wrote:
>> Hi Neil,
>>
>> here is my +1 vote.
>>
>> Detlef
>>
>> Neil Garthwaite wrote:
>>> Hello everyone,
>>>
>>> I would like to propose developing an agent to failover Xen Guest Domains ontop of OHAC.
>>>
>>> The purpose of the agent is to provide workload management and high availability for supported Xen Guest Domains (DomU) ontop of OHAC. Currently supported configurations can be found here,
>>>
>>> http://opensolaris.org/os/community/xen/docs/specs.html
>>>
>>> We expect that the workload management aspect of the agent will allow a DomU to use migration or live migration.
>>>
>>> We expect that the high availability aspect of the agent will failover a DomU in the event of a node failure.
>>>
>>> More specifically if a DomU is being moved from one node to another, workload management will be performed first followed by high availability if a node fails while workload management is being performed.
>>>
>>> Furthermore, we expect that the agent will,
>>>
>>> - Allow start/stop and restart dependencies for DomUs across nodes.
>>> - Allow for important DomUs where lesser DomUs are "offlined".
>>>
>>> for both workload management and high availability.
>>>
>>> If this proposal is approved, my intention is to also engage with the OpenSolaris Xen community.
>>>
>>> Many thanks in advance for considering this proposal.
>>>
>>> Regards
>>> Neil
>>> --
>>>
>>> This message posted from opensolaris.org
>>>
>>> _______________________________________________
>>> ha-clusters-discuss mailing list
>>> ha-clusters-discuss at opensolaris dot org
>>> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>>>
>> _______________________________________________
>> ha-clusters-discuss mailing list
>> ha-clusters-discuss at opensolaris dot org
>> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
>
_______________________________________________
ha-clusters-discuss mailing list
ha-clusters-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
|
|
|
|
|
