OpenStack 部署運(yùn)維實(shí)戰(zhàn)

來(lái)源：塔塔 更新時(shí)間：2014-12-23

更多

OpenStack 簡(jiǎn)介

OpenStack 是一個(gè)開(kāi)源的 IaaS 實(shí)現(xiàn)，它由一些相互關(guān)聯(lián)的子項(xiàng)目組成，主要包括計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)。由于以 Apache 協(xié)議發(fā)布，自 2010 年項(xiàng)目成立以來(lái)，超過(guò) 200 個(gè)公司加入了 OpenStack 項(xiàng)目，其中包括 AT&T、AMD、Cisco、Dell、IBM、Intel、Red Hat 等。目前參與 OpenStack 項(xiàng)目的開(kāi)發(fā)人員有 17,000+，來(lái)自 139 個(gè)國(guó)家，這一數(shù)字還在不斷增長(zhǎng)中。

OpenStack 兼容一部分 AWS 接口，同時(shí)為了提供更強(qiáng)大的功能，也提供 OpenStack 風(fēng)格的接口（RESTFul API）。和其他開(kāi)源 IaaS 相比，架構(gòu)上松耦合、高可擴(kuò)展、分布式、純 Python 實(shí)現(xiàn)，以及友好活躍的社區(qū)使其大受歡迎，每半年一次的開(kāi)發(fā)峰會(huì)也吸引了來(lái)自全世界的開(kāi)發(fā)者、供應(yīng)商和客戶(hù)。

OpenStack 的主要子項(xiàng)目有：

• Compute（Nova）提供計(jì)算虛擬化服務(wù)，是 OpenStack 的核心，負(fù)責(zé)管理和創(chuàng)建虛擬機(jī)。它被設(shè)計(jì)成方便擴(kuò)展，支持多種虛擬化技術(shù)，并且可以部署在標(biāo)準(zhǔn)硬件上。
• Object Storage（Swift）提供對(duì)象存儲(chǔ)服務(wù)，是一個(gè)分布式，可擴(kuò)展，多副本的存儲(chǔ)系統(tǒng)。
• Block Storage（Cinder），提供塊存儲(chǔ)服務(wù)，為 OpenStack 的虛擬機(jī)提供持久的塊級(jí)存儲(chǔ)設(shè)備。支持多種存儲(chǔ)后端，包括 Ceph，EMC 等。
• Networking（Neutron）提供網(wǎng)絡(luò)虛擬化服務(wù)，是一個(gè)可拔插，可擴(kuò)展，API 驅(qū)動(dòng)的服務(wù)。
• Dashboard 提供了一個(gè)圖形控制臺(tái)服務(wù)，讓用戶(hù)方便地訪問(wèn)，使用和維護(hù) OpenStack 中的資源。
• Image（glance）提供鏡像服務(wù)，它旨在發(fā)現(xiàn)，注冊(cè)和交付虛擬機(jī)磁盤(pán)和鏡像。支持多種后端。
• Telemetry（Ceilometer）提供用量統(tǒng)計(jì)服務(wù)，通過(guò)它可以方便地實(shí)現(xiàn) OpenStack 計(jì)費(fèi)功能。
• Orchestration（Heat）整合了 OpenStack 中的眾多組件，類(lèi)似 AWS 的 CloudFormation，讓用戶(hù)能夠通過(guò)模板來(lái)管理資源。
• Database（Trove）基于 OpenStack 構(gòu)建的 database-as-a-service。

網(wǎng)易私有云使用了 Nova、Glance、Keystone、Neutron 這 4 個(gè)組件。

網(wǎng)易私有云平臺(tái)概況

圖 1.網(wǎng)易私有云架構(gòu)

網(wǎng)易私有云平臺(tái)由網(wǎng)易杭州研究院負(fù)責(zé)研發(fā)，主要提供基礎(chǔ)設(shè)施資源、數(shù)據(jù)存儲(chǔ)處理、應(yīng)用開(kāi)發(fā)部署、運(yùn)維管理等功能以滿足公司產(chǎn)品測(cè)試/上線的需求。

圖 1 展示了網(wǎng)易私有云平臺(tái)的整體架構(gòu)。整個(gè)私有云平臺(tái)可分為三大類(lèi)服務(wù)：核心基礎(chǔ)設(shè)施服務(wù)（IaaS）、基礎(chǔ)平臺(tái)服務(wù)（PaaS）以及運(yùn)維管理支撐服務(wù)，目前一共包括了：云主機(jī)（虛擬機(jī)）、云網(wǎng)絡(luò)、云硬盤(pán)、對(duì)象存儲(chǔ)、對(duì)象緩存、關(guān)系型數(shù)據(jù)庫(kù)、分布式數(shù)據(jù)庫(kù)、全文檢索、消息隊(duì)列、視頻轉(zhuǎn)碼、負(fù)載均衡、容器引擎、云計(jì)費(fèi)、云監(jiān)控、管理平臺(tái)等 15 個(gè)服務(wù)。網(wǎng)易私有云平臺(tái)充分利用云計(jì)算開(kāi)源的最新成果，我們基于 OpenStack 社區(qū)的 keystone、glance、nova、neutron 組件研發(fā)部署了云主機(jī)和云網(wǎng)絡(luò)服務(wù)。

