SmartOS簡介

原文連結：http://www.programmer.com.cn/14134/   原文標題為“NodeStack：另類的開源雲端運算組合”

作者：程顯峰

轉載Babyfacer註：總部在香港的“風起亞洲”(Fengqi.Asia)公用雲端平台即是基於Joyent的SmartOS建立。我暫時沒時間寫（或翻譯）相關的技術文章，先轉載一篇至此。希望與各位對Joyent技術有興趣的朋友們多交流。我的個人Email是 michaelcxw(AT)gmail.com

NodeStack是另類的開源雲端運算組合，從內到外實現了應用PaaS。其架構主要包括SmartOS、Node.js和MongoDB三部分。本文將重點介紹NodeStack的底層平台SmartOS。

最近談到開源雲端運算，大家可能第一想到的是OpenStack、Cloud Foundry這種金光閃耀的組合。但NodeStack的發布，使得大家眼前一亮——原來可以這麼玩。簡單地說，NodeStack使用了一套完全不同的開源架構，從內到外實現了應用PaaS。其架構主要包括SmartOS、Node.js和MongoDB。由於這幾種技術的東家都參與了這個項目，我們就來看看NodeStack到底有什麼神奇的地方。

先來簡單介紹一下出場的各位玩家。

• Joyent，JavaScript的東家。有趣的是這個公司的主營業務是IaaS，其核心技術在於SmartOS—一種與時俱進的Solaris。
• Nodejitsu，JavaScript社區的核心玩家。公司的目標是做一個基於Node.js的PaaS平台。
• 10gen，MongoDB的東家。
• MongoLab，MongoDB雲端服務的供應商。

Joyent 在這個體系當中提供最為基礎的計算和儲存資源，很多人可能認為這和其他提供IaaS的公司沒什麼兩樣。其實不然，Joyent的雲從某種角度上來說並不完 備。但依我看，這個雲真的就是為做PaaS而裁剪的，特別合體。SmartOS的種種特性，真的令人讚歎：原來PaaS的底層應該是這樣的。

Nodejitsu 所做的工作就是用Joyent提供的計算和儲存資源，做一個專門針對Node.js應用的PaaS。這個開源PaaS的原始碼可以從GitHub上擷取。 應用肯定是少不了資料的，一個時髦的資料庫服務也是必不可少的，甚至有人將資料庫服務稱為DBaaS。MongoLab就是將10gen的MongoDB 做成了雲端服務，按量收錢，因此成為PaaS中強有力的組件。

本文將重點介紹底層平台SmartOS。後面我會陸續寫文章介紹開源PaaS平台和MongoDB雲端服務。

Nodestack的整體架構

SmartOS

為什麼Joyent要使用Solaris？Solaris開源嗎？不是掛掉了嗎？

要是大家知道誰為Joyent工作或許就不會有這樣的疑問了。Bryan Cantrill是Joyent現在的工程副總裁。作為原來Sun的傑出工程師，他設計並實現了DTrace，被MIT的《技術評論》評為“35才俊”（TR35）。

Brendan Gregg現在是Joyent的首席效能工程師。他是《DTrace》那本巨著的主要作者。此外，他還參與了《Solaris Performance and Tools》一書的撰寫。作為DTrace工具包的開發人員，他在Sun工作時曾參與了大量的Solaris效能最佳化項目，是這個星球上最懂效能最佳化的工程 師之一。

Sun開放了OpenSolaris，本以為Solaris那些閃耀的技術會對社區產生深遠的影響。不曾想好景不長，在被 Oracle收購之後，Sun改變了對待社區的態度，不再支援OpenSolaris項目了。然而，很多Solaris的團隊成員並不接受這種安排，繼續 維護了一個叫做Illumos的項目，使得開源的Solaris核心得以繼續維護。

好在Sun當時已開放了好多代碼，基礎已相當不錯。我認為有點可惜的是，Sun當時的編譯器體系並沒有開放出來，其中的編譯器、最佳化器、效能分析器和調試器都是業界一流水準的作品。但做人要厚道，不能貪求太多，讓我們著眼於已開放的那一部分吧。

