如何解决虚拟化SOA给数据中心流量暴增的危机

作者：无名 2009-01-06 18:32:52

云计算

虚拟化 SOA、虚拟化甚至刀片服务器是目前数据中心最热门的技术方向。SOA解决了业务灵活性问题，虚拟化改变了基础架构，在提高计算密度的同时提高了服务器部署的灵活性和可靠性，而刀片服务器的普遍使用将带来能耗以及数据中心空间的巨大改变。 SOA、虚拟化甚至刀片服务器是目前数据中心最热门的技术方向。SOA解决了业务灵活性问题，虚拟化改变了基础架构，在提高计算密度的同时提高了服务器部署的灵活性和可靠性，而刀片服务器的普遍使用将带来能耗以及数据中心空间的巨大改变。

但是这些技术的一个共同特点，就是改变了数据中心的网络流量。高密度的计算和越来越多的数据中心内部流量使服务等级保障成为一个巨大的难点。

以微软的数据中心虚拟化为例，按照微软中国公开的资料，其虚拟化的整合比例达到了10：1，也就是虚拟化后服务器数量减少了90%。这意味着虚拟化过后，微软的数据中心每台服务器要对应以前10台服务器的数据流量。

SOA和虚拟化交织在一起使数据中心的流量压力变得更加复杂。不管是谁家的SOA方案，企业服务总线的采用就是必然。简单的说，以前一种前台应用对应一台后端服务器的模式将被打破。在SOA架构下，用户一个简单的网页可能要请求更多的服务器才能完成，这必然导致大量的服务器间也就是数据中心内部的流量。在这种模式下，客户服务品质并不仅仅决定于用户直接链接的服务器，更多的决定于应用服务器间的响应时间，任何一个服务器响应时间的恶化都将降低整个服务品质。这就是数据中心必须要面临的挑战。

面对这种挑战，传统的三层及以下网络设备就无能为力了。因为这些网络设备能够保障带宽、流量控制，但是显然无法判定应用性质，甚至无法清晰的展示虚拟化环境下的基础架构逻辑，端到端的品质保障自然就成为空谈。

数据中心面临的新挑战需要一种能够识别应用，与基础架构的其他管理工具能够互动的方案。这种情况下，业务智能数据中心的解决方案就应运而生。

Radware业务智能ADC的解决方案就是其中之一。Radware业务智能解决方案不需要企业在构建数据中心时候改变现有的架构，Radware可以平滑运用到智能数据中心(ADC)建设当中。

比如这样一个例子:

假定客户ERP在一天中的需求是这样分布，在下午3点，其峰值的应用需要5台服务器而非峰值情况下只需要一台服务器;CRM的应用在上午9点是峰值，有 4台服务器为它工作，而其他时间也仅需要一台服务器。传统的解决方案是给客户总共用9台计算机来提供服务，是按照系统最高峰的需要来配备，也就是ERP5 台服务器和CRM4台服务器。但是仔细分析，在任何一个阶段，如果计算机系统足够聪明的话只需要6台设备可以满足用户高峰时期的需求，这样用户可以省下很多电费和购买设备等等额外的费用。

Radwared的解决方案是能够智能调配资源，比如CRM、ERP各一台永久的服务器，而其他四台服务器动态分配。下午3点钟针对ERP高峰时段需要5台处理需要，仅需要从动态服务器中调配4台来满足用户的需要。而在早晨 CRM需要4台服务器，则从动态服务器中调配3台为CRM服务器。

Radware能够实现这样的动态应用，是采用了这样一个结构，用Appdirector实现服务器的负载均衡，另外VirtualDirector则负责监听服务等级。如果一个应用的服务等级有所下降，VirtualDirector会通过VMware的虚拟化管理中心给这个应用分配更多的资源，同时通知Appdirector实现新的负载均衡。

在上面的ERP、CRM数据中心例子里。VirtualDirector的作用就是按照策略或者服务等级分配更多的虚拟机，而Appdirector的作用就是在不同的虚拟机之间实现动态负载均衡。

Radware的Appdirector和VirtualDirector都在一个盒子实现，就是最新的OnDemand Switch3这款产品。

对未来的数据中心而言，Radware的解决方案以及OnDemand Switch3最大的价值就是：终于有一种解决方案来检测和分析复杂应用的服务等级。这无疑是保障SLA的基础和关键。而传统基于流量的工具和解决方案，在面临新的复杂数据中心时将无能为力。

对CIO而言，当数据中心整合完毕后，面临的第一个挑战就是应用服务等级问题将无法诊断，这对CIO而言无疑将是一场恶梦。而Radware的解决方案正好就是一个可行的解决方案。

【编辑推荐】