SmartX?融?業的多種應?場景。此?檔整理“保險”機數量、配置和?常資源使?情況，希望可以為?業客戶IT

20關于北京志凌海納科技有限公司（SmartX）成?于2013年，是專業的現代化IT?案提供商。?向企業?建云需求，SmartX提供包含虛擬化、分布式存儲、軟件定義?絡與安全、容器管理與服務、數據保護與容災等模塊在內的超融合基礎設施、分布式存儲、Kubernetes原?存儲等多樣化產品組合，助?客戶構建簡單、彈性、可靠、開放的現代化IT憑借?研能?與卓越產品，SmartX獲評國家級“專精特新”?巨?企業與Gartner全球全棧超融合軟件推薦?商、連續三年獲評GartnerPeerInsights亞太區客戶之選，并多次?選Gartner、IDC、Forrester、GigaOm等國際分析機構全球報告，作為專業?商在全球范圍內?錄超融合架構?撐各類?產級數據庫系 Oracle/MySQL基于超融合和分布式存儲構建保險災備中 微分段加強云化數據中??絡安全防 分布式存儲?撐保險存算分離場 基礎架構?主可控“國產化轉型 全?替代國外超融合品 保險新場景探索與實 SmartX構建“解耦”“輕量”“敏捷”企業 SmartX保險?業客戶案 字化業務發展的重要核?組融合，具有更短的I/O路徑，?前SmartX超融合基礎架構和災備環境中，分別?撐了架構簡單靈活，3節點起資源，從?提?業務交付效

8年，某保險客戶在開發測試環境部署了?套基于超融合的基礎架構平臺，成功使?國產虛擬化+分布式存儲替代了e++團O融合平臺在開發測試環境中的性能表現相?當前?產環境獲得數倍提升，這進?步增加了客戶將超融合架構應?于?產系統隨后從2019年到2021年，經過3進，歷經三期的改造和升級擴容，客戶?產環境完成了2套超融合集群的部署落地，500?客戶的?產數據庫硬件平臺逐漸?化，使?年限已超5年，在開發測試和?產環境有著3年多的穩定運?及性能表現，得到了客戶的充分認可，這為客戶決定使?SmartX超融合架構MySQLSmartXMySQL?3年以上，其中針對“團險銷管”系統報表功能，基于相同的鏈路，采?新型?速存儲介化+分布式存儲）可以允許多硬件資源（CPU/內存/?絡/可?性。對于很多單機數據隔離性。

超融合架構相?當前?產環境，在數據庫查詢類業務表現MySQL客戶新建?套3節點全閃架構的超融合集群，使?SmartX原?虛擬化F，專??于?撐?產L數據庫業務，使?v1套L道類、內部應?類和周邊應?類業務系統，每套數據庫系統均包含多個虛擬機，采?L“?主多從”的部署?案。業務系統主要包括反洗錢、新團險銷售管理、核?接?優化出單、R統?接?平臺、官?微信、團險核?接?平臺、企福保、MySQL（3），192器，2.3T內存，68T存儲裸容量。Oracle

