如何确定服务器整合项目中的整合率?

日期: 2011-09-20 作者:Malcolm Hamer翻译:徐扬阳 来源:TechTarget中国 英文

服务器整合项目一般都从收集数据开始:收集服务器的资源需求以及统计数据,以使你能够确定服务器的整合率。一个服务器整合项目中分析阶段的目标是创建一个最终整合状态的完整定义。   最终整合状态包括以下几点: 一份在服务器整合项目后最终将保留的服务器列表。这包括那些将保留的以及将新购置的服务器。

每台服务器上将创建的虚拟机数量。一些服务器可能不会安装虚拟化软件,而保留为标准的服务器。这些服务器会承载一个单独的应用程序或一个单独的数据库,亦或是两者的结合。每个应用程序以及数据库实例在这个虚拟环境中将放置的确切位置。

如果其将置于虚拟机中,那么要确定具体的某台物理服务器中的某个虚拟机;如果其将置于一台不虚拟的……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

服务器整合项目一般都从收集数据开始:收集服务器的资源需求以及统计数据,以使你能够确定服务器的整合率。一个服务器整合项目中分析阶段的目标是创建一个最终整合状态的完整定义。

  最终整合状态包括以下几点:

  • 一份在服务器整合项目后最终将保留的服务器列表。这包括那些将保留的以及将新购置的服务器。
  • 每台服务器上将创建的虚拟机数量。一些服务器可能不会安装虚拟化软件,而保留为标准的服务器。这些服务器会承载一个单独的应用程序或一个单独的数据库,亦或是两者的结合。
  • 每个应用程序以及数据库实例在这个虚拟环境中将放置的确切位置。如果其将置于虚拟机中,那么要确定具体的某台物理服务器中的某个虚拟机;如果其将置于一台不虚拟的标准服务器中,需确定具体的某台标准服务器。

  你应该保留哪些服务器?

  在服务器整合项目的分析阶段,你的第一步应该是确定哪些服务器将保留在新的环境中。然后你可以计划服务器整合率。这可以按照服务器整合计划表中详细的参数:处理器、内存以及网络接口来决定。

  你也许会决定通过添加内存来升级一些服务器。一旦你确定了保留哪些服务器,你可以分配简单的编号给它们(E1, E2, E3等等),方便服务器整合项目中接下来的步骤。

  应用程序整合

  然后你可以开始主要的分析任务:分配每个应用程序实例和数据库实例到某台最终状态的物理服务器。如果在你的项目中有几百台,甚至几千台服务器,这将会是一项艰巨的任务。但是,某些假设可以帮你显著减少选择的数量并更好的计划服务器整合率。当然,一个需要两个月来进行数据收集的服务器整合项目,通常不会只需要三个小时就完成分析。

  当选择整合到同一台物理服务器上(但在不同的虚拟机中)的程序以及数据库时,以下几点是应用程序整合目标:

  • 不要在一台物理服务器上部署超过合理数目的虚拟机。例如,在生产环境服务器上你也许需要10台虚拟机,但是在测试和开发实例中也许需要较少量的。
  • 虚拟化软件能在每台服务器上支持超过200个虚拟机。但是,你应该避免在一台物理服务器上部署如此集中的生产实例。因为这样会产生单点故障。
  • 不要让物理服务器过载。确保所有应用所需的CPU、内存以及网络连接资源总和在机器的承受范围以内。

  为了实现前两个目标,你应该将重负载应用与轻负载应用或者数据库混合在每台物理服务器中。仅部署一些轻负载应用,将无法有效地利用服务器的所有资源,这与应用整合目标的第一条是相违背的。如果你将一些重负载应用放在一起,在各应用使用的高峰期,你将会遭遇低性能的风险。

  追踪应用程序

  Indus IT  Valley提供的应用整合工具(Application Consolidation Tool, ACT)可以帮你简化追踪应用程序实例。其它的第三方服务也可以帮你计划应用整合。如果你倾向于不通过使用其它工具来完成识别过程,传统的方法是将这些信息提炼成一个 Excel表格内。表格中每个应用程序或数据库实例可作为一行。你的应用程序整合列表应该包括这些列:

  • 应用程序编号/数据库编号
  • 当前服务器编号
  • 角色
  • 绿区(开始运行日期/时间以及结束运行日期/时间)
  • 工作流参数
  • 工作流等级
  • 特殊情形
  • 物理服务器分配
  • 虚拟机数量

  前两列能够识别出每个应用或数据库实例以及当前所处的服务器。

  工作流参数是描述这个应用程序或数据库实例,在其最终将处于的服务器上占用资源的百分比。工作流等级是你从工作流参数以及一些其它类似参数得出的一个广义的分类(高、中、低、不适合等等)。

  特殊情形一栏应该包括这个应用或者数据库的关键的特殊信息。这个数据来自于数据中心的记录或者之前的调查。在做关于你服务器整合计划的最终决定前,你需要将所有应用的特殊情形都考虑进去。

  在物理服务器分配以及虚拟机数量两栏,你将会填入一个代码(例如E3)来识别一组应用或者数据库将处于的物理服务器。虚拟机数量定义这台物理服务器上具体的虚拟机数量。当你将所有将得到保留的服务器指派为E1、E2、E3等最终状态代码后,你可以将新服务器指派为类似N1、N2、N3之类。

  为了更容易确定每个实例被分配到哪台最终状态的物理服务器,结合上面的应用程序/数据库实例表来进行排序和分析。你可以采取这大致的五步,来实现你的服务器整合计划。

  1. 通过特殊情形来对那些必须采用一个单独服务器的应用程序/数据库实例进行排序。在物理服务器分配一览对每个实例填入代码(E1、E2、E3等等)。虚拟机数目一览填入“NV”来表面这将会是台不采用虚拟化的服务器。
  2. 对剩下的实例通过工作流级别来排序。对任何属于“不适合”级别的实例分配单独的服务器。

  3. 将没有在前两步中被分到独立服务器的实例按照角色和绿区分组。将拥有相同角色的实例在物理服务器中放在一块会是比较好的选择。这样在将来对服务器采用不同的标准以及支持时,能够更容易。
  4. 将第三步中每组中的实例分配到各台物理服务器中。你应该针对工作流等级来平衡的分配——例如,两个“高”、三个“中”以及五个“低”。确定分配到每台物理服务器中实例的工作流参数总和相对服务器的总资源至少达到30%,但不超过50%。一旦你的选择看起来可接受了,将物理服务器代码填入相应实例行中。并且填入虚拟机数量一览(从1开始,在相同的物理服务器中递增)。
  5. 重复这个步骤,直到你将所有处于一个类似绿区的实例都分配完。继续按照角色和绿区来分配其它实例。

相关推荐

  • Docker容器一夜成名的故事

    Linux容器技术是在2008年引入的,Docker软件最初就是基于Linux容器构建的。这么说来,容器如今突然引发人们兴趣,原因何在?

  • 部署服务器整合计划时要避免五大错误

    服务器整合是很多公司开始采用虚拟化的驱动力。在部署服务器整合计划时,有太多因素需要考虑。别让以下五个陷阱绊倒你。

  • 打造低成本虚拟化

    虚拟化有助于提高效率、灾难恢复、存储等等,其众多优势也有降低成本的效益。许可、整合和节电是虚拟化实现节省成本的三个主要方面。本期《打造低成本虚拟化》技术手册将从许可、整合和电源管理三方面帮助你真正地降低对虚拟化的投入成本。

  • 你的服务器整合计划是否满足了可用性和故障转移需求?

    服务器整合计划是优化数据中心的一个重要步骤,需要大量的考虑和计划。那么我们应该如何制定服务器整合计划呢?每个服务器上应该预留多少容量呢?