老傢私 QNAP TS-1079 PRO & QTS 4.3.4 新開箱

pctine

5084分

樓主

pctine

個人積分：5084分

文章編號：66790012

Qtier 2.0

有關 Qtier 的介紹, 可以參考官網.

Qtier 自動分層儲存
如何使用 QNAP Qtier™來做資料自動分層以達您儲存裝置效能的最佳化？ (這份資料是舊的)

Qtier 2.0 看影片比較容易了解.

在影片中提及, Qtier 2.0 就是取代 SSD cache

如果沒有理解錯誤, Qtier 2.0 基本上是把 SSD cache 的功能整合進來, 就是在 Storage pool 中是結合 SSD+SAS+SATA 三層儲存, 在 SSD 這層中保留部份空間做為 cache 之用, 同時 SSD層其他的空間是做為儲存 data 空間使用.

不過在影片中並沒有提到, 利用 Qtier 2.0 資料夾自動分層指派時, 若設定為不自動分層的 folder, 那麼裡面的資料是否能被 ssd cache? 理論上必須要能根據存取率被 cache.

由於 TS-1079 Pro 不支援 Qtier, 手上只有 TS-253 Pro 支援 Qtier 功能, 雖然是 2bay NAS, 還是用 SSD+HDD 小測了一下

於建立 storage pool 時直接啟用 Qtier

SSD 做為第一超高速層.

HDD SATA 為第三層.

這樣 SSD+HDD 組合成 storage pool

不能免俗的測了一下 SSD & HDD 的存取效能. 還是希望 QNAP 佛心可以讓 TS-x79 Pro 支援 Qtier, 因為 x79 Pro 的效能比 TS-x53 Pro 好很多

這裡可以看出 Storage pool 的總容量為 SSD+HDD.

Qtier 分層設定

在 Share Folder 建立時, 也多了 Qtier 自動分層此選項.

這就是 Qtier 2.0 所新增的, 由 user 自行排除不需要做自動分層的 share folder.

所謂自動分層就是系統根據檔案的存取頻率分為 hot-data & cold-data, 常被存取的就移到超高速層 SSD, 不常用的就下放到 HDD 層. 由於這搬移工作會耗系統資源, 所以此處可設定執行分層的時段.

手動排程.

控制台的 share folder 管理頁面也加了自動分層選項.

基本上要在短時間內實測 Qtier 是有點難度, 因為它必須較長時間的 "煲" 資料才能看出它的效果.

這裡是某個 share folder 設定為不啟用自動分層的讀寫速度.

Run status group 0 (all jobs):
READ: io=10444MB, aggrb=177977KB/s, minb=177977KB/s, maxb=177977KB/s, mint=60090msec, maxt=60090msec

Run status group 1 (all jobs):
WRITE: io=10389MB, aggrb=177040KB/s, minb=177040KB/s, maxb=177040KB/s, mint=60090msec, maxt=60090msec

Run status group 2 (all jobs):
READ: io=84500KB, aggrb=1405KB/s, minb=1405KB/s, maxb=1405KB/s, mint=60119msec, maxt=60119msec

Run status group 3 (all jobs):
WRITE: io=116832KB, aggrb=1946KB/s, minb=1946KB/s, maxb=1946KB/s, mint=60031msec, maxt=60031msec

Disk stats (read/write):
dm-9: ios=42013/49994, merge=0/0, ticks=2841178/2839406, in_queue=5682726, util=99.90%, aggrios=42013/50081, aggrmerge=0/0, aggrticks=2841069/2842060, aggrin_queue=5683152, aggrutil=99.89%
dm-8: ios=42013/50081, merge=0/0, ticks=2841069/2842060, in_queue=5683152, util=99.89%, aggrios=42013/50081, aggrmerge=0/0, aggrticks=2840319/2840713, aggrin_queue=5682799, aggrutil=99.89%
dm-4: ios=42013/50081, merge=0/0, ticks=2840319/2840713, in_queue=5682799, util=99.89%, aggrios=10632/12531, aggrmerge=0/0, aggrticks=709997/709823, aggrin_queue=1420289, aggrutil=99.88%
dm-0: ios=516/22, merge=0/0, ticks=162/31, in_queue=194, util=0.06%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%
drbd1: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
dm-1: ios=0/95, merge=0/0, ticks=0/315, in_queue=315, util=0.13%
dm-2: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
dm-3: ios=42013/50009, merge=0/0, ticks=2839826/2838948, in_queue=5680649, util=99.88%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%
drbd2: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
[/share/folder2] #