e構是?次關鍵的轉型探索，需要進?全?的評估和充分驗證。經過與客戶的溝通討論，客戶確定臨時構建?套三節點超融合eC參考?產環境中的電商系統），使?第三?的標準數據庫測試?具SwingBench進??達8?時的持續性能測試，評估Oracle數據庫性能表現。第三?壓測?具SwingBench使?默認TPC-C壓測模型，在100?戶并發下，TPM平均值為63萬，平均延時為6ms。200TPM101300TPM112000?戶的并發測試?例，通過測試，在?并發?戶下，可以充e。通過?業經驗，看?下這?的TPM與應?業務的關系。每筆交易按15個原?操作計算，并根據?業經驗保留30%余量，相當于每分鐘處理超過3萬筆復雜?融業務交易，在不能實際壓測?產環境進?對?的背景下，此次測試數Oracle本次數據庫性能驗證，超融合架構展現出的性能指標完全可以滿?客戶的業務需求。在對數據庫的穩定性、可?性和性能進MySQL后，新建?于?撐Oracle數據庫的全閃超融合資源池。為降低遷移復雜度，并保持和原虛擬化架構的?致性，Oracle資源池的虛擬化層延?VMwareESXi。到?前為?，已遷移完成28套Oracle數據庫系統，含4套OracleRAC（兩節點），涵蓋客戶?前架構?撐平臺、渠道類、周邊應?類和BI報表業務等超融合集群（6節點）共提供了384個邏輯處理器，4.6T內存，230T存儲裸容量。S資源，有效降低基礎架構的建設成本和復雜度，在保持架構可靠性和?性能的前提下，提?了架構敏捷性，通過兩期的?產數據庫（L、e）資源池建設，客戶利?超融合架構完成了對重要?產系統的基礎架構轉型。同時實現了企業云基礎架構的分布式云化轉型和虛擬化以及存儲的國產化逐步替SMTXOS?持構建完整的備份和容災?案，包括雙活、備份與容災（備份與恢復、復制與恢復），提供不同級別的PRORTO、兼具?可靠和?可?性，從?保障企業核??以拉伸集群的?式，實現兩個可?域的數據實時同步。當優RPO=0和分鐘級RTO的業務恢復能?持將運?在SmartX原?虛擬化ELF平臺的虛擬機整機備份到集群外部的備份存儲庫，并?持使?備份?件對虛擬機

業務災備保護–異構基礎架構融機構，SmartX提供由超融合系統和分布式存儲構建的容災資SmartX容災?可??案，將裸?屬、VMware資源池的?產Oracle數優異的RPO與可實現RPO為秒級，RTO達到秒到分鐘級（數據庫接管時降低站點之間?絡依賴，多個集群間數據相互復制，可在遠程站點?鍵恢復業務，滿?RPO≥15min的數據保護需

分布式架構、NVMe-oF接?協議和RDMA?絡技術，充分發XeM+功能構建的應?容災?案，以及數據庫通過?志同步?案，將虛擬化環境的?產應?和數據庫持續同步?容災端，形成冗余架優異的RPO與可實現RPO為秒級，RTOSmartX優異的RPO與可實現RPO為0，RTO為0SmartX容災?可??案，將?產Oracle和MySQL數據庫持續同步?優異的RPO與可實現RPO為秒級，RTO達到秒到分鐘級（數據庫接管時SmartXCDP優異的RPO與可實現RPO達到秒級，RTO通過CDP軟件對?產環境虛擬機進?整體保護，其標準操作步能有效控制CDP軟件對?產環境資源的消耗，通常的資源消耗被控制在5%以內。業務災備保護–超融合集群?，可最?程度保證業務服務的可?性。SmartX超融合內置的SmartXSmartX超融合提供復制與恢復服務，數據可在多個數據中?之延遲限制，需要關注業務RPO以及數據增量與傳輸帶寬的適配案不僅架構復雜且成本?昂。SmartX超融合?持跨數據中?的3節點集群，以及1個位于異地的物理或虛擬仲裁節點（最佳實踐）10Gb寬與低于5ms的?絡延時。SmartX超融合系統原??持雙活集群架構，?需第三?軟、硬極致的RPO與雙活架構可搭配應?的?可?集群架構實現RPO為0，RTO接近為0的容災效果。SmartXSmartX超融合系統以分布式塊存儲為基礎，融合虛擬化平臺構建的?體化架構，利?x86、ARMX超融合容災基礎架構，最?三節點起步，并可按需擴容，降低容災基礎架構的初始構建成本；對應更多?產環境的容災需求時，也可通過按需擴容優勢，逐步擴展容災基礎架構資

