1 概述

    電信運(yùn)營商的信令監(jiān)控系統(tǒng)是一個(gè)典型的大數(shù)據(jù)處理系統(tǒng)，目前某運(yùn)營商信令監(jiān)控系統(tǒng)的數(shù)據(jù)處理主要由三種計(jì)算能力支撐：（1）SPARC計(jì)算能力；（2）Itanium計(jì)算能力；（3）x86-64計(jì)算能力。這三種計(jì)算能力不具有互通性，前兩種屬于RISC架構(gòu)，后一種屬于CISC架構(gòu)。

    云計(jì)算技術(shù)通過對(duì)計(jì)算資源的虛擬化來對(duì)資源進(jìn)行整合，提高資源利用率和可管理性；但是對(duì)這種異構(gòu)性的計(jì)算能力進(jìn)行整合，其優(yōu)勢(shì)并不明顯。原因有二：一是現(xiàn)行云計(jì)算技術(shù)未能實(shí)現(xiàn)異構(gòu)資源的統(tǒng)一管理和調(diào)度，而且預(yù)計(jì)將來也不可能實(shí)現(xiàn)，或者實(shí)現(xiàn)的代價(jià)太大（指令集仿真）；二是以計(jì)算能力類型劃分成多個(gè)資源池，降低了資源整合的集約化優(yōu)勢(shì)（資源池越大，復(fù)用優(yōu)勢(shì)越突出）。因此，在對(duì)信令監(jiān)控系統(tǒng)的云化過程中，需要考慮異構(gòu)計(jì)算資源到同構(gòu)資源的轉(zhuǎn)化。

    那么，應(yīng)該向哪一種計(jì)算資源集中和靠攏呢？當(dāng)前，電信行業(yè)“去小型機(jī)化”的趨勢(shì)明顯。以往一直是RISC小型機(jī)唱主角，然而隨著x86處理器性能和可靠性的不斷提升，不斷有應(yīng)用遷移到x86平臺(tái)，中國電信集團(tuán)打造的三大云資源池就都采用x86服務(wù)器。因此，將三種計(jì)算能力向x86-64集中不僅是發(fā)展趨勢(shì)，而且也為云計(jì)算打下了技術(shù)基礎(chǔ)。

    表1是信令監(jiān)控的小型機(jī)現(xiàn)狀，下文將以此為基礎(chǔ)，分析RISC小型機(jī)向x86服務(wù)器遷移的硬件性能可行性。

表1 信令監(jiān)控的小型機(jī)現(xiàn)狀

