• linkedu视频
  • 平面设计
  • 电脑入门
  • 操作系统
  • 办公应用
  • 电脑硬件
  • 动画设计
  • 3D设计
  • 网页设计
  • CAD设计
  • 影音处理
  • 数据库
  • 程序设计
  • 认证考试
  • 信息管理
  • 信息安全
菜单
linkedu.com
导航菜单
  • 网页制作
  • 数据库
  • 程序设计
  • 操作系统
  • CMS教程
  • 游戏攻略
  • 脚本语言
  • 平面设计
  • 软件教程
  • 网络安全
  • 电脑知识
  • 服务器
  • 视频教程
  • windows
  • 服务器硬件
  • 服务器运维
  • 云计算
  • 虚拟化
  • IIS教程
  • Linux
  • Apache
  • Ftp
  • DNS
  • Nginx
您的位置:首页 > 服务器 >云计算 > 《转》OpenStack Live Migration,《转》openstack

《转》OpenStack Live Migration,《转》openstack

作者:网友 字体:[增加 减小] 来源:互联网

本文主要包含live migration,openstack,openstack是什么,openstack官网,openstack视频教程等服务器相关知识,网友希望可以进行参考

《转》OpenStack Live Migration,《转》openstack


This post is based assumption that KVM as hypervisor, and Openstack is running in Grizzly on top of RHEL6.4.

Openstack VM live migration can have 3 categories:

-Block live migration without shared storage

-Shared storage based live migration

-Volume backed VM live migration


Block live migration

Block live migration does not require shared storage among nova-compute nodes, it uses network(TCP) to copy VM disk from source host to destination host, thus it takes longer time to complete than shared storage based live migration. Also during migration, host performance will be degraded in network and CPU points of view.

To enable block live migration, we need to change libvirtd and nova.conf configurations on every nova-compute hosts:

->Edit /etc/libvirt/libvirtd.conf

listen_tls = 0
listen_tcp = 1
auth_tcp = "none"

->Edit /etc/sysconfig/libvirtd 

LIBVIRTD_ARGS="–listen"

->Restart libvirtd

service libvirtd restart

->Edit /etc/nova/nova.conf, add following line:

live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

Adding this line is to ask nova-compute  to utilize libvirt's true live migration function.

By default Migrations done by the nova-compute does not use libvirt's live migration functionality, which means guests are suspended before migration and may therefore experience several minutes of downtime.

>Restart nova-compute service

service openstack-nova-compute restart

->Check running VMs

nova list
+--------------------------------------+-------------------+--------+---------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+--------+---------------------+
| 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | ACTIVE | ncep-net=10.20.20.3 |
+--------------------------------------+-------------------+--------+---------------------+

->Check which host the VM in running on

nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T08:47:13Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-1 |

->Check all available hosts

nova host-list
+--------------+-------------+----------+
| host_name | service | zone |
+--------------+-------------+----------+
| compute-1 | compute | nova |
| compute-2 | compute | nova |

>Let's migrate the vm to host compute-2

nova live-migration  --block-migrate vm-live-migration compute-2

>Later when we check vm status again, we cloud see the host changes to compute-2

nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T09:45:33Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-2 |

>We can just do a migration without specifying destination host, nova-scheduler will choose a free host for you

nova live-migration  --block-migrate vm-live-migration

Block live migration seems a good solution if we don't have/want shared storage , but we still want to do some host level maintenance work without bring downtime to running VMs.

Shared storage based live migration

This example we use GlusterFS as shared storage for nova-compute nodes. Since VM disk is stored on shared storage, hence live migration much much more faster than block live migration.

1.Setup GlusterFS cluster for nova-compute nodes

->Prepare 4 nodes, each node has an extra disk other than OS disk, dedicated for GlusterFS cluster

Node 1: 10.68.124.18 /dev/sdb 1TB
Node 2: 10.68.124.19 /dev/sdb 1TB
Node 3: 10.68.124.20 /dev/sdb 1TB
Node 4: 10.68.124.21 /dev/sdb 1TB

->Configure Node 1-4