可以看出因為不做自動分層, 它的循序讀寫在 TS-253 Pro 大約就是單顆硬碟 170MB/s 的速度.

而下面是另一個 share folder, 啟用自動分層功能.

Run status group 0 (all jobs):
READ: io=16384MB, aggrb=335685KB/s, minb=335685KB/s, maxb=335685KB/s, mint=49979msec, maxt=49979msec

Run status group 1 (all jobs):
WRITE: io=16373MB, aggrb=279227KB/s, minb=279227KB/s, maxb=279227KB/s, mint=60044msec, maxt=60044msec

Run status group 2 (all jobs):
READ: io=1338.2MB, aggrb=22835KB/s, minb=22835KB/s, maxb=22835KB/s, mint=60003msec, maxt=60003msec

Run status group 3 (all jobs):
WRITE: io=3377.9MB, aggrb=57647KB/s, minb=57647KB/s, maxb=57647KB/s, mint=60001msec, maxt=60001msec

Disk stats (read/write):
dm-9: ios=375322/895829, merge=0/0, ticks=2469277/1891667, in_queue=4361799, util=99.59%, aggrios=375322/897570, aggrmerge=0/0, aggrticks=2468515/1888895, aggrin_queue=4357873, aggrutil=99.24%
dm-8: ios=375322/897570, merge=0/0, ticks=2468515/1888895, in_queue=4357873, util=99.24%, aggrios=375322/897570, aggrmerge=0/0, aggrticks=2383188/1790608, aggrin_queue=4174270, aggrutil=95.75%
dm-4: ios=375322/897570, merge=0/0, ticks=2383188/1790608, in_queue=4174270, util=95.75%, aggrios=93986/224426, aggrmerge=0/0, aggrticks=596331/444054, aggrin_queue=1040491, aggrutil=92.26%
dm-0: ios=623/113, merge=0/0, ticks=12753/1858, in_queue=14611, util=5.55%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%
drbd1: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
dm-1: ios=375322/897570, merge=0/0, ticks=2372574/1773622, in_queue=4146619, util=92.26%
dm-2: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
dm-3: ios=0/23, merge=0/0, ticks=0/736, in_queue=736, util=0.32%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%
drbd2: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
[/share/folder1] #

在循序讀寫上達到 330MB/s & 270MB/s 左右. 看的出來這個檔案被配置到 SSD 高速讀寫層了.

再檢視 Qtier 各層的資料量. 也能看出 SSD 超高速層已使用容量增加.

自動分層根據排程執行資料搬移.

看起來當 SSD 超高速層有足夠空間時, 被設定為自動分層的 share folder, 檔案會優先進入到 SSD 層, 待日後依據各層容量及存取頻率, 系統再進行分層的自動調配. 而 Qtier 在較多 bay 數的 NAS 上才能真正發揮它的效用, 即 SSD & HDD 層的容量都要足夠大, 不然 SSD 層容量過小, 其實直接利用 SSD cache 來運作反而容易些.

另外就是 Qtier 2.0 結合了 SSD cache 進來, 但在 web UI上並沒有看到關於 SSD cache 的統計資料, 其實這部份也是蠻重要的, 至少 user 能有個參考的依據.

FB: Pctine

pctine

5084分

樓主

pctine

個人積分：5084分

文章編號：66790218

Cinema28多房影音播放系統

Cinema28 官網

Cinema28 套件數個月前在推 beta 試用, 其目的就是為了整合現 QTS Video/Photo/Music/HD Station 等眾多功能, 簡單說就是以前是以檔案為主體, 選擇檔案後再決定它從那個裝置輸出. 在 Cinema28 設計上是以播放裝置為主體, 由單一界面去管理眾影音裝置.

以裝置為主體時能夠更容易管理播放內容, 例如 Apple TV 本身能播放影片, 相片及音樂, 在過去播放影片由 video station 管理, 要播放相片又回到 Photo Station, 最後音樂要透過 Music Station. 即使透過 File Station 來選檔播放, 也不是那麼方便. 我想這應該是 Cinema28 推出最主要的目的吧.

Cinema28 第一次使用, 比想像中容易許多,

這是基本模式, TS NAS 插上 USB bluetooth dongle 即能和藍牙影音裝置連線, 這裡是連結 Pioneer SoundBar.

當然也支援 Apple TV

Chromecast.

這是進階模式畫面, 提供更多的功能選項. 這是 USB 外接音源裝置. 顯示播放中的曲目

同樣也支援 NAS 本機的 HDMI 輸出 port.

