[Openstack] OpenStack automate replication

Jacob Gardiner jgardiner at squiz.com.au
Mon Apr 4 23:26:40 UTC 2011


Hey guys, 

I'm referring to the restoration of a persistent VM in the event that a host fails. Obviously replication of the volume to another or several other machines is required along with some resource scheduling and re-replicating the degraded volume after the failure. 


On 04/04/2011, at 11:32 PM, Diego Parrilla Santamaría wrote:

> On Mon, Apr 4, 2011 at 3:27 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>> Persistence != HA. What are we talking about here? Both? I'm not sure...
> 
> Agree. Replication has to do more with DR services than HA. I tried to
> prioritize instances Highly Avalaible and persistent instances (two
> different features) before DR.
> 
>> 
>> -jay
>> 
>> On Mon, Apr 4, 2011 at 12:20 AM, Jacob Gardiner <jgardiner at squiz.com.au> wrote:
>>> 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
>>> 
>>> _______________________________________________
>>> 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
>>> 
>>> 
>> 





More information about the Openstack mailing list