剖析網(wǎng)易運(yùn)用OpenStack部署云計算平臺的案例

背景：遠(yuǎn)在天邊近在眼前的OpenStack用戶
OpenStack開源的特性，使其普及的速度比想象中要快得多。尤其受到電商的歡迎。其中攜程是目前國內(nèi)典型的OpenStack用戶，從2012年開始搭建私有云，該公司目前基于OpenStack部署了超過1000個虛擬桌面，未來計劃部署130000個。除此之外，愛奇藝也是涉足OpenStack的用戶，在2012年愛奇藝加入中國開源云聯(lián)盟，與英特爾、新浪等企業(yè)進(jìn)行OpenStack項(xiàng)目的開發(fā)。目前愛奇藝也成為中國視頻行業(yè)規(guī)模最大的OpenStack技術(shù)應(yīng)用商，該技術(shù)已被運(yùn)用到內(nèi)容生產(chǎn)、廣告投放、賬號管理、用戶付費(fèi)和大數(shù)據(jù)分析等方面。

　　不僅如此，京東商城已經(jīng)利用OpenStack平臺接入了大量線上業(yè)務(wù)，實(shí)現(xiàn)了自動部署、OpenStack HA、桌面云(Call Center)以及Elastic Scaling ELB等功能。其中線上業(yè)務(wù)和Call Center都屬于需要保持高度穩(wěn)定的服務(wù)，京東已經(jīng)在OpenStack應(yīng)用部署方面下了相當(dāng)?shù)墓Ψ?，克服了目前OpenStack版本迭代過快和bug問題，已經(jīng)使其達(dá)到了商業(yè)化運(yùn)營的效果。

　　除了京東，網(wǎng)易使用OpenStack構(gòu)建了自己的私有云web服務(wù)提供云主機(jī)支持，并把網(wǎng)易相冊，博客等訪問量較大的服務(wù)遷移到云平臺中，目前已穩(wěn)定運(yùn)行近1年，中間經(jīng)歷了在線平滑升級和10多個新產(chǎn)品上線，并且網(wǎng)易還針對其產(chǎn)品自身的業(yè)務(wù)特點(diǎn)在監(jiān)控、報警、運(yùn)維自動化方面開發(fā)了新功能。

OpenStack 簡介
OpenStack 是一個開源的 IaaS 實(shí)現(xiàn)，它由一些相互關(guān)聯(lián)的子項(xiàng)目組成，主要包括計算、存儲、網(wǎng)絡(luò)。由于以 Apache 協(xié)議發(fā)布，自 2010 年項(xiàng)目成立以來，超過 200 個公司加入了 OpenStack 項(xiàng)目，其中包括 ATT、AMD、Cisco、Dell、IBM、Intel、Red Hat 等。目前參與 OpenStack 項(xiàng)目的開發(fā)人員有 17,000+，來自 139 個國家，這一數(shù)字還在不斷增長中。
OpenStack 兼容一部分 AWS 接口，同時為了提供更強(qiáng)大的功能，也提供 OpenStack 風(fēng)格的接口（RESTFul API）。和其他開源 IaaS 相比，架構(gòu)上松耦合、高可擴(kuò)展、分布式、純 Python 實(shí)現(xiàn)，以及友好活躍的社區(qū)使其大受歡迎，每半年一次的開發(fā)峰會也吸引了來自全世界的開發(fā)者、供應(yīng)商和客戶。
OpenStack 的主要子項(xiàng)目有：
網(wǎng)易私有云使用了 Nova、Glance、Keystone、Neutron 這 4 個組件。
Compute（Nova）提供計算虛擬化服務(wù)，是 OpenStack 的核心，負(fù)責(zé)管理和創(chuàng)建虛擬機(jī)。它被設(shè)計成方便擴(kuò)展，支持多種虛擬化技術(shù)，并且可以部署在標(biāo)準(zhǔn)硬件上。
Object Storage（Swift）提供對象存儲服務(wù)，是一個分布式，可擴(kuò)展，多副本的存儲系統(tǒng)。
Block Storage（Cinder），提供塊存儲服務(wù)，為 OpenStack 的虛擬機(jī)提供持久的塊級存儲設(shè)備。支持多種存儲后端，包括 Ceph，EMC 等。
Networking（Neutron）提供網(wǎng)絡(luò)虛擬化服務(wù)，是一個可拔插，可擴(kuò)展，API 驅(qū)動的服務(wù)。
Dashboard 提供了一個圖形控制臺服務(wù)，讓用戶方便地訪問，使用和維護(hù) OpenStack 中的資源。
Image（glance）提供鏡像服務(wù)，它旨在發(fā)現(xiàn)，注冊和交付虛擬機(jī)磁盤和鏡像。支持多種后端。
Telemetry（Ceilometer）提供用量統(tǒng)計服務(wù)，通過它可以方便地實(shí)現(xiàn) OpenStack 計費(fèi)功能。
Orchestration（Heat）整合了 OpenStack 中的眾多組件，類似 AWS 的 CloudFormation，讓用戶能夠通過模板來管理資源。
Database（Trove）基于 OpenStack 構(gòu)建的 database-as-a-service。

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

