PIXNET Logo登入

程式開發ㄅㄆㄇ -歡迎光臨 Inuiüni 幼稚園

跳到主文

把敲鍵盤當彈鋼琴-我是不務正業的工程師Cooker Uni,這裡是我的生活知識庫。

部落格全站分類:生活綜合

  • 相簿
  • 部落格
  • 留言
  • 名片
  • 6月 08 週二 201000:07
  • Inui 職涯資料庫╭★資訊人員的生涯規劃與應學知識

[轉錄]資訊人員的生涯規劃與應學知識

  • 分 享在我的 Facebook
  • 分 享在我的 Plurk
  • 分 享在我的 即時通

邱奕南, 2001/4/16


對於一個程式設計師而言,如何在資訊領域中規劃自己未來的方向是很重要的一件事,畢竟沒有人願意十年、二十年後,還在程式撰寫的小圈圈中打轉
。以下,作者便以從事資訊業十餘年、歷經各種職位的經驗,提供一些心得給所有還在從事程式設計的人參考。

首先我們來看看,資訊人員可從事的職位有那些:

1.程式設計師:對於中小型軟體公司而言,程式設計師往往還必須兼任系統分析、系統設計的工作,但在較正規化的大型軟體公司裡,程式設計師的工
作,便只是程式撰寫而已。當然,也包括了單元測試與程式碼檢視的工作。因此他所要學的知識,主要是程式語言、資料結構與演算法,同時也要了解
跟作業系統有關的API函數與相關的界面協定,並養成良好的程式撰寫習慣與技巧。

2.技術主管:負責研究、評估、引進資訊應用的新技術,並對研發人員進行技術移轉的訓練,同時他也負責部份的程式撰寫工作。這個職位一般很少有
正式的編制,通常由資深程式設計師、研發小組主管,或是研發經理兼任。

3.研發小組主管:在規模較大的軟體公司裡,大都有這個編制,一般由資深程式設計師擔任。他的職責主要是帶領小組成員,完成程式撰寫的工作,並
整合與測試小組成員的程式。因此除了在程式設計的技術深耕外,他還必須具有管理的知識,並負起訓練小組成員的工作。有時他還必須兼任技術主管的職責。

4.系統設計師:大部份只會在較正規化的大型軟體公司裡,才有這種職位配置。他主要是負責系統設計的工作,而系統設計的內容往往和系統相關,因
此他所要學的知識,除了包括程式設計師應學的知識外,還要加上系統分析設計方面的知識。有時他還要兼任程式撰寫的工作,因此通常這個職位均由資深的程式設計師擔任。

5.系統分析師:大部份稍具制度的軟體公司,都會有這種職位配置。他主要是負責系統分析的工作,因此在邏輯思考能力上要有一定水準,同時對於軟
體工程以及各種資訊新技術,也要有廣泛與深入的了解。此外,不斷地累積系統分析經驗也是這個職位不可或缺的一部份。雖然程式設計與系統設計的
經驗在此職位並非必要,但這種經驗對於完成系統分析的工作,也具有輔助的效果。系統分析師在不同的組織體系裡,有時也會兼任需求分析的工作。

6.研發經理:主要掌控整個研發團隊,進行軟體的實際開發,由系統分析開始,到整合測試為止。通常擔任這個職務者,必須是個通才型人物,也就是
歷經程式設計師、系統設計師、系統分析師等三種職務,而且其技術能力必須可以服眾(特別是華人研發團隊)。除了這三種職務所需具備的知識外,
他還必須學習管理的知識。有時他還必須負起技術主管與教育訓練的工作。
在更小型的軟體公司裡,他可能還要兼任專案經理、產品經理、系統分析師、系統設計師、程式設計師、測試人員等多種工作,是個相當累人且不容易做好的職務。

7.專案經理:軟體發展管理者,主要是與客戶溝通,進行需求收集與分析,同時協調所有業務與研發人員進行開發工作,負責產品評估,並監督整個專
案的進度,直到專案驗收為止。因此他的人格特質便必須善於溝通與協調,而所學的知識只須包含軟體工程與領域知識即可,不過對於資訊技術的了解
程度,也會影響到專案經理的勝任能力。專案經理有時還必須兼任業務的工作,擔負部份的業績。

8.產品經理:和專案經理類似,只是對象改為產品而已,因此除了專案經理所應具備的人格特質與知識外,還必須具有相當的行銷知識與創意。在某些
公司的編制上,產品經理有時還必須負起主導產品方向、構思新產品,以及進行產品促銷與尋求銷售通路的工作,甚至也可能擔負部份的業績。

9.測試人員:主要負責品檢的工作,除了必須了解測試方面的知識外,也必須具有耐心、細心的人格特質。

10.品質稽核員:主要監督各軟體專案的開發流程,是否完全依照制度進行
。在實施全面品質保證的公司裡,品質稽核員的稽核範圍包括了公司內所有的作業流程,也包含了公司所有階級的人員。

11.顧問:顧問指的是學有專精的人,大致可包含下列四類:

a.理論技術顧問:也就是在理論研究方面學有專精的人,一般都是學校中的教授。

b.應用技術顧問:也就是在某種資訊應用技術上學有專精的人,一般都是某個公司的技術主管,不過他的價值會隨著資訊技術的演進而變化。

c.領域知識顧問:也就是在某個資訊應用領域上學有專精的人,一般都是某個領域中的佼佼者。

d.管理顧問:一般可分成企管顧問、資訊管理顧問、品質保證顧問等三種,分別輔導企業的經營管理、資訊化與品保認證事宜。一般都是由顧問公司的從業人員擔任。


由以上所述的工作類型與所需的人格特質,我們可歸納出幾種升遷路線:

1.測試人員-品質稽核員:
適合不善溝通、不喜管人,但具備耐心、細心人格特質的人。

