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 數量等，網絡擴容難度和風險都比較大，因此提早規劃好是最保險的，一個原則是大比小好，多比少好。
網絡隔離要作好，不然用戶網絡安全沒辦法保證。
信息安全問題要重視，這個是老生常談的問題了，每一個平臺都有相同問題，但仍是要重視再重視，一旦出現安全漏洞，全部虛擬機都面臨嚴重威脅。