[OSSLab]LSI CacheCade Pro 2.0 R/W SSDC(SSD Caching)簡測..

LSI MegaRAID CacheCade Pro 2.0 讀/寫快取記憶體軟體。該軟體可智慧地在固態記憶體 (SSD) 上為頻繁訪問的資料，或稱“熱點”資料建立快取記憶體，從而可以顯著提高硬碟驅動器 (HDD) 陣列的應用 I/O 性能。採用 CacheCade Pro 2.0 軟體的 MegaRAID控制器與完全使用 HDD 的陣列相比，每秒事物處理量可提升 13倍，成本可降低 82%。
    這款第二代軟體可相容 LSI MegaRAID SAS 9260、9261 和 9280 系列控制器，該軟體將上一代 CacheCade 軟體只能提供 SSD 讀緩存的性能進行了擴展，可同時提供讀緩存和寫緩存，也是業界首款採用 SSD 同時實現讀/寫快取記憶體功能的 SSD 專用控制器快取記憶體技術。

大概有些人已經看過了吧, 不過內容有一些更新了...
在這篇會見到一個術語: SSDC..
為SSD Caching, 因為CacheCade比較長
這裡先"謝謝惠顧"...=3="

前提補充
Write-caching這個機制本身最大影響是的就是Parity RAID mode下, 像是RAID 5或RAID 6...
由於這幾個模式會牽涉到Parity的Read-Modify-Write操作.., 因此Caching機制可以說是影響效能的重大關鍵...
當一個Parity根據前面的條帶數據計算出的時候..
P1=D1 xor D2 xor D3 xor ......xor Dn
這個Parity在Caching機制下未必要立即寫入VD上..
而是他會暫存在Hot data buffer...
因為任何時候的情況下都有可能Parity被再次拿來操作..

從這張圖可以看到了這個操作, 請注意綠色流線...
多個數據被取出的情況下...
D1, D2, .....,Dn...
如果沒有應用一種回寫機制扔到Hot data buffer上...
那性能之悲慘可想而知...
尤其在大量的XOR operation..
只會更慘不會更好..
下面的連結是之前花很多時間翻譯的AMCC RAID 6論文, 不妨可以去觀看:
http://www.osslab.com.tw/Storage/Enterprise/SAS%e8%88%87RAID/Raid_6_Structure
再次提醒, 一個決定Hardware RAID的關鍵與否, 請看下圖:

1. 硬件Caching機制
2. RAID Assist的存在, ex: MCU附加XOR function
3. 根據Frimware Stack設計而定

一般Built-In Porcessor最有效的作用就是乘載大量I/O操作...
由其實I/O中斷上的處理...
但是這個並非是決定Hardware與Software RAID的差異點...

從USA寄到TW的一個fedex box, 效率很好, 只花3天就送達了...
LSI使用International Overnight Priority Service寄送...

LSI00292的box部分:

其實內容就是一隻小塊PCB的2-pin RAID key而已:

在新版的CacheCade Pro 2.0下...
加入了Write Caching...

另外在LSI00292提供了FastPath的SSD I/O加速技術, 用來提升SSD的I/O存取性能
目前FastPath提供了2.0版本, 而且效能也比早期的好
這邊在說明一點, 在前一代的LSI00248, 也就是CacheCade 1.1提供SafeStore加密技術

在LSI00292不再繼續提供支持..
關於高階軟件服務的詳細部分:

當安裝CacheCade之後, 在MSM管理工具上, RAID Controller屬性便會看到相關的啟動資訊...

在正常且良好的情況下, LSI SSDC在性能上的衝擊是相當明顯...
所謂性能上衝擊明顯並不是指她的效能上的提升..
而是有好有壞, 啟動它會帶來好處, 但未必是絕對的情況..
LSI SSDC目前最高支持到512GB, 但是未來會開放到2TB..
並且支持RAID 5模式, 不過這個Parity mode僅針對LSISAS2208 RoC...

上圖的各種VD設定都會導致出來的結果有所不同..
與1.1版的f/w在設定上有些變化...
不再是使用Cached I/O來啟動..
而是有個別的專屬項目...

LSI CacheCade Pro 2.0 R/W目前僅支援LSISAS2108 RoC產品, 另外特殊的CTF-NVRAM的CV系列尚不支援:

將LSI00292的RAID key安插到對應的2-pins header上..

之後CacheCade的設定項目會變解鎖, 因為這個RAID key封裝相關的雜湊密鑰...