為了與網(wǎng)易私有云平臺(tái)其他服務(wù)（云硬盤(pán)、云監(jiān)控、云計(jì)費(fèi)等）深度整合以及滿足公司產(chǎn)品使用和運(yùn)維管理的特定需求，我們團(tuán)隊(duì)在社區(qū) OpenStack 版本的基礎(chǔ)上獨(dú)立研發(fā)了包括：云主機(jī)資源質(zhì)量保障（計(jì)算、存儲(chǔ)、網(wǎng)絡(luò) QoS）、鏡像分塊存儲(chǔ)、云主機(jī)心跳上報(bào)、flat-dhcp 模式下租戶(hù)內(nèi)網(wǎng)隔離等 20 多個(gè)新功能。同時(shí)，我們團(tuán)隊(duì)在日常運(yùn)維 OpenStack 以及升級(jí)社區(qū)新版本中，也總結(jié)了一些部署、運(yùn)維規(guī)范以及升級(jí)經(jīng)驗(yàn)。兩年多來(lái)，網(wǎng)易私有云平臺(tái) OpenStack 團(tuán)隊(duì)的研發(fā)秉承開(kāi)源、開(kāi)放的理念，始終遵循"來(lái)源社區(qū)，回饋社區(qū)"的原則。在免費(fèi)享受 OpenStack 社區(qū)不斷研發(fā)新功能以及修復(fù) bug 的同時(shí)，我們團(tuán)隊(duì)也積極向社區(qū)做自己的貢獻(xiàn)，從而幫助 OpenStack 社區(qū)的發(fā)展壯大。兩年來(lái)，我們團(tuán)隊(duì)一共向社區(qū)提交新功能開(kāi)發(fā)/bug 修復(fù)的 commits 近 100 個(gè)，修復(fù)社區(qū) bug 50 多個(gè)，這些社區(qū)貢獻(xiàn)涉及 OpenStack 的 Essex、Folsom、Havana、Icehouse、Juno 等版本。

得益于 OpenStack 的日益穩(wěn)定成熟，私有云平臺(tái)目前已經(jīng)穩(wěn)定運(yùn)行了 2 年多時(shí)間，為網(wǎng)易公司多達(dá) 30 個(gè)互聯(lián)網(wǎng)和游戲產(chǎn)品提供服務(wù)。從應(yīng)用的效果來(lái)看，基于 OpenStack 研發(fā)的網(wǎng)易私有云平臺(tái)已經(jīng)達(dá)到了以下目標(biāo)：

1. 提高了公司基礎(chǔ)設(shè)施資源利用率，從而降低了硬件成本。以物理服務(wù)器 CPU 利用率為例，私有云平臺(tái)將 CPU 平均利用率從不到 10% 提升到 50%。
2. 提高了基礎(chǔ)設(shè)施資源管理與運(yùn)維自動(dòng)化水平，從而降低了運(yùn)維成本。借助于 Web 自助式的資源申請(qǐng)和分配方式以及云平臺(tái)自動(dòng)部署服務(wù)，系統(tǒng)運(yùn)維人員減少了 50%。
3. 提高了基礎(chǔ)設(shè)施資源使用彈性，從而增強(qiáng)了產(chǎn)品業(yè)務(wù)波動(dòng)的適應(yīng)能力。利用虛擬化技術(shù)將物理基礎(chǔ)設(shè)施做成虛擬資源池，通過(guò)有效的容量規(guī)劃以及按需使用，私有云平臺(tái)可以很好適應(yīng)產(chǎn)品突發(fā)業(yè)務(wù)。

回頁(yè)首

網(wǎng)易 OpenStack 部署參考方案介紹

在具體的生產(chǎn)環(huán)境中，我們?yōu)榱思骖櫺阅芎涂煽啃裕琸eystone 后端使用 Mysql 存儲(chǔ)用戶(hù)信息，使用 memcache 存放 token。為了減少對(duì) keystone 的訪問(wèn)壓力，所有服務(wù)（nova，glance，neutron）的 keystoneclient 均配置使用 memcache 作為 token 的緩存。

