<div dir="ltr">I am hoping support for instance quiesce in the Nova API makes it into OpenStack. To my understanding, this is existing function in Nova, just not-yet exposed in the public API. (I believe Cinder uses this via a private Nova API.)<div><br></div><div>Much of the discussion is around disaster recovery (DR) and NFV - which is not wrong, but might be muddling the discussion? Forget DR and NFV, for the moment.</div><div><br></div><div>My interest is simply in collecting high quality backups of applications (instances) running in OpenStack. (Yes, customers are deploying applications into OpenStack that need backup - and at large scale. They told us, *very* clearly.) Ideally, I would like to give the application a chance to properly quiesce, so the on-disk state is most-consistent, before collecting the backup. </div><div><br></div><div>The existing function in Nova should be at least a good start, it just needs to be exposed in the public Nova API. (At least, this is my understanding.)</div><div><br></div><div>Of course, good backups (however collected) allow you to build DR solutions. My immediate interest is simply to collect high-quality backups.</div><div><br></div><div>The part in the blueprint about an atomic operation on a list of instances ... this might be over-doing things. First, if you have a set of related instances, very likely there is a logical order in which they should be quiesced. Some could be quiesced concurrently. Others might need to be sequential.</div><div><br></div><div>Assuming the quiesce API *starts* the operation, and there is some means to check for completion, then a single-instance quiesce API should be sufficient. An API that is synchronous (waits for completion before returning) would also be usable. (I am not picky - just want to collect better backups for customers.)</div><div> <br></div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 29, 2016 at 7:24 PM, joehuang <span dir="ltr"><<a href="mailto:joehuang@huawei.com" target="_blank">joehuang@huawei.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
This spec[1] was to expose quiesce/unquiesce API, which had been approved in Mitaka, but code not merged in time.<br>
<br>
The major consideration for this spec is to enable application level consistency snapshot, so that the backup of the snapshot in the remote site could be recovered correctly in case of disaster recovery. Currently there is only single VM level consistency snapshot( through create image from VM ), but it's not enough.<br>
<br>
First, the disaster recovery is mainly the action in the infrastructure level in case of catastrophic failures (flood, earthquake, propagating software fault), the cloud service provider recover the infrastructure and the applications without the help from each application owner: you can not just recover the OpenStack, then send notification to all applications' owners, to ask them to restore their applications by their own. As the cloud service provider, they should be responsible for the infrastructure and application recovery in case of disaster.<br>
<br>
The second, this requirement is not to make OpenStack bend over NFV, although this requirement was asked from OPNFV at first, it's general requirement to have application level consistency snapshot. For example, just using OpenStack itself as the application running in the cloud, we can deploy different DB for different service, i.e. Nova has its own mysql server nova-db-VM, Neutron has its own mysql server neutron-db-VM. In fact, I have seen in some production to divide the db for Nova/Cinder/Neutron to different DB server for scalability purpose. We know that there are interaction between Nova and Neutron when booting a new VM, during the VM booting period, some data will be in the memory cache of the nova-db-VM/neutron-db-VM, if we just create snapshot of the volumes of nova-db-VM/neutron-db-VM in Cinder, the data which has not been flushed to the disk will not be in the snapshot of the volumes. We cann't make sure when these data in the memory cache will be flushed, then<br>
 there is random possibility that the data in the snapshot is not consistent as what happened as in the virtual machines of nova-db-VM/neutron-db-VM.In this case, Nova/Neutron may boot in the disaster recovery site successfully, but some port information may be crushed for not flushed into the neutron-db-VM when doing snapshot, and in the severe situation, even the VM may not be able to recover successfully to run. Although there is one project called Dragon[2], Dragon can't guarantee the consistency of the application snapshot too through OpenStack API.<br>
<br>
The third, for those applications which can decide the data and checkpoint should be replicated to disaster recovery site, this is the third option discussed and described in our analysis: <a href="https://git.opnfv.org/cgit/multisite/tree/docs/requirements/multisite-vnf-gr-requirement.rst" rel="noreferrer" target="_blank">https://git.opnfv.org/cgit/multisite/tree/docs/requirements/multisite-vnf-gr-requirement.rst</a>. But unfortunately in Cinder, after the volume replication V2.1 is developed, the tenant granularity volume replication is still being discussed, and still not on single volume level. And just like what have mentioned in the first point, both application level and infrastructure level are needed, for you can't only expect that asking each application owners to do recovery after disaster recovery of a site's OpenStack: applications usually can deal with the data generated by it, but for the configuration change's protection, it's out of scope of application. There are several options for disaster recovery, but doesn't mean one option can fit all.<br>
<br>
There are several -1 for this re-proposed spec which had been approved in Mitaka, so the explanation is sent in the mail-list for discussion. If someone can provide other way to guarantee application level snapshot for disaster recovery purpose, it's also welcome.<br>
<br>
[1] Re-Propose Expose quiesce/unquiesce API:  <a href="https://review.openstack.org/#/c/295595/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/295595/</a><br>
[2] Dragon: <a href="https://github.com/os-cloud-storage/openstack-workload-disaster-recovery" rel="noreferrer" target="_blank">https://github.com/os-cloud-storage/openstack-workload-disaster-recovery</a><br>
<br>
Best Regards<br>
Chaoyi Huang ( Joe Huang )<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>