顯示具有 技術-雲端運算-Openstack 標籤的文章。 顯示所有文章
顯示具有 技術-雲端運算-Openstack 標籤的文章。 顯示所有文章

2013年11月12日 星期二

工作機會大比較! OpenStack vs CloudStack



Source: senoal

還記得之前我之前寫過一篇"cloudstack 與 openstack 目前的發展趨勢"，裡面有比較這兩個陣營在人數上，與活耀度上的比較，那讓我們先來複習一下最新進展，同樣的根據CloudWatch的追蹤報導 CY12-Q4 Community Analysis — OpenStack vs OpenNebula vs Eucalyptus vs CloudStack，在社群方面OpenStack 還是遙遙領先(不過成長趨緩?)，CloudStack 仍然努力緊追在後。

此外根據這篇OpenStack 的統計報告 study conducted by TrendKite，OpenStack 的媒體曝光度遠遠超過AWS (雷聲大雨點小?)



但是媒體的熱度似乎已經在降低，畢竟今年是BigData 年? (再誤)





不過今天我卻在Twitter上看到一個消息，Apple 正在Hire CloudStack Engineer ？ 奇怪話說前一陣子我才看到這篇文章 Apple looks to pick off engineers from Amazon, OpenStack to build out iCloud 。


喔？搜尋了一下果然Apple 在 LinkedIn的Job那邊果然有這個職缺。，看了一下工作內容描述，這不是在招喚我嘛?(誤)

