On Wed, Aug 21, 2019 at 8:35 PM Zaharo Bai (白战豪)-云数据中心集团
So, what is the current usage scenario for our online migration? I understand that the
current online migration of the community has not been truly online, and the upper layer
(iscsi target, openstack, etc.) must be required to do some operations such as switching
and data maintenance.
Is there a way to achieve full online migration in the rbd layer, the upper application
is not aware, just need to call librbd's CLI or API, or is it necessary to do so,
because doing so will inevitably change the architecture of ceph.
If using RBD under a higher-level layer, the upper layers would need
to know about the migration to update their internal data structures
to point to the correct (new) image. The only case where this really
isn't necessary is when live-migrating an image "in-place" (i.e. you
keep it in the same pool w/ the same name).
发件人: Jason Dillaman [mailto:email@example.com]
发送时间: 2019年8月21日 20:44
收件人: Zaharo Bai (白战豪)-云数据中心集团 <baizhanhao01(a)inspur.com>
抄送: ceph-users <ceph-users(a)ceph.com>
主题: Re: About image migration
On Tue, Aug 20, 2019 at 10:04 PM Zaharo Bai (白战豪)-云数据中心集团
I have a question I would like to ask you, Is the current image migration and
openstack adapted? according to my understanding, openstack’s previous live-migration
logic is implemented in cinder, just call librbd rbd_read/write API to do Data migration.
I believe the existing Cinder volume block live-migration is just a wrapper around
QEMU's block live-migration functionality, so indeed it would just be a series of RBD
read/write API calls between two volumes. The built-in RBD live-migration is similar but
it copies snapshots and preserves image sparseness during the migration process.
Because Cinder is using the QEMU block live-migration functionality, it's not tied
into RBD's live-migration.