2.測試人員-程式設計師-技術主管:
適合不善溝通、不喜管人,但又喜好程式撰寫與研究新技術的人。

3.程式設計師-研發小組主管:
適合細心、負責,具有一定溝通協調與管理能力,而又喜好程式撰寫與研究新技術的人。

4.程式設計師-系統設計師:
適合不善溝通、不喜管人,但又喜好程式撰寫與研究新技術,並具有一定資訊理論基礎的人。

5.系統設計師-系統分析師:
適合不喜管人,但邏輯思考能力強,喜好研究新技術,並具有一定溝通能力與資訊理論基礎的人。

6.系統分析師-研發經理:
適合細心、負責,善於溝通協調與管理,且技術超強的通才型人員。

7.系統分析師-專案經理:
適合負責,善於客戶應對與溝通協調,並具有一定技術能力的人。

8.系統分析師-產品經理:
適合負責,點子特多,洞察力精準,並具有一定客戶應對與溝通協調能力的人。

9.管理顧問:
適合善於應對與溝通的人,通常必須考上相關證照,並在顧問公司從事一段時間以上,有知名的成功輔導案例者。

讀者可依照自己的人格特質與興趣,慎選將來生涯規劃的方向,並及早充實應具備的知識與能力。不過在此,作者還有幾點建議提供參考:

1.加強打字速度:
這是很多資訊人員忽略的地方。打字速度的快慢,往往會影響到工作的產能,尤其愈是上層職位(此處指的是經理級的執行層,而非副總級以上的決策
層),他所要撰寫的文件愈多,因此儘可能提升自己的中英打速度,至少應達到50字/分鐘以上。

2.以通才型為目標:
因為通才型的人物幾乎可以勝任各種工作,在資訊競爭激烈的潮流中才不容易被淘汱,也比較容易找到合適的工作。不過在以此為目標前,要先衡量自
己的能力,否則不但無法達到博而精的地步,反而變成了雜而駁,那就得不償失了。建議是先精而後博。

3.多學不易變動的知識:
儘量學一些”學一次享用終生”的知識,例如資訊理論、軟體工程、管理學等,以培養自己往各方面發展的基本能力。

4.保持對應用技術的了解:
對於容易變動的資訊應用技術,如程式語言工具、作業系統API、各式整合界面與架構,只要保持了解其內容與架構,並知道資料如何取得即可,在實際預期會用到時,再開始拿來精研,比較不會浪費時間去精研將來用不著的
技術,因為這些技術可能在一、兩年後便被淘汱了。不過如果技術底子不夠,最好先精研一陣子,否則要用到時無法迅速理解,反而會降低了自己的技術能力。至於要專研什麼,便由讀者自行決定了,作者只建議,至少常用的
作業系統API一定都要試過會用,程式語言工具裡的程式庫原始碼都要看過一遍,以了解別人是怎麼寫的,為什麼要這麼寫。這樣至少便有一定的技術底子了。

5.加強英文閱讀能力:
大部份的資訊應用技術資料,都是以英文撰寫的,如果英文閱讀能力不夠,便會降低學習的速度,即使勉強可隨著潮流前進,但想走在別人前面,搶先
創新技術產品便不可能了。

(繼續閱讀...)
文章標籤

unix 發表在 痞客邦 留言(0) 人氣(31)

  • 個人分類:A+管理職涯
▲top
  • 6月 07 週一 201023:46
  • Inui 好文分享╭★關鍵字典-saas,paas,iaas

三種雲端運算架構
依照Wikipedia的定義,如圖3,雲端運算在建置架構上大致分成三個階層:應用程式、平台與基礎設施,並由此分別提供三種型態服務:

圖3:雲端運算架構階層堆疊。(資料來源:Wikipedia)


1.軟體即服務(SaaS)

在此階層中,主要是以雲端應用程式(Cloud Application)來提供各種SaaS服務,存取該服務的使用者不需要下載或安裝任何程式,就可以直接透過瀏覽器存取雲端應用程式所提供的功能與服 務。透過該服務,使用者不用對軟體進行排錯、更新等維護作業,對於使用管理負擔及成本的降低有不小的助益。不僅如此,比起自行建置的系統與程式,SaaS 提供了更高可用性的不中斷服務。

當前市面上不乏許多通行已久的SaaS服務,其中最耳熟能詳的莫過於Google Apps與Saleforce.com。採用P2P技術的Skype、趨勢科技的雲端防毒,以及YouTube、Facebook、Twitter等 Web應用程式,皆屬於不同類型的SaaS服務。微軟在既有商用軟體上,另外提供相對應線上軟體服務也是其中一種。在儲存方面,目前Amazon所提供的 自助式內容分派服務CloudFront,以及支援檔案共享與資料同步化服務的微軟Live Mesh,皆屬於採用分散式雲端儲存技術的SaaS服務。

2.平台即服務(PaaS)

所謂PaaS,指的是提供運算平台或解決方案服務化而言。它仰賴雲端基礎設施之資源,支援雲端應用的不同功能,並提供整合的API。PaaS好處在於應用 程式的部署更簡便、有效降低底層軟硬體架構採買及管理成本。常見的服務包括Microsoft Azure、Google Engine、Google Custom Search、Yahoo! BOSS等。至於Amazon SimpleDB、Amazon S3、Nirvanix等,則屬於提供結構化雲端儲存機制的PaaS服務。

3.基礎設施即服務(IaaS)

至於IaaS意指雲端基礎架構(Cloud Infrastructure),也就是將運算、儲存及網路等資源轉化為標準化服務,以提供內外部使用者存取之用。為了讓資源有效管理與應用,IaaS多 半藉助虛擬化技術來完成伺服器整合之基本作業。目前市面上的IaaS服務,在運算資源分派服務上,有Amazon CloudWatch,以及提供虛擬機器服務的Amazon EC2;在網路資源分派服務上,則有Amazon VPC虛擬私有雲端;在原生儲存資源分派服務上,則以Amazon EBS為代表。

