cloudstack 與 openstack 目前的發展趨勢

圖片來源：Kiwi He (殊途同歸)

最近參加許多研討會，或是在網路上的論壇，最常聽到的就是在詢問Openstack 與 CloudStack的比較與差異，網路上也有許多文章從各種角度去比較各個Open Source IaaS平台之間得差異，有的從功能面，有的從參與的廠商數，有的從社群的活躍度(Mail list 討論量，Bug Report量，Release 的速度，甚至活動的參與人數)，舉例圖片如下：

 圖片來源：婉兮清扬 [3]

就我的觀察，目前Open Source IaaS 的兩大陣營 CloudStack 與 OpenStack，是分別從不同的設計理念出發，但是最終的目標就是希望能迎頭趕上Amazon ，成為像AWS一樣的Public Cloud。目前這兩個IaaS的所處位置就如圖下圖所示：

圖片來源：opennebula

OpenStack

從社群面來說：

OpenStack 去年呈現爆炸性的成長(參與人數)，有許多大廠都跳進來搖旗吶喊，從正面的角度來看社群欣欣向榮，有這麼多大廠人力和財力的支持，發展起來一定很威，但是從反面角度思考，畢竟各家廠商都還是有商業利益考量，所以針對規格和發展方向就會進行拉扯與角力，這一點讓人隱憂。

從架構面來說：

此外OpenStack 的設計理念從一開始就是為了超大型的IaaS 架構在設計，所以所有的元件(Service) 一開始就是以分散式的架構在開發，每個Service 都可以獨立運作，也是由個社群團隊獨立開發，優點是如果整合的好的話，對於將來Scale out 整個系統會非常方便，但是目前的狀況卻似乎不是這樣，每個Service 的開發與整合感覺沒有那麼同步，所以不管在安裝上與整合上都有一定的門檻。不過隨著時間的演進這個問題應該會慢慢的解決。

從語言面來說：

OpenStack 主要是以Python 來開發，這部份我就不多評論，因為我跟pythone不熟~:P


CloudStack 

從社群面來說：

CloudStack 最早其實是Cloud.com所以開發的軟體，後來被Cirtix 所併購，所以這個產品一開始就算是一個成熟的產品，直到2012年Citrix 把 CloudStack 以Apache 的License 的方式捐獻出去，整個社群就開始蓬勃發展，這次去參加ApacheCon 2013 就有超過11個Session 就是跟CloudStack有關。

從架構面來說：

就我的觀察CloudStack的設計理念反而是從Private Cloud走向Public Cloud 架構，也就是CloudStack 在一開始開發時，主要是以管理較小的機房架構(Private Cloud)為主，所以不管在安裝的容易度上，和產品的整合度上都非常成熟，在這邊分別把我覺得不錯的優點和特色一一舉出：

1. 出色直覺化的UI

 最讓我覺得驚訝的就是建立Virtual Machine 的畫面，跟我之前開發MechCloud的想法一模一樣，利用圖像化直覺的設計，讓使用者很清楚他現在在做什麼，以及到哪個步驟了，下面第一張圖是當初MechCloud一開始的設計，第二張圖示Cloudstack的設計，是不是很像。

再來談談Architecute，下圖是Cloudstack的Architecture階層圖，管理階層是從Zone，Pod，Cluster，Host，到VM。直接看到這張架構圖應該是很好理解，但是如果在安裝與設定時要怎麼對應成這張圖呢？

Cloudstack 直接把上面階層的概念做成UI，讓你由圖片可以很清楚的了解整個Deploy 架構和網路設定

 2.支援多種網路架構(主要由Basic Mode and Advanced Mode去組合變化)

IaaS裡面最複雜的一部分就是網路規劃，以及Vlan的設定，CloudStack 同樣也是透過圖形化的方式讓管理者很容易去設定和了解網路的架構，下圖分別是Basic mode 和 Advanced Mode的畫面。

 詳情請參考：

• CloudStack Advanced Mode Step by Step
• Understanding Cloudstack's physical network architecture

3.歡迎各家廠商加入的Plugin-in 架構

這部份算是CloudStack最受歡迎的部份，這次參加ApacheCon 2013 裡面就有人提到OpenStack和CloudStack在這方便最大的差別：

Open source Community Leadership Drives Enterprise Grade innovation.Cloudstack's plug-in model permit enterprise-grade adapters.

Cloustack的理念是這樣，企業在尋找的是可以更客製化的Iaas環境，但是如果要客製化Iaas，必須先了解整個cloustack或是openstack實在是太困難，所以cloudstack 允許企業可以從 plug-in or adapter的架構切入，讓企業可以直接針對自己的需求與所需要支援的硬體去開發plugin，不用受限於社群的審查和投票流程，因為傳統在社群上要開發新Feature必須經過以下流程：

• 在Maillist 宣布，讓大家都能知道，是否能接受
• 公開Function Spec & Design
• JIRA ticket for feature
• Setup a Dev Environment
• Branch on github use your own (publich) branch
• Submit changes to Review board
• Post-reviw for large package of changes
• Decide on the wiki you want

