1 概述
電信運營商的信令監控系統是一個典型的大數據處理系統，目前某運營商信令監控系統的數據處理主要由三種計算能力支撐：（1）SPARC計算能力；（2）Itanium計算能力；（3）x86-64計算能力。這三種計算能力不具有互通性，前兩種屬于RISC架構，后一種屬于CISC架構。
云計算技術通過對計算資源的虛擬化來對資源進行整合，提高資源利用率和可管理性；但是對這種異構性的計算能力進行整合，其優勢并不明顯。原因有二：一是現行云計算技術未能實現異構資源的統一管理和調度，而且預計將來也不可能實現，或者實現的代價太大（指令集仿真）；二是以計算能力類型劃分成多個資源池，降低了資源整合的集約化優勢（資源池越大，復用優勢越突出）。因此，在對信令監控系統的云化過程中，需要考慮異構計算資源到同構資源的轉化。
那么，應該向哪一種計算資源集中和靠攏呢？當前，電信行業“去小型機化”的趨勢明顯。以往一直是RISC小型機唱主角，然而隨著x86處理器性能和可靠性的不斷提升，不斷有應用遷移到x86平臺，中國電信集團打造的三大云資源池就都采用x86服務器。因此，將三種計算能力向x86-64集中不僅是發展趨勢，而且也為云計算打下了技術基礎。
表1是信令監控的小型機現狀，下文將以此為基礎，分析RISC小型機向x86服務器遷移的硬件性能可行性。
表1 信令監控的小型機現狀
2 性能可行性分析
信令監控系統以IT為支撐，其對IT能力的需求主要有三個方面：計算能力需求、存儲能力需求和網絡能力需求。本節將聚焦如何科學而又平滑地將對RISC小型機的計算能力需求轉移到x86服務器上。
將RISC向CISC轉移，平滑性體現在兩方面：一方面是信息資產保護，原有數據得到延續，原有應用不需重構；另一方面是計算能力相當，RISC服務器所承擔的負荷，CISC服務器也需具備相當的能力。對于前一個方面，信令監控系統中，RISC服務器主要承擔了數據庫和應用中間件的任務，對此需要有基于CISC服務器的同類數據庫和應用中間件來接管相應的任務，使得數據和應用得到平滑遷移，需要對軟件功能進行可行性分析；對于后一個方面，需要合理評估RISC服務器和CISC服務器的計算能力，使得工作任務遷移后，不會出現處理能力不足或者資源浪費的情況，需要對硬件性能進行可行性分析。
性能的評估需要有統一的基準，針對信令監控系統的體系架構，可參考的測試基準（Benchmarks）有：
（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所列：
表2 測試項1
在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：
表3 擴展后的測試項1
從針對不同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
通過式（2）對表4進行計算并擴展，得到表5：
表5 測試項2
從針對不同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所列數據。
在此，仍沿用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通過犧牲性能（關鍵是線程的減少）來保障其高可靠性。
表6 測試項3
表7 測試項7
為保持與前兩類分析的一致性，需要將Xeon X5570這種45nm的CPU性能映射到Xeon 32nm的CPU。根據本文之外的數據分析，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的分析結果是一致的。
表8 現有RIsc小型機與其對標x86-64服務器的配置
3 結論
根據上文的硬件性能可行性分析，為信令監控系統中的各RISC小型機配置對應的x86-64服務器，具體結果見表8。
表中對x86-64服務器的配置進行了拉齊，一方面在于構成云計算計算資源池的無差別能力供應節點；另一方面其富余能力作為云計算高可用性的資源保障，不僅滿足信令監控系統的性能要求，也滿足其可靠性要求。
本文從多方面來論證RISC小型機與x86-64服務器之間的性能對應關系，發現當前主流配置的x86-64服務器完全能夠勝任信令監控系統中RISC小型機的工作任務。鑒于此，在具體實施小型機遷移工作時，還應該搭建現網系統進行POC驗證，一方面驗證軟件功能的可行性，另一方面驗證硬件性能的可行性，并要有一段時期的上線試運行。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：小型機向云計算的過渡探討
本文網址：http://www.guhuozai8.cn/html/consultation/1083977539.html
相關文章