在傳統的數據中??絡中，普遍認為數據中??絡內部的流量是安全的，外部的流量是不安全的。因此，通常在?絡內、外部的邊界位置部署防?墻，對進、出流量（即南北向制等動作。這種在物理邊界設備上對流量進?安全分析的技隨著數據中?基礎架構向新?代云化轉型，數據中??絡流量從以前的南北向流量為主轉變為東?向流量為主，這樣的背景下，對云環境內部流量進?安全管控就變得尤為重要。?旦攻擊者沖破邊界防護，那么企業云內部的安全將受到嚴重威脅，攻擊者可以隨意攻擊云內的各個業務和服務。因此在云化的數據中?內部，需要針對內外部的流量做全?的防護，如果將企業云內部虛擬機間的流量全部繞?集中式防?墻，很難滿?數據中?靈活性和敏捷性的部署要求，容易形微分段可以提供???粒度更細的分組規則，對企業云環境內部虛擬機進?分組（標簽），從?對所有分組之間的

安全策略直接關聯在業務對象上，相?使?IP??的運維管理不改變物理?絡結構的前提下，實現應?業務的最后?公?保基于IP分段的訪問控制策略，看易?難。實現更精細粒度VM云化數據中?承載著不同業務部?的IT需求，?每個業務部?流量下發安全策略。策略將跟能的業務策略控制，限制攻擊?為在?絡內部橫向移動的能滿?并實現《等保2.0?絡安全

CPU：2*kunpeng920(5220)32Cores硬盤：2*960GIntelS45104*4TBSMTXOSv5.0.3（超融合軟件）CloudTowerv2.0（管理平?）恒?TA6（虛擬機v8（DB01/DB02基于標簽?名單訪問控制，以VM為對象代替傳統IP地址的策略控制，為受保護VM提供零信任安全基于“開啟/關閉”安全防護，驗證?絡安全策略可有利?Hypervisor虛擬機對象感知能?，結合虛擬化?絡，實現滿?并實現“等保2.0?絡安全等級保護要求”中安全計算環境軟件定義存儲（SoftwareDefinedStorage，SDS）是?種存儲技術。SDS的?的是將數據分布式存儲將數據分布存儲在多個標準PC服務器節點，通過在多節點之間進?數據復制來提?數據可?性和容錯能?。分布式存儲可利?軟件定義簡化存儲管理，降低復雜度，提?運維效SMTXZBS分布式存儲?案亮ZBS通過標準接?和插件的?式，ZBS結合NVMe-oF協議、?速?存儲性能，?撐?I/O負載型業務更?的架構擴展性。分布式存儲?身天然特性，橫向擴展可同時增加集群數據存儲容量和存儲性能（每個節點都可以作為數據接

SMTXZBS分布式存儲性能評估（iSCSIvsNVMe-SMTXZBS性能表現，以及SMTXZBS對于服務器硬件兼容性測試?案（某保險客戶基于相同的硬件條件，由3臺不同品牌型號服務器組成存儲集群，對接前端裸?屬服務器，分別通過iSCSI協議和NVMe-R6202*E5-8*32G8*32G8*32G?點，類似于集群存儲的控制更低的總體擁有成本。基于標準化的硬件構建，相較于傳統專有存儲設備，在設備采購和?常運維兩個層?的成本?較，分布式敏捷的架構。3建、快速交付和按需擴容，提?IT基礎架構的交付效率。

