OpenStack

OpenStack

基于Openstack的KVM调优实战

大数据/云计算push 发表了文章 • 0 个评论 • 2159 次浏览 • 2015-11-18 21:58 • 来自相关话题

调优背景

2015年11月上旬,CRMAPP系统所使用的KVM虚拟机的CPU使用率过高异常,达到70%以上,相同业务压力下同性能配置的Vmware虚拟机的负载却非常低,只在10%以内波动,并且发现KVM宿主机的CPU使用率也异常高。




分析与解决

分别从以下几个方面逐一分析排查问题原因:
1、KVM的CPU虚拟模式
首先查看KVM虚拟机CPU信息如下:




与Vmware虚拟机CPU相比较如下:




通过比较Vmware与KVM的虚拟机CPU信息发现KVM虚拟机CPU模式存在如下几个问题:
[]缺少L3 Cache:初步分析是虚拟机CPU虚拟化模式选择不合理所导致。[/][]CPU不是NUMA架构并且CPU Topology不合理:KVM宿主机物理CPU属于NUMA多node的结构,虚拟机的CPU只有一个NUMA node,所有CPU Core都在这一个node中,且虚拟机CPU的Topology是多Socket单Core的形式。[/]
 
处理措施
>>>> 缺少L3 Cache针对该问题,检查了Openstack的nova.conf配置文件libvirt部分的cpu_mode的参数配置是host-model,该参数含义是根据物理CPU的特性,选择一个最靠近的标准CPU型号进行虚拟化模拟。 除了host-model外还可以有host-passthrough模式,该模式直接将物理CPU暴露给虚拟机使用,在虚拟机上完全可以看到的就是物理CPU的型号。


因Openstack 仍承载业务,选择小范围的修改cpu_mode的参数,通过将Openstack的代码文件 driver.py中cpu_mode的取值修改为host-passthrough并重启宿主机上Nova-computer服务与KVM虚拟机,将自动重新生成虚拟机的 libvirt.xml文件。>>>> CPU不是NUMA架构并且CPU Topology不合理经过梳理Openstack虚拟机的创建流程,并查阅Openstack官方文档与代码,发现在JUNO版的Openstack中,KVM的CPU的拓扑可以通过image或者flavor进行元数据传递来定义,如果没有特别的定义此类元数据,则模拟的CPU将是多Socket单Core单NUMA节点的CPU,这样的CPU与物理CPU完全不同。

通过nova命令对flavor增加了hw:numa_cpu、hw:numa_nodes、hw:cpu_sockets等属性。处理结果
经过上面两个方面的修改后,新建KVM虚拟机的CPU的信息发生如下改变,CPU的使用率有了明显下降,在10%到20%之间波动。
[]从单个NUMA节点变成4个NUMA节点[/][]具备了L3 cache[/][]CPU的Topology从32个Socket每个Socket 1个 core,变成了4个Socket每个Socket 8个Core[/]




 
2、KVM宿主机与NUMA运行状况在NUMA的CPU内存架构下,无论是物理主机还是虚拟机,如果NUMA的配置不合理对应用程序的性能都有较大的影响,并且不同类型的应用都有不同的配置需求。

Vmware ESX 5.0及之后的版本支持一种叫做vNUMA的特性,它将Host的NUMA特征暴露给了GuestOS,从而使得Guest OS可以根据NUMA特征进行更高性能的调度。SUSE与Redhat作为原生的操作系统在NUMA调度上需要人为的根据应用程序的类型的做特殊配置,对云平台来说,这部分的工作是难以做到的。

在优化之前,CRM APP的KVM虚拟机的NUMA调度状态非常不理想,表现为所有NUMA 节点的numa_miss统计数值大于numa_hit,这意味着CPU访问内存的路径不是优化的,存在大量CPU访问remote memory的情况。因为宿主机Ubuntu 12.02自身带有Automatic NUMA balancing,所以物理主机NUMA调度运行状态良好。处理措施升级KVM虚拟机的操作系统 到SUSE 12 ,因为新版本的SUSE支持Automatic NUMA balancing,并且操作系统检测到硬件属于NUMA架构时将自动开启。处理结果在新建的KVM虚拟机的 dmesg日志中可以看到如下信息:

Enablingautomatic NUMA balancing. Configure with numa_balancing= or sysctl

经过24小时的运行之后,CRMAPP的KVM虚拟机运行状态良好,CPU用率可以稳定在10%左右。



同时NUMA调度也有了较大程度的改善





总结

[]通过各环节的优化,目前KVM虚拟机的CPU利用率过高问题不再发生,整体运行达到Vmware虚拟机水平。[/][]不同类型的应用程序对于NUMA适应性不同,需要进行针对性优化。JAVA在NUMA方面也可尝试进行优化。参考Oracle官方文档,JAVA7针对并行扫描垃圾回收站(Parallel Scavenger garbage collector)加入了对NUMA体系结构的支持,实现了NUMA感知的内存分配器,由它为Java应用提供自动的内存分配优化。[/][]目前RedHat7与SUSE 12都加入了NUMA自动负载均衡的特性,可以尽量采用较新版本的操作系统,无论是物理机还是虚拟机,对于NUMA调度的优化不仅与KVM虚拟机有关,其实物理主机也应该关注NUMA调度是否是最优的。[/] 查看全部


