云操作系統設計漫談 |
發布時間: 2012/8/11 17:03:38 |
面對當前急速膨脹的數據存儲和處理需求,即便再強的單機(如小型機)也無法滿足,所以我們不得不借助于規模化的集群系統來處理。而如何將集群機器的計算資源和存儲資源進行合理組織、運用和調度,則是目前大中型數據中心首要面對的問題,如果解決不好不但會造成資源浪費嚴重,還會造成管理成本居高不下,尾大不掉。 本文將以我個人經驗談一談面向大型數據中心資源管理問題——我們知道單機上的硬件資源(處理器、硬盤、內存、外設等)的管理和任務調度由操作系統全面負責,那么我們放大資源管理和任務調度的范疇,從單機域擴展到整個數據中心范疇考慮,則應該存在一種能夠全局把握和管理數集群資源(與單機相比,還包括機柜、網絡設備等資源),并能負責集群范圍內任務調度的智能系統,我們不妨稱其為云操作系統——本文將重點討論云操作系統的實際目標、理念,以及可能的實現。 一、建設目標 云操作系統所要實現的目標主要有三個:一是整合資源。即整合IDC內的所有服務器資源,包括CPU、內存、磁盤等,以對外提供服務。對于大型IDC而言(服務器規模超過5000臺以上),其資源總和相當可觀,再加上資源復用運用,幾乎視為資源無限;二是資源位置透明。即所有資源位置對應用透明,應用不再關心資源位置;三是實現絕對的高可用性,永不宕機,最大程度保證數據和服務的安全性。 同時,我們在設計和實施云操作系統時,必須考慮以下理念和實際運行場景。 機器廉價化。我們云操作系統的實施前提是大規模、低成本。因此不使用專用服務器和專用存儲,而使用廉價PC服務器(所有的存儲資源將借助于機器自帶的SATA盤或者SSD盤)。設計和實施規模在上千臺到1萬臺服務器。 故障常態化。大規模地使用廉價機器(包括廉價網絡設備)無疑代表著故障頻發,對于這種系統故障常態化場景,云操作必須做到透明failover(失效轉移),才能做到高可用性。 資源池化。這點是云操作系統中最重要的理念之一,所有資源要盡量池化才能做到資源利用和復用最大化。目前看來,磁盤存儲資源可以做到完全池化——因為千兆網絡帶寬和磁盤帶寬近似,所以可將所有磁盤資源完全池化,從而每個單機上的任務可采用拉模式(pull模式)訪問集群中被池化的磁盤資源;而計算資源(CPU和內存我們都歸為計算資源)只能做到半池化——還是因為千兆網絡帶寬比內存或CPU帶寬相差多個數量級,所以無法將內存和CPU資源徹底池化。計算資源只能使用推模式(push模式)方式訪問,也就是下發任務到計算資源所在機器運行。如果是單機資源不足運行任務,則需要將大任務拆分為單機資源能滿足供給的子任務,化整為零式分布執行。 接管所有資源。理想情況下,云操作系統應盡力接管所有的資源分配和使用,包括內存、計算、I/O等。盡量避免任務直接訪問資源(如禁止執行malloc,write\read Connect等系統函數,只能使用受限的指定接口訪問資源) 應用混合部署。各種不同應用應該混合部署,機器不再被應用獨占。 應用資源訪問受限。應用訪問資源必須受限,從而避免混合部署的資源爭用,因此所有應用實例都要受節制,都需要在受限“沙箱”(“沙箱”僅僅是個邏輯概念,有很多種實現方式,例如cgroup,虛擬機等)——中運行。 應用服務上下文非本地持續化。只有保證服務上下文非本地存儲(share nothing),才能保證任務的遷移、擴展和與運行位置無關。 應用(任務)資源描述、提交、執行標準化。應用按任務方式提交給云操作系統,提交時需要描述任務中的各角色,以及各角色實例的資源配額。例如,一個key value服務角色有master role和slave role兩種,同時指明master單一實例的資源配額,slave多實例的資源賠額和實例數量。云操作系的任務調度部分,將按應用的資源描述,選擇資源配額充足的物理機啟動“沙箱”運行實例(配額限制內運行應用實例)。另外,云操作系統任務調度部分,也要支持runtime式的按需分配新的運行容器,供需要的新實例運行。例如key value的master發現slave實例數目不足時,可要求分配給其新的容器運行新slave實例子(也就是擴容)。 應用故障恢復盡量標準化,但要有所為有所不為。對于多數應用的故障恢復應實現統一化:當發現應用實例故障后,云操作系統再從資源池中分配一個運行環境加載應用實例。但允許應用自己管理failover過程。尤其對于基礎性應用,其可用性要求高,很可能需要自己采用主從熱備方式、多點提交方式或者其它“奇技淫巧“滿足可用性需求,因此對于這種智能要求高的應用,應該允許其自己接管故障恢復等行為。所以云操作系統要張弛有度,不能太集權化。 傻瓜型運維。運維人員只需要負責故障機器下架和標準機器上架。上架后保證機器自動自我配置,且在無需干預情況下自動加入集群。簡單的說,不需要IT人員駐留機房現場運維。 二、設計思路 要設計一個面向大中型數據中心的云操作系統,主要考慮以下九大功能模塊: 數據總線。數據總線是集群操作系統的基石,負責數據中心內的機器間的消息通訊。數據總線建立在TCP/UDP協議之上,實現點播、組播等功能。且滿足異步、同步消息推送、訂閱等功能。 分布式存儲系統。磁盤存儲資源池化,離不開一個分布存儲系統。該系統應該實現高可用性、高數據安全性、高吞吐和低延遲。 運行容器。負責任務運行的資源隔離服務,接管一切資源申請,避免不同任務之間的資源爭用。 駐機精靈。負責任務運行全生命周期管理,而且還要負責機器健康監測和程序下載等任務。 資源分配中心。資源分配中心管理集群中所有機器的資源信息和位置信息,并且還負責根據應用的資源請求,為其分配可用的物理機,在其上啟動運行容器,運行給定實例(也可理解為資源調度中心)。 全局命名中心。服務實例都配以全局邏輯名,各實例之間尋址都使用邏輯名。這些邏輯名和具體的物理IP和端口的映射關系管理由全局命名中心負責。 配置管理中心。配置中心為各應用實例提供了一個配置信息的集中存儲地,各應用實例不再本地存儲各自配置,而是集中存放。 分布式鎖。分布應用中難免有需要串行化完成的動作——任務需要有序執行,或者有需要保護的臨界資源——一個時刻只能一個實例訪問,這無疑需要分布式鎖支持。 故障監控服務。應用實例是否正常運行,異常情況如何發現,這些都是分布系統通用性要求,因此故障監控服務不能缺少。 云操作系統的核心部分應該就是筆者所描述的這些了。不過若要滿足前文中提到的應用服務上下文非本地存儲,那么可能還要提供一些上下文存儲需要用到的存儲服務,例如key value服務、No Sql服務、數據庫服務、graph DB等在線數據服務等,這些都應該屬于云操作系統范疇。 補充說明一下,本文中云操作并非OpenStack以及類似的私有云概念,當前的私有云概念主要面向虛擬機管理領域,而云操作系統面向的是管理IDC所有資源(池化資源、調度資源、恢復資源等)。但這并非說虛擬機和云操作系統對立,因為在我個人看來無論機器虛擬機(machine virtual machine,例如Xen,KVM)或者是系統虛擬機(system virtual machine,如Zone,vps)都可以是云操作系統中一種資源容器(沙盒),只不過這種容器相對而言很重,我們實踐中更希望借助于更輕的方式做資源容器(例如cgroup等)。 本文出自:億恩科技【www.laynepeng.cn】 |