齊齊哈爾醫學院附屬第一醫院位於具有「鶴城」之稱的齊齊哈爾市，坐落於嫩江之畔，始建於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的代碼重用率較好，數據庫整體運行平穩、架構高效。
通過以上關鍵測試數據，可得出以下結論：
超融合能夠為醫院集成平台提供穩定支撐：從上述數據庫性能報告上可以看出，Oracle Rac在超融合上承載穩定、性能富餘；針對醫院後續集成平台串聯繫統增多、數據量逐步增加的情況，深信服超融合也能遊刃有餘地提供穩定的底層支撐。
超融合滿足醫院一體化容災建設需求：醫院集成平台基於深信服超融合平台，直接升級構築容災平台與CDP數據備份，從而實現主備數中心的統一管理，確保RTO、RPO ≤30分鐘，滿足互聯互通四甲對醫院數據災備的相關要求。
2019年深信服入圍Gartner全球超融合基礎設施魔力象限，並在2020年和2021年連續上榜Gartner全球超融合基礎設施軟件魔力象限，是中國地區唯一全棧自研入圍的服務商。至今，深信服基於高可靠、高性能、靈活彈性的超融合架構，在醫療行業已幫助超過1000家用戶實現核心業務上雲，未來超融合也會成為承載更多醫院集成平台的穩固底座。
留言列表