網(wǎng)易私有云平臺由網(wǎng)易杭州研究院負(fù)責(zé)研發(fā)，主要提供基礎(chǔ)設(shè)施資源、數(shù)據(jù)存儲處理、應(yīng)用開發(fā)部署、運(yùn)維管理等功能以滿足公司產(chǎn)品測試/上線的需求。
圖 1 展示了網(wǎng)易私有云平臺的整體架構(gòu)。整個私有云平臺可分為三大類服務(wù)：核心基礎(chǔ)設(shè)施服務(wù)（IaaS）、基礎(chǔ)平臺服務(wù)（PaaS）以及運(yùn)維管理支撐服務(wù)，目前一共包括了：云主機(jī)（虛擬機(jī)）、云網(wǎng)絡(luò)、云硬盤、對象存儲、對象緩存、關(guān)系型數(shù)據(jù)庫、分布式數(shù)據(jù)庫、全文檢索、消息隊列、視頻轉(zhuǎn)碼、負(fù)載均衡、容器引擎、云計費(fèi)、云監(jiān)控、管理平臺等 15 個服務(wù)。網(wǎng)易私有云平臺充分利用云計算開源的最新成果，我們基于 OpenStack 社區(qū)的 keystone、glance、nova、neutron 組件研發(fā)部署了云主機(jī)和云網(wǎng)絡(luò)服務(wù)。
為了與網(wǎng)易私有云平臺其他服務(wù)（云硬盤、云監(jiān)控、云計費(fèi)等）深度整合以及滿足公司產(chǎn)品使用和運(yùn)維管理的特定需求，我們團(tuán)隊在社區(qū) OpenStack 版本的基礎(chǔ)上獨(dú)立研發(fā)了包括：云主機(jī)資源質(zhì)量保障（計算、存儲、網(wǎng)絡(luò) QoS）、鏡像分塊存儲、云主機(jī)心跳上報、flat-dhcp 模式下租戶內(nèi)網(wǎng)隔離等 20 多個新功能。同時，我們團(tuán)隊在日常運(yùn)維 OpenStack 以及升級社區(qū)新版本中，也總結(jié)了一些部署、運(yùn)維規(guī)范以及升級經(jīng)驗(yàn)。兩年多來，網(wǎng)易私有云平臺 OpenStack 團(tuán)隊的研發(fā)秉承開源、開放的理念，始終遵循"來源社區(qū)，回饋社區(qū)"的原則。在免費(fèi)享受 OpenStack 社區(qū)不斷研發(fā)新功能以及修復(fù) bug 的同時，我們團(tuán)隊也積極向社區(qū)做自己的貢獻(xiàn)，從而幫助 OpenStack 社區(qū)的發(fā)展壯大。兩年來，我們團(tuán)隊一共向社區(qū)提交新功能開發(fā)/bug 修復(fù)的 commits 近 100 個，修復(fù)社區(qū) bug 50 多個，這些社區(qū)貢獻(xiàn)涉及 OpenStack 的 Essex、Folsom、Havana、Icehouse、Juno 等版本。
得益于 OpenStack 的日益穩(wěn)定成熟，私有云平臺目前已經(jīng)穩(wěn)定運(yùn)行了 2 年多時間，為網(wǎng)易公司多達(dá) 30 個互聯(lián)網(wǎng)和游戲產(chǎn)品提供服務(wù)。從應(yīng)用的效果來看，基于 OpenStack 研發(fā)的網(wǎng)易私有云平臺已經(jīng)達(dá)到了以下目標(biāo)：
提高了公司基礎(chǔ)設(shè)施資源利用率，從而降低了硬件成本。以物理服務(wù)器 CPU 利用率為例，私有云平臺將 CPU 平均利用率從不到 10% 提升到 50%。
提高了基礎(chǔ)設(shè)施資源管理與運(yùn)維自動化水平，從而降低了運(yùn)維成本。借助于 Web 自助式的資源申請和分配方式以及云平臺自動部署服務(wù)，系統(tǒng)運(yùn)維人員減少了 50%。
提高了基礎(chǔ)設(shè)施資源使用彈性，從而增強(qiáng)了產(chǎn)品業(yè)務(wù)波動的適應(yīng)能力。利用虛擬化技術(shù)將物理基礎(chǔ)設(shè)施做成虛擬資源池，通過有效的容量規(guī)劃以及按需使用，私有云平臺可以很好適應(yīng)產(chǎn)品突發(fā)業(yè)務(wù)。
網(wǎng)易 OpenStack 部署參考方案介紹
在具體的生產(chǎn)環(huán)境中，我們?yōu)榱思骖櫺阅芎涂煽啃?，keystone 后端使用 Mysql 存儲用戶信息，使用 memcache 存放 token。為了減少對 keystone 的訪問壓力，所有服務(wù)（nova，glance，neutron）的 keystoneclient 均配置使用 memcache 作為 token 的緩存。
由于網(wǎng)易私有云需要部署在多個機(jī)房之中，每個機(jī)房之間在地理位置上自然隔離，這對上層的應(yīng)用來說是天然的容災(zāi)方法。另外，為了滿足私有云的功能和運(yùn)維需求，網(wǎng)易私有云需要同時支持兩種網(wǎng)絡(luò)模式：nova-network 和 neutron。針對這些需求，我們提出了一個面向企業(yè)級的多區(qū)域部署方案，如圖 2 所示。從整體上看，多個區(qū)域之間的部署相對獨(dú)立，但可通過內(nèi)網(wǎng)實(shí)現(xiàn)互通，每個區(qū)域中包括了一個完整的 OpenStack 部署，所以可以使用獨(dú)立的鏡像服務(wù)和獨(dú)立的網(wǎng)絡(luò)模式，例如區(qū)域 A 使用 nova-network，區(qū)域 B 使用 neutron，互不影響，另外為了實(shí)現(xiàn)用戶的單點(diǎn)登錄，區(qū)域之間共享了 keystone，區(qū)域的劃分依據(jù)主要是網(wǎng)絡(luò)模式和地理位置。
圖 2.多區(qū)域部署方法

