使用FreeNAS替換ESXI

在將我的MicroServer重裝為FreeNAS之後，我發現我其實並不需要Vmware ESXI，因為我需要的大部分功能，包括web伺服器，流量監控，PLEX，BT下載，都可以通過FreeBSD jail去實現，這完全是一個讓我感到驚喜的場面，只需要些許的點擊，少許的配置，就可以安裝很多應用程式上去，一直以來我都覺得jail是個很好的半虛擬化工具，但FreeBSD的目標受眾畢竟還是相對少很多。

而不太常用的Windows，也可以透過FreeNAS帶有的虛擬化功能，創建一台虛擬機就可以。

至此，所有我需要在ESXI上實現的功能，在FreeNAS中都完整的實現，數據也沒有丟失太多，只有一點點的數據丟失，算是運氣沒有那麼差。

ZFS在很早之前我就有使用，但從未認真關注過，也並沒有使用到RAID特性，FreeNAS是基於ZFS和FreeBSD的實現，在ZFS存儲池中，有以下一些基於RAID的概念需要了解：

Stripe：與RAID0類似，硬碟條帶，至少需要一個硬碟，一個都不能壞；
Mirror：與RAID1類似，硬碟鏡像，至少需要兩個硬碟，可以壞一個；
RAIDZ1：與RAID5類似，一重奇偶校驗，至少需要三個硬碟，可以壞一個；
RAIDZ2：與RAID6類似，雙重奇偶校驗，至少需要四個硬碟，可以壞兩個；
RAIDZ3：ZFS特有的，三重奇偶校驗，至少需要五個硬碟，可以壞三個；

Log(ZIL)：高速寫緩存設備，至少需要一個專用設備，可以使用兩個，建議使用具有停電保護的SSD；
Cache(L2ARC)：高速讀緩存設備，需要至少一個專用設備，可以使用兩個，建議使用具有停電保護的SSD；
Spare：熱備硬碟，當正在使用的硬碟發生故障後，Spare硬碟將馬上代替此故障盤，可以有多個。

關於RAID級別的區別，這裡就不說了，網路上有很多解釋很詳細的文章，可以搜索，由於我的MicroServer是四盤位，所以容量最大化的最小安全設計應該是raidz1，但網路上有很多基於RAID5的恢復失敗案例，主因為同一批硬碟故障率接近，當一塊硬碟出現崩潰，RAID5在恢復過程中大量讀取數據，恢復速度又較慢，此時剩餘硬碟崩潰的可能性大大增加，更重要的是zfs存儲池一旦創建後，是不能修改的，硬碟數量既不能增加，也不能減少，只能更換為更大容量的硬碟，我思考了一下，將四塊硬碟設置為RAIDZ2，容量損失一半，安全增加數倍，兩塊硬碟同時損壞的可能性，幾乎沒有。

高速讀寫緩存，是FreeNAS特有的功能，我用了兩塊PCIE轉NVME轉接卡，各安裝了一塊250G的NVME SSD，對讀寫進行緩存，效果嘛，我發現似乎因為目前我使用的是G網，而不是10G網，即使將MicroServer的兩個網路卡使用LACP聚合到交換機，我訪問NAS的讀速度，依然只能達到G網的峰值，也就是90M/s至109M/s之間的樣子，至於寫速度，同樣的文件，第一次寫入速度大約在60M/s至70M/s，第二次寫入速度會提升到90M/s至109M/s之間的樣子。

寫入速度這麼低，那兩塊希捷的硬碟，一定是所謂的疊瓦，查了一下序列號和批號果然是，當時買硬碟的時候，慣性思考為隨著技術的進步，磁碟密度果然是越來越高，沒想到，這不但是技術的退步，而且明顯是廠商的貪婪，因為廠商並沒有對技術參數進行說明和公開，目前只有希捷沒有公開自己使用了疊瓦技術的硬碟，西部數據和東芝都公開了自己使用了SMR技術的硬碟，當然，西部數據是被逼的，因為他們在應用於NAS的WD Red產品線上使用了不適合於NAS使用的SMR技術而被人揭露，這如果不能用廠商的貪婪來進行解釋，那麼實在是找不出來第二個解釋。

但我寫入的速度需求並不大，沒有iscsi這樣的需求，NFS也大多用於讀取數據，所以這種退步並沒有表達得很明顯。

於是我深深的懷疑，ESXI數據丟失，是因為疊瓦盤造成的，因為在SMR的機制中，當你刪除一個文件或者一部分文件後，磁碟會進行類似於SSD的trim操作，將磁碟遠端的數據複製到近端，如果你要進行一個複寫操作，這時候，磁碟的佔用會很容易達到100%，此時既無法讀取也無法寫入，問題在於，機械磁碟的trim效率遠遠低於SSD，於是就表現為，磁碟無響應，當磁碟無響應之後，在硬體RAID卡中，就可能會出現掉盤或者丟盤的現象，而我之前的Server上，是用了一塊LSI的RAID卡，把四塊硬碟做了RAID10陣列。

這無疑是個隱患，我重新購買了東芝的PMR硬碟，將希捷的SMR硬碟挨個換掉，經過測試，我的數據在ZFS環境下，同樣的數據大小，希捷的SMR硬碟數據重建時間為30到32小時，而東芝的PMR硬碟，數據重建時間為5到6小時，SMR硬碟數據重建的時間是PMR硬碟數的5到6倍，在這5到6倍的時間中，很可能會有另外的硬碟損壞，那麼就很可能出現數據完全丟失的情況，從FreeNAS的netdata plugin中也可以明顯看出兩種硬碟技術的讀寫曲線，SMR硬碟在重建時，寫入速率時高時低，寫入一段時間後，寫入速度會變為0，此時硬碟佔用為100%，經過dm-smr的trim操作後，重新恢復至一個較高的寫入速率，週而復始，而PMR硬碟在重建時，寫入速率穩定在90M/s到100M/s之間，沒有變為0的時候。

在生產線上，關鍵業務一般不會採用重建的方式，當關鍵業務出現陣列降級，會將業務下線，然後用新的硬碟創建新的陣列，將數據從舊的陣列複製到新的陣列上，然後用新的陣列上線業務，這樣可以避免陣列重建過程中，大量的數據讀取使得舊硬碟溫度過高而導致陣列損毀。

至此，終於將MicroServer的隱患消除，之前在ESXI上偶爾存在的lag現象也不復存在，一直以為是AMD的CPU性能不行，沒有想到，居然是被希捷的SMR硬碟坑了一道。