精選文章

[新聞|產業] 大型企業儲存廠商面臨市場寒冬

大部份的儲存系統大型製造商在將要過去的 2016 年都不太好過;不過,這究竟只是另一個寒冬,還是根本就是冰河期的開始?春天還會不會來呢?在即將步入 2017 年的這個時候,這些儲存廠商的心裡只怕是五味雜陳吧! 根據最新的 IDC 全球企業儲存系統追蹤季報 (IDC World...

2016年9月13日

[企業儲存觀察室|技術] 物件儲存是什麼?

這又是一個國內應用落後於全球市場的場景。筆者理解到物件儲存 (Object Storage) 大約是 5 年前左右,然而這 5 年來國內的企業儲存市場,別說是應用、即便是聽說或理解什麼是物件儲存都很少。少是因為如果沒有第三方應用/軟體的整合,單獨的一個物件儲存系統,還真是不知道能幹嘛?


但近 2 年來,隨著廠商們在物件儲存的基礎上,發展出更多的、更易於使用的儲存產品,如 NAS 應用或類 Dropbox 的雲端檔案共享應用,再加上第三平台的應用興起,漸漸地物件儲存開始進入國內企業用戶的視線。

以一個在大家生活周遭的應用來解釋物件儲存可能會容易一些。當我們在 Facebook 貼上一張照片時,它會在後台的儲存上產生一個檔案,如果使用傳統的檔案儲存如 NAS 的話,應用系統就必須要知道這個檔案的儲存路徑與檔名。當你在這張照片加上拍攝時間、地點、人物、活動名稱等用來闡釋這張照片的標記 (Tag) 時,應用系統就必須要在資料庫中新增一筆資料,這筆資料的內容就包含檔案路徑與大小不一、數目不定的這些 tag。熟悉資料庫系統讀者會發現,結構化的資料庫系統其實是無法處理這種具有變動性的資料格式的。

當你的朋友看到你分享的這張照片時,他可能會轉發,可能會加入自己的 tag,於是同一個原始檔案不同的使用者加入不同的 tag,這時候該如何處理呢?要不就把使用者也當做 tag,或是複製這張照片,加入新的 tag;總之,就是要產生一筆新的資料。我們只要稍微想想目前在社群網站上的照片數目,就可以知道應該沒有任何一個資料庫系統或檔案系統足以支撐這種規模的資料量。

這種資料儲存架構(如果可行的話),它應該不會是集中式的,接下來還要考慮如何進行資料備份?或是如何在全球各地都建立一套這樣的資料儲存,並且在資料儲存間進行同步作業?

物件儲存的工作原理和標準的檔案儲存不同;物件儲存將資料放到一個大小可變動的容器(就是物件)中,每一個物件具有一個唯一的 ID(而非檔案名稱),和包含詳細屬性的元資料 (Metadata),也就是在上面例子中的 tag。Metadata 不只是儲存像 tag 這樣的資料,它也可以是物件本身的儲存策略,例如物件的生命週期管理資訊:當物件超過六個月沒有被存取時,就把它移到最低層級的儲存媒體上;或是物件的資料保護資訊:每一個物件要複製四份,分別存在全球七個資料中心其中的四個中。

因此,前述 Facebook 照片的例子,如果使用物件儲存時就很容易處理了。當照片複製時,只要再產生另一個物件的 ID,指向原始的檔案位置就行,這個新的物件可以有自己的 metadata。它跟原始物件是不同的兩個物件,可以不同的儲存策略。

由於物件儲存不依賴 LUN 和資料卷,因此可以容易的進行不中斷擴展,將新的儲存容量加入到正在運行的系統中。大部份的物件儲存都不需要大規模的升級,或重新配置,即使是硬體升級也是一樣,這有點像橫向擴展 (Scale-Out) 儲存,每一個廠商的物件儲存所能支援的節點數都有其限制,但就容量上來說應該都大到足以支援絕大部份的企業用戶所需。

除了 metadata 外,另一個物件儲存和標準檔案儲存不同之處,就在於物件儲存使用 REST API 來存取資料,這也是為什麼物件儲存在初期很少人使用的原因;使用 RESTful 連接界面也就意味著不經由軟體是無法直接存取物件儲存中的資料的。近來有些廠商將物件儲存與標準檔案系統融合,提供除了 REATful 之外,包括 CIFS, NFS, 與 OpenStack 等檔案存取界面,藉由這些存取界面,企業用戶就可以更容易將物件儲存融合進現在儲存架構中。

但物件儲存的效能通常不如檔案儲存,雖然有多方法可以用來提昇存取的速度,但通常來說物件儲存最好的應用場景包括資料的長期歸檔、資料備份與資料的二次應用,而不是經常存取的線上交易資料;在某些情形(如不講求資料效能)下,物件儲存可以替代二/三級儲存或大型的檔案儲存。