Zimbra - NFS 與 iSCSI
在接下來的幾個月裡，我們將把我們的郵件伺服器從 postfix/courier 遷移到 Zimbra。我們已經非常成功地通過從 Dell Equallogic 導出的 iSCSI LUN 執行了原型伺服器。Equallogic 不是我們的“生產”SAN，NetApp FAS 2050 是。
擁有基於 iSCSI LUN 的系統的問題之一是缺乏靈活性。如果我們需要調整大小而不必關閉整個系統怎麼辦？我覺得將 Zimbra 數據儲存放在 NFS 導出上會有所幫助
- 隨時調整大小的靈活性，無需停機
- 過去文件修訂的快照更容易訪問
- 無需擔心文件系統損壞/沒有 fsck’in
切換到 NFS 的缺點
- 速度
- 可靠性（？）
- 速度
問題是，Zimbra（執行包括 spamassassin、jetty 和最重要的 MySQL 在內的一整套守護程序）是否足夠可靠和穩定以在 NFS 下執行——我們是否會讓自己失去在 NFS 下執行 MySQL 的數據？如果我們確實選擇在 NFS 下執行它——我們可以做些什麼來調整性能？
在 NetApp 上即時調整 iSCSI LUN 的大小沒什麼大不了的，我們一直都在這樣做。唯一的問題是文件系統對動態調整塊設備大小的支持級別。也就是說，易於使用快照和 WAFL 日誌文件系統是 NetApp 上 NFS 的兩大優勢。
雖然在我的工作中我不處理 Zimbra 或任何其他郵件伺服器，但這聽起來非常像 ESX 的 FC/iSCSI 與 NFS 辯論。在 NFS 上針對 NetApp 執行 ESX 是不費吹灰之力的，主要是為了快照和 WAFL 的可靠性。速度還沒有被證明是一個問題。有大量的基準測試表明，對於 ESX，1GBps NFS 可以與 4GBps FC 保持一致（這主要是由於 ESX I/O 流量的高度隨機性）。
如果你想要更快，你總是可以在 NetApp 中安裝一個 10GBps 的 NIC（不確定 2000 系列是否可以做到 10GBps……），它可以吹走你今天可以買到的任何 (8GBps) FC 卡。
Zimbra 論壇上有一篇關於這個主題的文章。那裡的海報與 NFS 一起使用。