作者介紹

霍明明，360 web 平臺部系統開發工程師。目前參與 360HULK 雲平臺容器化及虛擬化平臺相關服務建設，曾在新浪研發中心參與彈性計算平臺的建設工作。

360 內部虛擬化平臺發展階段  

（1） 第一個階段是早期虛擬化階段。在這個階段虛擬化技術相對不是特別成熟，從效能方面、硬體支援方面、技術實現等方面都相對薄弱。周邊工具也不是特別完善，整個虛擬機器效能、使用便捷性都不是特別高，正是由於這些不足 促使我們使用了最新的一些虛擬化技術棧來構建當前的虛擬化平臺，也就是 2.0 階段。

（2）這個階段，虛擬化技術日趨完善、整個的虛擬化技術棧也變得非常豐富。再加上雲端計算概念的出現，大大加快了虛擬化技術的發展。虛擬化的資源規模不斷的增大，圍繞基礎設施資源為中心的工具、平臺等都趨於完善。

（3）第三個階段是以應用為核心的階段，這也是我們目前在做的一項工作—容器化。容器化前幾年吵得比較火，目前很多企業已經開始慢慢將服務容器化，微服務化，這個也是一個行業趨勢。

當前，階段 1 的虛擬化平臺我們還在使用，很多之前的業務也都在上面執行著。但由於這個階段的虛擬化平臺功能有限：譬如機器建立速度很慢（有時建立雲主機可以達到 30 分鐘）、快照建立特別慢、宿主機故障時不支援熱遷移等等。因此，我們很需要一個性能高、建立速度快、故障時能快速遷移虛擬化平臺 — 也就是我們的 Ultron。Ultron 已成為了我們當前的主力。新的雲主機基本都是通過 Ultron 來提供的。

Ultron 簡介  

 Ultron 是什麼？

Ultron 是 360 Web 平臺部為滿足公司業務對彈性雲主機等資源需求，於 2015 年 7 月基於 OpenStack 研發的內部虛擬化 (IaaS) 平臺。Ultron 是 HULK 雲平臺的核心組成部分，致力於為公司各個業務提供高效能、穩定的適用於各種場景需求的虛擬化解決方案。

Ultron 又叫“奧創”，是美國漫威漫畫旗下的超級英雄。擁有天才級的智慧，創造性智力和自我修復能力，可以將部分或全部程式傳送到遠方的計算機系統或機器身體中，遠端控制其他機器。能夠以超人的速度準確計算和處理資訊。選擇 Ultron 作為虛擬化的專案名，就是希望我們的虛擬化平臺，能夠像 Ultron 一樣能夠控制成千上萬的機器，提供更快的計算的能力和更強大的擴縮容能力。

Ultron 最核心的功能就是給各個業務線提供虛擬機器了。

技術選型的話：

• 平臺：是 OpenStack，目前主要用到的元件有 Keystone、Glance、Nova、Neutron、Cinder
• 儲存：是本地儲存和 Ceph 共享儲存共存
• 網路：是 Vlan 模式和 Vxlan 模式混跑

在 OpenStack 的基礎上為了對接公司現有的一些系統，我們做了很多整合和定製化的工作。像公司的賬號系統、CMDB 系統、網路系統等等。這也許就是企業內部私有云都要做的一些事情吧~

Ultron 的演進

Ultron 從 2015 年 7 月份立項、技術調研、測試、管理端開發，到 11 月份上線建立第 1 臺虛擬機器我們大約花費了 4 個月的時間（在此期間，我們還開發了一套公有云平臺，後來由於某些原因放棄掉了~）。

剛開始，從穩定性和效能層面考慮，我們採用的是本地儲存 +Vlan 網路模式的方案。後來經過一段時間的調研和研究，我們又嘗試著引入了 Ceph 共享儲存和基於 Vxlan 的大二層網路，來提供一些高階的功能。然後就是整個 2016 年，我們主要是處理平臺中遇到的一些問題和做一些效能上的優化，在年底我們還做了一件“大事”，跨版本升級 OpenStack（Kilo–>Mitaka）。17 年的話，Ultron 我們沒有做太多工作，我們的工作重心轉移到了容器化上面。

