OpenStack 部署运维实战

时间 2019-11-20

标签 openstack 部署实战繁體版

原文原文链接

OpenStack 简介

OpenStack 是一个开源的 IaaS 实现，它由一些相互关联的子项目组成，主要包括计算、存储、网络。因为以 Apache 协议发布，自 2010 年项目成立以来，超过 200 个公司加入了 OpenStack 项目，其中包括 AT&T、AMD、Cisco、Dell、IBM、Intel、Red Hat 等。目前参与 OpenStack 项目的开发人员有 17,000+，来自 139 个国家，这一数字还在不断增加中。html

OpenStack 兼容一部分 AWS 接口，同时为了提供更强大的功能，也提供 OpenStack 风格的接口（RESTFul API）。和其余开源 IaaS 相比，架构上松耦合、高可扩展、分布式、纯 Python 实现，以及友好活跃的社区使其大受欢迎，每半年一次的开发峰会也吸引了来自全世界的开发者、供应商和客户。linux

OpenStack 的主要子项目有：ios

Compute（Nova）提供计算虚拟化服务，是 OpenStack 的核心，负责管理和建立虚拟机。它被设计成方便扩展，支持多种虚拟化技术，而且能够部署在标准硬件上。
Object Storage（Swift）提供对象存储服务，是一个分布式，可扩展，多副本的存储系统。
Block Storage（Cinder），提供块存储服务，为 OpenStack 的虚拟机提供持久的块级存储设备。支持多种存储后端，包括 Ceph，EMC 等。
Networking（Neutron）提供网络虚拟化服务，是一个可拔插，可扩展，API 驱动的服务。
Dashboard 提供了一个图形控制台服务，让用户方便地访问，使用和维护 OpenStack 中的资源。
Image（glance）提供镜像服务，它旨在发现，注册和交付虚拟机磁盘和镜像。支持多种后端。
Telemetry（Ceilometer）提供用量统计服务，经过它能够方便地实现 OpenStack 计费功能。
Orchestration（Heat）整合了 OpenStack 中的众多组件，相似 AWS 的 CloudFormation，让用户可以经过模板来管理资源。
Database（Trove）基于 OpenStack 构建的 database-as-a-service。

网易私有云使用了 Nova、Glance、Keystone、Neutron 这 4 个组件。sql

网易私有云平台概况

图 1.网易私有云架构

网易私有云平台由网易杭州研究院负责研发，主要提供基础设施资源、数据存储处理、应用开发部署、运维管理等功能以知足公司产品测试/上线的需求。数据库

图 1 展现了网易私有云平台的总体架构。整个私有云平台可分为三大类服务：核心基础设施服务（IaaS）、基础平台服务（PaaS）以及运维管理支撑服务，目前一共包括了：云主机（虚拟机）、云网络、云硬盘、对象存储、对象缓存、关系型数据库、分布式数据库、全文检索、消息队列、视频转码、负载均衡、容器引擎、云计费、云监控、管理平台等 15 个服务。网易私有云平台充分利用云计算开源的最新成果，咱们基于 OpenStack 社区的 keystone、glance、nova、neutron 组件研发部署了云主机和云网络服务。后端

为了与网易私有云平台其余服务（云硬盘、云监控、云计费等）深度整合以及知足公司产品使用和运维管理的特定需求，咱们团队在社区 OpenStack 版本的基础上独立研发了包括：云主机资源质量保障（计算、存储、网络 QoS）、镜像分块存储、云主机心跳上报、flat-dhcp 模式下租户内网隔离等 20 多个新功能。同时，咱们团队在平常运维 OpenStack 以及升级社区新版本中，也总结了一些部署、运维规范以及升级经验。两年多来，网易私有云平台 OpenStack 团队的研发秉承开源、开放的理念，始终遵循"来源社区，回馈社区"的原则。在免费享受 OpenStack 社区不断研发新功能以及修复 bug 的同时，咱们团队也积极向社区作本身的贡献，从而帮助 OpenStack 社区的发展壮大。两年来，咱们团队一共向社区提交新功能开发/bug 修复的 commits 近 100 个，修复社区 bug 50 多个，这些社区贡献涉及 OpenStack 的 Essex、Folsom、Havana、Icehouse、Juno 等版本。api

得益于 OpenStack 的日益稳定成熟，私有云平台目前已经稳定运行了 2 年多时间，为网易公司多达 30 个互联网和游戏产品提供服务。从应用的效果来看，基于 OpenStack 研发的网易私有云平台已经达到了如下目标：缓存