Key Qualifications

  • Expert with Apache CloudStack/Citrix Cloud Platform and the underlying systems, storage and network hardware that support it
  • Minimum 5 years in UNIX systems administration in a large environment (1000 servers)
  • Experience with VMware vCenter and the ESXi hypervisor
  • Expert in RedHat Enterprise Linux (and it's variants) system administration including Yum and RPM packaging
  • Experienced systems engineer with at least Bash shell programming (Ruby and Java programing experience is advantageous)
  • Experienced in systems and platform configuration management using Puppet
  • Proficiency with source control, continuous integration and testing methods (particularly Git, Jenkins and the like)
  • Good understanding of Kickstart, NetBoot, PXE, DHCP, DNS, LDAP, monitoring tools, etc


這不禁讓我想到工作機會的確也應該是一個很重要的考量點，於是我就開始上網蒐集資料，看看到底現在市場上對於 OpenStack 與 CloudStack Engineer 的需求是如何  (唉...不過這些都是國外的需求....Orz...)

首先來看這篇  Guess what? OpenStack fans say OpenStack skills are in demand
，在這篇文章裡面提到OpenStack Engineer 的薪水還是比較高。



再來是比較工作需求的比較，OpenStack 還是遠勝於CloudStack



跟AWS比起來，大家都算是小咖~:P 不過這樣比我覺得有失公平，因為一個是會使用AWS的工作需求，跟會開發OpenStack 和 CloudStack的需求？



最後貼一下在indeed.com 的工作需求比較結果：

  • CloudStack 205 個需求
  • OpenStack 1115 個需求
似乎仍然是openstack 勝出~:P




結論...國外的月亮比較圓 (大誤)


延伸閱讀：

思科"批腿"，CloudStack 逆襲 OpenStack


於 張貼者： 0 意見
標籤： , ,

2013年3月16日 星期六

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的畫面。






 詳情請參考：


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


於 張貼者： 0 意見
標籤： ,

2012年8月29日 星期三

[筆記] Openstack - EfficientMetering

Source: cloudave

Openstack 正在努力的追趕AWS的功能，那目前openstack還缺哪一塊呢? 很顯然的就是監控的部份，也就是cloudwatch，套句前輩說的話，所謂學控制的人都會知道『先能量測，才有辦法控制』，此外如果需要把openstack 提升到可以營運的程度，不管是public cloud 可以計價收費，或是private cloud 提供企業內部資源分配，都需要這個功能。

 到openstack 的論壇看了一下，的確也是有許多人對於這個功能很有興趣，[openstack-dev] [ceilometer] weekly meeting - CloudWatch functionality。

目前版本代號是Openstack Metering (ceilometer)，另外的名稱叫做EfficientMetering，下圖是目前找到的架構參考圖。






之前在作我們自己Datacenter 資料收集的部份也是採用同樣的架構，不過最大的問題就是資料量，採樣頻率越密集，資料量越大，所以最好的方式是要獨立出一個網段來收集這些資料包括vm狀態(是否連線，是否運作正常)，監控資訊(CPU、RAM、Disk I/O、Network I/O..等)，一旦這些都考量進去，將來整個openstack 的安裝與管理會更加複雜(廢話IaaS本來就不是簡單的東西...=_=)

Reference:
[1] Ceilometer, the OpenStack metering project
[2] Ceilometer java
於 張貼者： 0 意見
標籤：

2012年8月21日 星期二

在Openstack 如何建立Bootable volume (EBS like)

Source: network

艦長日誌：

延續上一篇"Openstack 跟AWS EC2 的API相容性測試"，裡面提到EC2 API RunInstance 無法像AWS一樣直接啟動EBS-backed Instance ，為了解決這個問題我繼續去openstack 官網找尋答案，找到了下面三篇文章：

第一篇是 boot-from-volume，不過看裡面的內容，是提供這個功能了，但似乎透過API的確還是有問題，而且只有測過euca2ools ....=_= 是怎樣

Unresolved issues


  • volume snapshot related stuff.
  • EC2 API: At the moment EC2 API allows snapshot id to specify boot volume. However right now volume id is used. As a result the patches for euca2ools is necessary which includes bug fix.
 
 Source:boot from volume (Blueprints in grey have been implemented.)


第二篇 auto-create-boot-volumes 是第一篇的延伸，目的是希望Support Creating EBS boot volumes when boot-time ，也就是希望可以實作出跟Amazon EBS-backed Instance 樣的自動化流程，下圖是整個create bootable 的volume 的流程。但是很不幸的，這只是規劃，甚至都還沒排入release plan [issue]。



所以自動的方法和Call API的方法就先不用想了，最後只能試試看openstack document裡面寫的如何製作Bootable volume，以及透過command line 的方式手動產生，另外也有script 版本[1]。

[Update:2012/08/22]
那最後的實驗結果呢?失敗了!!有沒有那位高手有試成功呢?我也report 這個issue [#201690]
參考上圖的 7 和 9 的步驟，我再想可能少放了什麼到root volume?
另外先撇除無法用這個volume開機，的確關機後這個volume仍然存在，但是每次用這個volume create instance 都必須使用 "nova boot --image 的command"去執行，所以還是非常不方便。

 [Update:2012/08/23]
Bootable volume 這篇裡面的教法是mount 一個volume，然後用copy的方法是不可行的，後來解決方法如下：
1. 透過Dashboard or command line create 一個nova-volume
2. 找到那個vloume 在host實際存放的位置
3. 把要clone 的對象(bootable image)dd 到那個volume
4. 然後Create Instance 的時候選擇使用這個volume 開機  (EC2 API沒有這個功能)

Reference:
[1] how to boot from a volume script

於 張貼者： 0 意見
標籤：

2012年8月15日 星期三

Openstack 跟AWS EC2 的API相容性測試

Source: Star Trek - Captain's Log
『太空，人類的終極邊疆。星艦企業號的旅程就是為了探索陌生的新世界，去尋找宇宙中的新生命與新文明，勇敢航向人類足跡從未踏至的領域。』
不知道為什麼就很想用這個梗，大概我跟也迷航在Openstack的功能與設定裡面了...Orz..不知道何時雲端運算會變成銀河運算或是宇宙運算....(誤)

艦長日誌：

          測試目標：讓MeshCloud可以介接Openstack
           API 版本： aws-java-sdk 1.3.10
OpenStack版本： Openstack-essex release
           測試環境： Ubuntu 12.04.1 LTS
           測試對象：呼叫 openstack API http://x.x.x.x:8773/services/Cloud/


這幾天都在測試Openstack-essex 跟AWS EC2 的API相容性，發現很多API並不如官網所宣稱的那麼相容，或者應該說可以呼叫，但是很多行為與細節跟AWS並不一致，目前遇到的問題如下：

1. 無法RunInstance 同時使用BlockDeviceMapping去產生Volume
2. 不管透過API還是Dashboard去產生的Instance 都無法把Root Device 掛載EBS
3. 同2 所以Instance 關閉後，Instance就會自動被刪除
4. Attach Volume 必須掛載在/dev/vdx下面 (跟Amazon不一樣)

5. 無法import Key (Bug #755819)
此外目前最大的問題是Openstack dashboard 很多設定的功能都沒有，必須透過下指令(如：nove-manage)，但是下指令修改後，卻又跟dashboard不同步。

之前許多網路新聞都說已經有很多廠商直接使用openstack，如果不是他們有特別的客製化，那就是還有許多設定我不知道或是設定錯誤...Orz... (不過我懷疑~:P)

官網列出來的比較表如下：

EC2 API method
OpenStack
實際測試
AllocateAddress
(./)
無法測試
AssociateAddress
(./)
無法測試
AttachVolume
(./)
ok
AuthorizeSecurityGroupIngress
(./)

BundleInstance
{X}

CancelBundleTask
{X}

CancelSpotInstanceRequests
{X}

ConfirmProductInstance
{X}

CreateImage
{X}

CreateKeyPair
(./)
ok
CreatePlacementGroup
{X}

CreateSecurityGroup
(./)
ok
CreateSnapshot
(./)

CreateSpotDatafeedSubscription
{X}

CreateTags
{X}

CreateVolume
(./)
ok
DeleteKeyPair
(./)
無法測試
DeletePlacementGroup
{X}

DeleteSecurityGroup
(./)

DeleteSnapshot
(./)

DeleteSpotDatafeedSubscription
{X}

DeleteTags
{X}

DeleteVolume
(./)
ok
DeregisterImage
(./)
無法測試
DescribeAddresses
(./)
空的
DescribeAvailabilityZones
(./)

DescribeBundleTasks
{X}

DescribeImageAttribute
(./)

DescribeImages
(./)
ok
DescribeInstanceAttribute
{X}

DescribeInstances
(./)
ok
DescribeKeyPairs
(./)
ok
DescribePlacementGroups
{X}

DescribeRegions
(./)

DescribeReservedInstances
{X}

DescribeReservedInstancesOfferings
{X}

DescribeSecurityGroups
(./)

DescribeSnapshotAttribute
{X}

DescribeSnapshots
(./)

DescribeSpotDatafeedSubscription
{X}

DescribeSpotInstanceRequests
{X}

DescribeSpotPriceHistory
{X}

DescribeTags
{X}

DescribeVolumes
(./)
會有warn
DetachVolume
(./)
ok
DisassociateAddress
(./)
無法測試
GetConsoleOutput
(./)
空的
GetPasswordData
{X}

ImportKeyPair
(./)
UnknownError
ModifyImageAttribute
(./)

ModifyInstanceAttribute
{X}

ModifySnapshotAttribute
{X}

MonitorInstances
{X}

PurchaseReservedInstancesOffering
{X}

RebootInstances
(./)
ok
RegisterImage
(./)

ReleaseAddress
(./)
無法測試
RequestSpotInstances
{X}

ResetImageAttribute
{X}

ResetInstanceAttribute
{X}

ResetSnapshotAttribute
{X}

RevokeSecurityGroupIngress
(./)

RunInstances
(./)
部分ok
StartInstances
(./)
ok
StopInstances
(./)
等同Terminate
TerminateInstances
(./)
ok
UnmonitorInstances
{X}



於 張貼者： 0 意見
標籤： ,
訂閱： 文章 ( Atom )