cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Bergsma <r...@remi.nl>
Subject Re: [DISCUSS] XenServer and HA: the way forward
Date Tue, 05 May 2015 12:34:25 GMT
What if we follow the vendor here? Citrix supports XenServer 6.0.2 until
June 2018:
https://www.citrix.nl/support/product-lifecycle/product-matrix.html

In my opinion we should support it. I don't want to leave people at 4.3.x
because of this.

Regards,
Remi


Op di 5 mei 2015 om 13:28 schreef S. Brüseke - proIO GmbH <
s.brueseke@proio.com>:

> In my opinion the way we should go is "keep it simple". We really should
> consider to drop support for XenServer 6.0.2 here and not making things
> more complicated and provide more than 1 option.
> Of course it depends on how many CS installations are still using
> XenServer 6.0.2.!
> Can somebody give more information on this?
>
> Mit freundlichen Grüßen / With kind regards,
>
> Swen Brüseke
>
> -----Ursprüngliche Nachricht-----
> Von: Remi Bergsma [mailto:remi@remi.nl]
> Gesendet: Dienstag, 5. Mai 2015 12:36
> An: dev@cloudstack.apache.org
> Betreff: Re: [DISCUSS] XenServer and HA: the way forward
>
> Hi all,
>
> Thanks for pointing me to the proposal, Koushik. Too bad no one responded
> to such a major change.
>
> When I put my "Operations" hat on, I see several issues. First of all,
> there was no mention of this change in the release notes. Not as a new
> feature, nor as a bug that was fixed. How do we expect people that operate
> CloudStack will know about this? It's not even in the recommended install
> instructions for a new cloud today. In my experience, when I talk to people
> about this, I find that almost no one knows. We as a community can do
> better than this!
>
> For XenServer 6.5 and 6.2 one can enable XenHA for the pool only, but for
> XenServer 6.0.2 this is a different story because as far as I know one can
> only enable HA as a whole (HA on pool + HA on VMs). And this is only if you
> have the paid version, which we happen to have. But I don't think it is a
> solution, as this leads to corruption when XenServer and CloudStack try to
> recover the same VM at the same time (Trust me, I've been there). Why do we
> even "support" 6.0.2 one could ask?
>
> I still do have some XenServer 6.0.2 clusters running.. If the pool master
> crashes I need to manually appoint a new one. I don't like manual work and
> if I had known before I wouldn't have upgraded before this was resolved. Or
> do I miss something here?
>
> If we want to drop support for older XenServer versions, then let's vote
> for it and be very clear about it. Dropping XenServer 6.0.2 comes a bit too
> early if  you ask me.
>
> Let's discuss how to proceed. I still feel the best solution is to add a
> switch between both HA methods so one can choose which one suits best, and
> for older XenServer versions we will restore the HA feature that way.
>
> Any thoughts?
>
> Regards,
> Remi
>
> Op di 5 mei 2015 om 08:13 schreef Koushik Das <koushik.das@citrix.com>:
>
> > The below is the proposal for switching to XenServer HA.
> >
> >
> > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201403.mbox/%3
> > C83F77FF1BD50194AB65AFA5479D082A71E4E8D@SJCPEX01CL02.citrite.net%3E
> >
> >
> > On 04-May-2015, at 9:03 PM, Tim Mackey <tmackey@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 <remi@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.
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message