2014年6月27日 星期五

自動分層讓混合儲存發揮最大效益

 
每週二∼六出刊.2014.06.28
 
本 期 目 錄 簡介/舊報明細
自動分層讓混合儲存發揮最大效益
混合式固態儲存設備|Dell Compellent SC8000
臉書發表首款開放網路交換器
是否Lambda一下?
App Annie&IDC:Google Play年營收成長250%
時尚【-4℃涼感POLO】↘399
比它牌省百元!【吸排+除臭】清爽一整天!

優惠訊息

. 號召IT青年與菁英,加入關注資訊科技的行列
. 行銷!就用中文網址輔助
. 日日新軟體、時時有更新,登入再下載、小當家通知你!

專題報導 

自動分層讓混合儲存發揮最大效益

透過自動分層儲存技術,可以讓SSD與傳統硬碟組成的混合架構,同時兼顧效能、容量與總體持有成本的需求

這是一個不平衡的世界,極少數富人占有絕大多數的財富、少數幾家領導品牌廠商占有整個業界絕大多數的利潤……,類似的,這種由80/20法則所描述的不平衡現象,在IT儲存應用領域也是普遍的情況——儲存設備的大部份效能,其實是由一小部份應用所消耗。這也是說:絕大多數的應用其實都不會耗去太多I/O效能,所以我們只需為那少數極耗I/O效能的關鍵應用,準備少量高效能儲存裝置即可,至於其他應用的儲存需求,則可用便宜的低價儲存設備來滿足。

混合儲存的效益——把高效能裝置用在刀口上

從儲存裝置本身的特性來看,SSD效能高,但單位容量成本也高;傳統硬碟單位容量成本低,效能也相對較差。

以80/20法則來看儲存系統的配置,採用全SSD的配置是不合理的——由於實際上只有一小部份應用會需要SSD的高效能,不分應用緊要與否、一律給予SSD資源,顯然不合成本效益;但傳統的全硬碟配置也已逐漸不敷使用,傳統硬碟雖然足以應付I/O需求不高的一般應用,但受先天架構所限,必須透過組成大規模陣列的笨拙方式,才能拼湊出關鍵應用所需的高I/O效能,為了一小部份關鍵應用的高I/O需求,往往必須耗費數十臺甚至上百臺硬碟組成陣列,即便滿足了I/O效能,但也耗費了大量空間與電力,顯然也不合乎效益。

因此為了兼顧效能與成本,同時使用SSD與傳統硬碟的混合儲存架構,才是當前IT環境最合理的做法,在儲存設備中混用小比例的SSD(一般來說占總儲存容量10∼15%即可),即足以因應一小部份關鍵應用的高I/O需求,其餘應用則透過傳統硬碟來提供儲存服務。

自動分層技術讓混合架構真正實用化

就原則來看,同時使用SSD與傳統硬碟的分層架構,是最合理與最具效益的儲存配置。但在實務上,這種混合架構將面對如何將各式各樣的資料放置到合適儲存層的困難。

理論上,我們可使用人工來進行分層儲存配置工作,由MIS預判各主機應用程式的I/O需求,然後分別配置不同層級的儲存資源,並視I/O運行狀態的變化來調整儲存資源配置。

然而這種人工調整儲存資源配置的方式,對於個人端或極小規模的應用環境或許適用,但對於企業IT環境實際上是不可行的。

首先,企業環境規模龐大,儲存系統必須服務數量眾多的主機與應用程式;其次,各主機與應用程式的I/O需求會隨時間而變化。面對數量眾多、且會隨時間變化的前端主機應用程式,為了讓儲存資源維持在最佳配置,將必須持續追蹤各主機應用程式的I/O負載變化,並針對I/O負載變化,頻繁地調整儲存配置,這將帶來非常龐大的管理作業負擔,遠超過人工作業所能負擔的程度。

因此唯有透過自動化的分層儲存與資料遷移技術,才能讓分層儲存架構真正步入實用化,由軟體來執行I/O存取負載的追蹤與統計工作,並依照預設政策或演算法,自動在各儲存層間遷移資料,從而自動讓整個儲存資源的配置達到最佳化。這也就是說,如何「自動化」,才是分層儲存的關鍵。

 閱讀全文
產品評測 

混合式固態儲存設備|Dell Compellent SC8000

