企业级存储最佳实践

Question

一直困扰我的一件事是存储最佳实践。文件系统吹嘘它们的大小如何是千兆字节或千兆字节。然而，我不知道有多少系统管理员愿意让一个卷在几个地形上增长。我知道这背后的主要原因是，如果驱动器失败，重建数组需要多长时间。单个LUN中的驱动器越多，在重建过程中损失另一个驱动器的风险就越大。

还有使用原因。管理员将根据他们认为需要为项目分配多少空间来划分一个LUN。对我来说，对于LUN来说，成为一个大数组并使用配额似乎更实用。我知道这并不能满足所有的需求(iSCSI)，但我看到很多NAS系统(NFS)都是这样管理的。我也明白，潜在的交易量可以根据需要很容易地增长/缩小，但是使用配额而不是操纵数量和可能的数据丢失会不会降低“风险”呢？

也许还有其他原因让我错过，所以请告诉我。我们不能期望文件系统如此庞大吗？我们是在等待硬件更快地缩短重建时间吗？

Answer 1

主轴分离是一个很好的理由，没有一个大的体积。如果您在单个NFS设备上运行Exchange和其他随机对象(可能是ESXi来宾)，您肯定会希望主轴分离。Exchange数据和longs应该与彼此独立的纺锤以及SQL数据库和日志分开。

Answer 2

重建驱动器不依赖于文件系统，而取决于驱动器本身。如果您使用2TB驱动器，那么您将需要大量的时间来重建。

重建是raid 5的一个问题。因为现在控制器可能支持raid 6或更好，您可以制作raid 10 (如果您想要最好的性能)。导出lun是SAN的工作，导出文件系统是NAS的工作。

两者各有优缺点(谷歌搜索，有大量的文件)。制作许多独立的luns (或文件系统)具有快照备份的优点。

Answer 3

就我个人而言，我根本不会在iSCSI或NFS上运行真正的企业流量(Oracle、MSSQL、Production )--我知道并信任FC，无论是在一般性能方面还是在失败情况下。哦，当然，这意味着我不能仅仅创建大量的LUN和细分，它确实创造了相当多的复杂性/工作，但是我们的系统可用性和最终用户体验比我们所希望的更好和更一致。

至于你的实际答案--好吧，你的帖子似乎非常面向NetApp/filer，因此我的最后一段--但你自己已经列出了原因。磁盘接口已经大大落后于磁盘容量-这意味着重建时间可能是荒谬的，特别是如果您想要看到良好的性能在重建期间，您现有的流量。磁盘总是死气沉沉的，在重建过程中影响多个平台性能的想法只会使管理员的生活变得更容易，这确实是一种短暂的方法。另外，纯粹从平台安全的角度来看，您可能希望对系统进行分区，而“大型LUN”方法在这种情况下可能不起作用(当然是基于硬件)。

最终，企业SAN本质上是业务或任务的关键，要求可用性和一致性高于成本、易于管理甚至是最终的性能。