openstack-mitaka调整实例大小报错
1 问题1
在openstack图形界面对实例进行迁移操作时,出现如下错误
1 | 2017-09-18 11:00:21.828 1386 INFO nova.compute.resource_tracker [req-4fe2d206-e9bc-4a61-9389-a01007335c61 - - - - -] Total usable vcpus: 12, total allocated vcpus: 5 |
建立各计算节点、控制节点之间的SSH免密登录,建立私钥
解决方案
- 开启nova用户登录权限
1 | usermod -s /bin/bash nova |
- 切换到nova用户
1 | su nova |
生成密钥(各个计算节点执行,控制节点也执行)
1 | $ ssh-keygen -t rsa |
- 所有计算节点均配置
依然在nova用户下操作
1 | $cat << EOF > ~/.ssh/config |
- 发送公钥到控制节点
compute1
1 | scp id_rsa.pub 10.20.0.2:/var/lib/nova/.ssh/id_rsa.pub2 |
compute2
1 | scp id_rsa.pub 10.20.0.2:/var/lib/nova/.ssh/id_rsa.pub3 |
contrloller(10.20.0.2)
1 | # cat id_dsa.pub id_dsa.pub2 id_rsa.pub id_rsa.pub2 id_rsa.pub3 id_dsa.pub3 > authorized_keys |
修改权限
1 | # chown nova:nova /var/lib/nova/.ssh/id_rsa /var/lib/nova/.ssh/authorized_keys |
- 登录测试
1 | ssh nova@computer |
在迁移实例,不再报错,并成功。
实例迁移根据使用存储不同,有不同差异,详细介绍参考openstack官方文档
Openstack调整实例大小_冷迁移
有时虚拟机创建后发现虚拟机规格太小,满足不了业务需求。于是需要在线拉伸虚拟机的规格。
1、用admin用户登录dashboard,创建满足需求的虚拟机规格
2、输入适当的参数
3、修改controller和各个computer节点的nova.cnf文件,打开下面两个参数
1 | allow_resize_to_same_host=True |
4、重启控制节点nova服务
1 | # systemctl restart openstack-nova-api.service openstack-nova-conductor.service openstack-nova-scheduler.service openstack-nova-cert.service openstack-nova-consoleauth.service openstack-nova-compute.service openstack-nova-novncproxy.service |
5、重启计算节点nova服务
1 | # service openstack-nova-compute restart |
Openstack的临时(Ephemeral)存储和块(Block)存储
转载:http://www.aboutyun.com/thread-8114-1-1.html
1 Openstack的临时(Ephemeral)存储和块(Block)存储
1.2 问题导读:
1、OpenStack中什么是临时存储,有什么好处?
2、什么是块存储,和临时的有什么不同?
1.3 背景
Openstack不管是Ephemeral Storage还是Block Storage, 其实从接口上看,其实都是块服务。那么为什么要搞两个不同的类型呢,本文从这两种不同类型块存储的实现上来分析下其中的原因。
1.4 临时存储
Openstack临时存储是由Nova提供的,主要是利用主机的本地存储给虚拟机提供卷服务。如果虚拟机被删除了,挂在这个虚拟机上的任何临时存储自动释放。这样的实现方式决定了:
使用Ephemeral Storage的虚拟机不能支持迁移,以及和虚拟机迁移相关的特性,包括 1) HA 2) 动态调度 等等。
存放在Ephemeral Storage上的数据是高度不可靠的,任何虚拟机和主机的故障都可能会导致数据丢失。
1.5 块存储
目前Openstack的块存储由Cinder提供,其后端支持很多类型的存储设备,比如多个厂商不同型号的阵列设备,或者是Ceph, Glusterfs, Sheepdog之类的分布式存储系统。基于块存储,可以为用户提供:
高可靠的存储(基于阵列的RAID, 或者是分布式存储的多副本机制;甚至还可以充分利用设备的备份,远程复制能力)
共享存储 (意味着可以支持HA, 虚拟机迁移等等)
1.6 临时存储的妙用
这么看来,临时存储岂不是几乎没什么作用了,那为什么还需要提供这个服务呢?其实原因非常简单: 这个服务便宜,而且便宜到令人发指的地步,比如AWS的Ephemeral Storage, 就是免费的。用户可以用它来做不少有意思的事情,比如:
无状态虚拟机,为系统提供Cache服务
为虚拟机操作系统提供交换分区,或者用来存放其它类型的临时文件
改进EBS的性能,比如买4个EBS盘,再配置2个免费的Ephermal盘,组建一个RAID 10系统
1.7 总结
对于云服务提供商,不管采用什么样的后端技术,为用户提供7个9甚至更高可靠性的EBS服务,成本是巨大的,如果使用阵列,其价格本来就昂贵;如果使用分布式存储,起码要3个副本,再考虑到定期备份,快照,跨地域容灾,成本一样很高。现在的SATA, SAS盘便宜而且量又足,很容易造成在本地主机上空闲,所以干脆直接送给用户,由他们去玩,而且对于玩的好的用户,还真能对业务有不少帮助。
最后再附上Openstack官方文档对几种存储的对比:
Openstack热迁移和冷迁移
1 迁移类型:
*非在线迁移
(有时也称之为‘迁移
’)。也就是在迁移到另外的计算节点时的这段时间虚拟机实例是处于宕机状态的。在此情况下,实例需要重启才能工作。
*在线迁移
(或 ‘真正的在线迁移
‘)。实例几乎没有宕机时间。用于当实例需要在迁移时保持运行。在线迁移有下面几种类型:
基于共享存储的在线迁移。所有的Hypervisor都可以访问共享存储。
块在线迁移。无须共享存储。但诸如CD-ROM之类的只读设备是无法实现的。
基于卷的在线迁移。实例都是基于卷的而不是临时的磁盘,无须共享存储,也支持迁移(目前仅支持基于libvirt的hypervisor)。
1.1 什么是热迁移
热迁移
(Live Migration,又叫动态迁移
、实时迁移
),即虚拟机保存/恢复(Save/Restore):将整个虚拟机的运行状态完整保存下来,同时可以快速的恢复到原有硬件平台甚至是不同硬件平台上。恢复以后,虚拟机仍旧平滑运行,用户不会察觉到任何差异。
1.2 Openstack热迁移
OpenStack有两种在线迁移类型:live migration
和block migration
。Livemigration
需要实例保存在NFS共享存储中,这种迁移主要是实例的内存状态的迁移,速度应该会很快。Block migration
除了实例内存状态要迁移外,还得迁移磁盘文件,速度会慢些,但是它不要求实例存储在共享文件系统中。
NFS允许一个系统在网络上与他人共享目录和文件。通过使用NFS,用户和程序可以像访问本地文件一样访问远端系统上的文件。
1.2.1 迁移步骤
迁移前的条件检查
动态迁移要成功执行,一些条件必须满足,所以在执行迁移前必须做一些条件检查。- 权限检查,执行迁移的用户是否有足够的权限执行动态迁移。
- 参数检查,传递给 API 的参数是否足够和正确,如是否指定了 block-migrate 参数。
- 检查目标物理主机是否存在。
- 检查被迁移的虚拟机是否是 running 状态。
- 检查源和目的物理主机上的 nova-compute service 是否正常运行。
- 检查目的物理主机和源物理主机是否是同一台机器。
- 检查目的物理主机是否有足够的内存(memory)。
- 检查目的和源物理主机器 hypervisor 和 hypervisor 的版本是否相同。
- 迁移前的预处理
在真正执行迁移前,必须做一下热身,做一些准备工作。
在目的物理主机上获得和准备虚拟机挂载的块设备(
volume
)。在目的物理主机上设置虚拟机的网络(
networks
)。目的物理主机上设置虚拟机的防火墙(
fireware
)。
- 迁移
条件满足并且做完了预处理工作后,就可以执行动态迁移了。主要步骤如下:
- 调用 libvirt python 接口 migrateToURI,来把源主机迁移到目的主机。
dom.migrateToURI(CONF.live_migration_uri % dest,logical_sum,None,CONF.live_migration_bandwidth)
live_migration_uri:这个 URI 就是在 3.2.2 里介绍的 libvirtd 进程定义的。
live_migration_bandwidth:这个参数定义了迁移过程中所使用的最大的带宽。 - 以一定的时间间隔(0.5)循环调用 wait_for_live_migration 方法,来检测虚拟机迁移 的状态,一直到虚拟机成功迁移为止。
- 迁移后的处理
当虚拟机迁移完成后,要做一些善后工作。
- 在源物理主机上 detach volume。
- 在源物理主机上释放 security group ingress rule。
- 在目的物理主机上更新数据库里虚拟机的状态。
- 在源物理主机上删除虚拟机。
上面四步正常完成后,虚拟机就成功的从源物理主机成功地迁移到了目的物理主机了
1.2.2 Live Migration 的实现
热迁移条件:
计算节点之间可以通过主机名互相访问
计算节点和控制节点的nova uid和gid保持一致
vncserver_proxyclient_address和vncserver_listen 监听的是本地IP
必须有共享存储,实例存放在共享存储中,且每个计算节点都可以访问共享存储。否则只能使用块迁移
1.2.3 配置
- 添加live_migration_flag
修改nova的配置文件,在[libvirt]
段下 添加如下字段
1 | live_migration_flag="VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_PERSIST_DEST,VIR_MIGRATE_TUNNELLED" |
- 配置配置versh免密码连接,修改/etc/libvirt/libvirtd.conf
添加如下配置
1 | listen_tls = 0 |
- 修改/etc/sysconfig/libvirtd 添加如下参数
1 | LIBVIRTD_CONFIG=/etc/libvirt/libvirtd.conf |
- 重启libvirt
1 | systemctl restart libvirtd.service |
- 查看监听端口:
1 | [root@compute1 ~]# netstat -lnpt | grep libvirtd |
- 测试:
1 | 在compute1节点上: |
如果能无密码连接上去,表示配置没问题
1.2.4动态迁移
- 查看所有实例
nova list - 查看需要迁移虚拟机实例
nova show f3d749ba-98e1-4624-9782-6da729ad164c - 查看可用的计算节点
nova-manage service list - 查看目标节点资源
nova-manage service describe_resource computer1 开始迁移,正常无任何回显
nova live-migration 8da00f69-05f6-4425-9a8a-df56b79a474f computer1也可以通过dashboard 节点迁移
用节点迁移需要使用admin管理员用户执
1.3 冷迁移配置
- 冷迁移需要启动nova账户,并配置ssh 免密码认证
1 | usermod -s /bin/bash nova |
将密钥复制到所有计算节点的/var/lib/nova/.ssh下,并设置权限为nova用户
- 编辑/etc/nova/nova.conf的配置文件,修改下面参数
1 | allow_resize_to_same_host=True |
- 在计算节点重启nova服务
1 | systemctl restart openstack-nova-compute |
- 在controller节点重启nova 相关服务
1 | systemctl restart openstack-nova-api.service openstack-nova-scheduler.service |