[switching to openstack-dev] Has anyone automated nova evacuate so that VM's on a failed compute host using shared storage are automatically moved onto a new host or is manually entering *nova compute <instance> <host>* required in all cases?
If it's manual only or require custom Heat/Ceilometer templates, how hard would it be to enable automatic evacuation within Novs? i.e. (within /etc/nova/nova.conf) auto_evac = true Or is this possible now and I've simply not run across it? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Sat, Sep 27, 2014 at 12:32 AM, Clint Byrum <cl...@fewbar.com> wrote: > So, what you're looking for is basically the same old IT, but with an > API. I get that. For me, the point of this cloud thing is so that server > operators can make _reasonable_ guarantees, and application operators > can make use of them in an automated fashion. > > If you start guaranteeing 4 and 5 nines for single VM's, you're right > back in the boat of spending a lot on server infrastructure even if your > users could live without it sometimes. > > Compute hosts are going to go down. Networks are going to partition. It > is not actually expensive to deal with that at the application layer. In > fact when you know your business rules, you'll do a better job at doing > this efficiently than some blanket "replicate all the things" layer might. > > I know, some clouds are just new ways to chop up these fancy 40 core > megaservers that everyone is shipping. I'm sure OpenStack can do it, but > I'm saying, I don't think OpenStack _should_ do it. > > Excerpts from Adam Lawson's message of 2014-09-26 20:30:29 -0700: > > Generally speaking that's true when you have full control over how you > > deploy applications as a consumer. As a provider however, cloud > resiliency > > is king and it's generally frowned upon to associate instances directly > to > > the underlying physical hardware for any reason. It's good when instances > > can come and go as needed, but in a production context, a failed compute > > host shouldn't take down every instance hosted on it. Otherwise there is > no > > real abstraction going on and the cloud loses immense value. > > On Sep 26, 2014 4:15 PM, "Clint Byrum" <cl...@fewbar.com> wrote: > > > > > Excerpts from Adam Lawson's message of 2014-09-26 14:43:40 -0700: > > > > Hello fellow stackers. > > > > > > > > I'm looking for discussions/plans re VM continuity. > > > > > > > > I.e. Protection for instances using ephemeral storage against host > > > failures > > > > or auto-failover capability for instances on hosts where the host > suffers > > > > from an attitude problem? > > > > > > > > I know fail-overs are supported and I'm quite certain > auto-fail-overs are > > > > possible in the event of a host failure (hosting instances not using > > > shared > > > > storage). I just can't find where this has been addressed/discussed. > > > > > > > > Someone help a brother out? ; ) > > > > > > I'm sure some of that is possible, but it's a cloud, so why not do > things > > > the cloud way? > > > > > > Spin up redundant bits in disparate availability zones. Replicate only > > > what must be replicated. Use volumes for DR only when replication would > > > be too expensive. > > > > > > Instances are cattle, not pets. Keep them alive just long enough to > make > > > your profit. > > > > > > _______________________________________________ > > > Mailing list: > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > Post to : openst...@lists.openstack.org > > > Unsubscribe : > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