Ultron 當前使用情況

（1）Ultron 目前支援公司 90% 以上的線上業務。

（2）Ultron 分佈在北京、上海、廣州、鄭州、廊坊等 9 個機房。

（3）Ultron 當前已有物理節點 1183 臺、虛擬機器 5944 臺（本地儲存和基於 Ceph 的共享儲存混跑）。

初期 Ceph 本身成熟度不是很高，鑑於對平臺穩定性及對業務負責任的態度，我們以本地儲存為主，共享儲存為輔的混跑模式。隨著 Ceph 本身的穩定和實際線上業務執行的經驗，我們覺得基於 Ceph 的共享儲存的雲主機已經可以作為主要型別來使用。後期我們資源的上線也會以共享儲存為主。

為什麼選擇 OpenStack？  

首先它是開源的。（對，這很重要。省錢哈……）

其次 OpenStack 自 2010.1 誕生以來便擔任著開源雲技術的“顏值擔當”，也是 IaaS 平臺的事實上的標準。不管是從技術的完備角度還是社群的支援力度都是其它開源雲平臺難以媲美的。經過 5 年 (截止 2015 年 7 月我們研發時) 社群的打磨，OpenStack 已經逐漸褪去最初的青澀與稚嫩，成為了全球發展最快的開源專案。OpenStack 社群成為了僅次於 Linux 的全球第二大活躍的開源社群，世界 100 強企業中近 50% 的企業採用了 OpenStack，開發者、使用者遍及全球。（其它的就不用我多解釋了，我都覺得不用它，都對不住社群。）

OpenStack 的使用  

元件

目前我們使用到的元件有：keystone、glance、cinder、nova、neutron。

邏輯架構

（1）控制節點 Active/Active 模式高可用

（2）Rabbitmq 採用 mirror 模式

（3）本地儲存虛擬機器 HA 由上層應用層決定

業務自己選擇在不同機房建立多臺，保證業務不會因機房割接等中斷

（4） 共享儲存虛擬機器 HA 既可由底層儲存保證也可由上層應用層保證，更靈活

共享儲存模式的虛擬機器在宿主機故障時可以使用熱遷移方式進行遷移和快速恢復

做的一些工作

 3.1 基於 ansible 實現平臺部署流程化，自動化，資源快速上線

初期技術調研階段，我們的部署還比較簡單、粗暴。基本上就是按照 OpenStack 官方文件一步一步的搞，部署一套測試環境非常耗時，而且非常痛苦。後來，隨著我們對 OpenStack 認識的加深，我們開始調研社群主流的自動化部署工具，像 Puppet、Fuel、Ansible 等，最終從上手速度和複雜度角度考慮，我們選擇 Ansible。

對於 OpenStak 的部署，我們分為四個部分：

（1）系統級別的初始化。主要是完成一些作業系統引數的調整、NTP 服務和網絡卡、yum 源設定等通用設定。

（2）控制節點部署。主要是完成 OpenStack 控制節點元件的安裝和配置。

（3）網路節點部署。主要是完成 OpenStack 網路元件的安裝和配置及監控代理的安裝。

（4）計算節點部署。主要是完成 OpenStack 計算元件的安裝和配置及其它輔助工具的安裝。

目前，針對 OpenStack 的部署，我們的 Ansible 大約使用了 50 個 role。

 3.2 基於 vxlan 和 ceph 的共享模式

基於 vxlan 大二層和 ceph 共享儲存，我們可以使用很多高階功能。

（1）虛擬機器秒級建立

本地儲存建立虛擬機器時需要先拉取映象到計算節點本地，如果映象比較大會比較耗時。

基於 Ceph 共享儲存虛擬機器建立時無需從 Glance 下載映象到本地，所以虛擬機器的啟動非常快。

（2）虛擬機器的秒級熱遷移