除了上述三個服務階層外,整個雲端運算架構中還有最頂層的用戶端,以及最底層的伺服器。對於雲端運算而言,其服務對象即為用戶端。用戶端可透過桌機、筆 電、Thin Client,甚至手機、PDA等行動裝置內建的瀏覽器來存取雲端運算服務。

就Thin Client與手機等裝置來說,裝置本身並不需要強大的硬體效能,也不用安裝任何軟體,只要有簡單好用的瀏覽器,就可以隨時隨地享受雲端服務所帶來的種種 好處。至於伺服器,當然是雲端運算提供各種服務的最重要基礎設備,即使是可以提昇整合效率的虛擬化軟體,也必須藉助伺服器的安裝才行。在伺服器類型上,同 時具備高密度運算容量,並有效提昇管理及佔用空間效益的刀鋒伺服器愈見青睞。

(繼續閱讀...)
文章標籤

unix 發表在 痞客邦 留言(0) 人氣(1,252)

  • 個人分類:雲端技術
▲top
  • 6月 07 週一 201023:44
  • 雲端運算的儲存基礎架構

雲端運算的儲存基礎架構
揭開雲端儲存的面貌
文/圖 曹乙帆.責任編輯/洪羿漣

當前的IT產業中,「雲端」幾乎成了時下最火紅、時髦的代名詞,軟硬體廠商開始將旗下產品逐漸移轉到雲端,或提出各自在雲端架構中的發展方向。其中屬於儲 存領域的「雲端儲存」,究竟在整個雲端運算的框架中扮演什麼角色?現在的發展狀況與面臨的瓶頸為何?請看本專題的分析探討。

談到雲端儲存(Cloud storage),簡單來說,就是將儲存資源放到網路上供人存取的一種新興方案。如此一來,使用者可以在任何時間、任何地方,透過任何可連網的裝置方便地 存取資料。若方案供應商能進一步確保資料的安全無虞,同時又提供許多資料檢索及管理的功能,使用者又何必不定期地花錢購買、安裝、設定或擴充儲存設備呢? 尤其對於定期會有龐大資料備份需求的使用者或企業來說,設備的管理及擴充絕對是一大夢魘及負擔。

就一般使用者而言,雲端儲存及類似方案似乎處處可見。值得注意的趨勢,就是雲端儲存所支援的存取裝置也從電腦主機,慢慢擴展到手機等行動裝置上。換句話 說,非透過電腦上網存取資料的時代已然過去,機動性更強的手機提供更具彈性的雲端資料存取方案。當前甚至有雲端音樂串流服務-ZumoDrive的推 出,iPod/iPhone的使用者可以事先將音樂丟到線上儲存空間中,然後再透過無線網路播放音樂串流,相當方便。(圖1)

圖1:ZumoDrive網站上所提供的雲端儲存服務。


相對於消費端雲端儲存的熱絡,企業端雖然仍處於「只聞樓梯響」的階段,但當前主要的儲存業者,如EMC、HP、HDS、IBM、NetApp…等,早已準 備好迎接雲端運算所可能產生的變革,如今就等著「東風」起而全力搶攻。


IT資源轉化為Web服務
雲端儲存是雲端運算架構中的一部分,所以在介紹雲端儲存之前,必須先對雲端運算架構有一些基本的了解。簡單來說,雲端運算就是將運算、儲存及網路,抑或硬 體、軟體及平台等IT資源,透過虛擬化之資源利用最佳化,以及可量化計費的服務型態,經由網路分送,給使用者隨時存取的一種服務平台。

該服務就像水電等公共設施一般,使用者不需了解其背後運作技術及狀況,企業用戶也不必耗費可觀的人力及管理成本,進行任何IT設備及資源的管理。所有資源 的分配及管理,設備的汰換、更新與擴充,全都由雲端運算供應商負責一切,並依使用者需求提供可擴展性的高可用性服務,至於使用戶則只要按使用量付費即可。

事實上,雲端運算所採用的理論基礎與技術皆非全新,從過去以來的伺服器整合(Server Consolidation)、Web Service、服務導向架構(SOA)、公共運算(Utility Computing)、主機代管等服務或平台上,就已經可以看到與雲端運算概念相似的身影。這也是當前雲端運算一直沒有被明確定義的原因之一。

不論如何,隨著網路頻寬的提昇、Web 2.0與虛擬化技術的日漸普及,雲端運算在上述各種有著相似概念技術、服務或平台長久所奠下的基礎上發展,開始愈受注目與青睞。

在許多技術服務當中,網格運算(Grid Computing)最常與雲端運算相提並論,雖然兩者皆採分散式運算架構,但事實上,卻有很大差異,其中尤以資源擴展性最為明顯。前者強調所有運算資源 集中化,以因應需要大規模運算的應用任務,缺乏擴展彈性;後者適用於多重用戶之大量單一請求,並依不同個別需求調配資源,具備動態擴展能力。


資源配置與管理介面
要達到資源隨需分配、隨需擴展的彈性,雲端運算必須融合許多技術,例如分散式運算、SaaS、Web Service與伺服器虛擬化等,尤其是伺服器虛擬化技術,在這幾年的推展下,不論是資源利用率的提昇,乃至降低電力、散熱所達成的節能減碳效益,都為雲 端運算發展奠下厚實的基礎,使其不但可發揮動態擴展性與多重用戶(Multi-tenancy)的經濟效益,並有效降低IT資源的使用成本。

伺服器虛擬化允許多作業系統與相關應用軟體可同時運行在單一實體機器中的特性,可協助企業加速完成基礎架構即服務(Infrastructure as a Service, IaaS)方案的部署。所謂IaaS資源大致是指儲存、網路與運算等三種資源而言,使用者可針對特定屬性的虛擬機器,指定搭配不同用量的資源配置(例如配 置該機擁有1GB記憶體、320GB硬碟等)。(圖2)