和典型 OpenStack 部署將硬件劃分為計算節(jié)點(diǎn)和控制節(jié)點(diǎn)不同的是，為了充分利用硬件資源，我們努力把部署設(shè)計成對稱的，即任意一個節(jié)點(diǎn)下線對整體服務(wù)不會照成影響。因此我們將硬件分為兩類：計算節(jié)點(diǎn)，控制計算節(jié)點(diǎn)。計算節(jié)點(diǎn)部署 nova-network，nova-compute，nova-api-metadata，nova-api-os-compute?？刂朴嬎愎?jié)點(diǎn)除了計算節(jié)點(diǎn)的服務(wù)外還部署了 nova-scheduler，nova-novncproxy，nova-consoleauth，glance-api，glance-registry 和 keystone，如圖 3 所示。
對外提供 API 的服務(wù)有 nova-api-os-compute，nova-novncproxy ,glance-api，keystone。這類服務(wù)的特點(diǎn)是無狀態(tài)，可以方便地橫向擴(kuò)展，故此類服務(wù)均部署在負(fù)載均衡 HAProxy 之后，并且使用 Keepalived 做高可用。為了保證服務(wù)質(zhì)量和便于維護(hù)，我們沒有使用 nova-api，而是分為 nova-api-os-compute 和 nova-api-metadata 分別管理。外部依賴方面，網(wǎng)易私有云部署了高可用 RabbitMQ 集群和主備 MySQL，以及 memcache 集群。
圖 3.計算節(jié)點(diǎn)，控制計算節(jié)點(diǎn)