提升了公司基础设施资源利用率，从而下降了硬件成本。以物理服务器 CPU 利用率为例，私有云平台将 CPU 平均利用率从不到 10% 提高到 50%。
提升了基础设施资源管理与运维自动化水平，从而下降了运维成本。借助于 Web 自助式的资源申请和分配方式以及云平台自动部署服务，系统运维人员减小了 50%。
提升了基础设施资源使用弹性，从而加强了产品业务波动的适应能力。利用虚拟化技术将物理基础设施作成虚拟资源池，经过有效的容量规划以及按需使用，私有云平台能够很好适应产品突发业务。

网易 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 各组件配置

OpenStack Havana 的配置项成百上千，大部分配置项都是可使用默认值的，不然光是理解这么多的配置项的含义就足以让运维人员崩溃，尤为是对那些并不熟悉源码的运维人员来讲更是如此。下文将列举若干网易私有云中较关键的配置项，并解释它们如何影响到服务的功能，安全性，以及性能等问题。

Nova 关键配置

my_ip = 内网地址

此项是用来生成宿主机上的 nova metadata api 请求转发 iptables 规则，若是配置不当，会致使虚拟机内部没法经过 169.254.169.254 这个 IP 获取 ec2/OpenStack metadata 信息；生成的 iptable 规则形如：

 
        -A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT \ 
       
        --to-destination ${my_ip}:8775

它另外的用途是虚拟机在 resize、cold migrate 等操做时，与目的端宿主机进行数据通讯。该项的默认值为宿主机的外网 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-compute api 的最大返回数据长度限制，若是设置太短，会致使部分响应数据被截断。

scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, ComputeFilter, ImagePropertiesFilter, JsonFilter, EcuFilter, CoreFilter

nova-scheduler 可用的过滤器，Retry 是用来跳过已经尝试建立可是失败的计算节点，防止重调度死循环；AvailabilityZone 是过滤那些用户指定的 AZ 的，防止用户的虚拟机建立到未指定的 AZ 里面；Ram 是过滤掉内存不足的计算节点；Core 是过滤掉 VCPU 数量不足的计算节点；Ecu 是咱们本身开发的过滤器，配合咱们的 CPU QoS 功能开发的，用来过滤掉 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 源里面的包版本：

1 2	`qemu-kvm 1.1.2+dfsg-6+deb7u3` `libvirt-bin 0.9.12`

内核选型

在内核的选型方面，咱们主要考虑以下两方面的因素：

稳定性：在开发私有云平台的一开始，稳定性就是网易私有云开发的一大基本原则。咱们采用 Debian Linux 版本，相对来讲，Debian 的原生内核无疑更为稳定。这也是咱们最开始的一个选择。
功能需求：在网易的定制开发中，为了保证虚拟机的服务性能，咱们开发了 CPU QoS 技术和磁盘 QoS，它依赖底层的 CPU 和 blkio cgroup 支持。所以，咱们须要打开内核中的 cgroup 配置选项。另外一方面，网易私有云综合各方面考虑，将支持 LXC 这种容器级别的虚拟化，除了 cgroup 外，LXC 还依赖 Linux 内核中的 namespace 特性。

综合上述因素的考虑，咱们选择了 Debian 社区的 Linux 3.10.40 内核源代码，而且打开了 CPU/mem/blkio 等 cgroup 配置选项以及 user namespace 等 namespace 选项，本身编译了一个适配网易私有云的 Linux 内核。从使用状况来看，选择上述版本的 OpenStack 底层依赖软件后，网易私有云运行还比较稳定，咱们后续还会适时的对这些软件进行更新。

配置优化

在网易私有云的稳定性获得了保障以后，咱们开始了性能方面的调优工做。这一方面，咱们参考了 IBM 公司的一些优秀实践，在 CPU、内存、I/O 等方面作了一些配置方面的优化。总体而言，网易私有云在注重稳定性的基础上，也会积极借鉴业界优秀实践来优化私有云平台的总体性能。

CPU 配置优化

为了保障云主机的计算能力，网易私有云开发了 CPU QoS 技术，具体来讲就是采用 cfs 的时间片均匀调度，外加 process pinning 的绑定技术。

参考 IBM 的分析，咱们了解到了 process pinning 技术的优缺点，而且通过测试也验证了不一样绑定方式的云主机间的性能存在较大的差别。好比，2 个 VCPU 分别绑定到不一样 numa 节点的非超线程核上和分配到一对相邻的超线程核上的性能相差有 30%~40%(经过 SPEC CPU2006 工具测试)。另外一方面，CPU0 因为处理中断请求，自己负荷就较重，不宜再用于云主机。所以，综合上面的因素考虑以及多轮的测试验证，咱们最终决定将 0-3 号 CPU 预留出来，而后让云主机在剩余的 CPU 资源中由宿主机内核去调度。最终的 CPU 配置以下所示（libvirt xml 配置）：