圖2:雲端運算架構模型。(資料來源:IBM)


該方案允許快速的應用程式資源配置,基礎架構之上的底層作業系統,也可依負載控制需求進行擴展或縮小。也因為如此,使用中的資源較能與應用軟體的需求做良 好的搭配。當前IaaS方案多半提供了基於REST(REpresentational State Transfer)式的HTTP操作介面,透過該介面,可允許在其基礎架構上進行虛擬映像檔的部署、管理,以及資源的指定分配。

REST介面並沒有其他協定的額外負擔,它允許使用者可以簡易地存取其伺服器。每個資源皆透過獨一無二的URI(Uniform Resource Identifier)定址,同時基於CRUD(Create創建、Retrieve檢索、Update更新、Delete刪除)四個操作,資源因而能被 控管。


三種雲端運算架構
依照Wikipedia的定義,如圖3,雲端運算在建置架構上大致分成三個階層:應用程式、平台與基礎設施,並由此分別提供三種型態服務:

圖3:雲端運算架構階層堆疊。(資料來源:Wikipedia)


1.軟體即服務(SaaS)

在此階層中,主要是以雲端應用程式(Cloud Application)來提供各種SaaS服務,存取該服務的使用者不需要下載或安裝任何程式,就可以直接透過瀏覽器存取雲端應用程式所提供的功能與服 務。透過該服務,使用者不用對軟體進行排錯、更新等維護作業,對於使用管理負擔及成本的降低有不小的助益。不僅如此,比起自行建置的系統與程式,SaaS 提供了更高可用性的不中斷服務。

當前市面上不乏許多通行已久的SaaS服務,其中最耳熟能詳的莫過於Google Apps與Saleforce.com。採用P2P技術的Skype、趨勢科技的雲端防毒,以及YouTube、Facebook、Twitter等 Web應用程式,皆屬於不同類型的SaaS服務。微軟在既有商用軟體上,另外提供相對應線上軟體服務也是其中一種。在儲存方面,目前Amazon所提供的 自助式內容分派服務CloudFront,以及支援檔案共享與資料同步化服務的微軟Live Mesh,皆屬於採用分散式雲端儲存技術的SaaS服務。

2.平台即服務(PaaS)

所謂PaaS,指的是提供運算平台或解決方案服務化而言。它仰賴雲端基礎設施之資源,支援雲端應用的不同功能,並提供整合的API。PaaS好處在於應用 程式的部署更簡便、有效降低底層軟硬體架構採買及管理成本。常見的服務包括Microsoft Azure、Google Engine、Google Custom Search、Yahoo! BOSS等。至於Amazon SimpleDB、Amazon S3、Nirvanix等,則屬於提供結構化雲端儲存機制的PaaS服務。

3.基礎設施即服務(IaaS)

至於IaaS意指雲端基礎架構(Cloud Infrastructure),也就是將運算、儲存及網路等資源轉化為標準化服務,以提供內外部使用者存取之用。為了讓資源有效管理與應用,IaaS多 半藉助虛擬化技術來完成伺服器整合之基本作業。目前市面上的IaaS服務,在運算資源分派服務上,有Amazon CloudWatch,以及提供虛擬機器服務的Amazon EC2;在網路資源分派服務上,則有Amazon VPC虛擬私有雲端;在原生儲存資源分派服務上,則以Amazon EBS為代表。

除了上述三個服務階層外,整個雲端運算架構中還有最頂層的用戶端,以及最底層的伺服器。對於雲端運算而言,其服務對象即為用戶端。用戶端可透過桌機、筆 電、Thin Client,甚至手機、PDA等行動裝置內建的瀏覽器來存取雲端運算服務。

就Thin Client與手機等裝置來說,裝置本身並不需要強大的硬體效能,也不用安裝任何軟體,只要有簡單好用的瀏覽器,就可以隨時隨地享受雲端服務所帶來的種種 好處。至於伺服器,當然是雲端運算提供各種服務的最重要基礎設備,即使是可以提昇整合效率的虛擬化軟體,也必須藉助伺服器的安裝才行。在伺服器類型上,同 時具備高密度運算容量,並有效提昇管理及佔用空間效益的刀鋒伺服器愈見青睞。


三大雲端部署類型
上述三種類型服務的雲端,若是供企業內部使用,即為私有雲端(Private Cloud),如果是營運商專門建置用來提供外部用戶使用,並藉此營利者稱為公共雲端(Public Cloud),說明如下:

圖4:雲端運算部署型態。(資料來源:Wikipedia)



公共雲端

一般雲端運算多半是指公共雲端而言,又稱為外部雲端(External Cloud)。其服務供應商能提供極精細的IT服務資源動態配置,並透過Web應用或Web服務,提供網路自助式服務。對於使用者而言,完全不需知道伺服 器的確切位置,或什麼等級伺服器,所有IT資源皆有遠端方案商提供。而且該廠商必須具備資源監控與評量等機制,才能採取如同公用運算般的精細付費機制。 EMC Atmos即為此例。

對於中小型企業而言,公共雲端提供了最佳IT運算與成本效益的解決方案;但對有能力自建資料中心的大型企業來說,公共雲端難免仍有安全與信任上的顧慮。不 論如何,公共雲端改變了既有委外市場的產品內容與型態,提供裝置設定,以及永續IT資源管理的代管服務,對於主機代管等委外市場會產生影響。


私有雲端

私有雲端又稱之為內部雲端(Internal Cloud),相對於公共雲端,此概念較新。許多企業由於對公共雲端供應商的IT管理方式、機密資料安全性與賠償機制,會有信任上的疑慮,所以紛紛開始嘗 試透過虛擬化或自動化機制,來模擬建置內部網路中的雲端運算。

