【51CTO 9月29号外电】对于企业的IT部门来说，虚拟化技术是一种很有效的工具，可以大大提高基础架构的效率。但要是没有经过合理规划，你很容易因无法合理地扩展系统而受挫。
那么，该如何规划虚拟化系统所需的容量，以便***不会出现开支过度或资源不足的情况呢?下面是需要考虑的一些关键方面。
采用单一架构
许多公司会犯的其中一个最严重的错误就是，试图在没有合并的网络上运行合并后的系统。针对诸如存储设备和服务器之类的特定部件分开建立数据中心网络再也不合适了。
随着许多公司迁移到私有云计算——在这种环境下，系统合并到了数量较少的设备上，网络管理起来必须更加简单，还要支持庞大的流量。
融合网络构成了下一代数据中心的基础;而融合网络的特点是，存储设备流量和服务器流量在统一架构上传送。
融合网络协议大战基本上尘埃落定;现在可以买到与厂商无关的万兆连接设备，这种设备对服务器和存储设备的支持足够好，可以帮助你避免启动风暴(bootstorm)之类的问题。
在单一网络架构上管理虚拟化系统可以大大简化管理员们的工作，在确保系统正常运行时间的同时，降低管理成本。
全面摸底
在你扩大试点项目的规模之前，有必要了解一下目前的系统在处理什么负载。使用管理工具了解系统活动的基本情况是关键的一步，但是从中了解的情况不一样。
Glasshouse Technologies公司的虚拟化服务主管Erwin Vollering提醒：“十有八九，你的客户以为自己摸清楚了情况，但是他们了解的只是安装在工作站上的应用程序而已，对于那些应用程序的具体使用情况所知不多。”
使用网络探测器或客户端代理来估量这方面的情况后，就可以了解你的桌面虚拟化系统从15个机器扩大到1500个机器后，预计会出现什么样的局面。
别忘了对你的系统进行抽样测试，了解你的计算需求会出现剧烈的变化。然后，你就可以计划模拟峰值负载。
与厂商交流
规划扩展系统时，有必要全面了解所用硬件的功能。向存储厂商尽量多打探一些信息，了解他们的系统在某些负载下运行情况如何。
在以应用为中心的环境下，你必须确保软件也考虑在内。面对庞大的工作负载，软件运行起来如何?你的关系数据库行不行?还是说需要迁移到大型的多节点数据库?
在大数据当道的时代，这成了一个关键的决策。你可能需要完全重新考虑交付应用程序的方式，如果这是一种为不同的基础架构设计的遗留应用程序，更是如此。
加强集成
你的所有硬件都有效地集成起来后，合并后的虚拟化系统工作起来要高效得多。
下一代数据中心的特点之一就是支持集成环境的统一网络架构;在这种环境中，存储设备、服务器和网络设备都经过了优化，以便协同运行。
这提供了更好的性能，还让系统管理工具更容易全面了解硬件基础架构的情况，因而更容易全面了解在基础架构上运行的软件。应考虑构建让合并后的系统更顺畅运行的下一代数据中心架构。
注意故障点
设计的系统可能是为了满足在特定的时间段处理特定数量的交易这一要求。
系统面临的交易量增加后，单一故障点就成了一个切实存在的问题。如果你试点系统中的交换机出现故障，起到故障切换作用的交换机也许能够接过重任。但是如果交易量增加一个数量级后，还会是这种情况吗?
设计多个故障区是个好主意——故障区在系统的不同部分隔离开来，那样基础架构的任何部分都不会在任何一个时间点受到危及。
理想情况下，你还需要设计应对系统全部峰值负载的那些系统，以便万一出现故障，它们就能够接过重任。
系统规模扩大后，这一步很难做到。亚马逊建在都柏林的弹性块存储(Elastic Block Store)系统最近之所以过了那么久之后才恢复如初，一个原因是由于变压器出现了故障，结果数量众多的服务器同时出现了停运。
其余还在运行的服务器不断试图复制所发现的一切数据，这导致了客户的交易“陷入停滞”。亚马逊只好用卡车运来更多的设备，以增加容量。
亚马逊称：“之所以出现了延误，是因为故障发生在都柏林的晚间;用卡车运送设备需要从离数据中心有一段距离的地方运过来。”
IT管理服务公司Adapt的架构主管John Soanes说：“要规划和测试重新启动。”
“由于你面临争夺资源的情况，因而接连出现故障。所以，有节制地努力打造一个庞大系统确实很重要。”
结论
“如果进去的是垃圾，那么出来的也是垃圾”这句格言渗透到了从代码编写到系统设计的IT的方方面面，它同样适用于虚拟化。
一开始获得高质量的信息，就能避免以后出现问题。还要考虑自下而上地设计各个方面，以便融合架构可以提升性能、简化管理。
【51CTO.com独家译稿，未经授权谢绝转载!合作媒体转载请注明原文出处及出处!】
译文来源： http://www.theregister.co.uk/2011/09/26/network_virtualisation_plan_for_growth/
