日前CSDN[問底]欄目發(fā)表了麒麟云平臺團隊的專欄文章，分享了團隊在天河二號千節(jié)點規(guī)模上進行大規(guī)模部署的實踐經(jīng)驗，并介紹了基于OpenStack構(gòu)建企業(yè)級解決方案KylinCloud上所取得的進展。原文如下：

       OpenStack正在成為事實上的IaaS標準，其本身的設(shè)計架構(gòu)賦予了其高度的可擴展性。盡管如此，在千節(jié)點量級的大規(guī)模部署中，仍然有許多因 素決定了實際實施中需要在整體架構(gòu)和細節(jié)優(yōu)化上進行多方面的嘗試與探索。本文分享在天河二號千節(jié)點規(guī)模上進行大規(guī)模部署的實踐經(jīng)驗，并介紹團隊在基于 OpenStack構(gòu)建企業(yè)級解決方案KylinCloud上所取得的進展。

OpenStack大規(guī)模部署所遭遇的挑戰(zhàn)

       隨著本身不斷的成熟及在多個生產(chǎn)環(huán)境中的成功應(yīng)用，開放、開源的云服務(wù)平臺OpenStack正在成為事實上的IaaS標準。在其官方的介紹中，易 于實施（Simple to Implement）、高可擴展（Massively Scalable）和特性豐富（Feature Rich）是主要的 特色，這得益于OpenStack本身松耦合的架構(gòu)設(shè)計、活躍且強有力的社區(qū)貢獻和不斷成熟的生態(tài)圈。

       然而，需要管理數(shù)據(jù)中心千以上的物理節(jié)點時，如基于OpenStack構(gòu)建公有云，如何發(fā)揮OpenStack的可擴展性優(yōu)勢提供穩(wěn)定、高效的服務(wù)，仍然有許多因素需要考慮，其主要的挑戰(zhàn)主要來自以下兩個方面：

• OpenStack本身的因素：由于定位在松耦合、功能豐富，OpenStack所包含的組件在多個開源平臺里面是相對較 多的，當前的最新版Juno的組件數(shù)為11，即將發(fā)布的Kilo會達到12（包含Ironic），而且這個數(shù)字可能還在繼續(xù)增長；同時，各個組件間存在依 賴關(guān)系，如每個組件都會依賴Keystone，Nova還依賴于Glance、Neutron和Cinder；此外，多個組件，如Neutron、 Cinder和Glance還存在多種存儲后端實現(xiàn)機制，以實現(xiàn)對各種部署環(huán)境的靈活支持；最后，每個組件都有大量的配置文件，而每個配置文件又有大量的 配置選項用于對系統(tǒng)進行定制與優(yōu)化；
• 部署環(huán)境的因素：在數(shù)據(jù)中心中，物理節(jié)點數(shù)目達到一定量級之后其本身的運維會面臨部署配置復(fù)雜、調(diào)試困難等因素，僅OS安 裝及軟件包的部署與維護就帶來很大的工作量；同時硬件故障率、網(wǎng)絡(luò)壓力、數(shù)據(jù)庫壓力甚至日志壓力都給OpenStack的部署帶來諸多挑戰(zhàn)，典型的表現(xiàn)之 一是消息超時、響應(yīng)變慢等問題。

天河二號的云計算需求

       在世界超算Top500排名中取得四連冠的天河二號已經(jīng)于2014年初部署在國家超算廣州中心并對外提供服務(wù)。與已有超級計算機系統(tǒng)的一個重要區(qū)別 是，天河二號不僅僅定位在高性能計算，而是通過異構(gòu)多態(tài)的體系結(jié)構(gòu)設(shè)計與實現(xiàn)，期望能夠為廣州市、廣東省甚至更大范圍的政府部門和企事業(yè)單位的信息化建設(shè) 和大數(shù)據(jù)處理提供強有力的資源支撐。

圖1 天河二號

      為了滿足信息化和數(shù)據(jù)處理類應(yīng)用對按需、彈性計算資源的需求，天河二號的軟件體系中融合了當前不斷成熟與普及的云計算模式。經(jīng)過比較與測試，研發(fā)團 隊選取了具有良好擴展性和社區(qū)基礎(chǔ)的OpenStack作為軟件棧的組成部分。本文再現(xiàn)了在天河二號千節(jié)點規(guī)模上進行OpenStack大規(guī)模部署的一次 試驗。

軟硬件配置

      在開始之前，簡單介紹一下此次部署的軟硬件配置。

     硬件：天河二號定制刀片，每個節(jié)點配有雙路12核CPU，64GB內(nèi)存，兩塊千兆網(wǎng)卡、一塊THNI高速網(wǎng)卡以及一塊1TB的SATA本地硬盤；

