歷經(jīng)過5年的實(shí)踐積累，SmartX融合在數(shù)據(jù)庫?產(chǎn)環(huán)境下優(yōu)秀的性能表現(xiàn)和穩(wěn)定的?助客?更好地選型評估，我們在本?檔中匯總了SmartX融合在數(shù)據(jù)庫場景下的性能評估實(shí)踐，通過多維度的評估?法讓讀者直觀地了解SmartX融合對國產(chǎn)及?國產(chǎn)數(shù)據(jù)庫的?SmartX?撐Oracle性能測試及對 SmartX與vSAN8?持Oracle數(shù)據(jù)庫性能對 SmartX與vSAN7?持Oracle數(shù)據(jù)庫性能對 SmartX與Nutanix?撐Oracle數(shù)據(jù)庫性能對 SmartX融合信創(chuàng)?案?撐MySQL性能測 SmartX分布式存儲(chǔ)?撐OceanBase性能測 SmartX融合信創(chuàng)?案?撐達(dá)夢數(shù)據(jù)庫性能測試（開啟Boost模式 SmartX融合信創(chuàng)?案?撐GaussDB性能測 SmartX融合及分布式存儲(chǔ)?撐openGauss性能測 SmartX融合?持DB2業(yè)務(wù)系統(tǒng)的性能評 SmartX融合?撐券商?業(yè)Oracle數(shù)據(jù)庫集中交易系統(tǒng)委托場景性能評 SmartX融合?撐某基?公司OracleRAC及CC系統(tǒng)性能驗(yàn) 如何降低Oracle容災(zāi)加固資源池的總成本和復(fù)雜 SmartX?撐Oracle?前在企業(yè)核?業(yè)務(wù)中，往往會(huì)使?數(shù)套Oracle數(shù)據(jù)庫，每庫容量在?百GB到?TB性能優(yōu)化。針對以上?案，SmartXOracle配置?案?：普通混閃融合（單DB實(shí)例針對普通混閃融合進(jìn)?Oracle數(shù)據(jù)庫優(yōu)化測試，確保在同等配置情況下性能更好，滿??般?產(chǎn)Oracle數(shù)據(jù)庫建設(shè)DBVM基于OracleSwingBench2.GDBVM基于OracleSwingBench2.G在某保險(xiǎn)公司的項(xiàng)?POC測試中，??在Oracle數(shù)據(jù)庫應(yīng)?場景對SmartX融合與國內(nèi)數(shù)據(jù)庫?體機(jī)產(chǎn)品進(jìn)?了橫本次項(xiàng)?測試的背景是驗(yàn)證客?的TA注冊登記系統(tǒng)（Oracle數(shù)據(jù)庫）在SmartX融合和數(shù)據(jù)庫?體機(jī)上的跑批性根據(jù)測試結(jié)果，基于SmartX增強(qiáng)型全閃融合3個(gè)節(jié)點(diǎn)的Oracle數(shù)據(jù)庫性能，可過?體機(jī)A?案，并接近更?配置的數(shù)據(jù)庫?體機(jī)的性能表現(xiàn)，?兩個(gè)?體機(jī)?案都使?了5個(gè)節(jié)點(diǎn)（2計(jì)算節(jié)點(diǎn)+3存儲(chǔ)節(jié)點(diǎn)）。通過以上評測可以看到，SmartX基于軟件優(yōu)化并結(jié)合業(yè)內(nèi)先進(jìn)的硬件和?絡(luò)技術(shù)，可實(shí)現(xiàn)接近甚?越數(shù)據(jù)庫?體機(jī)的性能表現(xiàn)。同時(shí)，相?于數(shù)據(jù)庫?體機(jī)和物理服務(wù)器加中?端存儲(chǔ)的集成?案，SmartX融合在數(shù)據(jù)庫場景還具備各種IT運(yùn)維簡單：基于產(chǎn)品運(yùn)維?員熟悉的標(biāo)準(zhǔn)PCSmartXvSAN8Oracle 融合與vSAN8在數(shù)據(jù)庫場景下的性能對某銀???計(jì)劃將IBM?機(jī)數(shù)據(jù)庫下移?x8G平臺(tái)，因此對SmartX與VMware融合（vSAN8）承載Oracle數(shù)據(jù)庫11101TPS），提升120%；在?負(fù)載測試下，SmartX融合也具備更好的穩(wěn)定性。關(guān)于SmartX融合分布式存儲(chǔ)與vSAN8技術(shù)對?，請查看博客鏈接全?內(nèi)容合中，主機(jī)的所有資源都分配給了測試虛擬機(jī)，SmartX融合因?yàn)榭紤]多臺(tái)虛擬機(jī)運(yùn)?，僅分配部分主機(jī)資源給測試數(shù)據(jù)庫Swingbench性能測試：利?Swingbench測試?具，分別對SmartX融合與VMware融合進(jìn)?數(shù)據(jù)庫存儲(chǔ)基準(zhǔn)性能測試：利?Fio測試?具，分別測試SmartX融合與VMware融合在?、低負(fù)載情況*OracleDellEMCPowerStore3200，兩者的資源配置均為VMware融合，僅在4K隨機(jī)寫場景下IOPS和延遲表現(xiàn)略遜于VMware融合。SmartX融合表壓?測試中，在1500并發(fā)??壓?下，SmartX融合性能可達(dá)到24G31TPS，較vSAN8(11101TPS）提升120%，同時(shí)也優(yōu)于Oracle??實(shí)現(xiàn)IBM值得注意的是，?前的測試僅基于??當(dāng)前物理環(huán)境和測試環(huán)境進(jìn)?對?，采?的也是初發(fā)版本的vSANESA，經(jīng)過VMware后續(xù)版本的調(diào)校和更新，vSANESA能夠發(fā)揮更強(qiáng)的能?。SmartXvSAN7Oracle 客?希望通過測試相同數(shù)據(jù)庫在不同ITDBaas采?SwingbenchOLTP物理機(jī)在此次測試過程中性能表現(xiàn)最好，VMware融合性能表現(xiàn)?般。VMware融合環(huán)境為客?實(shí)際使?的測試環(huán)508SmartX融合架構(gòu)下的Oracle壓測性能可以達(dá)到相同配置的物理機(jī)的84%，性能差異控制在15%以內(nèi)，是可接受上述結(jié)果為客?后續(xù)DBaasSmartXNutanixOracle博客鏈接：志凌海納SmartXvs. 相較存寫緩存分離的DSF（Nutanix），SmartX分布式存儲(chǔ)ZBS數(shù)據(jù)庫的性能需求；SmartX融合在基準(zhǔn)性能測試與數(shù)據(jù)庫場景性能測試中的整體表現(xiàn)也優(yōu)于Nutanix融合，尤其是在數(shù)據(jù)庫插?測試中，在單數(shù)據(jù)卷部署Oracle時(shí)，SmartX融合性能較Nutanix融合提升G0%，?參考Nutanix最佳實(shí)踐拆分?jǐn)?shù)據(jù)卷后，單卷SmartX融合性能表現(xiàn)仍?于Nutanix融合約5%。關(guān)于SmartX與Nutanix的技術(shù)對?，即分布式存儲(chǔ)設(shè)計(jì)實(shí)現(xiàn)如何影響融合在數(shù)據(jù)庫場景下的表現(xiàn)，請查看博客鏈接在本次測試中，包含基于FIO的存儲(chǔ)性能測試和基于OracleSmartXNutanix注：根據(jù)Nutanix可以看到，SmartX融合在隨機(jī)讀寫場景下的性能遠(yuǎn)?于Nutanix融合，在順序讀和順序混合讀寫場景下的性能略低于Nutanix融合。在業(yè)務(wù)測試中，選擇OracleSmartXNutanix在數(shù)據(jù)庫導(dǎo)?導(dǎo)出場景中，使?SOE（SimpleOrderEntry）模型進(jìn)?測試，測試不同數(shù)據(jù)量的導(dǎo)?導(dǎo)出?時(shí)，耗時(shí)越短性能越優(yōu)。整體測試表明，SmartX融合單卷性能明顯優(yōu)于Nutanix融合單卷，與Nutanix-ASM最佳部署?式接近；?在導(dǎo)出測試中，SmartX融合性能表現(xiàn)明顯優(yōu)于Nutanix單卷和最佳部署?式。數(shù)據(jù)庫TPC-C在數(shù)據(jù)庫TPC-C（TransactionProcessingPerformanceCouncil）測試中，使?SwingbenchTPS（TransactionsPerSecond）越?越優(yōu)?？梢钥吹剑S著并發(fā)數(shù)量增?，兩種融合平均OPS均有明顯上升，且SmartX融合單卷性能明顯優(yōu)于Nutanix單卷部署，略優(yōu)于Nutanix-ASM最佳部署?式。30個(gè)PDC2分鐘。該測試COUNT（*）表?每秒插?的數(shù)據(jù)量，數(shù)值越?越優(yōu)。從測試結(jié)果可以看到，在80s后，Nutanix融合多次出現(xiàn)接近觸底的情況，?SmartX則呈現(xiàn)更為穩(wěn)定和均勻的得益于ZBS統(tǒng)?的緩存空間和技術(shù)優(yōu)化，SmartX融合在數(shù)據(jù)庫場景下能提供更好的性能表現(xiàn)。通過SmartX融合和Nutanix融合在FIO測試和Oracle數(shù)據(jù)庫場景測試中的性能表現(xiàn)，可以看出，SmartX融合僅需單卷部署就可以發(fā)揮最佳性能，?Nutanix融合需要配置多卷并通過系統(tǒng)或應(yīng)?的并?調(diào)度能?，才能提供近似的性能表現(xiàn)，并且SmartX融合在多數(shù)數(shù)據(jù)庫場景中性能均優(yōu)于Nutanix融合。SmartXVMware?撐MySQL博客鏈接：MySQL于融合架構(gòu)各服務(wù)模塊的均衡發(fā)展（如SmartX融合基礎(chǔ)架構(gòu)）。本?介紹證券客?通過MySQL數(shù)據(jù)庫場景驗(yàn)證SmartX融合平臺(tái)與?前正在使?的VMwarevSAN在對?測試下的性平臺(tái)1?VMwareHCI(ESXi+執(zhí)?測試階段?記錄TPS及平均可以看出，MySQL數(shù)據(jù)庫虛擬機(jī)在SmartX的兩種融合平臺(tái)上的測試結(jié)果都?VMwarevSAN平臺(tái)表現(xiàn)優(yōu)異，甚?SmartX原?虛擬化服務(wù)ELF的性能表現(xiàn)要?于ESXi虛擬化平臺(tái)。SmartX融合平臺(tái)所承載的MySQL數(shù)據(jù)庫虛擬機(jī)，其TPS及時(shí)延的性能表現(xiàn)優(yōu)于現(xiàn)有?案的VMwarevSAN20%。SmartX融合的原?虛擬化服務(wù)ELF在此場景下的計(jì)算性能相?VMwareESXi虛擬化平臺(tái)表現(xiàn)更優(yōu)測試結(jié)果顯?，SmartX融合基于?穩(wěn)定的分布式存儲(chǔ)架構(gòu)，能提供?撐MySQL數(shù)據(jù)庫系統(tǒng)良好穩(wěn)定運(yùn)?所需要的?性能、?融企業(yè)級的IT以上測試僅驗(yàn)證了SmartX融合架構(gòu)?撐數(shù)據(jù)庫系統(tǒng)的性能優(yōu)勢，SmartX融合?案還會(huì)為核?業(yè)務(wù)的基礎(chǔ)架構(gòu)帶SmartX融合架構(gòu)具有簡單、易操作的橫向擴(kuò)容能?，在擴(kuò)展容量及計(jì)算資源的同時(shí)也得到近乎線性的性能提對于絕?多數(shù)?融客?，SmartX融合的開放性，使其分布式存儲(chǔ)可以搭配多種計(jì)算虛擬化產(chǎn)品組成融合基礎(chǔ)架構(gòu)，能有效整合各類IT系統(tǒng)的計(jì)算和存儲(chǔ)資源，進(jìn)?步降低IT架構(gòu)復(fù)雜度和投?成本?；谲浖x模式的SmartX融合基礎(chǔ)架構(gòu)可以快速引?先進(jìn)的硬件技術(shù)，從?快速提升系統(tǒng)能?。例如，SmartX針對核?業(yè)務(wù)系統(tǒng)最關(guān)注的可靠性問題，?前SmartX隨著“?主可控”在IT格的?融機(jī)構(gòu)，已逐步將?產(chǎn)應(yīng)?系統(tǒng)遷移?國產(chǎn)數(shù)據(jù)庫平臺(tái)。不過，不少??也對國產(chǎn)數(shù)據(jù)庫的性能及其與IT作為多年深耕IT基礎(chǔ)設(shè)施信創(chuàng)?態(tài)的專業(yè)融合?商，志凌海納SmartX已與多家國產(chǎn)數(shù)據(jù)庫?商進(jìn)?了深度適配，數(shù)據(jù)庫系統(tǒng)，并協(xié)助企業(yè)??基于?產(chǎn)環(huán)境進(jìn)?國產(chǎn)數(shù)據(jù)庫性能評測與調(diào)優(yōu)。以下，我們將分享SmartXMySQL數(shù)據(jù)庫以及G例SmartX融合?持國產(chǎn)數(shù)據(jù)庫（達(dá)夢、openGauss、???倉、OceanBase、云和恩墨根據(jù)客?需求，驗(yàn)證基于SmartX原?虛擬化ELFMySQL通過SysbenchOLTP1G1基于SmartX融合，MySQL在Kunpeng與Intel芯?架構(gòu)下的性能表現(xiàn)（單位基于SmartX融合，MySQL在Hygon與Intel芯?架構(gòu)下的性能表現(xiàn)（單位基于相同的SmartX融合虛擬化平臺(tái)，數(shù)據(jù)庫在國產(chǎn)國芯服務(wù)器上的性能表現(xiàn)良好；基于不同國產(chǎn)芯?的SmartXSmartXOceanBase等特性，在?融、電商等?業(yè)得到了?泛應(yīng)?。OceanBaseOceanBase鑒于很多??都很關(guān)?國產(chǎn)數(shù)據(jù)庫的真實(shí)性能與調(diào)優(yōu)?案，以下，我們以SmartX?研分布式存儲(chǔ)SMTXZBSOceanBase我們以SMTXZBS作為OceanBase通過獨(dú)?部署的BenchmarkSQL壓?測試?具，基于TPC-C測試模型壓測OceanBase數(shù)據(jù)庫，并以tpmC測試對象：1節(jié)點(diǎn)OB3節(jié)點(diǎn)OB測試?標(biāo)：對?兩組測試對象的TPC-COB節(jié)點(diǎn)數(shù)?例，驗(yàn)證SMTXZBSOB從上述圖表得知，所有測試場景下（多組不同規(guī)模、不同并發(fā)壓?）測試結(jié)果基本?致：31點(diǎn)數(shù)之?為3:1，兩者理論tpmC值?例應(yīng)接近3:1（實(shí)際會(huì)有損耗）；各個(gè)場景中，兩者tpmC值的?例都維持在2.G5:1SMTXZBS作為OceanBase的存儲(chǔ)卷不會(huì)削弱OB133節(jié)點(diǎn)OB（SMTXZBS2）測試?標(biāo)：對?兩組測試對象的TPC-CSMTXZBS2副本疊加OceanBase3絕?部分場景下，3副本OB集群tpmC130因此，使?SMTXZBS（2）疊加OceanBase3OceanBase1副本的性能是接近的。為了進(jìn)?步驗(yàn)證SMTXZBS?持OceanBase的性能，我們參考了?融信息化研究所與華為聯(lián)合發(fā)布的《基于OceanStorDoradoOceanBase中相近配置?案下以Dorado5G00OceanBase存儲(chǔ)的TPC-C性能數(shù)據(jù)，并基于該數(shù)據(jù)與SMTXZBS實(shí)測性能數(shù)據(jù)進(jìn)?對?，供讀者參考。DoradoSMTXZBS服務(wù)器CPU型號不?致：其中Dorado對應(yīng)的服務(wù)器CPU32，?SMTXZBS對應(yīng)的服務(wù)器CPU482.GGHz。因此，Dorado的CPU核?數(shù)約為SMTXZBS的G7服務(wù)器CPU型號、架構(gòu)均不?致：其中Dorado對應(yīng)的服務(wù)器CPU核數(shù)是32，?SMTXZBS對應(yīng)的服務(wù)器CPU核數(shù)為20核（?持線程），兩者的主頻分別2.GGHz和2.1GHz，?且兩者CPU架構(gòu)也不?樣，因此兩者?法直接?較性能。但?般情況下，壓?測試機(jī)對CPU考慮到兩組性能測試中的數(shù)據(jù)庫服務(wù)器硬件存在差異，其中Dorado的CPU核?數(shù)是SMTXZBS的G7%，與上述?較?），使?SMTXZBSOceanBase博客鏈接：性能接近翻倍！利?Boost技術(shù)優(yōu)化 基于以上需求，SmartX?案中?圍繞信創(chuàng)數(shù)據(jù)庫產(chǎn)品（達(dá)夢DM8）在SmartX融合信創(chuàng)平臺(tái)（基于鯤鵬芯?的信創(chuàng)服務(wù)器）上進(jìn)?性能測試，并利?獨(dú)有的Boost測試結(jié)果表明，結(jié)合數(shù)據(jù)庫的參數(shù)調(diào)整，Boost模式下SmartX融合信創(chuàng)平臺(tái)?撐的達(dá)夢數(shù)據(jù)庫獲得了接近100%的性能提升。本次測試使?BenchmarkSQL基于TPC-C基準(zhǔn)執(zhí)?測試，對?達(dá)夢DM8（分別基于SATASSD和NVMeSSD）、未進(jìn)?Boost模式優(yōu)化的SmartX融合信創(chuàng)平臺(tái)和優(yōu)化后的融合平臺(tái)上的性BoostBIOSBoost模式和RDMA（包括開啟CPU獨(dú)占功能和調(diào)節(jié)虛擬磁盤存儲(chǔ)策略為厚置備）、虛擬機(jī)操作系統(tǒng)參數(shù)優(yōu)化（利?CPU多核特性進(jìn)??在未做優(yōu)化時(shí)，基于信創(chuàng)架構(gòu)的SmartX融合運(yùn)?達(dá)夢數(shù)據(jù)庫性能是裸?屬服務(wù)器（基于SATASSD）的。?通過Boost（以SATASSD）1.77倍，NVMe裸盤的88%。據(jù)庫。DM8320CPU，是?前業(yè)界領(lǐng)先的ARM-based7nmARM3205250CPU（cores）?較多，單路CPU482路CPU3G（常?的Intel?強(qiáng)系列CPU單路?多在20核左右）。因此，后期性能優(yōu)化的其中?個(gè)重點(diǎn)是如何更好利?多核的優(yōu)勢。Boost模式是SMTXOSI/OI/O訪問延遲。Boost模式通常會(huì)搭配RDMA?絡(luò)?起啟?，可最?化提升存儲(chǔ)性能。本次測試使?BenchmarkSQL基于TPC-CDM8（分別基于SATASSD和NVMeSSD）、未進(jìn)?Boost模式優(yōu)化的SmartX融合信創(chuàng)平臺(tái)和優(yōu)化后的融合平臺(tái)上的性能。TPC-CTransactionProcessingPerformanceCouncil（TPC）發(fā)布的標(biāo)準(zhǔn)基準(zhǔn)測試之?，?于測試在線事務(wù)處理（OLTP）系統(tǒng)的性能。TPC-CBenchmarkSQL是?款可以使?TPC-CBenchmarkSQL可以使?TPC-C測試規(guī)范中定義的事務(wù)操作和數(shù)據(jù)結(jié)構(gòu)，來模擬?個(gè)TPC-CBenchmarkSQL可以被認(rèn)為是TPC-C測試的?種實(shí)現(xiàn)?式。本次測試使?BenchmarkSQL基于TPC-C基準(zhǔn)執(zhí)?測試，以便更客觀地評價(jià)融合信創(chuàng)平臺(tái)上數(shù)據(jù)庫的性能表現(xiàn)。??以往或許有了解過?些數(shù)據(jù)庫的TPC-C測試數(shù)據(jù)，但這些數(shù)據(jù)?多基于x8G架構(gòu)服務(wù)器環(huán)境，對于信創(chuàng)芯?的（物理機(jī)部署），然后執(zhí)??組TPC-C測試作為參照，以便與后續(xù)SmartX融合的表現(xiàn)進(jìn)?對?由于數(shù)據(jù)庫對磁盤I/O性能?較敏，在測試場景中，我們使?了兩款不同類型的SSD作為存儲(chǔ)介質(zhì)，分別進(jìn)?測試?先，通過FIO測試?具對SSD分別執(zhí)?I/O（8k），作為兩款SSD的I/O然后，我們在兩種SSDTPC-C（100warehouse，200terminals測試中取不完全是等?關(guān)系（其中NVMeSSD的I/O寫?能?相?SATASSD340%，然?TPC-C102%）。AnumactlCPU2個(gè)NUMA（48）BCPU，利?服務(wù)器上所有CPU（3G）。測試結(jié)果有點(diǎn)出乎所料：A（48）要?B組（3G）的性能更好。?般情況下，更多的CPU達(dá)夢數(shù)據(jù)庫的?作線程參數(shù)最??持G4（官?要求?作線程與CPU），3GCPU考慮到數(shù)據(jù)庫的特點(diǎn)以及NUMA的影響，后續(xù)融合平臺(tái)測試中的虛擬機(jī)配置采取48vCPU（并確保在同?個(gè)CPU調(diào)整terminal1008008組terminals調(diào)整warehouses1003003warehouse測試。每組warehouse結(jié)合上述不同的terminal數(shù)量，共執(zhí)?24組測試。測試?：未做任何優(yōu)化的SmartX融合運(yùn)?達(dá)夢數(shù)據(jù)庫性能表TPC-CNewOrder100warehouse300terminalt05t2筆新訂單（NewOrder）。在沒有任何優(yōu)化的情況下，數(shù)據(jù)庫表現(xiàn)并不算理想，是裸?屬服務(wù)器（基于SATASSD）部署性能的80%。測試?：經(jīng)過Boost模式調(diào)優(yōu)的SmartX融合運(yùn)?達(dá)夢數(shù)據(jù)庫性能表下?將展?在SMTXOSBoostTPC-C1）BIOS開啟Boost模式之前，要求在服務(wù)器BIOS啟?BoostRDMA在部署SMTXOS1啟?Boost在部署SMTXOS5啟?開啟CPU創(chuàng)建數(shù)據(jù)庫虛擬機(jī)時(shí)，勾選CPUvCPU進(jìn)?NUMA將數(shù)據(jù)庫所在的虛擬磁盤從默認(rèn)的精簡制備設(shè)置為厚置備，將?幅度提升I/O性能，同時(shí)降低CPU利?CPU由于TPC-C測試是通過SMTXOS集群外部的benchmarkSQLBoostCPUCPU?式?：為?卡隊(duì)列指定CPU/分別為多組?卡隊(duì)列指定CPUecho1>/sys/class/net/enp1s0/queues/rx-0/rps_cpusecho2>/sys/class/net/enp1s0/queues/rx-1/rps_cpusecho4>/sys/class/net/enp1s0/queues/rx-2/rps_cpusecho8>/sys/class/net/enp1s0/queues/rx-3/rps_cpusecho32>/sys/class/net/enp1s0/queues/tx-1/xps_cpus其中echo1sys/class/net/enp1s0/queues/rx-0/rps_cpus代表將CPU1綁定到rx-0CPU0、1、2、3四個(gè)CPU對應(yīng)的值分別是1（20）、2（21）、4（22）、8（23）。?式?：為?卡中斷指定CPU修改配置?件，使得irqbalance??為每個(gè)?卡中斷分配CPU執(zhí)?上述兩個(gè)部分的?絡(luò)優(yōu)化，可以明顯提升TPC-C測試中的?絡(luò)性能，其中發(fā)送速度的峰值最?提升17.4%，接收27.1%。達(dá)夢DM8（log?les）2個(gè)。由于SMTXOS開啟Boost模式后，獲得更強(qiáng)的I/O28?提升MEMORY_POOL=30000 #MemoryPoolSizeInMegabyteMEMORY_TARGET=30000 其中NORMAL緩沖區(qū)對應(yīng)的BUFFER（30）。在本次測試中調(diào)整BUFFER緩沖區(qū)??為70GB，BUFFER_POOLS數(shù)量為48（保持與CPU核數(shù)?致）。BUFFER=70000 BUFFER_POOLS=48 #numberofbu?erpools此外，RECYCLERECYCLE12GB，RECYCLE_POOLS數(shù)量為48（保持與CPU核數(shù)?致）。RECYCLE=12000 RECYCLE_POOLS=48 #Numberofrecyclebu?erpools最后需要根據(jù)CPU48（保持與CPU）WORKER_THREADS=48 注：修改dm.inissh登陸SMTXOS（數(shù)據(jù)庫虛擬機(jī)所在節(jié)點(diǎn)），執(zhí)?sudovirshlist查看虛擬機(jī)的ID根據(jù)虛擬機(jī)ID執(zhí)?sudovirshvcpuinfo1，查看vCPU核與物理CPU核的對應(yīng)關(guān)系。通過numactl命令啟動(dòng)數(shù)據(jù)庫，實(shí)現(xiàn)綁定NUMA?的：完成上述所有優(yōu)化操作后，重新執(zhí)?TPC-CSMTXOSBoost模式優(yōu)化后性能?幅提升通過開啟SMTXOSBoost數(shù)據(jù)庫性能在每個(gè)測試場景下的提升都是?常明顯的，?乎通過Boost模式以及相關(guān)優(yōu)化，在SmartX融合信創(chuàng)平臺(tái)上運(yùn)?達(dá)夢數(shù)據(jù)庫可獲得以下收益到NVMe裸盤性能的87.4%。SMTXOSCPU50，意味著剩下的資源可以運(yùn)?更多的業(yè)務(wù)，有效半配：數(shù)據(jù)庫使?單臺(tái)服務(wù)器部分CPU48CPU，9GG本次測試不僅為讀者展?了信創(chuàng)數(shù)據(jù)庫在融合信創(chuàng)平臺(tái)上的真實(shí)表現(xiàn)，也驗(yàn)證了SmartX融合Boost模式對數(shù)據(jù)庫從測試結(jié)果上看，SmartX融合平臺(tái)憑借杰出的I/O性能及相關(guān)針對性優(yōu)化，可明顯提升達(dá)夢數(shù)據(jù)庫TPC-C性能測試表現(xiàn)。由于上述測試模型是基于模擬?產(chǎn)場景，數(shù)據(jù)庫的參數(shù)是注重I/O（寫?存儲(chǔ)介質(zhì)）。?家可能會(huì)有?個(gè)疑問：是否能通過內(nèi)存緩存，以不落盤的?式進(jìn)?步提升數(shù)據(jù)庫TPC-C測試，結(jié)果如下：新的技術(shù)路徑。作為國內(nèi)專業(yè)的融合?商，SmartX融合（SMTXOS）以?研分布式存儲(chǔ)為核?，兼具輕量解耦、通過測試探索基于SmartX融合架構(gòu)部署GaussDB的性能表現(xiàn)，及其性能優(yōu)化?案。資源分配評估：評估通過調(diào)整虛擬機(jī)資源分配（如CPU、內(nèi)存、存儲(chǔ)配置）和數(shù)據(jù)庫參數(shù)設(shè)置對分布式數(shù)據(jù)庫國產(chǎn)化硬件適配性驗(yàn)證：分別在鯤鵬和海光CPU本次測試采?了標(biāo)準(zhǔn)的TPC-C測試模型，模擬?融?業(yè)中?并發(fā)事務(wù)處理的需求，對?測試GaussDB在SmartX境）是基于單實(shí)例外，其它各項(xiàng)測試均使?“?主兩從”的集群模式進(jìn)?部署。海光服務(wù)器單節(jié)點(diǎn)共G4（128vCPU），3G均啟?了vhostI/ORDMARDMA，以通過動(dòng)態(tài)調(diào)整虛擬機(jī)資源配置（如CPUI/O）以及數(shù)據(jù)庫參數(shù)（如wal_bu?ers、shared_bu?ers），評估不同資源分配與調(diào)優(yōu)措施對性能的提升效果。進(jìn)?步優(yōu)化虛擬化開銷，引?SR-IOV、RDMA和vhost等SmartX融合虛擬化優(yōu)化技術(shù)，評估?絡(luò)性能提升測試過程中，所有性能數(shù)據(jù)均通過SmartX融合內(nèi)置的監(jiān)控?具和BenchmarkSQL?具實(shí)時(shí)采集。測試以事務(wù)吞吐在GaussDBshared_bu?ers1GB，max_process_memory32vCPU、128GBshared_bu?ers1GB45GB前（43470tpmC）提?了約310%。，測試中使?了不同的CPU超融合海光環(huán)境：在單實(shí)例部署、基于相同的內(nèi)存優(yōu)化配置并使?VIRTIO500G4vCPU超融合鯤鵬環(huán)境：在?主兩從部署、基于相同的內(nèi)存優(yōu)化配置并使?VIRTIO500G2vCPUGaussDB性能（3387G4tpmC）相?使?VIRTIO（271523tpmC）25%。測試進(jìn)?步對?了GaussDB在融合虛擬化與裸?屬環(huán)境中的性能表現(xiàn)。在虛擬化環(huán)境中，虛擬機(jī)分配了最?資源，以確保最佳性能；在裸?屬環(huán)境中，GaussDB采?相同的數(shù)據(jù)庫配置參數(shù)。測試結(jié)果顯?，在虛擬化環(huán)境中，使?VIRTIO?絡(luò)和SR-IOV?絡(luò)時(shí)，融合虛擬化平臺(tái)的吞吐量相較于裸?屬環(huán)境均存在?定差距，不過SR-IOV使?VIRTIO?絡(luò)：海光環(huán)境中，融合?持GaussDB的吞吐量平均約為物理機(jī)環(huán)境的70%SmartX融合基礎(chǔ)設(shè)施通過融合部署的形式，提供分布式存儲(chǔ)、計(jì)算虛擬化、?絡(luò)、數(shù)據(jù)保護(hù)、運(yùn)維管理等全棧基礎(chǔ)設(shè)施服務(wù)。通過啟?SmartX融合?級特性，如vhost、RDMA功能、SR-IOV特性、常駐緩存功能等，SmartX融合可顯著提升虛擬機(jī)性能、降低?絡(luò)延遲、加速存儲(chǔ)讀寫能?，為GaussDB靠、易擴(kuò)容的基礎(chǔ)架構(gòu)?持。同時(shí)，SmartX融合能為國產(chǎn)數(shù)據(jù)庫提供靈活合理的資源分配策略，僅使?物理機(jī)四分博客鏈接：SmartXopenGauss北京志凌海納科技有限公司（以下簡稱“SmartX”）攜?openGauss社區(qū)完成了openGauss數(shù)據(jù)庫基于SmartX融合平臺(tái)（SMTXOS）和SmartX分布式存儲(chǔ)平臺(tái)（SMTXZBS）的性能測試和調(diào)優(yōu)。為幫助??更好的了解openGauss數(shù)據(jù)庫在信創(chuàng)硬件平臺(tái)及SmartX軟件平臺(tái)上的運(yùn)?表現(xiàn)，SmartX攜?openGauss社區(qū)圍繞openGauss-5.1.0企業(yè)版在SmartX融合信創(chuàng)平臺(tái)和SmartX分布式存儲(chǔ)信創(chuàng)平臺(tái)（基于鯤鵬本次測試使?BenchmarkSQL基于TPC-CopenGauss數(shù)據(jù)庫在SmartXTPC-CTransactionProcessingPerformanceCouncil（TPC）發(fā)布的標(biāo)準(zhǔn)基準(zhǔn)測試之?，?于測試在線事務(wù)處理（OLTP）系統(tǒng)的性能。TPC-C，它包括了?系列的事務(wù)操作，如客?訂單、庫存管理、交付處理等。TPC-CTPM)”BenchmarkSQL是?款可以使?TPC-CBenchmarkSQL可以使?TPC-C測試規(guī)范中定義的事務(wù)操作和數(shù)據(jù)結(jié)構(gòu)，來模擬?個(gè)TPC-CBenchmarkSQL可以被認(rèn)為是TPC-C測試的?種實(shí)現(xiàn)?式。*融合測試場景中，需要留部分CPU和內(nèi)存資源給SMTXOS作為開銷。因此，openGauss數(shù)據(jù)庫?法獨(dú)占物理機(jī)1：openGauss數(shù)據(jù)庫和BenchmarkSQL（并運(yùn)?在不同物理服務(wù)器節(jié)點(diǎn)），BenchmarkSQL虛擬機(jī)的訪問請求通過?絡(luò)發(fā)送到openGauss數(shù)據(jù)庫虛擬機(jī)進(jìn)?處理。部署架構(gòu)2：openGauss數(shù)據(jù)庫和BenchmarkSQL部署在同?虛擬機(jī)之內(nèi)（openGauss所在虛擬機(jī)），BenchmarkSQLopenGauss1：（測試結(jié)果為Neworder2：（測試結(jié)果為NeworderBIOS（CPU）開啟boost（降低IO開啟vCPU（不共享利?多個(gè)虛擬卷分開存放表空間以及?志?件（提升IO）關(guān)閉為數(shù)據(jù)庫進(jìn)程綁定numa調(diào)整redolog開啟/關(guān)閉異步BenchmarkSQLBenchmarkSQL當(dāng)BenchmarkSQL在數(shù)據(jù)庫啟?異步?志后，性能有較?提升（50），經(jīng)后臺(tái)監(jiān)控查看，初步判斷IO由于觀察到同步?志下，其性能會(huì)受到IOIO調(diào)整宿主機(jī)pro?le使?iSCSI1：openGaussiSCSISMTXZBS（最通?）的協(xié)議，由于iSCSIIOopenGauss數(shù)據(jù)庫服務(wù)器通過NVMe-oF協(xié)議接?存儲(chǔ)可有效降低IO延時(shí)。在SMTXZBS分離部署場景下沿?了前?章節(jié)SMTXOS融合場景的調(diào)優(yōu)?段，并額外增加了索引的優(yōu)化，性能測試25其中，BenchmarkSQLopenGaussSSD73%，最?值能達(dá)到裸?屬服務(wù)器+本地NVMeSSD110%。本次測試為雙???展?了openGauss數(shù)據(jù)庫在SmartX在某?融??針對SmartX融合（搭配鯤鵬CPU架構(gòu)服務(wù)器）承載???倉數(shù)據(jù)庫的基準(zhǔn)性能測試中（170kTpmc，?物理機(jī)（128C2.GGHzSASSSD做raid10）210kTpmc，SmartX融合信創(chuàng)集群的性能可以達(dá)到相同配置的物理機(jī)的80%。請聯(lián)系SmartX我們針對SmartX融合信創(chuàng)平臺(tái)（海光）承載MogDB的性能進(jìn)?了調(diào)優(yōu)測試，并與同樣配置的物理服務(wù)器環(huán)境進(jìn)?融合集群通過單?節(jié)點(diǎn)部署多個(gè)MogDB試中性能表現(xiàn)與物理機(jī)部署?常接近，可良好?持MogDB請聯(lián)系SmartX 以下測試通過模擬實(shí)際業(yè)務(wù)場景，驗(yàn)證SmartX融合對數(shù)據(jù)庫的?持能?某客?原本采?“VMwareIT件和存儲(chǔ)?絡(luò)等弊端，IT級基礎(chǔ)架構(gòu)的同時(shí)能夠推進(jìn)基礎(chǔ)設(shè)施信創(chuàng)轉(zhuǎn)型，同時(shí)實(shí)現(xiàn)VMwareSmartX融合（ELF+分布式塊存儲(chǔ)軟件ZBS）?持IBMDB2數(shù)據(jù)庫，模擬業(yè)務(wù)系統(tǒng)運(yùn)?，并將性能測試結(jié)果與實(shí)際插?性能測試：通過腳本在DB21數(shù)據(jù)導(dǎo)出性能測試：通過腳本在DB21IBMDB2數(shù)據(jù)庫運(yùn)?在SmartX融合架構(gòu)上的性能表現(xiàn)優(yōu)于現(xiàn)有?產(chǎn)環(huán)境SAN架構(gòu)，可充分滿??產(chǎn)業(yè)務(wù)系統(tǒng)數(shù)據(jù)了SmartX融合具備“VMware虛擬化+存儲(chǔ)“的整體替換能?。SmartX融合?撐券商?業(yè)Oracle數(shù)據(jù)庫集中交易系統(tǒng)委托場景性能評此前在?信創(chuàng)環(huán)境下融合架構(gòu)的使?經(jīng)驗(yàn)，計(jì)劃引?國產(chǎn)融合來構(gòu)建輕量信創(chuàng)云，因此驗(yàn)證SmartX融合在基于Oracle為30萬條，?共30個(gè)PDC腳本同時(shí)運(yùn)?，每1000筆提交?次，總計(jì)運(yùn)?3分鐘，驗(yàn)證融合平臺(tái)在委托場景下的穩(wěn)SmartX融合平臺(tái)每秒插?量穩(wěn)定在4-10萬之間，整體表現(xiàn)?于實(shí)際?產(chǎn)環(huán)境性能?平。相?于其他?商的測試數(shù)測試的友商，性能表現(xiàn)優(yōu)異，可?持??構(gòu)建輕量信創(chuàng)云底座。此外，?些?融機(jī)構(gòu)也驗(yàn)證了SmartX融合?持Oracle數(shù)據(jù)庫運(yùn)?TA注冊登記系統(tǒng)、CISP估值數(shù)據(jù)落地等多任務(wù)跑批性能。SmartX融合?撐某基?公司OracleRAC及CC系統(tǒng)性能驗(yàn)博客鏈接：基于SMTXOS5.0NVMeSmartX表明，相?于?產(chǎn)環(huán)境，測試環(huán)境下CISP估值數(shù)據(jù)落地單任務(wù)跑批時(shí)間縮短85%，多任務(wù)跑批時(shí)間縮短82%。2015201G4臺(tái)HPDL580EMCVNX5G00混閃存儲(chǔ)組成的SANOracleRAC集群，每套RAC在2018年初，客?先后在周邊?產(chǎn)和信息化等業(yè)務(wù)場景中嘗試使?了SmartX融合架構(gòu)。截?當(dāng)前，兩個(gè)業(yè)務(wù)場景中的集群已經(jīng)穩(wěn)定運(yùn)?了過4年時(shí)間。在此期間，客?也將?套以RAC架構(gòu)部署的業(yè)務(wù)系統(tǒng)跑在融合上進(jìn)??時(shí)間在2020年底，基于現(xiàn)有2套融合集群的穩(wěn)定表現(xiàn)，客?決定新建?套融合集群，將傳統(tǒng)SAN架構(gòu)上的2套RAC系統(tǒng)遷移上來，同時(shí)對RAC2套RAC在SmartX融合架構(gòu)承載運(yùn)?多套RAC數(shù)據(jù)庫期間，客?關(guān)注到基?數(shù)據(jù)中?業(yè)務(wù)系統(tǒng)性能較遷移前存在?定的性能提升，與此同時(shí)客?也在規(guī)劃O32和TA?想了解，融合架構(gòu)是否可以進(jìn)?步提升該場景下的性能，同時(shí)也為后續(xù)O32和TA的基礎(chǔ)架構(gòu)選型提供數(shù)據(jù)參考，為此圍繞“基?數(shù)據(jù)中?系統(tǒng)”展開POC客?數(shù)據(jù)中?V4.0 在融合測試平臺(tái)，全新部署基?數(shù)據(jù)中?業(yè)務(wù)系統(tǒng)（簡稱cc），采?2副本存儲(chǔ)策略，部署OracleRAC集群。在測針對?產(chǎn)環(huán)境中耗時(shí)相對較?的場景（CISP）385%，性能優(yōu)勢明顯。43的跑批任務(wù)，可以在30多分鐘完成，跑批時(shí)間相?于?產(chǎn)環(huán)境縮短了82%，?幅提升了跑批效率。CPUUser%在部分時(shí)段存在70%、50%、30%、20%等持續(xù)時(shí)間的連續(xù)負(fù)載壓?，符合跑批場景下的特點(diǎn)。CPUWaitI/O密集型的應(yīng)?Wait整體看CPU1.5GB/sCPUUser%和Wait%的占?來看，存儲(chǔ)性能是該場景下決定跑批時(shí)間的關(guān)鍵因素。得益于SMTXOS5.0NVMe25GbEI/OSmartX對?速硬件的?持得益于融合與RDMA（RemoteDirectMemoryAccess）技術(shù)的結(jié)合。這?技術(shù)結(jié)合實(shí)現(xiàn)了不同節(jié)點(diǎn)之間分布式塊存儲(chǔ)軟件ZBS操作系統(tǒng)內(nèi)核進(jìn)?傳輸，由于bypass操作系統(tǒng)內(nèi)核態(tài)，可以節(jié)省?量CPU展能?差等問題，難以提供敏捷彈性的?可靠性保障。SmartX融合可為不同主?產(chǎn)環(huán)境數(shù)據(jù)庫提供異構(gòu)容災(zāi)保護(hù)，搭配數(shù)據(jù)庫原?的數(shù)據(jù)容災(zāi)功能，實(shí)現(xiàn)RPO=0、秒級RTO的容災(zāi)效果。?河財(cái)險(xiǎn)在其同?數(shù)據(jù)中?內(nèi)，以傳統(tǒng)架構(gòu)和SmartX融合架構(gòu)兩種異構(gòu)資源池作為IT基礎(chǔ)架構(gòu)?撐。基于SmartX融合集群的資源池，可?撐核??產(chǎn)應(yīng)?、互聯(lián)?應(yīng)?、ITOAOracle與MySQL，Oracle主庫和備庫分別部署在傳統(tǒng)架構(gòu)和SmartX融合架構(gòu)上，利?Oracle的ActiveDataGuard(ADG)功能實(shí)現(xiàn)數(shù)據(jù)同步；MySQL此外，?正富邦基?將部署在物理機(jī)上的O32、TA系統(tǒng)的核?數(shù)據(jù)庫和基于SmartX融合的多數(shù)據(jù)庫實(shí)例，利?數(shù)據(jù)庫復(fù)制技術(shù)，將數(shù)據(jù)同步到由SmartX融合集群構(gòu)建的容災(zāi)與?般業(yè)務(wù)資源池和深證通?業(yè)云，在實(shí)現(xiàn)關(guān)鍵數(shù)據(jù)庫容如何降低Oracle博客鏈接：如何降低Oracle隨著ITOracle數(shù)據(jù)庫構(gòu)建了IT不開基礎(chǔ)設(shè)施底座。之前，我們介紹了SmartX融合作為Oracle的云底座，能夠兼顧?性能與簡單敏捷等特性。同時(shí)，為確保業(yè)務(wù)連續(xù)性并符合監(jiān)管機(jī)構(gòu)政策要求，企業(yè)還需要構(gòu)建OracleOracle本?將概述不同主?產(chǎn)環(huán)境Oracle數(shù)據(jù)庫部署架構(gòu)，并介紹如何基于SmartX融合+Oracle數(shù)據(jù)庫原?容災(zāi)技術(shù)DG/ADG或者OGG，實(shí)現(xiàn)Oracle場景?：主?產(chǎn)環(huán)境是Oracle在主?產(chǎn)環(huán)境采?OracleExadata數(shù)據(jù)庫?體機(jī)或OracleODASmartX融合+Oracle原?數(shù)據(jù)庫容災(zāi)技術(shù)DG/ADGDataGuard/ActiveDataGuard)，構(gòu)建數(shù)據(jù)庫容災(zāi)環(huán)境。經(jīng)過優(yōu)化的SmartX融合可以獲得接近?體機(jī)的性能在主?產(chǎn)環(huán)境采?IBMPower?機(jī)+集中存儲(chǔ)作為Oracle數(shù)據(jù)庫運(yùn)?平臺(tái)時(shí)，可采?SmartX融合+Oracle原?數(shù)據(jù)庫容災(zāi)技術(shù)OracleGoldenGate(OGG)，構(gòu)建異構(gòu)服務(wù)器平臺(tái)的數(shù)據(jù)庫容災(zāi)環(huán)境。采?OracleOGG經(jīng)過優(yōu)化的SmartX融合可以獲得接近甚?過裸?屬加中?端存儲(chǔ)的性能容災(zāi)環(huán)境不再需要昂貴的IBMPower場景三：主?產(chǎn)環(huán)境是x84在主?產(chǎn)環(huán)境采?x8G服務(wù)器+集中存儲(chǔ)作為OracleOracleOracleDG/ADG+SmartX融合，構(gòu)建數(shù)據(jù)庫容災(zāi)環(huán)境。經(jīng)過優(yōu)化的SmartX融合可以獲得接近甚?過傳統(tǒng)架構(gòu)的性能在此場景下，由于x8G服務(wù)器+集中存儲(chǔ)是多年前設(shè)備，存在性能或者容量瓶頸，許多客?都會(huì)采?基于SmartX融合平臺(tái)的Oracle數(shù)據(jù)庫作為主?產(chǎn)環(huán)境，采?利舊現(xiàn)有x8G服務(wù)器+集中存儲(chǔ)的設(shè)備作為Oracle這樣可以在滿??業(yè)法規(guī)遵從要求的情況下，充分利舊現(xiàn)有IT在充分利?融合提升主?產(chǎn)環(huán)境性能的同時(shí)，SmartX融合的云化特性（按需擴(kuò)展、簡便管理等），可幫助客?更基于SmartX融合的容災(zāi)加固?案總體優(yōu)采?Oracle秒級RPO和分鐘級RTO，滿?法規(guī)遵從要求。成功案例：某保險(xiǎn)公司基于SmartX融合構(gòu)建Oracle?體機(jī)容災(zāi)加固資源某財(cái)險(xiǎn)公司基于OracleOA、DMZ、財(cái)務(wù)、投資等多個(gè)關(guān)鍵IT客?采?OracleODAx8G務(wù)、OA系統(tǒng)等的Oracle數(shù)據(jù)庫。體系優(yōu)化：建設(shè)公司級完整的IT能?提升：建?有效的災(zāi)備應(yīng)急處理體系，借助?動(dòng)化?具實(shí)現(xiàn)災(zāi)備?效有序切換，提升抗?險(xiǎn)能?和IT在充分考慮成本、性能、維護(hù)等因素后，客?確定了建設(shè)與主?產(chǎn)系統(tǒng)不同架構(gòu)、相同CPU基于?案?標(biāo)，客?在進(jìn)?了多次技術(shù)交流、POC測試后，確定采?SmartX融合+VMware虛擬化來建設(shè)Oracle通過在融合集群新建容災(zāi)Oracle數(shù)據(jù)庫（數(shù)據(jù)存儲(chǔ)采?3副本，確保數(shù)據(jù)?可?），讓若?套?產(chǎn)數(shù)據(jù)庫利?Oracle數(shù)據(jù)庫，實(shí)現(xiàn)秒級RPO和分鐘級RTO，達(dá)到建設(shè)?標(biāo)。容災(zāi)資源池同時(shí)?撐Oracle以更低總擁有成本實(shí)現(xiàn)秒級RPO和分鐘級RTO據(jù)庫以O(shè)racle、DB2、SQLServer為代表，由于數(shù)據(jù)庫在?融?業(yè)往往承載了關(guān)鍵業(yè)務(wù)數(shù)據(jù)，其數(shù)據(jù)訪問具備容量以O(shè)racle業(yè)務(wù)連續(xù)性為例，其主流的運(yùn)?操作系統(tǒng)集中在Linux和AIX（?融?業(yè)保有量?）的“煙囪式”垂直多層IT）。：RAC+?型機(jī)+FCRAC+x8G+FCRAC+x8G+VM+FC存儲(chǔ)庫備份、存儲(chǔ)異地?cái)?shù)據(jù)同步復(fù)制以及通過RACDG（?業(yè)監(jiān)管對業(yè)務(wù)可?性和數(shù)據(jù)可靠RAC+?型機(jī)+FCRAC+x8G+FC以O(shè)racleADG，GG切換演練等?作為IT單元和基于FCSAN（如使?存儲(chǔ)級數(shù)據(jù)遠(yuǎn)程復(fù)制技術(shù)，還需購買相關(guān)License作為?個(gè)嶄新的IT基礎(chǔ)架構(gòu)和產(chǎn)品形態(tài)，融合基礎(chǔ)架構(gòu)（HyperconvergedInfrastructure簡稱HCI）作為近?年IT下圖中以O(shè)racle為例結(jié)合融合架構(gòu)實(shí)現(xiàn)數(shù)據(jù)容災(zāi)保護(hù)，該?案采?硬件基礎(chǔ)架構(gòu)異構(gòu)的設(shè)計(jì)思路，上層數(shù)據(jù)庫采?ADG（OracleAdvanceDataGuard）和OGG（OracleGlodenGate）組合的?式保障數(shù)據(jù)?可靠性，底層利?基于x8G的融合架構(gòu)（融合計(jì)算、存儲(chǔ)、?絡(luò)）替代傳統(tǒng)架構(gòu)下的服務(wù)器+FC?絡(luò)+FCSAN共享存儲(chǔ)?體機(jī)和基于x8GCommvaultG套業(yè)務(wù)系統(tǒng)OracleG套庫的業(yè)務(wù)數(shù)據(jù)進(jìn)?實(shí)時(shí)分析。在?業(yè)監(jiān)控要求以及????對業(yè)務(wù)架構(gòu)可靠性、數(shù)據(jù)容錯(cuò)性、業(yè)務(wù)連續(xù)性、業(yè)務(wù)恢復(fù)速度的綜合多??考慮背景下，結(jié)合現(xiàn)階段?部署的IT的?量評估、測試驗(yàn)證，最終??選擇使?融合+傳統(tǒng)架構(gòu)混合異構(gòu)的?式建設(shè)新?代容災(zāi)保護(hù)平臺(tái)，為業(yè)務(wù)數(shù)據(jù)提某保險(xiǎn)公司?期融合環(huán)境由7臺(tái)SmartXHalo7100S組成，采?vSphere+分布式存儲(chǔ)ZBS的融合模式部署，每臺(tái)節(jié)點(diǎn)安裝ESXi虛擬化操作系統(tǒng)，并在每個(gè)節(jié)點(diǎn)上部署SmartXSCVM7個(gè)節(jié)點(diǎn)的本地磁盤組成分布式存儲(chǔ)池，節(jié)點(diǎn)之間通過10G?絡(luò)進(jìn)?存儲(chǔ)數(shù)據(jù)交換同步，提供G4TB數(shù)據(jù)存儲(chǔ)空間，業(yè)務(wù)系統(tǒng)的數(shù)據(jù)存儲(chǔ)策略為2副本，數(shù)據(jù)庫存儲(chǔ)策略為3副本。?前?撐30+業(yè)務(wù)系統(tǒng)。本次新建融合集群主要?的是備份??核??產(chǎn)Oracle數(shù)據(jù)庫，提供數(shù)據(jù)庫容災(zāi)備份，通過在HCI集群新建備份數(shù)據(jù)庫并與主庫實(shí)時(shí)數(shù)據(jù)同步（ADG），在主庫故障發(fā)?時(shí)，切換業(yè)務(wù)到備庫的容災(zāi)?案，數(shù)據(jù)庫VM3副項(xiàng)?實(shí)施后的Oracle降低IT融合架構(gòu)具備交付快、?可靠、擴(kuò)展易、成本低等特點(diǎn)，為?融?業(yè)關(guān)鍵業(yè)務(wù)系統(tǒng)加固提供了?種全新的IT為??提供異構(gòu)靈活的混合架構(gòu)解決?案，并為?融?業(yè)??未來的IT博客鏈接：Oracle步覆蓋?部分?產(chǎn)業(yè)務(wù)。但在?些重要業(yè)務(wù)場景，??對于融合架構(gòu)的適?性仍有疑慮。為此，我們整理了SmartX?線技術(shù)團(tuán)隊(duì)和?業(yè)??共同開展的業(yè)務(wù)場景融合?案適?性驗(yàn)證，希望相關(guān)的數(shù)據(jù)和結(jié)論可以為?業(yè)客?IT基礎(chǔ)架本次，我們將介紹SmartX融合對Oracle數(shù)據(jù)倉庫跑批性能?持與優(yōu)化的驗(yàn)證數(shù)據(jù)倉庫（DataWarehouse）是?種?向分析和報(bào)告的數(shù)據(jù)管理系統(tǒng)。通常，數(shù)據(jù)定期從事務(wù)系統(tǒng)、關(guān)系數(shù)據(jù)庫和其和決策者通過商業(yè)智能（BI）?具、SQL某?融客?在?產(chǎn)環(huán)境使?Oracle數(shù)據(jù)倉庫為CrystalReports（?晶報(bào)表）系統(tǒng)提供數(shù)據(jù)加?和數(shù)據(jù)處理。隨著業(yè)務(wù)量和數(shù)據(jù)量的增?，Oracle數(shù)據(jù)倉庫跑批的性能越來越差，?前跑批?作是從凌晨開始到早上G點(diǎn)結(jié)束，考慮到后期基于以上兩點(diǎn)原因，客?希望使?SmartX融合測試Oracle數(shù)據(jù)倉庫跑批性能本次測試是為了驗(yàn)證Oracle數(shù)據(jù)倉庫在融合架構(gòu)下的跑批性能表現(xiàn)。在數(shù)據(jù)量完全相同的情況下，對??產(chǎn)環(huán)境現(xiàn)有?案與基于SmartX融合的Oracle數(shù)據(jù)倉庫跑批時(shí)間，?共進(jìn)?3輪跑批測試，時(shí)間越短表現(xiàn)越優(yōu)異。將DB2數(shù)據(jù)庫的數(shù)據(jù)，通過Informatica（ETL）抽取到OracleOracle經(jīng)過多輪測試驗(yàn)證，SmartX融合架構(gòu)相?原?產(chǎn)架構(gòu)的?機(jī)+集中式存儲(chǔ)，在進(jìn)?Oracle數(shù)據(jù)倉庫跑批時(shí)有明顯的性能提升，34%，并得到客?認(rèn)可。驗(yàn)證了Oracle數(shù)據(jù)倉庫從?機(jī)下移x84服務(wù)器的可?性，為客?后續(xù)使?SmartX融合替換?機(jī)+集中式存e，以上測試僅驗(yàn)證了融合架構(gòu)?撐Oracle數(shù)據(jù)倉庫系統(tǒng)跑批的性能的可?性和優(yōu)勢。除此之外，融合?案還會(huì)為企提升可靠性與可?性：針對關(guān)鍵業(yè)務(wù)系統(tǒng)最關(guān)注的可靠性問題，?前SmartX也為??提供諸多融合容災(zāi)備份?案，在提升效率和降低成本的情況下，提升系統(tǒng)的可靠性和可?性。欲詳細(xì)了解SmartX案，請閱讀：??了解SmartX。資源整合：對于絕?多數(shù)?融客?，融合的計(jì)算虛擬化和分布式存儲(chǔ)可以有效統(tǒng)?整合各類IT系統(tǒng)的計(jì)算和存儲(chǔ)資源，進(jìn)?步降低整體IT彈性擴(kuò)展：SmartX融合架構(gòu)具有簡單、易操作的橫向擴(kuò)展能?，在擴(kuò)展容量及計(jì)算資源的同時(shí)也得到近乎線，不少?融機(jī)構(gòu)使?數(shù)倉業(yè)務(wù)系統(tǒng)，為公司?層提供?常經(jīng)營報(bào)表，同時(shí)?持監(jiān)管報(bào)送等應(yīng)?。該業(yè)務(wù)系統(tǒng)通常是I/O密集型應(yīng)?，對IT在《Oracle數(shù)據(jù)倉庫在超融合架構(gòu)下的跑批性能驗(yàn)證》?章中，我們分享了?融機(jī)構(gòu)利?SmartX融合優(yōu)化Oracle?SmartX某?融機(jī)構(gòu)使?傳統(tǒng)架構(gòu)?撐數(shù)倉業(yè)務(wù)系統(tǒng)，其中存儲(chǔ)使?EMCPowerStore否對標(biāo)全閃中?端集中式存儲(chǔ)？能否有效?撐數(shù)倉業(yè)務(wù)系統(tǒng)對報(bào)表輸出時(shí)效性的要求？為此，該?融客?使?SmartX計(jì)算端采?裸?屬（Intelx8G）部署Oracle24存儲(chǔ)端測試環(huán)境使?SMTXZBS3臺(tái)通?Intelx8G（混閃），1PowerStore1000T全閃存儲(chǔ)。數(shù)倉業(yè)務(wù)系統(tǒng)跑批的內(nèi)容是Oraclelinux數(shù)倉業(yè)務(wù)跑批期間統(tǒng)計(jì)了SMTXZBSSMTXZBS基準(zhǔn)數(shù)據(jù)指SMTXZBS本次測試數(shù)據(jù)指數(shù)倉業(yè)務(wù)跑批期間SMTXZBS博客鏈接：BI數(shù)倉跑批測試-vSAN緩存擊穿 在《VMware與SmartX分布式存儲(chǔ)緩存機(jī)制淺析與性能對?》中，我們分析了vSAN7緩存擊穿的問題及其原因。近期，某?融??在進(jìn)?數(shù)據(jù)倉庫分布式存儲(chǔ)選型時(shí)，同樣遭遇了測試過程中vSAN務(wù)的問題。隨后，??采?SmartX融合（內(nèi)置分布式存儲(chǔ)ZBS）進(jìn)?跑批測試與性能優(yōu)化，經(jīng)過多輪測試驗(yàn)證，SmartX融合可穩(wěn)定承載Oracle數(shù)據(jù)倉庫BI系統(tǒng)，并有效縮短跑批時(shí)間約42%（從?產(chǎn)環(huán)境的8.5?時(shí)縮短?低于5），滿?客?在性能及穩(wěn)定性??的要求。本?，我們將對這?測試實(shí)踐進(jìn)?分享，為有需求的讀者提供參考。某?融客?在?產(chǎn)環(huán)境中使?x8G服務(wù)器和全閃集中式存儲(chǔ)EMCPowerMax?撐Oracle數(shù)據(jù)倉庫，為BI???先對vSANBI/DWvSAN400G（7:3），10，導(dǎo)致整體性能下降，影響其他業(yè)務(wù)系統(tǒng)VM，?法完成跑30MB/s（全量跑批數(shù)據(jù)量），不僅?法充分利?閃存性能，更不能在?產(chǎn)環(huán)境要求的時(shí)間窗?（8.5）內(nèi)完成全量數(shù)據(jù)跑批任務(wù)。發(fā)現(xiàn)vSAN難以滿??產(chǎn)需求后，??轉(zhuǎn)向考慮其他分布式存儲(chǔ)?案。在了解到SmartX融合（內(nèi)置?研分布式存儲(chǔ)ZBS）豐富的?融?產(chǎn)環(huán)境案例與優(yōu)化的緩存機(jī)制后，??計(jì)劃對SmartX融合環(huán)境下的BI/DW進(jìn)?多輪跑批測試，本次測試關(guān)注Oracle數(shù)據(jù)倉庫在SmartX融合架構(gòu)下的跑批性能優(yōu)化效果，通過3輪多次跑批測試（基于不同存儲(chǔ)硬件），對??產(chǎn)環(huán)境集中式存儲(chǔ)?案、vSAN?案和SmartX融合架構(gòu)下Oracle數(shù)據(jù)倉庫的存儲(chǔ)性能和跑批時(shí)間。具驗(yàn)證SmartX融合架構(gòu)能否同時(shí)承載BI/DW及新的SQLServer數(shù)據(jù)庫，同時(shí)滿?I/O性能要求SmartX融合環(huán)境：融合軟件SMTXOS5.1.0、集群管理CloudTower3.0、vSphere?產(chǎn)場景，打開歸檔并進(jìn)?跑批測試。結(jié)果顯?，SmartX融合環(huán)境下BI/DW僅需8.5?時(shí)即可完成全量跑批任務(wù)，10ms，判斷為冷數(shù)據(jù)交互導(dǎo)致，因此計(jì)劃開展第三考慮到客?未來?產(chǎn)環(huán)境集群將承載多套DB8結(jié)果顯?，SmartX融合環(huán)境下，BI/DW僅需不到5?時(shí)即可完成全量跑批任務(wù)，同時(shí)可承載SQLServer數(shù)據(jù)庫，10T83%。全閃集群下，讀帶寬有所提?（1.9GBps），讀寫延遲均?幅下降：寫延遲最?8.05ms，平均為4ms；讀延遲最?不過5ms，平均為2ms。三輪測試后，SmartX融合環(huán)境下數(shù)據(jù)倉庫整體跑批時(shí)間滿?客?預(yù)期，可避免緩存擊穿問題，同時(shí)驗(yàn)證了在?存儲(chǔ)融合架構(gòu)的Oracle數(shù)據(jù)倉庫BI8.5542%。通過多輪連續(xù)測試驗(yàn)證，SmartX融合架構(gòu)相?原?產(chǎn)傳統(tǒng)架構(gòu)，在進(jìn)?Oracle數(shù)據(jù)倉庫報(bào)表跑批時(shí)有了明驗(yàn)證了Oracle數(shù)據(jù)倉庫從x8G4路物理服務(wù)器遷移到2路融合服務(wù)器的可?性，同時(shí)確認(rèn)性能及運(yùn)維簡易?前，??已采?SmartX融合構(gòu)建7+7全閃雙活集群作為?產(chǎn)DB資源池，穩(wěn)定?撐新核?系統(tǒng)的SQLServerAlways-OnOracleRAC形態(tài)承載BI、零售庫存、ESPOracle得益于SmartX融合在以上數(shù)據(jù)庫場景評估中的優(yōu)異表現(xiàn)，SmartX融合對于?融等?業(yè)?產(chǎn)環(huán)境核?業(yè)務(wù)及對應(yīng)SmartX例如，某兩岸合資基?在使?SmartX融合承載外圍?產(chǎn)和辦公?產(chǎn)后，對融合架構(gòu)的性能和穩(wěn)定性?分認(rèn)可，隨后便將應(yīng)?場景拓展到數(shù)據(jù)庫資源池，采?4節(jié)點(diǎn)SmartX融合?體機(jī)承載8套多數(shù)據(jù)庫實(shí)例集群，運(yùn)?CC、?控、某頭部?營銀?也使?SmartX融合承載100+套核?業(yè)務(wù)系統(tǒng)的MySQL數(shù)據(jù)庫：在?產(chǎn)環(huán)境中，??配置了10個(gè)節(jié)點(diǎn)的SMTXOS融合軟件（采?原?虛擬化ELF），承載了除核?賬務(wù)系統(tǒng)數(shù)據(jù)庫之外全部的?產(chǎn)系統(tǒng)數(shù)據(jù)庫，同時(shí)實(shí)現(xiàn)了國產(chǎn)融合+分布式云化雙轉(zhuǎn)型。某保險(xiǎn)客?在對數(shù)據(jù)庫的穩(wěn)定性、可?性和性能進(jìn)?多維度的綜合評估后，決定新建?于?撐Oracle融合資源池。為降低遷移復(fù)雜度，并保持和原虛擬化架構(gòu)的?致性，OracleVMwareESXi。?前已遷移??余套Oracle數(shù)據(jù)庫，涵蓋渠道類、應(yīng)?類和BI報(bào)表業(yè)務(wù)等系統(tǒng)。此外，某公募基?管理公司也在使?SmartX融合承載O32、TA、估值等核?系統(tǒng)的災(zāi)備并穩(wěn)定運(yùn)??年多后，充分認(rèn)可SmartX融合的穩(wěn)定性和可靠性，將災(zāi)備資源池轉(zhuǎn)為?產(chǎn)資源池，使?SMTXOS（ELF+ZBS）?撐O32、TA、?2017年起，該客?開始和SmartX接觸并了解融合技術(shù)，逐步探索以融合承載外圍?產(chǎn)、辦公?產(chǎn)，并在對?前在很多企業(yè)的核?業(yè)務(wù)中，往往會(huì)使?數(shù)套核?數(shù)據(jù)庫，每庫容量在?百GB到?TB不等，對可靠性和性能都有各種IT運(yùn)維簡單：基于產(chǎn)品運(yùn)維?員熟悉的標(biāo)準(zhǔn)PC以該客?的案例為例，4節(jié)點(diǎn)SmartX融合?體機(jī)承載了8套多數(shù)據(jù)庫實(shí)例集群，承載CC、?控、估值、直銷、監(jiān)管SmartX融合不僅可以作為核?數(shù)據(jù)庫的云底座，同時(shí)還可以構(gòu)建核?數(shù)據(jù)庫容災(zāi)環(huán)境，以確保業(yè)務(wù)連續(xù)性以及符合在該客?的實(shí)際應(yīng)?中，部署在物理機(jī)上的O32、TASmartX同時(shí)，客?的CC8到由SmartX融合集群構(gòu)建的容災(zāi)與?般業(yè)務(wù)資源池和深證通?業(yè)云，實(shí)現(xiàn)關(guān)鍵數(shù)據(jù)庫的容災(zāi)加固。基于SmartX融合，構(gòu)建核?數(shù)據(jù)庫?產(chǎn)和容災(zāi)資源池，可按需彈性擴(kuò)展降低?產(chǎn)數(shù)據(jù)庫資源池建設(shè)成本，?4個(gè)SmartX融合節(jié)點(diǎn)承載8套多數(shù)據(jù)庫實(shí)例運(yùn)?降低數(shù)據(jù)庫容災(zāi)加固的建設(shè)成本，基于數(shù)據(jù)庫數(shù)據(jù)復(fù)制技術(shù)實(shí)現(xiàn)核?數(shù)據(jù)庫到SmartX融合資源池和深證實(shí)現(xiàn)秒級RPO，分鐘級RTO攜?合作四余年，客?也對SmartX的產(chǎn)品和服務(wù)有了切實(shí)受，CIO對SmartX的評價(jià)如下“?從使?SmartX融合以來，我們沒有發(fā)?過數(shù)據(jù)異常的問題，也沒有發(fā)?過性能問題，通過外部控制臺(tái)就可以絡(luò)，我們從到貨?交付使?了3天的時(shí)間，最終幫助我們業(yè)務(wù)系統(tǒng)如期順利上線?！薄皬匿N售?員到技術(shù)?員都可以?專業(yè)兩個(gè)字來形容，不管是什么問題，只要找到?個(gè)SmartX博客鏈接：銀?100MySQL某頭部?營銀?是全國第?家O2OOnlinetoO?ineO2O?融=普惠?融”的經(jīng)營邏輯，?爭成為區(qū)域普惠?融客群最多、FintechIT該銀?的這項(xiàng)輕量私有云實(shí)踐，探索了符合區(qū)域銀???特點(diǎn)及需求的云化轉(zhuǎn)型?案，同時(shí)也充分說明SmartX融合不僅能運(yùn)?于VDI、開發(fā)測試等場景，也能滿?重要?產(chǎn)系統(tǒng)的需要，承載重要?產(chǎn)應(yīng)?及其配套的數(shù)據(jù)庫。隨著業(yè)務(wù)系統(tǒng)越來越互聯(lián)?化，作為該頭部?營銀?云化轉(zhuǎn)型的底座，數(shù)據(jù)中?IT如何以更低的總擁有成本?撐云化轉(zhuǎn)型對IT如何提升業(yè)務(wù)系統(tǒng)以及內(nèi)部研發(fā)對IT具體??，??現(xiàn)有的傳統(tǒng)IT開源軟件構(gòu)建私有云：利?多個(gè)開源軟件分別完成IaaS、PaaS中，在資源池的構(gòu)建?式上，以往的傳統(tǒng)三層式架構(gòu)占據(jù)統(tǒng)治地位，但主流融合?商搭配成熟商?CMP產(chǎn)品構(gòu)建私在確定?向和考察?商之后，該銀?決定選?SmartX融合進(jìn)?產(chǎn)品POC與試??、產(chǎn)品POC該銀?與SmartX3個(gè)?，分別針對SmartX原?虛擬化ELFPOC與試?，對SmartX融合系統(tǒng)的功能、性能、穩(wěn)定性及實(shí)際運(yùn)?業(yè)務(wù)系統(tǒng)的效果進(jìn)?了全?位的驗(yàn)證。???，SmartXSMTXOSELF除了體驗(yàn)常規(guī)的存儲(chǔ)、虛擬化功能外，還遷移部署了若?測試環(huán)境應(yīng)?運(yùn)?在SmartX融合平臺(tái)。另???，SmartXSMTXOSPOC經(jīng)過POCSMTXOSELFSMTXOS由于SmartXSmartX確認(rèn)采?SmartX?案之后，??并沒有?開始就直接完成全部業(yè)務(wù)系統(tǒng)MySQL數(shù)據(jù)庫的遷移?作，?是計(jì)劃通過SmartX提供的V2V10SmartX在這個(gè)環(huán)節(jié)中，SmartXV2V10機(jī)，經(jīng)過1個(gè)?的實(shí)際?產(chǎn)環(huán)境驗(yàn)證，再?次印證了SmartX產(chǎn)品的穩(wěn)定性和可靠性。從以上過程可以看出，融合作為創(chuàng)新的融合部署的分布式架構(gòu)，滿?了??多??的需求。該銀???選擇SmartX在?產(chǎn)環(huán)境中，??配置了10個(gè)節(jié)點(diǎn)的SMTXOS融合軟件（采?內(nèi)置免費(fèi)的ELF虛擬化），承載了100+?產(chǎn)業(yè)務(wù)系統(tǒng)的MySQL數(shù)據(jù)庫并穩(wěn)定運(yùn)?。融合承載了除核?賬務(wù)系統(tǒng)數(shù)據(jù)庫之外全部的?產(chǎn)系統(tǒng)數(shù)據(jù)庫，如電?票據(jù)、企在災(zāi)備環(huán)境中，??配置了G個(gè)節(jié)點(diǎn)的SMTXOS（采?內(nèi)置免費(fèi)的ELF），承載災(zāi)備機(jī)房全部業(yè)務(wù)系統(tǒng)（率先在業(yè)內(nèi)采?基于融合架構(gòu)和CMP云管理平臺(tái)的輕量私有云，?案核?的計(jì)算和存儲(chǔ)組件全部為互聯(lián)?化基于融合+云管平臺(tái)?案，該銀?實(shí)現(xiàn)了分布式架構(gòu)的云化轉(zhuǎn)型，滿?了業(yè)務(wù)系統(tǒng)對于敏捷資源的需求，還優(yōu)化了總借助架構(gòu)精簡、融合部署的融合，降低30%硬件采購數(shù)量，節(jié)省50%機(jī)柜空間。前期?規(guī)模起步，真正實(shí)采?融合原?ELF虛擬化，?持異構(gòu)，降低成本。借助擁有?研核?的融合軟件，進(jìn)?步提升國產(chǎn)化?未來，將有更多的業(yè)務(wù)系統(tǒng)陸續(xù)遷移到SmartX融合平臺(tái)上運(yùn)?，SmartX融合將繼續(xù)助?該銀?私有云的搭建完融合?撐保險(xiǎn)客?構(gòu)建?產(chǎn)級MySQLOracle2018年，某保險(xiǎn)客?在開發(fā)測試環(huán)境部署了?套基于融合的基礎(chǔ)架構(gòu)平臺(tái)，成功使?國產(chǎn)虛擬化+分布式存儲(chǔ)替代了VMware300I/O融合集群的部署落地，500?客?的?產(chǎn)數(shù)據(jù)庫硬件平臺(tái)逐漸?化，使?年限已5年，底層硬件平臺(tái)升級替換在2021年被提上?程。由于融3SmartX本?將介紹該客?的MySQL及OracleSmartX融合在開發(fā)測試環(huán)境?撐多套MySQL數(shù)據(jù)庫穩(wěn)定運(yùn)?3年以上，其中在針對“團(tuán)險(xiǎn)銷管”系統(tǒng)報(bào)表功能進(jìn)?50s，認(rèn)為這個(gè)時(shí)間已經(jīng)很?，做全量需要更多的時(shí)間。詢，與?產(chǎn)環(huán)境測試“?天數(shù)據(jù)量”（數(shù)據(jù)量與全量數(shù)據(jù)相差3個(gè)數(shù)量級）的查詢數(shù)據(jù)對?，SmartX融合查詢性能客?新建?套3節(jié)點(diǎn)全閃架構(gòu)的融合集群，使?SmartX原?虛擬化ELF，專??于?撐MySQL數(shù)據(jù)庫業(yè)務(wù)，使?v2v?案遷移11套MySQL業(yè)務(wù)數(shù)據(jù)庫到融合集群，包含渠道類、內(nèi)部應(yīng)?類和周邊應(yīng)?類業(yè)務(wù)系統(tǒng)，?前已完成?期3套系統(tǒng)的遷移，每套數(shù)據(jù)庫系統(tǒng)均包含多個(gè)虛擬機(jī)，采?MySQL“?主多從”的部署?案。使?融合架構(gòu)?撐Oracle?產(chǎn)系統(tǒng)數(shù)據(jù)庫，對于客?基礎(chǔ)架構(gòu)是?次關(guān)鍵的轉(zhuǎn)型探索，需要進(jìn)?全?的評估和充分驗(yàn)證。經(jīng)過與客?的溝通討論，客?確定臨時(shí)構(gòu)建?套三節(jié)點(diǎn)融合集群并新裝部署OracleRAC（虛擬機(jī)資源配置以及數(shù)據(jù)庫配置參考?產(chǎn)環(huán)境中的電商系統(tǒng)），使?第三?的標(biāo)準(zhǔn)數(shù)據(jù)庫測試?具SwingBench8能測試，評估Oracle第三?壓測?具SwingBench使?默認(rèn)TPC-C100TPM平均值為G3100200300放Oracle（百萬級TPM），且性能曲線輸出平穩(wěn)。我們通過?業(yè)經(jīng)驗(yàn)，看?下這?的TPM系。每筆交易按15個(gè)原?操作計(jì)算，并根據(jù)?業(yè)經(jīng)驗(yàn)保留30%余量，相當(dāng)于每分鐘處理過3萬筆復(fù)雜?融業(yè)務(wù)交易能進(jìn)?多維度的綜合評估后，客?最終決定，在建設(shè)MySQL資源池后，新建?于?撐Oracle數(shù)據(jù)庫的全閃融合資源池。為降低遷移復(fù)雜度，并保持和原虛擬化架構(gòu)的?致性，Oracle資源池的虛擬化層延?VMwareESXi。2G套Oralce2OracleRAC（兩節(jié)點(diǎn)），涵蓋客??前架構(gòu)?撐平臺(tái)、渠道類、周邊應(yīng)?類和BI基于融合架構(gòu)的企業(yè)云IaaS平臺(tái)通過融合計(jì)算、存儲(chǔ)、?絡(luò)資源，有效降低基礎(chǔ)架構(gòu)的建設(shè)成本和復(fù)雜度，在保持近相?于服務(wù)器+集中存儲(chǔ)的傳統(tǒng)架構(gòu)，融合架構(gòu)的I/O本地化、SSD緩存等技術(shù)特性帶來了更多的性能提升。全分布式的部署模式，使得集群I/O 從總體擁有成本來看，基于融合的分布式架構(gòu)具有顯著的成本優(yōu)勢。使?標(biāo)準(zhǔn)以太?交換機(jī)替換了專有FC最?化利?上服務(wù)器磁盤插槽，將服務(wù)器的硬件能?充分釋放。融合架構(gòu)?持?規(guī)模3節(jié)點(diǎn)起步，按需彈性使?國產(chǎn)?主研發(fā)的分布式存儲(chǔ)?案進(jìn)?企業(yè)云IaaS某公募基?管理公司：以融合構(gòu)建?產(chǎn)及災(zāi)備環(huán)境，承載Oracle數(shù)據(jù)原有集中式存儲(chǔ)升級為SmartX?主研發(fā)的分布式塊存儲(chǔ)ZBS，且虛擬化采?SmartX原?虛擬化ELF（基于KVM），為后續(xù)信創(chuàng)整體轉(zhuǎn)型奠定基礎(chǔ)。某公募基?管理公司于2013年底開始進(jìn)?信息化建設(shè)的規(guī)劃，基于對SmartX融合架構(gòu)及其在基??業(yè)成熟應(yīng)?案例的了解，該客?決定先通過POC驗(yàn)證融合性能和?可?，引?SmartX融合開啟IT基礎(chǔ)架構(gòu)轉(zhuǎn)恒?O32SmartX融合軟件SMTXOS部署在由3臺(tái)標(biāo)準(zhǔn)x8G服務(wù)器組成的集群上，創(chuàng)建兩個(gè)虛擬機(jī)分別承載APP和OracleDB，其中APP8vCpu32G（低配），OracleDB8vCpu32G（?配）。該客?原有的傳統(tǒng)架構(gòu)運(yùn)?O32交易系統(tǒng)中的?個(gè)靜態(tài)?控模塊需要約15min，同運(yùn)?清算后備份和靜態(tài)?控模塊需綜合POC測試情況，客?決定正式引?SmartX融合架構(gòu)進(jìn)?IT基礎(chǔ)架構(gòu)的轉(zhuǎn)型?2020年?2022年，客?分批次共計(jì)部署了3個(gè)節(jié)點(diǎn)SmartX融合產(chǎn)品，其中G個(gè)節(jié)點(diǎn)以純軟件的形式部署，3個(gè)節(jié)點(diǎn)以?體機(jī)的形式部署。同時(shí)，融合也從最初的災(zāi)備資源池轉(zhuǎn)為了?產(chǎn)資源池，承載O32和估值等核?業(yè)務(wù)系統(tǒng)。在2020年末?期部署中，客?基于SmartX原?虛擬化ELF（基于KVM的虛擬化平臺(tái)）部署3個(gè)融合節(jié)點(diǎn)，以純軟件形式交付，承載O32、TA、估值等核?系統(tǒng)的災(zāi)備。經(jīng)過半年多的災(zāi)備環(huán)境實(shí)地驗(yàn)證，客?更加認(rèn)可SmartX融合產(chǎn)品的穩(wěn)定性，也進(jìn)?步熟悉原?虛擬化ELF的產(chǎn)品功能，在2021年中旬?期部署中選擇擴(kuò)容3節(jié)點(diǎn)，增?災(zāi)備環(huán)境?撐。本次部署，以?體機(jī)的形式交付。左右的測試聯(lián)調(diào)后全部切換到融合環(huán)境中上，同時(shí)新增3個(gè)純軟件節(jié)點(diǎn)作為同城災(zāi)備機(jī)房的基礎(chǔ)資源。在基于融合構(gòu)建的?產(chǎn)與災(zāi)備資源池的基礎(chǔ)上，?前，客?進(jìn)?步通過SMTXOS的異步復(fù)制功能持續(xù)將?產(chǎn)集群業(yè)未來，計(jì)劃將融合應(yīng)??辦公?產(chǎn)、開發(fā)測試等場景中，并繼續(xù)完善異步復(fù)制?案。此外，客?也將探索/某?壽保險(xiǎn)公司?機(jī)數(shù)倉下移實(shí)踐，提升Oracle隨著數(shù)據(jù)中?IT某?壽保險(xiǎn)公司（以下簡稱“客?”）過往采?傳統(tǒng)三層架構(gòu)，即IBMPower/x8GFCSAN聚焦融合?商存儲(chǔ)?研能?，選擇SmartX逐步擴(kuò)在選型過程中，志凌海納SmartX憑借核??研能?、本地服務(wù)?持響應(yīng)能?、以及在POC過程中展?出的良好性公司籌建時(shí)的IT?2013年合作以來，客?（含養(yǎng)?公司）共采?45節(jié)點(diǎn)SmartX融合搭建了8套集群，承載團(tuán)險(xiǎn)核?系統(tǒng)、公司由于SmartX融合具備?規(guī)模起步、按需靈活擴(kuò)展的特性，客?可以從容應(yīng)對業(yè)務(wù)需求增加所對應(yīng)的資源增?，不必在使?SmartX融合集群?撐開發(fā)測試、?產(chǎn)以及輕量型數(shù)據(jù)庫系統(tǒng)近4年后，客?希望進(jìn)?步驗(yàn)證使?SmartX存儲(chǔ)上的Oralce數(shù)據(jù)倉庫系統(tǒng)，為后續(xù)逐步淘汰?舊Power服務(wù)器做前期驗(yàn)證?？?在?產(chǎn)環(huán)境使?Oracle數(shù)據(jù)倉庫為CrystalReports（?晶報(bào)表）系統(tǒng)提供數(shù)據(jù)加?和數(shù)據(jù)處理。隨著業(yè)務(wù)量和數(shù)據(jù)量的增?，OracleG在數(shù)據(jù)量完全相同的情況下，對??產(chǎn)環(huán)境現(xiàn)有?案與基于SmartX融合的Oracle數(shù)據(jù)倉庫跑批時(shí)間，?共進(jìn)?3輪SmartX融合VS?機(jī)+集中存儲(chǔ)驗(yàn)證OracleDW經(jīng)過多輪測試驗(yàn)證，SmartX融合架構(gòu)相?原?產(chǎn)架構(gòu)的?機(jī)+集中式存儲(chǔ)，在進(jìn)?Oracle數(shù)據(jù)倉庫跑批時(shí)3G%，并得到客?認(rèn)可。驗(yàn)證了Oracle數(shù)據(jù)倉庫從?機(jī)下移x8G服務(wù)器的可?性，為后續(xù)使?SmartX融合替換?機(jī)+集中式存儲(chǔ)，e運(yùn)，在探索融合應(yīng)?場景的歷程中，客?始終以業(yè)務(wù)系統(tǒng)穩(wěn)定運(yùn)?、數(shù)據(jù)可靠安全為前提，對IT基礎(chǔ)架構(gòu)的演進(jìn)不斷嘗試提升ITIT穩(wěn)定、彈性拓展的IT當(dāng)前客?正在逐步將OracleRAC、數(shù)倉等系統(tǒng)遷移?SmartX融合?性能集群中，充分發(fā)揮集群?性能優(yōu)勢。未來將繼續(xù)深化與SmartX博客鏈接：為了更好地開展智慧醫(yī)療服務(wù)，不少醫(yī)院已經(jīng)在完善HIS、EMR、PACS息集成平臺(tái)，并在此基礎(chǔ)上形成了CDR、ODR等各類數(shù)據(jù)倉庫。業(yè)務(wù)系統(tǒng)的升級也讓??提?了對IT基礎(chǔ)架構(gòu)的要為此，我們將通過多例SmartX融合?撐醫(yī)療核?數(shù)據(jù)庫的??實(shí)踐，帶您?窺SmartX融合如何通過架構(gòu)簡化與SmartX?向醫(yī)療??提供架構(gòu)簡單、性能強(qiáng)勁的融合基礎(chǔ)設(shè)施解決?案：以“SMTXOS融合軟件+商?服務(wù)器+在硬件??，SmartX融合不僅?持25GbE和100GbE的?速?絡(luò)，還提供全閃和NVMe配置的融合?體機(jī)，可充分滿?醫(yī)療數(shù)據(jù)庫與集成平臺(tái)的?性能需求。在軟件??，SmartX融合還通過I/O本地化、冷熱數(shù)據(jù)?動(dòng)分層、Boost模式、RDMA等技術(shù)特性，進(jìn)?步降低了響應(yīng)時(shí)延、提升了架構(gòu)的整體性能。此外，SmartX融合的全分布式架構(gòu)和彈性擴(kuò)展能?，可?持性能隨資源擴(kuò)展?線性提升，避免了性能瓶頸，保障了除了提升性能和規(guī)避宕機(jī)帶來的停機(jī)與數(shù)據(jù)丟失?險(xiǎn)，SmartX還通過可滿?多種級別和場景的融合災(zāi)備解決?案，進(jìn)?步保障醫(yī)療數(shù)據(jù)庫與集成平臺(tái)的可?性。災(zāi)備?案不僅?持ELF和VMwareOracle數(shù)據(jù)庫性能驗(yàn)證：SmartX融合表現(xiàn)優(yōu)于為了驗(yàn)證SmartX融合對數(shù)據(jù)庫的?持能?，我們使?Swingbench?具測試了相同配置的Oracle數(shù)據(jù)庫在裸?屬服務(wù)器、VMware融合和SmartX融合三種不同IT基礎(chǔ)架構(gòu)上的性能表現(xiàn)。結(jié)果顯?，在100G數(shù)據(jù)（數(shù)據(jù)膨脹后約350G）壓?下，基于三種架構(gòu)的數(shù)據(jù)庫TPS分別為27123、14231和2324G。SmartX融合架構(gòu)下，Oracle壓測宣武醫(yī)院：SmartX融合?撐HIS備庫穩(wěn)定運(yùn)博客鏈接：融合承載HIS基于以上數(shù)據(jù)，不少醫(yī)院充分認(rèn)可SmartX融合在醫(yī)療數(shù)據(jù)庫場景的優(yōu)秀表現(xiàn)，并已將核?業(yè)務(wù)與對應(yīng)數(shù)據(jù)庫部署在SmartX融合平臺(tái)。例如，??診量8000的?都醫(yī)科?學(xué)宣武醫(yī)院使?搭配了NVMe閃存的SMTXHalo融合?體機(jī)（基于ELF）構(gòu)建了5節(jié)點(diǎn)融合集群，承載HIS系統(tǒng)、HIS備份數(shù)據(jù)庫、HISRedis只讀庫、HIS中間件、XAP中間件等核?業(yè)務(wù)系統(tǒng)與數(shù)據(jù)庫，并通過三副本技術(shù)保障集群可靠性。同時(shí)，??使?普通混閃融合?體機(jī)，運(yùn)?PACS務(wù)于?體的綜合醫(yī)院（三級甲等）。該醫(yī)院選擇了SmartX融合進(jìn)?基礎(chǔ)架構(gòu)轉(zhuǎn)型，并進(jìn)?多次在線擴(kuò)容，?前承了醫(yī)院的?乎全部內(nèi)?業(yè)務(wù)和數(shù)據(jù)庫，包括HIS應(yīng)?以及HISOracleRACPACS、集成平臺(tái)、RIS、LIS、EMR作為全國最?的?腔專科醫(yī)院，北京?學(xué)?腔專科醫(yī)院原有HIS本較?、運(yùn)維管理復(fù)雜，尋求HIS數(shù)據(jù)庫環(huán)境的基礎(chǔ)架構(gòu)融合轉(zhuǎn)型。在測試環(huán)境下?時(shí)間運(yùn)?EMR測試數(shù)據(jù)庫環(huán)境，并與EMR有?倍以上的提升。多次業(yè)務(wù)在線擴(kuò)容后，?前融合集群?撐HIS測試數(shù)據(jù)庫、HIS?產(chǎn)庫（含?診庫與住院庫）、DockerCenter與消息服務(wù)，均采?SmartX原?的ELF虛擬化替換Hyper-V，?2020年上線后穩(wěn)定運(yùn)??今。?貢市第???醫(yī)院：融合與