NodeStack：另類的開源云計算組合
NodeStack是另類的開源云計算組合，從內到外實現了應用PaaS。其架構主要包括SmartOS、Node.js和MongoDB三部分。本文將重點介紹NodeStack的底層平臺SmartOS。
最近談到開源云計算，大家可能第一想到的是OpenStack、Cloud Foundry這種金光閃耀的組合。但NodeStack的發布，使大家眼前一亮——原來可以這么玩。簡單地說，NodeStack使用了一套完全不同的 開源架構，從內到外實現應用PaaS。其架構主要包括SmartOS、Node.js和MongoDB。由于這幾種技術的東家都參與了這個項目，我們就來 看看NodeStack到底有什么神奇的地方。
先來簡單介紹一下出場的各位玩家。
- Joyent，Node.js的東家。有趣的是這個公司的主營業務是IaaS，其核心技術在于SmartOS——一種與時俱進的Solaris。
- Nodejitsu，Node.js社區的核心玩家。公司的目標是做一個基于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（Kernel-based Virtual Machine）
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可以實現動態跟蹤服務，解決開發者所關心的各種問題。我們其實可以用標簽來描 述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提供給用戶后，其上會有海量的應用，這些應用會引用很多第三方庫，而這其中有很多庫是被重復使用的。比如很多展示類的網站都使用了同 一個縮放圖片的庫。這時要是文件系統能將這些重復自動合并，則可以大大降低存儲的成本。包括上面的大量克隆也是需要強有力的數據去重的。至于數據的壓縮和 校驗，也不失為一種降低數據存儲成本的途徑。云時代存儲價格低廉才有競爭力嘛！
來自：原文鏈接