測試數據SMTXZBS掛載?塊磁盤給前端物理機，分別進?4K/8K/16K和256K性能驗證.4K隨機讀寫8K隨機讀寫256K順序讀寫通過對?iSCSI和NVMe-oF接?協議性能測試數據，SMTXZBS存儲性能在NVMe-oF接?協議下表現出更?的隨機和順儲功能的評測也是?常重要的評估指標，SMTXZBS在存儲管ZBS分布式存儲資源池建設（對接裸?屬和VMware）經過本次分布式存儲性能測試驗證，SMTXZBS持久化存儲，承載災備應?和Oracle數據庫系統等。SMTXZBS分布式存儲集群（3節點）共提供了230TB存儲裸CPU：2CPU：2*IntelXeonSilver4314（16Cores2.4GHz）DISK：24*MemblazeD65363.2TBNET：25GbEMellanoxCX5（存儲和接??絡）硬件環境（寧暢R620通過ContainerStorageInterface（CSI）驅動的?式愈發成為在這個背景下，某保險客戶構建了SMTXZBS分布式存儲平CSIDriver儲，使得容器化應?擺脫臨時性存儲限制，如Pod跨節點間漂SMTXZBSCSISMTXZBS分布式存儲集群（3節點）共提供了86TB存儲裸CPU：2*CPU：2*Hygon7360（24Cores2.2GHz）SSD：2*1.92TBS4620SATASSDHDD:12*2.4TB硬件環境（Nhh現?般，尤其是在?些?負載情況下。此外，當硬盤出現故障h會導致?段時間內的性能波動，最終導致了業務虛擬機性能也受到影響。所以客戶需要?套?性能、穩定的分布式存儲替代現有hCPU：2*IntelXeonSilver4214（12Cores2.2GHz）SSD：2*CPU：2*IntelXeonSilver4214（12Cores2.2GHz）SSD：2*IntelS46101.92TBHDD:9*4TBZBSvsCeph類友商?前主流的分布式存儲有兩?類技術路線，?種是以ZBS為代表的?研產品，另?種是基于開源產品構建（Ceph）實CASE1-測試?案（某?融客戶3擬化（VMware）平臺，通過iSCSI協議提供存儲卷。存儲節點硬件信息（Intel(R)Xeon(R)Gold5220CPU@1.6T*2IntelX5502x10GBase-TCASE1-測試數據CASE2-測試?案（某?融客戶了友商兩套分布式存儲集群，?套20節點HDD集群（配置16塊1.8TB磁盤）和?套5節點SSD全閃集群（每節點配置22塊960GB磁盤）。本次驗證?標，是驗證在?塊為什么僅驗證4K表現？因為對于?塊順序讀寫操作上，客戶的存儲節點硬件信息（服務器型號：H3CCASE2-測試數據5SmartX3圖中5P1V代表5節點存儲池，1個虛擬機性能壓測（3P1V同友商20節點集群與SmartX3節點集群?塊隨機性能對?。圖中20P6V代表20節點存儲池，6個虛擬機并?性能壓測（3P6V同理）通過對?兩組與Ceph類商業產品的性能測試數據，SMTXZBS并不敏感。?2代或3代的IntelSilver42.4GHz左右，節點內存配置128G，采?分層混閃或全閃存儲結構。SMTXZBS單節點?持128TB的裸存儲容量，但由于考慮到節在60TB左右。SMTXZBS?前最新的軟件版本已?持NVMe-oF接?協議，配更?的業務?作負載需求。NVMeoverTCP可以在不改變?國際局勢不確定性持續提升，在芯?、操作系統、虛擬化、存儲、?絡、數據庫等領域存在較為突出的技術依賴以及被動的技術限制，?融?業應樹?業應更加關注科技能?建SmartXSmartX超融合、分布式存儲、

作為承載信息系統運?的核?底座，?融機構的IT基礎設施?其中，數字化轉型要求ITIT僅需要采?新的CPU體系，整個硬件產品的從開發到穩定有成本居?不下。其中像FC交換機并沒有很好的國產化替