網(wǎng)絡(luò)規(guī)劃方面，網(wǎng)易私有云主要使用 nova-network 的 FlatDHCPManager+multi-host 網(wǎng)絡(luò)模式，并劃分了多個 Vlan，分別用于虛擬機(jī) fixed-ip 網(wǎng)絡(luò)、內(nèi)網(wǎng)浮動 IP 網(wǎng)絡(luò)、外網(wǎng)網(wǎng)絡(luò)。
運(yùn)維上使用網(wǎng)易自主研發(fā)的運(yùn)維平臺做監(jiān)控和報警，功能類似 Nagios，但是更加強(qiáng)大。其中較重要的監(jiān)控報警包括日志監(jiān)控和進(jìn)程監(jiān)控。日志監(jiān)控保證服務(wù)發(fā)生異常時第一時間發(fā)現(xiàn)，進(jìn)程監(jiān)控保證服務(wù)正常運(yùn)行。另外網(wǎng)易私有云使用 Puppet 做自動部署，以及使用 StackTach 幫助定位 bug。
OpenStack 各組件配置
OpenStack Havana 的配置項(xiàng)成百上千，大部分配置項(xiàng)都是可以使用默認(rèn)值的，否則光是理解這么多的配置項(xiàng)的含義就足以讓運(yùn)維人員崩潰，尤其是對那些并不熟悉源碼的運(yùn)維人員來說更是如此。下文將列舉若干網(wǎng)易私有云中較關(guān)鍵的配置項(xiàng)，并解釋它們?nèi)绾斡绊懙椒?wù)的功能，安全性，以及性能等問題。

