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

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

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

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

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

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

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

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

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

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

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

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