搭載不斷進化的老牌自動分層儲存技術,新版本提供精細分層機制,可同時支援SLC與MLC兩種SSD

在2010年併入Dell的Compellent是自動分層儲存領域的先驅者,目前在Dell旗下的Compellent系列產品,包括舊款的SC 40、當前的產品主力SC8000,以及剛發表的新款中階機型SC4020,全都支援專屬的Data Progression自動分層技術。

我們這次介紹的是Dell Compellent產品線當前主力SC8000,本身是採用2顆6核心處理器的控制器,用戶可選擇搭配2U/12Bay的SC200或2U/24Bay的SC220磁碟櫃,或5U/84Bay的SC280高密度磁碟櫃,最大可支援960臺磁碟。

用戶可視需求混合搭配不同類型的磁碟裝置,包括3.5吋的1.5萬轉或7200轉SAS硬碟,2.5吋的1.5萬轉、1萬轉與7200轉SAS硬碟,以及2.5吋的SSD等。

基於獨特RAID架構的自動分層

Dell Compellent的Data Progression自動分層儲存,是奠基於Compellent Storage Center作業系統動態區塊(Dynamic Block)技術的一項應用功能,不同於傳統磁碟陣列是以實體磁碟機作為構成RAID群組的單位,Storage Center作業系統底層的RAID架構,是以預設4096個512KB區塊組成的2MB Page Pool為基本單位,利用散布在所有實體磁碟機上的Page Pool,來組成不同層級的RAID與Volume。

而Data Progression則可利用底層的動態區塊技術,透過metadata來記錄每個動態區塊的建立╱存取╱修改時間、存取頻率,以及所處的RAID與儲存層級等資訊,據此來執行分層遷移資料。

簡便的儲存分層設定

當用戶將硬碟群組納入SC8000時,Storage Center作業系統會視硬碟類型與選用的RAID層級,自動將其歸類於3個層級其中之一,接下來當用戶建立Volume時,可透過選擇欲Profile屬性,來分別套用不同的分層設定。

Profile是Storage Center用於設定個別Volume可使用儲存層的參數集,系統已預設了幾種Profile供用戶直接套用,用戶也可自行建立新的Profile,並隨時替Volume更改Profile。就Data Progression自動分層儲存功能來說,用戶唯一要做的,只有為Volume選擇要套用的Profile。

若用戶選擇使用的Profile,允許讓Volume同時使用跨不同層級的磁碟層,接下來系統便會持續監視每個區塊的存取頻率,並定期視存取頻率自動將區塊搬移到適當的磁碟層級。

 閱讀全文
專題報導 

臉書發表首款開放網路交換器

Facebook正式發表自行設計的置頂式交換器(代號Wedge),以及代號FBOSS的交換器作業系統

繼Google及Amazon相繼打造自家網通設備後,Facebook也於6月下旬正式發表自行設計的置頂式交換器(代號Wedge),以及代號FBOSS的交換器作業系統。這兩項產品是Facebook開放運算計畫(Open Compute Project,OCP)網路專案的初步成果。

OCP是Facebook於2011年成立的一項非營利計畫,旨在以最低的成本打造最具效益的運算架構,涵蓋伺服器、儲存、資料中心及網路等,並以開放硬體及軟體的型態邀請產業共襄盛舉,已有超過50家軟、硬體業者加入,如Intel、AMD、Broadcom、Cumulus Networks、VMware等。因此,Facebook早在去年中就宣布,在OCP計畫下啟動了制定網路交換器開放規格的專案,目標是打造出軟體層可以和硬體層無關的網路交換器設備。Broadcom、Intel、Mellanox與 Accton等業者也貢獻了交換器的硬體設計,而Cumulus Networks以及Big Switch Networks亦已捐贈交換器軟體。

 閱讀全文
專欄 

是否Lambda一下?

在Lambda語法的直接支援下,選擇哪種工具解決問題都很方便,而且等於多一個思考角度

林信良
因在網路上經營「良葛格學習筆記」(openhome.cc)而聞名,曾任昇陽教育訓練中心技術顧問、甲骨文教育訓練中心授權講師,目前為自由工作者,從事講師、技術書籍寫作與翻譯,專長為Java 程式開發相關技術教育訓練,研究興趣包括:程式語言、Web 相關開放原始碼框架。閒暇之餘記錄所學,技術文件涵蓋 C/C++、Java、Ruby/Rails、Python、JavaScript 等領域。