OpenStack 中支援冷遷移和熱遷移。冷遷移是將虛擬機器磁碟資料和配置通過網路拷貝到新的計算節點。我們知道虛擬機器磁碟資料一般都比較大幾十 GB 到幾百 GB 不等，所以該過程非常耗時且消耗頻寬，個人感覺其應用價值不大。而熱遷移通過利用 vxlan 大二層和共享儲存的優勢，“無需”拷貝虛擬機器磁碟資料，只需拷貝少量記憶體資料和虛擬機器配置到新的節點即可，整個過程非常快，以秒計，而且虛擬機器網路不中斷，內部業務無影響。

通過熱遷移我麼可以在計算節點故障時將雲主機快速遷移，保證業務不中斷；通過熱遷移我們還可以在計算節點資源緊張時將虛擬機器遷移到資源充足的節點，減少因資源徵用對業務的影響。

（3）虛擬機器分鐘級別建立快照

與本地儲存相比，基於 Ceph 的共享儲存的虛擬機器在建立快照時，無需快照上傳的過程。整個過程全部在 Ceph 端完成，所以速度上要遠遠地快於本地儲存。

虛擬機器高可用

Ceph 資料三副本機制，一方面保證了虛擬機器資料丟失的可能性大大降低；另一方面當虛擬機器所在計算節點故障時，虛擬機器的資料任然在 Ceph 共享儲存中，可以很快的在其它計算節點重新啟動虛擬機器，保證虛擬機器“不丟失”，可恢復。

 3.3 監控

對 OpenStack 我們主要是做了三方面的監控：

（1）基於公司現有的監控系統 Wonder 實現對節點 OS 級別監控。

像節點的 CPU、記憶體、磁碟、網路、存活等基礎監控都是通過 Wonder 來實現收集和報警。有關 Wonder 我們之前有過詳細的介紹，感興趣的移步這裡 http://www.infoq.com/cn/articles/360-wonder-monitoring-system

（2）基於開源監控二次開發，實現對 OpenStack 元件存活的監控。

Wonder 實現了 OS 層面的監控，對於 OpenStack 元件的存活和其是否正常工作也是我們非常關心的，經過調研我們通過對社群開源的監控元件進行二次開發，然後對接 Wonder 實現。該監控不僅僅是元件的存活，我們還模擬使用者真實操作，呼叫 OpenStack Api 實現資源檢視、建立等基本操作來監控元件是否正常工作。

（3）基於 ELK 實現對 OpenStack 元件的日誌監控。

有時候，系統狀態正常、OpenStack 程序也是存活的，資源增刪也是 OK，但是由於是 Active/Active 模式，其中一個 controller 服務或者 agent 服務有問題，我們也檢測不到；特別是計算節點眾多，某個 nova-compute、libvirt 元件有問題，我們不能第一時間發現。作為運維我們是不能忍的。怎麼辦呢？有問題查日誌，這是我們技術人員定位問題的第一法寶，因此，通過 ELK 對節點上日誌的收集與分析來監控服務的健康狀況是非常必要的。

在近 2 年的時間內，通過 ELK 對日誌的監控、分析我們及時發現的問題舉例：

Libvirt 證書過期

Rbd 連線異常

元件連線 rabbitmq 異常

虛擬機器建立失敗

……

 3.4 壓測

引入 Rally 框架對平臺進行基本功能測試和併發效能測試等。

任何系統上線前肯定都要經過各種測試，以便管理員對其穩定性和效能有個清晰的認識。對於當前資源池能夠支援的量和後期的資源規劃都非常有幫助。鑑於此，我們在平臺上線前也對其進行了一定程度的測試。

3.5 調優

我們也參考社群對平臺進行了一系列的調優。

（1）超賣。目前只超賣 CPU，記憶體和磁碟都不超賣。根據我們實際線上跑的情況，超賣記憶體會經常出現虛擬機器 OOM 的問題 、超賣磁碟會出現宿主機磁碟滿的問題。

