>Hmm, I totally see the value of doing this. Not sure that there could be >the same kinds of "liveness" guarantees with non-shared-storage, but I >am certainly happy to see a proof of concept in this area! :) By "liveness", if you mean down time of migration, our current results show that liveness is guaranteed with non-shared-storage. Some preliminary work has been published in a conference SOSE14, which can be found at http://www.vmthunder.org/dlsm_sose2014_final.pdf And we have made some improvements to it, and the work is still under development. We are planning to write a new paper and submit it to another conference in this summer.
>> how about zero-copying? > >It would be an implementation detail within nova.image.api.copy() >function (and the aforementioned "image bits mover library") :) IMHO, (pre-)copying and zero-copying are different in nature, and it's not necessary to mask such difference by a single interface. With 2 sets of interfaces, programmers (users of copying service) will be reminded of the cost of (pre-)copying, or the risk of runtime network congestion of zero-copying. At 2014-04-23 23:02:29,"Jay Pipes" <jaypi...@gmail.com> wrote: >On Wed, 2014-04-23 at 13:56 +0800, lihuiba wrote: >> >For live migration, we use shared storage so I don't think it's quite >> >the same as getting/putting image bits from/to arbitrary locations. >> With a good zero-copy transfer lib, live migration support can be >> extended to non-shared storage, or cross-datacenter. It's a kind of >> value. > >Hmm, I totally see the value of doing this. Not sure that there could be >the same kinds of "liveness" guarantees with non-shared-storage, but I >am certainly happy to see a proof of concept in this area! :) > >> >task = image_api.copy(from_path_or_uri, to_path_or_uri) >> ># do some other work >> >copy_task_result = task.wait() >> +1 looks cool! >> how about zero-copying? > >It would be an implementation detail within nova.image.api.copy() >function (and the aforementioned "image bits mover library") :) > >The key here is to leak as little implementation detail out of the >nova.image.api module > >Best, >-jay > >> At 2014-04-23 07:21:27,"Jay Pipes" <jaypi...@gmail.com> wrote: >> >Hi Vincent, Zhi, Huiba, sorry for delayed response. See comments inline. >> > >> >On Tue, 2014-04-22 at 10:59 +0800, Sheng Bo Hou wrote: >> >> I actually support the idea Huiba has proposed, and I am thinking of >> >> how to optimize the large data transfer(for example, 100G in a short >> >> time) as well. >> >> I registered two blueprints in nova-specs, one is for an image upload >> >> plug-in to upload the image to >> >> glance(https://review.openstack.org/#/c/84671/), the other is a data >> >> transfer plug-in(https://review.openstack.org/#/c/87207/) for data >> >> migration among nova nodes. I would like to see other transfer >> >> protocols, like FTP, bitTorrent, p2p, etc, implemented for data >> >> transfer in OpenStack besides HTTP. >> >> >> >> Data transfer may have many use cases. I summarize them into two >> >> catalogs. Please feel free to comment on it. >> >> 1. The machines are located in one network, e.g. one domain, one >> >> cluster, etc. The characteristic is the machines can access each other >> >> directly via the IP addresses(VPN is beyond consideration). In this >> >> case, data can be transferred via iSCSI, NFS, and definitive zero-copy >> >> as Zhiyan mentioned. >> >> 2. The machines are located in different networks, e.g. two data >> >> centers, two firewalls, etc. The characteristic is the machines can >> >> not access each other directly via the IP addresses(VPN is beyond >> >> consideration). The machines are isolated, so they can not be >> >> connected with iSCSI, NFS, etc. In this case, data have to go via the >> >> protocols, like HTTP, FTP, p2p, etc. I am not sure whether zero-copy >> >> can work for this case. Zhiyan, please help me with this doubt. >> >> >> >> I guess for data transfer, including image downloading, image >> >> uploading, live migration, etc, OpenStack needs to taken into account >> >> the above two catalogs for data transfer. >> > >> >For live migration, we use shared storage so I don't think it's quite >> >the same as getting/putting image bits from/to arbitrary locations. >> > >> >> It is hard to say that one protocol is better than another, and one >> >> approach prevails another(BitTorrent is very cool, but if there is >> >> only one source and only one target, it would not be that faster than >> >> a direct FTP). The key is the use >> >> case(FYI:http://amigotechnotes.wordpress.com/2013/12/23/file-transmission-with-different-sharing-solution-on-nas/). >> > >> >Right, a good solution would allow for some flexibility via multiple >> >transfer drivers. >> > >> >> Jay Pipes has suggested we figure out a blueprint for a separate >> >> library dedicated to the data(byte) transfer, which may be put in oslo >> >> and used by any projects in need (Hoping Jay can come in:-)). Huiba, >> >> Zhiyan, everyone else, do you think we come up with a blueprint about >> >> the data transfer in oslo can work? >> > >> >Yes, so I believe the most appropriate solution is to create a library >> >-- in oslo or a standalone library like taskflow -- that would offer a >> >simple byte streaming library that could be used by nova.image to expose >> >a neat and clean task-based API. >> > >> >Right now, there is a bunch of random image transfer code spread >> >throughout nova.image and in each of the virt drivers there seems to be >> >different re-implementations of similar functionality. I propose we >> >clean all that up and have nova.image expose an API so that a virt >> >driver could do something like this: >> > >> >from nova.image import api as image_api >> > >> >... >> > >> >task = image_api.copy(from_path_or_uri, to_path_or_uri) >> ># do some other work >> >copy_task_result = task.wait() >> > >> >Within nova.image.api.copy(), we would use the aforementioned transfer >> >library to move the image bits from the source to the destination using >> >the most appropriate method. >> > >> >Best, >> >-jay >> > >> > >> >_______________________________________________ >> >OpenStack-dev mailing list >> >OpenStack-dev@lists.openstack.org >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