内存配置优化

内存配置方面，网易私有云的实践是关闭 KVM 内存共享，打开透明大页：

 
          echo 0 > /sys/kernel/mm/ksm/pages_shared 
         
          echo 0 > /sys/kernel/mm/ksm/pages_sharing 
         
          echo always > /sys/kernel/mm/transparent_hugepage/enabled 
         
          echo never > /sys/kernel/mm/transparent_hugepage/defrag 
         
          echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

通过 SPEC CPU2006 测试，这些配置对云主机 CPU 性能大概有 7%左右的提高。

I/O 配置优化

1）磁盘 I/O 的配置优化主要包含以下方面：

KVM 的 disk cache 方式：借鉴 IBM 的分析，网易私有云采用 none 这种 cache 方式。

disk io scheduler：目前网易私有云的宿主机磁盘调度策略选用的是 cfq。在实际使用过程当中，咱们发现 cfq 的调度策略，对那些地低配置磁盘很容易出现 I/O 调度队列过长，utils 100% 的问题。后续网易私有云也会借鉴 IBM 的实践，对 cfq 进行参数调优，以及测试 deadline 调度策略。

磁盘 I/O QoS：面对日渐突出的磁盘 I/O 资源紧缺问题，网易私有云开发了磁盘 I/O QoS，主要是基于 blkio cgroup 来设置其 throttle 参数来实现。因为 libvirt-0.9.12 版本是在 QEMU 中限制磁盘 I/O，而且存在波动问题，因此咱们的实现是经过 Nova 执行命令方式写入到 cgroup 中。同时咱们也开发并向 libvirt 社区提交了 blkiotune 的 throttle 接口设置 patch（已在 libvirt-1.2.2 版本中合入）来完全解决这个问题。

2）网络 I/O 的配置优化

咱们主要是开启了 vhost_net 模式，来减小网络延时和增长吞吐量。

运维经验

使用经验

开源软件 bug 在所不免，可是新版本比旧版本会好用不少，尤为是对于 OpenStack 这种正在迅速成长壮大的开源软件来讲更是如此，这一点在咱们使用过 Essex、Folsom 和 Havana 版本后深有体会，因此建议各类 OpenStack 用户能及时的跟进社区版本，与社区保持同步。
不要轻易的对社区版本进行各种所谓的功能性能方面的"优化"，尤为是在没有与社区专家交换意见以前，千万不要轻易下手，不然此类"优化"极有可能演变成故障点或者性能瓶颈点，最终可能致使没法与社区同步，毕竟一个公司或团队（尤为是小公司、小团队）的能力和知识储备，是很难与社区成百上千的各种专家相提并论的。
多参考各种大型公司分享的部署架构方案，尽可能不要本身闭门造车，尤为是对于开源软件来讲，各种公司、团队的使用场景千差万别，各类周边组件也是应有尽有，多参考业界实践是最好的方式。
一些细节实现可能有不少途径，但每种方式都有优缺点，须要通过充分的论证、分析、测试验证后，才能考虑部署到生产环境使用。
全部的部署方案、功能设计都要考虑到平滑升级问题，即便你获得的信息是升级时能够停服，仍然要尽可能避免这种状况，由于停服的影响范围很难界定。

运维准则

OpenStack 也是一个后端系统服务，全部系统运维相关的基本准则都适用，这里简单的提几点实际运维过程当中根据遇到的问题总结的一些经验：

配置项默认值与实际环境不匹配可能致使各类问题，尤为是网络相关配置与硬件有很强的关联性，生产环境和开发环境硬件异构，致使部分默认值在生产环境不适用。应对准则：每一个版本都必须在与线上硬件相同的环境测试过才能上线。
作好容量规划，已分配的配额量要小于云平台总容量，不然会出现各类问题，致使运维开发耗费不少没必要要的精力去定位分析问题。
配置项过多容易出错，须要与开发人员一块儿仔细核对，上线时首先要经过 puppet 的 noop 功能验证改动是否正确后，才能真正上线。
网络规划要提早作好，如固定 IP、浮动 IP、VLAN 数量等，网络扩容难度和风险都比较大，因此提早规划好是最保险的，一个原则是大比小好，多比少好。
网络隔离要作好，不然用户网络安全没办法保证。
信息安全问题要重视，这个是老生常谈的问题了，每一个平台都有相同问题，但仍是要重视再重视，一旦出现安全漏洞，全部虚拟机都面临严重威胁。