由于網(wǎng)易私有云需要部署在多個(gè)機(jī)房之中，每個(gè)機(jī)房之間在地理位置上自然隔離，這對(duì)上層的應(yīng)用來(lái)說(shuō)是天然的容災(zāi)方法。另外，為了滿足私有云的功能和運(yùn)維需求，網(wǎng)易私有云需要同時(shí)支持兩種網(wǎng)絡(luò)模式：nova-network 和 neutron。針對(duì)這些需求，我們提出了一個(gè)面向企業(yè)級(jí)的多區(qū)域部署方案，如圖 2 所示。從整體上看，多個(gè)區(qū)域之間的部署相對(duì)獨(dú)立，但可通過(guò)內(nèi)網(wǎng)實(shí)現(xiàn)互通，每個(gè)區(qū)域中包括了一個(gè)完整的 OpenStack 部署，所以可以使用獨(dú)立的鏡像服務(wù)和獨(dú)立的網(wǎng)絡(luò)模式，例如區(qū)域 A 使用 nova-network，區(qū)域 B 使用 neutron，互不影響，另外為了實(shí)現(xiàn)用戶(hù)的單點(diǎn)登錄，區(qū)域之間共享了 keystone，區(qū)域的劃分依據(jù)主要是網(wǎng)絡(luò)模式和地理位置。

圖 2.多區(qū)域部署方法

和典型 OpenStack 部署將硬件劃分為計(jì)算節(jié)點(diǎn)和控制節(jié)點(diǎn)不同的是，為了充分利用硬件資源，我們努力把部署設(shè)計(jì)成對(duì)稱(chēng)的，即任意一個(gè)節(jié)點(diǎn)下線對(duì)整體服務(wù)不會(huì)照成影響。因此我們將硬件分為兩類(lèi)：計(jì)算節(jié)點(diǎn)，控制計(jì)算節(jié)點(diǎn)。計(jì)算節(jié)點(diǎn)部署 nova-network，nova-compute，nova-api-metadata，nova-api-os-compute?？刂朴?jì)算節(jié)點(diǎn)除了計(jì)算節(jié)點(diǎn)的服務(wù)外還部署了 nova-scheduler，nova-novncproxy，nova-consoleauth，glance-api，glance-registry 和 keystone，如圖 3 所示。

對(duì)外提供 API 的服務(wù)有 nova-api-os-compute，nova-novncproxy ,glance-api，keystone。這類(lèi)服務(wù)的特點(diǎn)是無(wú)狀態(tài)，可以方便地橫向擴(kuò)展，故此類(lèi)服務(wù)均部署在負(fù)載均衡 HAProxy 之后，并且使用 Keepalived 做高可用。為了保證服務(wù)質(zhì)量和便于維護(hù)，我們沒(méi)有使用 nova-api，而是分為 nova-api-os-compute 和 nova-api-metadata 分別管理。外部依賴(lài)方面，網(wǎng)易私有云部署了高可用 RabbitMQ 集群和主備 MySQL，以及 memcache 集群。

圖 3.計(jì)算節(jié)點(diǎn)，控制計(jì)算節(jié)點(diǎn)

網(wǎng)絡(luò)規(guī)劃方面，網(wǎng)易私有云主要使用 nova-network 的 FlatDHCPManager+multi-host 網(wǎng)絡(luò)模式，并劃分了多個(gè) Vlan，分別用于虛擬機(jī) fixed-ip 網(wǎng)絡(luò)、內(nèi)網(wǎng)浮動(dòng) IP 網(wǎng)絡(luò)、外網(wǎng)網(wǎng)絡(luò)。

運(yùn)維上使用網(wǎng)易自主研發(fā)的運(yùn)維平臺(tái)做監(jiān)控和報(bào)警，功能類(lèi)似 Nagios，但是更加強(qiáng)大。其中較重要的監(jiān)控報(bào)警包括日志監(jiān)控和進(jìn)程監(jiān)控。日志監(jiān)控保證服務(wù)發(fā)生異常時(shí)第一時(shí)間發(fā)現(xiàn)，進(jìn)程監(jiān)控保證服務(wù)正常運(yùn)行。另外網(wǎng)易私有云使用 Puppet 做自動(dòng)部署，以及使用 StackTach 幫助定位 bug。

OpenStack 各組件配置

OpenStack Havana 的配置項(xiàng)成百上千，大部分配置項(xiàng)都是可以使用默認(rèn)值的，否則光是理解這么多的配置項(xiàng)的含義就足以讓運(yùn)維人員崩潰，尤其是對(duì)那些并不熟悉源碼的運(yùn)維人員來(lái)說(shuō)更是如此。下文將列舉若干網(wǎng)易私有云中較關(guān)鍵的配置項(xiàng)，并解釋它們?nèi)绾斡绊懙椒?wù)的功能，安全性，以及性能等問(wèn)題。

Nova 關(guān)鍵配置

my_ip = 內(nèi)網(wǎng)地址

此項(xiàng)是用來(lái)生成宿主機(jī)上的 nova metadata api 請(qǐng)求轉(zhuǎn)發(fā) iptables 規(guī)則，如果配置不當(dāng)，會(huì)導(dǎo)致虛擬機(jī)內(nèi)部無(wú)法通過(guò) 169.254.169.254 這個(gè) IP 獲取 ec2/OpenStack metadata 信息；生成的 iptable 規(guī)則形如：

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