所以Plugin 的架構可以讓企業在開發上增加彈性，不論是要直接捐獻給社群，或是沒有捐獻給社群直接拿來獲利都是可以。


4. 使用Java 開發

好啦，這其實是我的私心，因為Java比較熟，所以從Cloudstack切入會比較容易，不管是要改寫,patch 或是寫plugin都非常方便。


最後，就如同我說的cloudstack一開始就是從Private cloud的角度去開發，所以之前的架構是把所有servie 都綁在一起 ，如果要比較大規模的佈署時(類似AWS)可能就會遇到Scale 的問題，因此cloudstack社群也有注意到這個問題，在 4.1 已經開始在把系統架構重構(代號Javelin)，目的是要把架構變成Loosely-coupled component oriented distributed architecture。

結論：

青菜蘿蔔個有所愛，所以也不能因為我比較喜歡cloudstack就說openstack不好，一切還是要回歸企業的應用與需求為主，上面所寫的只是希望可以給各位在選擇解決方案時能有所參考。



延伸閱讀：
[1] CloudStack 與 OpenStack 誰將稱王
[2] OpenStack vs CloudStack: The Latest Score
[3] CY12-Q4 Community Analysis — OpenStack vs OpenNebula vs Eucalyptus vs CloudStack

Apache Kafka 又一個messaging system !?

圖片來源：網路

這次在ApacheCon2013 上看到  Apache Kafka 的專案介紹，心想又一個messaging system !?

Intra-cluster Replication in Apache Kafka

於是又好奇的去收集了許多資料，首先參考Slideshare的一篇介紹Apache Kafka 的投影片，Kafka號稱最大的特色是同時混和了Offline log以及Realtime Message  兩種功能。

還記得上一篇文章我有提到各種分散式Log-aggregation系統 (如Scribe 和 Flume)，他們的架構都是Push driven architecture，雖然具高效能高擴充性，但是有以下缺點：

• 預期的端點(End points)都是大型叢集(如：Hadoop)
• 端點(End points)不能有太多即時性商業邏輯 (business logic in real-time)

因為他們最主要的工作就是盡量快速的去消化客戶端push 過來的log，而跟傳統的Messaging System(如：RabbitMQ , ActiveMQ)，並不夠Scale ?：
(不太懂這邊的意思，還需要要研究一下...)

• No API for batching, transcational (broker retain consumers stream position)
• No Message persistence means multiple consumers over time are impossible limiting architecture

圖片來源：Apache Kafka

談到MQ大家最有興趣的一點就是效能了，看到投影片的圖...有沒有那麼神！？

圖片來源：Apache Kafka

不過仔細看benchmark 的條件與環境設定，還是發現他為了增加吞吐的效能，對於資料的的完整性和確保性作了取捨：

Kafka producer currently doesn't wait for ack form the broker. Without ack , there is no gurantee that every published message is actually receved by the broker

所以如果是必須保證送達的系統，可能就不能使用Kafka 了~

RabbitMQ vs. Kafka

了解了Kafka特性後，還是不免會想要跟RabbitMQ作一下比較，參考Quora的這篇文章"RabbitMQ vs Kafka which one for durable messaging with good query feature"，針對兩個系統的特色，節錄以下內容：

a) Use Kafka if you have a fire hose of events (100k+/sec) you need delivered in partitioned order 'at least once' with a mix of online and batch consumers, you want to be able to re-read messages, you can deal with current limitations around node-level HA (or can use trunk code), and/or you don't mind supporting incubator-level software yourself via forums/IRC. 

b) Use Rabbit if you have messages (20k+/sec) that need to be routed in complex ways to consumers, you want per-message delivery guarantees, you don't care about ordered delivery, you need HA at the cluster-node level now, and/or you need 24x7 paid support in addition to forums/IRC.

不過作者也回答道，如果要求的是Real time streaming process (filter/query) 的功能的話，這兩個都不適合，反而應該考慮Storm：

Neither offers great "filter/query" capabilities - if you need that, consider using Storm on top of one of these solutions to add computation, filtering, querying, on your streams

透過這些文章與解釋我似乎開始了解 Kafka or Storm 的用途與應用情境，也漸漸了解到為什麼很多公司都是使這兩個系統用來補足Hadoop real-time process 不足的地方，因為實在有太多公司使用這種組合，下面舉例infochimps這間公司如何看待Storm and Kafka：

Why should you care?

With Storm and Kafka, you can conduct stream processing at linear scale, assured that every message gets processed in real-time, reliably. In tandem, Storm and Kafka can handle data velocities of tens of thousands of messages every second.
Stream processing solutions like Storm and Kafka have caught the attention of many enterprises due to their superior approach to ETL (extract, transform, load) and data integration.
Storm and Kafka are also great at in-memory analytics, and real-time decision support. Companies are quickly realizing that batch processing in Hadoop does not support real-time business needs. Real-time streaming analytics is a must-have component in any enterprise Big Data solution or stack, because of how elegantly they handle the “three V’s” — volume, velocity and variety.
Storm and Kafka are the two technologies on the list that we’re most committed to at Infochimps, and it is reasonable to expect that they’ll be a formal part of our platform soon.