（2）NUMA。我們都知道 NUMA 架構每個處理器都可以訪問自己和別的處理器的儲存器，訪問自己的儲存器要比訪問別的儲存器的快很多，NUMA 調優的目標就是讓處理器儘量的訪問自己的儲存器，提高 cache 的命中率，提高處理速度。在 Kilo 版本中 OpenStack 已經開始了對 NUMA 的支援，Mitaka 版本中支援的更加完善。

（3）KSM。核心共享儲存，該特性可以使得不同的處理器共享相同內容的記憶體頁。核心會主動掃描記憶體，合併內容相同的記憶體頁。如果有處理器改變這個共享的記憶體頁時，會採用寫時複製的方式寫入新的記憶體頁。當一臺主機上的多臺虛擬機器使用相同作業系統或者虛擬機器使用很多相同內容記憶體頁時，KSM 可以顯著提高記憶體的利用率。因為記憶體掃描的消耗，使用 KSM 的代價是增加了 CPU 的負載，並且如果虛擬機器突然做寫操作時，會引發大量共享的頁面，此時會存在潛在的記憶體壓力峰值，超過一定的水平限制，將會引發大量不可預知的 swap 操作，甚至引發 OOM。因為，其比較消耗 CPU，所以我們預設是給它關閉的，只有當節點記憶體壓力較大時，用來合併記憶體，來增加記憶體的可用空間。

（4）DPDK。引入 DPDK 技術，來提高虛擬機器資料包的處理速度和吞吐量。

（5）Ceph 的一系列調優。像使用 rbd cache、cache tier 等。

 3.6 跨版本升級

平臺最初使用的是 Kilo 版本，為了使用一些高階功能（像 DPDK），我們在 16 年底對所有機房進行了跨版本升級，跨過 Liberty 直接升級到 Mitaka。在整個升級過程中遇到了不少坑（像 RPC 版本不相容問題、kombu 庫依賴版本不匹配問題、之前新增的 patch 與新版本整合等）

一些經驗  

1. 合理規劃資源邏輯區域，資源排程更靈活
2. 外界限制，從軟體角度加以規避，加快專案進度（主要是與公司內部現有周邊系統整合的限制）
3. 基礎服務、ELK 日誌監控，ansible 部署，提高運維效率（工具要到位，減少無畏的人為勞動）
4. 限制虛擬機器建立、啟動併發量，避免啟動風暴
5. 規劃儲存需要根據線上業務建立模型評估效能、容量、規模
6. 超賣等設定合理，磁碟是問題（qcow2 格式虛擬機器磁碟使用率很低、 xfs 碎片激增導致虛擬機器 qemu 程序成為殭屍程序）
7. RabbitMQ 與 erlang 版本匹配（版本不匹配會造成記憶體吃的非常厲害，最終導致宿主機宕機。我們當前使用的 rabbitmq-server-3.6.1-1、erlang-R16B-03.11，目前執行良好）

QA 環節 

   Q1： 使用 DPDK 後，在 VXLAN 模式，萬兆網絡卡能跑到多大頻寬？

A1：這裡虛擬機器理論頻寬是可以跑滿宿主機網絡卡頻寬的，DPDK 在一定程度上瓶頸在於 CPU 上或者說在小包的處理能力上目前我們測試的幾個點

(1). 以 64byte 最小包做測試，1GB 網絡卡，PPS（packet per second）的理論上限是：148.8 萬包 / 每秒

(2). 核心的 vhost-net 下，虛擬機器的 1GB 網絡卡只能達到約 17 萬

(3). ovs-dpdk 下，虛擬機器的 1GB 網絡卡，達到了 126 萬，幾乎達到理論峰值（沒有達到，還有可能 CPU 已經是瓶頸了）(4). ovs-dpdk 是 vhost-net 大約 7 倍的效能

Q2：計算節點大規模部署時，是否劃分了 Region，AZ 之類？網路節點是否會限制整個叢集的效能？對於東西向流量較大時