它另外的用途是虛擬機(jī)在 resize、cold migrate 等操作時(shí)，與目的端宿主機(jī)進(jìn)行數(shù)據(jù)通信。該項(xiàng)的默認(rèn)值為宿主機(jī)的外網(wǎng) IP 地址，建議改為內(nèi)網(wǎng)地址以避免潛在的安全風(fēng)險(xiǎn)。

metadata_listen = 內(nèi)網(wǎng)地址

此項(xiàng)是 nova-api-metadata 服務(wù)監(jiān)聽(tīng)的 IP 地址，可以從上面的 iptables 規(guī)則里面看出它與 my_ip 的配置項(xiàng)有一定的關(guān)聯(lián)，保持一致是最明智的選擇。

novncproxy_base_url = vncserver_proxyclient_address = ${private_ip_of_compute_host}
vncserver_listen = ${private_ip_of_compute_host}
novncproxy_host = ${private_ip_of_host}

我們僅在部分節(jié)點(diǎn)上部署 novncproxy 進(jìn)程，并把這些進(jìn)程加入到 HAProxy 服務(wù)中實(shí)現(xiàn) novnc 代理進(jìn)程的高可用，多個(gè) HAProxy 進(jìn)程使用 Keepalived 實(shí)施 HAProxy 的高可用，對(duì)外只需要暴露 Keepalived 管理的虛擬 IP 地址即可：

這種部署方式好處是：

1）實(shí)現(xiàn) novnc 代理服務(wù)的高可用

2）不會(huì)暴露云平臺(tái)相關(guān)節(jié)點(diǎn)的外網(wǎng)地址

3）易于 novnc 代理服務(wù)的擴(kuò)容

但也有不足：

1）虛擬機(jī)都監(jiān)聽(tīng)在其所在的計(jì)算節(jié)點(diǎn)的內(nèi)網(wǎng) IP 地址，一旦虛擬機(jī)與宿主機(jī)的網(wǎng)絡(luò)隔離出現(xiàn)問(wèn)題，會(huì)導(dǎo)致所有虛擬機(jī)的 VNC 地址接口暴露出去

2）在線遷移時(shí)會(huì)遇到問(wèn)題，因?yàn)?VNC 監(jiān)聽(tīng)的內(nèi)網(wǎng) IP 在目的端計(jì)算節(jié)點(diǎn)是不存在的，不過(guò)這個(gè)問(wèn)題 nova 社區(qū)已經(jīng)在解決了，相信很快就會(huì)合入 J 版本。

resume_guests_state_on_host_boot = true

在 nova-compute 進(jìn)程啟動(dòng)時(shí)，啟動(dòng)應(yīng)該處于運(yùn)行狀態(tài)的虛擬機(jī)，應(yīng)該處于運(yùn)行狀態(tài)的意思是 nova 數(shù)據(jù)庫(kù)中的虛擬機(jī)記錄是運(yùn)行狀態(tài)，但在 Hypervisor 上該虛擬機(jī)沒(méi)有運(yùn)行，在計(jì)算節(jié)點(diǎn)重啟時(shí)，該配置項(xiàng)具有很大的用處，它可以讓節(jié)點(diǎn)上所有虛擬機(jī)都自動(dòng)運(yùn)行起來(lái)，節(jié)省運(yùn)維人員手工處理的時(shí)間。

api_rate_limit = false

不限制 API 訪問(wèn)頻率，打開(kāi)之后 API 的并發(fā)訪問(wèn)數(shù)量會(huì)受到限制，可以根據(jù)云平臺(tái)的訪問(wèn)量及 API 進(jìn)程的數(shù)量和承受能力來(lái)判斷是否需要打開(kāi)，如果關(guān)閉該選項(xiàng)，則大并發(fā)情況下 API 請(qǐng)求處理時(shí)間會(huì)比較久。

osapi_max_limit = 5000

nova-api-os-compute api 的最大返回?cái)?shù)據(jù)長(zhǎng)度限制，如果設(shè)置過(guò)短，會(huì)導(dǎo)致部分響應(yīng)數(shù)據(jù)被截?cái)唷?

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

nova-scheduler 可用的過(guò)濾器，Retry 是用來(lái)跳過(guò)已經(jīng)嘗試創(chuàng)建但是失敗的計(jì)算節(jié)點(diǎn)，防止重調(diào)度死循環(huán)；AvailabilityZone 是過(guò)濾那些用戶(hù)指定的 AZ 的，防止用戶(hù)的虛擬機(jī)創(chuàng)建到未指定的 AZ 里面；Ram 是過(guò)濾掉內(nèi)存不足的計(jì)算節(jié)點(diǎn)；Core 是過(guò)濾掉 VCPU 數(shù)量不足的計(jì)算節(jié)點(diǎn)；Ecu 是我們自己開(kāi)發(fā)的過(guò)濾器，配合我們的 CPU QoS 功能開(kāi)發(fā)的，用來(lái)過(guò)濾掉 ecu 數(shù)量不足的計(jì)算節(jié)點(diǎn)；ImageProperties 是過(guò)濾掉不符合鏡像要求的計(jì)算節(jié)點(diǎn)，比如 QEMU 虛擬機(jī)所用的鏡像不能在 LXC 計(jì)算節(jié)點(diǎn)上使用；Json 是匹配自定義的節(jié)點(diǎn)選擇規(guī)則，比如不可以創(chuàng)建到某些 AZ，要與那些虛擬機(jī)創(chuàng)建到相同 AZ 等。其他還有一些過(guò)濾器可以根據(jù)需求進(jìn)行選擇。

