苏宁张小斌：OpenStack实践基础知识（四）

OpenStack到目前还未能提供热升级，升级难题如何解决

升级比较麻烦，社区一般都支持N->N+1的升级，但考虑到比如操作系统版本变化、库文件变化（会很多）、数据库变化，还有自行开发的如运维自动化、监控、安全加固、工作量会比较多。

特别如果是生产环境，那些运行的虚拟机不是想停就停的，而且如果比如Apache-JBoss-MySQL，分布到多个节点，IP能不能变化，那升级顾及的东西很多。

然而相邻版本升级的情况会非常少。绝大部分需要升级的生产环境是中间差了好几个版本（生产环境由于增加许多定制、考虑到生产环境的稳定性、再加上令人望难生畏的升级，事实上升级是个很艰难的决定）。通常建议旧有环境维持，新业务搭建于新版本的环境之上。

Devstack和RDO相比如何?如果用在生产环境下哪套比较好

对于生产环境，如果需要现成好用的，可以考虑RDO、Mirantis Fuel（这个对于了解OpenStack的功能，非常全面，而且是可视图形化界面，说明、文档等也非常全面）；这些工具搭建基本环境，包括生产环境都没有问题。万一遇到问题，只需要参照网上/社区，对OpenStack代码/配置进行调整即可，这些已经是通用的OpenStack问题调试，脱离了RDO/Mirantis的范围；而这些工具里面包装的，也是社区里的OpenStack Icehouse、Juno版本。

DevStack一般是初学/开发使用较多，适合单机环境，我觉得不适合生产环境，里面封装太厉害，需要修改时改不动；RDO可控性稍强，可以搭建多节点环境，里面而且带有基于Nagios的监控。正式环境，没有监控，就和夜间开车没有开灯一样容易翻车；但RDO如果考虑到运维自动化，虽然里面也是封装Puppet的，但也比较复杂（我们环境最新的Puppet代码，光文件就有3187个）。  

什么样的硬件去适配OpenStack

硬件配置可参考《OpenStack企业云计算架构与实践》第8章，但是取决于规模大小，在内存/CPU上可以调整，比如笔者常用的有CPU: 2*6 core，hyperthread，128/256GB 内存；控制服务和计算服务对磁盘空间要求都不大；也可以这样计算：一个虚机50GB，每个节点20个虚拟机，就可以算出存储空间需求。  

块存储也可以同样计算；考虑到虚拟机不一定占满整个空间，可以乘以0.75。  

计算节点只运行虚拟机，可以有单独的存储服务器组成共享存储（支持热迁移，Host evacuate等）、块存储等。但如果服务器是通用的（如都是128GB内存，2*6core，hyperthread, 几十TB的硬盘），也可以把Nova-compute,、Cinder-volume部署于一起。  

Mirantis公司的官网上有硬件计算器（非常cool），只要在谷歌上搜索Mirantis OpenStack hardware calcuator，你就会发现这个工具的连接。

OpenStack Flat模式下如何组织内网broadcast storm

Flat模式下阻止广播的手段不太多，这种模式就是用于小型的环境中，想隔离就要上升到三层了。可以利用二层防火墙适当减少些广播流量，比如ebtables，对虚拟机的出口流量过滤。 

虚拟资源的调度和迁移以及虚拟化环境下的安全 

在云项目选型中，很多用户首要考虑的是虚拟资源的调度、迁移，以及虚拟化环境下的安全。

调度需求主要是对宿主机负载情况和资源进行探测，动态调整各宿主机的负载，保障客户体验。调度包括虚拟机调度和块存储调度，Nova里提供了很多手段，包括主机的划分，可用手段包括可用域、主机集合、medadata等。一方面Nova会将自己节点的资源上报，另外，结合反亲和策略、differenthost等，可以构造自己的调度。常见的有不同类型虚拟机调度到不同资源池（硬件可能不同）；集群调度不同主机等。

调度还有Strip：即根据虚拟机需要的计算资源平均到各个物理机; pack：类似于省电模式，将虚拟机尽可能集中到少数服务器上去；还可以根据剩余的计算资源来调度；所以管理程序需要综合运用这些手段，来满足实际需要。

