当我执行繁重的磁盘操作（例如一次删除 10k 个文件）时，网络共享将变得无响应并且在短时间内无法提供文件。
这是我的配置。我有一个由两台 Windows 2008 R2 Enterprise 服务器组成的故障转移文件服务器集群。每台服务器都是在两台运行 Windows Hyper-V 的独立 Dell Poweredge 服务器之上运行的 VM。两台 Dell 服务器都配有专用的 Dell MD3000i SAN NIC。每台文件服务器 VM 都通过此专用 NIC 路由其 iSCSI 连接，以连接到文件所在的 SAN 上的卷。
如果我运行一个批处理文件，从通过共享名引用文件的远程计算机执行 10k 次删除（即 \\fileserver\sharename\folder\filename.jpg），则在共享耗尽之前，它可能执行 1,000 或 8,000 次删除。每次都是随机的。讽刺的是，批处理文件将继续删除文件，但访问同一共享上文件的其他服务器将被阻止。我删除的文件不会被其他服务器访问，因此锁定这些特定文件不是问题。
如果我在文件群集的主服务器上运行相同的批处理文件并通过文件的本地路径 (即 x:\folder\filename.jpg) 引用文件，则共享会立即中断，其他服务器将等待。当我终止正在运行的批处理文件时，对该共享的访问将恢复。
有谁知道共享中断的原因，或者我可以做什么来进一步诊断这个问题？任何建议都非常感谢。
更新说明：我已将此问题隔离为仅发生在主机盒边界内。除了与 SAN 的 iSCSI 连接之外，与虚拟机一起复制此问题所涉及的网络流量均不会到达主机盒所连接的物理交换机。iSCSI 连接在标准网络流量之外有自己的专用交换机和到 SAN 的私有子网。
答案1
这说明某种资源耗尽。如果这是一台 Linux 主机，我会想，“这听起来像是一大堆 IO 等待。”检查操作系统级别的性能监视器，就像 mfinni 指出的那样。有两个领域可能存在瓶颈，即逻辑/物理磁盘性能和 iSCSI 网络连接上的网络性能。PerfMon 可以为您提供这些信息。我完全不了解 HyperV，但如果它与 VMWare 类似，那么您也可以查看虚拟机管理程序方面的一些性能指标。这样做。
作为一个理论，我猜你执行的非常高级别的元数据更新会导致 iSCSI 堆栈中的某些固有延迟放大。这反过来又会挤占其他 I/O 或元数据请求，从而导致你描述的症状，当 MFT 块被另一个进程敲打时，其他进程可以插话。iSCSI 本身可能会导致这种情况，但 VM 层可能会增加其自己的内部延迟。如果这确实是问题所在，您可能需要考虑将 iSCSI LUN 呈现给虚拟机管理程序，然后将生成的磁盘呈现给 VM；这样，您就不再依赖于 iSCSI 的虚拟化网络适配器，而是依赖于物理网络适配器。
编辑： 看来您可能遇到过这种故障。我关注的 PerfMon 计数器是运行 iSCSI 连接的接口的“发送字节数/秒”和“发送数据包数/秒”。两者的组合应该会为您提供平均数据包大小。（或者，如果您有能力，可以将嗅探器放入循环中，看看数据包在网络交换机上是什么样子。如果您能做到，这是更可靠的方法）如果该数据包大小非常小（例如，小于 800 字节），那么除了深入到 TCP 级别并查看可以在群集节点和 iSCSI 目标之间进行哪些优化之外，您对此无能为力。Server 2008 对其 TCP 设置很挑剔，因此这里可能会有所收获。
答案2
天哪。事件查看器中是否有任何内容表明操作系统正在经历某种资源耗尽？您可以使用 perfmon 检查吗？