Nova 關(guān)鍵配置
my_ip = 內(nèi)網(wǎng)地址
此項(xiàng)是用來生成宿主機(jī)上的 nova metadata api 請求轉(zhuǎn)發(fā) iptables 規(guī)則，如果配置不當(dāng)，會導(dǎo)致虛擬機(jī)內(nèi)部無法通過 169.254.169.254 這個 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 等操作時，與目的端宿主機(jī)進(jìn)行數(shù)據(jù)通信。該項(xiàng)的默認(rèn)值為宿主機(jī)的外網(wǎng) IP 地址，建議改為內(nèi)網(wǎng)地址以避免潛在的安全風(fēng)險。
metadata_listen = 內(nèi)網(wǎng)地址
此項(xiàng)是 nova-api-metadata 服務(wù)監(jiān)聽的 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)程的高可用，多個 HAProxy 進(jìn)程使用 Keepalived 實(shí)施 HAProxy 的高可用，對外只需要暴露 Keepalived 管理的虛擬 IP 地址即可：
這種部署方式好處是：
1）實(shí)現(xiàn) novnc 代理服務(wù)的高可用
2）不會暴露云平臺相關(guān)節(jié)點(diǎn)的外網(wǎng)地址
3）易于 novnc 代理服務(wù)的擴(kuò)容
但也有不足：
1）虛擬機(jī)都監(jiān)聽在其所在的計算節(jié)點(diǎn)的內(nèi)網(wǎng) IP 地址，一旦虛擬機(jī)與宿主機(jī)的網(wǎng)絡(luò)隔離出現(xiàn)問題，會導(dǎo)致所有虛擬機(jī)的 VNC 地址接口暴露出去
2）在線遷移時會遇到問題，因?yàn)?VNC 監(jiān)聽的內(nèi)網(wǎng) IP 在目的端計算節(jié)點(diǎn)是不存在的，不過這個問題 nova 社區(qū)已經(jīng)在解決了，相信很快就會合入 J 版本。
resume_guests_state_on_host_boot = true
在 nova-compute 進(jìn)程啟動時，啟動應(yīng)該處于運(yùn)行狀態(tài)的虛擬機(jī)，應(yīng)該處于運(yùn)行狀態(tài)的意思是 nova 數(shù)據(jù)庫中的虛擬機(jī)記錄是運(yùn)行狀態(tài)，但在 Hypervisor 上該虛擬機(jī)沒有運(yùn)行，在計算節(jié)點(diǎn)重啟時，該配置項(xiàng)具有很大的用處，它可以讓節(jié)點(diǎn)上所有虛擬機(jī)都自動運(yùn)行起來，節(jié)省運(yùn)維人員手工處理的時間。
api_rate_limit = false
不限制 API 訪問頻率，打開之后 API 的并發(fā)訪問數(shù)量會受到限制，可以根據(jù)云平臺的訪問量及 API 進(jìn)程的數(shù)量和承受能力來判斷是否需要打開，如果關(guān)閉該選項(xiàng)，則大并發(fā)情況下 API 請求處理時間會比較久。
osapi_max_limit = 5000
nova-api-os-compute api 的最大返回數(shù)據(jù)長度限制，如果設(shè)置過短，會導(dǎo)致部分響應(yīng)數(shù)據(jù)被截斷。
scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, ComputeFilter, ImagePropertiesFilter, JsonFilter, EcuFilter, CoreFilter
nova-scheduler 可用的過濾器，Retry 是用來跳過已經(jīng)嘗試創(chuàng)建但是失敗的計算節(jié)點(diǎn)，防止重調(diào)度死循環(huán)；AvailabilityZone 是過濾那些用戶指定的 AZ 的，防止用戶的虛擬機(jī)創(chuàng)建到未指定的 AZ 里面；Ram 是過濾掉內(nèi)存不足的計算節(jié)點(diǎn)；Core 是過濾掉 VCPU 數(shù)量不足的計算節(jié)點(diǎn)；Ecu 是我們自己開發(fā)的過濾器，配合我們的 CPU QoS 功能開發(fā)的，用來過濾掉 ecu 數(shù)量不足的計算節(jié)點(diǎn)；ImageProperties 是過濾掉不符合鏡像要求的計算節(jié)點(diǎn)，比如 QEMU 虛擬機(jī)所用的鏡像不能在 LXC 計算節(jié)點(diǎn)上使用；Json 是匹配自定義的節(jié)點(diǎn)選擇規(guī)則，比如不可以創(chuàng)建到某些 AZ，要與那些虛擬機(jī)創(chuàng)建到相同 AZ 等。其他還有一些過濾器可以根據(jù)需求進(jìn)行選擇。
running_deleted_instance_action = reap
nova-compute 定時任務(wù)發(fā)現(xiàn)在數(shù)據(jù)庫中已經(jīng)刪除，但計算節(jié)點(diǎn)的 Hypervisor 中還存在的虛擬機(jī)（也即野虛擬機(jī)審計操作方式）后的處理動作，建議是選擇 log 或者 reap。log 方式需要運(yùn)維人員根據(jù)日志記錄找到那些野虛擬機(jī)并手工執(zhí)行后續(xù)的動作，這種方式比較保險，防止由于 nova 服務(wù)出現(xiàn)未知異?；蛘?bug 時導(dǎo)致用戶虛擬機(jī)被清理掉等問題，而 reap 方式則可以節(jié)省運(yùn)維人員的人工介入時間。
until_refresh = 5
用戶配額與 instances 表中實(shí)際使用量的同步閾值，也即用戶的配額被修改多少次后強(qiáng)制同步一次使用量到配額量記錄
max_age = 86400
用戶配額與實(shí)際使用量的同步時間間隔，也即距上次配額記錄更新多少秒后，再次更新時會自動與實(shí)際使用量同步。
眾所周知，開源的 nova 項(xiàng)目目前仍然有很多配額方面的 bug 沒有解決，上面兩個配置項(xiàng)可以在很大程度上解決用戶配額使用情況與實(shí)際使用量不匹配的問題，但也會帶來一定的數(shù)據(jù)庫性能開銷，需要根據(jù)實(shí)際部署情況進(jìn)行合理設(shè)置。
### 計算節(jié)點(diǎn)資源預(yù)留 ###
vcpu_pin_set = 4-$
虛擬機(jī) vCPU 的綁定范圍，可以防止虛擬機(jī)爭搶宿主機(jī)進(jìn)程的 CPU 資源，建議值是預(yù)留前幾個物理 CPU，把后面的所有 CPU 分配給虛擬機(jī)使用，可以配合 cgroup 或者內(nèi)核啟動參數(shù)來實(shí)現(xiàn)宿主機(jī)進(jìn)程不占用虛擬機(jī)使用的那些 CPU 資源。
cpu_allocation_ratio = 4.0
物理 CPU 超售比例，默認(rèn)是 16 倍，超線程也算作一個物理 CPU，需要根據(jù)具體負(fù)載和物理 CPU 能力進(jìn)行綜合判斷后確定具體的配置。
ram_allocation_ratio = 1.0
內(nèi)存分配超售比例，默認(rèn)是 1.5 倍，生產(chǎn)環(huán)境不建議開啟超售。
reserved_host_memory_mb = 4096
內(nèi)存預(yù)留量，這部分內(nèi)存不能被虛擬機(jī)使用
reserved_host_disk_mb = 10240
磁盤預(yù)留空間，這部分空間不能被虛擬機(jī)使用
service_down_time = 120
服務(wù)下線時間閾值，如果一個節(jié)點(diǎn)上的 nova 服務(wù)超過這個時間沒有上報心跳到數(shù)據(jù)庫，api 服務(wù)會認(rèn)為該服務(wù)已經(jīng)下線，如果配置過短或過長，都會導(dǎo)致誤判。
rpc_response_timeout = 300
RPC 調(diào)用超時時間，由于 Python 的單進(jìn)程不能真正的并發(fā)，所以 RPC 請求可能不能及時響應(yīng)，尤其是目標(biāo)節(jié)點(diǎn)在執(zhí)行耗時較長的定時任務(wù)時，所以需要綜合考慮超時時間和等待容忍時間。
multi_host = True
是否開啟 nova-network 的多節(jié)點(diǎn)模式，如果需要多節(jié)點(diǎn)部署，則該項(xiàng)需要設(shè)置為 True。
Keystone
配置項(xiàng)較少，主要是要權(quán)衡配置什么樣的后端驅(qū)動，來存儲 token，一般是 SQL 數(shù)據(jù)庫，也可以是 memcache。sql 可以持久化存儲，而 memcache 則速度更快，尤其是當(dāng)用戶要更新密碼的時候，需要刪除所有過期的 token，這種情況下 SQL 的速度與 memcache 相差很大很大。
glance
包括兩個部分，glance-api 和 glance-registry，：

