iSCSI：每個目標的 LUN？
我的問題特別涉及 ZFS/COMSTAR，但我認為通常適用於任何 iSCSI 系統。
是否應該更願意為要公開的每個 LUN 創建一個目標？還是讓一個目標具有多個 LUN 是一種好習慣？
任何一種方法都會對性能產生影響嗎？是否存在其他方法有意義的交叉點？
該案例適用於 VM 磁碟，其中每個磁碟 (zvol) 都是一個 LUN。到目前為止，我們已經為每個 VM 創建了一個單獨的目標；但是包含所有 LUN 的單個目標可能會大大簡化管理……但我們可能需要每個目標數百個 LUN。（然後可能有數十個啟動器連接到該目標）
最佳做法是讓多個 LUN 掛在一個目標上。總共有多少個目標，以及這些目標中有多少實際上暴露了相同的 LUN。我傾向於為您的客戶端設置的每個 MPIO 路徑推荐一個目標，因此，如果我正在設置系統，則至少有 2 個目標（但它們只是同一目標組和目標門戶組的一部分，並且是提供相同的視圖 - 它完全用於 iSCSI MPIO）。
超過 2 個目標的唯一原因通常是業務、網路或其他案例特定壓力帶來的邏輯分離。4、8 甚至多達 16 個目標並不是那麼瘋狂，具體取決於環境的大小和復雜性。如果您超過 16 歲，尤其是超過 16 歲，那麼您在架構中出現錯誤的可能性越來越大，應該聘請專家進行審查。如果您正在使用 iSCSI MPIO（並且您必須使用，因為如果您不使用 iSCSI MPIO，那麼 zvols 和 iSCSI 在文件系統和 NFS 上的唯一主要勝利可能會失去，並且現在使用 iSCSI 幾乎沒有優勢超過 NFS，並且絕對有很多缺點），您通常還應該有偶數個目標（2、4、6、8 等），
還要記住，COMSTAR 在處理視圖方面足夠智能，只要您正確地創建和分配目標組和主機組，您就可以讓一個目標提供潛在的數十個甚至數百個 LUN，其中實際 LUN ID暴露給傳入啟動器（客戶端）的不是 578 或其他任何值，而是每個單個啟動器可能低至 0。這在處理某些客戶端作業系統時很重要，例如 Linux（尤其是較舊的版本），這些作業系統有一個討厭的習慣，即為他們找到的每個 LUN 自動發現和分配設備，並且他們可以處理看到的 LUN 的最大數量並且還有一個最大的“LUN 編號”（實際的 LUN 編號本身，而不是看到的 LUN 的數量）。
我從來沒有花時間對其進行量化，但我的直覺反應是，你會感受到 128 個目標和 1 個 LUN 對性能的影響，就像你對 1 個目標和 128 個 LUN 的感覺一樣，或者稍差一些128 個目標的性能。毫無疑問，COMSTAR 的期望是您正在設置具有多個 LUN 的目標，而不是像以前的 COMSTAR 時代那樣每個目標設置 1 個 LUN。
關於一般環境的評論：
只有在 VM 總數較低（低於 100，最好低於 50）的情況下，或者您沒有考慮到需要在以下情況下導出/導入池的高可用性形式時，才應該為每個 VM 創建一個單獨的 LUN池正在導出/導入時服務處於離線狀態。
這與通過 COMSTAR over ZFS 導出/導入和完全初始化一堆 LUN 需要多長時間有關。每增加一個 zvol，導入時間就會增加 X 毫秒。幾十個沒什麼大不了的，但是當您擴展到 1000 個時會迅速引起一個明顯的問題。我曾經管理過具有超過 3,000 個 zvol 的 Sun 7410，這花費了15 分鐘的大部分時間使用他們的集群功能進行故障轉移（本質上是從一個節點導出池並在進行手動故障轉移時將其導入另一個節點，就像 15 分鐘的怪物一樣）。這在很大程度上是由於數據集的數量，而且它們是 zvol。使用 3,000 個文件系統（不是 zvols）重複完全相同的場景只用了 5 分鐘（仍然很長，但已經縮短了 3 倍，這是幾年前的事了。雖然在 ZFS 中完成這些任務的總時間在此後的幾年中有所改善，但相對zvols 與文件系統的差異以及完全導入和線上的時間仍然存在，最後我檢查了。
現在，如果您的設置中沒有 2 個或更多節點，並且希望在它們之間快速導出和導入，那麼沒有大量 zvol 的最大原因就消失了。由於許多與您的問題不直接相關的其他原因，這仍然不能使其中的 1,000 個成為一個特別好的主意。將它們分開所獲得的好處在一定程度上被擁有大量 zvol 所帶來的管理和性能痛苦所抵消。為了我的錢，我強烈建議改用 NFS，即使（哎呀，尤其是如果）您希望每個 VM 有一個數據集。