我们目前正在考虑从传统的服务器环境迁移到 SAN/VMWare 环境。
我被要求为我们的主要服务器（DC、文件服务器、Exchange）收集性能统计数据，以查看它对我们的环境是否可行，或者我们是否会遇到 SAN 性能问题。
我已经在 8 小时内运行了一些预定的基线，包括许多计数器，但生成的日志太大而无用 - perfmon 大约需要三分钟才能打开它们，或者让我们查看不同的计数器。
虽然我通常知道哪些对查看性能有用，哪些是足够的监控列表，可以为我们提供一个有用的起点，还有哪些计数器对此有用。
我在想
- 中央处理器性能
- 磁盘/文件
- 网络使用
- 活动目录（GPO、登录等）
但是哪些计数器最有用，还有哪些我们应该特别关注的领域？
可能会杀死您的最大因素是磁盘 IO。收集每秒事务和每秒读取/写入的扇区将使您开始确定在 SAN 上需要什么。还要注意内存和页面文件的使用，这可能会对您的磁盘 IO 统计数据造成不良影响，并且为您的虚拟机配置一些额外的内存很简单。
网络可能是下一个最重要的，但这很简单——每秒聚合传输和数据包，确保它不是太荒谬。
根据我的经验，CPU 是现代系统中最不可能出现的瓶颈。我倾向于不担心它，除非你有多台机器一直在固定它们的 CPU。如果您的 CPU 用完，则配置额外的 VM 服务器很简单。
经过更多研究，我认为这是一个很好的通用计数器列表：
逻辑磁盘
记忆
网络
物理磁盘
过程
处理器
系统
对于磁盘绑定，我喜欢监视每个物理磁盘的“\PhysicalDisk(...)\Current Disk Queue Length”。
对于您使用 perfmon 查看事物的问题：尽管这可能超出了您的工作范围，但我使用 Nagios 使用 check_nt 插件和安装在客户端上的 nsclient++ 监视 Windows 计数器。然后我可以使用n2rrd绘制所有内容，也可以使用 rrdtool 创建自定义图表。
您列出的所有内容通常在 vmware/san 环境中运行。这实际上只是 SAN 和虚拟服务器需要有多强大以及正确的架构的问题。如果您愿意花现金购买昂贵的 san，供应商应该能够告诉您您需要什么。
根据您的使用情况，磁盘 IO 和网络可能是迁移到 VMWare 类型基础架构时最需要关注的问题，特别是如果您的 VM 存储在 SAN 上，您绝对应该评估所有机器的网络使用情况和磁盘 IO你会迁移。大多数用于 VMWare 类型的服务器都应该配备大量的 NIC，但仍然值得牢记您可以使用多少个，以及 SAN 上的磁盘速度。VMWare ESX 支持不立即将所有磁盘更改写回 VM 的能力，因此您可以通过这种方式节省一些性能。
正如凯尔所说，我们使用RRDTool来衡量性能，这真的很有用。
虚拟机与典型的服务器不同，因为您会在不同的领域遇到问题。大多数时候，CPU 不是瓶颈资源，但 RAM 是。在你进去之前要真正知道的事情：
确定是否可以使用文件支持的磁盘或是否需要直接呈现的 LUN 可能需要一些了解。直接呈现的 LUN 是您的存储阵列将 LUN 直接呈现给 VM 的地方，使用NPIV使这变得更容易。您可以在没有 NPIV 的情况下执行此操作，但它可能对您的血液来说太危险了，所有全新的光纤通道硬件都应该支持它，而 ESX 3.5 肯定支持。直接呈现消除了存储阵列和虚拟机冲击 I/O 之间的抽象层，从这个意义上说，它可以提供更好的性能。但是，直接演示设置起来更棘手，并且在“环绕它”阶段具有更长的启动时间。
文件支持的磁盘更简单。此外，它们可以非常简单地在存储阵列之间移动（对于某些简单的值，涉及复制多 GB 文件），直接呈现需要（通常非常昂贵）阵列级复制软件来完成。低 I/O 负载的东西在文件支持上工作得很好，甚至在一些更高 I/O 的东西上也是如此。我们正在文件支持的磁盘上为超过 3000 名用户运行完整的 Exchange 2007 安装。备份可能会更快，但在白天用户不会注意到任何减速。