內部雲端的建置,不但提供更高的安全掌控性,同時內部IT資源不論在管理、調度、擴展、分派、存取控制與成本支出上都更具精細度、彈性與效益。其建置難度 不小,當前已有HP BladeSystem Matrix、NetApp Dynamic Data Center等整合型基礎架構方案的推出,以HP BladeSystem Matrix為例,其組成硬體包括BladeSystem c7000機箱,撘配ProLiant BL460c G6刀鋒型伺服器、StorageWorks Enterprise Virtual Array 4400,以及管理軟體工具HP Insight Dynamics-VSE,即試圖藉此方案得以減低建置技術的門檻,在可見的未來取代資料中心,成為資料中心未來蛻變轉型的終極樣貌。


混合雲端(Hybrid Cloud)

所謂混合雲端,意指企業同時擁有公共與私有兩種型態雲端而言。當然在建置步驟上會先從私有雲端開始,待一切運作穩定後再對外開放,企業不但可提昇內部IT 使用效率,也可藉由對外的公共雲端服務獲利。

如此一來,原本只能讓企業花大錢的IT資源,也能轉而成為營利的工具。企業可將這些收入一部分用來繼續投資在IT資源的添購及改善上,不但內部員工受益, 同時也提供更完善的雲端服務。也因為如此,混合雲端或許會成為今後企業IT建置的主流模式。此型態的最佳代表,莫過於提供簡易儲存服務(Simple Storage Service;S3)及彈性運算雲端(Elastic Compute Cloud;EC2)服務的亞馬遜(Amazon)。


雲端儲存的樣貌
如前述,雲端儲存是指雲端運算架構中的儲存部分,從底層的IaaS、中層PaaS到頂層SaaS都可以看到其身影,其中尤以底層儲存資源的網路服務化最為 重要。或許可以簡單地說,雲端儲存就是儲存即服務(Storage as a Service)的意思。

事實上,雲端儲存既可以看做雲端運算架構中的重要組成份子,當然也可以個別拉出成為獨立的Web服務。就像雲端運算的組成架構一樣,一個完備的雲端儲存也 有許多階層,雖然劃分方式及名稱不同,但與前者階層架構仍有許多相似之處。

舉例來說,雲端儲存的核心即為儲存層,就如同雲端運算中的IaaS階層,是由分散在不同區域的各類型儲存設備所組成,不論是DAS,抑或FC SAN、iSCSI或NAS等IP儲存設備,皆可透過支援儲存虛擬化技術的集中化管理系統整合在一起。透過管理系統,可以進行所有儲存設備的遠端監控、排 錯等作業;而最重要且最困難的部份則是應用中介層,此類似於雲端運算中的PaaS階層,必須達到不同儲存設備間的協同運作,並提供單一整合服務。

在使用上,使用者不論身在何處或任何時間,只要透過Web-based應用程式,即可上網直接存取資料。即時面對任何特定需求,例如串流資料檔之存取,雲 端儲存系統也可隨時動態新增擴充來加以支援。

再就傳輸介面來說,HTTP可說是最通用的通訊協定。換句話說,它使得使用者只要透過瀏覽器便可遠端存取資料,而不必進行任何編碼程序,同時相對應的應用 程式會隨即被啟動呼叫。但為了解決網路資料的定址與操作問題,具備URI定址能力,並支援CRUD操作原理的REST介面,遂成為當前許多雲端儲存產品一 致採用的資料物件介面。

對於雲端運算所啟動的映像檔,雲端儲存大多能透過傳統區塊及檔案介面,像是iSCSI或NFS來提供。這些映像檔為虛擬機器所掛載,並派送到使用雲端運算 的用戶系統上。至於傳統磁碟及檔案系統也能一樣地被配置。雲端運算應用軟體,一旦被運行,當然也能使用資料物件介面。

比起專用設備,雲端儲存的最大特點不在功能或介面上,而在於隨選派送功能的支援上。更重要的是,它可實現不同儲存裝置之間的協同運作。面對區塊儲存或檔案 系統,雲端儲存可對單一LUN或虛擬Volume提供精細的分配外,實際的儲存空間能被隨需配置,同時並採取用多少就付多少的付費機制。

藉由一些壓縮或資料重複刪除等技術,並可進一步減少儲存空間的用量。針對儲存管理,則多半採用典型之頻外(Out-of-band)標準資料儲存介面,另 外也可透過API,抑或Web-based使用者管理介面。該介面當然也可以將快照與複製等其他資料服務功能納入。


首要解決異質平台協同問題
不論是雲端運算或雲端儲存,虛擬化技術都是其中不可或缺的重要促因與基礎。但儲存虛擬化並不像推展已久的伺服器虛擬化那麼普及與順利,因為其中仍有許多待 解決的難題存在。

這是因為當前各種儲存方案與技術十分繁雜而多樣,光從一家企業內部可能同時存在各種不同類型儲存裝置的狀況便知一二。更何況不同儲存設備供應商間的儲存環 境一直存在相容性問題,所以喊了多年的儲存整合,仍舊難以如企業需求所願,這也是儲存虛擬化與雲端儲存推展上的最大阻力。

雖然儲存雲端在某方面很容易跨入(例如線上儲存與備份),但另一方面想要透過私有雲端儲存來達成全面性之儲存整合,似乎不是那麼容易的事情。對此,HP建 議指出,想要成功完成儲存虛擬化目標必須改善企業既有IT儲存環境,其改善重點不外共通分享的儲存架構、親和的使用環境、簡潔單一的操作介面,以及效能卓 著的儲存方案等。其中,不論是單一操作介面或統一標準的API,更是解決不同儲存裝置間協同問題的關鍵之一。(圖5)

圖5:虛擬化儲存架構的層級分類。(資料來源:HP)


