小型机向云计算的过渡探讨

开篇：润墨网以专业的文秘视角，为您筛选了一篇小型机向云计算的过渡探讨范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

【摘要】文章针对电信行业“去小型机化”的趋势和信令监控系统的现状，以三种测试基准（SPEC jEnterprise2010、TPC-C和SAP SD 2-Tier）分析了RISC向CISC转移的性能可行性，并给出了现有RISC小型机与其对标x86-64服务器的配置，为涉及小型机的信息系统云化提供了一种思路。

【关键词】RISC小型机 x86-64服务器 SPEC jEnterprise2010 TPC-C SAP SD 2-Tier 云计算

1 概述

电信运营商的信令监控系统是一个典型的大数据处理系统，目前某运营商信令监控系统的数据处理主要由三种计算能力支撑：（1）SPARC计算能力；（2）Itanium计算能力；（3）x86-64计算能力。这三种计算能力不具有互通性，前两种属于RISC架构，后一种属于CISC架构。

云计算技术通过对计算资源的虚拟化来对资源进行整合，提高资源利用率和可管理性；但是对这种异构性的计算能力进行整合，其优势并不明显。原因有二：一是现行云计算技术未能实现异构资源的统一管理和调度，而且预计将来也不可能实现，或者实现的代价太大（指令集仿真）；二是以计算能力类型划分成多个资源池，降低了资源整合的集约化优势（资源池越大，复用优势越突出）。因此，在对信令监控系统的云化过程中，需要考虑异构计算资源到同构资源的转化。

那么，应该向哪一种计算资源集中和靠拢呢？当前，电信行业“去小型机化”的趋势明显[1]。以往一直是RISC小型机唱主角，然而随着x86处理器性能和可靠性的不断提升，不断有应用迁移到x86平台，中国电信集团打造的三大云资源池就都采用x86服务器。因此，将三种计算能力向x86-64集中不仅是发展趋势，而且也为云计算打下了技术基础。

表1是信令监控的小型机现状，下文将以此为基础，分析RISC小型机向x86服务器迁移的硬件性能可行性。

2 性能可行性分析

信令监控系统以IT为支撑，其对IT能力的需求主要有三个方面：计算能力需求、存储能力需求和网络能力需求。本节将聚焦如何科学而又平滑地将对RISC小型机的计算能力需求转移到x86服务器上。

将RISC向CISC转移，平滑性体现在两方面：一方面是信息资产保护，原有数据得到延续，原有应用不需重构；另一方面是计算能力相当，RISC服务器所承担的负荷，CISC服务器也需具备相当的能力。对于前一个方面，信令监控系统中，RISC服务器主要承担了数据库和应用中间件的任务，对此需要有基于CISC服务器的同类数据库和应用中间件来接管相应的任务，使得数据和应用得到平滑迁移，需要对软件功能进行可行性分析；对于后一个方面，需要合理评估RISC服务器和CISC服务器的计算能力，使得工作任务迁移后，不会出现处理能力不足或者资源浪费的情况，需要对硬件性能进行可行性分析。

性能的评估需要有统一的基准，针对信令监控系统的体系架构，可参考的测试基准（Benchmarks）[2]有：

（1）SPEC jEnterprise

2010：全面系统化的基准测试，用于J2EE5.0服务器的性能测量和表征，对由J2EE服务器和数据库服务器构成的应用系统进行整体测试，以每秒处理的企业Java操作数作为其测量指标，指标单位：EjOPS；

（2）TPC-C：广泛应用的数据库事务处理基准测试，衡量服务器及数据库OLTP性能表现，以每分钟完成的TPC-C数据库交易作为其测量指标，指标单位：tpmC；

（3）SAP SD 2-Tier：衡量服务器及数据库执行SAP企业ERP的性能表现，SAP商业套件和数据库服务器共用单台物理服务器，以每小时可处理的完全业务订单作为其测量指标，测试结果标准化为SAPS值（100SAPS值等同于每小时2000笔完全业务订单）。