Sun這家公司，你說它有先見之明也好，說它過於超前也好。以當今雲端運算大潮的視角來看，能看準這些方向的公司實在是太有眼光了，主要體現為ZFS彪悍的檔案系 統（其實說它是檔案系統本身就是對ZFS的一種侮辱，它還有卷管理）、Zone作業系統層的虛擬化技術、Crossbow網路虛擬化組件以及DTrace 超級調試工具。甚至有Solaris忠粉說，Linux的Btrfs、LXC、Open vSwitch、SystemTap就是對Solaris上述技術的山寨。山寨與否可能無從考證，看來大家對技術趨勢看法比較一致。我認為，這些技術也是 雲端運算技術拆解的一個縮影。

Joyent認為，Solaris這些特性簡直就是為其IaaS而打造的，因此堅定地將方向鎖定在這個看似不怎 麼閃耀的系統上。它不但招聘了大量原來Sun公司的工程師，還積極投身到Illumos這個項目上。但僅有Illumos遠遠不夠，它只維護了一個非常核 心的核心，距離發行版還有一段距離。Joyent並沒有採用已有的基於Illumos的發行版，比如OpenIndian，而是根據自己的需要做了一個， 這就是SmartOS。要說SmartOS和別的發行版最明顯的不同，那一定是KVM了。對，你看得沒錯。SmartOS將Linux的KVM移植到了 Solaris上。我不知道Joyent這些天才工程師是如何做到的，但他們的確做到了。

綜合來看，SmartOS是一個非常有特點的發行版。SmartOS的定位就是做Hypervisor，甚至這個發行版不提供安裝功能，只提供一個LiveCD鏡像。開始時，我對此也非常不理解，後來慢慢發現這也是一個非常不錯的想法。

這樣無論使用網路啟動，還是USB引導，只要使用的LiveCD是一樣的，起來的系統就是完全一樣的。這個看上去沒什麼，但如果大家管理的機器數目眾多，很 少有人能保證系統是完全一樣的。作為Hypervisor的所有軟體都在SmartOS內部提供了，結果給各種軟體版本依賴性造成了衝突，也就是說升級新 版本失敗了，大不了換回老的鏡像，不會出現“升級崩潰”現象。當然，這種LiveCD的設計相對來講只能算雕蟲小技，遠不能與其最核心的四大亮點相比，即 KVM、Zones、DTrace和ZFS。

KVM

KVM是開源虛擬化的一面旗幟。但提到KVM，就不得不提到它的對手 ——Xen。似乎在相當長的一段時間，選擇Xen還是KVM引起了很大的爭議。Xen的勢力非常強大，現在比較彪悍的虛擬化系統都有Xen的身影，比如 Amazon Web Services、Rackspace、Linode都是基於Xen的。

Xen無疑曾經是一個非常成功的平台虛擬化 方案。其實Sun的Solaris本來就是支援Xen的，可是Joyent的這些愛好技術的工程師認為KVM更有前途（我也這麼認為），於是把KVM移植 到了Solaris上。毫無疑問，KVM會在Linux下前途無量，因為它已進入了Linux核心主線。Xen雖然提交了一些東西給核心，但遠不是核心的 一部分。

很多人都不看好這個把KVM移植到Solaris上的做法。因為大家都知道KVM和Xen最大的不同就在於兩點：第一，要求使用硬 件的虛擬化支援；第二，儘可能地使用Linux核心已有的特性，而不是另起爐灶。不知道是Joyent的工程師水平太高，還是KVM設計得足夠精良很容易 移植，反正大家看到Joyent對自己的移植成果還是非常滿意的。

KVM並不是Joyent的重頭戲，但的確是個非常重要的部分。因為有了 KVM，就可以相容以前的各種既有系統，使用者可以不用遷移到SmartOS上，仍然使用原來的系統。這大大降低了使用者移轉的顧慮。但說白了，Joyent 要做的IaaS不是類似於AWS的那種，而是一種更容易構建PaaS或者其他服務的IaaS，所以說KVM很精彩，但不是重點。那麼重點是什麼呢？