调优背景


2015年11月上旬,CRMAPP系统所使用的KVM虚拟机的CPU使用率过高异常,达到70%以上,相同业务压力下同性能配置的Vmware虚拟机的负载却非常低,只在10%以内波动,并且发现KVM宿主机的CPU使用率也异常高。
openstack_kvm.png


分析与解决


分别从以下几个方面逐一分析排查问题原因:
1、KVM的CPU虚拟模式
首先查看KVM虚拟机CPU信息如下:
openstack_kvm2.png

与Vmware虚拟机CPU相比较如下:
openstack_kvm3.png

通过比较Vmware与KVM的虚拟机CPU信息发现KVM虚拟机CPU模式存在如下几个问题:
    []缺少L3 Cache:初步分析是虚拟机CPU虚拟化模式选择不合理所导致。[/][]CPU不是NUMA架构并且CPU Topology不合理:KVM宿主机物理CPU属于NUMA多node的结构,虚拟机的CPU只有一个NUMA node,所有CPU Core都在这一个node中,且虚拟机CPU的Topology是多Socket单Core的形式。[/]

 
处理措施
>>>> 缺少L3 Cache
针对该问题,检查了Openstack的nova.conf配置文件libvirt部分的cpu_mode的参数配置是host-model,该参数含义是根据物理CPU的特性,选择一个最靠近的标准CPU型号进行虚拟化模拟。 除了host-model外还可以有host-passthrough模式,该模式直接将物理CPU暴露给虚拟机使用,在虚拟机上完全可以看到的就是物理CPU的型号。


因Openstack 仍承载业务,选择小范围的修改cpu_mode的参数,通过将Openstack的代码文件 driver.py中cpu_mode的取值修改为host-passthrough并重启宿主机上Nova-computer服务与KVM虚拟机,将自动重新生成虚拟机的 libvirt.xml文件。
>>>> CPU不是NUMA架构并且CPU Topology不合理
经过梳理Openstack虚拟机的创建流程,并查阅Openstack官方文档与代码,发现在JUNO版的Openstack中,KVM的CPU的拓扑可以通过image或者flavor进行元数据传递来定义,如果没有特别的定义此类元数据,则模拟的CPU将是多Socket单Core单NUMA节点的CPU,这样的CPU与物理CPU完全不同。

通过nova命令对flavor增加了hw:numa_cpu、hw:numa_nodes、hw:cpu_sockets等属性。
处理结果
经过上面两个方面的修改后,新建KVM虚拟机的CPU的信息发生如下改变,CPU的使用率有了明显下降,在10%到20%之间波动。
    []从单个NUMA节点变成4个NUMA节点[/][]具备了L3 cache[/][]CPU的Topology从32个Socket每个Socket 1个 core,变成了4个Socket每个Socket 8个Core[/]

openstack_kvm4.png

 
2、KVM宿主机与NUMA运行状况
在NUMA的CPU内存架构下,无论是物理主机还是虚拟机,如果NUMA的配置不合理对应用程序的性能都有较大的影响,并且不同类型的应用都有不同的配置需求。

Vmware ESX 5.0及之后的版本支持一种叫做vNUMA的特性,它将Host的NUMA特征暴露给了GuestOS,从而使得Guest OS可以根据NUMA特征进行更高性能的调度。SUSE与Redhat作为原生的操作系统在NUMA调度上需要人为的根据应用程序的类型的做特殊配置,对云平台来说,这部分的工作是难以做到的。

在优化之前,CRM APP的KVM虚拟机的NUMA调度状态非常不理想,表现为所有NUMA 节点的numa_miss统计数值大于numa_hit,这意味着CPU访问内存的路径不是优化的,存在大量CPU访问remote memory的情况。因为宿主机Ubuntu 12.02自身带有Automatic NUMA balancing,所以物理主机NUMA调度运行状态良好。
处理措施
升级KVM虚拟机的操作系统 到SUSE 12 ,因为新版本的SUSE支持Automatic NUMA balancing,并且操作系统检测到硬件属于NUMA架构时将自动开启。
处理结果
在新建的KVM虚拟机的 dmesg日志中可以看到如下信息:

Enablingautomatic NUMA balancing. Configure with numa_balancing= or sysctl

经过24小时的运行之后,CRMAPP的KVM虚拟机运行状态良好,CPU用率可以稳定在10%左右。
openstack_kvm5.png

同时NUMA调度也有了较大程度的改善
openstack_kvm6.png


总结


    []通过各环节的优化,目前KVM虚拟机的CPU利用率过高问题不再发生,整体运行达到Vmware虚拟机水平。[/][]不同类型的应用程序对于NUMA适应性不同,需要进行针对性优化。JAVA在NUMA方面也可尝试进行优化。参考Oracle官方文档,JAVA7针对并行扫描垃圾回收站(Parallel Scavenger garbage collector)加入了对NUMA体系结构的支持,实现了NUMA感知的内存分配器,由它为Java应用提供自动的内存分配优化。[/][]目前RedHat7与SUSE 12都加入了NUMA自动负载均衡的特性,可以尽量采用较新版本的操作系统,无论是物理机还是虚拟机,对于NUMA调度的优化不仅与KVM虚拟机有关,其实物理主机也应该关注NUMA调度是否是最优的。[/]

