我不是SAN的专家，我在这里写作是为了得到关于我们的供应商似乎无法解决的持续和激怒的问题的一些线索。
我们拥有一台配备16 x 2 Tb磁盘的ENHANCE ES3160P4 SAN，用于我们的video监控系统。 SAN由供应商configuration为在RAID 5arrays中使用14个磁盘，2个磁盘是全局备用。 RAID通常分为两个大小相等的虚拟磁盘，跨越整个RAID空间。 每一个结果是超过12 Tb的东西。 每个虚拟磁盘对应一个LUN，连接到一个连续存储video数据的video服务器，并允许用户在需要时检索logging。 这些LUN使用NTFS进行格式化，并通过iSCSI连接到Windows Server 2012video服务器。 video服务器倾向于充分利用他们拥有的可用空间。
通过此configuration，SAN的磁盘出现故障并失败，并且每次SAN无法恢复RAID，因为另一个磁盘出现故障。 在过去的几个月中我们失去了4次RAID。
这个问题似乎不是由于一个坏的SAN样本造成的，因为我们拥有其他三台类似configuration的同样types的机器，似乎也有相同的问题。 只有一个没有问题，但目前没有得到充分利用。
经过几个月未知的testing和检查，供应商最后说，众所周知，SAN不应该被100％使用，或者它会在物理上快速降级，并且说为了解决这个问题，虚拟磁盘应该被创build留下RAID中可用总空间的10-15％。
我在网上search了这个问题，没有find具体的说法。 在我看来，创build跨越整个RAID的虚拟磁盘然后使用不足的LUN（即允许Windows具有空闲空间并避免碎片化）会更合理。 如果不是的话，我不明白为什么ENHANCE SAN允许创build跨越整个RAID的虚拟磁盘，如果它是“众所周知的”，必须留下一些空闲的空间，以及为什么供应商在开始时configuration系统…但这是另一点。
最后，我们要解决这个情况。 任何build议都被接受。 如上所述，我不是SAN专家，但是我经历了很多问题后，才真正了解供应商是否知道发生了什么事情，因为我们不能再接受这种情况了。
提前谢谢了！ 问候
编辑：磁盘types从答案似乎是相关的信息，我补充说，磁盘都是西部数据模型WD2001FYYG-01SL3。
从你所描述的问题来看，主要的问题是他们决定使用RAID5来处理这么大的arrays，这对于这个设置来说是个不错的select，因为你经历的原因是：在恢复期间出现第二个磁盘故障，而这第二次失败也很可能会冒这个风险。
如果他们已经使用了例如RAID6，则在恢复过程中出现第二个磁盘故障不会导致arrays发生故障，并且恢复可以正常进行，代价是一个磁盘的净存储容量和一定的性能影响。
我看不出15％的可用空间是如何帮助解决这个问题的，而从文件系统的性能angular度来看，这可能是也可能不是一个好主意，这显然与失败的RAID无关。 我就这个叫废话。
所有这一切，我不禁要问：在几个月的过程中多次发生这种情况，即使对于RAID5系统来说也是如此。 我会build议查看所使用的磁盘types – 它可能只是您的供应商使用便宜的台式机驱动器，而不是经过authentication的24/7驱动器在这样的系统中使用。