目前我们正在考虑从传统的服务器环境转向SAN / VMWare环境。
我被要求收集主要服务器的性能统计数据 – DC，文件服务器，Exchange，看看它是否对我们的环境是可行的，或者如果我们将要遇到SAN性能问题。
我已经运行了8小时以上的计划基线，包括很多计数器，但是结果日志太大而无用 – 大约需要三分钟的时间才能打开它们，或者让我们查看不同的计数器。
虽然我一般都知道哪些是有用的，看性能是一个足够的列表来监视，这将给我们一个有用的起点，也是什么柜台将是有用的。
我在想
但是柜台是最有用的，还有哪些地方应该特别针对我们的关注？
可能会杀死你的最大的是磁盘IO。 收集每秒的事务数和每秒读取/写入的扇区数将使您开始确定在SAN上需要什么。 同时关注内存和页面文件的使用情况，这可以对你的磁盘IO状态做坏事，并且为你的虚拟机configuration一些额外的内存很简单。
networking可能是下一个最重要的networking，但这非常简单 – 每秒汇总传输和数据包，确保它不是太荒谬。
根据我的经验，CPU是现代系统中可能性最小的瓶颈。 除非您有多台机器始终如一地固定在CPU上，否则我宁愿不要担心。 如果用完CPU，则configuration额外的VM服务器很简单。
经过多一点研究，我认为这是一个很好的通用计数器列表：
逻辑磁盘
记忆
networking
物理磁盘
处理
处理器
系统
对于磁盘绑定，我喜欢监视每个物理磁盘的“\ PhysicalDisk（…）\ Current Disk Queue Length”。
对于使用perfmon查看问题的问题：尽pipe这可能超出了您所做的范围，但是我使用check_nt插件和安装在客户端上的nsclient ++来监视Nagios的Windows计数器。 然后我可以使用n2rrd来绘制所有graphics ，我也可以使用rrdtool来创build自定义graphics。
你列出的所有东西通常运行在vmware / san环境中。 这实际上只是一个关于SAN和虚拟服务器需要多么强大以及正确的体系结构的问题。 如果你愿意花钱购买一个昂贵的SAN，那么供应商应该能够告诉你你需要什么。
根据您的使用情况，磁盘IO和networking似乎是迁移到VMWaretypes基础架构时最为关心的问题，特别是如果您的虚拟机存储在SAN上，您肯定应该评估所有机器的networking使用情况和磁盘IO你会迁移。 大多数用于VMWaretypes的服务器应该有很多的NIC，但是仍然值得注意的是可以使用多less个NIC，以及SAN上磁盘的速度。 VMWare ESX支持不立即将所有磁盘更改写回虚拟机的function，因此您可以通过这种方式节省某些性能。
测量性能，我们使用RRDTool来访问性能，如凯尔所说，这是非常有用的。
虚拟机不像典型的服务器，因为你遇到了不同领域的问题。 大多数情况下，CPU不是瓶颈资源，而是RAM。 在你进入之前要真正了解的事情：
确定是否可以使用文件支持的磁盘，或者是否需要直接显示的LUN，可能需要了解一些信息。 直接呈现的LUN是您的存储arrays将LUN直接呈现给VM的位置，通过使用NPIV可以使其更容易。 你可以在没有NPIV的情况下做到这一点，但是对于你的血液来说可能太危险了，所有全新的光纤通道硬件都应该支持它，而ESX 3.5当然也是如此。 直接呈现方式可以删除存储arrays和虚拟机之间的抽象层，从而使得I / O性能更好。 然而，直接呈现设置起来更麻烦，并且在“围绕它”的阶段有更高的启动时间。
文件备份的磁盘更简单。 另外，它们可以非常简单地在存储arrays之间移动（对于某些简单的复制多GB文件的值而言），这是直接表示需要（通常非常昂贵的）arrays级复制软件来完成的。 低I / O负载的东西工作只是在文件支持，甚至一些更高的I / O事情桃色。 我们正在为文件备份磁盘上的超过3000个用户运行完整的Exchange 2007安装。 备份可能会更快，但在白天用户不会注意到任何减速。