軟件的具體版本信息如下：

• OpenStack ─ IceHouse （2014.1）；
• OS ─ 內(nèi)核為3.8.0的Ubuntu Server 12.04；
• Ceph ─ 0.67.0，用于提供后端存儲，取代Swift；
• Puppet ─ 2.7.11，實現(xiàn)自動化的部署與配置；
• Rabbitmq ─3.24，缺省的消息隊列；
• MySQL ─ Ver 15.1 Distrib 5.5.35-MariaDB，OpenStack的后臺支撐數(shù)據(jù)庫；
• kvm ─ QEMU emulator version 1.7.91，以KVM作為底層的虛擬化機制；
• libvirt ─ 1.2.2，虛擬化層接口；
• OpenvSwitch ─ 2.0.1，虛擬機網(wǎng)絡(luò)的管理后端。

部署架構(gòu)

      為了實現(xiàn)OpenStack千級節(jié)點的部署，經(jīng)過調(diào)研和嘗試，在確定其架構(gòu)時確定了如下五個重要的選擇：

     使用Cell進行邏輯劃分。OpenStack中使用Cell來解決可擴展性和規(guī)模瓶頸，實現(xiàn)對橫向擴展和大規(guī)模部署的支持。 Cell在Grizzly版本引入，并不斷成熟。前面提到，OpenStack由多個松耦合的組件構(gòu)成，當達到一定的規(guī)模后，某些模塊將成為整個系統(tǒng)的瓶 頸。Cell以樹型結(jié)構(gòu)為基礎(chǔ)，主要包括根Cell（API-Cell）與子Cell（ Child-Cell） 兩種形式，子Cell可以嵌套。根Cell 運行 nova-api 服務(wù)，每個子Cell 運行除 nova-api 外的所有 nova-*服務(wù)以及nova-cells服務(wù)，并具有自己的數(shù)據(jù)庫和消息隊列、數(shù)據(jù)庫。同時，樹形結(jié)構(gòu)引入了分級調(diào)度的概念，即調(diào)度某個虛擬機的時候先 要進行Cell的選擇，可以有多種調(diào)度策略。父Cell會將消息路由到子Cell的消息隊列，同時，子Cell定時的將自己的資源信息上報給父Cell， 用來給分級調(diào)度策略提供決策數(shù)據(jù)和基于Cell的資源監(jiān)控，Cell之間的通信通過rpc完成。

      采用無盤方式部署系統(tǒng)。由于節(jié)點規(guī)模龐大，同時存在一定的故障率，為了提高部署效率，減輕系統(tǒng)維護與軟件包升級的開銷，全系統(tǒng)采用無 盤方式部署。將OpenStack相關(guān)的包與操作系統(tǒng)定制為一個鏡像，節(jié)點重啟時會自動從無盤服務(wù)器拉取鏡像。同時，鏡像中打入了一些自動化的腳本用于完 成基本的環(huán)境配置，如初次啟動時的硬盤分區(qū)、IP地址和hostname的確定與寫入、無密碼SSH等。

      采用Puppet實現(xiàn)節(jié)點服務(wù)的自動好配置。以無盤的方式部署系統(tǒng)后，各個節(jié)點可以看作是同質(zhì)的。為了實現(xiàn)對OpenStack各個 服務(wù)的配置，使用Puppet來完成各個配置文件、配置項的設(shè)置以及服務(wù)的啟動。首先定義每個節(jié)點的角色，并為每個角色與角色之間的關(guān)系定義相應(yīng)的配置腳 本，進行配置時，每個Puppet 客戶端會到服務(wù)器端去獲取自己的角色和相應(yīng)的腳本，然后加以執(zhí)行。

      使用Ceph RBD卷作為統(tǒng)一的存儲后端，實現(xiàn)鏡像存儲、邏輯卷和虛擬機啟動（Boot-from-Volume）。采用分布式存 儲Ceph主要基于三方面的考慮：一是Ceph架構(gòu)本身具有的可擴展性、可靠性與高性能，同時其RBD功能已經(jīng)相對成熟；二是實驗環(huán)境的每個節(jié)點都具有一 塊1TB的SATA盤，在不考慮使用成本較高的集中式存儲的前提下，使用Ceph把這些本地盤利用起來具有相當大的吸引力；三，尤為重要的是，Ceph一 直與OpenStack保持良好的合作關(guān)系，能夠很好的支持OpenStack多個組件對存儲后端的支持。另外，統(tǒng)一采用Ceph RBD卷作為存儲后端，能夠?qū)崿F(xiàn)低開銷的虛擬機遷移并降低對空間的使用率。

      管理網(wǎng)、業(yè)務(wù)網(wǎng)與存儲網(wǎng)絡(luò)分離。即充分使用每個節(jié)點的三塊網(wǎng)卡，兩塊以太網(wǎng)卡分別用于管理網(wǎng)絡(luò)和虛擬機業(yè)務(wù)網(wǎng)，THNI高速網(wǎng)用于Ceph，實現(xiàn)網(wǎng)絡(luò)的流量隔離，并提高存儲的訪問帶寬。

      基于以上考慮，在實際部署方案中，采用了如下的部署架構(gòu)：

