一直困擾我的一件事是儲存最佳實踐。檔案系統吹噓它們的大小可以達到 PB 或 EB 級。然而，我不知道有多少系統管理員願意讓單一磁碟區成長到幾個太字節。我確實知道這背後的主要原因是如果驅動器發生故障，重建陣列需要多長時間。單一 LUN 中的磁碟機越多，所需時間就越長，且在重建過程中遺失另一個磁碟機的風險就越大。
然後是使用原因。管理員將根據他們認為需要分配給專案的空間大小來劃分 LUN。對我來說，LUN 成為一個大陣列並使用配額似乎更實際。我知道這不能滿足所有要求 (iSCSI)，但我看到很多 NAS 系統 (NFS) 都是以這種方式管理的。我還了解到，基礎卷可以很容易地根據需要增加/縮小，但是使用配額而不是操縱卷並將可能的數據丟失帶入等式中，“風險”不是更小嗎？
可能還有其他原因導致我沒找到，請各位指教。我們不能期望檔案系統變得如此之大嗎？我們是否正在等待硬體變得更快以減少重建時間？
答案1
主軸分離是不採用大體積的一個很好的理由。如果您在單一 NFS 裝置上執行 Exchange、SQL Server 和其他隨機事物（可能是 ESXi 用戶端），您肯定會想要主軸分離。交換資料和長整型資料以及 SQL 資料庫和日誌應位於彼此不同的軸上。
答案2
重建驅動器不依賴檔案系統，而是依賴驅動器本身。如果您使用 2TB 驅動器，那麼您將需要大量時間來重建。
重建是 raid 5 的問題。導出lun是SAN的工作，導出檔案系統是NAS的工作。
兩者都有其優點和缺點（在谷歌上搜索，有大量的論文）。製作大量獨立的 lun（或檔案系統）具有快照備份的優點。
答案3
就我個人而言，我根本不會透過 iSCSI 或 NFS 來運行真正的企業流量（Oracle、MSSQL、生產 ESX） - 我了解並信任 FC，無論是對於一般效能還是在故障情況下。哦，當然，這意味著我不能只創建大量 LUN 並進行細分，它確實會造成相當多的複雜性/工作，但我們的系統可用性和最終用戶體驗數據比我們希望的更好、更一致。
至於您的實際答案 - 嗯，您的帖子似乎非常面向 NetApp/filer，因此是我的最後一段 - 但您自己已經列出了原因。磁碟介面已大大落後於磁碟容量 - 這意味著重建時間可能很荒謬，特別是如果您希望在重建現有流量期間看到不錯的效能。磁碟總是會死掉，在重建過程中影響多個平台效能以簡單地讓管理員的生活更輕鬆的想法確實是一種短暫的方法。另外，純粹從平台安全的角度來看，您可能希望對系統進行分區，而「大 LUN」方法可能在這種情況下不起作用（當然基於硬體）。
最終，企業 SAN 本質上是業務或任務關鍵型產品，要求可用性和一致性、成本、易於管理甚至最終效能。