Open Stack

I think the lines are blurring slightly.

It's not the responsibility of the infrastructure layer to ensure that the application layer self-heals after an unscheduled reboot. 

I don't think that a HA feature should be left out because there are applications that may not heal, The discussion of infrastructure choice sits with the application administrator and not the infrastructure developer - you guys.

The openstack team is making good ground, but there's a key 'cloud' function missing and its HA. 


On 03/04/2011, at 6:59 PM, Diego Parrilla wrote:

> +1
> 
> Some people think Cloud means 'magic' and failed physical instances should recover to the previous state. Most of the times this is not possible at app level, and I wonder if desirable.
> 
> Still, Nova lacks of features like 'HA' instances and instances running on remote block storage (like EBS backed instances in AWS).I think this is basic for self-healing features needed for real DR.
> 
> 
> Enviado desde mi iPad
> 
> El 02/04/2011, a las 22:46, Jesse Andrews <anotherjesse at gmail.com> escribió:
> 
>> What to do when an instance dies is application specific.
>> 
>> Some applications may not care, autoscaling back to the proper size by themselves. Other applications may need the resources to be returned in the most recent state.
>> 
>> Currently openstack requires the user to handle recovery.
>> 
>> I expect there will be an option to mark a virtual machine as "HA" which would attempt to relaunch on crashes. How exactly to implement it will depend on the cloud requirements. If the instances are backed to a SAN or distributed filesystem (like ceph) the VM can be relaunched with all state that has been flushed to disk. On a cloud with local disk only, the scheduled snapshotting could allow the vm to a recent state.
>> 
>> Or HA could mean relaunch the image (ala autoscale)
>> 
>> What use case are you thinking about?
>> 
>> Jesse
>> 
>> On Apr 2, 2011 1:33 PM, "Marek Denis" <marek at octogan.net> wrote:
>> > Hello,
>> > 
>> > I have been trying to find out some info about features OpenStack 
>> > provide and still cannot figure out whether 'cloud features' are 
>> > available by default. By 'cloud features' I mean proper handling 
>> > situations where we have many instances running on many different 
>> > hardware servers. Suddently one server (physically) goes down, something 
>> > bad happened. How will the OpenStack as a cloud behave by default? Will 
>> > it run all the lost instances on other hardware servers or this should 
>> > be specifically configured or programmed? How about data replication? 
>> > Users shouldn't notice anything, as all the instances are ran in the 
>> > cloud. Is it available by default? I couldn't find any docs that would 
>> > explain these topics in a detailed way. Thanks for your explanation.
>> > -- 
>> > regards
>> > 
>> > M
>> > 
>> > 
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to : openstack at lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help : https://help.launchpad.net/ListHelp
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

Jacob Gardiner
National Hosting Manager
E jgardiner at squiz.com.au

Squiz Pty. Ltd. A 92 Jarrett Street, Leichhardt NSW 2040
P +61 2 8507 9900 F +61 2 8507 9988 SUPPORT 13000 SQUIZ W www.squiz.com.au

AUSTRALIA UNITED KINGDOM NEW ZEALAND EUROPE UNITED STATES
SYDNEY MELBOURNE CANBERRA HOBART BRISBANE

SUPPORTED OPEN SOURCE SOLUTIONS


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110404/0edfdc07/attachment.html>