OpenStack虚拟机Resize节点不变

通常用户在创建了虚拟机之后,可能会适当地修改flavor,比如CPU多配置一些核,内存扩大一些等,这样都会用到resize功能,但是往往修改了规格之后,有时候会发现虚拟机所在的宿主节点机也发生了改变,也就是发生了迁移,也就是说可以理解为resize是在migrate的同时,改变了虚拟机的flavor

但在具体实现的地方,有这么一段注释

def resize(self, context, instance, flavor_id=None, force_host=None,
           **extra_instance_updates):
    """Resize (ie, migrate) a running instance.

    If flavor_id is None, the process is considered a migration, keeping
    the original flavor_id. If flavor_id is not None, the instance should
    be migrated to a new host and resized to the new flavor_id.
    """

这里写的很清楚,传进去的可选参数flavor_id如果为空的话,那么虚拟机执行resize操作其实是和migrate操作是一样的效果,有兴趣可以看下函数实现,在nova/compute/api.py里;直接查看一下resize命令可以看到这两个参数居然都是必选的,这说明了API调用和novaclient封装的还是有一定区别的

nova help resize
usage: nova resize [--poll] <server> <flavor>

但是否一定会修改host呢,如果是这样,那单节点岂不是不能进行resize操作了?所以答案显示然否定的

$ cat /etc/nova/nova.conf | grep allow_resize
allow_resize_to_same_host = True

在nova的配置文件当中,加入这一行,就能兼容单节点和多节点的resize操作,但是要注意的是,修改了配置之后一定要重启nova服务,具体来说我没记错的话应该是nova-api和nova-compute这两个服务

我们对openstack这里做了一定修改,为什么设置成允许不更换节点呢,甚至优先考虑不更换,主要来自两个方面,一个是从容量分配的角度,调度算法已经被修改成虚拟机的创建优先调度到资源更多的节点上,以保证节点之间负载的均衡,另一个就是从性能方面考虑,假如本节点在资源最充足的情况下,为何还要调度迁移到其它节点去呢,直接不更换节点进行扩展flavor操作,都省了migrate这一个漫长的过程

下面虚拟机进行resize,这里就直接通过novaclient命令执行,而不用RESTful的http接口了

通过一个脚本,打印resize过程中status的变化

#!/bin/bash

uuid=$1
tmp=ACTIVE
echo "Start: "`nova show $uuid | awk '{if ($2 == key) print $4}' key=OS-EXT-SRV-ATTR:host`
nova resize $uuid 2
while true; do
    status=`nova show $uuid | awk '{if ($2 == key) print $4}' key=status`
    if test $status != $tmp; then
        tmp=$status
        echo $status
    elif test $status = "ACTIVE"; then
        echo $status
        break
    fi
    sleep 2
done
echo "Stop: "`nova show $uuid | awk '{if ($2 == key) print $4}' key=OS-EXT-SRV-ATTR:host`

这里通过nova show得到status的输出状态,最终执行的结果为

Start: 10-180-0-47
RESIZE
VERIFY_RESIZE
ACTIVE
ACTIVE
Stop: 10-180-0-47

可以看到这里的过程,虚拟机状态只有两个,一个是RESIZE,另一个就是RESIZE之后的确认工作 

 

发表评论