workers = 2
glance-api 處理請求的子進(jìn)程數(shù)量，如果配置成 0，則只有一個主進(jìn)程，相應(yīng)的配置成 2，則有一個主進(jìn)程加 2 個子進(jìn)程來并發(fā)處理請求。建議根據(jù)進(jìn)程所在的物理節(jié)點(diǎn)計算能力和云平臺請求量來綜合確定。
api_limit_max = 1000
與 nova 中的配置 osapi_max_limit 意義相同
limit_param_default = 1000
一個響應(yīng)中最大返回項(xiàng)數(shù)，可以在請求參數(shù)中指定，默認(rèn)是 25，如果設(shè)置過短，可能導(dǎo)致響應(yīng)數(shù)據(jù)被截斷。
OpenStack 底層依賴軟件版本、配置以及性能調(diào)優(yōu)
虛擬化技術(shù)選型
在私有云平臺的體系架構(gòu)中， OpenStack 依賴一些底層軟件，如虛擬化軟件，虛擬化管理軟件和 Linux 內(nèi)核。這些軟件的穩(wěn)定性以及性能關(guān)系著整個云平臺的穩(wěn)定性和性能。因此，這些軟件的版本選擇和配置調(diào)優(yōu)也是網(wǎng)易私有云開發(fā)中的一個重要因素。
在網(wǎng)易私有云平臺中，我們選用的是 Linux 內(nèi)核兼容最好的 KVM 虛擬化技術(shù)。相對于 Xen 虛擬化技術(shù)，KVM 虛擬化技術(shù)與 Linux 內(nèi)核聯(lián)系更為緊密，更容易維護(hù)。選擇 KVM 虛擬化技術(shù)后，虛擬化管理驅(qū)動采用了 OpenStack 社區(qū)為 KVM 配置的計算驅(qū)動 libvirt，這也是一套使用非常廣泛，社區(qū)活躍度很高的一套開源虛擬化管理軟件，支持 KVM 在內(nèi)的各種虛擬化管理。
另一方面，網(wǎng)易采用開源的 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)定性：在開發(fā)私有云平臺的一開始，穩(wěn)定性就是網(wǎng)易私有云開發(fā)的一大基本原則。我們采用 Debian Linux 版本，相對來說，Debian 的原生內(nèi)核無疑更為穩(wěn)定。這也是我們最開始的一個選擇。
功能需求：在網(wǎng)易的定制開發(fā)中，為了保證虛擬機(jī)的服務(wù)性能，我們開發(fā)了 CPU QoS 技術(shù)和磁盤 QoS，它依賴底層的 CPU 和 blkio cgroup 支持。因此，我們需要打開內(nèi)核中的 cgroup 配置選項(xiàng)。另一方面，網(wǎng)易私有云綜合各方面考慮，將支持 LXC 這種容器級別的虛擬化，除了 cgroup 外，LXC 還依賴 Linux 內(nèi)核中的 namespace 特性。
綜合上述因素的考慮，我們選擇了 Debian 社區(qū)的 Linux 3.10.40 內(nèi)核源代碼，并且打開了 CPU/mem/blkio 等 cgroup 配置選項(xiàng)以及 user namespace 等 namespace 選項(xiàng)，自己編譯了一個適配網(wǎng)易私有云的 Linux 內(nèi)核。從使用情況來看，選擇上述版本的 OpenStack 底層依賴軟件后，網(wǎng)易私有云運(yùn)行還比較穩(wěn)定，我們后續(xù)還會適時的對這些軟件進(jìn)行更新。
配置優(yōu)化
在網(wǎng)易私有云的穩(wěn)定性得到了保障之后，我們開始了性能方面的調(diào)優(yōu)工作。這一方面，我們參考了 IBM 公司的一些 優(yōu)秀實(shí)踐，在 CPU、內(nèi)存、I/O 等方面做了一些配置方面的優(yōu)化。整體而言，網(wǎng)易私有云在注重穩(wěn)定性的基礎(chǔ)上，也會積極借鑒業(yè)界優(yōu)秀實(shí)踐來優(yōu)化私有云平臺的整體性能。
CPU 配置優(yōu)化
為了保障云主機(jī)的計算能力，網(wǎng)易私有云開發(fā)了 CPU QoS 技術(shù)，具體來說就是采用 cfs 的時間片均勻調(diào)度，外加 process pinning 的綁定技術(shù)。
參考 IBM 的分析，我們了解到了 process pinning 技術(shù)的優(yōu)缺點(diǎn)，并且經(jīng)過測試也驗(yàn)證了不同綁定方式的云主機(jī)間的性能存在較大的差異。比如，2 個 VCPU 分別綁定到不同 numa 節(jié)點(diǎn)的非超線程核上和分配到一對相鄰的超線程核上的性能相差有 30%~40%(通過 SPEC CPU2006 工具測試)。另一方面，CPU0 由于處理中斷請求，本身負(fù)荷就較重，不宜再用于云主機(jī)。因此，綜合上面的因素考慮以及多輪的測試驗(yàn)證，我們最終決定將 0-3 號 CPU 預(yù)留出來，然后讓云主機(jī)在剩余的 CPU 資源中由宿主機(jī)內(nèi)核去調(diào)度。最終的 CPU 配置如下所示（libvirt xml 配置）：

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