對於IaaS基礎架構而言,擁有一個可程式介面,意味著使用者可以撰寫一個可透過該介面來管理雲端使用狀況的用戶端軟體,而這也是當前充斥許多API的原 因。不僅如此,許多雲端方案供應商並且免費地授權其專利API,好讓使用者能夠藉此打造出相同的雲端基礎架構。

儘管有許多Open API,但是許多雲端社群會員已經開始放慢制式地採用單一公司專利介面的腳步。雖然開源社群開始一些嘗試性的回應動作,但仍無法扼止API激增的狂潮。事 實上,對於雲端運算而言,其所需要的標準API,應該得符合中立特色,同時廠商實施風險最小且最穩定可靠才行。如此才可讓客戶將其應用程式堆疊從一個雲端 供應商,方便無礙地轉移到其他供應商。


OCCI開放雲端運算介面
面對上述問題,開放網格論壇(Open Grid Forum, OGF)早已成立專責介面標準化的工作小組。其所制定的開放雲端運算介面標準(Open Cloud Computing Interface, OCCI),即為一個免費、開放、為社群共同接納推動,且以雲端基礎架構服務為鎖定目標的介面標準。藉由該API,資料中心與雲端夥伴可以免受現有一堆專 利或開放雲端API之間歧異不相容之苦。

面對雲端基礎架構服務所組成之關鍵元件,目前OCCI是採用資源導向架構(Resourced Oriented Architecture, ROA)來表示。同時,每個由簡潔URI標示的資源可擁有許多不同的描述呈現方式(例如可以超文件來表示)。OCCI工作小組正規劃在API中加入許多格 式的支援,在初始版本中,Atom/Pub、JSON及Plain Text等標準都被納入支援行列中。

該版本並且規定一個單獨URI進入點(Entry Point)定義一個OCCI介面,該介面顯示「Nouns」內含屬性,其中的「Verb」會被執行。原則上,該屬性會以鍵值對(Key-value pairs)表示,而適當的動詞則以連結(Link)表示。重要的是,該屬性會以URI來描述。(圖6)

圖6:OCCI介面URI對齊IaaS資源示意圖。(資料來源:SNIA)


該API不僅提供CRUD操作,且分別與HTTP Verb的POST、GET、PUT及Delete等參數相對應。HEAD與OPTIONS等Verb參數可用來檢索詮釋資料(Metadata)與有效 操作,而不需要實體主體來增進效能。所有HTTP功能均能利用現有網際網路基礎架構,包括快取、代理、閘道及其他進階功能。再者,所有詮釋資料,包括資源 間的關聯性會透過HTTP表頭對外公開。該介面原生地以ATOM表示,並盡可能地接近底層HTTP協定來執行。

OCCI會提供對基礎架構服務之定義、創建、部署、操作及退出的管理功能。透過簡易服務生命週期模型,可支援由雲端供應商提供的基本通用生命週期狀態。在 事件中,供應商並不會提供或報告服務生命週期狀況,OCCI並不會強制遵行,而是將生命週期模型定義成提議書,供雲端供應商遵循。

參照OCCI,雲端運算用戶端可啟動執行全新應用程式堆疊,並管理其生命週期與其採用的資源。為了執行像是來自SNIA CDMI介面所導出的應用程式堆疊,透過OCCI介面即可分派儲存至特定虛擬機器。SNIA機構並表示,接下來該組織會進一步對儲存管理與其中資料管理之 方法途徑進行檢驗。

圖7:OCCI介面架構圖。(資料來源:SNIA)



擔負雲端儲存標準介面制定重任的SNIA
在介紹完雲端運算的標準介面之後,接著讓我們看看雲端儲存統一標準介面的制定狀況。國際間致力於儲存標準制定工作的儲存網路產業協會(Storage Networking Industry Association, SNIA),是當前雲端儲存標準的主要推動者,致力於儲存系統統一標準與API介面的開發作業,用以集中搜尋、監控並管理不同廠牌及標準的儲存設備。

由於各家儲存系統的標準不一,異質儲存裝置所構成的網路儲存系統的協同管理,一直是當前最急迫待解的問題。透過標準化介面,即使各家系統內部各有不同的運 作功能與標準,但仍能透過統一介面進行溝通,從而實現並發揮協同管理的最大效益,且各家產品仍能保留進行自身標準及技術功能的研發。


雲端儲存計畫正式推動
對於雲端儲存發展有著里程碑一般深遠意義與影響的,莫過於SNIA組織於2009年10月12日對外發佈雲端儲存計畫(Cloud Storage Initiative, CSI)的正式推動。該計畫是在2009年秋季舉行的年度盛會-儲存網路世界大會(SNW Fall 2009)上正式發表。發起成員包括EMC、HP、HDS、LSI、NetApp、Sun、Symantec與Xiotech(Seagte子公司)。 CSI計畫的工作內容主要包括雲端儲存技術及標準的推廣與技術合作,同時並與業界共同推廣雲端儲存相關技術的培訓、開發與應用發展。

當前雲端儲存互通性與協同管理的最重要且急迫的工作,莫過於統一標準介面的制定。對此,SNIA特別成立專門性的雲端儲存技術工作小組(Techical Working Group, TWG),如圖8,目前該小組已有30家廠商共140名技術成員的加入。該小組會與SNIA、CSI各單位及會員,乃至其他雲端產業組織共同合作。其主要 工作項目大致包含開發雲端儲存參考模型、最佳應用方案與實例。當然最重要的任務莫過於制定雲端儲存產品之統一管理標準介面(亦即CDMI標準API的制定 與推廣)。(圖9)

圖8:SNIA雲端儲存技術工作小組組織架構圖。



圖9:雲端儲存參考模型。(資料來源:SNIA)