在LSI00292便開始支持Write Caching...
從高級的Firmware Log, 又稱為Persistent Log....
從這份進階的Log可以看到LSI RAID HBA再進行初始化時候的相關狀態...
在T4階段可以看到LSI SSDC的啟動資訊...

另外在MegaCLI可以看到當安裝RAID key之後, Upgrade Key屬性值便會改變...

在啟用Write Caching之後...
隨機寫入性能最好的情況下會提升50~100倍左右...
但是這個前提是必須要把HBA上的Hot data buffer徹底關掉...
也就是不能啟用Write-back caching...
一切交由SSD Array處理..
在這種情況下...
我個人的想法是...
1. 把SSD本身體質問題排除, 數據安全性會大幅提升, 因為任何時候寫入操作面向的都是非揮發的SSD, 而非DRAM...
2. 但是關掉HBA上的Hot data buffer, 循序性能是有可能受到大幅衝擊...
3. 隨機性能會大幅提升..
當針對VD啟用SSDC後, 從SSDC本身便可以看到被關聯的VD..

而且從VD本身也可以看到相關的SSDC屬性..

從一塊操作極為頻繁的WorkingSet, 姑且可以稱為Hot Zone
相反地, 不頻繁的情況下, 這塊區域則是Cold Zone

早期在1.1版的情況下, 可以從來自LSI CacheCade 1.1文件中的一張圖表示, 下圖是早期1.1版Read Caching作用流程:

在早期1.1版由於只支持Read Caching, 代表著如果一個數據被操作操作很頻繁,
那他就有很大的機會被衝進LSI SSDC, 並且由SSDC成為次層Cache,
不過LSI的評估文件顯示各項測試期HBA上的Hot data buffer(Cache Memory)都一律強制被關閉掉,
包括Write Caching, 這是為了顯示其LSI SSDC的最大差異性.
但我不認為這是一種好方法, 如果是在1.1版下, 至少我會建議Write Caching是要開啟的,
因為該功能轉用Write Through會對寫入性能造成很大的衝擊, 尤其是在Parity RAID mode下.
在1.1版如果要啟動LSI SSDC, 只要在VD的屬性設定部分, 將IO Policy改成Cached IO, 便可立即啟用.

從2.0版開始提供針對LSI SSDC的Write Caching機制,
允許在任何時候異動LSI SSDC上的Hot data, 根據適當的應用下能有效加速讀取和寫入性能.
並且根據RAID Controller的設定, 在一段時間後會將LSI SSDC上的數據自動衝回VD的實體結構(Cache Flush).
下圖是我從1.1版的Read Caching流程進行的一些更改, 可以看到寫入數據的流線:

當然這可能會想到SSD上的數據安全性問題, 因為根據SSD本身體質而有所不同,
在MegaRAID 3.6板之後便提供一種SSD Guard技術可以提前得知SSD是否發生異常,
如果影響到本身的數據結構, 可以另外再安裝新的SSD, 便會自動將有問題的SSD上的數據衝回新安裝的SSD上,
這保證了一定程度的數據安全性和一致性.

LSI SSD Guard基礎上是基於SMART和Copyback這兩種支持而提供的, 插入新的SSD作為Hot spare.
Copyback操作完成後, 可以把舊有故障的SSD取下, 換上完成數據更換的SSD,
在讓RAID Controller自動進行OAR(Online RAID Roaming)重新配置Array(這會重新設定HBA上的NVRAM).
SSD Guard對大多RAID mode有效, 這包括了不具安全性的RAID 0模式.
在LSI SSDC啟用Write Caching下, 如果透過SMART得知SSD發生問題, 在嚴重影響數據結構以前,
會自動將SSDC上的數據衝回VD實體結構, 以保證數據安全性和一致性,
並且自動將Wirte Caching改回Write Through. 對SSDC而言, 這是處於在degrade的狀態下
關於LSI的SSDC在消費級領域上, 類似的就是Intel的SRT(Smart Response Technology)...

這是SRT的相關設定, 不過要透過IRST的RAID Stack去啟動..
當然LSI的SSDC要遠比SRT先進許多了...
另外還有類似的技術就是Adaptec的maxCache, 前身為MaxIQ..

原理同樣類似, 不過他沒有支持Write-caching機制...
我不清楚新型的Hybrid SSD&HDD RAID有沒有這樣設計...
http://www.adaptec.com/en-us/_common/hybrid-raid/
下圖為來自1.1版的應用說明, 從最左圖可以看較大的WorkingSet data並不容易cache到SSDC的hot zone..

