齊齊哈爾醫學院附屬第一醫院位於具有“鶴城”之稱的齊齊哈爾市,坐落于嫩江之畔,始建於1954年9月,是一所集醫療、教學、科研、預防、保健于一體的綜合性三級甲等醫院。醫院佔地面積13.3萬平方米,建築面積11.5萬平方米。開放床位1320張,在崗職工1101人,衛生專業技術人員894人。醫院現設臨床科室48個,醫技科室24個。
近年來,隨著齊齊哈爾醫學院附屬第一醫院資訊化水準的迅速發展,醫院的資訊系統越來越多,甚至達到了上百個。醫院基於對未來醫院“十四五”資訊化的總體考慮,決定引入整合平臺實現醫院資訊系統的統一整合和交互,建立和完善以電子病歷為核心的醫院資訊系統。
齊齊哈爾醫學院附屬第一醫院--東院區(圖片來自醫院官網)
齊齊哈爾醫學院附屬第一醫院根據目前自身的資訊化建設現狀以及對未來的發展需求,針對整合平臺的建設提出了詳細的建設目標和要求:
1.穩定承載現有業務
建設高可靠高穩定的醫院資訊整合平臺,保障各科室數據、應用之間的高效交互,併為醫院後續的智慧應用建設提供穩定的底層平臺,發揮醫院數據樞紐的重要作用。
2.靈活滿足未來業務要求
醫院未來將依託整合平臺開展輔助決策,從而使醫院醫療服務工作達到理想狀態:就醫流程最優化、醫療品質最佳化、工作效率最高化、病歷實現電子化、決策實現科學化、辦公實現自動化、網路實現區域化、軟體實現標準化。因此要求底層承載平臺具備延展性與相容性,能夠承載後續的相關應用。
3.業務容災要求
新版互聯互通測評要求明確提出關於容災備份能力、容災恢復時間(四級甲等要求四小時內)、使用虛擬化或雲計算技術等多維度要求。因此本次建設方案需要同步建設整合平臺的容災平臺,滿足對應的容災恢復時間要求。
深信服超融合,為整合平臺打造穩定運作、統一管理的平臺底座
深信服根據醫院業務的整體發展需求,對醫院底層IT架構進行統一規劃,構建符合整合平臺業務與互聯互通成熟度合規性需求的整體架構。首先,在主機房採用9台深信服超融合一體機,承載醫院資訊整合平臺與相關應用,為醫院各個科室應用之間的互聯互通提供穩定、高效、敏捷的底層IT平臺;另外,災備機房採用5台深信服超融合一體機為主機房整合平臺提供容災環境,確保數據不丟失、業務不中斷。
齊齊哈爾醫學院附屬第一醫院實測技術參數的展示與解讀
醫院整合平臺由杭州聯眾負責整體建設,CDR部分採用Oracle Rac數據庫,底層採用深信服超融合架構承載,本次實測採用Oracle自帶的AWR數據庫報告對實際運作承載效果做對應分析。
(説明:AWR報告是Oracle 10g下提供的一種性能收集和分析工具,它能提供一個時間段內整個系統資源使用情況的報告,通過這個報告可以了解系統的整體運作情況,類似于個人體檢報告。)
測試方案:
數據庫版本:Oracle RAC 19.0.0(19C);
報告時間:上午9:00-11:00,屬於業務高峰期,選取時間比較適合;
數據庫配置:24個核心CPU,Oracle建議每個Core有1-10個會話,也就是説最好有24-240個會話能保證有比較好的性能,這裡有2000+;
快照監控時間:本次為2小時。
1.實時性能測試數據
①. Buffer Nowait 100%:説明在從記憶體取數據的時候,等待時間為0;
②. Buffer Hit 100%:説明從記憶體取數據的時候,buffer的全程能夠從記憶體中讀取;
③. Library Hit 95.9%:説明sql在Shared Pool的命中率,最佳值是100%;
④. Parse CPU to Parse Elapsd 90.44%;説明在解析sql語句過程中,cpu佔整個的解析時間比例,期望值是100%,説明沒有産生等待;
⑤. Redo NoWait 100%:説明在産生日誌的時候,沒有産生等待,期望值是100%;
⑥. Latch Hit 99.98%:説明latch的命中率,期望值是100%,latch類似鎖,是一種記憶體鎖,但只會産生等待,不會産生阻塞,和lock還是有區別的,latch是在併發的情況下産生的;
⑦. Non-Parse CPU 76.77%:説明非解析cpu的比例,越高越好,用100減去這個比例,可以看出解析sql所花費的cpu,100-76.77=23.23,説明花費在解析SQL上的cpu較高。
數據解讀
1.測試數據顯示,Oracle數據庫整體性能較為穩定,暫存命中率、latch命中率、記憶體等待等數據都大於90%;
2. CPU在解析SQL上花費的時間較多,SQL語句解析相比較而言耗費了一定性能。
2.業務負載測試數據
①.DB time per second 0.6:是每秒的CPU time(即下面的DB CPU)+ wait time(不包括後臺進程消耗的時間);
②.DB CPUs per second 0.5:該示例是0.5個,而共有24個core,説明24個CPU,每秒鐘平均才使用0.5個,目前CPU整體較為空閒;
③.DB time Per Second - DB CPU Per Second為0.1:即是每秒的等待時間,目前該數值較低,説明CPU等待時間短,有能力應對醫院後續整合平臺上線更多業務;
④.Logons 5.1:表示每秒/每事務登錄的次數;
⑤.Har parses(SQL) 12.8:硬解析。硬解析低説明SQL代碼重用率高,每秒最好低於20;
⑥.Rollbacks 0.1:每秒事務的回滾數,回滾率低説明數據庫無效操作少,對性能消耗更小,該數值最好低於2;
⑦.Transactions 7.2:每秒事務數,反映數據庫任務繁重與否。
數據解讀
1.數據庫負載壓力較小,運作平穩;
2. CPU等待時間、處理時間較短,CPU壓力較小;
3.每秒事務數目前還不高,因為當下醫院處於開始啟用整合平臺的階段,後續壓力更大的情況下,也有較好的冗余保障;
4.回滾、硬解析時間短,數據整體的無效操作與SQL的代碼重用率較好,數據庫整體運作平穩、架構高效。
通過以上關鍵測試數據,可得出以下結論:
1.超融合能夠為醫院整合平臺提供穩定支撐:從上述數據庫性能報告上可以看出,Oracle Rac在超融合上承載穩定、性能富餘;針對醫院後續整合平臺串聯繫統增多、數據量逐步增加的情況,深信服超融合也能遊刃有餘地提供穩定的底層支撐。
2.超融合滿足醫院一體化容災建設需求:醫院整合平臺基於深信服超融合平臺,直接升級構築容災平臺與CDP數據備份,從而實現主備數中心的統一管理,確保RTO、RPO 點30分鐘,滿足互聯互通四甲對醫院數據災備的相關要求。
2019年深信服入圍Gartner全球超融合基礎設施魔力象限,並在2020年和2021年連續上榜Gartner全球超融合基礎設施軟體魔力象限,是中國地區唯一全棧自研入圍的服務商。至今,深信服基於高可靠、高性能、靈活彈性的超融合架構,在醫療行業已幫助超過1000家用戶實現核心業務上雲,未來超融合也會成為承載更多醫院整合平臺的穩固底座。