Zones

PaaS也好，IaaS也好，肯定是要為很多使用者服務的，比較學術的說法叫多租戶系統。由於各租戶之間的資料和資源是完全隔離的，所以就需要系統提供各個層面的隔離。

舉個例子來說，我們要提供一個為很多人服務的資料庫，使用者之間是絕對不能泄露資料的，這是資料的隔離。但這隻是使用者看到的一個表面。試想，如果一個使用者缺乏資料庫的使用經驗，寫了一條不恰當的查詢語句，導致CPU的佔用率非常高，可能會影響其他使用者的正常使用。

如果這種情況發生在沒有CPU限制的系統內，一般的解決方案需要修改資料庫的源碼，增加監視或者評估模組，來限制對於某種資源的消耗。但這種方案的成本很 高，需要對應用情境非常瞭解，不具有普遍性。要是臨時換了一種資料庫，原來做的工作就要付諸東流了。另外，這種技術還需要對可能發生問題的原因有定論。但 提供雲端運算就像提供電能一樣，幾乎不太可能知道使用者最終如何使用電能。因此，用總結規律的方式來處理這類資源消耗問題並不是一個好方法。這不僅要求考慮到 所有可能發生的情況，而且實現起來也非常複雜，違背了KISS原則。

能否只在資源層面做出一些限制，比如分配給一個使用者固定的CPU佔用，無論使用者以何種方式操作，都不能逾越這個限制，使用者好像被限制在一台資源有限的機器中一樣？

Zones 是Solaris下作業系統層面的虛擬化方案，也稱作容器技術。平台虛擬化的方案對很多情境並不經濟，如前面所說的提供資料庫服務的方案。但為每個使用者提 供一個作業系統，然後在裡面安裝一個資料庫，顯然又有點太浪費了。容器有效地將由單個作業系統管理的資源劃分到孤立的組中，以更好地在孤立的組間平衡有沖 突的資源使用需求。與虛擬化相比，這樣既不需要指令級類比，也不需要即時編譯。容器可以在核心CPU本地運行指令，而不需要任何專門的解釋機制。此外，也 避免了准虛擬化（Paravirtualization）和系統調用替換過程中的複雜性。

這裡也體現出了多租戶和多使用者的一個非常不同的地方，多個租戶使用不同的執行個體，也就是說kill了這個租戶的資料庫進程，別的租戶是完全感覺不到的。本質上說，依賴修改應用源碼的方式還是屬於多使用者的套路。這樣會有很多問題，後續將討論這個問題。

這裡多說兩句，用Linux的同學也不用羨慕，可以嘗試LXC。LXC在Cgroup基礎上又向前發展了一步，成為比較系統的容器。很多國內大的互連網公司最近都紛紛擁抱了容器技術，而不是IaaS，究其原因還是容器技術非常適合其應用情境，更加經濟高效。

互連網企業中擁有大量的伺服器叢集，但一般來講，系統管理非常規範，不會有太多不同的系統，因此不太需要KVM這種非常重型的虛擬化方案。他們要解決的問題 是如何能最經濟地減少CPU的空閑。這也是Joyent虛擬化方案的主要應用情境，它希望的是客戶在它的IaaS上構建某種服務。客戶在意的是彈性和隔 離，Joyent在意的是成本。

這與大部分互連網企業的內部需求非常相似。在這種情境下真的沒有必要使用KVM等重型方案。給大家提個醒，OpenStack也是支援LXC作為Hypervisor的，不過支援得還不是很好。

要強調的一點是，這幾種技術都有個美中不足之處，那就是不支援熱遷移。當然，既然提到了這一點肯定就是有人實現了熱遷移，那就是OpenVZ。OpenVZ 也算是老牌的容器項目了，說句比較公道的話，目前OpenVZ還是要比LXC成熟、好用些，但它的命運有點兒像Xen，終究不是嫡系。雖然目前在歐美 VPS市場佔據絕對主導地位，但最終被LXC取代也是可以預見的。其他各路人馬也正在加班加點實現熱遷移這一非常重要的特性，且看誰能奪冠就是了。

