超微 Supermicro X11DPi-NT 主板的注意事項

Supermicro X11DPi-NT / X11DPi-N 這款主板堪稱接近完美。它基本上把從 Xeon CPU 中可用的 PCI Express 鏈路都用上了，并且 CPU 和 CPU 之間也是使用 3 條 QPI 連接上的（這個是要點，有的主板只有兩條 QPI 的）。

但是！

如果你打算使用 X11DPi-NT 用作 VROC 用途，那麽你就要注意了。這款主板支持 Intel VROC，不過有以下的限制：

1、除了主板自帶的兩個 OCuLink 端口，就只有 Slot 6 這根插槽具有 VROC 功能。

2、必須把 Slot 6 設置成爲 x4x4x4x4 的 Bifurcation 模式才能夠啓用該插槽的 VMD 功能。這就是說我沒辦法使用 PCI Express Switch (PLX / PEX) 以鏈路更多的 NVME SSD。

3、好像 Slot 6 和主板的兩個 OCuLink 端口并不是同一個 CPU 的……

基本上，X11DPi-NT 的 VROC 功能極其有限。如果閣下有使用大量 NVME 作 RAID 的打算，那麽就不要重蹈本人的覆徹。可以考慮 X11DPH-T / X11DPH-i ——這款主板所有 PCIe 插槽都支援 VMD，包含兩個 M.2 插槽。并且應該支持任意的 Bifurcation 模式，這對於打算使用 PLX / PEX PCI-E Switch 的用戶來説是一個不錯選擇。

Farewell: Hard Disk Drives

It has been so many years already - my first HDD was a CONNER CFS-420A with capacity 420 MB. It should be around 1994. That was the exciting moment I can still remember - what an upgrade to 1.44MB floppy disks!

More than 25 years later, now I have made the decision to phase out all HDD sin my system. I have even bought a few 12TB Seagate Exos for my next project, but now they will be sold before being put into real use.