2 性能可行性分析

    信令監(jiān)控系統(tǒng)以IT為支撐，其對(duì)IT能力的需求主要有三個(gè)方面：計(jì)算能力需求、存儲(chǔ)能力需求和網(wǎng)絡(luò)能力需求。本節(jié)將聚焦如何科學(xué)而又平滑地將對(duì)RISC小型機(jī)的計(jì)算能力需求轉(zhuǎn)移到x86服務(wù)器上。

    將RISC向CISC轉(zhuǎn)移，平滑性體現(xiàn)在兩方面：一方面是信息資產(chǎn)保護(hù)，原有數(shù)據(jù)得到延續(xù)，原有應(yīng)用不需重構(gòu)；另一方面是計(jì)算能力相當(dāng)，RISC服務(wù)器所承擔(dān)的負(fù)荷，CISC服務(wù)器也需具備相當(dāng)?shù)哪芰�。�?duì)于前一個(gè)方面，信令監(jiān)控系統(tǒng)中，RISC服務(wù)器主要承擔(dān)了數(shù)據(jù)庫和應(yīng)用中間件的任務(wù)，對(duì)此需要有基于CISC服務(wù)器的同類數(shù)據(jù)庫和應(yīng)用中間件來接管相應(yīng)的任務(wù)，使得數(shù)據(jù)和應(yīng)用得到平滑遷移，需要對(duì)軟件功能進(jìn)行可行性分析；對(duì)于后一個(gè)方面，需要合理評(píng)估RISC服務(wù)器和CISC服務(wù)器的計(jì)算能力，使得工作任務(wù)遷移后，不會(huì)出現(xiàn)處理能力不足或者資源浪費(fèi)的情況，需要對(duì)硬件性能進(jìn)行可行性分析。

    性能的評(píng)估需要有統(tǒng)一的基準(zhǔn)，針對(duì)信令監(jiān)控系統(tǒng)的體系架構(gòu)，可參考的測(cè)試基準(zhǔn)（Benchmarks）有：

    （1）SPEC jEntERPrise

    2010：全面系統(tǒng)化的基準(zhǔn)測(cè)試，用于J2EE5.0服務(wù)器的性能測(cè)量和表征，對(duì)由J2EE服務(wù)器和數(shù)據(jù)庫服務(wù)器構(gòu)成的應(yīng)用系統(tǒng)進(jìn)行整體測(cè)試，以每秒處理的企業(yè)Java操作數(shù)作為其測(cè)量指標(biāo)，指標(biāo)單位：EjOPS；

    （2）TPC-C：廣泛應(yīng)用的數(shù)據(jù)庫事務(wù)處理基準(zhǔn)測(cè)試，衡量服務(wù)器及數(shù)據(jù)庫OLTP性能表現(xiàn)，以每分鐘完成的TPC-C數(shù)據(jù)庫交易作為其測(cè)量指標(biāo)，指標(biāo)單位：tpmC；

    （3）SAP SD 2-Tier：衡量服務(wù)器及數(shù)據(jù)庫執(zhí)行SAP企業(yè)ERP的性能表現(xiàn)，SAP商業(yè)套件和數(shù)據(jù)庫服務(wù)器共用單臺(tái)物理服務(wù)器，以每小時(shí)可處理的完全業(yè)務(wù)訂單作為其測(cè)量指標(biāo)，測(cè)試結(jié)果標(biāo)準(zhǔn)化為SAPS值（100SAPS值等同于每小時(shí)2000筆完全業(yè)務(wù)訂單）。

    在上述三種基準(zhǔn)的測(cè)試結(jié)果中，信令監(jiān)控系統(tǒng)所用到的SUN M5000、SUN T5440、HP rx8640等RISC服務(wù)器均能找到相同、類似或者可換算的衡量指標(biāo)，而且通過該衡量指標(biāo)，可以找到與其相對(duì)應(yīng)的x86-64服務(wù)器，從而建立RISC服務(wù)器與CISC服務(wù)器之間的性能換算關(guān)系。

    2.1 以SPEC jEntERPrise2010為基準(zhǔn)分析SPARC和x86-64的性能

    SPEC jEnterprise2010測(cè)試數(shù)據(jù)主要由IBM和Oracle提供。IBM只提供基于自己的WebSphere中間件產(chǎn)品、DB2數(shù)據(jù)庫產(chǎn)品以及硬件產(chǎn)品的測(cè)試數(shù)據(jù)，如果要衡量PowerPC64與x86-64之間的關(guān)系，其數(shù)據(jù)可以參考；Oracle提供基于自己的Weblogic中間件產(chǎn)品、Oracle數(shù)據(jù)庫產(chǎn)品以及第三方硬件產(chǎn)品的測(cè)試數(shù)據(jù)，由于其測(cè)試范圍包括了SPARC和x86-64架構(gòu)，所以O(shè)racle的測(cè)試數(shù)據(jù)將作為本文的參考，但I(xiàn)tanium架構(gòu)沒有測(cè)試數(shù)據(jù)，需要從其他基準(zhǔn)中去發(fā)掘。測(cè)試項(xiàng)如表2所列：

表2 測(cè)試項(xiàng)1

    在SPEC jEnterprise2010中，Oracle并沒有對(duì)基于SPARC64 VII（Fujitsu生產(chǎn)，側(cè)重高可靠性）和UltraSPARC T2+（Sun Microsystems，側(cè)重高吞吐量）的服務(wù)器進(jìn)行測(cè)試，不過測(cè)試中有基于SPARC T3的服務(wù)器；而且從廠家提供的技術(shù)細(xì)節(jié)來看，SPARC T3整合了兩個(gè)UltraSPARC T2+ CPU，所以理論上可以認(rèn)為SPARC T3與UltraSPARC T2+的單核在同頻下具有相當(dāng)?shù)男阅�，至于SPARC64 VII的性能對(duì)標(biāo)將在后文的SAP SD 2-Tier中予以分析。

    SPEC jEnterprise2010受測(cè)系統(tǒng)均是經(jīng)過調(diào)優(yōu)的，通常內(nèi)存、磁盤和網(wǎng)絡(luò)不太可能存在瓶頸，且各Java業(yè)務(wù)操作之間是一種并發(fā)關(guān)系。在三層體系架構(gòu)中（前端-客戶端、中間件、后端-數(shù)據(jù)庫），中間件和數(shù)據(jù)庫在業(yè)務(wù)流水線上是上下游關(guān)系；而且從實(shí)際運(yùn)行數(shù)據(jù)和受測(cè)系統(tǒng)的配置來判斷，中間件服務(wù)器通常容易成為性能瓶頸。因此在一定業(yè)務(wù)量規(guī)模范圍內(nèi)，可以近似地認(rèn)為EjOPS值與應(yīng)用服務(wù)器的CPU總核數(shù)和CPU頻率之間是一種線性關(guān)系：

    EjOPS=a*應(yīng)用服務(wù)器的CPU總核數(shù)*CPU頻率 （1）

    通過式（1）對(duì)表2進(jìn)行計(jì)算并擴(kuò)展，如表3：