running_deleted_instance_action = reap

nova-compute 定時(shí)任務(wù)發(fā)現(xiàn)在數(shù)據(jù)庫(kù)中已經(jīng)刪除，但計(jì)算節(jié)點(diǎn)的 Hypervisor 中還存在的虛擬機(jī)（也即野虛擬機(jī)審計(jì)操作方式）后的處理動(dòng)作，建議是選擇 log 或者 reap。log 方式需要運(yùn)維人員根據(jù)日志記錄找到那些野虛擬機(jī)并手工執(zhí)行后續(xù)的動(dòng)作，這種方式比較保險(xiǎn)，防止由于 nova 服務(wù)出現(xiàn)未知異?；蛘?bug 時(shí)導(dǎo)致用戶(hù)虛擬機(jī)被清理掉等問(wèn)題，而 reap 方式則可以節(jié)省運(yùn)維人員的人工介入時(shí)間。

until_refresh = 5

用戶(hù)配額與 instances 表中實(shí)際使用量的同步閾值，也即用戶(hù)的配額被修改多少次后強(qiáng)制同步一次使用量到配額量記錄

max_age = 86400

用戶(hù)配額與實(shí)際使用量的同步時(shí)間間隔，也即距上次配額記錄更新多少秒后，再次更新時(shí)會(huì)自動(dòng)與實(shí)際使用量同步。

眾所周知，開(kāi)源的 nova 項(xiàng)目目前仍然有很多配額方面的 bug 沒(méi)有解決，上面兩個(gè)配置項(xiàng)可以在很大程度上解決用戶(hù)配額使用情況與實(shí)際使用量不匹配的問(wèn)題，但也會(huì)帶來(lái)一定的數(shù)據(jù)庫(kù)性能開(kāi)銷(xiāo)，需要根據(jù)實(shí)際部署情況進(jìn)行合理設(shè)置。

### 計(jì)算節(jié)點(diǎn)資源預(yù)留 ###

vcpu_pin_set = 4-$

虛擬機(jī) vCPU 的綁定范圍，可以防止虛擬機(jī)爭(zhēng)搶宿主機(jī)進(jìn)程的 CPU 資源，建議值是預(yù)留前幾個(gè)物理 CPU，把后面的所有 CPU 分配給虛擬機(jī)使用，可以配合 cgroup 或者內(nèi)核啟動(dòng)參數(shù)來(lái)實(shí)現(xiàn)宿主機(jī)進(jìn)程不占用虛擬機(jī)使用的那些 CPU 資源。

cpu_allocation_ratio = 4.0

物理 CPU 超售比例，默認(rèn)是 16 倍，超線程也算作一個(gè)物理 CPU，需要根據(jù)具體負(fù)載和物理 CPU 能力進(jìn)行綜合判斷后確定具體的配置。

ram_allocation_ratio = 1.0

內(nèi)存分配超售比例，默認(rèn)是 1.5 倍，生產(chǎn)環(huán)境不建議開(kāi)啟超售。

reserved_host_memory_mb = 4096

內(nèi)存預(yù)留量，這部分內(nèi)存不能被虛擬機(jī)使用

reserved_host_disk_mb = 10240

磁盤(pán)預(yù)留空間，這部分空間不能被虛擬機(jī)使用

service_down_time = 120

服務(wù)下線時(shí)間閾值，如果一個(gè)節(jié)點(diǎn)上的 nova 服務(wù)超過(guò)這個(gè)時(shí)間沒(méi)有上報(bào)心跳到數(shù)據(jù)庫(kù)，api 服務(wù)會(huì)認(rèn)為該服務(wù)已經(jīng)下線，如果配置過(guò)短或過(guò)長(zhǎng)，都會(huì)導(dǎo)致誤判。

rpc_response_timeout = 300

RPC 調(diào)用超時(shí)時(shí)間，由于 Python 的單進(jìn)程不能真正的并發(fā)，所以 RPC 請(qǐng)求可能不能及時(shí)響應(yīng)，尤其是目標(biāo)節(jié)點(diǎn)在執(zhí)行耗時(shí)較長(zhǎng)的定時(shí)任務(wù)時(shí)，所以需要綜合考慮超時(shí)時(shí)間和等待容忍時(shí)間。

multi_host = True