CDMI雲端儲存全新標準介面
目前由SNIA草擬的CDMI(Cloud Data Management Interface)介面標準之最新版本為0.80版,預計明年將會推出正式的1.0版。由於各家儲存方案介面標準不一,所以當前不論是儲存虛擬化或雲端 儲存,皆深為儲存資源無法有效協同運作的問題所苦。對此,CDMI介面的制定,就是為了強化雲端儲存與資料管理的協同作業。

在CDMI架構中,被上層介面所揭示的下層儲存空間,是以抽象化的容器(Container)概念來表示。所謂容器不僅僅是儲存空間的有用抽象化,同時也 做為儲存在其中資料的群組,抑或總體應用數據服務的控制點。至於CDMI不只提供具備CRUD基本操作概念的資料物件介面,同時也可以用來管理被雲端運算 基礎架構所傳送使用的容器。

對於雲端運算來說,CDMI提供了通用雲端運算管理基礎架構,同時原本資訊管理的重點已漸漸從儲存管理轉移圍繞在資料管理上。CDMI標準則可以協助使用 者將特殊詮釋資料(Metadata)標記在資料上,該詮釋資料會告訴端點儲存供應商,什麼樣的資料服務提供該資料(例如備份、歸檔、加密等)。

這些資料服務都會將鍵值加入到使用者存在雲端上的資料中,然後透過CDMI標準介面的執行,使用者可在不同雲端供應商間任意移動資料,而不再需要忍受不同 介面中一再重新編碼的痛苦。


標準化運算及儲存的協同運作
再就可存取的CDMI容器來說,其不僅藉由CDMI做為資料通道,同時也可採用其他協定來存取資料,尤其是以CDMI做為雲端運算環境的儲存介面。輸出的 CDMI容器能被雲端運算環境中的虛擬機器當成每一個用戶上所顯示的虛擬磁碟機來用。

較令人期待的是,雲端運算基礎架構管理可同時支援OCCI及CDMI兩種標準介面。為了達成協同運作,CDMI內含可導出OCCI介面所獲得的資 訊,OCCI則提供被導出CDMI容器相對應的儲存。

其操作執行的範例如下:
1.用戶端透過CDMI介面創建一個CDMI容器,並將其轉換成一個OCCI導出型態。CDMI容器ObjectID會回報結果。
2.用戶端接著透過OCCI介面創建一個虛擬機器,並藉由該ObjectID附加一個CDMI類型之儲存容量。OCCI虛擬機器ID會回報結果。
3.接著用戶端以OCCI虛擬機器ID進行CDMI容器物件導出資訊的更新作業,如此才能讓虛擬機器存取該容器。
4.最後用戶端再透過OCCI介面啟動虛擬機器。

OCCI及CDMI可說是專門讓雲端運算及雲端儲存達成協同運作的標準化作業(圖10)。該標準是透過OGF與SNIA兩者間的策略聯盟,以及透過跨 SDO雲端標準協同小組之協調一致才達成。OCCI可充份利用CDMI已配置好,以及設定完成的儲存。一旦兩個介面採用相同原理及技術,單一用戶將能同時 管理應用程式的運算與儲存需求,並且符合配置在兩介面上需求的同時擴展。

圖10:整合式雲端運算環境CDMI及OCCI介面協同運作架構。(資料來源:SNIA)



小結
雲端儲存與雲端運算一樣,必須經由網路來提供隨選分派的儲存資源。重要的是,該網路必須具備良好的QoS機制才行。對於用戶來說,具備彈性擴展與隨使用需 求彈性配置的雲端儲存,可節省大筆的儲存設備採購及管理成本,甚至因儲存設備損壞所造成的資料遺失風險也可因此避免。總之,不論是端點使用者將資料備份到 雲端,抑或企業基於法規遵循,或其他目的的資料歸檔與保存,雲端儲存皆可滿足不同需求。

至於IT資源要能實現彈性隨需配置,還須仰賴各種不同平台領域之間的協同工作才能達成。而國際標準的制定,正有助於整個雲端運算相關產業的應用發展,讓雲 端的精神不再那麼遙不可及,而是落實到實際IT架構的應用。



【原文刊載於RUN!PC雜誌:2009年11月號】

(繼續閱讀...)
文章標籤

unix 發表在 痞客邦 留言(0) 人氣(178)

  • 個人分類:雲端技術
▲top
  • 6月 07 週一 201015:12
  • Inui 市場新訊╭★ 關鍵字典-API 7869768

Inui 市場新訊╭★ 關鍵字典-API

應用程式介面(Application Programming Interface,簡稱API),又稱為應用編程介面,就是軟體系統不同組成部分銜接的約定。由於近年來軟體的規模日益龐大,常常會需要把複雜的系統劃分成小的組成部分,編程介面的設計十分重要。程式設計的實踐中,編程介面的設計首先要使系統的職責得到合理劃分。良好的介面設計可以降低系統各部分的相互依賴,提高組成單元的內聚性,降低組成單元間的耦合程度,從而提高系統的維護性和擴充套件性。

 

概要

應用程式介面為:「『電腦作業系統(Operating system)』或『程式函式庫』提供給應用程式呼叫使用的程式碼」。其主要目的是讓應用程式開發人員得以呼叫一組常式功能,而無須考慮其底層的原始碼為何、或理解其內部工作機制的細節。API本身是抽象的,它僅定義了一個介面,而不涉入應用程式如何實現的細節。

(繼續閱讀...)
文章標籤

unix 發表在 痞客邦 留言(0) 人氣(39)

  • 個人分類:B.資訊應用
▲top
  • 6月 07 週一 201014:21
  • Inui 程式開發╭★Visual Studio Application Lifecycle Management 使用者入門

Inui 程式開發╭★Visual Studio Application Lifecycle Management 使用者入門
Visual Studio Application Lifecycle Management 使用者入門
此內容是經過人為翻譯以達更高的品質標準。如欲同時瀏覽本網頁和英文原文,請點選「偏好設定」並選擇 「傳統」為偏好瀏覽方式。