yum install -y xfsprogs.x86_64
mkfs.xfs -f -i size=512 /dev/sdb
mkdir /brick1
echo "/dev/sdb /brick1 xfs defaults 1 2" >> /etc/fstab 1014 cat /etc/fstab 
mount -a && mount
mkdir /brick1/sdb
yum install glusterfs-fuse glusterfs-server
/etc/init.d/glusterd start
chkconfig glusterd on

->On Node-1, add peers

gluster peer probe 10.68.125.19
gluster peer probe 10.68.125.20
gluster peer probe 10.68.125.21

->On node-1, create a volume for nova-compute

gluster volume create nova-gluster-vol replica 2 10.68.125.18:/brick1/sdb 10.68.125.19:/brick1/sdb 10.68.125.20:/brick1/sdb 10.68.125.21:/brick1/sdb
gluster volume start nova-gluster-vol

->We can check the volume information

gluster volume info
Volume Name: nova-gluster-vol
Type: Distributed-Replicate
Status: Started
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: 10.68.125.18:/brick1/sdb
Brick2: 10.68.125.19:/brick1/sdb
Brick3: 10.68.125.20:/brick1/sdb
Brick4: 10.68.125.21:/brick1/sdb

->On each nova-compute node, mount the GluserFS volume to /var/lib/nova/instances

yum install glusterfs-fuse
mount.glusterfs 10.68.125.18:/nova-gluster-vol /var/lib/nova/instances
echo "10.68.125.18:/nova-gluster-vol /var/lib/nova/instances glusterfs defaults 1 2" >> /etc/fstab
chown -R nova:nova  /var/lib/nova/instances

2.Configure libvirt and nova.conf on every nova-compute node

->Edit /etc/libvirt/libvirtd.conf

listen_tls = 0
listen_tcp = 1
auth_tcp = "none"

->Edit /etc/sysconfig/libvirtd 

LIBVIRTD_ARGS="–listen"

->Restart libvirtd

service libvirtd restart

->Edit /etc/nova/nova.conf, add following line:

live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

3.Let's try live migration

->Check running VMs

nova list
+--------------------------------------+-------------------+--------+---------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+--------+---------------------+
| 5374577e-7417-4add-b23f-06de3b42c4

分享到:QQ空间新浪微博腾讯微博微信百度贴吧QQ好友复制网址打印

您可能想查找下面的文章:

  • 《转》OpenStack Live Migration,《转》openstack

相关文章

  • hadoop-2.6.0 Unhealthy Nodes 问题,hadoop2.6.0安装
  • Spark性能优化指南:高级篇
  • 孙其功陪你学之——Spark 正则化和SparkSQL,孙其功sparksql
  • HBase RegionServer详解(未完),hbaseregionserver
  • hive的变量传递设置,hive变量传递设置
  • 一道hadoop面试题,hadoop面试题
  • openstack:cinder-volume配置lvm/glusterfs/IP-SAN等多种后端,openstacklvm
  • 观点 | 为什么说云主机比物理机故障率更低?,云主机
  • hadoop集群搭建之NFS服务,hadoop集群nfs
  • 一步一步教你搭建基于docker的MongoDB复制集群环境,dockermongodb

文章分类

  • windows
  • 服务器硬件
  • 服务器运维
  • 云计算
  • 虚拟化
  • IIS教程
  • Linux
  • Apache
  • Ftp
  • DNS
  • Nginx

最近更新的内容

    • 《转》ceilometer的数据采集机制入门,《转》ceilometer
    • 如何解决Greenplum中无法通过标准命令修复的元数据错误,greenplum元数据
    • 智能助手相伴,享受人机温情,智能助手人机
    • RabbitMQ(python实现)学习之一:简单两点传输“Hello World”的实现,rabbitmqpython
    • Spark DataFrame小试牛刀,sparkdataframe小试
    • [Hive]关于Hive的启动问题,hive启动问题
    • hadoop2.x编译(三),hadoop2.x编译
    • 深入理解kafka设计原理,深入理解kafka设计
    • 在spark上运行独立程序(Self-Contained Applications),selfcontained
    • jsp里input中获取当前时间,与WdatePicker配合使用,inputwdatepicker

关于我们 - 联系我们 - 免责声明 - 网站地图

©2020-2025 All Rights Reserved. linkedu.com 版权所有