是否開(kāi)啟 nova-network 的多節(jié)點(diǎn)模式，如果需要多節(jié)點(diǎn)部署，則該項(xiàng)需要設(shè)置為 True。

Keystone

配置項(xiàng)較少，主要是要權(quán)衡配置什么樣的后端驅(qū)動(dòng)，來(lái)存儲(chǔ) token，一般是 SQL 數(shù)據(jù)庫(kù)，也可以是 memcache。sql 可以持久化存儲(chǔ)，而 memcache 則速度更快，尤其是當(dāng)用戶(hù)要更新密碼的時(shí)候，需要?jiǎng)h除所有過(guò)期的 token，這種情況下 SQL 的速度與 memcache 相差很大很大。

glance

包括兩個(gè)部分，glance-api 和 glance-registry，：

workers = 2

glance-api 處理請(qǐng)求的子進(jìn)程數(shù)量，如果配置成 0，則只有一個(gè)主進(jìn)程，相應(yīng)的配置成 2，則有一個(gè)主進(jìn)程加 2 個(gè)子進(jìn)程來(lái)并發(fā)處理請(qǐng)求。建議根據(jù)進(jìn)程所在的物理節(jié)點(diǎn)計(jì)算能力和云平臺(tái)請(qǐng)求量來(lái)綜合確定。

api_limit_max = 1000

與 nova 中的配置 osapi_max_limit 意義相同

limit_param_default = 1000

一個(gè)響應(yīng)中最大返回項(xiàng)數(shù)，可以在請(qǐng)求參數(shù)中指定，默認(rèn)是 25，如果設(shè)置過(guò)短，可能導(dǎo)致響應(yīng)數(shù)據(jù)被截?cái)唷?

OpenStack 底層依賴(lài)軟件版本、配置以及性能調(diào)優(yōu)

虛擬化技術(shù)選型

在私有云平臺(tái)的體系架構(gòu)中， OpenStack 依賴(lài)一些底層軟件，如虛擬化軟件，虛擬化管理軟件和 Linux 內(nèi)核。這些軟件的穩(wěn)定性以及性能關(guān)系著整個(gè)云平臺(tái)的穩(wěn)定性和性能。因此，這些軟件的版本選擇和配置調(diào)優(yōu)也是網(wǎng)易私有云開(kāi)發(fā)中的一個(gè)重要因素。

在網(wǎng)易私有云平臺(tái)中，我們選用的是 Linux 內(nèi)核兼容最好的 KVM 虛擬化技術(shù)。相對(duì)于 Xen 虛擬化技術(shù)，KVM 虛擬化技術(shù)與 Linux 內(nèi)核聯(lián)系更為緊密，更容易維護(hù)。選擇 KVM 虛擬化技術(shù)后，虛擬化管理驅(qū)動(dòng)采用了 OpenStack 社區(qū)為 KVM 配置的計(jì)算驅(qū)動(dòng) libvirt，這也是一套使用非常廣泛，社區(qū)活躍度很高的一套開(kāi)源虛擬化管理軟件，支持 KVM 在內(nèi)的各種虛擬化管理。

另一方面，網(wǎng)易采用開(kāi)源的 Debian 作為自己的宿主機(jī)內(nèi)核，源使用的是 Debian 的 wheezy 穩(wěn)定分支，KVM 和 libvirt 采用的也是 Debian 社區(qū) wheezy 源里面的包版本：

qemu-kvm  1.1.2+dfsg-6+deb7u3
libvirt-bin  0.9.12

內(nèi)核選型

在內(nèi)核的選型方面，我們主要考慮如下兩方面的因素：

• 穩(wěn)定性：在開(kāi)發(fā)私有云平臺(tái)的一開(kāi)始，穩(wěn)定性就是網(wǎng)易私有云開(kāi)發(fā)的一大基本原則。我們采用 Debian Linux 版本，相對(duì)來(lái)說(shuō)，Debian 的原生內(nèi)核無(wú)疑更為穩(wěn)定。這也是我們最開(kāi)始的一個(gè)選擇。
• 功能需求：在網(wǎng)易的定制開(kāi)發(fā)中，為了保證虛擬機(jī)的服務(wù)性能，我們開(kāi)發(fā)了 CPU QoS 技術(shù)和磁盤(pán) QoS，它依賴(lài)底層的 CPU 和 blkio cgroup 支持。因此，我們需要打開(kāi)內(nèi)核中的 cgroup 配置選項(xiàng)。另一方面，網(wǎng)易私有云綜合各方面考慮，將支持 LXC 這種容器級(jí)別的虛擬化，除了 cgroup 外，LXC 還依賴(lài) Linux 內(nèi)核中的 namespace 特性。

