diff --git a/specs/stein/async-volume-migration.rst b/specs/stein/async-volume-migration.rst deleted file mode 100644 index c29350e6..00000000 --- a/specs/stein/async-volume-migration.rst +++ /dev/null @@ -1,236 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -======================================================== -Async volume migration between backends -======================================================== -https://blueprints.launchpad.net/cinder/+spec/async-volume-migration-between-backends - - -Problem description -=================== - -Currently if we migrate a volume from one backend to another backend, -especially when these two backends are handling two different vendors of -arrays, we can't attach this migrating volume to server until the migration -is totally complete. - -Both the dd way or driver-specific way will fail if we attach a volume when -it is migrating: - -* If we migrate the volume through dd way, the source or target volume is not - usable to server. - -* If we migrate the volume through driver-specific way, the migration task is - issued to the source backend by scheduler and the volume is owned by the - source backend during the whole migration. If we attach this volume to a - server when the migration is undergoing, the volume on the source - backend(array) will be attached to the server. But after the migration is - completed, the source volume on the source backend(array) will be deleted - so the previous attachment will actually fails. - - -Use Cases -=================== - -Currently cinder supports four cases for volume migration: - -#. Available volume migration between two different backends. These backends - could be from one single vendor or different vendors. -#. Available volume migration between two pools of one single backend. -#. In-use(attached) volume migration using driver specific way. -#. In-use(attached) volume migration using Cinder generic migration. - -This spec will only focus on case 1, to make an available volume -usable(can be attached to a server) immediately after we issue migration, no -need to wait until the migration complete. Case 2 is already well handled by -most drivers, and if we go into case 2, we won't go to case 1 again, so this -spec will focus on case 1. - -Proposed change -=============== - -In brief, the async migration is to use some features of backend array and -I've known that these features are already supported by most vendors like -EMC VMAX, IBM SVC, HP XP, NetApp and so on. Note that for the backends not -support these features, they still can use the existing driver specific -migration or host-copy way. We won't affect anything to the existing routine, -just add a new way for developers or users to choose. - -These features are: - -* One array can take over other array's LUN as a remote LUN if these two - arrays are connected with FC or iSCSI fabric. - -* We can migrate a remote LUN to a local LUN and meanwhile the remote(source) - LUN is writable and readable with the migration task is undergoing, after the - migration is completed, the local(target) LUN is exactly the same as the - remote(source) LUN and no data will be lost. - -To enable one array to take over other array's volume, we should allow one -driver to call other drivers' interfaces directly or indirectly. These two -drivers are from two independent backends, can be managed by one single volume -node or two different volume nodes. - -To enable an available volume usable(attach to a server) immediately -after we issued migration from one backend to another backend, we should -ALLOW the migration task to be send to the TARGET backend. - -There will be a new interface for driver which will be called -'migrate_volume_target'. We introduce a new interface instead of use the -existing 'migrate_volume' interface because there would be lots of -differences between them, a significant difference is that the drivers -executing the 'migrate_volume' interface always take them self as the -source backend, but the new interface should take itself as the target -backend. - -Some change will be made in the volume/manager.py for migrate_volume routine: - -#. If not force_host_copy and new_type_id is None, firstly call source backend - driver's migrate_volume(). If source backend driver's migrate_volume() - return True which means it has migrated successfully, change the - "migration_status" to "success" and update the volume, then go to step 3. - If source backend driver's migrate_volume() returned False, go to step 2. - -#. Call target backend driver's migrate_volume_target() through rpcapi, give a - chance for target backend to perform the migration. Give target backend a - chance to perform the migration will make the migration more flexible, and - is important to enable async migration. migrate_volume_target() should - return one more bool value than the migrate_volume() routine to mark the - migration is executed synchronously or asynchronously. The whole return - value could be: (moved, migration_async, model_update). If - migrate_volume_target() returns moved as False which means driver can't - perform the migration, we will go to _migrate_volume_generic() as usual to - perform host-copy migration. If migrate_volume_target() returns moved as - True and async as False, change the "migration_status" to "success" and - update the volume in db, then go to step 3. If migrate_volume_target() - returns moved as True and async as True, change the "migration_status" to - "migrating_attachable" and update the volume in db, then just go to step 3. - "migrating_attachable" means this volume is migrating and is safe to attach - it to a server, and end users can check if the volume is attachable to use - while it is migrating by "cinder show" command. Note that driver developer - should make sure the volume on the corresponding backend is safe to - read/write and no data corruption will occur while the migration is - undergoing before implementing the migrate_volume_target() interface. - -#. Update the volume.host to the target host and update the db with - model_update. Now the volume is usable for server to perform read/write - on it. If migrate_volume_target() returns async as False, the whole - migrate_volume() routine is end now. If migrate_volume_target() returns - True, go to step 4. - -#. Call target backend driver's complete_migration_target() to monitor the - undergoing migration, and do some cleaup after the migration is totally - completed. - -#. Update "migration_status" to "success" and end the whole migrate_volume() - routine. - - -Alternatives ------------- - -Let users wait a long time before the volume is usable for a server until -the whole migration is totally complete. - -REST API impact ---------------- - -None - -Data model impact ------------------ - -None - -Security impact ---------------- - -None - -Notifications impact --------------------- - -Currently no direct notifications. But users can know that the async -migration is started when the "migration_status" changed to -"migrating_attachable" and is finished when the "migration_status" -changed to "success". - -For other impact, like what operations are permitted and what operations -are not permitted, I think it's same like the existing migration. - -Other end user impact ---------------------- - -After issued "cinder migrate" command, end users can check the -"migration_status" by "cinder show" command. If "migration_status" is -"migrating", this volume is probably not safe to attach, and if -"migration_status" is "migrating_attachable" or "success", we can attach -it safely. But one thing we should let end user know is that if -"migration_status" is "migrating_attachable", the volume is safe to -attach but the performance of the volume may not as good as other volumes -for the moment before the undergoing migration is done. - -Performance Impact ------------------- - -As we know, driver assisted migration is mostly more efficient than host -copy, assuming that there is no read-through along with the migration. - -If we attach the migrating volume and do read-through operations on the -volume, the performance of the read/write is surelly not so good as the -direct read/write. As far as I know, for the OLTP workload, the performance -may decrease no more than 15 percent. - -Other deployer impact ---------------------- - -If deployers want to use the async feature, they should make sure the -backend driver supports this feature, and make sure these backends are -connected to each other. - -Developer impact ----------------- - -Driver developers should implement two new interfaces: "migrate_volume_target" -and "complete_migration_target". - -If drivers won't support this feature, driver devlopers needn't do anything. -We won't break down any driver or any existing function. - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - Wilson Liu - -Work Items ----------- - -* Implement the proposed change - -Dependencies -============ - -None - -Testing -======= - -* Unit-tests should be implemented - -Documentation Impact -==================== - -None - -References -========== - -None