技术控

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

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

[复制链接]
妳是我的主角 发表于 2016-10-4 03:49:09
327 12

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
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-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
  [code]$ pipinstallgit+git://github.com/MirantisWorkloadMobility/CloudFerry.git
[/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
$ wgethttps://bootstrap.pypa.io/get-pip.py
$ pythonget-pip.py
$ pipinstallgit+git://github.com/MirantisWorkloadMobility/CloudFerry.git
# 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 [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:
  [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]keep_ip=yes
[/code]  for holding on to the same fixed IP of the instance as in source cloud.
  [code]keep_floatingip=yes
[/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  
  [code]$ cloudferrymigrate2
[/code]
友荐云推荐




上一篇: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
我装作听不懂的样子
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2017 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表