I/O 配置優(yōu)化.
1）磁盤 I/O 的配置優(yōu)化主要包含如下方面：
KVM 的 disk cache 方式：借鑒 IBM 的分析，網(wǎng)易私有云采用 none 這種 cache 方式。
disk io scheduler：目前網(wǎng)易私有云的宿主機(jī)磁盤調(diào)度策略選用的是 cfq。在實(shí)際使用過程中，我們發(fā)現(xiàn) cfq 的調(diào)度策略，對那些地低配置磁盤很容易出現(xiàn) I/O 調(diào)度隊列過長，utils 100% 的問題。后續(xù)網(wǎng)易私有云也會借鑒 IBM 的實(shí)踐，對 cfq 進(jìn)行參數(shù)調(diào)優(yōu)，以及測試 deadline 調(diào)度策略。
磁盤 I/O QoS：面對日漸突出的磁盤 I/O 資源緊缺問題，網(wǎng)易私有云開發(fā)了磁盤 I/O QoS，主要是基于 blkio cgroup 來設(shè)置其 throttle 參數(shù)來實(shí)現(xiàn)。由于 libvirt-0.9.12 版本是在 QEMU 中限制磁盤 I/O，并且存在波動問題，所以我們的實(shí)現(xiàn)是通過 Nova 執(zhí)行命令方式寫入到 cgroup 中。同時我們也開發(fā)并向 libvirt 社區(qū)提交了 blkiotune 的 throttle 接口設(shè)置 patch（已在 libvirt-1.2.2 版本中合入）來徹底解決這個問題。
2）網(wǎng)絡(luò) I/O 的配置優(yōu)化
我們主要是開啟了 vhost_net 模式，來減少網(wǎng)絡(luò)延時和增加吞吐量。