這張來自LSI CacheCade文件顯示出在HDD透過LSI SSDC開啟加速後, 所表明的一種存取情況:

不同的I/O線程下, 呈現不同的數據分布區域. QD1在一個線程, 由於這個數據通常單純且較不易cache住, 在隨著QD逐漸拉升之後.
多線程I/O可以有效反應出數據是容易被cache的, 因為經過了多次存取.
在以往的情況下, Hardware RAID HBA會將這種所謂的Hot Data暫存在Cache Memory, 也就是Hot-data buffer.
這個有效且經過驗證的加速設計在典型的Parity RAID mode會獲得最大效益, 而轉成SSDC設計之後, 雖然NAND FLASH的速度無法跟DRAM相比.
不過由於存取效率依然遠勝傳統HDD, 而且容量高於DRAM Cache, 因此在像是大型串流的線性I/O存取, 利用SSDC可以獲取更好的效能.

這表示著在不同的應用下, Hot-data buffer的存取次數會明顯有所不同. 上圖是來自早期1.1版的文件, 從OLTP情況下可以獲得最大效率, 在大型的WorkingSet data改進會減少. 但是在新版的2.0引進Write Caching機制以後, 其各方面效能皆會有所明顯改善.

這個在2.0 R/W之後, 這些情況都會受到大幅的改變, 因為啟用了SSDC Write caching機制..
從先簡單的測試來看...
HDD: WD WD1000FYYG, SAS 2.0, 6Gb/s, 1TB x4
RAID: LSI MegaRAID SAS 9260-8i, LSISAS2108 RoC
SSD: Crucial M4 64GB x8
        Crucial M4 128GB x2
PFK: LSI Advanced Software Service, LSI00292

WD WD1000FYYG SAS HDD部分資訊:

從HDD資訊可以看到, LSI MSM管理工具提供HDD溫度監控, HDD溫度監控支持產品有: LSISAS1078, LSISAS2008, LSISAS2108和LSISAS2208全部產品
另外LSISAS2208 RoC更是支持了Controller和Chip溫度監控.
使用軟體為CDM..
測試檔案尺寸為1GB...
首先來一張Baseline的情況下..
正常關閉SSDC, 使用最佳的設置..
256k, RA&WB&DIO

而啟用SSDC後, 設定上必須要稍微做一些改變...
64k, NRA&WB&DIO, 你可以發現我故意啟動WB...

這邊可以看到使用LSI的SSDC後, 成績有出彩的變化...
整體性能可以說是大幅提升..
不過有個問題就是隨機寫入性能遭受影響..
這是因為開啟WB後的結果..
那我把WB關掉的話呢?
64K, NRA&WT&DIO

可以看到隨機寫入性能因而大幅提升..
可是循序性能卻受到大幅影響...
LSI其實很早就表明過...
HBA上的Hot data buffer會嚴重影響性能...
不過在這個案例上..
數據可以保障安全性...
因為你不會直接寫入HBA上的Hot data buffer...
但是可是缺點就是某些情況循序性能會重創...
還有我們可以看到在有些測試上可以見到LSI SSDC的強悍案例...
檔案尺寸1GB
來先看看Baseline的情況..

開啟LSI SSDC後...

很歡樂的情況...
像吃了威爾鋼一樣..
當然ATTO本身就是很歡樂的測試軟體..
因此不太可考性......

我們在看AS SSD的情況..
Baseline結果..

LSI SSDC之後..

成績明顯大幅拉開了差距....
以上都是以4盤去做測試...

最後得到了一些結論就是:
1. 針對循序性能的大幅強化方案=> 256KB, NRA&WB&DIO
2. 針對隨機性能的大幅強化方案=> 256KB, NRA&WT&DIO
另外就是使用CacheCade Pro, 採用第二方案的話..
BBU可以免除, 透過SSD Array保證數據安全性...
如果要保證SSD Array的數據安全性..
有兩種做法..
1. 不可關閉SSD Guard, 因為SSD Guard是結合Copyback和SMART而設計的