綜合上述因素的考慮，我們選擇了 Debian 社區(qū)的 Linux 3.10.40 內(nèi)核源代碼，并且打開(kāi)了 CPU/mem/blkio 等 cgroup 配置選項(xiàng)以及 user namespace 等 namespace 選項(xiàng)，自己編譯了一個(gè)適配網(wǎng)易私有云的 Linux 內(nèi)核。從使用情況來(lái)看，選擇上述版本的 OpenStack 底層依賴(lài)軟件后，網(wǎng)易私有云運(yùn)行還比較穩(wěn)定，我們后續(xù)還會(huì)適時(shí)的對(duì)這些軟件進(jìn)行更新。

配置優(yōu)化

在網(wǎng)易私有云的穩(wěn)定性得到了保障之后，我們開(kāi)始了性能方面的調(diào)優(yōu)工作。這一方面，我們參考了 IBM 公司的一些優(yōu)秀實(shí)踐，在 CPU、內(nèi)存、I/O 等方面做了一些配置方面的優(yōu)化。整體而言，網(wǎng)易私有云在注重穩(wěn)定性的基礎(chǔ)上，也會(huì)積極借鑒業(yè)界優(yōu)秀實(shí)踐來(lái)優(yōu)化私有云平臺(tái)的整體性能。

CPU 配置優(yōu)化

為了保障云主機(jī)的計(jì)算能力，網(wǎng)易私有云開(kāi)發(fā)了 CPU QoS 技術(shù)，具體來(lái)說(shuō)就是采用 cfs 的時(shí)間片均勻調(diào)度，外加 process pinning 的綁定技術(shù)。

參考 IBM 的分析，我們了解到了 process pinning 技術(shù)的優(yōu)缺點(diǎn)，并且經(jīng)過(guò)測(cè)試也驗(yàn)證了不同綁定方式的云主機(jī)間的性能存在較大的差異。比如，2 個(gè) VCPU 分別綁定到不同 numa 節(jié)點(diǎn)的非超線程核上和分配到一對(duì)相鄰的超線程核上的性能相差有 30%~40%(通過(guò) SPEC CPU2006 工具測(cè)試)。另一方面，CPU0 由于處理中斷請(qǐng)求，本身負(fù)荷就較重，不宜再用于云主機(jī)。因此，綜合上面的因素考慮以及多輪的測(cè)試驗(yàn)證，我們最終決定將 0-3 號(hào) CPU 預(yù)留出來(lái)，然后讓云主機(jī)在剩余的 CPU 資源中由宿主機(jī)內(nèi)核去調(diào)度。最終的 CPU 配置如下所示（libvirt xml 配置）：

<vcpu placement='static' cpuset='4-23'>1</vcpu>
<cputune>
    <shares>1024</shares>
    <period>100000</period>
    <quota>57499</quota>
</cputune>

內(nèi)存配置優(yōu)化

內(nèi)存配置方面，網(wǎng)易私有云的實(shí)踐是關(guān)閉 KVM 內(nèi)存共享，打開(kāi)透明大頁(yè)：

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

經(jīng)過(guò) SPEC CPU2006 測(cè)試，這些配置對(duì)云主機(jī) CPU 性能大概有 7%左右的提升。

I/O 配置優(yōu)化

1）磁盤(pán) I/O 的配置優(yōu)化主要包含如下方面：

KVM 的 disk cache 方式：借鑒 IBM 的分析，網(wǎng)易私有云采用 none 這種 cache 方式。

disk io scheduler：目前網(wǎng)易私有云的宿主機(jī)磁盤(pán)調(diào)度策略選用的是 cfq。在實(shí)際使用過(guò)程中，我們發(fā)現(xiàn) cfq 的調(diào)度策略，對(duì)那些地低配置磁盤(pán)很容易出現(xiàn) I/O 調(diào)度隊(duì)列過(guò)長(zhǎng)，utils 100% 的問(wèn)題。后續(xù)網(wǎng)易私有云也會(huì)借鑒 IBM 的實(shí)踐，對(duì) cfq 進(jìn)行參數(shù)調(diào)優(yōu)，以及測(cè)試 deadline 調(diào)度策略。

磁盤(pán) I/O QoS：面對(duì)日漸突出的磁盤(pán) I/O 資源緊缺問(wèn)題，網(wǎng)易私有云開(kāi)發(fā)了磁盤(pán) I/O QoS，主要是基于 blkio cgroup 來(lái)設(shè)置其 throttle 參數(shù)來(lái)實(shí)現(xiàn)。由于 libvirt-0.9.12 版本是在 QEMU 中限制磁盤(pán) I/O，并且存在波動(dòng)問(wèn)題，所以我們的實(shí)現(xiàn)是通過(guò) Nova 執(zhí)行命令方式寫(xiě)入到 cgroup 中。同時(shí)我們也開(kāi)發(fā)并向 libvirt 社區(qū)提交了 blkiotune 的 throttle 接口設(shè)置 patch（已在 libvirt-1.2.2 版本中合入）來(lái)徹底解決這個(gè)問(wèn)題。

2）網(wǎng)絡(luò) I/O 的配置優(yōu)化