DTrace

對PaaS平台來說，一個超級調試工具是不可或缺的。DTrace可以實現動態Tracing Service，解決開發人員所關心的各種問題。我們其實可以用標籤來描述 DTrace：可在生產環境下跟蹤系統的方方面面（功能和效能）——能跟蹤使用者的服務、開銷十分小、支援容器模型。目前，作業系統和軟體已經非常複雜，尤 其是虛擬化以後就更加複雜了。系統內部究竟發生了什麼，對於使用者來講似乎根本是無從知道的。而擺在PaaS開發人員面前的問題則是，不但要清楚地知道自己的 服務瓶頸在哪裡，還要知道使用PaaS的應用有哪些問題，以便對使用者提供良好的支援。

DTrace這種工具，讓系統再一次透明地展現在我們 面前，讓我們能夠清楚地知道整個系統各個層面的所有資訊。這些資訊對於調試那種原來我們最為頭痛的瞬態，以及幾乎無法複現的線上Bug起著至關重要的作 用。DTrace非常徹底地解決了一個核心問題：系統到底在什麼時刻做了什麼。這對於解決有些不確定因素的系統是特別有協助的，比如不可人工幹預的垃圾收 集調度器。

相應的，Linux也有其超級調試工具——SystemTap。這種工具目前得到了非常多開源項目的大力支援。10月 SystemTap迎來了它的2.0版本，也算是標誌性事件。不過SystemTap真的是晚了好幾年啊。DTrace為Sun的各種系統的成熟與穩定都 立下了汗馬功勞，包括最著名的ZFS和JVM。ZFS也不是一誕生就天下無敵的，它也遇到過類似今天EXT4這些焦頭爛額的問題。關鍵是這些問題解決得 早。要是SystemTap再早3年，沒準Linux的檔案系統能成熟不少呢。

我這裡也建議很多與Linux系統打交道比較多的同行，儘快 投入SystemTap的懷抱，早早放棄落後腐朽的調試方式。SystemTap前途光明，畢竟它是Red Hat的親兒子，Linux陣營中只要是Red Hat親兒子的一般都能成為高富帥，何況還有IBM的支援，也算是有個白富美的媽。

ZFS

說ZFS是目前最彪悍的檔案系統恐怕不會有多少人反對。它不但將傳統的檔案系統和卷管理合二為一，還提供了諸多對雲端運算特別有協助的特性，比如快照和複製、資料校正、資料壓縮、資料去重。

快照可以快速且一致地儲存資料的狀態，可以隨時復原資料，也可以使服務復原到任何想要的時刻。快照開銷非常小，這使得用快照來做常規備份成為一種可能。複製 則可以在短時間內產生大量服務執行個體，對那些使用PaaS的使用者，有什麼比等待應用啟動更讓人著急的呢。因此必須一個瞬間就為使用者提供所需要的租戶空間。

將PaaS提供給使用者後，其上會有海量的應用，這些應用會引用很多第三方庫，而這其中有很多庫是被重複使用的。比如很多展示類的網站都使用了同一個縮放圖片 的庫。這時要是檔案系統能將這些重複自動合并，則可以大大降低儲存的成本。包括上面的大量複製也是需要強有力的資料去重的。至於資料的壓縮和校正，也不失 為一種降低資料存放區成本的途徑。雲時代儲存價格低廉才有競爭力嘛！

小結

SmartOS 沒有像樣的管理工具，沒有可供調用的API，僅憑這兩點我們就可以判定它不是一個合格的IaaS。因為雲端運算最重要的可擴充性並沒有體現出來，所以 SmartOS肯定不是Joyent雲的全部。我們讚歎SmartOS各項精巧設計的同時，也為缺失一部分精彩內容而感到有點兒遺憾。不過還好，下期我們 可以解剖一個PaaS的源碼，它的名字叫haibu。

作者程顯峰，AdMaster首席佈道師，關注云計算對軟體研發過程的影響，積極投身開源社區，譯有《MongoDB權威指南》等。 新浪微博：@程顯峰-Mars