投?產出?法量化，不能有效?撐IT決策，IT的成本投?與資源使?趨勢?法形成可視化視圖，IT架構的可視、可除此以外，來?政策和信息安全的信創轉型要求IT基礎設施滿采?符合信創標準的CPU通過以上分析可以看到，傳統存儲不僅是IT基礎設施云化轉型SmartXSmartX由3節點組成超融合集群，在只有CPU芯?配置不同，其他硬Hygon72852.0GHz*2Kunpeng92052501.6TB*24KIOPS（3P1VIntel256KBW（3P1VIntel4K隨機讀/寫IOPS對?（3P3V驗證集群性能Intel256K順序讀/寫BW對?（3P3V驗證集群性能Intel4K隨機寫4K隨機寫延時256K順序寫256K順序寫延時基于SmartX超融合實現基礎架構信創轉型傳統集中存儲橫向擴展能?不?，形成孤島，資源?法池IT案例1某保險集團客戶作為第?期信創試點單位，累計部署近0個X超融合信創節點，基于海光芯?平臺構建基礎架構。承載業務范圍包括辦公管理（A、郵件），?般業務（內外部?站、綜合協同平臺、內控系統、外事管理、檔案管理、在線服務平臺、集團/產險/壽險相關業務系統），核?業務（?險管理）2某保險客戶同樣作為第?期信創試點單位，分別基于海光和鯤鵬XA為客戶?主研發，所以使?了改造?作量較?的海光芯?平臺來承載應?系統，?商業版的數據庫則使?了鯤鵬芯?平臺來承SmartX超融合基礎架構?撐保險客戶業務系統及相應數據實現分布式IT基礎架構轉型，對穩態和敏態業務應?實現實現IT資源使??式的云化升級，利?云平臺實現?云多了SmarX信創云基礎設施性能和穩定性，以及保險客戶信創轉Nutanix宣布中國市場?2023結合當前IT基礎架構的國產化2022年芯?制造商BroadcomVMware。雖然這項交易因接受反壟斷調查?屢遭推遲，不少正在使?VMware產品的企業依舊擔?，VMware品價格會在完成收購后出現增?，?產品和服務質量出現下滑。結合國內IT基礎設施信創轉型的背景，企業紛紛開始去VMware化，并積極尋求現有VMware產品的替代?案。SmartXSmartX在硬件服務器、操作系滿?國內客戶在國產化轉型需SmartX超融合?持集群異構，

某保險客戶全?驗證SmartX超融合并實現基礎架構逐步替代Nutanix在國內超融合市場格局對?中，SmartXNutanix上?分匹配。根據Gartner發布的《2019中國區超融合競爭格局》報告，SmartX和Nutanix均為獨?超融合?商（Pure-SmartXNutanixNutanix作為國際超融合市場的領導者，其功能和性能得到了?標準。SmartX通過多年的產品迭代，在功能、性能、可靠性以Nutanix?值得?提的是，根據IDC報告“中國軟件定義存儲（SDS）及超融合存儲（HCI）系統市場季度跟蹤報告，2021年第四季度2021年SmartX在中國的超融合軟件市場份額超過在?前SmartX統計的部分?融客戶清單中（采集數據來?38家已交付的?融客戶），其中有17家客戶同時使?了SmartX和Nutanix的超融合產品（?信創環境）。其中9家客戶使?SmartX超融合產品裝機量超過Nutanix，從?個視?證明，SmartX完全具備相匹敵的產品綜合能?。SmartX新?代基礎架構，在產眾多的落地案例?撐，實現對SmartX及時、專業和全?的服SmartX團隊的360度閉環服務體系。

