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
- The challenges in OpenStack Migration
- Introduction to CloudFerry
- Typical Migration Flow
- Migration Scenarios
- Configuration Options and Limitations
Introduction to CloudFerry
- 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.
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 Service Corresponding Objects Keystone
- Floating IPs
- Security groups
- LBaaS objects
CloudFerry works via SSH/SCP, MySQL transactions and OpenStack API calls.
- VM’s ephemeral storage
- User quotas
- Tenant quotas
- Key pairs
Typical Migration Flow
An Introduction for CloudFerry, a tool for OpenStack Cloud to Cloud Migration
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
- CloudFerry installation
- Main config
- Scenario file
- 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
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. 复制代码
- $ pipinstallgit+git://github.com/MirantisWorkloadMobility/CloudFerry.git
Main Configuration 复制代码
- $ apt-getinstall build-essentiallibssl-devlibffi-devpython-devsqlite -y
- $ wgethttps://bootstrap.pypa.io/get-pip.py
- $ pythonget-pip.py
- $ pipinstallgit+git://github.com/MirantisWorkloadMobility/CloudFerry.git
- # see list of available commands
- $ cloudferry --help
To generate the main config file, use the following command
Migration Scenarios 复制代码
- $ oslo-config-generator --namespace cloudferry | teeconfiguration.ini
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 [scenario/cold_migrate.yaml]
- Resources Migration [scenario/migrate_resources.yaml]
- Migrate VMs: Instances Migration [scenario/migrate_vms.yaml]
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.
Under Resources Migration scenario we can migrate all the objects supported by CloudFerry. We cannot migrate instances under this scenario.
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
Some Configuration Options and Limitations
- 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.
Important Options in the configuration file
Under the [migrate] section:
To Migrate the whole cloud, we can use this option. The values are “True/False” 复制代码
- migrate_whole_cloud = Value
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.
The above option is the path to a config file which allows specifying tenant, instance, or other OpenStack object to be migrated. 复制代码
- filter_path = configs/filter.yaml
for holding on to the same fixed IP of the instance as in source cloud.
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
上一篇：An exercise in futility
下一篇：WalmartLabs open sources the application platform that powers Walmart.com