openstack nova集成docker

大数据/云计算Geek小A 发表了文章 • 0 个评论 • 1218 次浏览 • 2015-09-16 19:31 • 来自相关话题

    docker已经可以作为compute driver来使用,脱离了原来HEAT的模式,可以做到真正地使用nova来启动容器.这里记录一下openstack Kilo + docker 1.8的集成过程.所有组件环境基于centos7. 
架构图如下: 





安装docker

    在compute node节点上安装docker,强烈建议安装docker-engine 1.8,需要linux3.1的kernal版本,拥有较高的生产稳定性,并且有启动用户组,旧版的docker-io是没有用户组,集成的时候docker.sock的权限每次都是手工修改很不方便.# curl -sSL https://get.docker.com/ | sh
# usermod -aG docker nova
# systemctl enable docker.service
# systemctl start docker.service

安装novadocker

直接从github上clone安装# pip install -e git+https://github.com/stackforge/nova-docker#egg=novadocker
# cp -R src/etc/nova/rootwrap.d /etc/nova/
# chmod -R root.nova /etc/nova/rootwrap.d
# cd src/novadocker/
# python setup.py install

配置nova调用docker驱动

# vi /etc/nova/nova.conf
compute_driver = novadocker.virt.docker.DockerDriver

配置glance支持容器格式

# vi /etc/glance/glance-api.conf (修改后重启glance-api服务)
container_formats = ami,ari,aki,bare,ovf,docker

Fix bug设置

    由于novadocker开发的版本是基于nova比较新的版本,在现在发行的版本中使用会有一个BUG,下面是修复记录.
    
1.重启openstack-nova-compute服务时提示没有找到oslo_log模块# pip install oslo.log2.重启openstack-nova-compute服务时提示没有找到hv_type模块通过代码定位发现目前的版本中模块是nova.compute.hvtype
修改/usr/lib/python2.7/site-packages/novadocker/virt/docker/driver.py
把from nova.compute import hv_type 改为 from nova.compute import hvtype3.直接导入driver测试提示报错,CONF没有’my_ip’这个opt配置通过代码排查发现目前的openstack是使用oslo.config这个模块包来做cfg的导入和导出
但是在novadocker整个项目里面使用的oslo_config这个独立的模块
修改driver.py, client.py, hostinfo.py, vifs.py模块
from oslo_config import cfg 改为 from oslo.config import cfg4.直接导入driver测试提示继续报错,没有找到hvtype.DOCKER属性修改 /usr/lib/python2.7/site-packages/nova/compute/hvtype.py
在# specific ‘baremetal’ & ‘fake’ then added in.下面增加
DOCKER=’docker’    此时启动openstack-nova-compute已经正常

glance导入docker镜像

# docker pull hipache
# docker save hipache | glance image-create --is-public=True --container-format=docker --disk-format=raw --name hipache    需要注意的是glance导入后的名字一定要和docker images下显示的名字一模一样,否则创建时会提示无法找到镜像

启动容器实例

nova boot --image hipache --flavor 1 --nic net-id=342a0eef-e03d-4fd8-af3c-1ed485bee989 docker



1.此时启动容器实例报错失败,从nova-compute.log的日志看异常信息是”attach vif error”,具体是无法使用nova-rootwrap来提权进入namespace创建实例的网络接口google找到的这个BUG的解决是禁用compute节点的selinux2.继续下一个BUG,日志抛出一个Python异常是没有找到hardware.InstanceInfo模块进入目录/usr/lib/python2.7/site-packages/nova/virt
查看hardware.py的代码的确没有找到这个类或者函数,在github上找到nova项目的最新代码可以看到是有的.



把这个类的代码复制到本地的hardware.py里面
 
3.重启启动一个实例后,异常继续保持 



