《虛擬化平臺 3.0 時代，360 依然是 OpenStack 的堅定擁護者》要點：
本文介紹了虛擬化平臺 3.0 時代，360 依然是 OpenStack 的堅定擁護者，希望對您有用。如果有疑問，可以聯系我們。

作者介紹

霍明明,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： 我們虛擬機任然存在,看業務的需求了,容器不是銀彈,有些系統不太適合或者短時間內不能容器化,這些系統還是會跑在虛擬機上的.當然,我們盡力去將業務容器化,微服務化.

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

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/2384.html