在上述三种基准的测试结果中，信令监控系统所用到的SUN M5000、SUN T5440、HP rx8640等RISC服务器均能找到相同、类似或者可换算的衡量指标，而且通过该衡量指标，可以找到与其相对应的x86-64服务器，从而建立RISC服务器与CISC服务器之间的性能换算关系。

2.1 以SPEC jEnterprise2010为基准分析SPARC和

x86-64的性能

SPEC jEnterprise2010测试数据主要由IBM和Oracle提供。IBM只提供基于自己的WebSphere中间件产品、DB2数据库产品以及硬件产品的测试数据，如果要衡量PowerPC64与x86-64之间的关系，其数据可以参考；Oracle提供基于自己的Weblogic中间件产品、Oracle数据库产品以及第三方硬件产品的测试数据，由于其测试范围包括了SPARC和x86-64架构，所以Oracle的测试数据将作为本文的参考，但Itanium架构没有测试数据，需要从其他基准中去发掘。测试项如表2所列[3]：

在SPEC jEnterprise2010中，Oracle并没有对基于SPARC64 VII（Fujitsu生产，侧重高可靠性）和UltraSPARC T2+（Sun Microsystems，侧重高吞吐量）的服务器进行测试，不过测试中有基于SPARC T3的服务器；而且从厂家提供的技术细节来看，SPARC T3整合了两个UltraSPARC T2+ CPU，所以理论上可以认为SPARC T3与UltraSPARC T2+的单核在同频下具有相当的性能，至于SPARC64 VII的性能对标将在后文的SAP SD 2-Tier中予以分析。

SPEC jEnterprise2010受测系统均是经过调优的，通常内存、磁盘和网络不太可能存在瓶颈，且各Java业务操作之间是一种并发关系。在三层体系架构中（前端-客户端、中间件、后端-数据库），中间件和数据库在业务流水线上是上下游关系；而且从实际运行数据和受测系统的配置来判断，中间件服务器通常容易成为性能瓶颈。因此在一定业务量规模范围内，可以近似地认为EjOPS值与应用服务器的CPU总核数和CPU频率之间是一种线性关系：

EjOPS=a*应用服务器的CPU总核数*CPU频率 （1）

通过式（1）对表2进行计算并扩展，如表3：

从针对不同a值的计算结果来看，Xeon 32nm架构的单核·GHz性能在120～140EjOPS，这也说明了线性关系推论有其合理性；而实际上，a代表CPU架构的效率，值越大效率越高。

经过上述对SPEC jEnterprise2010结果的分析，可以推断出UltraSPARC T2+与x86-64（Xeon 32nm）的服务器在该类应用场景的单核·GHz性能比大约为3：4。

在中间件应用场景中，对应到信令监控系统中的服务器具体配置，1个UltraSPARC T2+（8核、1.6GHz）CPU性能，等同于同频率的Xeon 32nm的6核。

2.2 以TPC-C为基准分析Itanium、 SPARC和x86-64

的性能

TPC-C的基准测试主要针对数据库软件和服务器硬件，它对服务器硬件测试的重心主要放在CPU上，服务器的内存、网络和存储通常都是超量配置。例如：近年来，TPC-C受测服务器的CPU核与内存之比通常为1：32以上。因此，可以认为测试结果主要代表了CPU的性能。这也可以从TPC-C的测试数据项中看出——其测试结果表中将CPU类型和CPU核数量作为关联字段，而内存、网络和存储配置均仅在测试总结文档中说明。

通过上面的分析，可以近似地认为tpmC值与数据库服务器的CPU总核数和CPU频率之间是一种线性关系：

目前，TPC-C测试结果表中保留了从2000年开始的数据，约有273项，从这之中筛选出与信令监控系统的硬件相关，并且尽量与上述SPEC jEnterprise2010所列出的硬件保持一致，从而有表4所列的测试项可供参考[4]：

通过式（2）对表4进行计算并扩展，得到表5：

从针对不同a值的计算结果来看，Xeon 32nm架构的单核·GHz性能为2.2～2.6万tpmC，这也说明了线性关系的推论基本合理；同样a代表CPU架构的效率，值越大效率越高。