ps. 話說趨勢也有自己的MQ叫做TME - TrendMicro Message Exchange，所以我才會覺得怎麼又一個MQ....XD

Reference:
[1] Message Queue Evaluation Notes
[2] Background Jobs in Ruby on Rails
[3] Intra-cluster Replication in Apache Kafka

ApacheCon2013 - About BigTop

參加Conference要觀察一個技術或是專案的受重視程度，通常可以藉由幾個指標來觀察：

1. Session Room的安排 (越熱門的會議室通常越大間，越熱門的越早報告)
2. 類似題目sharing 次數 (越熱門的題目通常會被分享比較多次)

而這次參加ApacheCon最明顯的感受就是關於Bigtop 的受重視程度，因為光是Bigtop相關的題目就有三四場：

• Build & Deploy your own big data distribution with Apache Bigtop 
• Getting Hadoop, Hive and Hbase up and running in less than 15 min  [投影片]
• Lessons in Apache Software Integration [投影片]

三場的內容整理如下：

Why Bigtop ?

首先先從Hadoop的痛開始說起，傳統安裝Hadoop & Ecosystem 都會從Apache網站下載tar開始，然後接下來的步驟可能如下：

1. 下載安裝Hadoop
2. 設定環境變數 (當發現出現一堆error message 才會想起什麼環境變數忘了設定)
3. 設定HDFS權限 (當發現權限錯誤時才會想起要設定權限)
4. 如果要安裝Hive 就會遇到版本問題 (安裝其他ecosystem也常發生這些問題...Orz..)

所以社群就發現這不是跟當年的Linux一樣嘛？！最一開始Linux 都得要自己去下載套件，自己去Build每個套件，找出相依性....

  圖片來源：Bigtop

這種痛苦直到Debain出現才解決，除了提供一個整合的安裝還境外，由於是Debain完全由社群所貢獻，並不會由特定公司所把持，仍可以保持自由軟體的特性，但是也歡迎其他公司另外基於Debain上再做出更好的產(例如：ubuntu)。畢竟對於大部分的使用者來說，能用apt-get install 來安裝軟體是最好的，誰還會想由 tar ball來安裝呢？因為還得解決一堆相依性的問題。

圖片來源：Bigtop

所以BigTop 的概念就是類似Debain 的角色，要靠社群的力量來完成一個套件，其他公司如Cloudera和Hortoneworks ...等，可以基於Bigtop上加值和再開發。

所以Bigtop的定位就是：

Bigtop make building block to distribution

想像以後如果想要安裝任何Hadoop ecosystem時，只要下以下的指令，不是很棒嘛：

# bigtop lanuch-cluster -config ./hbase.ini

Key challenges

有願景是好的，不過Bigtop專案目前也遇到以下許多問題：

• A really drivers set of components
• High churn APIs 
• 不像Linux 有一個統一的架構，大家都不知道hadoop的最終方向，都是邊走邊改，所以API之間的相容性永遠是問題
• Asynchronous development cycles.
• 每個專案由於熱門程度不同，開法速度也不一樣，所以在升級上很難做到同步一致。
• Combinatorial explosion of dependency
• 永遠有各種版本的組合，也永遠會有不同的Bug
• Java based
• Java 開源專案最怕的 dependency 地獄，就算用 maven 也會有衝突的問題，最有常遇到的例子就是slf4j 和 log4j版本的問題
• Fundamentally distributed application
• Apache 的好處就是提供各式各樣的專案和building block，但是缺點就是太多了，你必須到市場去慢慢挑選你要怎麼整合，一個Architecture 就像一個廚師，你必須先知道每個食材的特色，和相互之間的關係，你才可以知道要挑什麼食材煮一套菜。

所以Bigtop的願景怎麼實現？這個專案到底要提供什麼？

• Integration 
• Build (make, Maven)
• Packaging (RPM, DEB)
• Deployment (Puppet)
• Testing (integration Test)
• A continuous integration Jenkins server 

所以目前Bigtop所使用的方法是一步一步慢慢推進，Embrace asynchronous nature (擁抱不同不的Hadoop)，總是找出一個最好的build ，然後再每次慢慢改一個lib 來測試推進。

Ps. 講者特別再會場徵求

目前Bigtop的Jenkins和測試整環境放在EC2 由cloudera提供，他們也歡迎任何公司/學術機構提供Test Case (放在Hadoop 跑的Real Case)，讓他們放在Jenkins 上持續的跑整合測試。



延伸閱讀：
[1] What is Bigtop, and Why Should You Care
[2] How to install Hadoop distribution from Bigtop