<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">>IMHO, zero-copy approach is better
</div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">VMThunder's "on-demand transferring" is the same thing as your "zero-copy approach".</div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">VMThunder is uses iSCSI as the transferring protocol, which is option #b of yours.</div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><br></div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><br></div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">>Under #b approach, my former experience from our previous similar<br>>Cloud deployment (not OpenStack) was that: under 2 PC server storage<br>>nodes (general *local SAS disk*, without any storage backend) +<br>>2-way/multi-path iSCSI + 1G network bandwidth, we can provisioning 500<br>>VMs in a minute.<br></div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">suppose booting one instance requires reading 300MB of data, so 500 ones</div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">require 150GB.  Each of the storage server needs to send data at a rate of </div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">150GB/2/60 = 1.25GB/s on average. This is absolutely a heavy burden even </div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">for high-end storage appliances. In production  systems, this request (booting </div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">500 VMs in one shot) will significantly disturb  other running instances </div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">accessing the same storage nodes.</div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><br></div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">VMThunder eliminates this problem by P2P transferring and on-compute-node</div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">caching. Even a pc server with one 1gb NIC (this is a true pc server!) can boot</div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">500 VMs in a minute with ease. For the first time, VMThunder makes bulk </div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">provisioning of VMs practical for production cloud systems. This is the essential</div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">value of VMThunder.</div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><br></div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><br></div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><br></div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><br></div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">===================================================</div><div class="gmail_quote" style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">From: <b class="gmail_sendername">Zhi Yan Liu</b> <span dir="ltr"><<a href="mailto:lzy.dev@gmail.com" target="_blank" style="color: rgb(0, 51, 153); ">lzy.dev@gmail.com</a>></span><br>Date: 2014-04-17 0:02 GMT+08:00<br>Subject: Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder<br>To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank" style="color: rgb(0, 51, 153); ">openstack-dev@lists.openstack.org</a>><br><br><br>Hello Yongquan Fu,<br><br>My thoughts:<br><br>1. Currently Nova has already supported image caching mechanism. It<br>could caches the image on compute host which VM had provisioning from<br>it before, and next provisioning (boot same image) doesn't need to<br>transfer it again only if cache-manger clear it up.<br>2. P2P transferring and prefacing is something that still based on<br>copy mechanism, IMHO, zero-copy approach is better, even<br>transferring/prefacing could be optimized by such approach. (I have<br>not check "on-demand transferring" of VMThunder, but it is a kind of<br>transferring as well, at last from its literal meaning).<br>And btw, IMO, we have two ways can go follow zero-copy idea:<br>a. when Nova and Glance use same backend storage, we could use storage<br>special CoW/snapshot approach to prepare VM disk instead of<br>copy/transferring image bits (through HTTP/network or local copy).<br>b. without "unified" storage, we could attach volume/LUN to compute<br>node from backend storage as a base image, then do such CoW/snapshot<br>on it to prepare root/ephemeral disk of VM. This way just like<br>boot-from-volume but different is that we do CoW/snapshot on Nova side<br>instead of Cinder/storage side.<br><br>For option #a, we have already got some progress:<br><a href="https://blueprints.launchpad.net/nova/+spec/image-multiple-location" target="_blank" style="color: rgb(0, 51, 153); ">https://blueprints.launchpad.net/nova/+spec/image-multiple-location</a><br><a href="https://blueprints.launchpad.net/nova/+spec/rbd-clone-image-handler" target="_blank" style="color: rgb(0, 51, 153); ">https://blueprints.launchpad.net/nova/+spec/rbd-clone-image-handler</a><br><a href="https://blueprints.launchpad.net/nova/+spec/vmware-clone-image-handler" target="_blank" style="color: rgb(0, 51, 153); ">https://blueprints.launchpad.net/nova/+spec/vmware-clone-image-handler</a><br><br>Under #b approach, my former experience from our previous similar<br>Cloud deployment (not OpenStack) was that: under 2 PC server storage<br>nodes (general *local SAS disk*, without any storage backend) +<br>2-way/multi-path iSCSI + 1G network bandwidth, we can provisioning 500<br>VMs in a minute.<br><br>For vmThunder topic I think it sounds a good idea, IMO P2P, prefacing<br>is one of optimized approach for image transferring valuably.<br><br>zhiyan<br><div><div class="h5"><br>On Wed, Apr 16, 2014 at 9:14 PM, yongquan Fu <<a href="mailto:quanyongf@gmail.com" target="_blank" style="color: rgb(0, 51, 153); ">quanyongf@gmail.com</a>> wrote:<br>><br>> Dear all,<br>><br>><br>><br>>  We would like to present an extension to the vm-booting functionality of<br>> Nova when a number of homogeneous vms need to be launched at the same time.<br>><br>><br>><br>> The motivation for our work is to increase the speed of provisioning vms for<br>> large-scale scientific computing and big data processing. In that case, we<br>> often need to boot tens and hundreds virtual machine instances at the same<br>> time.<br>><br>><br>>     Currently, under the Openstack, we found that creating a large number of<br>> virtual machine instances is very time-consuming. The reason is the booting<br>> procedure is a centralized operation that involve performance bottlenecks.<br>> Before a virtual machine can be actually started, OpenStack either copy the<br>> image file (swift) or attach the image volume (cinder) from storage server<br>> to compute node via network. Booting a single VM need to read a large amount<br>> of image data from the image storage server. So creating a large number of<br>> virtual machine instances would cause a significant workload on the servers.<br>> The servers become quite busy even unavailable during the deployment phase.<br>> It would consume a very long time before the whole virtual machine cluster<br>> useable.<br>><br>><br>><br>>   Our extension is based on our work on vmThunder, a novel mechanism<br>> accelerating the deployment of large number virtual machine instances. It is<br>> written in Python, can be integrated with OpenStack easily. VMThunder<br>> addresses the problem described above by following improvements: on-demand<br>> transferring (network attached storage), compute node caching, P2P<br>> transferring and prefetching. VMThunder is a scalable and cost-effective<br>> accelerator for bulk provisioning of virtual machines.<br>><br>><br>><br>>   We hope to receive your feedbacks. Any comments are extremely welcome.<br>> Thanks in advance.<br>><br>><br>><br>> PS:<br>><br>><br>><br>> VMThunder enhanced nova blueprint:<br>> <a href="https://blueprints.launchpad.net/nova/+spec/thunderboost" target="_blank" style="color: rgb(0, 51, 153); ">https://blueprints.launchpad.net/nova/+spec/thunderboost</a><br>><br>>  VMThunder standalone project: <a href="https://launchpad.net/vmthunder" target="_blank" style="color: rgb(0, 51, 153); ">https://launchpad.net/vmthunder</a>;<br>><br>>  VMThunder prototype: <a href="https://github.com/lihuiba/VMThunder" target="_blank" style="color: rgb(0, 51, 153); ">https://github.com/lihuiba/VMThunder</a><br>><br>>  VMThunder etherpad: <a href="https://etherpad.openstack.org/p/vmThunder" target="_blank" style="color: rgb(0, 51, 153); ">https://etherpad.openstack.org/p/vmThunder</a><br>><br>>  VMThunder portal: <a href="http://www.vmthunder.org/" target="_blank" style="color: rgb(0, 51, 153); ">http://www.vmthunder.org/</a><br>><br>> VMThunder paper: <a href="http://www.computer.org/csdl/trans/td/preprint/06719385.pdf" target="_blank" style="color: rgb(0, 51, 153); ">http://www.computer.org/csdl/trans/td/preprint/06719385.pdf</a><br>><br>><br>><br>>   Regards<br>><br>><br>><br>>   vmThunder development group<br>><br>>   PDL<br>><br>>   National University of Defense Technology<br>><br>><br></div></div>> _______________________________________________<br>> OpenStack-dev mailing list<br>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank" style="color: rgb(0, 51, 153); ">OpenStack-dev@lists.openstack.org</a><br>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" style="color: rgb(0, 51, 153); ">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>><br><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank" style="color: rgb(0, 51, 153); ">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" style="color: rgb(0, 51, 153); ">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div><br style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><br clear="all" style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><div style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><br></div><span style="font-family: Helvetica, 'Microsoft Yahei', verdana; ">-- </span><br style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><div dir="ltr" style="font-family: Helvetica, 'Microsoft Yahei', verdana; "><span style="font-family: arial; font-size: small; ">Yongquan Fu</span><div style="font-family: arial; font-size: small; ">PhD, Assistant Professor,<br>National Key Laboratory for Parallel and Distributed<br>Processing, College of Computer Science, National University of Defense<br>Technology, Changsha, Hunan Province, P.R. China<br>410073</div></div></div>