2. 使用SSDC的RAID 10模式來保證數據安全..
如果SSD夠強悍的話, 我的建議可以使用4顆...
當然米多的話, 多買幾顆也無所謂..
但是目前最大容量限制為512GB..
這點請注意!
然後關閉HBA上的任何Hot Data buffer..
一切由SSD Array來操作..
而且BBU可以完全免除...
不過有可能會因為Wide-ports數量不足的情況發生, 因為大多使用者都是選購非high-port count的版本,
例如LSI MegaRAID SAS 9260-8i, 提供Native Wide-port Connector x2..
最多只能連接8顆PHY Target, 在這種情況下如果要進行更多的裝置串接(expand connector number),
你可以需要如下的裝置-SAS Expander:

RAID HBA面對的target是SAS Expander, 上圖為Intel RES2SV240, 提供4x6的wide-ports數量,
對於SAS Expander對向RAID HBA這種initiator而言, 其routing method會是使用direct routing算法, 也就是所謂的no routing,
當然如果對向的又是SAS Expander的話, 則是subtractive routing算法, 而面對路徑選擇的話則會採用table routing,
不過這些說明都已經超出本帖講的範圍, 因此稍微看看即可...

增加影片部分(請點擊)...

來看看LSI SSDC的運作情況..
我強制寫一個4GB的檔案進行操作..
這檔案比較大..
綠燈為HDD在閃燈..
藍燈為SSD在閃燈...
你可以發現一段時間後HDD便不會在運作了...
轉由SSD在處理..

無法Caching所帶來的慘況:
256K, NRA&WT&DIO

更改成一般設定:
256K, RA&WB&DIO


Sequential I/O獲得SSDC的效益, 這個前提是數據必須是重複性:


根據官方MSM Content Help的建議設定

問題補充:
LSI SSDC並不會將全部I/O給caching...
如果一個I/O的workingset操作不頻繁的話...
也就是所謂的cold zone的部分
那這個數據集有很大的機會跟直接跳過caching...
像是如果是做大型串流數據複製..
例如檔案拷貝...
這種數據很難被caching...
那沒有經過SSDC的情況下..
你只會看到一個很慘的情況...

使用LSI的SSDC要注意用途...
如果I/O請求併發數量很大的話..
那他會有使用價值存在...
                  
16562, Is TRIM supported with LSI RAID controllers or SAS HBAs?
TRIM is not supported with LSI RAID controllers or SAS HBAs.
http://kb.lsi.com/KnowledgebaseArticle16562.aspx?Keywords=trim
PS: 如果使用pass-through打穿讓OS識別, 可以正常使用TRIM.

太強大了！看來 CacheCade 2.0 可以把 Adaptec 的 MaxIQ/ZCR 以及其他的電池方案淘汰掉……
如果單純考量到CacheCade Pro 2.0 R/W的泛用性用途情況下..
依然還是需要搭配HBA上的Hot Data Buffer..
作三層混合使用...

CacheCade是不可能把Adaptec的最高安全級別-ZMCP給取代掉..
LSI的CacheVault才是用來對向ZMCP的高階服務..

大致上內容全部修完....=3="
謝謝各位惠顧...

{:1_345:}端个凳子慢慢看

好长呀。。。直接眼花了

看的眼花缭乱啊

對於档案伺服器4K IOPS是最重要的性能指標，單隊列的IOPS降低不少，緩存技術和NCQ處理的不錯，深隊列成績有提升，持續傳輸成績不是很重要

對於档案伺服器4K IOPS是最重要的性能指標，單隊列的IOPS降低不少，緩存技術和NCQ處理的不錯，深隊列成績有 ...
jeffxl 发表于 2011-10-16 20:22

對於各種應用下..
其實也要注意App本身的Caching機制存在...
例如Web Server, 這類東西本身就提供超強的caching管理, 像是IIS本身提供caching, 跨入CLR(CLR是微軟.NET環境的根本..)後可能又有caching...

QD1的情況下, 改進有限..
如果改成Read Caching, 那他幾乎是不會有改進的...
因為幾乎不太可能被衝進SSDC...
但是一般情況都是多線程的.
所以使用妥當的話, 他會有加速的效果...
File Server是有其效益, 但是這種東西要使用以前先要考慮到是否真的有需要..
根據其硬體配置和建置規模..

當然廉價的H700免費提供SSDC..
雖然是1.1版, 僅能支持Read Caching...

