Please correct me if I am wrong, but does that mean that in CS 4.3 a crash of the pool master will disable the cluster for CS?!?
As a technician I feel more save to add a new host to a cluster using XenCenter because of shared storage, NICs and other stuff. CS then needs to discover the new host and add it to its system. If a pool master fails than CS should discover the new pool master like XenCenter is doing this. Mit freundlichen Grüßen / With kind regards, Swen Brüseke -----Ursprüngliche Nachricht----- Von: Koushik Das [mailto:koushik....@citrix.com] Gesendet: Dienstag, 5. Mai 2015 08:12 An: <dev@cloudstack.apache.org> Betreff: Re: [DISCUSS] XenServer and HA: the way forward The below is the proposal for switching to XenServer HA. http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201403.mbox/%3c83f77ff1bd50194ab65afa5479d082a71e4...@sjcpex01cl02.citrite.net%3E On 04-May-2015, at 9:03 PM, Tim Mackey <tmac...@gmail.com> wrote: > Thanks for starting this thread Remi. > > From my perspective the pros of simply enabling XenServer HA are: > > - automatic election of pool master in the event of hardware failure > - automatic fencing of a host in the event of dom0 corruption > - automatic fencing of a host in the event of heartbeat failure > > The risks of simply enabling XenServer HA are: > > - additional code to detect a newly elected pool master > - acceptance of the fact an admin can force a new pool master from > XenServer CLI > - requirement for pool size to be greater than 2 (pool size of 2 > results in semi-deterministic fencing which isn't user obvious) > - understanding that storage heartbeat can be shorter than storage > timeout (aggressive fencing) > - understanding that HA plans are computed even when no VMs are > protected (performance decrease) > > One question we'll want to decide on is who is the primary actor when > it comes to creating the pool since that will define the first pool master. > During my demo build using 4.4 at CCCEU I expected to add pool members > through the CS UI, but found that adding them in XenServer was required. > This left me in an indeterminate state wrt pool members. > > I vote that if a host is added to CS and it *is* already a member of a > pool, that the pool be imported as a cluster and any future membership > changes happen using CS APIs. If a host is added which isn't a member > of a pool, then the user be asked if they wish to add it to an > existing cluster (and behind the scenes add it to a pool), or create a > new cluster and add it to that cluster. This would be a change to the "add > host" semantics. > Once the host is added, we can enable XenServer HA on the pool if it > satisfies the requirements for XenServer HA (has shared storage and > three or more pool members). > > There are some details we'd want to take care of, but this flow makes > sense to me, and we could use it even with upgrades. > > -tim > > On Mon, May 4, 2015 at 6:04 AM, Remi Bergsma <r...@remi.nl> wrote: > >> Hi all, >> >> Since CloudStack 4.4 the implementation of HA in CloudStack was >> changed to use the XenHA feature of XenServer. As of 4.4, it is >> expected to have XenHA enabled for the pool (not for the VMs!) and so >> XenServer will be the one to elect a new pool master, whereas >> CloudStack did it before. Also, XenHA takes care of fencing the box >> instead of CloudStack should storage be unavailable. To be exact, >> they both try to fence but XenHA is usually faster. >> >> To be 100% clear: HA on VMs is in all cases done by CloudStack. It's >> just that without a pool master, no VMs will be recovered anyway. >> This brought some headaches to me, as first of all I didn't know. We >> probably need to document this somewhere. This is important, because >> without XenHA turned on you'll not get a new pool master (a behaviour >> change). >> >> Personally, I don't like the fact that we have "two captains" in case >> something goes wrong. But, some say they like this behaviour. I'm OK >> with both, as long as one can choose whatever suits their needs best. >> >> In Austin I talked to several people about this. We came up with the >> idea to have CloudStack check whether XenHA is on or not. If it is, >> it does the current 4.4+ behaviour (XenHA selects new pool master). >> When it is not, we do the CloudStack 4.3 behaviour where CloudStack is fully >> in control. >> >> I also talked to Tim Mackey and he wants to help implement this, but >> he doesn't have much time. The idea is to have someone else join in >> to code the change and then Tim will be able to help out on a >> regularly basis should we need in depth knowledge of XenServer or its >> implementation in CloudStack. >> >> Before we kick this off, I'd like to discuss and agree that this is >> the way forward. Also, if you're interested in joining this effort >> let me know and I'll kick it off. >> >> Regards, >> Remi >> - proIO GmbH - Geschäftsführer: Swen Brüseke Sitz der Gesellschaft: Frankfurt am Main USt-IdNr. DE 267 075 918 Registergericht: Frankfurt am Main - HRB 86239 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