運(yùn)維經(jīng)驗(yàn)
使用經(jīng)驗(yàn)
開源軟件 bug 在所難免，但是新版本比舊版本會好用很多，尤其是對于 OpenStack 這種正在迅速成長壯大的開源軟件來說更是如此，這一點(diǎn)在我們使用過 Essex、Folsom 和 Havana 版本后深有體會，所以建議各種 OpenStack 用戶能及時的跟進(jìn)社區(qū)版本，與社區(qū)保持同步。
不要輕易的對社區(qū)版本進(jìn)行各類所謂的功能性能方面的"優(yōu)化"，尤其是在沒有與社區(qū)專家交換意見之前，千萬不要輕易下手，否則此類"優(yōu)化"極有可能演變成故障點(diǎn)或者性能瓶頸點(diǎn)，最終可能導(dǎo)致無法與社區(qū)同步，畢竟一個公司或團(tuán)隊（尤其是小公司、小團(tuán)隊）的能力和知識儲備，是很難與社區(qū)成百上千的各類專家相提并論的。
多參考各類大型公司分享的部署架構(gòu)方案，盡量不要自己閉門造車，尤其是對于開源軟件來說，各類公司、團(tuán)隊的使用場景千差萬別，各種周邊組件也是應(yīng)有盡有，多參考業(yè)界實(shí)踐是最好的方式。
一些細(xì)節(jié)實(shí)現(xiàn)可能有很多途徑，但每種方式都有優(yōu)缺點(diǎn)，需要經(jīng)過充分的論證、分析、測試驗(yàn)證后，才能考慮部署到生產(chǎn)環(huán)境使用。
所有的部署方案、功能設(shè)計都要考慮到平滑升級問題，即使你得到的信息是升級時可以停服，仍然要盡量避免這種情況，因?yàn)橥７挠绊懛秶茈y界定。
運(yùn)維準(zhǔn)則
OpenStack 也是一個后端系統(tǒng)服務(wù)，所有系統(tǒng)運(yùn)維相關(guān)的基本準(zhǔn)則都適用，這里簡單的提幾點(diǎn)實(shí)際運(yùn)維過程中根據(jù)遇到的問題總結(jié)的一些經(jīng)驗(yàn)：
配置項(xiàng)默認(rèn)值與實(shí)際環(huán)境不匹配可能導(dǎo)致各種問題，尤其是網(wǎng)絡(luò)相關(guān)配置與硬件有很強(qiáng)的關(guān)聯(lián)性，生產(chǎn)環(huán)境和開發(fā)環(huán)境硬件異構(gòu)，導(dǎo)致部分默認(rèn)值在生產(chǎn)環(huán)境不適用。應(yīng)對準(zhǔn)則：每個版本都必須在與線上硬件相同的環(huán)境測試過才能上線。
做好容量規(guī)劃，已分配的配額量要小于云平臺總?cè)萘?，否則會出現(xiàn)各種問題，導(dǎo)致運(yùn)維開發(fā)耗費(fèi)很多不必要的精力去定位分析問題。
配置項(xiàng)過多容易出錯，需要與開發(fā)人員一起仔細(xì)核對，上線時首先要通過 puppet 的 noop 功能驗(yàn)證改動是否正確后，才能真正上線。
網(wǎng)絡(luò)規(guī)劃要提前做好，如固定 IP、浮動 IP、VLAN 數(shù)量等，網(wǎng)絡(luò)擴(kuò)容難度和風(fēng)險都比較大，所以提前規(guī)劃好是最保險的，一個原則是大比小好，多比少好。
網(wǎng)絡(luò)隔離要做好，否則用戶網(wǎng)絡(luò)安全沒辦法保證。
信息安全問題要重視，這個是老生常談的問題了，每個平臺都有相同問題，但還是要重視再重視，一旦出現(xiàn)安全漏洞，所有虛擬機(jī)都面臨嚴(yán)重威脅。