Cloud OS Design Sharing

近日參與CS Design Camp，最後演講者分享如何將自己擅長的語言Ruby與CS整合的設計，聽完後個人也不禁熱血起來，在此野人獻曝個人的Cloud OS設計，以下簡稱COSM。

COSM定義：
雲計算IaaS管控平台，提供使用者簡易Web管理介面，虛擬化部分能自由選用hypervisor，整體架構符合NTIS的雲端五大特性。


COSM設計宗旨：

•  絕對彈性佈署(用戶根據運算需求快速佈署雲平台)
• 既鬆散、又耦合，功能模組化(每個模組都可以切割出去單獨販售)
• 允許動態調配資源(不中止服務)。

COSM架構將實體機分為四種角色：

Role	Description	Implementation
Web	- 操作介面 - 提供Restful API - SLB架構	Pylon、Nginx、Spring MVC
Center	- 管理節點 - 建議一個環境中起碼有兩台Center，彼此HA - 視規模可動態增加管理結點 - DB	python2.6、CentOS 5.4、Spring IoC、PostgreSQL
Host	- Support Multi-Hypervisor - 提供HA	Xen、KVM
Storage	- Share storage         - volume,存放image、vdisk、meta-data	NFS、iScsi、SAN、Fiber

COSM運作設計：

• Software-defined Cloud OS
• 每台實體機上只要有python環境，便允許執行COSM，代表他在雲中可以擔任任何角色。
•  一個安裝包，人工手動安裝CentOS於第一台實體主機，自動化script建立DB、deploy Web、啟動Main deamon。
• 搭配PXE、安裝config，除第一台主機外的上千上百台主機用Mac Address自動向Center詢問自己扮演角色，啟動COMS加入雲資源。
• 各種角色可以動態切換，例如Host資源不足，可將Storage轉乘Host。反之亦然。
• Center的HA方式：分為Master與Slave，彼此間記憶體要保持同步，彼此heartbeat，如果Slave經由double/triple check後發現Master死掉，COMS會自動選擇一台負擔較輕的Slave擔任Master。
• Host本身運行COMS與Center溝通，可做到實體機HA，當heartbeat長期沒有回應透過Center將虛擬機migrate到其他Host繼續執行。
•  Host只被某一台Center的Slave管，由Master的Center去分配隸屬。

COMS模組概述：

• CM：CloudManager，簡單來說就是整個COMS的Main
• AAA：使用者認證、授權機制，獨立模組，用IoC切割實作與API，方便介接不同公司的DB認證或LDAP。
• IR：Image Reposiroty，負責管理image，並提供上下載功能。
•  HC：hypervisor controller，提供multi-hypervisor管理，包裹libvirt、Xen API、vCenter API等實作模組為統一API讓CM用。
• HA：高可用性，行為上面寫得差不多了。
• Snapshot：三年前hypervisor這項技術支援還不夠成熟，往往snapshot的行為必須針對不同hypervisor作處理，例如KVM的VM記憶體部分libvirt就可以快照，而disk則需要透過linux指令才能做，算是比較麻煩，所以特別獨立一個模組。另外獨立出來還有一個好處是可以單獨賣，作技轉也方便。
• DB：有關SQL執行全部都放到這個模組，需要存取DB的模組都從這邊下，不讓SQL command到處塞，確保乾淨。
• Monitor：監控硬體、虛擬等資源的使用率，千萬不要跟HC或CM綁在一起，這樣才能確保未來抽換底層OS或是protocal時，只要改這邊的code就能fulfilment新環境。
• Deploy：佈署相關程式、script、設定檔都放在這裡，也能單獨賣。分為硬體佈署、Software-defined Cloud，軟體部分跟後面提到的DragonDrog呼應。被包裹出來的安裝模板OS基本上已經被minimize過，連同OS、code大概只要三百多MB。
• Web：Portal、使用者操作UI，第一面向客戶，永遠是客製化最多的地方，獨立開發。
• Restful：提供對外系統介接API。
• DragonDrog：這裡都是java script，很厲害，提供使用者一個拖拉介面，元件包含網路設備(vSwitch)、OS Type、軟體、DB，藉由一個頁面拖拉元件的方式然後一個鍵click下去產生一份XML檔，類似OVF，只是更厲害的是這份XML描述的是一整個IDC。然後deploy模組可以根據這份XML自動部屬一整個IDC。(基本上扯到IDC就太遠了，實作還沒這麼威)

COMS實作要點：

• 扯到Cloud，vendor實在太多，hypervisor有VMWare、Xen、KVM，DB免費的有MySQL、PostgreSQL，今天我們不可能為了迎合特定某一家vendor而去改程式碼，所以抽象層跟實作層在每個模組都要盡量切得很清楚，對CloudManager模組(Main)來說，假設今天他要開啟一台VM，他要呼叫的程式碼永遠只看的到startVM()這個抽象層，實作層一定是讀取某個config file或是Spring Framework提供的IoC機制，一直到instance被new出來前才會知道實作的程式是哪一支。
• 更有趣的是，由於python是script語言，甚至可以做到run time還能抽換實作層，這點很威。可參考Power of Script Language。
• 基於以上特性，不難想像這樣的設計很適合hybrid cloud。

開發環境：

• 當時設備條件匱乏，只有PC跟laptop，所以即使是storage也只能用linux架NFS來頂著用。
• 程式碼控管用Git，沒錢買TFS或ClearCase。Git雖然沒有美美的UI，但開源的它你可以針對自己需要去客製化。
• 硬體限制，基本上只要是CentOS5的HCL就能滿足。
• 好的網卡、switch很重要，是決定你開發時程上下天堂的關鍵。

精進：

• 現在會增加幾個模組，Alarm、Analyser、Buffer、QA
• 加入SDN(Software-Defined Networking)