OpenStack 部署运维实战Word下载.docx
《OpenStack 部署运维实战Word下载.docx》由会员分享，可在线阅读，更多相关《OpenStack 部署运维实战Word下载.docx（15页珍藏版）》请在冰点文库上搜索。
∙Telemetry（Ceilometer）提供用量统计服务，通过它可以方便地实现OpenStack计费功能。
∙Orchestration（Heat）整合了OpenStack中的众多组件，类似AWS的CloudFormation，让用户能够通过模板来管理资源。
∙Database（Trove）基于OpenStack构建的database-as-a-service。
网易私有云使用了Nova、Glance、Keystone、Neutron这4个组件。
回页首
网易私有云平台概况
图1.网易私有云架构
网易私有云平台由网易杭州研究院负责研发，主要提供基础设施资源、数据存储处理、应用开发部署、运维管理等功能以满足公司产品测试/上线的需求。
图1展示了网易私有云平台的整体架构。
整个私有云平台可分为三大类服务：
核心基础设施服务（IaaS）、基础平台服务（PaaS）以及运维管理支撑服务，目前一共包括了：
云主机（虚拟机）、云网络、云硬盘、对象存储、对象缓存、关系型数据库、分布式数据库、全文检索、消息队列、视频转码、负载均衡、容器引擎、云计费、云监控、管理平台等15个服务。
网易私有云平台充分利用云计算开源的最新成果，我们基于OpenStack社区的keystone、glance、nova、neutron组件研发部署了云主机和云网络服务。
为了与网易私有云平台其他服务（云硬盘、云监控、云计费等）深度整合以及满足公司产品使用和运维管理的特定需求，我们团队在社区OpenStack版本的基础上独立研发了包括：
云主机资源质量保障（计算、存储、网络QoS）、镜像分块存储、云主机心跳上报、flat-dhcp模式下租户内网隔离等20多个新功能。
同时，我们团队在日常运维OpenStack以及升级社区新版本中，也总结了一些部署、运维规范以及升级经验。
两年多来，网易私有云平台OpenStack团队的研发秉承开源、开放的理念，始终遵循"
来源社区，回馈社区"
的原则。
在免费享受OpenStack社区不断研发新功能以及修复bug的同时，我们团队也积极向社区做自己的贡献，从而帮助OpenStack社区的发展壮大。
两年来，我们团队一共向社区提交新功能开发/bug修复的commits近100个，修复社区bug50多个，这些社区贡献涉及OpenStack的Essex、Folsom、Havana、Icehouse、Juno等版本。
得益于OpenStack的日益稳定成熟，私有云平台目前已经稳定运行了2年多时间，为网易公司多达30个互联网和游戏产品提供服务。
从应用的效果来看，基于OpenStack研发的网易私有云平台已经达到了以下目标：
1.提高了公司基础设施资源利用率，从而降低了硬件成本。
以物理服务器CPU利用率为例，私有云平台将CPU平均利用率从不到10%提升到50%。
2.提高了基础设施资源管理与运维自动化水平，从而降低了运维成本。
借助于Web自助式的资源申请和分配方式以及云平台自动部署服务，系统运维人员减少了50%。
3.提高了基础设施资源使用弹性，从而增强了产品业务波动的适应能力。
利用虚拟化技术将物理基础设施做成虚拟资源池，通过有效的容量规划以及按需使用，私有云平台可以很好适应产品突发业务。
网易OpenStack部署参考方案介绍
在具体的生产环境中，我们为了兼顾性能和可靠性，keystone后端使用Mysql存储用户信息，使用memcache存放token。
为了减少对keystone的访问压力，所有服务（nova，glance，neutron）的keystoneclient均配置使用memcache作为token的缓存。
由于网易私有云需要部署在多个机房之中，每个机房之间在地理位置上自然隔离，这对上层的应用来说是天然的容灾方法。
另外，为了满足私有云的功能和运维需求，网易私有云需要同时支持两种网络模式：
nova-network和neutron。
针对这些需求，我们提出了一个面向企业级的多区域部署方案，如图2所示。
从整体上看，多个区域之间的部署相对独立，但可通过内网实现互通，每个区域中包括了一个完整的OpenStack部署，所以可以使用独立的镜像服务和独立的网络模式，例如区域A使用nova-network，区域B使用neutron，互不影响，另外为了实现用户的单点登录，区域之间共享了keystone，区域的划分依据主要是网络模式和地理位置。
图2.多区域部署方法
和典型OpenStack部署将硬件划分为计算节点和控制节点不同的是，为了充分利用硬件资源，我们努力把部署设计成对称的，即任意一个节点下线对整体服务不会照成影响。
因此我们将硬件分为两类：
计算节点，控制计算节点。
计算节点部署nova-network，nova-compute，nova-api-metadata，nova-api-os-compute。
控制计算节点除了计算节点的服务外还部署了nova-scheduler，nova-novncproxy，nova-consoleauth，glance-api，glance-registry和keystone，如图3所示。
对外提供API的服务有nova-api-os-compute，nova-novncproxy,glance-api，keystone。
这类服务的特点是无状态，可以方便地横向扩展，故此类服务均部署在负载均衡HAProxy之后，并且使用Keepalived做高可用。
为了保证服务质量和便于维护，我们没有使用nova-api，而是分为nova-api-os-compute和nova-api-metadata分别管理。
外部依赖方面，网易私有云部署了高可用RabbitMQ集群和主备MySQL，以及memcache集群。
图3.计算节点，控制计算节点
网络规划方面，网易私有云主要使用nova-network的FlatDHCPManager+multi-host网络模式，并划分了多个Vlan，分别用于虚拟机fixed-ip网络、内网浮动IP网络、外网网络。
运维上使用网易自主研发的运维平台做监控和报警，功能类似Nagios，但是更加强大。
其中较重要的监控报警包括日志监控和进程监控。
日志监控保证服务发生异常时第一时间发现，进程监控保证服务正常运行。
另外网易私有云使用Puppet做自动部署，以及使用StackTach帮助定位bug。
OpenStack各组件配置
OpenStackHavana的配置项成百上千，大部分配置项都是可以使用默认值的，否则光是理解这么多的配置项的含义就足以让运维人员崩溃，尤其是对那些并不熟悉源码的运维人员来说更是如此。
下文将列举若干网易私有云中较关键的配置项，并解释它们如何影响到服务的功能，安全性，以及性能等问题。
Nova关键配置
my_ip=
内网地址
此项是用来生成宿主机上的novametadataapi请求转发iptables规则，如果配置不当，会导致虚拟机内部无法通过169.254.169.254这个IP获取ec2/OpenStackmetadata信息；
生成的iptable规则形如：
-Anova-network-PREROUTING-d169.254.169.254/32-ptcp-mtcp--dport80-jDNAT\
--to-destination${my_ip}:
8775
它另外的用途是虚拟机在resize、coldmigrate等操作时，与目的端宿主机进行数据通信。
该项的默认值为宿主机的外网IP地址，建议改为内网地址以避免潜在的安全风险。
metadata_listen=
此项是nova-api-metadata服务监听的IP地址，可以从上面的iptables规则里面看出它与my_ip的配置项有一定的关联，保持一致是最明智的选择。
novncproxy_base_url=vncserver_proxyclient_address=${private_ip_of_compute_host}
vncserver_listen=${private_ip_of_compute_host}
novncproxy_host=${private_ip_of_host}
我们仅在部分节点上部署novncproxy进程，并把这些进程加入到HAProxy服务中实现novnc代理进程的高可用，多个HAProxy进程使用Keepalived实施HAProxy的高可用，对外只需要暴露Keepalived管理的虚拟IP地址即可：
这种部署方式好处是：
1）实现novnc代理服务的高可用
2）不会暴露云平台相关节点的外网地址
3）易于novnc代理服务的扩容
但也有不足：
1）虚拟机都监听在其所在的计算节点的内网IP地址，一旦虚拟机与宿主机的网络隔离出现问题，会导致所有虚拟机的VNC地址接口暴露出去
2）在线迁移时会遇到问题，因为VNC监听的内网IP在目的端计算节点是不存在的，不过这个问题nova社区已经在解决了，相信很快就会合入J版本。
resume_guests_state_on_host_boot=true
在nova-compute进程启动时，启动应该处于运行状态的虚拟机，应该处于运行状态的意思是nova数据库中的虚拟机记录是运行状态，但在Hypervisor上该虚拟机没有运行，在计算节点重启时，该配置项具有很大的用处，它可以让节点上所有虚拟机都自动运行起来，节省运维人员手工处理的时间。
api_rate_limit=false
不限制API访问频率，打开之后API的并发访问数量会受到限制，可以根据云平台的访问量及API进程的数量和承受能力来判断是否需要打开，如果关闭该选项，则大并发情况下API请求处理时间会比较久。
osapi_max_limit=5000
nova-api-os-computeapi的最大返回数据长度限制，如果设置过短，会导致部分响应数据被截断。
scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ImagePropertiesFilter,JsonFilter,EcuFilter,CoreFilter
nova-scheduler可用的过滤器，Retry是用来跳过已经尝试创建但是失败的计算节点，防止重调度死循环；
AvailabilityZone是过滤那些用户指定的AZ的，防止用户的虚拟机创建到未指定的AZ里面；
Ram是过滤掉内存不足的计算节点；
Core是过滤掉VCPU数量不足的计算节点；
Ecu是我们自己开发的过滤器，配合我们的CPUQoS功能开发的，用来过滤掉ecu数量不足的计算节点；
ImageProperties是过滤掉不符合镜像要求的计算节点，比如QEMU虚拟机所用的镜像不能在LXC计算节点上使用；
Json是匹配自定义的节点选择规则，比如不可以创建到某些AZ，要与那些虚拟机创建到相同AZ等。
其他还有一些过滤器可以根据需求进行选择。
running_deleted_instance_action=reap
nova-compute定时任务发现在数据库中已经删除，但计算节点的Hypervisor中还存在的虚拟机（也即野虚拟机审计操作方式）后的处理动作，建议是选择log或者reap。
log方式需要运维人员根据日志记录找到那些野虚拟机并手工执行后续的动作，这种方式比较保险，防止由于nova服务出现未知异常或者bug时导致用户虚拟机被清理掉等问题，而reap方式则可以节省运维人员的人工介入时间。
until_refresh=5
用户配额与instances表中实际使用量的同步阈值，也即用户的配额被修改多少次后强制同步一次使用量到配额量记录
max_age=86400
用户配额与实际使用量的同步时间间隔，也即距上次配额记录更新多少秒后，再次更新时会自动与实际使用量同步。
众所周知，开源的nova项目目前仍然有很多配额方面的bug没有解决，上面两个配置项可以在很大程度上解决用户配额使用情况与实际使用量不匹配的问题，但也会带来一定的数据库性能开销，需要根据实际部署情况进行合理设置。
###计算节点资源预留###
vcpu_pin_set=4-$
虚拟机vCPU的绑定范围，可以防止虚拟机争抢宿主机进程的CPU资源，建议值是预留前几个物理CPU，把后面的所有CPU分配给虚拟机使用，可以配合cgroup或者内核启动参数来实现宿主机进程不占用虚拟机使用的那些CPU资源。
cpu_allocation_ratio=4.0
物理CPU超售比例，默认是16倍，超线程也算作一个物理CPU，需要根据具体负载和物理CPU能力进行综合判断后确定具体的配置。
ram_allocation_ratio=1.0
内存分配超售比例，默认是1.5倍，生产环境不建议开启超售。
reserved_host_memory_mb=4096
内存预留量，这部分内存不能被虚拟机使用
reserved_host_disk_mb=10240
磁盘预留空间，这部分空间不能被虚拟机使用
service_down_time=120
服务下线时间阈值，如果一个节点上的nova服务超过这个时间没有上报心跳到数据库，api服务会认为该服务已经下线，如果配置过短或过长，都会导致误判。
rpc_response_timeout=300
RPC调用超时时间，由于Python的单进程不能真正的并发，所以RPC请求可能不能及时响应，尤其是目标节点在执行耗时较长的定时任务时，所以需要综合考虑超时时间和等待容忍时间。
multi_host=True
是否开启nova-network的多节点模式，如果需要多节点部署，则该项需要设置为True。
Keystone
配置项较少，主要是要权衡配置什么样的后端驱动，来存储token，一般是SQL数据库，也可以是memcache。
sql可以持久化存储，而memcache则速度更快，尤其是当用户要更新密码的时候，需要删除所有过期的token，这种情况下SQL的速度与memcache相差很大很大。
glance
包括两个部分，glance-api和glance-registry，：
workers=2
glance-api处理请求的子进程数量，如果配置成0，则只有一个主进程，相应的配置成2，则有一个主进程加2个子进程来并发处理请求。
建议根据进程所在的物理节点计算能力和云平台请求量来综合确定。
api_limit_max=1000
与nova中的配置osapi_max_limit意义相同
limit_param_default=1000
一个响应中最大返回项数，可以在请求参数中指定，默认是25，如果设置过短，可能导致响应数据被截断。
OpenStack底层依赖软件版本、配置以及性能调优
虚拟化技术选型
在私有云平台的体系架构中，OpenStack依赖一些底层软件，如虚拟化软件，虚拟化管理软件和Linux内核。
这些软件的稳定性以及性能关系着整个云平台的稳定性和性能。
因此，这些软件的版本选择和配置调优也是网易私有云开发中的一个重要因素。
在网易私有云平台中，我们选用的是Linux内核兼容最好的KVM虚拟化技术。
相对于Xen虚拟化技术，KVM虚拟化技术与Linux内核联系更为紧密，更容易维护。
选择KVM虚拟化技术后，虚拟化管理驱动采用了OpenStack社区为KVM配置的计算驱动libvirt，这也是一套使用非常广泛，社区活跃度很高的一套开源虚拟化管理软件，支持KVM在内的各种虚拟化管理。
另一方面，网易采用开源的Debian作为自己的宿主机内核，源使用的是Debian的wheezy稳定分支，KVM和libvirt采用的也是Debian社区wheezy源里面的包版本：
qemu-kvm1.1.2+dfsg-6+deb7u3
libvirt-bin0.9.12
内核选型
在内核的选型方面，我们主要考虑如下两方面的因素：
∙稳定性：
在开发私有云平台的一开始，稳定性就是网易私有云开发的一大基本原则。
我们采用DebianLinux版本，相对来说，Debian的原生内核无疑更为稳定。
这也是我们最开始的一个选择。
∙功能需求：
在网易的定制开发中，为了保证虚拟机的服务性能，我们开发了CPUQoS技术和磁盘QoS，它依赖底层的CPU和blkiocgroup支持。
因此，我们需要打开内核中的cgroup配置选项。
另一方面，网易私有云综合各方面考虑，将支持LXC这种容器级别的虚拟化，除了cgroup外，LXC还依赖Linux内核中的namespace特性。
综合上述因素的考虑，我们选择了Debian社区的Linux3.10.40内核源代码，并且打开了CPU/mem/blkio等cgroup配置选项以及usernamespace等namespace选项，自己编译了一个适配网易私有云的Linux内核。
从使用情况来看，选择上述版本的OpenStack底层依赖软件后，网易私有云运行还比较稳定，我们后续还会适时的对这些软件进行更新。
配置优化
在网易私有云的稳定性得到了保障之后，我们开始了性能方面的调优工作。
这一方面，我们参考了IBM公司的一些优秀实践，在CPU、内存、I/O等方面做了一些配置方面的优化。
整体而言，网易私有云在注重稳定性的基础上，也会积极借鉴业界优秀实践来优化私有云平台的整体性能。
CPU配置优化
为了保障云主机的计算能力，网易私有云开发了CPUQoS技术，具体来说就是采用cfs的时间片均匀调度，外加processpinning的绑定技术。
参考IBM的分析，我们了解到了processpinning技术的优缺点，并且经过测试也验证了不同绑定方式的云主机间的性能存在较大的差异。
比如，2个VCPU分别绑定到不同numa节点的非超线程核上和分配到一对相邻的超线程核上的性能相差有30%~40%（通过SPECCPU2006工具测试）。
另一方面，CPU0由于处理中断请求，本身负荷就较重，不宜再用于云主机。
因此，综合上面的因素考虑以及多轮的测试验证，我们最终决定将0-3号CPU预留出来，然后让云主机在剩余的CPU资源中由宿主机内核去调度。
最终的CPU配置如下所示（libvirtxml配置）：
<
vcpuplacement='
static'
cpuset='
4-23'
>
1<
/vcpu>
cputune>
<
shares>
1024<
/shares>
period>
100000<
/period>
quota>
57499<
/quota>
/cputune>
内存配置优化
内存配置方面，网易私有云的实践是关闭KVM内存共享，打开透明大页：
echo0>
/sys/kernel/mm/ksm/pages_shared
echo0>
/sys/kernel/mm/ksm/pages_sharing
echoalways>
/sys/kernel/mm/transparent_hugepage/enabled
echonever>
/sys/kernel/mm/transparent_hugepage/defrag
/sys/kernel/mm/transparent_hugepage/khugepaged/defrag
经过SPECCPU2006测试，这些配置对云主机CPU性能大概有7%左右的提升。
I/O配置优化
1）磁盘I/O的配置优化主要包含如下方面：
KVM的diskcache方式：
借鉴IBM的分析，网易私有云采用none这种cache方式。
diskioscheduler：
目前网易私有云的宿主机磁盘调度策略选用的是cfq。
在实际使用过程中，我们发现cfq的调度策略，对那些地低配置磁盘很容易出现I/O调度队列过长，utils100%的问题。
后续网易私有云也会借鉴IBM的实践，对cfq进行参数调优，以
升级会员 