【正文】 案例 2 –醫(yī)療信息系統(tǒng)案例 了解客戶需求 ? Q7:數(shù)據(jù)擴(kuò)展性 ? 現(xiàn)有容量 2TB ? 3年內(nèi)增加到 3TB ? 如果有 PACS系統(tǒng)的整合或者 EMR系統(tǒng)的需求，可能會漲到 10TB以上 ? A7: 存儲必須快速實現(xiàn)容量的增加，不能影響業(yè)務(wù)的連續(xù)運(yùn)行 案例 2 –醫(yī)療信息系統(tǒng)案例 了解客戶需求 ? Q8: 數(shù)據(jù)訪問效率 ? 50%的查詢， 50%對數(shù)據(jù)修改 ? 平均操作響應(yīng)時間不能超過 5秒 ? ~100個用戶會對數(shù)據(jù)庫訪問 ? 存在業(yè)務(wù)高峰期的問題，早上 8:0010:00，下午 13:3015:00業(yè)務(wù)集中 ? A8： 必須采用 FC磁盤才能滿足客戶的高效能需求 案例 2 –醫(yī)療信息系統(tǒng)案例 了解客戶需求 ? Q9: 數(shù)據(jù)訪問模式 ?根據(jù) HIS平臺， C/S環(huán)境 ?采用 SQL Server架構(gòu) ?采用 SQL Server實現(xiàn)雙機(jī) Standby ? 本案例采用了 SQL Server數(shù)據(jù)庫，利用 SQL Server雙機(jī)互備提供高可用性 案例 2 –醫(yī)療信息系統(tǒng)案例 了解客戶需求 ? Q10: 數(shù)據(jù)安全訪問 ?SQL Server ? 雙機(jī) Standby方案 案例 2 –醫(yī)療信息系統(tǒng)案例 了解客戶需求 ? Q11:系統(tǒng)可靠性需求 ? 系統(tǒng)需要連續(xù)不斷運(yùn)行 ? 必須對病毒免疫 ? 必須支持較大用戶并發(fā) ? 必須支持超過 100個并發(fā)的用戶數(shù)量 ? 管理簡便 ? 采用小型機(jī)， Windows 案例 2 –醫(yī)療信息系統(tǒng)案例 了解客戶需求 ? Q12: 系統(tǒng)性能需求 ? 必須支持多達(dá) 3TB的數(shù)據(jù)訪問 ? 必須支持高達(dá) 100的并發(fā)用戶 ? 系統(tǒng)平均響應(yīng)時間小于 5秒 ? 存在業(yè)務(wù)高峰期的突發(fā)需求 A12: 高性能多 CPU小型機(jī) 案例 2 –醫(yī)療信息系統(tǒng)案例 了解客戶需求 ? Q13: 煙囪式？融合式？ ? 目前業(yè)務(wù)平臺單一 ? 業(yè)務(wù)未融合，資源要求簡單 ? 僅數(shù)據(jù)庫需求 ? Q13： 主機(jī)不采用資源共享模式，存儲采用共享模式，進(jìn)行存儲集中 客戶需求 Summary ? 從前面了解的需求，總結(jié)客戶的需求如下： ? 性能要求較高、現(xiàn)有 SAN環(huán)境 ? 數(shù)據(jù)量較大，現(xiàn)有數(shù)據(jù) 2TB， 3年內(nèi)達(dá)到 3TB，還會增加 ? 數(shù)據(jù)不能丟失，系統(tǒng)可靠性 % ? 主機(jī)系統(tǒng)數(shù)據(jù)安全備份 ? 用戶數(shù)據(jù)備份，每月全備份一次 3TB、每日增量備份 1GB、全備份時間不能超過 8小時、增量備份不超過 1小時、數(shù)據(jù)恢復(fù)時間不超過 12小時、要求自動、集中備份 ? 數(shù)據(jù)庫采用 SQL Server，雙機(jī)互備模式，要求支持 100以上并發(fā)用戶、平均響應(yīng)時間不超過 5秒、能夠支持高峰突發(fā)性業(yè)務(wù) ? 現(xiàn)有 IT管理力量薄弱，要求管理簡便，防病毒，安全性高，系統(tǒng)可靠。 案例 1 – 社保案例 了解客戶需求 ? Q7:數(shù)據(jù)擴(kuò)展性 ? 現(xiàn)有容量 20TB ? 3年內(nèi)增加到 30TB ? 如果政策改變，可能會漲到 50TB ? A7: 存儲必須快速實現(xiàn)容量的增加，不能影響業(yè)務(wù)的連續(xù)運(yùn)行 案例 1 – 社保案例 了解客戶需求 ? Q8: 數(shù)據(jù)訪問效率 ? 75%的查詢， 25%對數(shù)據(jù)修改 ? 平均操作響應(yīng)時間不能超過 5秒 ? ~100個用戶會對數(shù)據(jù)庫訪問 ? 晚上數(shù)據(jù)的報表需要較多的計算資源 ? A8： 必須采用 FC磁盤才能滿足客戶的高效能需求 案例 1 – 社保案例 了解客戶需求 ? Q9: 數(shù)據(jù)訪問模式 ?根據(jù)社保核心平臺， J2EE環(huán)境 ?采用 Oracle + Weblogic架構(gòu) ?采用 Oracle RAC實現(xiàn)并行處理 ? 本案例采用了 Oracle數(shù)據(jù)庫，利用 Oracle RAC提供多節(jié)點訪問和高性能 案例 1 – 社保案例 了解客戶需求 ? Q10: 數(shù)據(jù)安全訪問 ?Oracle RAC ?WebLogic Cluster ? HA方案 案例 1 – 社保案例 了解客戶需求 ? Q11:系統(tǒng)可靠性需求 ? 系統(tǒng)需要連續(xù)不斷運(yùn)行 ? 必須對病毒免疫 ? 必須支持大規(guī)模高并發(fā) ? 必須支持超過 500個并發(fā)的用戶數(shù)量 ? 采用小型機(jī)， Unix 案例 1 – 社保案例 了解客戶需求 ? Q12: 系統(tǒng)性能需求 ? 必須支持多達(dá) 30TB的數(shù)據(jù)訪問 ? 必須支持高達(dá) 500的并發(fā)用戶 ? 必須采用 HA的方式 ? 系統(tǒng)平均響應(yīng)時間小于 5秒 ? 報表時間必須小于 8小時 A12: 高性能多 CPU小型機(jī) 案例 1 – 社保案例 了解客戶需求 ? Q13: 煙囪式？融合式？ ? 業(yè)務(wù)平臺和報表平臺共享數(shù)據(jù)庫 ? 業(yè)務(wù)平臺白天比較忙，而報表相反 ? 希望能利用峰值差在不同系統(tǒng)之間調(diào)度計算資源 ? Q13： 動態(tài)資源調(diào)度技術(shù) 客戶需求 Summary ? 從前面了解的需求，總結(jié)客戶的需求如下： ? 性能要求較高、現(xiàn)有 SAN環(huán)境 ? 數(shù)據(jù)量大，現(xiàn)有數(shù)據(jù) 20TB， 3年內(nèi)達(dá)到 30TB，還會增加 ? 數(shù)據(jù)不能丟失，系統(tǒng)可靠性 % ? 主機(jī)系統(tǒng)數(shù)據(jù)安全備份 ? 用戶數(shù)據(jù)備份，每月全備份一次 30TB、每日增量備份 15GB、全備份時間不能超過 8小時、增量備份不超過 1小時、數(shù)據(jù)恢復(fù)時間不超過12小時、要求自動、集中備份 ? 數(shù)據(jù)庫采用 Oracle RAC、應(yīng)用服務(wù)器采用 WebLogic Cluster，要求支持500以上并發(fā)用戶、平均響應(yīng)時間不超過 5秒、報表時間不超過 8小時 ? 白天應(yīng)用系統(tǒng)忙、晚上數(shù)據(jù)庫有大量的批量作業(yè)要進(jìn)行處理，如報表、批量數(shù)據(jù)處理業(yè)務(wù) HP建議硬件設(shè)備 ? 根據(jù)用戶的需求，建議的 HP硬件配置方案： ?存儲陣列： EVA 8400 ?SAN交換機(jī)： 8/16 SAN Switch ?數(shù)據(jù)庫服務(wù)器： SuperDome、 HPUX、 ServiceGuard、ServiceGuard extension for RAC、 1個 nPar、 2個 vPar ?應(yīng)用服務(wù)器： SuperDome、 HPUX、 1個 nPar、 2個 vPar ?虛擬帶庫： VLS9000 ?磁帶庫： 245e ?備份軟件： DP ?備份管理服務(wù)器： DL380 ?存儲管理服務(wù)器： DL380 57 2023年 2月 3日星期五 案例 1 – 社保案例 社保解決方案應(yīng)用系統(tǒng)架構(gòu) 集群 案例 1 – 社保案例 社?？傮w架構(gòu) 社保數(shù)據(jù)庫服務(wù)器RAC1 SD 12*社保數(shù)據(jù)庫服務(wù)器RAC2 SD 12*存儲管理服務(wù)器 FC Switch 8/16 MC/Service Guard Extension for RAC 備份服務(wù)器