我們主要是開(kāi)啟了 vhost_net 模式，來(lái)減少網(wǎng)絡(luò)延時(shí)和增加吞吐量。

運(yùn)維經(jīng)驗(yàn)

使用經(jīng)驗(yàn)

• 開(kāi)源軟件 bug 在所難免，但是新版本比舊版本會(huì)好用很多，尤其是對(duì)于 OpenStack 這種正在迅速成長(zhǎng)壯大的開(kāi)源軟件來(lái)說(shuō)更是如此，這一點(diǎn)在我們使用過(guò) Essex、Folsom 和 Havana 版本后深有體會(huì)，所以建議各種 OpenStack 用戶(hù)能及時(shí)的跟進(jìn)社區(qū)版本，與社區(qū)保持同步。
• 不要輕易的對(duì)社區(qū)版本進(jìn)行各類(lèi)所謂的功能性能方面的"優(yōu)化"，尤其是在沒(méi)有與社區(qū)專(zhuān)家交換意見(jiàn)之前，千萬(wàn)不要輕易下手，否則此類(lèi)"優(yōu)化"極有可能演變成故障點(diǎn)或者性能瓶頸點(diǎn)，最終可能導(dǎo)致無(wú)法與社區(qū)同步，畢竟一個(gè)公司或團(tuán)隊(duì)（尤其是小公司、小團(tuán)隊(duì)）的能力和知識(shí)儲(chǔ)備，是很難與社區(qū)成百上千的各類(lèi)專(zhuān)家相提并論的。
• 多參考各類(lèi)大型公司分享的部署架構(gòu)方案，盡量不要自己閉門(mén)造車(chē)，尤其是對(duì)于開(kāi)源軟件來(lái)說(shuō)，各類(lèi)公司、團(tuán)隊(duì)的使用場(chǎng)景千差萬(wàn)別，各種周邊組件也是應(yīng)有盡有，多參考業(yè)界實(shí)踐是最好的方式。
• 一些細(xì)節(jié)實(shí)現(xiàn)可能有很多途徑，但每種方式都有優(yōu)缺點(diǎn)，需要經(jīng)過(guò)充分的論證、分析、測(cè)試驗(yàn)證后，才能考慮部署到生產(chǎn)環(huán)境使用。
• 所有的部署方案、功能設(shè)計(jì)都要考慮到平滑升級(jí)問(wèn)題，即使你得到的信息是升級(jí)時(shí)可以停服，仍然要盡量避免這種情況，因?yàn)橥７挠绊懛秶茈y界定。

運(yùn)維準(zhǔn)則

OpenStack 也是一個(gè)后端系統(tǒng)服務(wù)，所有系統(tǒng)運(yùn)維相關(guān)的基本準(zhǔn)則都適用，這里簡(jiǎn)單的提幾點(diǎn)實(shí)際運(yùn)維過(guò)程中根據(jù)遇到的問(wèn)題總結(jié)的一些經(jīng)驗(yàn)：

• 配置項(xiàng)默認(rèn)值與實(shí)際環(huán)境不匹配可能導(dǎo)致各種問(wèn)題，尤其是網(wǎng)絡(luò)相關(guān)配置與硬件有很強(qiáng)的關(guān)聯(lián)性，生產(chǎn)環(huán)境和開(kāi)發(fā)環(huán)境硬件異構(gòu)，導(dǎo)致部分默認(rèn)值在生產(chǎn)環(huán)境不適用。應(yīng)對(duì)準(zhǔn)則：每個(gè)版本都必須在與線上硬件相同的環(huán)境測(cè)試過(guò)才能上線。
• 做好容量規(guī)劃，已分配的配額量要小于云平臺(tái)總?cè)萘浚駝t會(huì)出現(xiàn)各種問(wèn)題，導(dǎo)致運(yùn)維開(kāi)發(fā)耗費(fèi)很多不必要的精力去定位分析問(wèn)題。
• 配置項(xiàng)過(guò)多容易出錯(cuò)，需要與開(kāi)發(fā)人員一起仔細(xì)核對(duì)，上線時(shí)首先要通過(guò) puppet 的 noop 功能驗(yàn)證改動(dòng)是否正確后，才能真正上線。
• 網(wǎng)絡(luò)規(guī)劃要提前做好，如固定 IP、浮動(dòng) IP、VLAN 數(shù)量等，網(wǎng)絡(luò)擴(kuò)容難度和風(fēng)險(xiǎn)都比較大，所以提前規(guī)劃好是最保險(xiǎn)的，一個(gè)原則是大比小好，多比少好。
• 網(wǎng)絡(luò)隔離要做好，否則用戶(hù)網(wǎng)絡(luò)安全沒(méi)辦法保證。
• 信息安全問(wèn)題要重視，這個(gè)是老生常談的問(wèn)題了，每個(gè)平臺(tái)都有相同問(wèn)題，但還是要重視再重視，一旦出現(xiàn)安全漏洞，所有虛擬機(jī)都面臨嚴(yán)重威脅。