在?融?業國產化?主可控的頂層戰略指導下，SmartX可作為全?替代Nutanix產品的最佳?案，其原因如下：Nutanix2401200Nutanix環境中移除4個Nutanix節點，依次部署Nutanix超融合（VMware）SmartX（KVM）SmartXNutanix驗證SmartX超融合平臺功能（虛擬機?命周期管理、快驗證SmartXv2v?具，遷移Nutanix平臺虛擬機到SmartX平臺，驗證遷移操作便利性、遷移速度等指標。遷移真實業務應?，在SmartX平臺?期運?，驗證穩定IntelE52699v44KIOPS（4P1V256KBW（4P1V4K隨機讀/寫IOPS對?（4P4V驗證集群性能256K順序讀/寫BW對?（4P4V驗證集群性能v2v使?SmartXV2V?具從Nutanix開發測試環境遷移虛擬機?SmartX平臺，同時遷移5個模板虛擬機（每個遷移速率約為120MB/s，5個虛擬機速率相加為600MB/s）。SmartXNutanix相類似的產品能?。在技術實現層?，雖然SmartX與?到的具體技術不甚相同，整體技術具有?定的相似性。但SmartX針對核?組件、存儲數據結構、I/O路徑和數據冗雜機制等進?了技術優化，在性能測試?例中表現出了?于Nutanix的性能。此外，SmartX?持更開放的硬件配置，能靈活滿??通過對SmartX超融合產品在功能、性能、可靠性、穩定性和跨平臺虛擬機遷移多個維度的測試驗證，SmartX超融合產品得到SmartX3SmartX過CloudTower管理平臺統?運維和管理。并完成?產業務系統的應?和數據庫MySQL、Redis等虛擬機遷移到SmartX超融合集群，其中典型的業務系統包括：信科：運維堡壘機、綜合巡檢管理平臺、災備管理系財險：財險增值管理系統、財險快速出單系統、客戶數某?融客戶對?驗證 SmartX超融合 VMwarevSAN超融合在相同硬件條件下，驗證SmartX超融合（VMware虛擬IntelGold5220R2.2GHz*2（12）IntelGold62463.3GHz*2（節點3）9604KIOPS（3P1V256KBW（3P1V4K隨機讀/寫IOPS對?（3P30V驗證集群性能256K順序讀/寫BW對?（3P30V驗證集群性能4K隨機讀/寫IOPS對?（3P30V驗證集群性能4K4K4KSmartXSmartX256K順序讀/寫BW對?（3P30V驗證集群性能256K寫256K讀SmartXSmartX雖然VMware在虛擬化領域中占據主導地位，但超融合架構是如存儲數據結構、I/O路徑、緩存機制等，SmartX和VMwarevSAN實現的機制有較?不同，導致在性能測試?例中SmartX結合當前IT基礎架構的國產化趨勢背景下，本章節通過兩條故是?種?向分析和報告的數據管理系統。通常，數據定期從事務系統、關系數據庫和其他來源流?數據倉庫，數據倉庫能夠集中并整合多個來源的?量數據。企業中的業務分析師、數據?程師、數據科學家和決策者通過商業智能?具、SQL客戶端和其他分析應?程序訪問數據，從中獲得寶貴的業務洞察，以改善決

e供數據加?和數據處理。隨著業務量和數據量的增?，上6同時，?產環境的數據倉庫還部署在IBM?型機上，雖然運?運維復雜度等問題，客戶希望進??機下移x86的可能性驗基于以上兩點原因，客戶希望使?SmartX超融合測試Oracle本次測試是為了驗證Oracle數據倉庫在超融合架構下的跑批性在數據量完全相同的情況下，對??產環境現有?案與基于SmartX超融合的Oracle數據倉庫跑批時間，?共進?3輪跑將DB2數據庫的數據，通過Informatica（ETL抽數?具）抽OracleOracleIBMAIX驗證環境數倉部署在RHEL4.8操作系統。基于客戶的測試?標和測試場景，Oracle數據倉庫在超融合架經過多輪測試驗證，SmartX超融合架構相?原?產架構的IBMOracle有明顯的性能提升，跑批時間可有效縮短36%。同時，驗證了Oracle數據倉庫從?機下移x86SmartX提?了資源利?率。Oracle數據倉庫跑批業務通常是在夜某財險客戶?前使?的Oracle數據倉庫數據量為3.9TB，運?在傳統架構上，底層使?的集中式存儲為EMCPowerStore1000T全閃存儲，通過16GB的FC?絡與前端的4路計算節SmartXOralce數據倉庫，并且還能進?步提升數倉的跑批效率，但是均衡的應?，對于當前??的Oracle數倉，存儲資源消耗較分離架構進?Oralce數倉跑批驗證的想法應運??。Oralce4、5、6SmartX存儲ZBS搭建的存算分離架構與當前運?在傳統架構下的跑批SmartXZBSZBSZBS通過對4、5、6?的數據進?跑批測試后，按照全部存儲過程計，測試環境（基于ZBS構建的存算分離架構）對?當前?產SmartX1、本次跑批數據8K寫IOPS最?值和256K順序讀最?值遠遠沒有達到SmartX基準數據的性能。2、說明本次測試IO通過本次對?測試可以看出，基于S構建的存算分離架構已經具備承載客戶現有數倉應?的能?，并且較當前的?產環境，在不同的統計維度上均有不同幅度的性能提升。客戶可以在不改變上層數倉應?的情況下，僅通過更換承載數倉基礎設施進?步提升效率、縮短跑批處理時間，進?帶來應?價值的提升。同S隨著容器化技術的迅速發展，企業應?的部署?式發?了?命性的變化。容器化不僅提供