對於各種應用下..
其實也要注意App本身的Caching機制存在...
例如Web Server, 這類東西本身就提供超強的ca ...
per1-q1222 发表于 2011-10-16 20:39

   大部分熱數據集中的領域有很多成熟的韌體緩存技術存在（命中率超級高），磁盤的讀IOPS能力慢慢的在邊緣化，基於板卡的磁盤IO加速正在慢慢的變得不太重要（提供的持續性能有時有些許功用）。在我的工作範圍，我做國內網吧的技術支持工作，作為網吧的檔案伺服器來說（譬如無盤伺服器），基於韌體的緩存技術命中率幾乎達到100%，然後多盤回寫技術提供的寫IOPS又大大優於基於板卡的各種RAID技術（我用的SF主控的SSD作為回寫，因為可壓縮性尚可，可以併發出高IOPS），SO 我目前找不到使用這些產品的任何理由。相對來說讀的處理我認為完全基於可以韌體化，幾乎大部分併發高的應用場合，用戶訪問數據的資源熱集中性都很高，離散分佈的讀不是很多。就是用戶回寫不好預期，幾乎無法緩存，命中極低，寫緩存技術目前還是瓶頸（測評當中的回寫感覺沒有意義），分盤異步讀寫可以大大提高寫IOPS而不是板卡的各種聯合RAID（RAID難於異步寫，如果異步可寫，那麼讀併發又是問題）。我目前釋放讀寫壓力的方式就是韌體緩存讀、基於韌體的分盘異步寫。

说到底还是storage tiers的问题。LSI的SSDC从技术上看目前非常不错，比MAXIQ想的更周到，不过这家公司最近越来越商业，自从SAS得道后，软件卖钱已经成为一种“习惯”。

说到底还是storage tiers的问题。LSI的SSDC从技术上看目前非常不错，比MAXIQ想的更周到，不过这家公司最近 ...
neeyuese 发表于 2011-10-16 21:05

   这个产品对我做网吧文件服务器来说有何用处？我的应用场合，读数据热集中型，用户回写超级离散型，几乎无法缓存。请浴室姐姐作答下，我看看有没有其他新方案可参考
我目前读在用SUPERCACHE，写使用无盘软件可提供的分盘异步回写，回写性能是异步累加的，相当于所有多盘SSD的IOPS写性能相加，目前比各种板卡或者RAID方案回写性能优