从上面的分析中，不难推断出Itanium 9150M与x86-64（Xeon 32nm）的服务器在数据库场景的单核·GHz性能大致相当，SPARC T3与UltraSPARC T2+的服务器的单核·GHz性能相差不大，也验证了前面关于技术架构的推断，此类SPARC性能大约是前面二者CPU架构的1/2。

在数据库应用场景中，对应到信令监控系统中的服务器具体配置，Itanium 9140N（2cores，18M Cache，1.6GHz）与Itanium 9150M（2cores，24M Cache，1.66GHz）相比性能稍弱，其性能大致等同于同频率的Xeon 32nm的双核；1个UltraSPARC T2+（8核、1.6GHz）CPU性能，等同于同频率的Xeon 32nm的四核。

2.3 以SAP SD 2-Tier为基准分析SPARC

由于SAP SD 2-Tier的测试结果时间跨度长（从1995年至今），被测数据库涉及不同类型和不同版本，而且所用SAP商业套件也有多个版本（对比分析考虑的主要因素），被测CPU还要覆盖Itanium、SPARC和x86-64三种架构，要找到这样的测试项实属不易；因此退而求其次，只要求覆盖SPARC和x86-64两种架构，可以从700条测试项中筛选出表6所列数据[7]。

在此，仍沿用SAPS值与CPU核数、CPU频率以及代表CPU架构效率的a的线性关系：

推算得到表7。从表7中可以清晰地看到，前面需要找的SPARC64 VII与UltraSPARC T2+之间的单位核·G性能关系，大约为1：2。这也可以从这两种CPU的技术规格上来印证——虽然均是SPARC v9架构的65nm，但SPARC64 VII侧重高可靠性，4核8线程，UltraSPARC T2+侧重高吞吐量，8核64线程，SPARC64 VII通过牺牲性能（关键是线程的减少）来保障其高可靠性。

为保持与前两类分析的一致性，需要将Xeon X5570这种45nm的CPU性能映射到Xeon 32nm的CPU。根据本文之外的数据分析[5]，Xeon E5-2690相比Xeon X5570在单位核·G性能方面有约20%的增加；因此可以推算到UltraSPARC T2+的单核·GHz性能是Xeon 32nm的1/2，SPARC64 VII的单核·GHz性能则是Xeon 32nm的1/4。

在SAP的应用+数据库一体化应用场景中，对应到信令监控系统中的服务器具体配置，SPARC64 VII（4核、2.4GHz）性能大致等同于同频率的Xeon 32nm的单核；1个UltraSPARC T2+（8核、1.6GHz）CPU性能，等同于同频率的Xeon 32nm的四核，这一结论与TPC-C的分析结果是一致的。

3 结论

根据上文的硬件性能可行性分析，为信令监控系统中的各RISC小型机配置对应的x86-64服务器，具体结果见表8。

表中对x86-64服务器的配置进行了拉齐，一方面在于构成云计算计算资源池的无差别能力供应节点；另一方面其富余能力作为云计算高可用性的资源保障，不仅满足信令监控系统的性能要求，也满足其可靠性要求。

本文从多方面来论证RISC小型机与x86-64服务器之间的性能对应关系，发现当前主流配置的x86-64服务器完全能够胜任信令监控系统中RISC小型机的工作任务。鉴于此，在具体实施小型机迁移工作时，还应该搭建现网系统进行POC验证，一方面验证软件功能的可行性，另一方面验证硬件性能的可行性，并要有一段时期的上线试运行。

参考文献：

[1] 计世资讯. 2012 Q1，“去小型机化”推动x86服务器市场快速增长[R]. 2012.

[2] Robin Webster. Choosing between an x86 or UNIX system[R].

[3] SPEC jEnterprise2010 Published Results[Z]. 2012.

[4] TPC-C Benchmark Results[Z]. 2012.

[5] SAP SD Standard Application Benchmark Results， Two-Tier Internet Configuration[Z]. 2012.