迁移需求主要为在上述动态调度，或宿主机故障的情况下虚拟机迁移。迁移要结合监控，可通过（live）migration、（host）evacuate来实现手工/自动迁移，但自动化判断逻辑还的自己实现；另外live-migration, evacuate等需要共享存储支持。但NFS不推荐生产环境，节点数上升到10台以上性能就不好了，而且有单节点失效危险；没有共享存储带宽也要考虑；另外，迁移有的会freeze虚机，对业务影响也需要评估。

虚拟化环境下安全需求主要为不同业务属性虚拟资源的VLAN动态管理（当然需要考虑VLAN有4096的限制），各VLAN的IP资源分配、默认网关、防入侵等。安全还包括主机安全、网络攻击、入侵检测、通过KVM的攻击，这些都由一些开源工具+自行开发一些内容来解决；KVM安全HP/Symantec讲得很多。还有内部消息的安全等，这个OpenStack自己可以解决。

搭建OpenStack环境建议使用哪个版本，使用哪种网络模式

目前最新的是K版本，一般新版本在社区发布（每年4月和10月）后等两三个月，此时该版本的很多问题都已经解决，基本就可以直接拿来用了；另外，Juno、Icehouse、 Havanna版本也足够稳定，可以直接拿来用。笔者曾经搭建的Havanna版本，除了Dashboard里稍微改动之外，其他服务代码并未动一行，运行半年也很稳定（不可思议？想想OpenStack已经发布了10+个版本了，另外有无数的全世界最杰出的工程师在这个社区里，有自动化测试在持续运行，虽然无法模拟生产环境），偶尔有ovs agent丢失流表，最简单办法是重启就好了。

Neutron-GRE/VXLAN还在演进，建议新环境还是观察跟踪即可。VLAN对于绝大多数企业很适合，因为VLAN本身企业就在用，而且非常广泛，改动成本最低，配置也相对方便：Neutron里配置queue和数据库IP地址；ovs agent里配置VLAN模式，也可以配置VLAN范围（默认配置2～4095也可以）；网上博客里有大量资料可以参考。  

OpenStack网络确实让人眼花缭乱，早期都存在于Nova项目里，网络部分叫Nova-network，非常稳定，支持multi-host，早期的OpenStack环境使用非常广泛。在Neutron发展起来之后，往往传言Nova-network要被废弃，事实上直到现在也还是存在。Neutron里支持Flat、VLAN、GRE、VXLAN等。但是笔者个人的观点是优先选择适合自己的，且好把控的就好。如果扁平网络足够了，用Nova-network也可以的，说是Nova-network要退役，但实际上一直存在，许多企业（包括一些早期大型环境）还在用，而且代码量并不大；许多企业里Neutron-vlan也足够了，因为事实上没有太多企业会超出4096的范围。 

新的许多大型公有云使用VXLAN，基于万兆网。这目前是大型公有云使用最多的一种网络模式。（责编/周建丁）

作者简介：张小斌，苏宁 OpenStack 研发中心负责人，分别于西安交通大学和中科院计算所完成本科和硕士研究生学业，拥有 18 年计算机软件设计、开发和管理经验。目前专注于云计算的研究探索，关注社区，注重 OpenStack 在企业的实践和落地。在企业级计算、网络和存储的整体解决方案、高可用性、安全以及应用管理自动化和弹性等领域都有所拓展。 

张小斌的更多OpenStack实践观点，可以参阅其著作《OpenStack企业云平台架构与实践》，电子工业出版社出版。

该书结合作者亲身经历的各类OpenStack的咨询、规划和实施经验，以循序渐进的方式，从理论和工程角度，讲述了如何将OpenStack（本质上只是一堆相关的进程和服务）变成企业可靠的、托管企业各类生产环境的云平台的方方面面，让OpenStack真正变成我们身边默默无闻但又实实在在的环境的一分子。

书中分别介绍了OpenStack与云，OpenStack社区，OpenStack与AWS、VMware、虚拟化管理工具，虚拟机管理程序与典型应用，OpenStack架构与组件，OpenStack部分组件安装示例，系统定制技术，OpenStack部署，第三方工具搭建OpenStack运行环境，九州云Animbus融合架构一体机解决方案等内容。

【预告】首届中国人工智能大会（CCAI 2015）将于7月26-27日在北京友谊宾馆召开。机器学习与模式识别、大数据的机遇与挑战、人工智能与认知科学、智能机器人四个主题专家云集。人工智能产品库将同步上线，预约咨询：QQ：1192936057。欢迎关注。