當小組開始使用 Visual Studio Application Lifecycle Management (ALM) 時,系統管理員會設定伺服器,專案管理人員會建立 Team 專案,其他小組成員則會設定工作環境。如需 Visual Studio Team Foundation Server 組態選擇的詳細資訊,請參閱Planning for Visual Studio Team System。

Team Foundation 的系統管理員工作
  1. 安裝 Team Foundation Server。

    1. 下載 Team Foundation 的安裝指南,並用於將 Team Foundation Server 安裝在您的伺服器上。

      如需詳細資訊,請參閱 Microsoft 網站上的這個主題:Team Foundation 的安裝指南 (英文)。

    2. 根據您的授權及原則,讓小 組成員可使用 Team Foundation 的用戶端。

      如需如何在您的網路上散發 Team Foundation 的用戶端,請參閱Setup User Permissions and Advanced Options。

  2. 在 Team Foundation Server 中設定專案管理。

    1. 如果您升級現有的 Team Foundation Server 安裝,請將 Team 專案組織成 Team 專案集合。

      如需詳細資訊,請參閱使 用 Team 專案集合組織您的伺服器。

    2. 授與專案管理員建立專案所 需的使用權限。

      如需詳細資訊,請參閱 設 定 Team Foundation Server 的系統管理員權限。

  3. 如果您有任何小組會使用 Lab Management,請在 Team Foundation Server 上加以設定。如需詳細資訊,請參閱Configuring Lab Management in Team Foundation Server。

  4. 安裝適當的系統,讓您的 小組可以在遠端部署組建和執行測試。

    1. 如果您的小組將使用 Visual Studio Lab Management,請安裝 Microsoft System Center Virtual Machine Manager 及您的虛擬機器,然後設定 Lab Management。

      如需詳細資訊,請參閱使 用 Team Foundation 管理主控台設定您的伺服器。

    2. 如果您的小組不會使用 Lab Management,請在實體或虛擬機器上安裝測試控制器及測試代理程式。

      如需詳細資訊,請參閱設 定測試電腦以便執行測試或收集資料。

  5. 如果您的小組會使用 Team Foundation Build,請安裝在一部或多部伺服器上。

    如需詳細資訊,請參閱設 定和管理 Team Foundation Build。

專案管理員的工作
  1. 安裝您會使用的 Team Foundation 的用戶端。

    如需詳細資訊,請參閱安 裝 Visual Studio。

  2. 選擇流程範本。

    如需詳細資訊,請參閱選 擇流程範本。

  3. 在您要建立的 Team 專案中決定專案集合。

    如需詳細資訊,請參閱使 用 Team 專案集合組織您的伺服器。

  4. 建立 Team 專案

    如需詳細資訊,請參閱 建 立 Team 專案。

  5. 設定版本控制。

    如需詳細資訊,請參閱管 理 Team Foundation 版本控制。

  6. 如果您是使用 Team Foundation Build,請為每個 Team 專案建立組建定義。

    如需詳細資訊,請參閱 建 置應用程式。

  7. 將使用 Team 專案所需的權限授與小組成員。

    如需詳細資訊,請參閱 將 使用者加入至 Team 專案。

個別小組成員的工作
  1. 安裝您會使用的 Team Foundation 的用戶端。

    如需詳細資訊,請參閱安 裝 Visual Studio。

  2. 設定您的版本控制工作區。

    如需詳細資訊,請參閱使 用工作區和將 檔案放入版本控制下。

請參閱

概念

Visual Studio Application Lifecycle Management

(繼續閱讀...)
文章標籤

unix 發表在 痞客邦 留言(0) 人氣(13)

  • 個人分類:C.程式設計
▲top
«1...5051

文章搜尋

文章分類

toggle E.法律領域 (3)
  • 合約書範本 (4)
  • 版權與使用 (1)
  • 資安研究 (4)
toggle D.商務邏輯 (3)
  • 財務金流 (1)
  • 架構流程 (4)
  • 雲端技術 (3)
toggle F.生活有感 (15)
  • inui 圖書館 (16)
  • inui 視聽教室 (56)
  • inui 自習時間 (35)
  • inui 福利社 (9)
  • inui 電競課 (5)
  • inui 美勞課 (4)
  • inui 保健室 (53)
  • inui 體育課 (2)
  • inui 食堂 (3)
  • inui 郊遊去 (4)
  • inui 綠色地球 (5)
  • inui 財經課 (3)
  • inui 語言教室 (2)
  • inui 新聞室 (1)
  • inui 夢遊中 (18)
toggle G.玩味設計 (6)
  • 生活品味 (8)
  • 機械動力 (6)
  • 文具繪圖 (4)
  • 室設建築 (11)
  • 灣刀台丸 (2)
  • 活在未來 (1)
  • A+管理職涯 (17)
  • B.資訊應用 (97)
  • C.程式設計 (37)
  • 未分類文章 (1)

我正在閱讀的書

Donate us

熱門文章

  • ()Inui 好文分享關鍵字典-saas,paas,iaas
  • ()國科會自由軟體專案研究計劃需求規格書參考範例 (SRS)
  • ()日本串燒店中日文菜單
  • ()Inui 原創分享uni kurutoga 三代 クルトガエンジン
  • ()高雄手工藝品店
  • ()Inui 藝文庫 馬克.夏卡爾 Marc Chagall 生平暨作品賞析
  • ()Inui 原創分享 試試這味道,高雄國民市場客家麻糬
  • ()Inui 生活品味陳綺貞:用底片機画出詩意影像
  • ()Inui 郊遊去台北住宿資訊
  • ()Inui 夢遊中周公解夢-夢見針

最新文章

    參觀人氣

    • 本日人氣:
    • 累積人氣:

    訪客行為

    http://unix116.pixnet.net

    無料贊助

    Site Explorer