异常提示InstanceInfo没有getitem这个内置方法
根据driver.py里面的调用可以发现get_info调用的时候是hardware.InstanceInfo是返回一个字典
删除刚才在hardware.py复制的代码,重写InstanceInfodef InstanceInfo(state=None, max_mem_kb=0, mem_kb=0, num_cpu=0,cpu_time_ns=0, id=None):
Info={}
Info['state'] = state
Info['max_mem_kb'] = max_mem_kb
Info['self.mem_kb'] = mem_kb
Info['num_cpu'] = num_cpu
Info['cpu_time_ns'] = cpu_time_ns
Info['id'] = id
return Info此时启动实例正常无报错[root@openstack-k ~]# nova list
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| c9d7ef23-f0fe-488d-88b1-3b5650901820 | hipache | ACTIVE | - | Running | admin_private=192.168.0.101, 172.24.4.228 |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
[root@openstack-k ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14583d5d6308 hipache "supervisord -n" 5 hours ago Up 5 hours nova-c9d7ef23-f0fe-488d-88b1-3b5650901820
[root@openstack-k ~]#参考连接:https://wiki.openstack.org/wiki/Docker
http://docs.docker.com/installation/centos/
https://bugs.launchpad.net/nova-docker/+bug/1480246
https://github.com/openstack/nova/
https://github.com/stackforge/nova-docker原文链接:原文地址 查看全部
opdock1.png

    docker已经可以作为compute driver来使用,脱离了原来HEAT的模式,可以做到真正地使用nova来启动容器.这里记录一下openstack Kilo + docker 1.8的集成过程.所有组件环境基于centos7. 
架构图如下: 
openstack1.png


安装docker


    在compute node节点上安装docker,强烈建议安装docker-engine 1.8,需要linux3.1的kernal版本,拥有较高的生产稳定性,并且有启动用户组,旧版的docker-io是没有用户组,集成的时候docker.sock的权限每次都是手工修改很不方便.
# curl -sSL https://get.docker.com/ | sh
# usermod -aG docker nova
# systemctl enable docker.service
# systemctl start docker.service


安装novadocker


直接从github上clone安装
# pip install -e git+https://github.com/stackforge/nova-docker#egg=novadocker
# cp -R src/etc/nova/rootwrap.d /etc/nova/
# chmod -R root.nova /etc/nova/rootwrap.d
# cd src/novadocker/
# python setup.py install


配置nova调用docker驱动


# vi /etc/nova/nova.conf
compute_driver = novadocker.virt.docker.DockerDriver


配置glance支持容器格式


# vi /etc/glance/glance-api.conf (修改后重启glance-api服务)
container_formats = ami,ari,aki,bare,ovf,docker


Fix bug设置


    由于novadocker开发的版本是基于nova比较新的版本,在现在发行的版本中使用会有一个BUG,下面是修复记录.
    
1.重启openstack-nova-compute服务时提示没有找到oslo_log模块
# pip install oslo.log
2.重启openstack-nova-compute服务时提示没有找到hv_type模块
通过代码定位发现目前的版本中模块是nova.compute.hvtype 
修改/usr/lib/python2.7/site-packages/novadocker/virt/docker/driver.py
把from nova.compute import hv_type 改为 from nova.compute import hvtype
3.直接导入driver测试提示报错,CONF没有’my_ip’这个opt配置
通过代码排查发现目前的openstack是使用oslo.config这个模块包来做cfg的导入和导出 
但是在novadocker整个项目里面使用的oslo_config这个独立的模块
修改driver.py, client.py, hostinfo.py, vifs.py模块
from oslo_config import cfg 改为 from oslo.config import cfg
4.直接导入driver测试提示继续报错,没有找到hvtype.DOCKER属性
修改 /usr/lib/python2.7/site-packages/nova/compute/hvtype.py 
在# specific ‘baremetal’ & ‘fake’ then added in.下面增加
DOCKER=’docker’
    此时启动openstack-nova-compute已经正常


glance导入docker镜像


# docker pull hipache
# docker save hipache | glance image-create --is-public=True --container-format=docker --disk-format=raw --name hipache
    需要注意的是glance导入后的名字一定要和docker images下显示的名字一模一样,否则创建时会提示无法找到镜像


启动容器实例


nova boot --image hipache --flavor 1 --nic net-id=342a0eef-e03d-4fd8-af3c-1ed485bee989 docker
openstack2.png

1.此时启动容器实例报错失败,从nova-compute.log的日志看异常信息是”attach vif error”,具体是无法使用nova-rootwrap来提权进入namespace创建实例的网络接口
google找到的这个BUG的解决是禁用compute节点的selinux
2.继续下一个BUG,日志抛出一个Python异常是没有找到hardware.InstanceInfo模块
进入目录/usr/lib/python2.7/site-packages/nova/virt 
查看hardware.py的代码的确没有找到这个类或者函数,在github上找到nova项目的最新代码可以看到是有的.
openstack3.png

把这个类的代码复制到本地的hardware.py里面
 
3.重启启动一个实例后,异常继续保持 
openstack4.png
异常提示InstanceInfo没有getitem这个内置方法 
根据driver.py里面的调用可以发现get_info调用的时候是hardware.InstanceInfo是返回一个字典
删除刚才在hardware.py复制的代码,重写InstanceInfo
def InstanceInfo(state=None, max_mem_kb=0, mem_kb=0, num_cpu=0,cpu_time_ns=0, id=None):
Info={}
Info['state'] = state
Info['max_mem_kb'] = max_mem_kb
Info['self.mem_kb'] = mem_kb
Info['num_cpu'] = num_cpu
Info['cpu_time_ns'] = cpu_time_ns
Info['id'] = id
return Info
此时启动实例正常无报错
[root@openstack-k ~]# nova list
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| c9d7ef23-f0fe-488d-88b1-3b5650901820 | hipache | ACTIVE | - | Running | admin_private=192.168.0.101, 172.24.4.228 |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
[root@openstack-k ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14583d5d6308 hipache "supervisord -n" 5 hours ago Up 5 hours nova-c9d7ef23-f0fe-488d-88b1-3b5650901820
[root@openstack-k ~]#
参考连接:
https://wiki.openstack.org/wiki/Docker 
http://docs.docker.com/installation/centos/
https://bugs.launchpad.net/nova-docker/+bug/1480246
https://github.com/openstack/nova/
https://github.com/stackforge/nova-docker
原文链接:原文地址

基于Openstack的KVM调优实战

大数据/云计算push 发表了文章 • 0 个评论 • 2159 次浏览 • 2015-11-18 21:58 • 来自相关话题

调优背景

2015年11月上旬,CRMAPP系统所使用的KVM虚拟机的CPU使用率过高异常,达到70%以上,相同业务压力下同性能配置的Vmware虚拟机的负载却非常低,只在10%以内波动,并且发现KVM宿主机的CPU使用率也异常高。




分析与解决

分别从以下几个方面逐一分析排查问题原因:
1、KVM的CPU虚拟模式
首先查看KVM虚拟机CPU信息如下:




与Vmware虚拟机CPU相比较如下:




通过比较Vmware与KVM的虚拟机CPU信息发现KVM虚拟机CPU模式存在如下几个问题:
[]缺少L3 Cache:初步分析是虚拟机CPU虚拟化模式选择不合理所导致。[/][]CPU不是NUMA架构并且CPU Topology不合理:KVM宿主机物理CPU属于NUMA多node的结构,虚拟机的CPU只有一个NUMA node,所有CPU Core都在这一个node中,且虚拟机CPU的Topology是多Socket单Core的形式。[/]
 
处理措施
>>>> 缺少L3 Cache针对该问题,检查了Openstack的nova.conf配置文件libvirt部分的cpu_mode的参数配置是host-model,该参数含义是根据物理CPU的特性,选择一个最靠近的标准CPU型号进行虚拟化模拟。 除了host-model外还可以有host-passthrough模式,该模式直接将物理CPU暴露给虚拟机使用,在虚拟机上完全可以看到的就是物理CPU的型号。


因Openstack 仍承载业务,选择小范围的修改cpu_mode的参数,通过将Openstack的代码文件 driver.py中cpu_mode的取值修改为host-passthrough并重启宿主机上Nova-computer服务与KVM虚拟机,将自动重新生成虚拟机的 libvirt.xml文件。>>>> CPU不是NUMA架构并且CPU Topology不合理经过梳理Openstack虚拟机的创建流程,并查阅Openstack官方文档与代码,发现在JUNO版的Openstack中,KVM的CPU的拓扑可以通过image或者flavor进行元数据传递来定义,如果没有特别的定义此类元数据,则模拟的CPU将是多Socket单Core单NUMA节点的CPU,这样的CPU与物理CPU完全不同。

通过nova命令对flavor增加了hw:numa_cpu、hw:numa_nodes、hw:cpu_sockets等属性。处理结果
经过上面两个方面的修改后,新建KVM虚拟机的CPU的信息发生如下改变,CPU的使用率有了明显下降,在10%到20%之间波动。
[]从单个NUMA节点变成4个NUMA节点[/][]具备了L3 cache[/][]CPU的Topology从32个Socket每个Socket 1个 core,变成了4个Socket每个Socket 8个Core[/]




 
2、KVM宿主机与NUMA运行状况在NUMA的CPU内存架构下,无论是物理主机还是虚拟机,如果NUMA的配置不合理对应用程序的性能都有较大的影响,并且不同类型的应用都有不同的配置需求。

Vmware ESX 5.0及之后的版本支持一种叫做vNUMA的特性,它将Host的NUMA特征暴露给了GuestOS,从而使得Guest OS可以根据NUMA特征进行更高性能的调度。SUSE与Redhat作为原生的操作系统在NUMA调度上需要人为的根据应用程序的类型的做特殊配置,对云平台来说,这部分的工作是难以做到的。

在优化之前,CRM APP的KVM虚拟机的NUMA调度状态非常不理想,表现为所有NUMA 节点的numa_miss统计数值大于numa_hit,这意味着CPU访问内存的路径不是优化的,存在大量CPU访问remote memory的情况。因为宿主机Ubuntu 12.02自身带有Automatic NUMA balancing,所以物理主机NUMA调度运行状态良好。处理措施升级KVM虚拟机的操作系统 到SUSE 12 ,因为新版本的SUSE支持Automatic NUMA balancing,并且操作系统检测到硬件属于NUMA架构时将自动开启。处理结果在新建的KVM虚拟机的 dmesg日志中可以看到如下信息:

Enablingautomatic NUMA balancing. Configure with numa_balancing= or sysctl

经过24小时的运行之后,CRMAPP的KVM虚拟机运行状态良好,CPU用率可以稳定在10%左右。



同时NUMA调度也有了较大程度的改善





总结

[]通过各环节的优化,目前KVM虚拟机的CPU利用率过高问题不再发生,整体运行达到Vmware虚拟机水平。[/][]不同类型的应用程序对于NUMA适应性不同,需要进行针对性优化。JAVA在NUMA方面也可尝试进行优化。参考Oracle官方文档,JAVA7针对并行扫描垃圾回收站(Parallel Scavenger garbage collector)加入了对NUMA体系结构的支持,实现了NUMA感知的内存分配器,由它为Java应用提供自动的内存分配优化。[/][]目前RedHat7与SUSE 12都加入了NUMA自动负载均衡的特性,可以尽量采用较新版本的操作系统,无论是物理机还是虚拟机,对于NUMA调度的优化不仅与KVM虚拟机有关,其实物理主机也应该关注NUMA调度是否是最优的。[/] 查看全部


调优背景


2015年11月上旬,CRMAPP系统所使用的KVM虚拟机的CPU使用率过高异常,达到70%以上,相同业务压力下同性能配置的Vmware虚拟机的负载却非常低,只在10%以内波动,并且发现KVM宿主机的CPU使用率也异常高。
openstack_kvm.png


分析与解决


分别从以下几个方面逐一分析排查问题原因:
1、KVM的CPU虚拟模式
首先查看KVM虚拟机CPU信息如下:
openstack_kvm2.png

与Vmware虚拟机CPU相比较如下:
openstack_kvm3.png

通过比较Vmware与KVM的虚拟机CPU信息发现KVM虚拟机CPU模式存在如下几个问题:
    []缺少L3 Cache:初步分析是虚拟机CPU虚拟化模式选择不合理所导致。[/][]CPU不是NUMA架构并且CPU Topology不合理:KVM宿主机物理CPU属于NUMA多node的结构,虚拟机的CPU只有一个NUMA node,所有CPU Core都在这一个node中,且虚拟机CPU的Topology是多Socket单Core的形式。[/]

 
处理措施
>>>> 缺少L3 Cache
针对该问题,检查了Openstack的nova.conf配置文件libvirt部分的cpu_mode的参数配置是host-model,该参数含义是根据物理CPU的特性,选择一个最靠近的标准CPU型号进行虚拟化模拟。 除了host-model外还可以有host-passthrough模式,该模式直接将物理CPU暴露给虚拟机使用,在虚拟机上完全可以看到的就是物理CPU的型号。


因Openstack 仍承载业务,选择小范围的修改cpu_mode的参数,通过将Openstack的代码文件 driver.py中cpu_mode的取值修改为host-passthrough并重启宿主机上Nova-computer服务与KVM虚拟机,将自动重新生成虚拟机的 libvirt.xml文件。
>>>> CPU不是NUMA架构并且CPU Topology不合理
经过梳理Openstack虚拟机的创建流程,并查阅Openstack官方文档与代码,发现在JUNO版的Openstack中,KVM的CPU的拓扑可以通过image或者flavor进行元数据传递来定义,如果没有特别的定义此类元数据,则模拟的CPU将是多Socket单Core单NUMA节点的CPU,这样的CPU与物理CPU完全不同。

通过nova命令对flavor增加了hw:numa_cpu、hw:numa_nodes、hw:cpu_sockets等属性。
处理结果
经过上面两个方面的修改后,新建KVM虚拟机的CPU的信息发生如下改变,CPU的使用率有了明显下降,在10%到20%之间波动。
    []从单个NUMA节点变成4个NUMA节点[/][]具备了L3 cache[/][]CPU的Topology从32个Socket每个Socket 1个 core,变成了4个Socket每个Socket 8个Core[/]

openstack_kvm4.png

 
2、KVM宿主机与NUMA运行状况
在NUMA的CPU内存架构下,无论是物理主机还是虚拟机,如果NUMA的配置不合理对应用程序的性能都有较大的影响,并且不同类型的应用都有不同的配置需求。

Vmware ESX 5.0及之后的版本支持一种叫做vNUMA的特性,它将Host的NUMA特征暴露给了GuestOS,从而使得Guest OS可以根据NUMA特征进行更高性能的调度。SUSE与Redhat作为原生的操作系统在NUMA调度上需要人为的根据应用程序的类型的做特殊配置,对云平台来说,这部分的工作是难以做到的。

在优化之前,CRM APP的KVM虚拟机的NUMA调度状态非常不理想,表现为所有NUMA 节点的numa_miss统计数值大于numa_hit,这意味着CPU访问内存的路径不是优化的,存在大量CPU访问remote memory的情况。因为宿主机Ubuntu 12.02自身带有Automatic NUMA balancing,所以物理主机NUMA调度运行状态良好。
处理措施
升级KVM虚拟机的操作系统 到SUSE 12 ,因为新版本的SUSE支持Automatic NUMA balancing,并且操作系统检测到硬件属于NUMA架构时将自动开启。
处理结果
在新建的KVM虚拟机的 dmesg日志中可以看到如下信息:

Enablingautomatic NUMA balancing. Configure with numa_balancing= or sysctl

经过24小时的运行之后,CRMAPP的KVM虚拟机运行状态良好,CPU用率可以稳定在10%左右。
openstack_kvm5.png

同时NUMA调度也有了较大程度的改善
openstack_kvm6.png


总结


    []通过各环节的优化,目前KVM虚拟机的CPU利用率过高问题不再发生,整体运行达到Vmware虚拟机水平。[/][]不同类型的应用程序对于NUMA适应性不同,需要进行针对性优化。JAVA在NUMA方面也可尝试进行优化。参考Oracle官方文档,JAVA7针对并行扫描垃圾回收站(Parallel Scavenger garbage collector)加入了对NUMA体系结构的支持,实现了NUMA感知的内存分配器,由它为Java应用提供自动的内存分配优化。[/][]目前RedHat7与SUSE 12都加入了NUMA自动负载均衡的特性,可以尽量采用较新版本的操作系统,无论是物理机还是虚拟机,对于NUMA调度的优化不仅与KVM虚拟机有关,其实物理主机也应该关注NUMA调度是否是最优的。[/]

openstack nova集成docker

大数据/云计算Geek小A 发表了文章 • 0 个评论 • 1218 次浏览 • 2015-09-16 19:31 • 来自相关话题

    docker已经可以作为compute driver来使用,脱离了原来HEAT的模式,可以做到真正地使用nova来启动容器.这里记录一下openstack Kilo + docker 1.8的集成过程.所有组件环境基于centos7. 
架构图如下: 





安装docker

    在compute node节点上安装docker,强烈建议安装docker-engine 1.8,需要linux3.1的kernal版本,拥有较高的生产稳定性,并且有启动用户组,旧版的docker-io是没有用户组,集成的时候docker.sock的权限每次都是手工修改很不方便.# curl -sSL https://get.docker.com/ | sh
# usermod -aG docker nova
# systemctl enable docker.service
# systemctl start docker.service

安装novadocker

直接从github上clone安装# pip install -e git+https://github.com/stackforge/nova-docker#egg=novadocker
# cp -R src/etc/nova/rootwrap.d /etc/nova/
# chmod -R root.nova /etc/nova/rootwrap.d
# cd src/novadocker/
# python setup.py install

配置nova调用docker驱动

# vi /etc/nova/nova.conf
compute_driver = novadocker.virt.docker.DockerDriver

配置glance支持容器格式

# vi /etc/glance/glance-api.conf (修改后重启glance-api服务)
container_formats = ami,ari,aki,bare,ovf,docker

Fix bug设置

    由于novadocker开发的版本是基于nova比较新的版本,在现在发行的版本中使用会有一个BUG,下面是修复记录.
    
1.重启openstack-nova-compute服务时提示没有找到oslo_log模块# pip install oslo.log2.重启openstack-nova-compute服务时提示没有找到hv_type模块通过代码定位发现目前的版本中模块是nova.compute.hvtype
修改/usr/lib/python2.7/site-packages/novadocker/virt/docker/driver.py
把from nova.compute import hv_type 改为 from nova.compute import hvtype3.直接导入driver测试提示报错,CONF没有’my_ip’这个opt配置通过代码排查发现目前的openstack是使用oslo.config这个模块包来做cfg的导入和导出
但是在novadocker整个项目里面使用的oslo_config这个独立的模块
修改driver.py, client.py, hostinfo.py, vifs.py模块
from oslo_config import cfg 改为 from oslo.config import cfg4.直接导入driver测试提示继续报错,没有找到hvtype.DOCKER属性修改 /usr/lib/python2.7/site-packages/nova/compute/hvtype.py
在# specific ‘baremetal’ & ‘fake’ then added in.下面增加
DOCKER=’docker’    此时启动openstack-nova-compute已经正常

glance导入docker镜像

# docker pull hipache
# docker save hipache | glance image-create --is-public=True --container-format=docker --disk-format=raw --name hipache    需要注意的是glance导入后的名字一定要和docker images下显示的名字一模一样,否则创建时会提示无法找到镜像

启动容器实例

nova boot --image hipache --flavor 1 --nic net-id=342a0eef-e03d-4fd8-af3c-1ed485bee989 docker



1.此时启动容器实例报错失败,从nova-compute.log的日志看异常信息是”attach vif error”,具体是无法使用nova-rootwrap来提权进入namespace创建实例的网络接口google找到的这个BUG的解决是禁用compute节点的selinux2.继续下一个BUG,日志抛出一个Python异常是没有找到hardware.InstanceInfo模块进入目录/usr/lib/python2.7/site-packages/nova/virt
查看hardware.py的代码的确没有找到这个类或者函数,在github上找到nova项目的最新代码可以看到是有的.



把这个类的代码复制到本地的hardware.py里面
 
3.重启启动一个实例后,异常继续保持 



异常提示InstanceInfo没有getitem这个内置方法
根据driver.py里面的调用可以发现get_info调用的时候是hardware.InstanceInfo是返回一个字典
删除刚才在hardware.py复制的代码,重写InstanceInfodef InstanceInfo(state=None, max_mem_kb=0, mem_kb=0, num_cpu=0,cpu_time_ns=0, id=None):
Info={}
Info['state'] = state
Info['max_mem_kb'] = max_mem_kb
Info['self.mem_kb'] = mem_kb
Info['num_cpu'] = num_cpu
Info['cpu_time_ns'] = cpu_time_ns
Info['id'] = id
return Info此时启动实例正常无报错[root@openstack-k ~]# nova list
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| c9d7ef23-f0fe-488d-88b1-3b5650901820 | hipache | ACTIVE | - | Running | admin_private=192.168.0.101, 172.24.4.228 |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
[root@openstack-k ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14583d5d6308 hipache "supervisord -n" 5 hours ago Up 5 hours nova-c9d7ef23-f0fe-488d-88b1-3b5650901820
[root@openstack-k ~]#参考连接:https://wiki.openstack.org/wiki/Docker
http://docs.docker.com/installation/centos/
https://bugs.launchpad.net/nova-docker/+bug/1480246
https://github.com/openstack/nova/
https://github.com/stackforge/nova-docker原文链接:原文地址 查看全部
opdock1.png

    docker已经可以作为compute driver来使用,脱离了原来HEAT的模式,可以做到真正地使用nova来启动容器.这里记录一下openstack Kilo + docker 1.8的集成过程.所有组件环境基于centos7. 
架构图如下: 
openstack1.png


安装docker


    在compute node节点上安装docker,强烈建议安装docker-engine 1.8,需要linux3.1的kernal版本,拥有较高的生产稳定性,并且有启动用户组,旧版的docker-io是没有用户组,集成的时候docker.sock的权限每次都是手工修改很不方便.
# curl -sSL https://get.docker.com/ | sh
# usermod -aG docker nova
# systemctl enable docker.service
# systemctl start docker.service


安装novadocker


直接从github上clone安装
# pip install -e git+https://github.com/stackforge/nova-docker#egg=novadocker
# cp -R src/etc/nova/rootwrap.d /etc/nova/
# chmod -R root.nova /etc/nova/rootwrap.d
# cd src/novadocker/
# python setup.py install


配置nova调用docker驱动


# vi /etc/nova/nova.conf
compute_driver = novadocker.virt.docker.DockerDriver


配置glance支持容器格式


# vi /etc/glance/glance-api.conf (修改后重启glance-api服务)
container_formats = ami,ari,aki,bare,ovf,docker


Fix bug设置


    由于novadocker开发的版本是基于nova比较新的版本,在现在发行的版本中使用会有一个BUG,下面是修复记录.
    
1.重启openstack-nova-compute服务时提示没有找到oslo_log模块
# pip install oslo.log
2.重启openstack-nova-compute服务时提示没有找到hv_type模块
通过代码定位发现目前的版本中模块是nova.compute.hvtype 
修改/usr/lib/python2.7/site-packages/novadocker/virt/docker/driver.py
把from nova.compute import hv_type 改为 from nova.compute import hvtype
3.直接导入driver测试提示报错,CONF没有’my_ip’这个opt配置
通过代码排查发现目前的openstack是使用oslo.config这个模块包来做cfg的导入和导出 
但是在novadocker整个项目里面使用的oslo_config这个独立的模块
修改driver.py, client.py, hostinfo.py, vifs.py模块
from oslo_config import cfg 改为 from oslo.config import cfg
4.直接导入driver测试提示继续报错,没有找到hvtype.DOCKER属性
修改 /usr/lib/python2.7/site-packages/nova/compute/hvtype.py 
在# specific ‘baremetal’ & ‘fake’ then added in.下面增加
DOCKER=’docker’
    此时启动openstack-nova-compute已经正常


glance导入docker镜像


# docker pull hipache
# docker save hipache | glance image-create --is-public=True --container-format=docker --disk-format=raw --name hipache
    需要注意的是glance导入后的名字一定要和docker images下显示的名字一模一样,否则创建时会提示无法找到镜像


启动容器实例


nova boot --image hipache --flavor 1 --nic net-id=342a0eef-e03d-4fd8-af3c-1ed485bee989 docker
openstack2.png

1.此时启动容器实例报错失败,从nova-compute.log的日志看异常信息是”attach vif error”,具体是无法使用nova-rootwrap来提权进入namespace创建实例的网络接口
google找到的这个BUG的解决是禁用compute节点的selinux
2.继续下一个BUG,日志抛出一个Python异常是没有找到hardware.InstanceInfo模块
进入目录/usr/lib/python2.7/site-packages/nova/virt 
查看hardware.py的代码的确没有找到这个类或者函数,在github上找到nova项目的最新代码可以看到是有的.
openstack3.png

把这个类的代码复制到本地的hardware.py里面
 
3.重启启动一个实例后,异常继续保持 
openstack4.png
异常提示InstanceInfo没有getitem这个内置方法 
根据driver.py里面的调用可以发现get_info调用的时候是hardware.InstanceInfo是返回一个字典
删除刚才在hardware.py复制的代码,重写InstanceInfo
def InstanceInfo(state=None, max_mem_kb=0, mem_kb=0, num_cpu=0,cpu_time_ns=0, id=None):
Info={}
Info['state'] = state
Info['max_mem_kb'] = max_mem_kb
Info['self.mem_kb'] = mem_kb
Info['num_cpu'] = num_cpu
Info['cpu_time_ns'] = cpu_time_ns
Info['id'] = id
return Info
此时启动实例正常无报错
[root@openstack-k ~]# nova list
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| c9d7ef23-f0fe-488d-88b1-3b5650901820 | hipache | ACTIVE | - | Running | admin_private=192.168.0.101, 172.24.4.228 |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
[root@openstack-k ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14583d5d6308 hipache "supervisord -n" 5 hours ago Up 5 hours nova-c9d7ef23-f0fe-488d-88b1-3b5650901820
[root@openstack-k ~]#
参考连接:
https://wiki.openstack.org/wiki/Docker 
http://docs.docker.com/installation/centos/
https://bugs.launchpad.net/nova-docker/+bug/1480246
https://github.com/openstack/nova/
https://github.com/stackforge/nova-docker
原文链接:原文地址
OpenStack是一个开源的云计算管理平台项目,由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境,项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。