A2：我們是做了劃分的，目前我們每個機房一個 region，這些 region 公用一個 keystone。

Q3： ELK 監控小技巧相關，比如說，nova-api 報 error，ELK 通過哪些手段發給運維，傳送哪些內容？包括具體日誌嗎？

A3：我們當前其實做的還比較簡單， 匹配 error 資訊後，我們會將整個丟擲的異常棧日誌資訊通過郵件的形式傳送出來。

Q4 ：關於儲存，有沒有考慮使用傳統的企業級儲存，比如 San nas 等，這些儲存也穩定，還有重刪壓縮功能，比多副本更高的磁碟利用率。

A4： 這個更多的是要看公司對儲存的 cover 的能力和成本的考慮吧。 再就是對於和 OpenStack 結合而言，沒有比 Ceph 更合適的了.

 Q5：Ultron 的版本升級頻率是如何的？

A5： 我們是功能驅動的，如果新版本沒有我們需要的功能，我們也不會做升級。目前我們做了一個跨版本的升級，當前是 Mitaka 版本。

Q6：為什麼用 RabbitMQ ，而不是其他呢？有麼有哪些使用的坑

A6： 哈，這個問題。 首先 RabbitMQ 是官方預設的訊息佇列元件（剛開始也沒得選）；其次 rabbitmq 效能、穩定性等都能夠扛得住當前的規模具體坑的話：

1. erlang 和 rabbitmq 的版本要匹配
2. 網路分割槽問題
3. 記憶體瘋長問題（也是由於版本不匹配導致）

Q7：OpenStack 有哪些缺點？似乎很多人並不是很看好？

A7： 這個話題比較大，不便細說     但是“似乎很多人並不是很看好？” 這個觀點不知道從哪來的, 當前全球百強企業 50% 左右都已經使用了~

 Q8：一個 region 最多承載了多少臺節點？所有機房之間是通過什麼線路互聯的，延時有多大？

A8： 一個 region 最多承載多少臺節點，這個要看多個方面：你的網路架構是什麼樣的？儲存模式等等。當前我們最大的 region 有接近 400 個計算節點（當然，還會繼續增長）

 Q9：所有 region 共用一個 keystone 的話，keystone 壓力會不會太大了，擴充套件性如何保障？

A9： 目前我們是 9 個 region，兩個 keystone 節點，執行良好（keystone 支援多種 token 的生成方式，選擇一個最合適的）。擴充套件的話，加節點唄。我們使用 OpenStack 就是建立虛擬機器，頻率不是非常高的話，keystone 的壓力並沒有很大。

 Q10：想問下 360 目前有沒有虛擬機器和容器混合使用的需求？以及目前結合使用的方式。

A10：主要 3 個階段吧，最早的時候是把容器當虛擬機器用，然後是將容器跑在業務申請的虛擬機器裡面的，目前我們是將容器直接跑在物理機上的。

 Q11：mysql 用的是多活模式，還是主備模式呢？

A11：後者，其實資料庫部分我們是不關心的，我們有強大的 DBA 團隊，我們只管用~ 哈哈 (DBA 很貼心的)

 Q12：Openstack 和 cloudstack 有什麼區別？Openstack 和 cloudstack 做雲，誰更有優勢？

A12： 兩者都是雲管理平臺~，且都是開源的。就成熟度而言 cloudstack 可能略高（畢竟最初是商用產品），不過 OpenStack 發展到現在也已經非常成熟了。具體使用哪個要根據企業的實際需求。

Q13：keystone 的 token 用的是 uuid 方式嗎？

A13： 對，目前我們是 uuid。

Q14：請問在階段 3 中以應用為核心的 3.0 平臺當中，是否虛擬機器就不存在了，應用全部跑在容器上？

14： 我們虛擬機器任然存在，看業務的需求了，容器不是銀彈，有些系統不太適合或者短時間內不能容器化，這些系統還是會跑在虛擬機器上的。當然，我們盡力去將業務容器化，微服務化。

文章來源微信公眾號：高效運維開發