表3 擴(kuò)展后的測(cè)試項(xiàng)1

    從針對(duì)不同a值的計(jì)算結(jié)果來看，Xeon 32nm架構(gòu)的單核·GHz性能在120～140EjOPS，這也說明了線性關(guān)系推論有其合理性；而實(shí)際上，a代表CPU架構(gòu)的效率，值越大效率越高。

    經(jīng)過上述對(duì)SPEC jEnterprise2010結(jié)果的分析，可以推斷出UltraSPARC T2+與x86-64（Xeon 32nm）的服務(wù)器在該類應(yīng)用場景的單核·GHz性能比大約為3：4。

    在中間件應(yīng)用場景中，對(duì)應(yīng)到信令監(jiān)控系統(tǒng)中的服務(wù)器具體配置，1個(gè)UltraSPARC T2+（8核、1.6GHz）CPU性能，等同于同頻率的Xeon 32nm的6核。

    2.2 以TPC-C為基準(zhǔn)分析Itanium、 SPARC和x86-64的性能

    TPC-C的基準(zhǔn)測(cè)試主要針對(duì)數(shù)據(jù)庫軟件和服務(wù)器硬件，它對(duì)服務(wù)器硬件測(cè)試的重心主要放在CPU上，服務(wù)器的內(nèi)存、網(wǎng)絡(luò)和存儲(chǔ)通常都是超量配置。例如：近年來，TPC-C受測(cè)服務(wù)器的CPU核與內(nèi)存之比通常為1：32以上。因此，可以認(rèn)為測(cè)試結(jié)果主要代表了CPU的性能。這也可以從TPC-C發(fā)布的測(cè)試數(shù)據(jù)項(xiàng)中看出——其測(cè)試結(jié)果表中將CPU類型和CPU核數(shù)量作為關(guān)聯(lián)字段，而內(nèi)存、網(wǎng)絡(luò)和存儲(chǔ)配置均僅在測(cè)試總結(jié)文檔中說明。

    通過上面的分析，可以近似地認(rèn)為tpmC值與數(shù)據(jù)庫服務(wù)器的CPU總核數(shù)和CPU頻率之間是一種線性關(guān)系：

    目前，TPC-C測(cè)試結(jié)果表中保留了從2000年開始的數(shù)據(jù)，約有273項(xiàng)，從這之中篩選出與信令監(jiān)控系統(tǒng)的硬件相關(guān)，并且盡量與上述SPEC jEnterprise2010所列出的硬件保持一致，從而有表4所列的測(cè)試項(xiàng)可供參考

表4 測(cè)試項(xiàng)2

    通過式（2）對(duì)表4進(jìn)行計(jì)算并擴(kuò)展，得到表5：

