有一件事一直让我感到困惑，那就是存储最佳实践。文件系统吹嘘它们的大小可以达到 PB 或 EB。然而，我不知道有多少系统管理员愿意让单个卷增长到几 TB。我知道这背后的主要原因是如果驱动器发生故障，重建阵列需要多长时间。单个 LUN 中的驱动器越多，重建所需的时间就越长，重建过程中丢失另一个驱动器的风险就越大。
然后是使用原因。管理员将根据他们认为需要分配给项目的空间大小来划分 LUN。我认为将 LUN 设置为一个大型阵列并使用配额似乎更为实际。我知道这不会满足所有要求（iSCSI），但我看到很多 NAS 系统（NFS）都是以这种方式管理的。我也知道底层卷可以根据需要轻松增加/缩小，但使用配额而不是操纵卷并带来可能的数据丢失，难道不是“风险”更小吗？
我可能没有注意到其他原因，所以请告诉我。我们难道不能指望文件系统变得这么大吗？我们是否在等待硬件速度变快以减少重建时间？
答案1
主轴分离是避免使用大型卷的一个很好的理由。如果您在单个 NFS 设备上运行 Exchange、SQL Server 和其他随机事物（可能是 ESXi 客户机），那么您肯定会需要主轴分离。Exchange 数据和 long 应该位于彼此不同的主轴上，SQL 数据库和日志也是如此。
答案2
重建驱动器并不取决于文件系统，而是取决于驱动器本身。如果您使用的是 2TB 驱动器，则需要大量时间来重建。
重建是 raid 5 的问题。为此，现在许多控制器都支持 raid 6，或者更好的是，您可以制作 raid 10（如果您想要最佳性能）。导出 lun 是 SAN 的工作，导出文件系统是 NAS 的工作。
两者都有其优点和缺点（在谷歌上搜索，有很多关于这方面的论文）。制作大量独立的 lun（或文件系统）具有快照备份的优势。
答案3
就我个人而言，我根本不会通过 iSCSI 或 NFS 运行真正的企业流量（Oracle、MSSQL、Production ESX）——我了解并信任 FC，无论是在一般性能方面还是在故障情况下。当然，这意味着我不能只创建大量 LUN 并进行细分，这确实会带来相当多的复杂性/工作，但我们的系统可用性和最终用户体验数据比我们希望的更好、更一致。
至于您的实际答案 - 嗯，您的帖子似乎非常以 NetApp/filer 为导向，因此我写了最后一段 - 但您自己已经列出了原因。磁盘接口远远落后于磁盘容量 - 这意味着重建时间可能非常长，特别是如果您希望在重建现有流量时看到不错的性能。磁盘总是坏掉，在重建期间影响多个平台的性能以简化管理员的工作的想法确实是一种短命的方法。此外，纯粹从平台安全的角度来看，您可能希望对系统进行分区，而“大 LUN”方法在这种情况下可能行不通（当然是基于硬件）。
最终，企业 SAN 本质上对业务或任务至关重要，要求可用性和一致性优于成本、易于管理甚至最终性能。