技术控

    今日:39| 主题:57639
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] An Introduction for CloudFerry, a tool for OpenStack Cloud to Cloud Migration

[复制链接]
妳是我的主角 投递于 2016-10-4 03:49:09
356 12
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   
  • Migration Scenarios   
  • 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

  
       
  • Grizzly   
  • Icehouse   
  • Juno  
   Objects Supported for Migration

               Openstack Service       Corresponding Objects               Keystone            
          
  • Tenants      
  • User roles      
               Neutron            
          
  • Networks
               
    • Private         
    • Public         
    • Shared        
            
  • Subnets      
  • Ports      
  • Floating IPs      
  • Security groups      
  • Routers      
  • LBaaS objects      
  • Quotas      
               Glance            
          
  • Images      
               Cinder            
          
  • Volumes      
  • Quotas      
               Nova            
          
  • VMs      
  • VM’s ephemeral storage      
  • Flavors      
  • User quotas      
  • Tenant quotas      
  • Key pairs      
            CloudFerry works via SSH/SCP, MySQL transactions and OpenStack API calls.
   Typical Migration Flow

   

An Introduction for CloudFerry, a tool for OpenStack Cloud to Cloud Migration

An Introduction for CloudFerry, a tool for OpenStack Cloud to Cloud Migration-1-技术控-resources,software,existing,running,another

  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

  
       
  • Requirements   
  • CloudFerry installation   
  • Main config   
  • Scenario file  
   Pre-requisites

  
       
  • 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.  
   CloudFerry Installation

  The documentation recommends installing CloudFerry as follows
  1. $ pipinstallgit+git://github.com/MirantisWorkloadMobility/CloudFerry.git
复制代码
  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.
  1. $ apt-getinstall  build-essentiallibssl-devlibffi-devpython-devsqlite  -y
  2. $ wgethttps://bootstrap.pypa.io/get-pip.py
  3. $ pythonget-pip.py
  4. $ pipinstallgit+git://github.com/MirantisWorkloadMobility/CloudFerry.git
  5. # see list of available commands
  6. $ cloudferry --help
复制代码
Main Configuration

  To generate the main config file, use the following command
  1. $ oslo-config-generator --namespace cloudferry | teeconfiguration.ini
复制代码
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 [scenario/cold_migrate.yaml]   
  • Resources Migration [scenario/migrate_resources.yaml]   
  • Migrate VMs: Instances Migration [scenario/migrate_vms.yaml]  
   Cold Migration

  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:
  1. migrate_whole_cloud = Value
复制代码
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.
  1. filter_path = configs/filter.yaml
复制代码
The above option is the path to a config file which allows specifying tenant, instance, or other OpenStack object to be migrated.
  1. keep_ip=yes
复制代码
for holding on to the same fixed IP of the instance as in source cloud.
  1. keep_floatingip=yes
复制代码
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  
  1. $ cloudferrymigrate2
复制代码



上一篇:An exercise in futility
下一篇:WalmartLabs open sources the application platform that powers Walmart.com
何宇 投递于 2016-10-4 08:29:11
我穿越了
回复 支持 反对

使用道具 举报

乐安 投递于 2016-10-5 04:48:40
我有一颗学霸心,却只有学渣命
回复 支持 反对

使用道具 举报

zwznca274 投递于 2016-10-11 12:07:44
呵呵。。。
回复 支持 反对

使用道具 举报

112112 投递于 2016-10-14 07:36:06
不要在意我,我只是个小尾巴。
回复 支持 反对

使用道具 举报

若酷 投递于 2016-10-15 00:10:46
若酷留下了印记
回复 支持 反对

使用道具 举报

黄若宇 投递于 2016-10-15 13:06:36
看来楼下的有话说!
回复 支持 反对

使用道具 举报

胡珊 投递于 2016-11-2 18:05:22
不错,谢谢分享
回复 支持 反对

使用道具 举报

离子膜、 投递于 2016-11-12 21:35:40
我左青龙,右白虎,肩膀纹个米老鼠.
回复 支持 反对

使用道具 举报

姜启龙 投递于 2016-11-13 09:17:43
我装作听不懂的样子
回复 支持 反对

使用道具 举报

我要投稿

推荐阅读


回页顶回复上一篇下一篇回列表
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 | 粤公网安备 44010402000842号 )

© 2001-2017 Comsenz Inc.

返回顶部 返回列表