服务器 Gind.cn
  1. 服务器 Gind.cn
  3. ESX 3.5资源组
Intereting Posts
ZyWALL USG 200随机崩溃 SQL Server镜像 – 你有多less个SQL镜像服务器？ 如何在我的网站上使用SSL证书？ 当使用超过128M的PHP分段错误 Windows Server 2008 R2显示事件ID 137错误 发送邮件，然后在后缀中删除 APC最小的shm大小 Server 2012 DFS复制限制值 lastb：/ var / log / btmp空 Ubiquiti EdgeRouter POE上的反向代理 由于不同的磁盘技术而出现杂乱的磁盘 – LVM的答案？ 使Apple Wiki服务器parsing为域名 在迁移到非常相似的硬件之后，Hyper-V虚拟机非常慢。 从SQL服务器dynamic插入单个logging到MS访问 Systemd：作为服务运行时，Redis服务器无法启动 – 符号链接层次太多

ESX 3.5资源组

我是一名DBA，负责pipe理一个vmware ESX 3.5集群，主要托pipeSQL Server和一些应用程序服务器，而且我还有一个关于如何设置资源组的问题， 但是我与ESX系统pipe理员之一有关pipe理资源 。

集群（3个节点，每个节点32GB）目前拥有33个configuration为消耗77GB内存的guest虚拟机，尽pipeESX报告只有44GB处于活动状态。 集群托pipe住，testing，开发服务器和一些其他的杂项客人。

我想做的是简化服务器资源的pipe理，并能够pipe理和报告相关服务器的性能。

例如，Live SQL服务器，SharePoint服务器，CRM服务器等消耗的资源（RAM，磁盘，CPU）

我接下来做的是创build4个“顶级”资源组。 

1-High - For the most mission critical services (ie. the live SQL server) 32768 memory shares 2-Normal - For the majority of the remaining live systems (CRM, Sharepoint etc) 16384 memory shares 3-Dev - Test and development systems 8192 memory shares 4-Low - Non supported servers (no sla, temporary build servers etc) 1024 memory shares

我已经将服务器分组到他们自己的“应用程序”资源组（SQL Live，SQLtesting，CRM Live，CRMtesting等），但没有对这些组设置任何明确的资源限制。

然后，我将“应用程序”组放入适当的“顶级”资源组中。

例如，每个子组有4个访客，每个1个CPU和1GB RAM 

 1-High 32768 shares SQL Live 4 guests 2-Normal 16384 shares CRM Live 4 guests Sharepoint Live 4 guests 3-Dev 16384 shares CRM Test 4 guests SQL Test 4 guests Sharepoint test 4 guests 4-Low Remaining cruft 4 guests

系统pipe理员会告诉我：“Sharepoint只能获得所需资源的50％的28％！”

在我回复他之前，我可以得到一些build议和检查我的假设：

  • 在正常操作中，群集不会过度使用RAM（或CPU），因此不会对任何来宾（CPU或RAM）应用资源限制。
  • 如果其中一台主机发生故障，那么只有64GB的内存可用。 当客人重新启动（我们启用了HA和DRS）时，剩下的主机将开始重新启动guest虚拟机，并且这将过度使用RAM。
  • 我想确保最高优先级的服务保持其服务
  • 我不想微观pipe理每个客人！

你有什么想法和经验？

如果我正确地阅读这篇文章，那么你对你的环境的正常运作是正确的，但我不确定你们中的任何一个在竞争时如何工作是正确的。

当没有争用（当资源利用率超过80％时争用开始），则股份不起作用。 因此，就您所处环境的正常运营而言，资源小组将是一个整体。

当存在争用时，CPU资源将受到系统pipe理员指示的限制，但是如果您丢失主机，则不一定会发生。

您不会说是否修改了子资源池上的共享。 我会假设这些都设置正常。

假定共享工作的方式存在争用，即每个资源池获得的资源比例等于该级别总股数的一小部分。 对于你的第一个级别，你有58万股，所以高池大约56％，正常28％，开发14％，最低1.7％。 在每个池中，子池共享该池的资源，除非您明确设置了该级别的额外共享，如果您拥有相同的规则，但池的总数不受影响。

因此，如果出现争用，Live Sharepoint系统将获得28％的竞争资源中的50％，即14％。

您可以通过为每个系统所需的CPU和RAM的绝对最小值分配预留值来帮助解决问题。 保留的值保证给您分配给他们的系统\资源池，不被共享分配。 它们的主要缺点是如果值太高，集群可能无法尝试重新启动虚拟机，因为资源不能得到保证。

另外请记住，即使系统在Windows系统正常运行时只消耗〜44GB，当启动VM时，100％的内存也会被分配（暂时）。 这可以在故障转移期间触发内存的争用情况，即使系统运行时系统实际上有足够的RAM。 要注意的一点就是不要太担心，但是在HA重启过程中可能会导致问题。

编辑添加
如果您对个别虚拟机或子资源组的默认共享设置没有做任何更改，那么当您将所有虚拟机升级到只有一个子级RG的结构中时，分配给单个虚拟机的资源比例不会改变并将它们直接放置在父项中。 但是，如果有多个孩子的RG和不同数量的虚拟机，那么这是不正确的。

在你的例子中，我们有他们的孩子RG中的4个Sharepoint虚拟机和他们的子组中的2个CRM虚拟机。 Sharepoint虚拟机分别达到3.5％（28％/ 4的50％）和CRM虚拟机分别达到7％（28％/ 2的50％）。 如果现在将所有这些移动到父级RG并删除空的子级RG，则现在有6个VM共享正常RG的28％的可用资源，每个将获得〜4.7％（28％/ 6）。

当然，如果您更改子资源组或单个虚拟机上的共享，这一切都将改变。

资源定义只在过度使用的集群中生效。