USB 音源 & Bluetooth Speaker

Chromecast 播放中影片.

多房影音, 所以各個裝置能夠同時播放不同的影音檔

影音裝置一覽表

在前面畫面上可看到, 除了慣用的目錄及檔案瀏覽模式外, Cinema28 也結合 QSirch 功能, 直接透過 Qsirch 搜尋 NAS 裡面的影音檔, 將檔案托拉至裝置即能播放.

在實測中除了 Apple TV & HD Player外, 其餘的裝置播放皆正常, 在 Cinema 28 顯示 Apple TV 播放中, 但實際上並無畫面輸出, 而 HD Player 已安裝及啟用, 同樣也是偵測不到, 這部份是比較異常的部份.

另外現在的設計無法做到同步播放的功能, 例如有數個 Apple TV device, 希望能夠同時串流同一部影片或是音樂, 現有的 Cinema 28 設計上並無 grouping 的方式. 不過這也屬較特殊的應用.

FB: Pctine

tagahu_123

1390分

23樓

tagahu_123

個人積分：1390分

文章編號：66790371

pctine wrote:
Qtier 2.0...(恕刪)

我比較好奇自動分層儲存資料要怎麼完整的異機備份，而且如果開啟自動分層儲存，QTIER與一般硬碟做的硬碟陣列視同為同一個儲存池，如果qtier掛了那整個儲存池好像也會跟著一起崩壞，如果真的是這樣那為了速度但風險好像也相對提高（等於要注意2個地方的陣列，尤其是ssd陣列也不能讓他掛掉）。
不知道pctine可以幫忙測試嗎？ssd如果抽取出來模擬遺失的狀態，一般硬碟的除存池是否會跟著一起無法作用甚至資料遺失？

pctine

5084分

樓主

pctine

個人積分：5084分

文章編號：66791544

tagahu_123 wrote:
我比較好奇自動分層儲存資料要怎麼完整的異機備份，而且如果開啟自動分層儲存，QTIER與一般硬碟做的硬碟陣列視同為同一個儲存池，如果qtier掛了那整個儲存池好像也會跟著一起崩壞，如果真的是這樣那為了速度但風險好像也相對提高（等於要注意2個地方的陣列，尤其是ssd陣列也不能讓他掛掉）。

不知道pctine可以幫忙測試嗎？ssd如果抽取出來模擬遺失的狀態，一般硬碟的除存池是否會跟著一起無法作用甚至資料遺失？..(恕刪)

由於它的 storage pool 是由多個 raid group 所組合而成, 這個結構和以前在 QTS 裡面將原有的 storage pool 做擴充是一樣的道理, 差別是以前類以將 RAID group 以類似 JBOD 的方式串接起來, 並沒有儲存分層的概念.

所以回到這個 storage pool 的架構, 那麼備份的方式並沒有不同, 因為 user 備份是以檔案及目錄為依規, 和這些檔案到底存放在 storage pool 的那一層沒有關係.

在以前沒有 auto-tiering 的作法, 我們可以就手動將 ssd & hdd 分為兩個 storage pool, 然後依據檔案及程式的特性各自在不同的 pool 建立 volume 及 share folder, 由人來決定資料放那裡, 有了 auto-tiering 後就是將 ssd+hdd 合組成一個 storage pool, 此時同樣也是要為了資料安全, 選擇 ssd or hdd raid group 的 raid type, 觀念上並無不同, 所以也並不是風險提高.

至於所提的將 Qtier 中 storage pool 的任一層抽掉, 那肯定資料會掉. storage pool 直接毀損.

最後就是有關 Qtier vs SSD Cache 在提速方面的表現, 現在看到的 live demo 大都是很短時間內的測試, 這部份確實對於 Qtier 來說會比較有利, 也就是所提到 Qtier 會比 SSD Cache 更 '快' 表現出提速的效果, 自己的猜測是, 因為由 SSD+HDD 組合而成的 storage pool, live demo 中所測試的資料量比實務中少非常多, 所以一開始 copy 進入 storage pool 時, 若進入自動分層時它發覺 SSD 層有足夠的空間, 就優先存在該層了, 和以前沒有 auto-tiering 的做法不同, 以前是檔案往 HDD 塞, 然後真正在存取時再決定要不要 caching 在 SSD. 所以在最前面有提到, 除非你的 SSD 層的容量夠大, 才能發揮 Qtier 自動分層的功效, 不然直接用 SSD Cache 的技術反而方便簡單.

FB: Pctine