Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2E698E21D for ; Thu, 28 Feb 2013 06:47:09 +0000 (UTC) Received: (qmail 18865 invoked by uid 500); 28 Feb 2013 06:47:08 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 18768 invoked by uid 500); 28 Feb 2013 06:47:07 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 18745 invoked by uid 99); 28 Feb 2013 06:47:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Feb 2013 06:47:07 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [72.51.28.127] (HELO webmail.bbits.ca) (72.51.28.127) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Feb 2013 06:46:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by webmail.bbits.ca (Postfix) with ESMTP id 7B791BF8002 for ; Wed, 27 Feb 2013 22:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at bbits.ca Received: from webmail.bbits.ca ([127.0.0.1]) by localhost (webmail.bbits.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuZwEMCH+4n7; Wed, 27 Feb 2013 22:46:32 -0800 (PST) Received: from [192.168.1.66] (d50-98-121-185.bchsia.telus.net [50.98.121.185]) by webmail.bbits.ca (Postfix) with ESMTPSA id 36EF93F80BA; Wed, 27 Feb 2013 22:46:32 -0800 (PST) References: <059a01ce156b$9c3b9ec0$d4b2dc40$@apache.org> <35F04D4C394874409D9BE4BF45AC5EA9010F3BAF65DA@BANPMAILBOX01.citrite.net> <059c01ce156f$44ba0d40$ce2e27c0$@apache.org> <6E004C34C1C59E45A35B4338808BC3150131E6E9B03E@SJCPMAILBOX01.citrite.net> <64FB1554ABC9B44FAA773FBD6CB889C2010D9C0309CE@BANPMAILBOX01.citrite.net> <2C97F788CCC013428671BC3A5FC2F64D15AC3D@c-mail.cloud-valley.com.cn> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Message-Id: Content-Transfer-Encoding: quoted-printable Cc: "cloudstack-dev@incubator.apache.org" X-Mailer: iPhone Mail (9B206) From: "Kelceydamage@bbits" Subject: Re: HA question Date: Wed, 27 Feb 2013 22:46:30 -0800 To: "cloudstack-dev@incubator.apache.org" X-Virus-Checked: Checked by ClamAV on apache.org This is turning out to be a great discussion to have. Now I get that CloudSt= ack HA is purely handled by the management/orchestration engine and only if= VM is tagged(which I knew). But what is good to find out is that it does no= t involve underlying hypervisor specific HA modules(except perhaps VMware). I= ncidentally VMwares HA mechanism is also called storage heartbeat(5.x+) but i= t uses hypervisor modules as well. I do agree with Ahmad that it might be worth looking into expanding our HA s= uite to support hypervisor specific HA modules as an override to the default= CS HA. There has not been too many HA discussions on the mailing list, and by the l= ooks of it we were all under slightly different impressions. Thanks again for the good discussion. Sent from my iPhone On Feb 27, 2013, at 9:48 PM, Ahmad Emneina wrote: > I would imagine it's best to leverage on the underlying hypervisors' HA > mechanisms, configured oud-of-band of cloudstack. I find cloudstacks > implementation a little laggy compared to the paid for variety. CloudStack= > does a well enough job to figure out which host the vm eventually lands on= . >=20 >=20 > On Wed, Feb 27, 2013 at 9:37 PM, Mice Xia wr= ote: >=20 >> Currently for xenserver/KVM, Cloudstack uses 'storage heartbeat' to detec= t >> whether it should start HA, i.e. agent resides on xenserver/KVM >> periodically writes a timestamp on shared storage, if host network >> pingTimeOut happens, Cloudstack will investigate if 'storage heartbeat' >> timeout and if that's the case HA job will be launched for HA enabled VMs= >> on the host. >>=20 >> It's a simplified procedure, HA implementation involves delta sync/ >> investigators and fencers. >>=20 >> -Mice >>=20 >> -----Original Message----- >> From: Sanjeev Neelarapu [mailto:sanjeev.neelarapu@citrix.com] >> Sent: Thursday, February 28, 2013 1:21 PM >> To: cloudstack-dev@incubator.apache.org; kdamage@apache.org >> Subject: RE: HA question >>=20 >> Hi Hari, >>=20 >> AFAIK, in CloudStack if a host crashes CloudStack would detect the host a= s >> down after pingTimeout interval. >> CloudStack does not reduce the available capacity because the host >> capacity values are not removed from op_host_capacity table. It assumes t= he >> host down is a temporary issue. >>=20 >> Thanks, >> Sanjeev >>=20 >> -----Original Message----- >> From: Hari Kannan [mailto:hari.kannan@citrix.com] >> Sent: Thursday, February 28, 2013 10:36 AM >> To: kdamage@apache.org; cloudstack-dev@incubator.apache.org >> Subject: RE: HA question >>=20 >> Hi Kelcey, >>=20 >> At the risk of stating the obvious, I just wish to re-iterate my earlier >> point - with CloudStack, HA is for VM, not for host. That is different th= an >> VMware's HA in someways - in VMware, if a cluster is HA, when any host >> crashes, all VMs on that host will be restarted on a different host. With= >> cloudstack, only VMs that are HA enabled will be restarted. >>=20 >> At least, that is the way I understand this.. >>=20 >> I also wonder what happens in CloudStack if a host crashes (assume there >> were no VMs on it) - would CloudStack detect this host is down and reduce= >> the available capacity? >>=20 >> Hari >>=20 >> -----Original Message----- >> From: Kelcey Damage (BT) [mailto:kelcey@backbonetechnology.com] On Behalf= >> Of kdamage@apache.org >> Sent: Wednesday, February 27, 2013 8:51 PM >> To: cloudstack-dev@incubator.apache.org >> Cc: Hari Kannan >> Subject: RE: HA question >>=20 >> So it's safe to conclude that HA while enabled on the host(As in the >> module), must be available cluster wide(uniform cluster). This is how >> VMware and others operate. >>=20 >> Thanks all. >>=20 >> -Kelcey >>=20 >>=20 >>> -----Original Message----- >>> From: Sateesh Chodapuneedi [mailto:sateesh.chodapuneedi@citrix.com] >>> Sent: Wednesday, February 27, 2013 8:46 PM >>> To: cloudstack-dev@incubator.apache.org >>> Cc: Hari Kannan >>> Subject: RE: HA question >>>=20 >>> For VMware, CloudStack uses native HA provided by VMware. >>> VMware provides HA at the level of cluster. >>>=20 >>> Regards, >>> Sateesh >>>=20 >>>> -----Original Message----- >>>> From: Nitin Mehta [mailto:Nitin.Mehta@citrix.com] >>>> Sent: 28 February 2013 10:13 >>>> To: cloudstack-dev@incubator.apache.org >>>> Cc: Hari Kannan >>>> Subject: Re: HA question >>>>=20 >>>> CS has its own HA logic and doesn't use the native HA of the HV and >>>> so the question for enabling the HA for hosts doesn't arise. This is >>>> true >> for XS. >>>> For Vmware and KVM, I will let the guru's speak :) >>>>=20 >>>> On 28/02/13 9:55 AM, "kdamage@apache.org" >>> wrote: >>>>=20 >>>>> Thanks that=C2=B9s awesome, but not quite the answer I was looking for= . >>>>>=20 >>>>> To better phrase my question, if the cluster is the basic unit of >>>>> availability, when hosts are enabled for HA, must all hosts in the >>>>> cluster be enabled? Or can the cluster exist with a non-uniform >>>>> structure, having only some hosts enabled for HA? >>>>>=20 >>>>> You partially answered it with the special reserve HA hosts, but I'm >>>>> looking more in terms of general use. >>>>>=20 >>>>> Thanks >>>>>=20 >>>>> -kelcey >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Hari Kannan [mailto:hari.kannan@citrix.com] >>>>>> Sent: Wednesday, February 27, 2013 8:21 PM >>>>>> To: cloudstack-dev@incubator.apache.org >>>>>> Subject: RE: HA question >>>>>>=20 >>>>>> Hi Kelsey, >>>>>>=20 >>>>>> HA is at 2 levels =C2=AD VMs can be marked HA. In addition, you can m= ark >>>>>> some hosts as reserved for =C2=B3Dedicated=C2=B2 HA hosts. Quoting fr= om the >>>>>> manual, the dedicated HA option is set through a special host tag >>>>>> when the host is created. >>>>>> To allow the administrator to dedicate hosts to only HA-enabled >>>>>> VMs, set the global configuration variable ha.tag to the desired >>>>>> tag (for example, "ha_host"), and restart the Management Server. >>>>>> Enter the value in the Host Tags field when adding the host(s) that >>>>>> you want to dedicate to HA-enabled VMs. >>>>>>=20 >>>>>> Hari >>>>>>=20 >>>>>> From: Kelcey Damage (BT) [mailto:kelcey@backbonetechnology.com] >>>>>> Sent: Wednesday, February 27, 2013 8:00 PM >>>>>> To: CloudStack dev list >>>>>> Subject: RE: HA question >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I can=C2=B9t remember, do we enable HA on a per host basis, or on a p= er >>>>>> cluster basis? >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> [cid:image001.png@01CE1524.FA0D61B0]Kelcey Damage Infrastructure >>>>>> Systems Architect >>>>=20 >>>>> www.backbonetechnology.com >>>>>> ------------------------------------------------------------------- >>>>>> - >>>>>> ----- >>>>=20 >>>>> kelcey@backbonetechnology.com>> m >>>>>>>=20 >>>>>>=20 >>>>>> address: 55 East 7th Ave, Vancouver, BC, V5T 1M4 >>>>>> tel: +1 604 713 8560 ext:114 >>>>>> fax: +1 604 605 0964 >>>>>> skype: kelcey.damage >>>>>>=20 >>>>>=20 >>>>>=20 >>=20 >>=20 >>=20