表5 測(cè)試項(xiàng)2

    從針對(duì)不同a值的計(jì)算結(jié)果來看，Xeon 32nm架構(gòu)的單核·GHz性能為2.2～2.6萬tpmC，這也說明了線性關(guān)系的推論基本合理；同樣a代表CPU架構(gòu)的效率，值越大效率越高。

    從上面的分析中，不難推斷出Itanium 9150M與x86-64（Xeon 32nm）的服務(wù)器在數(shù)據(jù)庫場景的單核·GHz性能大致相當(dāng)，SPARC T3與UltraSPARC T2+的服務(wù)器的單核·GHz性能相差不大，也驗(yàn)證了前面關(guān)于技術(shù)架構(gòu)的推斷，此類SPARC性能大約是前面二者CPU架構(gòu)的1/2。

    在數(shù)據(jù)庫應(yīng)用場景中，對(duì)應(yīng)到信令監(jiān)控系統(tǒng)中的服務(wù)器具體配置，Itanium 9140N（2cores，18M Cache，1.6GHz）與Itanium 9150M（2cores，24M Cache，1.66GHz）相比性能稍弱，其性能大致等同于同頻率的Xeon 32nm的雙核；1個(gè)UltraSPARC T2+（8核、1.6GHz）CPU性能，等同于同頻率的Xeon 32nm的四核。

    2.3 以SAP SD 2-Tier為基準(zhǔn)分析SPARC

    由于SAP SD 2-Tier的測(cè)試結(jié)果時(shí)間跨度長（從1995年至今），被測(cè)數(shù)據(jù)庫涉及不同類型和不同版本，而且所用SAP商業(yè)套件也有多個(gè)版本（對(duì)比分析考慮的主要因素），被測(cè)CPU還要覆蓋Itanium、SPARC和x86-64三種架構(gòu)，要找到這樣的測(cè)試項(xiàng)實(shí)屬不易；因此退而求其次，只要求覆蓋SPARC和x86-64兩種架構(gòu)，可以從700條測(cè)試項(xiàng)中篩選出表6所列數(shù)據(jù)。

    在此，仍沿用SAPS值與CPU核數(shù)、CPU頻率以及代表CPU架構(gòu)效率的a的線性關(guān)系：

    推算得到表7。從表7中可以清晰地看到，前面需要找的SPARC64 VII與UltraSPARC T2+之間的單位核·G性能關(guān)系，大約為1：2。這也可以從這兩種CPU的技術(shù)規(guī)格上來印證——雖然均是SPARC v9架構(gòu)的65nm，但SPARC64 VII側(cè)重高可靠性，4核8線程，UltraSPARC T2+側(cè)重高吞吐量，8核64線程，SPARC64 VII通過犧牲性能（關(guān)鍵是線程的減少）來保障其高可靠性。

表6 測(cè)試項(xiàng)3

表7 測(cè)試項(xiàng)7

    為保持與前兩類分析的一致性，需要將Xeon X5570這種45nm的CPU性能映射到Xeon 32nm的CPU。根據(jù)本文之外的數(shù)據(jù)分析，Xeon E5-2690相比Xeon X5570在單位核·G性能方面有約20%的增加；因此可以推算到UltraSPARC T2+的單核·GHz性能是Xeon 32nm的1/2，SPARC64 VII的單核·GHz性能則是Xeon 32nm的1/4。

    在SAP的應(yīng)用+數(shù)據(jù)庫一體化應(yīng)用場景中，對(duì)應(yīng)到信令監(jiān)控系統(tǒng)中的服務(wù)器具體配置，SPARC64 VII（4核、2.4GHz）性能大致等同于同頻率的Xeon 32nm的單核；1個(gè)UltraSPARC T2+（8核、1.6GHz）CPU性能，等同于同頻率的Xeon 32nm的四核，這一結(jié)論與TPC-C的分析結(jié)果是一致的。

表8 現(xiàn)有RIsc小型機(jī)與其對(duì)標(biāo)x86-64服務(wù)器的配置

3 結(jié)論

    根據(jù)上文的硬件性能可行性分析，為信令監(jiān)控系統(tǒng)中的各RISC小型機(jī)配置對(duì)應(yīng)的x86-64服務(wù)器，具體結(jié)果見表8。

    表中對(duì)x86-64服務(wù)器的配置進(jìn)行了拉齊，一方面在于構(gòu)成云計(jì)算計(jì)算資源池的無差別能力供應(yīng)節(jié)點(diǎn)；另一方面其富余能力作為云計(jì)算高可用性的資源保障，不僅滿足信令監(jiān)控系統(tǒng)的性能要求，也滿足其可靠性要求。

    本文從多方面來論證RISC小型機(jī)與x86-64服務(wù)器之間的性能對(duì)應(yīng)關(guān)系，發(fā)現(xiàn)當(dāng)前主流配置的x86-64服務(wù)器完全能夠勝任信令監(jiān)控系統(tǒng)中RISC小型機(jī)的工作任務(wù)。鑒于此，在具體實(shí)施小型機(jī)遷移工作時(shí)，還應(yīng)該搭建現(xiàn)網(wǎng)系統(tǒng)進(jìn)行POC驗(yàn)證，一方面驗(yàn)證軟件功能的可行性，另一方面驗(yàn)證硬件性能的可行性，并要有一段時(shí)期的上線試運(yùn)行。

轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標(biāo)題：小型機(jī)向云計(jì)算的過渡探討

本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/1083977539.html