02168888812
云终端系列报道第七十七期 - 大规模部署 2016-09-09

炙伦云终端分享嘉宾:


三、大规模部署中遇到各种坎
    01.软件版本选取
        
    在搭建OpenStack前,必须进行需求分析,确定所需的需求。然后根据需求选取满足条件的OpenStack及相关组件的版本,以避免后期出现各种系统及虚拟机问题。
    我们根据携程呼叫中心的业务需要,选好了几个版本的KVM、QEMU,以及OpenVSwitch,在选取能适配它们的几个可用kernel、Libvirt版本,并剔除了不稳定版本或者有已知问题的版本,将这些组件组成合理的组合,进行7x24小时用户模拟自动测试,找到最稳定、合适的并满足需求的,作生产上线使用。
    
    02.资源超分    
    
    超分与应用场景强关联。一定要首先确定需求,是CPU密集、内存密集、IO密集还是存储密集。在做了充足的用户调查后,我们准备了大量用户模拟自动化脚本,进行自动化测试,以选取最合理超分值。
    从我们的测试结果看,瓶颈主要是内存。内存超分过度会导致主机直接OOM(Out Of Memory)宕机。Windows及Windows应用吃内存比较严重,特别是像Chrome这些程序,优先占用内存先。虽然我们使用KSM(Kernel Samepage Merging,相同内存页合并功能),省了一些内存,但最终上线也只能达到1:1.2的超分。
    对于IO,在Windows启动阶段比较明显。大量Windows同时启动时会造成启动风暴情,在我们的极端条件测试中出现过启动Windows需要40分钟,硬盘IO 100%使用,每个读写请求平均0.2秒响应。所以,在大规模部署时,对虚拟机并发开机数一定要有一定限制。同时,硬盘一定要多块做RAID,以提供更高的IO吞吐量。
    最后是CPU。 CPU过度超分会严重影响用户体验。但是一般不会造成宿主机宕机。在我们的测试条件下,超分到1:2用户体验开始下降,所以实际上线超分不多。
    最终我们现在生产环境,是以内存为标准进行超分,硬盘、CPU控制在可接受范围。
    
    03.网络细节

    多DNSMasq实例问题
    我们虚拟机的IP地址通过DHCP获取。DHCP服务端我们使用的DNSMasq比较老,只是简单的实现了多实例运行,但并未真正实现绑定到虚拟接口。
    在生产环境,我们观察到VM都能获取IP,但是在续租IP的时候大量失败。经抓包分析,虚拟机在第一次请求IP时,由于自身无IP地址,使用的是广播方式进行DHCP请求;在续租时,由于本身有IP地址,也已明确DHCP服务端地址,所以采用IP点对点单播请求。
    服务端,多个DNSMasq实例运行的情况下,如果是广播包,所有DNSMasq都收到消息,所有广播请求能正确回复。在单播情况下,只有最后启动的DNSMasq能收到请求,最终导致虚拟机得不到正确的DHCP续租响应。最终我们通过升级DNSMasq解决。
    宿主机重启导致虚拟机网络不通
    在物理机重启后,有时会出现VM网络不通。经过调查,我们分析出根本原因是libvirt, ovs的启动、关闭顺序。
    在正常情况下,libvrit退出时会删除它管理的OpenVSwitch Port以及它创建的对应的Tap虚拟网卡。libvirt启动时会创建需要的Tap网卡,并请求OpenVSwitch 创建对应的Port建立虚拟连接。
    逻辑上,OpenVSwitch Port相当于交换机网口。Tap网卡,相当于PC的网卡。他们之间需要连线网络才能正常通信。
    如果关机时,OpenVSwitch比Libvirt先停止,Libvirt将不能成功删除它管理的OpenVSwitch Port ;开机时,如果OpenVSwitch先启动,它将建试图重建之前存在的port。但因为Libvirt还未启动, OpenVSwitch Port对应的Tap网卡还未创建(即虚拟网口对应的虚拟网卡不存在),OpenVSwitch重建Port最终失败并且Port将被销毁。
    由于Port信息对OpenVSwitch来说是用户配置信息,OpenVSwitch并不会从数据库中清理掉对应的Port记录。所以等到Libvirt启动调用OpenVSwitch创建Port时,OpenVSwitch发现数据库里面已经存在这些Port,所以并未真正触发Port重建,最后造成VM网络不通。
    最终我们通过开、关机顺序调整实现问题修复。
    RabbitMQ长连接
    RabbitMQ是OpenStack使用的一种消息交交互组件。OpenStack在某些时候,会出现无法创建虚拟机的情况。通过日志分析我们发现计算节点没有收到对应的创建请求消息。然后抓包分析进一步发现,TCP数据包被防火墙拦截、丢弃。原来防火墙对TCP会话有数量限制,会定期丢弃长久无数据交互的TCP会话。
    在了解根本原因后,一方面通过定期自动冒烟测试保证网络不空闲,一方面想解决方案。从应用层面上,我们调研到RabbitMQ已经有心跳机制,但要升级。由于升级影响范围太广,最终没有进行。
    接着我们对网络层面进行了调查,发现TCP本身有Keepalive保活机制,同时RabbitMQ代码本身也有TCP保活,但默认不开启。最后我们通过启用RabbitMQ TCP保活机制,设置一个合理的保活间隔解决问题。

上一页:云终端系列报道第七十六期 - 实现虚拟云桌面 下一页:云终端系列报道第七十八期 - 系统稳定背后的黑科技
推荐新闻 Recommended news

帮助中心
6509367