1. 128個控制節(jié)點，包括：

• 8個nova控制節(jié)點：運行nova-api和nova-cells；
• 8個鏡像服務(wù)節(jié)點：運行g(shù)lance-*服務(wù)；
• 8個卷服務(wù)節(jié)點：運行cinder-*服務(wù)；
• 8個網(wǎng)絡(luò)控制節(jié)點：運行neutron-server服務(wù)；
• 16個網(wǎng)絡(luò)服務(wù)節(jié)點：運行neutron-*-agent服務(wù)；
• 8個認證服務(wù)節(jié)點：運行keystone服務(wù)；
• 6個消息隊列的節(jié)點：，運行Rabbitmq；
• 6個數(shù)據(jù)庫的節(jié)點：運行MySQL；
• 4個負載均衡節(jié)點，采用LVS+Keepalived實現(xiàn)API節(jié)點的調(diào)度分發(fā)與高可用；
• 2個Horizon節(jié)點；
• 8個ceph 監(jiān)控節(jié)點，運行ceph mon服務(wù)；
• 16個監(jiān)控節(jié)點：為了實現(xiàn)對當前系統(tǒng)狀態(tài)的監(jiān)控與報警，還部署了16個節(jié)點用作Ganglia和Nagios的服務(wù)器端；
• 其余節(jié)點作為備用節(jié)點。

      2. 8個Cell的計算節(jié)點，每個Cell包含128個節(jié)點，包含2個Cell Server節(jié)點（運行除nova-api之外的nova-*服務(wù)、nova-cells、消息隊列和數(shù)據(jù)庫）和126個計算節(jié)點，每個計算節(jié)點同時運行ceph的osd服務(wù)。

      大致的部署圖如下：

圖2 千節(jié)點規(guī)模部署的拓撲圖

性能優(yōu)化措施

       在系統(tǒng)部署完畢之后，為了適應(yīng)管理和調(diào)度物理節(jié)點和虛擬機的需要，需要針對相關(guān)的服務(wù)進行參數(shù)調(diào)優(yōu)，在此給出主要的一些配置。

      1. 在多個物理節(jié)點上配置各類*-api服務(wù)，并進行負載均衡，主要包括nova-api、cinder-api、glance-api等，用于增加請求的響應(yīng)能力；

      2. 為Neutron配置獨立的Keystone服務(wù)。經(jīng)觀察發(fā)現(xiàn)，Neutron需要頻繁的認證，為此，為其配置獨立的Keystone，但數(shù)據(jù)庫共用，從而保證Keystone的最大并發(fā)響應(yīng)數(shù)；

      3. 通過開啟服務(wù)的多進程模式提高響應(yīng)能力：主要包括兩類，一類是設(shè)置相關(guān)服務(wù)配置中的worker的數(shù)目，包括Neutron- server中的api_works、nova-api中的osapi_compute_workers、metadata_workers和 ec2_workers、nova-conductor中的workers、glance-api和cinder-api中的workers配置項等；第 二類是將服務(wù)進行Apache托管，使用Apache的多進程機制增加服務(wù)能力，主要包括Keystone和Puppet Master兩個服務(wù)；

      4. 服務(wù)的性能參數(shù)調(diào)整，增強每個服務(wù)進程的處理能力。

其中Nova涉及到的參數(shù)如下：

• api_rate_limit，將其設(shè)置為false，取消限制；
• 使用較大的數(shù)據(jù)庫連接池：主要包括min_pool_size、max_pool_size和max_overflow等參數(shù)；

Neutron涉及到的參數(shù)如下： 

• 使用較大的數(shù)據(jù)庫連接池：主要包括min_pool_size、max_pool_size和max_overflow等參數(shù)；
• agent_down_time：但有數(shù)目較多的Agent運行時，允許更多Agent出現(xiàn)故障；

消息隊列Rabbitmq涉及到的參數(shù)如下：

• rabbitmqctl set_vm_memory_high_watermark：允許Rabbitmq使用更多內(nèi)存來響應(yīng)連接；
• ulimit -n：設(shè)置較大的socket限制以承載更大的負載；
• 使用Rabbitmq集群機制實現(xiàn)消息隊列壓力的分攤；

MySQL涉及到的參數(shù)如下：