?可靠性和?可?性。S分布式存儲系統的多副本數據保護和故障轉移機制使得即使某個節點發?故障或數?性能。ZBSSAN靈活橫向擴展，容量和性能線性增?。S分布式存儲系統具備?擴展性，通過添加更多的節點和存儲介質，可以實現橫向和縱向按需增加存儲容量，線性提?性能和容量，這種?平擴展的?式使得系統能夠靈活應對業架構靈活性和可維護性。S分布式存儲系統節點之間的數據分布和治理是軟件定義，提?了系統的可運維性。同時，分布式存儲系統還能夠提供各種數據管理功能，如數據備份和快照等，為?戶提供全?的數據保護了輕量級、可移植的部署單元，還在跨平臺、彈性伸縮以及開發與運維協作等??帶來了諸多優勢。然?，隨之?來的是對持久化存儲需求的不斷增?，?分布式存儲通過ContainerStorage決容器持久性存儲需求的?選

某保險集團客戶在?產和開發測試環境中分別部署了?套某CephCSIDriver針對現有問題進??例設計，驗證SMTXZBS通過CSIDriverSMTXZBSCSIDriver容器云平臺成功發布基于ZBSCSI動態創建PV的資源對象，包括DeploymentStatefulsetPVPVC將計算端Pod所在虛擬機的?卡Down掉10s左右后把?卡UP起PodPVCPodnodeAnodeB儲鏈接（iscsisession）是否有殘留，以及是否會產?blockdev--report進程nodeAiscsisessionnodeA和nodeB是否有blockdev--reportWorkPVCPodWork節點Work是否需要在StorageClassYaml?件中添加新擴容的Work節點地址授權PVfioDockerImage，創建PVC和SXFPVC掛載給PodPod2Pod12某CephSMTX測試環境SMTXZBSSmartXSMTXZBSCSIDriverTomcat、MySQL和ZK集群成功在線擴容PVCSmartXCSI當?卡UP起來后Pod中的PVCSmartX（iscsisession）是Pod鏈接會?動被CSI清理。并且不依賴blockdevcat/sys/xxx的?式查找塊設備信息nodeA（iscsinodeA和nodeB都沒有blockdev--reportSmartX授權?式對于?戶完全?感CSIPod不需要?動在StorageClassYamlWorker成功掛載PV，且不需要?動SmartXPod4K隨機讀/寫IOPS對?256K順序讀/寫BW對?4K12隨著互聯?的普及和數字化轉型的加速，?量的數據被?成和積累。傳統的數據處理?具更適?于結構化數據，?現代業務?成的數據越來越多地是半結構化或?結構化的，如?

通過本次測試，客戶原有環境中的?絡抖動影響PVC、存儲連接殘留和存儲授權復雜等問題，在SMTXZBS對接客戶容器云SMTXZBS4KCeph儲IOPS性能提升26倍；在256K順序寫場景下，相?某Ceph類分布式存儲帶寬性能提升2.8倍。SMTXZBS在4K隨機讀、4K隨機寫和256K順序寫場景下，P99Ceph類分布式存儲更好。SMTXZBS在?時間12?時4K隨機寫場景下性能表現穩定，且?論是IOPS還是延時表現都和2分鐘性能?乎持本、圖像、?頻和視頻等。?數據平臺的出現使得處理這些復雜數據變得更為容易。許多業務需要對數據進?實時分析以做出及時決策。傳統的數據處理系統?法滿?這種對實時性的需求，因此?數據平臺提供了更快速的數據處理和分析