如果你文件服务器需要比较大的容量，再考虑这类方案吧，这个方案针对的是一整个体系，也就是利用上一级的Tier（SSD），来最合理的优化下一级的Tier(HDD），而非你现在使用的“无盘”环境。

大部分熱數據集中的領域有很多成熟的韌體緩存技術存在（命中率超級高），磁盤的讀IOPS能力慢慢的在邊 ...
jeffxl 发表于 2011-10-16 20:56

LSI SSDC的Write Caching在這邊的測試主要可以提高IO讀取性能...
如果只使用Read Caching的情況...
那大多必須要在尺寸較小的workingset data才有幫助(而且是多線程)..
Write Caching絕對有其效用存在..

這東西使用要注意..
否則他可能會嚴重影響性能...

说到底还是storage tiers的问题。LSI的SSDC从技术上看目前非常不错，比MAXIQ想的更周到，不过这家公司最近 ...
neeyuese 发表于 2011-10-16 21:05

不僅是這樣..
而且還在新版的f/w強制關閉一些功能..
似乎要拿來另外賣錢..

其實最好是想拿ioMeter做徹底的測試..
做不同的profile測試
我原本有想這樣做..
只是後來懶了..{:1_323:}

如果你文件服务器需要比较大的容量，再考虑这类方案吧，这个方案针对的是一整个体系，也就是利用上一级的Ti ...
neeyuese 发表于 2011-10-16 21:12

   除了无盘部分，无盘网吧还有上千G的内容服务器，譬如游戏等资源。通过ISCSI技术做虚拟盘映射到用户端来完成内容提供服务，这个容量的读命中让也是我头痛的地方，需要巨大的内存容量（8G甚至16G以上）来缓存才能提供不到80%的命中率，磁盘IO负载依然很高，忙时参考服务器性能监视器对应内容工作盘，压力不是一般的大，长期Idle时间为0。虽然有八二定理才使（80%的用户经常使用几乎20%的数据，80%的数据只有那少数20%的人调用）缓存命中有目前的状况，就是那20%人访问冷门数据让我的磁盘IO遇到瓶颈，其实我可以不管他们，既然是冷门数据，让他们慢好了，但是如果能解决的话还是一个不错的体验，貌似这个产品就是用来提高此类应用的。

这个内容服务器没有回写压力，提供的内容几乎不需要回写服务器
还有，现在的大型网吧可不是小型服务器了，主交换上万兆光纤模块交换机直连服务器，并发数据还是非常大的
不过我现在在有些网吧的内容服务器上使用纯软件的方式使用SSD缓存热数据，SSD容量比内存大，做三级缓存方式，内存不命中那么SSD可以提供一定的下一级的命中率，因为容量大，SSD的命中还是很高的，此SSD不提供任何内容服务，全部容量做热缓存（这样是不是一个意思？）

对于你第一种情况，最好的加速20%冷数据体验，是另外加一台内容服务器，专门负责这部分数据，如果纯粹在原服务器上提高上一级Tier的命中率，只不过是提高了另外80%的热数据体验，这样下去是没底的，因为你永远不可能把数据都缓存住。

纯软件方式做SSD缓存热数据，这个也就是类似Fency cache了，SSD纯粹做为L5使用，对SSD的耐久度是个考验。

对于你第一种情况，最好的加速20%冷数据体验，是另外加一台内容服务器，专门负责这部分数据，如果纯粹在原 ...
neeyuese 发表于 2011-10-16 21:47

   你刚才有一点理解错了，八二定理，我这里是80%都是冷数据，因为20%的热数据是80%的人都经常访问，另外20%的人可能访问80%的冷数据。这个80%的冷数据我几乎无法另外做ISCSI服务器，涉及到客户端路径管理问题和游戏自动更新难度（虽然可以跨服务器做），跨服务器更新，主内容服务器更新内容下发的话这样需要同步到另外一台冷数据服务器。又因为我16G内存做读缓存提供的IOPS满足了80%的人，其实热数据缓存需求就是那20%的数据，比如1000G数据就是200G是热的，又因为用户载入时不会调用一个游戏的所有资源，进入同一个游戏载入资源，不同的用户有非常大的一致性，一个魔兽世界的文件夹只有少数几百兆是热数据，虽然他有10几G的材质库。所以16G内存可以达到20%的热数据（比如200G）有80%的全局命中率，我使用的SUPERCACHE是基于扇区的缓存，哪怕文件的一部分被经常使用就会缓存，而不是缓存整个文件，这样提供了缓存效率，并不是200G的热数据需要200G的内存提供100%的热数据命中。所以热数据命中好说。


难点在于冷数据，我的内容服务器不只1000G数据啊，那是上千G的冷门数据，实在无法管理，目前最优方案就是单服务器SSD做磁盘上级纯软件缓存，磨损就磨损，只是个读缓存，坏了不伤数据，立即换一块就是，只要能提供相应的性能，对于大型网吧来说这个成本忽略不计，提供5块SSD随时给他们网管备用，坏了就换就是

我前一贴的原话是：“（80%的用户经常使用几乎20%的数据，80%的数据只有那少数20%的人调用）”

热的20%有80%的人经常调用，20%的人才调用那80%的冷数据

热数据只有20%哦，但满足80%需求。
冷数据另建立服务器还是缓存效率低，因为冷数据大都冷门的原因，所以访问分布可能很广泛，另建服务器也不大可能有缓存高命中，单服务器压力是冷数据（因为冷数据未命中缓存），如果只有热数据访问，那么单服务器磁盘是没有什么压力的，另外建服务器只是转移了压力，并没有减少任何IO压力，我的IO压力就是冷数据访问，单服务器和双服务器区别似乎不大。



最关键的！冷数据可能是访问某个热数据的资源的一部分，无法分拆。比如这个版本下的魔兽世界，大家进游戏初始化载入的几乎是同一个资源需求，有趋向性，可以缓存。目前版本玩家经常进入的副本是趋同性的，很可能被缓存命中，但魔兽世界广大的无缝地图和冷门副本等资源不可能被缓存算法包含，那么你不会希望我把魔兽世界文件夹分拆到其他服务器，因为存在访问问题，而且热数据在工作中是动态统计的，下个游戏版本可能又有新的游戏热点地区，基于文件访问结构的约束，就算是“热门”资源，我无法把这个资源同一部分的冷门资源分拆，客户机的访问逻辑是个问题

热数据其实大部分都只是一个资源的少部分，我这里冷热数据的最小单位是扇区级别，不是以文件或资源文件夹来分割的
热数据也许只是一个游戏材质资源文件的一小部分，比如魔兽世界单个文件N个G的MPQ资源文件