My experiences with HDDs could be quite a bit different from most of the people out there: I was very cautious about reliability and durability, rather than focusing mainly on capacity. If you have ever noticed about the specifications of the most decent HDDs, you might start noticing one thing: the Unrecoverable Error Rate has remained 10^14 (consumer parts) and 10^15 (server parts for many years without improvement.

Yes, right, who would be really caring about these numbers? They are just indicators, and new technology should be always more reliable, right? Unfortunately, my personal believe is, if there is a number published in that way, it MUST has a meaning. Consider other common storage technologies, such as SSD (10^17 for enterprise parts) and Tapes (10^17 - 10^19), what I can say is HDDs have a frightening LOW reliability nowadays.

Imagine a 1 TB HDD and a 10 TB HDD, they both have URE of 10^15. During a RAID rebuild, 10TB one will have 10 times higher chance to encounter an URE. While 10^15 URE means you *might* encounter a Non-Recoverable Read Error every 125 TB of data, this is not a lot for today's large capacity drives. If I am using 10x 12TB Exos HDDs to build a RAID 6 array, it will be so likely to get a Read Error during re-build - which is exactly the reason putting me off from proceeding with my original plan. I just don't want to put my data at risk.

That's also the reason why in the past my 16 HDDs RAID 60 array served me well, because each member was only 1TB in size. With 10^15 URE, the array was still relatively secured and it has proved itself. However, with 12TB, 10^15 URE is DANGEROUS and it is not making sense for traditional RAID techonology.

Also, think about the rebuild time - with my 16 HDDs RAID 60, even with a 1TB drive size, the rebuild time was somewhere around 4 hours without anyone using it. How about a 12 TB HDD? Well, if you are luck, you can have the array rebuilt in 2 days (given that nobody will be using it). Otherwise, it could be "weeks" - and the longer the time, the more likely another unrecoverable read error can happen. (And another one!)

You may say RAID is now out of date. But unfortunately it is the opposite - HDDs are now out of date. I now have an array of 2TB SSDs in RAID 6, and I am feeling way more comfortable with their 10^17 URE. The maximum size of SSD I can accept to be put into the array would be 15.36TB - if higher then I will need 10^18 URE.

HDD has a good characteristic: offline durability. This is especially true when it comes to offline data storage - think about data retention of SSD when it has been completely powered off - after the Intel 320 array incident happened to me in the past (data gone after powering off for > 1 month), I think you might expect data could be held in server class SSDs for 1 year max offline without problem, but don't expect more than that. HDD can do far better than SSD in this case since the storage of data is not depending on electricity stored in NAND cells that could leak, but on platter with magnetic recording that can last.

HOWEVER, how often are you going to put your HDDs offline? Possibly never - they are in RAID, and they are serving as nearline storage. This has defeated the purpose of this great characteristic. For nearline storage, I can easily use SSDs because they are ONLINE, with continuous power supply so they have the same data retention reliability as HDDs. They can run cooler and they have far better access performance than HDDs. So that's why my 12TB Exos are out of the picture for my project - I will be getting some 15.36 TB SSDs instead.

For archiving, an "old school" technology has somehow came to my mind - TAPES! They are offline storage, portable, power efficient and has a really high URE. They use magnetic recording as well so data retention is surprisingly good. If I need archiving, a tape library is better suited in this case.

With Tapes and SSDs, I have to say "farewell" to HDDs - unless URE has been increased to 10^16 or even 10^17, they won't be considered by me just because I want to have better sleep at night without worrying about RAID rebuild...

FAREWELL, MY LOVELY HDDS!

Windows Network Direct: Your better bet is with Windows Server 2019

I have been always struggling to get RDMA working inside a Windows virtual machine. I had tried Mellanox ConnectX-3, Mellanox ConnectX-5 and Chelsio T62100-LP-CR network adapters, with Windows Server 2012 or 2016, and even with Direct Device Assignment in Windows Server 2016, I could not get RDMA working flawlessly in any virtual machine.

Recently, I retried RDMA in a Windows VM (2019) on a Windows Server 2019 host, with a Chelsio T62100-LP-CR - and finally have RDMA (iWarp) working correctly (even without a switch - you can connect port 1 to port 2 to form a 100GbE link). It enabled SMB Direct between the VM and the host (and between VMs as well), and performance was acceptable (needs tuning).

If you are after any RDMA application inside a Windows VM, or simple just want to use SMB Direct in a VM, Windows Server 2019 or later is your better bet in this case.

Do note that you need the following:

• SR-IOV support from BIOS - this sometimes means enabling the ASPM option in BIOS.
• A network card that supports RDMA - I like iWarp because it is simpler (virtually no configuration needed). If you like RoCE then you may need DCB configured properly, or even need a 40GbE/100GbE switch.
• Windows Server 2019 or higher - both host and VM. You may use Windows 10 (latest) - I didn't try that out but theoretically it should work.
• Workstation / Server grade hardware - I have seen many times people complaining about not being able to enable SR-IOV due to missing implementation like IOMMU or ACS etc. with consumer grade hardware. Your CPU supports all these features doesn't mean your motherboard / BIOS has support of all features.

微軟已經修復 Windows Server 2016 TP 中的 Deduplication 數據損壞問題

近日收到 Microsoft 的消息說 Windows Server 2016 TP 中的 Deduplication 數據損壞問題已經被修復，并且附上了一個内部測試補丁。安裝該補丁之後，測試運行了幾次 DedupJob 均沒有問題。產生問題的是 dedup.sys 驅動程序。

看來微軟對於數據損壞此類嚴重問題還是比較重視的。如果閣下希望在 Windows Server 2016 TP 中使用 Deduplication，則需要等待補丁在 Windows Update 中的正式發佈。比較保險的應該會在下一個纍積更新之中，或者更保險一點可以等待至 TP5。注意必須先安裝補丁，然后再開啓 Deduplication 功能。從微軟工程師的描述中看來此問題可能衹會發生在從 Windows 2012 R2 升級到 2016 的系統中。

關於詳細問題描述可以參考此帖子。

[已修復] 注意 Windows Server 2016 TP 中的 Deduplication 可能會導致數據損壞

UPDATE: 此問題已修復。

不知道這算是幸運還是不幸，反正就被我遇上了。基本情況如下：

先決條件：
- 系統是 Windows 2012 R2
- 磁盤爲 GPT 的 NTFS，開啓 VDI 模式的 Deduplication，數據重複刪除率達到 75%
- 狀態: 1TB 中刪除重複后大約使用 250GB。
- 磁盤儲存大量 Windows 2008 R2 與 Windows 8.1 的 VM，格式爲 VHD 或者  VHDX
- 磁盤是本地磁盤，注意這個配置 Microsoft 不建議。沒有 SAN 或者 iSCSI 的使用。

步驟：
- 升級 Host 到 Windows 2016 TP4，并且安裝 Deduplication 功能
- 將所有 VM 導入到 Hyper-V，并且運行
- 添加更多的 VM
- 確保 Background Deduplication 運行至少一次

結局：
- 大部分 VM 突然進入 BSOD 狀態
- 檢查該 VM 的 VHD / VHDX 文件，發現無法用 CHKDSK 修復，數據完全丟失。卷返回 Invalid Function 錯誤。
- 該 VHD / VHDX 文件無法重複使用！你必須刪除該文件，然後重新創建，才能夠在 VM 中重新安裝系統
- Host 中開啓 Deduplication 的卷卻沒有問題，CHKDSK 通過。
- 關閉 Background Deduplication 后，就不會進一步損壞其他數據

所以此次數據損壞可能是 Dedup 服務造成的。已經將此問題報告 Microsoft，他們也在進一步調查，不過在他們回復之前，閣下最好還是先關閉 Dedup 服務以避免產生同樣的問題。

如何使用 USB 驅在 UEFI 系統上面安裝 Windows 2016

好吧，我知道 Windows 2016 衹是一個 Technical Preview, 不過貌似微軟忽略了一些非常重要的因素。TP 4 很大，比以前的 Server 操作系統都大，所以 install.wim 達到了 4.22GB。總所周知 UEFI 系統用 USB 盤安裝需要一些先決條件：

- FAT32 格式的 USB 盤
- 設置爲 Active Partition
- 複製 Windows 2016 安裝數據到 USB 盤中

最後一項很不幸對於 Windows 2016 TP4 是無法辦到的——install.wim 超過了 FAT32 所能夠承受的 4GB 極限！
解決辦法很簡單，用下面的命令切割 install.wim 文件：

Dism /Split-Image /ImageFile:l:\sources\install.wim /SWMFile:f:\install.swm /FileSize:3072

(L: 是光盤，F: 是硬盤)

然後把切割好的 install.swm 和 install2.swm 複製到 USB 盤的 sources 目錄裏面，這樣就可以完成所有先決條件了！

Intel 320 160GB SSD: 小心 MLC 可怕的“空白門”事件！

其實這是一年多以前的事情了。那時候入手了 4 個 Intel 320 160GB SSD，然後組成了一個 RAID 5 陣列，用起來沒有問題，性能挺不錯的。

不過由於需要更新機器的硬件，所以我把機器關掉了大約一個月的時間，之後硬件更新完畢，開始后發現令人抓狂的一幕：4 個 Intel 320 160GB SSD 其中的兩個變成完全空白了！！

令人抓狂的兩個！而不是一個！RAID 5 更本救不了！數據完全丟失！！

後來調查了一下，發現這種事情還是在情理之中的。首先，SSD 是通過電壓來儲存數據的，也就是説，每一個 Cell 特定的電壓會代表不同位狀態。SLC SSD 會比較簡單，有電壓和歸零代表位的 0 和 1，然而 MLC SSD 就會比較複雜。而在這一個月時間中，我是沒有開機的，也就是説所有的 SSD 均沒有辦法補充電量。我所有的 Intel X25-E SSD 均沒有數據丟失的問題，也不知道是由於高端質量還是 SLC 對電壓的容錯性好。然而其兩個 Intel 320 160GB SSD 則很不幸是“漏電體”，在沒有加電的情況下，電壓流失。這個時候，MLC Cell 裏面的電壓就會把原來該標識的數據表示成爲另外的錯誤數據，以至於整盤數據混亂，完蛋了……

當然，那兩個 SSD 在重新分區格式化之後還是可以使用，衹不過一旦長時間不通電，數據還是會丟失。

最終的結局就是我把所有 MLC 類型的 SSD 都出手了。其實現在的情況還是有點令人堪憂。總所周知，晶體越大，儲電越多。例如 Intel X25-E 的 50nm 大晶體，儲電能力肯定比 Intel 320 160GB SSD 的 34nm 要好得多，更不用説 SLC 衹需要表示 2 種狀態，而 MLC 需要表示 4 種狀態，對電壓值得準確性要求高得多。而現在的 MLC 可能衹用 25nm 甚至更小的晶體，本身儲電量已經少，如果沒有很好的辦法防止漏電，長時間鍵關機就可能導致數據錯亂甚至消失了。

關於 Avago LSI CacheCade 的一些使用心得

曾用過 LSI 9361-8i 再加上 CacheCade 2.0，感覺有點不大盡人意。主要的原因是這種技術僅僅適用於非常特定的情況。

首先説説循序讀寫 (Sequential Read / Write)。我嘗試在一個大容量 HDD RAID Array 上面使用 CacheCade。我所期望的是在偶爾的 4K IO 時性能可以有所提升，而陣列的主要目的還是循序讀寫。然而比較不幸的是，無論 CacheCase 1.0 或者 2.0 均沒有辦法很好的檢測 Sequential Read / Write，導致 Sequential 性能大幅度下降。就算 4K 性能增加，也無補主要的循序性能缺失。感覺上應該是 CacheCade 無法很好的辨別循序讀寫以至於循序讀寫也要經過 SSD Cache，造成不必要的延遲（？）。

那有什麽應用會用到 Random Access 呢？儲存 VM 的 VHDX 文件的陣列應該會用到。然而轉而一想，在我具有足量的 SSD 儲存下，再加上 Microsoft 的 Deduplication 功能，儲存 VHDX 根本不用 HDD 陣列。并且由於 HDD 陣列的功耗較高，應該盡可能將其 Spin Down。因此也用不上 CacheCade （因爲 LSI 9361-8i 不支持 Dimmer Switch Max with Cache 設定！）

結果就是，CacheCade 可能祇能夠用於中型的 SQL 數據庫，因爲小型的完全可以使用 SSD，大型的也完全有足夠資金全部使用 SSD，衹有中型的 Production 數據庫可能需要用到這種 Hybrid 的方案。而像我這種以 Development 爲主的 SQL 數據庫，直接 SSD儲存就可以提供足量的空間。

綜上，CacheCade 至少在對於我來説，比較鷄肋了……

LSI 9361-8i vs. Dell PERC H730P 之糾結拼

早期入手了 LSI (Avago) 9361-8i 控制器，1GB 的緩存，再加上 CacheVault 和 CacheCade 2.0，置換了 Dell H710P，原因在前面的 post 有述。感覺良好，并且有 LSI 的技術支持，直到……

突然發現 -> 沒有 Dimmer Swtich LV3 !!!!!!!!!!!

後果很嚴重，我一大堆 HDD 都沒辦法享受 Spin Down Configured，電費急漲！

開始懷念 Dell H710P 了……突然發現市面上有 Dell H730P，價錢還比 LSI 9361-8i 便宜，感覺這次判斷錯誤，再次果斷置換，終于 DS L3 回來了！

因此總結如下：

LSI 9361-8i

優點：
- LSI 技術支持，3年 warranty
- 頻繁的 driver / firmware 更新
- 有 CacheVault 選項，不用 Lithium Battery
缺點：
- 絕對沒有 Spin Down Configured - 我直接查詢 technical support 的
- 價錢貴
- 標配比 OEM 低
適用：
全天候 online 或者 SSD 爲主的配置，喜歡 CacheVault 的懶人，LSI 的 support 是的確不錯的哦。

Dell PERC H730P

優點：
- 價格便宜
- 2GB RAM / Flash
- 有 Spin Down Configured !!
缺點：
- 沒有 LSI 支持，technical support 絕對不鳥你……
- driver / firmware 更新緩慢
- 順便説句，Dell 也不會鳥你，除非你買他的伺服器……
- 僅 Lithium Battery，兩三年后記得更換，麻煩……
適用：
想要省錢，又能夠忍受沒有 support 的日子，并且有大量 HDD 想要 DS L3 的，就這款吧。

Dell PERC H710P：兼容性問題！！

這是舊事重提了，其實兩個 Dell PERC H710P 都已經出手。這款卡絕對是經典，性價比一流，比 LSI 自己原廠的要好得多，而且可以 Spin Down Configured Drives （忘記是否需要 MegaSCU 改了）。然而在一下的配置中存在致命問題：

配置：
- 非 UEFI 主板（可能無關聯……）
- 非 Dell 系統（可能有關聯……）
- Windows Server 2012 R2 (自帶最新的驅動程序)
- Dell PERC H710P

結局：Fatal Error - PERC Kernel Panic.........      >_<

解決辦法就是用非 Dell PERC H710P 的磁盤裝 Windows，然後降級到 Windows Server 2008 R2 的 PERC H710P 驅動程序……感覺糟透了……

驗證 Windows Server 2012 R2 的 Deduplication 是否可以作用在本機運行的 VHDX 上

根據微軟的論述，Windows Server 2012 R2 可以支持對正在運行的 VM 所使用的 VHDX 文件進行重復刪除處理（Deduplication），前提是 VHDX 文件與 Hyper-V 服務器不在同一個機器上面。

不過，既然微軟已經解決在 file locked 情況下對文件内容進行 Dedup，我想就算全部東西都在本機也應該沒有問題。

操作如下：
1、創建 3 個 VM，其 VHDX 文件都同在一個 SSD RAID 分區上面，佔約 33GB 空間
2、開啓 Dedup，選擇 VDI 選項，天數應該不要緊，VHDX 文件會被即時處理：

3、使用 PowerShell 運行 Start-DedupJob -Volume V: -Type Optimization
注意：此時 3 個 VM 都在運行中。
4、結果：

Dedup 成功。VM 運行不受影響。
至於好處那也是顯然易見的——在這個只有 300GB 的 SSD RAID 分區上，同時運行 30 個 VM 也不會覺得擁擠了。如果都只是基礎鏡像，所需的空間可能就 30-40GB 吧~~ :D 剩下的空間大有作爲啦！

Windows Server 2012 R2 RTM: 第二代 Hyper-V VM 儲存性能

Windows Server 2012 R2 RTM 針對 Hyper-V 有比較多的功能特性更新。其中最有代表性的就是，第二代的 VM 去掉了虛擬 IDE 控制器，被虛擬 SCSI 控制器取代。由於 SCSI 指令所需的模擬較少，此層面將會比 IDE 虛擬要薄，從而產生的性能損耗將會少得多。上一代的 VM 只能夠在非啓動槃上使用 SCSI 控制器，現在可以抛棄 IDE 模擬——前提是 Guest 操作系統必須是 Windows 8 或者 Windows 2012 (或以上~）。

下面作一個比較直觀的對比：

主機配置：
Intel Xeon W5580 x2
Tyan S7025
Dell PERC H710P
Intel X25-E x22
Intel RES2SV240 x2

好吧，已經比較過時的硬件，不過那些 Intel X25-E 還可以使用約 80 年……對，80 年……這也是爲什麽現在的 SSD 都是 MLC 而不是 SLC —— 不會坏的 SSD 廠商是不會盈利的~~

開啓了 Hypervisor 后，由於 VM 的硬盤活動，對主機的硬盤性能造成一定影響。一般情況下，主機的 AS SSD 分數應在 2700-2800 之間。分別測試下，得出下面的數據：

 

 

主板/北橋瓶頸了……





看看IOPS:

可以看出，在綫性存取方面，儲存性能已經比較貼近主機的直接訪問性能。4K IOPS 由於本身是 VHDX 的問題，讀寫會多一層，所以額外的操作會導致延遲，從而影響性能。至於最後的存取延遲測試，我覺得可能 VHDX 被 cached 了……

下面看看文件複製性能：

達到主機約 60-75% 的性能。
下面是壓縮測試：

有點令人驚訝的是，壓縮測試中 VM 與主機的性能一致。(Compression Test = 綫性存取？)

總體來説，PERC H710P + Tyan S7025 是沒有辦法完全發揮 22 個 Intel X25-E 的性能……好吧，跑題了，應該是說，Windows Server 2012 R2 在 VM 性能發揮上有比較明顯的提升。可以預期，加上 VHDX 文件的重復刪除 (Deduplication)，在 SSD 上跑 VM 將會是一件很愜意的事情——SSD 容量小的問題也有解決方法了。

而 MLC SSD 的用戶其實也不用怕讓 VM 在 SSD 上運行了。Windows Server 2012 自帶的 Storage Space 可以組成軟 RAID，而我個人覺得，由於此 RAID 還是在操作系統層面上，TRIM 是應該可以實現的，所以 MLC SSD 壽命在 RAID 的情況下也應該不會產生以前的致命問題。當然，3000-5000 次的刷寫極限，還是沒有辦法跟 50nm 大晶體的 100000 次刷寫極限對比的 (Intel X25-E Rocks!)