某保險集團客戶因?產機房搬遷（測試環境搬遷過程中遇到事故）、設備?舊以及平臺存儲O性能存在瓶頸等原因，計劃在新機房使?新架構重新部署?數據平臺，因此客戶希望使?XS驗證SMTXZBS分別基于iSCSI和NVMeoverRDMA接?協HBase寫?HDFS場景分別從?產環境12臺計算節點和POC環境3臺計算節點中的HBase數據庫中，導出3個（共80GB）、14個（共1.5TB）相同數據表寫?到HDFS，記錄?時時間；HBase查詢場景PhoenixHBaseHBase寫?HDFS場景HBase查詢場景通過本次測試可以說明SMTXZBSHBase寫?HDFSHBase3個表導出場景：SmartX分布式存儲（NVMeoverRDMA接?協議）相??產物理機環境，導表時間縮短3.5SmartX分布式存儲（iSCSI接?協議），導表時間縮短2.4倍；overRDMA接?協議）相??產物理機環境，導表時間縮短3.1倍；監控分布式存儲的集群IO帶寬指標（最?寫2.1GB/s，最?讀340MB/s），離集群性能上限（寫GB/s，讀8.6GB/s）還有較?余量，所以如果按照?HBase??產物理機環境，查詢時間縮短3.5倍，相?SmartX分布式存儲（iSCSI接?協議），查詢時間縮短2.4倍。CXK保即將到期，計劃使?新的基礎架構來替換CX并承載上?運?的數據庫，包括投資、財務和監管報送等數據庫，因此客戶希望通過核?庫跑批場景來驗證新的基礎架構是否通過測試Oracle核?數據庫跑批場景，來驗證SmartX超融合SmartXOracleRAC11g產環境運?相同的10個批處理任務，每個任務分別跑3SmartXSmartXOracleRAC據庫的能?。并且核?數據庫跑批的存儲I/O壓?遠沒有達到SmartXSmartX3SmartX概 以保險?業數字化轉型為背ITSmartX利?HCI與?態CMP聯合，3節點，即可實現云資源池快

發展的必由之路。數字化轉型不僅僅是IT技術層?的轉型，更?，盡可能開放，以獲得業內最專業的?案組件，并逐軟件定義化：遵循軟件定義、分布式等理念和技術框架，構建?可靠、?性能、維護簡單、彈性擴展的資源敏捷?助化：實現資源線上?助交互申請，底層基礎架構平臺?動化快速構建、發布并交付到業務部?，為開管理統?化：通過統?視圖，實現IT基礎架構的可視、場景多樣化：升級后的基礎架構能夠兼顧穩態業務和敏公有云技術棧下移，基于互聯?企業的公有云產品私有化部署，采?全套互聯?企業的產品技術棧，具備并繼開源云平臺（包括通過開源技術封裝的商業公司），通k和軟件功能迭代提供技術保?需獨?部署和維護管理節建設成本低，架構按需擴展（投?），

某保險集團，部署節點超過100+，初期投資超過1000萬，客戶對平臺完全沒有運維能?，集群升級需要1個某省農信，部署節點超過?年，業務系統仍?法上線。產品對硬件兼容性差，常4~50產品功能模塊之間依賴?，需要搭配銷售，造成擴容成實施運維復雜，由于架構起步規模?，通常??個節點起步，系統部署調試通常需要按?交付。升級變更同樣需要較?的時間，客戶技術?員?法掌握。同時存在?實際業務?撐不符合預期，這些?云?論是產品化程度，還是客戶?身對云平臺的掌控能?都?法滿??產級別要求。最終云平臺?多淪為邊緣?產以及開發測試環境使?，?法持續有效?撐?產環境，與客戶之前