我不是存储专家。我知道如何拼写 SAN 以及一些其他基础知识，但仅此而已。
标准磁盘计数器在测量 SAN 存储时是否可靠？我们有 2 台 MS SQL (2005) 服务器，都连接到同一个 SAN，昨天开始出现问题。我们无法控制硬件，因此除了通过 Veritas Enterprise Admin 看到的 LUN（即基本卷配置）之外，我对存储的配置方式没有太多信息。我无法使用任何工具来监控控制器或交换机上的吞吐量。
取而代之的是，我运行了性能监控计数器（物理和逻辑磁盘时间百分比，物理和逻辑磁盘队列长度）。物理磁盘的磁盘时间百分比数字似乎很不正常 - 高达 32000%（是的，32K）。
这是正确的吗？或者我是否正确地认为某些东西从 LUN 级别以下聚合起来以形成该指标，并且这个计数器不是我应该用来对抗 SAN 存储的东西？
编辑：
应该补充的是，我们最近发现 32 个缓存模块中的一个出现问题，因此被移除。我知道它是日立的，但我不知道具体型号。
更新：
日立刚刚更换了故障内存模块并重新初始化了光纤端口卡，现在一切似乎都恢复正常了。感谢大家提供的信息！
答案1
%Disk Time 的看似疯狂的数字确实表明了一些事情，但是 Perfmon 得出 %Disk Time 的方式意味着数字>100％并非不可能。
%Disk time实际上是一个计算计数器，它来自：
Avg Disk Sec/Transfer * Disk Transfers/sec.
平均磁盘秒/传输将当前间隔内所有 IO 的完成时间相加，然后除以 IO 数量，得出平均端到端完成时间。每秒磁盘传输数就是完成 IO 的总数除以间隔。
许多 IO 可能在当前间隔之外发起，因此其乘积可能大于 100%。这种情况可能发生在任何系统上，但在 SAN 等复杂磁盘阵列上，超过 100% 的情况更常见。
由于计算方式的原因，%Disk Time 并不能真正告诉你很多信息，尽管在本例中它告诉你有些地方不对劲。使用 (100-%idle time) 计算利用率是一个更好的主意，因为 %idle time 实际上是直接测量的。
磁盘队列长度可能比简单的本地存储设置中的队列长度大得多，但通常如果队列长度 >> 支持 LUN 的主轴数量，则情况正在好转，特别是如果队列长度在相当长的一段时间内稳步上升。在具有 10-15 个磁盘的 LUN 上，值为 10 甚至 20 根本不是问题，但值为 350 肯定说明出了问题。缓存故障或配置不当肯定会导致此类问题，但也可能存在其他原因。
也就是说，如果您想知道到底是什么，您真的必须查看 SAN 级别的性能监控，并且您必须从 SAN 人员那里获得这些信息。问题可能出在 LUN 上的磁盘上（可能磁盘发生故障并且正在进行 RAID 重建，可能由于某种原因缓存被禁用，可能从同一磁盘剥离的其他 LUN 具有更高的优先级并且很忙），可能缓存在该特定阵列上被禁用/失败，也许 SAN 结构或交换机遇到问题。
有一篇关于Windows 中的磁盘计数器。
答案2
这些 LUN 的“平均磁盘读取队列长度”和“平均磁盘写入队列长度”性能值是多少，各个服务器之间如何相互比较。
如果你能和你的 SAN 伙伴们商量出一些安静的时间，那么你就可以跑了IO区域在两台机器上进行并比较结果。
答案3
有些计数器对您有用，有些则无用。诸如当前磁盘队列之类的信息将告诉您 Windows 主机在发送读/写命令和根据 SAN 中的缓存处理该命令之间看到的排队情况。但如果磁盘运行良好，您仍然可以看到主机上的排队，因为缓存问题、交换机问题或光纤问题。
每次读取的秒数和每次写入的秒数等内容的工作方式相同，它们告诉您写入缓存需要多长时间。
每秒 IO 写入次数等数字更有用。同样，这是 SAN 缓存的 IO，但该 IO 必须在某个时刻到达磁盘。每秒 IO 读取次数也是如此。这是从磁盘和缓存读取的，但如果它在读取缓存中，它会在某个时刻从磁盘中出来。