【文章內(nèi)容簡介】 5000 ~250 MB/s ~34w 多層式固態(tài)硬盤 SSD ~ 1000 ~150MB/s ~12w 15000轉(zhuǎn)光纖硬盤 ~6ms ~180 ~100MB/s ~15w 25 2023年 2月 3日星期五 近線 FATA磁盤 不常訪問的數(shù)據(jù)、快速恢復、備份到磁盤 … 在線 FC磁盤 活動數(shù)據(jù)、本地和遠程鏡像、即時恢復 … 數(shù)據(jù)生命周期 – 分層存儲 固態(tài)硬盤 SSD IO密集型應用 … 26 2023年 2月 3日星期五 數(shù)據(jù)訪問層的需求 ? 數(shù)據(jù)訪問模式 ? 數(shù)據(jù)訪問安全 ? 系統(tǒng)可靠性要求 ? 系統(tǒng)性能需求 ? 系統(tǒng)備份與恢復 ? 資源共享 27 2023年 2月 3日星期五 Q9: 數(shù)據(jù)訪問模式 ? 數(shù)據(jù)庫 ?Oracle、 SQL Server、 DB Sybase、 … ? 文件服務 ?NFS、 CIFS ?NAS 28 2023年 2月 3日星期五 Q10: 數(shù)據(jù)安全訪問 ? 提供高可用，多節(jié)點的訪問 ?如 Oracle RAC，可以選擇 ServiceGuard+ServiceGuard extension for RAC ? 雙機 Standby ?互備模式 ? 應用容災（涉及流程、切換、演練、人員等） 29 2023年 2月 3日星期五 Q11:系統(tǒng)可靠性需求 ? 非計劃宕機時間 ? 防病毒與安全 ? 內(nèi)部安全機制 30 2023年 2月 3日星期五 小機？ PC服務器？ ?安全性更高， PC Server上的 OS安全性相對較低，而且病毒、 bug等更嚴重 ?擴展性更高，如果業(yè)務增長較快必須移植到小型機 ?穩(wěn)定性更高，小型機 %，而 PC Server一般%，停機時間分別為 5分鐘和 52分鐘 ?可靠性更高 ?硬件上更多的可靠性技術（如 zx2的雙芯片備件、IO故障隔離、 CPU故障隔離） ?集群技術更成熟 31 2023年 2月 3日星期五 Q12: 系統(tǒng)性能需求 ? 性能考慮指標 ? 并發(fā)用戶數(shù) ? 平均響應時間 ? 業(yè)務復雜程度 ? 一般情況下，一個 CPU Core支持 2050并發(fā)用戶數(shù) ? 小型機下： CPU Core/Memory = 1:2 或者 1:4 ? PC機下： CPU Core/Memory = 1:1 或者 1:2 32 2023年 2月 3日星期五 Q13: 煙囪式？融合式？ ? 單一應用 /多個應用 ? 能利用應用峰值的錯峰特性？ ? 充分利用虛擬化技術實現(xiàn)資源的共享 ?硬件分區(qū)、軟件分區(qū)、虛擬機、資源動態(tài)調(diào)度技術 ?虛擬連接 VC、刀片技術 33 2023年 2月 3日星期五 應用層的需求 ? 中間件選擇（應用架構） ? 應用訪問安全 ? 系統(tǒng)可靠性 ? 系統(tǒng)性能需求 ? 系統(tǒng)備份與恢復 ? 資源共享 34 2023年 2月 3日星期五 中間件選擇 ? C/S 架構 ?無中間件平臺 ? 多層架構 ?J2EE架構，如 WebLogic， WebSphere， JBoss ?.NET架構 ?Transaction，如 TUXEDO、 CICS ?需要有中間件服務器支撐 35 2023年 2月 3日星期五 應用訪問安全 ? 應用服務器 Cluster ?應用服務器本身就有集群的能力，如 WebLogic、WebSpere、 JBoss等 ?有別于數(shù)據(jù)庫中的 HA和 Standby 36 2023年 2月 3日星期五 系統(tǒng)性能需求 ? 根據(jù)系統(tǒng)的并發(fā)用戶數(shù)來選擇服務器 ? 一般情況下，一個 CPU Core支持 50100并發(fā)用戶數(shù) ? 小型機下： CPU Core/Memory = 1:2 或者 1:4 ? PC機下： CPU Core/Memory = 1:1 或者 1:2 37 2023年 2月 3日星期五 案例分享 ? 某省社保案例 ? 醫(yī)療信息系統(tǒng)案例 38 2023年 2月 3日星期五 案例 1 – 社保案例 社保 IT部門面臨挑戰(zhàn) ? 業(yè)務復雜、影響面廣 ?養(yǎng)老、醫(yī)療、失業(yè)、工傷、生育 ? 政策、流程變更頻繁 ? 參保機構 /人員增加，系統(tǒng)不能滿足業(yè)務需要 ?白天，參保機構辦理停保、續(xù)保業(yè)務多，應用服務器很忙，客戶等待時間很長。（晚上較閑） ?晚上，批量處理參保機構信息，數(shù)據(jù)庫服務器忙，有時在第二天上班前不能處理完畢。（白天較閑） ? 信息化建設正興起，系統(tǒng)維護力量相對薄弱 案例 1 – 社保案例 了解客戶需求 ? Q1: 客戶存儲環(huán)境？ 客戶現(xiàn)有環(huán)境和計劃采用的技術 ? 結(jié)合用戶現(xiàn)有技術環(huán)境，選擇合適的存儲環(huán)境 ? 客戶對性能要求較高 ? 客戶現(xiàn)有 SAN 存儲環(huán)境 ? A1: FC SAN 案例 1 – 社保案例 了解客戶需求 ? Q2: 客戶數(shù)據(jù)容量？ 現(xiàn)有數(shù)據(jù)容量和發(fā)展需求 ? 800萬參保用戶、 48萬參保單位為例 ? 保留五年的數(shù)據(jù)在一級存儲 ? 存儲需求 30TB ? 數(shù)據(jù)冗余 , RAID 5 ? 陣列裸容量 50TB ? 隨著農(nóng)村醫(yī)療和區(qū)域醫(yī)療的加入，數(shù)據(jù)還會增加 ? A2: 需要 50TB存儲容量，并提供容量增加的能力 案例 1 – 社保案例 了解客戶需求 ? Q3: 數(shù)據(jù)安全的保證 在線一份數(shù)據(jù)還是兩份？單存儲？ ?數(shù)據(jù)量大，難以保存兩份數(shù)據(jù) ?內(nèi)置 RAID技術可以滿足數(shù)據(jù)的安全需求 ?需要存儲陣列提供企業(yè)級的安全級別， % ?在第一期不考慮容災的問題 ? A3: 企業(yè)級存儲的內(nèi)置 RAID實現(xiàn)數(shù)據(jù)安全保護 案例 1 – 社保案例 了解客戶需求 ? Q3: 數(shù)據(jù)安全的保證 在線一份數(shù)據(jù)還是兩份？雙存儲？ ? 利用企業(yè)存儲陣列的 RAID技術 ? 不使用兩份或者雙存儲 ? 雙存儲的容災解決方案將在后期考慮 ? A3: 企業(yè)級磁盤陣列 案例 1 – 社保案例 了解客戶需求 ? Q4: 數(shù)據(jù)安全 – 備份 磁帶機 Tape Driver ? 數(shù)據(jù)需要備份，以保證數(shù)據(jù)的安全 ? 需要利用磁帶來保證具有數(shù)據(jù)的多個版本 ? 除了數(shù)據(jù)之外，主機的操作環(huán)境也需要備份 ? 全備份數(shù)據(jù)量 ～ 30TB ? 日增加數(shù)據(jù)量 ～ 15GB ? 磁帶機只能用于主機系統(tǒng)的數(shù)據(jù)備份，不能用于數(shù)據(jù) 案例 1 – 社保案例 了解客戶需求 ? Q5: 數(shù)據(jù)安全 – 備份 磁帶庫 Tape Library ? 數(shù)據(jù)容量 30TB ? 每月完全備份一次 ~30TB ? 每天增量備份 ~16GB ? 多個備份任務要