目前JDK8引進了Lambda專案,包括了Lambda語法、方法參考(Method reference)、Stream API、函數式風格API,以及平行處理等重大特性,如果你要轉進JDK8了,那麼,是不是過去可用的方式,都要改採Lambda的相關特性來實現呢?

面對一個問題會有多種風格的解法時,你是否一定要選擇Lambda呢?

可讀性考量

從最簡單的角度來看待Lambda語法,就是將之當作匿名類別(Anoynmous class)的語法蜜糖,不用理會類別名稱,也不用管方法名稱,在型態推斷(Type inference)的輔助下,連參數型態與傳回型態都可以省略,撰寫程式時可以少打一些字,對減少程式碼數量是有幫助。

然而,減少程式碼數量不見得有助於可讀性,如果拿掉匿名類別語法上的名稱與型態資訊,反而使得你必須察看API文件才能理解程式碼(特別是在沒有IDE輔助下),那麼你就不應當使用Lambda語法,是否使用方法參考,也是視程式碼展現的可讀性而定。

JDK8中有許多搭配Lambda語法的高階API,這類API抽取了可重用的流程,在名稱上顯露出高階語義,自然地,當你使用它們時,要確認自己(或夥伴)瞭解名稱代表什麼,且不在意內部實作細節,否則的話,反而會在閱讀程式碼時失去了直覺而感到困惑。

舉例來說,Map的forEach語法在迭代鍵值很值得使用,因為相較於使用for迴圈來說,可讀性高且forEach名稱清楚易懂。相對地,如果若原本有段直覺的程式碼:

List itemNames = new ArrayList<>();
for(Order order : orders) {
for(LineItem lineItem : order.getLineItems()) {
itemNames.add(lineItem.getName());
}
}

不用任何說明,從程式碼中可以一眼看出來,執行目的是從每個訂單中收集品項名稱,你可以試著將之改成Lambda版本,兩個版本要撰寫的程式碼數量其實是差不多,思考一下,如果你(或夥伴)對於map、flatMap的語義清不清楚,而這些方法又隱藏了可重用的流程細節,對程式碼的閱讀是否會有幫助?

List itemNames = orders.stream()
.map(Order::getLineItems)
.flatMap(lineItems -> lineItems.stream())
.map(LineItem::getName)
.collect(toList());

 閱讀全文
專題報導 

App Annie&IDC:Google Play年營收成長250%

App Annie和IDC在E3展特別報告指出,2014年Q1電玩遊戲在Google Play及App Store總下載量達40%,且行動裝置App營收較去年同期大幅成長,影視業瞄準行動平臺新市場

App Annie和IDC在E3展共同發表特別報告指出,兩大娛樂界臺柱產業,電玩遊戲與電影工業的合作關係越來越緊密,儘管這兩個產業的營利模式迥然不同。自2000年以來,利用電影題材開發的遊戲類型已達24種。

以電影為題材的電玩遊戲類型,多數為城市經營、益智遊戲、無盡奔跑以及卡片對戰,前15名的行動裝置電玩遊戲,其中有8款題材來自動畫或電視影集,而營收前15名的跨平臺遊戲,其中有5款題材來自電視影集。App Annie分析,這意味著行動裝置螢幕與電視螢幕的交互體驗,在未來行銷變得重要。

 閱讀全文
前期文章 全部歷史文章
出刊日期 出刊主題
2014-06-27 軟體架構的演化
2014-06-26 【封面故事】4G來了!新世代行...
2014-06-25 4G LTE服務正式開臺,你知道哪...
2014-06-24 4G黑暗島露出的第一道曙光
主編推薦  
建商不能說的祕密
最美味的下酒菜缺它不可!
夏日保養最容易忽略的部位
找工作和找男友的5個原則
我要訂閱這份報紙 我要取消這份報紙 訂報說明
.本電子報內容由 iThome online 提供
PChome ePaper 電子報版權所有,關於電子報發送有任何疑問,請聯絡 客服中心
廣告刊登消費者保護兒童網路安全關於PChome徵人
網路家庭版權所有、轉載必究 Copyrightc PChome Online

沒有留言:

張貼留言

您或許對這些文章有興趣: