This is the first of a series of posts exploring the CloudFerry OpenStack migration tool in depth.
Table of Contents
The challenges in OpenStack Migration
Introduction to CloudFerry
Typical Migration Flow
Configuration Options and Limitations
The Challenges in OpenStack Migration
The use case of Openstack C2C migration comes for an organization when their existing OpenStack cloud is running an older release and they want to upgrade.
In an Openstack cloud environment we can have many tenants with their corresponding workloads & resources. When the need arises to move these tenants, workloads & resources from one cloud environment to another, doing so manually is a cumbersome task which is risky.
As of now OpenStack doesn’t provide a direct software upgrade path, this is exactly where CloudFerry comes into picture.
Introduction to CloudFerry
CloudFerry is an open-source tool developed by Mirantis which automates resources and workload migration between OpenStack clouds with low risk & good speed. Note: A “workload” is a virtual machine & all the resources that were used to create it.
Current Version of CloudFerry: 1.54 Supported OpenStack Releases
Objects Supported for Migration
Openstack ServiceCorresponding ObjectsKeystone
VM’s ephemeral storage
CloudFerry works via SSH/SCP, MySQL transactions and OpenStack API calls. Typical Migration Flow
Image Credit : Linked from the CloudFerry documentation.
There are 3 stages that a typical migration flow is composed of: Condensation: Condensation is determining the number of physical nodes that can be freed up and moved to the destination cloud. Evacuation: Evacuation is getting the source cloud workloads onto as few nodes as possible. Migration of Workloads: Once condensation & evacuation are done, we can move the freed up physical nodes to the destination cloud and start migrating workloads into the new cloud to use the migrated hardware.
In case of failed migration CloudFerry rolls back the destination cloud state to the initial state that was there before migration. The amount of time it takes for any kind of migration, depends upon the speed of the network & the amount of workload to be migrated. Artifacts in a migration
From the host where CloudFerry is installed there should be network connection to source and destination clouds through their external (public) network.
Should be able to have admin access to keystone (typically admin access point lives on 35357 port).
A valid private ssh-key for both clouds which will be used by CloudFerry for data transfer.
sudo/root access on compute & controller nodes is needed from CloudFerry host.
Openstack MySQL DB write access for CloudFerry Machine.
Credentials of global cloud admin of both clouds are needed.
requirements.txt has all the Python requirements listed in it.
The documentation recommends installing CloudFerry as follows
[/code] I’ve faced issues installing CloudFerry using above method on fresh Ubuntu 14.04 machine. I was able to come up with some other steps for its installation with the help of the following docker file from CloudFerry’s Github repository.
[code]$ apt-getinstall build-essentiallibssl-devlibffi-devpython-devsqlite -y
# see list of available commands
$ cloudferry --help
[/code] Main Configuration
To generate the main config file, use the following command
[code] $ oslo-config-generator --namespace cloudferry | teeconfiguration.ini
[/code] Migration Scenarios
We have different types of migration scenarios available which we can choose under migration section of our main configuration file. Each scenario has a corresponding file with the steps involved for that scenario. These files are provided with CloudFerry itself and the correct file path should be mentioned in the main config file depending on the scenario. The scenarios are:
Cold Migration does the migration of both resources & instances migration, at first it migrates resources and then migrates instances. Any instances during the cold migration will be brought down before migration. Resources Migration
Under Resources Migration scenario we can migrate all the objects supported by CloudFerry. We cannot migrate instances under this scenario. Migrate VMs
As the name suggest we use this scenario to migrate instances/VMs. Under this scenario CloudFerry expects the networks which are used by instances in source cloud to be present in destination cloud.If the network used by an instance of source cloud is present in destination, it’ll migrate it. Whereas if the network used by an instance of source cloud is not present in destination, it won’t migrate it. As a workaround if you try to change the option:“keep_ip=no” it’ll be of no use. So it is suggested to use resources migration scenario first, before using this scenario.
While migrating the VMs/Instances their respective glance images are also migrated.
Rollback issues of the migrate_vms.yaml scenario
When the migration fails under this scenario, the rollback to the initial state of destination cloud is not proper i.e, the glance images that are migrated from source to destination cloud are not removed or rolled back.
If you are migrating two instances of two different networks of which only one same network is present in destination, the migration fails. As discussed earlier, we are supposed to have same networks in the destination cloud under this scenario but the rollback is not proper i.e, the instance with same network on both sides will be migrated, while the other instance won’t but as part of rollback the migrated instance is not removed.
Some Configuration Options and Limitations
Important Options in the configuration file
Under the [migrate] section:
[code]migrate_whole_cloud = Value
[/code] To Migrate the whole cloud, we can use this option. The values are “True/False”
When the value is “True”, whole cloud will be migrated despite the filter config file is specified;When the value is “False”, (default value), migration of resources and instances happens according to the filter config file.
[code]filter_path = configs/filter.yaml
[/code] The above option is the path to a config file which allows specifying tenant, instance, or other OpenStack object to be migrated.
[/code] for holding on to the same fixed IP of the instance as in source cloud.
[/code] for holding on to the same floating IP of the instance as in source cloud.
While there are other important options too, but these are some options which are basic for a successful migration Limitations of the current version of CloudFerry
Live migration is not supported as of now.
LVM cinder backend is not supported, only NFS and iSCSI VMAX are supported.
CloudFerry has CLI option for version2 API which is still under development and is not ready for use. It can be invoked by