• max_connections：使用更大的最大連接數(shù)；
• 使用Galera Mysql 集群技術(shù)提高MySQL的性能和可用性。

另外一些服務(wù)適當?shù)姆艑捚涑瑫r時間設(shè)置，防止由于規(guī)模過大、節(jié)點數(shù)多引起的超時導(dǎo)致服務(wù)無法響應(yīng)，主要包括兩個參數(shù)：

• neutron_url_timeout：Neutron服務(wù)的響應(yīng)時間限制；
• rpc_response_timeout：RPC響應(yīng)時間顯示；

最后，在每個節(jié)點KVM的配置進行調(diào)整，主要包括KSM（重復(fù)頁去重）、虛擬內(nèi)存比例調(diào)整、使用virtio_blk提高IO性能以及設(shè)置I/O的調(diào)度策略為Deadline等。

實際運行情況

       在上述的架構(gòu)和優(yōu)化下，實現(xiàn)了對共計1152個物理節(jié)點的大規(guī)模OpenStack的部署。為了驗證此部署的能力，使用測試鏡像Cirros、以最小配置（1 vCPU、512MB內(nèi)存）進行啟動虛擬機和查詢虛擬機的測試。結(jié)果顯示，能夠一次同時啟動的虛擬機的數(shù)據(jù)為5000個左右，且大部分時間耗費在調(diào)度上；每秒可以實現(xiàn)1000個虛擬機的查詢操作。后續(xù)需要根據(jù)分析的性能瓶頸進行進一步的探索與優(yōu)化。

基于OpenStack打造高效安全的企業(yè)云服務(wù)平臺

       在以上部署實踐的基礎(chǔ)上，天河二號的云平臺研發(fā)團隊深入到OpenStack源代碼內(nèi)部，圍繞遇到的問題和需求開發(fā)了一系列新特性和大量的Bug修 復(fù)，并積極反饋給社區(qū)。2012年以來團隊向社區(qū)貢獻了大量代碼，并在最新的Juno核心組件的代碼貢獻（commit數(shù)目）位居國內(nèi)第二位。

同時，圍繞著充分發(fā)揮天河二號的性能優(yōu)勢、為中小企業(yè)提供安全、高可用、彈性的高品質(zhì)服務(wù)這一目標，團隊基于OpenStack進行了一系列深入的 產(chǎn)品化定制與改造，形成了獨立的云服務(wù)解決方案KylinCloud─麒麟云平臺。麒麟云平臺采用互聯(lián)網(wǎng)自助服務(wù)的模式，面向企事業(yè)單位提供IaaS和 PaaS層的IT服務(wù)，希望成為小微企業(yè)的IT服務(wù)的承載平臺，并基于此構(gòu)建完善的IT服務(wù)生態(tài)環(huán)境。

圖3 麒麟云平臺的特色之處

      目前，麒麟云平臺已經(jīng)穩(wěn)定運行在天河二號上，在用戶單位的配合與支持下，已經(jīng)適配了廣州市電子政務(wù)中心、廣州市蘿崗區(qū)的若干電子政務(wù)系統(tǒng)的 部署和運行；同時，作為廣東省省級教育數(shù)據(jù)中心的主要資源池，將為各類教育管理系統(tǒng)提供所需的計算和存儲資源，已經(jīng)部署上線了多個信息管理系統(tǒng)；此外，麒 麟云平臺已經(jīng)在為幾十家中小企業(yè)提供服務(wù)，如支持企業(yè)客戶的信息服務(wù)托管以及基于互聯(lián)網(wǎng)的智能銷售等行業(yè)服務(wù)，又如依托天河二號的強大計算能力為動漫產(chǎn)業(yè) 提供海量的計算資源，目前正在支持華強、紅鵬、創(chuàng)意云等多個用戶的渲染業(yè)務(wù)，其中華強高性能渲染虛擬機集群的最大規(guī)模達到千個物理節(jié)點規(guī)模，已經(jīng)在支撐其 生產(chǎn)系統(tǒng)。麒麟云平臺在廣州市電子政務(wù)和華強文化等單位和企業(yè)的成功應(yīng)用已經(jīng)驗證了其基于天河二號提供云服務(wù)的可用性、可靠性和可擴展性，為超級計算機系 統(tǒng)的應(yīng)用開拓了一條嶄新的途徑。

同時，研發(fā)團隊也在努力構(gòu)建面向商用硬件的完整解決方案，面向不同用戶、不同應(yīng)用的需求，提供深度定制、安全、可靠的云服務(wù)。此外，麒麟云平臺正在與國內(nèi)著名安全系統(tǒng)解決方案提供商合作，對麒麟云平臺的系統(tǒng)安全、平臺安全和虛擬機安全進行全方位的定制與增強。