云計(jì)算資源需求分析報(bào)告和規(guī)劃

1、標(biāo)準(zhǔn)1.1.1.1 云計(jì)算資源需求分析與規(guī)劃1.1.1.1.1 數(shù)據(jù)中心服務(wù)器部署基本要求本項(xiàng)目關(guān)鍵業(yè)務(wù)數(shù)據(jù)庫(kù)、數(shù)據(jù)倉(cāng)庫(kù)采用物理服務(wù)器獨(dú)立部署（集群 + 同城雙 活），應(yīng)用和管理類(lèi)服務(wù)器采用虛擬機(jī)部署（同城雙活） 。1.1.1.1.2 應(yīng)用服務(wù)器采用虛擬化方案采用虛擬化技術(shù)是實(shí)現(xiàn)云計(jì)算的基礎(chǔ)。 通過(guò)為客戶提供服務(wù)器整合和數(shù)量控 制、業(yè)務(wù)連續(xù)性、測(cè)試 / 開(kāi)發(fā)自動(dòng)化、企業(yè)臺(tái)式機(jī)管理等解決方案，從而實(shí)現(xiàn)降 低成本、提高響應(yīng)速度、實(shí)現(xiàn)零停機(jī)、災(zāi)難快速恢復(fù)等系列好處。通過(guò)虛擬架構(gòu) 整合服務(wù)器，可以控制 x86 服務(wù)器的蔓延，在一臺(tái)服務(wù)器上運(yùn)行多個(gè)操作系統(tǒng) 和應(yīng)用，并使新的硬件支持老的應(yīng)用， 數(shù)據(jù)中心撤

2、退舊的硬件。 虛擬基礎(chǔ)架構(gòu)使 企業(yè)能夠通過(guò)提高效率、增加靈活性和加快響應(yīng)速度而降低 IT 成本。管理一個(gè) 虛擬基礎(chǔ)架構(gòu)使 IT 能夠快速將資源和業(yè)務(wù)需要連結(jié)起來(lái)，并對(duì)其進(jìn)行管理。虛 擬基礎(chǔ)架構(gòu)可以使 x86 服務(wù)器的利用率從現(xiàn)在的 5-15% 提高到 60-80% ，并且 在數(shù)十秒的時(shí)間完成新應(yīng)用程序的資源調(diào)配， 而不需要幾天時(shí)間。 請(qǐng)求響應(yīng)時(shí)間 也改為以分鐘計(jì)算。在維護(hù)上，可以實(shí)現(xiàn)零停機(jī)硬件維護(hù)， 不需要等待維護(hù)窗口。文案標(biāo)準(zhǔn)服務(wù)器虛擬化是計(jì)算機(jī)資源邏輯組的過(guò)程， 這種資源的新虛擬視圖并不受實(shí) 現(xiàn)，地理位置或底層資源的物理配置的限制。 這種邏輯視圖對(duì)信息基礎(chǔ)設(shè)施有深 遠(yuǎn)的影響。服務(wù)器虛擬化帶

3、來(lái)的益處： 虛擬化技術(shù)可借助信息基礎(chǔ)設(shè)施更好地提供服務(wù)，從而幫助客戶節(jié)省資金。 與傳統(tǒng)的物理服務(wù)器部署方式相比，虛擬化所帶來(lái)的一些優(yōu)勢(shì)包括：? 能夠迅速保存、復(fù)制和供應(yīng)虛擬機(jī)，從而實(shí)現(xiàn)零停機(jī)時(shí)間維護(hù)并支持全 新的“ go live (實(shí)時(shí)化)”方案；? 動(dòng)態(tài)共享服務(wù)器平臺(tái)中的閑置資源，從而在消除煙囪式( stovepipe ) 部署的同時(shí)，進(jìn)一步提高性能和利用率；與此同時(shí)也能為應(yīng)用提供一個(gè) 隔離性的操作環(huán)境；? 可以實(shí)現(xiàn)更高的技術(shù)標(biāo)準(zhǔn)化水平和流通率，從而降低運(yùn)營(yíng)和維護(hù)成本；? 可在虛擬服務(wù)器組件發(fā)生故障時(shí)進(jìn)行無(wú)縫故障切換， 從而提高系統(tǒng)可用 性；? 降低復(fù)雜性，從而改進(jìn)邏輯和物理災(zāi)難恢復(fù)。服務(wù)

4、器虛擬化的軟件平臺(tái)選型原則在服務(wù)器虛擬化的軟件平臺(tái)方面， 主流的軟件提供商均提供了所有軟件廠商文案標(biāo)準(zhǔn)具有管理 CPU、存、網(wǎng)絡(luò)和硬盤(pán)資源的能力的服務(wù)器虛擬化軟件，這些軟件都 同時(shí)支持 Windows 與 Linux 操作環(huán)境。 目前，服務(wù)器虛擬化軟件分為商用軟 件和開(kāi)源軟件， 這些軟件都提供了對(duì)于服務(wù)器虛擬化硬件平臺(tái)的支持， 然而之間 存在細(xì)微的差別。 此外不同的虛擬化軟件的軟件架構(gòu)之間的差異較大， 不同平臺(tái) 上的虛擬機(jī)并不能很好實(shí)現(xiàn)相互之間的兼容或遷移。在服務(wù)器虛擬化的軟件平臺(tái)選擇中，應(yīng)重點(diǎn)考慮以下幾點(diǎn)：? 系統(tǒng)穩(wěn)定性和可擴(kuò)展性? 遷移的便利性，包括從物理服務(wù)器向虛擬機(jī)的遷移? 對(duì)于虛擬化

5、硬件平臺(tái)的支持? 良好的兼容性服務(wù)器虛擬化的硬件平臺(tái)選型原則 為服務(wù)器虛擬化選擇適當(dāng)?shù)挠布脚_(tái)正如選擇適當(dāng)?shù)奶摂M化軟件一樣重要 為了做出正確的選擇，必須考慮到以下因素：? 優(yōu)越的性能：服務(wù)器虛擬化的主要目的是更加充分的利用資源。在單臺(tái) 服務(wù)器上增加的工作負(fù)載需要更高的系統(tǒng)性能， 以保持所需的服務(wù)等級(jí) 和應(yīng)用響應(yīng)時(shí)間。目前廣泛采用的多核處理器架構(gòu)，以及對(duì)多核處理器 架構(gòu)提供支持以充分利用其性能和能力的系統(tǒng)， 可以進(jìn)一步提高服務(wù)器 的性能和吞吐率。在服務(wù)器性能需求方面，除了要考慮在非虛擬化模式 下運(yùn)行工作負(fù)載所需的性能之外，還需要考慮運(yùn)行虛擬機(jī)（ VM ）所需 的額外資源。硬件系統(tǒng)中的處理器與芯片

6、組所包含的硬件輔助特性，可 以在最大限度降低這一開(kāi)銷(xiāo)方面發(fā)揮作用。能效與空間： 在成本或物理限制影響最終用戶正常工作的能力的情況下，文案標(biāo)準(zhǔn)例如，當(dāng)成本超出預(yù)算，或功耗要求超出可用資源時(shí)，功耗與散熱問(wèn)題 最為明顯。當(dāng)不斷擴(kuò)展的 IT 占用空間導(dǎo)致數(shù)據(jù)中心或 IT 空間擴(kuò)建時(shí)， 占地空間就會(huì)成為一個(gè)大問(wèn)題。 虛擬化與整合有助于減少硬件占地空間 和能源利用。更高能效的系統(tǒng)能夠進(jìn)一步降低功耗要求，從而節(jié)省能源 和降低運(yùn)營(yíng)成本。功耗要求較低和 / 或性能功耗比較高的系統(tǒng)可幫助 IT 人員有效控制能源和空間要求。? 總擁有成本（ TCO）/投資回報(bào)（ ROI ）：不斷攀升的運(yùn)營(yíng)成本使資源與 資本從旨在推

7、動(dòng)創(chuàng)新和提高 IT 價(jià)值的計(jì)劃中抽離了出來(lái)。使用虛擬化 環(huán)境將可以提高系統(tǒng)利用率，降低功耗與散熱要求，減少空間要求，簡(jiǎn) 化運(yùn)營(yíng)和降低系統(tǒng)管理要求。? 優(yōu)化的平臺(tái)特性： 組件與系統(tǒng)廠商將不斷推出多種專(zhuān)為虛擬化而優(yōu)化的 特性。例如，主流的硬件廠商均為處理器增添了虛擬化能力，也有針對(duì) 大量 I/O 、網(wǎng)絡(luò)處理需求的平臺(tái)虛擬化特性。這些能力既能簡(jiǎn)化強(qiáng)大虛 擬化軟件的設(shè)計(jì)， 又能降低在虛擬化環(huán)境中運(yùn)行應(yīng)用通常所需的性能開(kāi) 銷(xiāo)。對(duì)于 EHRS 上的大量文件處理， I/O 虛擬化的優(yōu)化可進(jìn)一步提升信 息交換平臺(tái)的處理與擴(kuò)展能力。? 良好的廠商協(xié)作：通過(guò)著眼于當(dāng)前全行業(yè)圍的協(xié)作，我們將能夠更好地 了解虛擬化的

8、特征。鑒于虛擬化涉及多個(gè)層次上的軟硬件組件，系統(tǒng)廠 商、操作系統(tǒng)與應(yīng)用廠商以及虛擬化廠商需要攜手合作，共同制定出可 行的解決方案。目前，多家行業(yè)合作伙伴正在全新平臺(tái)上針對(duì)虛擬化進(jìn) 行優(yōu)化。? 良好的兼容性： 保持各代平臺(tái)之間的兼容性是未來(lái)系統(tǒng)的一個(gè)重要特性。文案標(biāo)準(zhǔn)將 VM 從一臺(tái)服務(wù)器遷移到另一臺(tái)服務(wù)器上需要考慮架構(gòu)問(wèn)題，這樣IT 部門(mén)無(wú)需創(chuàng)建虛擬資源島( islands of virtual resource )，但卻可以 真正發(fā)揮出基礎(chǔ)設(shè)施的最大靈活性。對(duì)虛擬機(jī)安全的考慮虛擬化使用戶獲得在效率、 成本方面的顯著收益 ,以及在數(shù)據(jù)中心更具環(huán)保、 靈活的擴(kuò)展性和減少實(shí)施時(shí)間方面的附加價(jià)值。

9、數(shù)據(jù)中心的虛擬系統(tǒng)面臨許多與 物理服務(wù)器相同的安全挑戰(zhàn)，并且還有自身的一些特點(diǎn)，如果不解決這些問(wèn)題， 安全最終將抵消虛擬化的優(yōu)勢(shì)。 尤其在虛擬化體系結(jié)構(gòu)將從根本上改變關(guān)鍵業(yè)務(wù) 應(yīng)用，包括設(shè)計(jì)、 部署和管理的情況下， 用戶需要考慮哪種安全機(jī)制最適合保護(hù) 這些虛擬服務(wù)器。傳統(tǒng)環(huán)境下的網(wǎng)絡(luò)安全拓?fù)鋱D， 在網(wǎng)絡(luò)出口處部署有防火墻， 防毒墻， 上網(wǎng) 行為管理等安全設(shè)備， 用來(lái)隔離外網(wǎng)， 過(guò)濾來(lái)自外網(wǎng)的惡意程序， 規(guī)網(wǎng)用戶的上 網(wǎng)行為，同時(shí)在 DMZ 區(qū)使用防火墻隔離， 部署 IDS 監(jiān)控對(duì)服務(wù)器的非法訪問(wèn)行 為，在服務(wù)器上部署防病毒軟件，保護(hù)核心服務(wù)器的安全運(yùn)行。根據(jù)傳統(tǒng)的安全設(shè)計(jì)模型， 需要在每個(gè)操作

10、系統(tǒng)中安裝防毒軟件， 在網(wǎng)絡(luò)層部署入防火墻、侵檢測(cè)或入侵防御系統(tǒng)，但是在這種在傳統(tǒng)方式下合理的設(shè)計(jì)，文案標(biāo)準(zhǔn)在虛擬環(huán)境下會(huì)面臨一些新的問(wèn)題：未激活的虛擬機(jī) ，物理機(jī)下關(guān)閉計(jì)算機(jī)后 CPU停止運(yùn)行， 網(wǎng)絡(luò)關(guān)閉， 理論上 不會(huì)有數(shù)據(jù)的交互，操作系統(tǒng)也就不存在被感染的可能；但是在虛擬環(huán)境下， CPU，網(wǎng)絡(luò)，底層的 ESX都在工作中，關(guān)閉的操作系統(tǒng)類(lèi)似于物理環(huán)境下的一個(gè) 應(yīng)用程序，盡管這個(gè)“應(yīng)用程序”沒(méi)有運(yùn)行，但仍然有被病毒感染的可能；資源的沖突 ，防毒軟件在啟用預(yù)設(shè)掃描后， 當(dāng)?shù)搅酥付〞r(shí)間， 會(huì)同時(shí)進(jìn)行文 件掃描的動(dòng)作， 這個(gè)時(shí)候防毒軟件對(duì) CPU和存的占用急劇增加， 當(dāng)系統(tǒng)資源被耗 盡的時(shí)候就會(huì)導(dǎo)

11、致服務(wù)器 down 機(jī)；管理復(fù)雜度 ，由于虛擬化的便利性， 系統(tǒng)管理員可以非常方便的根據(jù)模板生 成新的系統(tǒng)， 這些新系統(tǒng)要打補(bǔ)丁， 進(jìn)行病毒代碼的更新， 也會(huì)增加安全管理的 復(fù)雜度；虛擬化環(huán)境的動(dòng)態(tài)特性面臨入侵檢測(cè) /防御系統(tǒng)( IDS/IPS )的新挑戰(zhàn)。基于 網(wǎng)絡(luò)的IDS/IPS ，也無(wú)法監(jiān)測(cè)到同一臺(tái) ESX服務(wù)器上的虛擬機(jī)之間的通訊；由于 虛擬機(jī)能夠迅速地恢復(fù)到之前的狀態(tài)，利用 VMware VMotion ? 易于在物理服 務(wù)器之間移動(dòng)，所以難以獲得并維持整體一致的安全性。所以虛擬化已經(jīng)使 “網(wǎng)絡(luò)邊界去除” 的挑戰(zhàn)更加明顯， 虛擬化對(duì)于安全的需 求也更加迫切。文案標(biāo)準(zhǔn)包括其存、狀態(tài)和網(wǎng)

12、絡(luò)通信流量等。 因?yàn)樵诓桓奶摂M網(wǎng)絡(luò)配置的情況下， 服務(wù)器部的全部網(wǎng)絡(luò)通信流量是可見(jiàn)的。 包括防病毒、 防火墻、 IDS/IPS 和系統(tǒng)完整性監(jiān)控等在 的安全功能均可以應(yīng)用于安全虛擬機(jī)中1.1.1.1.3 數(shù)據(jù)庫(kù)服務(wù)器性能需求分析區(qū)域衛(wèi)生信息系統(tǒng)覆蓋面廣、 業(yè)務(wù)極其復(fù)雜，各業(yè)務(wù)子系統(tǒng)之間交叉非常多， 因此很難通過(guò)搭建業(yè)務(wù)模型通過(guò)壓力測(cè)試來(lái)進(jìn)行系統(tǒng)性能的分析， 所以，業(yè)一般 采用“售前估算法”，通常的做法是： 選擇應(yīng)用系統(tǒng)中業(yè)務(wù)重要性、 業(yè)務(wù)頻繁度、 客戶連接數(shù)最多、 最具有代表性的一個(gè)業(yè)務(wù)進(jìn)行估算， 結(jié)合行業(yè)其他項(xiàng)目的建設(shè) 經(jīng)驗(yàn)進(jìn)行綜合評(píng)價(jià)，得出最終的主要設(shè)備性能需求。本項(xiàng)目中，我們選擇“以

13、EHR（居民電子健康記錄）為基礎(chǔ)的社區(qū)衛(wèi)生信 息系統(tǒng)”作為我們?cè)u(píng)估數(shù)據(jù)中心核心數(shù)據(jù)庫(kù)服務(wù)器性能的參考業(yè)務(wù)系統(tǒng)， 售前估 算法主要涉及的要點(diǎn)見(jiàn)下表：文案標(biāo)準(zhǔn) 市區(qū)域衛(wèi)生信息系統(tǒng)網(wǎng)注冊(cè)用戶估算為 3000 個(gè)，預(yù)計(jì)高峰并發(fā)訪問(wèn)數(shù) 在 1500 個(gè)左右；通過(guò)門(mén)戶發(fā)起的業(yè)務(wù)申請(qǐng)用戶估算為每天 2000 個(gè)， 預(yù)計(jì)高峰并發(fā)訪問(wèn)數(shù)在 500 個(gè)左右；因此，估算公式中的 U 值為 2000 ； 假設(shè)每個(gè)用戶每秒提交業(yè)務(wù)處理請(qǐng)求個(gè)數(shù)為 1 個(gè)，公式中的 Q 值； 平均處理每個(gè)業(yè)務(wù)處理請(qǐng)求所需要的時(shí)間應(yīng)在 1 秒左右，公式中的 J 值； 假設(shè)每年并發(fā)用戶增長(zhǎng)率暫時(shí)考慮為 0，公式中的 G 值； 主機(jī)系統(tǒng)的平均使

14、用計(jì)算資源率建議不超過(guò) 40% （雙機(jī)熱備），公式中 的 B 值； 系統(tǒng)設(shè)計(jì)性能覆蓋年限為 5 年左右，公式中的 N 值； 根據(jù)經(jīng)驗(yàn)及對(duì)應(yīng)用程序的分析， 每個(gè)業(yè)務(wù)請(qǐng)求相當(dāng)于 5-10 個(gè) tpmC ，本 項(xiàng)目的主數(shù)據(jù)庫(kù)服務(wù)器主要為 OLTP（聯(lián)機(jī)事務(wù)處理） 應(yīng)用；公式中的 S 值； 1 分鐘為 60 秒，公式中的 T值； 由此得出 :文案標(biāo)準(zhǔn)UQJ（100%+G） N TSB，根據(jù)以上數(shù)值，得出本系統(tǒng)所需的主機(jī) TPCC性能要求為最低 1500000TPMC ，最高 3000000 TPMC ；本方案以 IBM Power 740 小型機(jī)為例，其 3.6GHz 的 Power7 CPU 的單

15、核 TPmC 值約為 100000 ，因此滿足信息系統(tǒng) 5 年應(yīng)用的服務(wù)器主機(jī) TPmC 總 值需要配 32 核 Power7 3.6GHz CPU 。結(jié)合業(yè)務(wù) 724 小時(shí)不能停頓的系統(tǒng)高穩(wěn)定可靠要求，以及節(jié)約成本考慮， 建議配置 2 臺(tái)數(shù)據(jù)庫(kù)服務(wù)器做集群，兩個(gè)節(jié)點(diǎn)可同時(shí)提供數(shù)據(jù)庫(kù)處理，參照 Oracle RAC 技術(shù)特性，雙機(jī)集群后，整體性能為單機(jī)服務(wù)器的 1.5 倍左右。綜上所述，數(shù)據(jù)庫(kù)主機(jī)系統(tǒng)的單機(jī)參考配置為： 相當(dāng)于 IBM Power7 16Core 3.6GHz CPU 。數(shù)據(jù)庫(kù)服務(wù)器存需求分析如下：（1） 參照實(shí)際應(yīng)用經(jīng)驗(yàn) 以及參考數(shù)據(jù)庫(kù)的技術(shù)特性要求， 信息系統(tǒng)數(shù)據(jù)庫(kù)連接 數(shù)

16、約為 2000 個(gè)，每個(gè)連接占用 20M 存，共計(jì)所需 40G 存；（ 2） 以 3-5 年在線生成數(shù)據(jù)庫(kù)數(shù)據(jù)將達(dá)到 500GB 左右的規(guī)模估算， 一般醫(yī)院 信息系統(tǒng)的在線業(yè)務(wù)和查詢業(yè)務(wù)都在同一數(shù)據(jù)庫(kù)里執(zhí)行， 按照使用經(jīng)驗(yàn)來(lái) 看大概有接近 5% 的熱點(diǎn)數(shù)據(jù)，因此數(shù)據(jù)緩存使用的容為按照 25G 估算；（ 3） 在執(zhí)行數(shù)據(jù)庫(kù)備份時(shí)，為了加快備份速度，使用 5GB 左右的文件緩存； （ 4） 目前主流的、最新版本操作系統(tǒng)建議保留使用 10G 左右的存用于系統(tǒng)調(diào) 配；綜上，按照 70%的系統(tǒng)存使用閥值來(lái)計(jì)算，共計(jì)存 114GB ；在主機(jī)硬件配 置時(shí)，應(yīng)配置 128GB 存。文案標(biāo)準(zhǔn)1.1.1.1.4

17、存儲(chǔ)需求分析1.1.1.1.4.1 存儲(chǔ)性能基本要求 數(shù)據(jù)中心存儲(chǔ)系統(tǒng)的磁盤(pán)陣列應(yīng)采用支持多種轉(zhuǎn)速的、 熱插拔硬盤(pán)的高性能存儲(chǔ)設(shè)備， 雙控制器或多控制器模式保證磁盤(pán)陣列本身的高可用， 陣列的控制器 緩存建議少于 32GB ，采用8GB或以上FC通道連接 SAN ，并支持 ISCSI接口便于 文件類(lèi)的存儲(chǔ)。針對(duì)數(shù)據(jù)庫(kù)熱點(diǎn)數(shù)據(jù)的存儲(chǔ)，建議采用高性能的 SSD盤(pán)； 針對(duì)一般數(shù)據(jù)庫(kù)存儲(chǔ)和虛擬機(jī)文件存儲(chǔ)， 建議采用不低于 10000 轉(zhuǎn)速的 SAS 硬盤(pán)；針對(duì)影像文件、視頻文件等存儲(chǔ)，可采用成本較低的 SATA硬盤(pán)； 磁盤(pán)陣列通過(guò)存儲(chǔ)虛擬化網(wǎng)關(guān)進(jìn)行存儲(chǔ)資源的池化， 從而支撐數(shù)據(jù)庫(kù)和虛擬 機(jī)同城雙活方案的

18、實(shí)現(xiàn)；1.1.1.1.4.2 數(shù)據(jù)量估算（1）以 EHR 為核心的應(yīng)用系統(tǒng)數(shù)據(jù)估算業(yè)務(wù)類(lèi)別數(shù)據(jù)類(lèi)型說(shuō)明數(shù)據(jù)量估算EHR 業(yè)務(wù)居民主索引數(shù)據(jù)按 500 萬(wàn)人口計(jì)算0.01M*500 萬(wàn) =50G居民健康卡數(shù)據(jù)按 500 萬(wàn)人口計(jì)算0.02M*500 萬(wàn) =100G出生證數(shù)據(jù)按每年 4 萬(wàn)計(jì)算1M*4 萬(wàn)*1 年=40G/ 年婦幼保健數(shù)據(jù)按每年 80 萬(wàn)計(jì)算1M*80 萬(wàn)*1 年=80G/ 年文案標(biāo)準(zhǔn)個(gè)人基本健康檔案按 500 萬(wàn)人口計(jì)算0.1M*500 萬(wàn)=500G專(zhuān)項(xiàng)疾病保健數(shù)據(jù)按每年 6 萬(wàn)計(jì)算1M*6 萬(wàn)*1 年=60G/ 年電子病歷數(shù)據(jù)按每年 4 萬(wàn)計(jì)算10M*4 萬(wàn)*1 年=400G/

19、 年檢驗(yàn) / 檢查結(jié)果數(shù)據(jù)按每年 80 萬(wàn)計(jì)算0.02M*80 萬(wàn)*1 年 =16G/年處方/醫(yī)囑數(shù)據(jù)按每年 160 萬(wàn)計(jì)算0.01M*160 萬(wàn)*1 年 =16G/年健康體檢數(shù)據(jù)按每年 14 萬(wàn)計(jì)算0.1M*14 萬(wàn)*1 年=14G/ 年醫(yī)學(xué)影像索引及圖文報(bào)告系統(tǒng)數(shù)據(jù)按每年 4 萬(wàn)計(jì)算2M*4 萬(wàn)*1 年=80G/ 年其他診療數(shù)據(jù)按 500 萬(wàn)人口計(jì)算0.2M*500 萬(wàn) *1 年=1000G/ 年數(shù)據(jù)倉(cāng)庫(kù)主題數(shù)據(jù)庫(kù)按每年 100 萬(wàn)條數(shù)據(jù)0.02M*100 萬(wàn)*1 年 =20G/年資源數(shù)據(jù)庫(kù)按每年 2 萬(wàn)條數(shù)據(jù)0.02M*2 萬(wàn)*1 年=0.4G/ 年方法庫(kù)，模型庫(kù)估算 1G其他數(shù)據(jù)各種標(biāo)

20、準(zhǔn)協(xié)議數(shù)據(jù)估算 1G監(jiān)控管理數(shù)據(jù)按每年 0.6G 增量計(jì)算0.6G/ 年系統(tǒng)其他數(shù)據(jù)（用按每年 0.2G 增量0.2G/ 年文案標(biāo)準(zhǔn)戶，日志等）計(jì)算合計(jì)約 2829.2GB每年增量約 600.2GB系統(tǒng)設(shè)計(jì) 5 年總數(shù)據(jù)量5230GB以上數(shù)據(jù)存儲(chǔ)應(yīng)采用 SSD 和 SAS 混合形式2）區(qū)域醫(yī)療主要數(shù)據(jù)估算應(yīng)用系統(tǒng)數(shù)據(jù)量估算HIS/EMR/LIS/HSS 等300G ，每年增量 30G疾控/衛(wèi)監(jiān)/ 急救等500GB ，每年增量 50GB合計(jì)約 800GB ，每年增量 80GB系統(tǒng)設(shè)計(jì) 5 年總數(shù)據(jù)量1200GB以上數(shù)據(jù)存儲(chǔ)應(yīng)采用 SSD 和 SAS 混合形式3）其他應(yīng)用系統(tǒng)數(shù)據(jù)估算應(yīng)用系統(tǒng)數(shù)據(jù)量

21、估算基層衛(wèi)生服務(wù)信息系統(tǒng) / 綜合運(yùn)營(yíng)數(shù)據(jù)100G ，每年增量 10G外網(wǎng)應(yīng)用數(shù)據(jù)500GB ，每年增量 50GB視頻數(shù)據(jù)（典型）1000GB ，每年增量 1000GB合計(jì)約 1600GB ， 每 年 增 量1060GB系統(tǒng)設(shè)計(jì) 5 年總數(shù)據(jù)量5840GB以上數(shù)據(jù)存儲(chǔ)應(yīng)采用 SAS 和 SATA 混合形式4）數(shù)據(jù)中心系統(tǒng)平臺(tái)存儲(chǔ)資源占用估算文案標(biāo)準(zhǔn)系統(tǒng)數(shù)據(jù)量估算虛擬機(jī)，預(yù)計(jì) 50 個(gè)虛擬機(jī)， 每個(gè)虛擬機(jī) 200GB10000GB ，每年增量 200G程序更新10G ，每年增量 1G配置管理10G ，每年增量 1G合計(jì)約 10020GB ， 每 年 增 量202GB系統(tǒng)設(shè)計(jì) 5 年總數(shù)據(jù)量108

22、28GB以上數(shù)據(jù)存儲(chǔ)應(yīng)采用 SAS 和 SATA 混合形式根據(jù)上述分析可得數(shù)據(jù)中心存儲(chǔ)系統(tǒng)可用容量應(yīng)不低于： 23098GB（ 23TB ）， 考慮設(shè)計(jì)不少于 2個(gè)數(shù)據(jù)存儲(chǔ)副本，則建議容量不少于 69TB ，可分期逐步擴(kuò)容。1.1.1.1.5 服務(wù)器計(jì)算資源需求分析根據(jù)本項(xiàng)目的應(yīng)用系統(tǒng)建設(shè)需求， 分解各個(gè)應(yīng)用系統(tǒng)對(duì)計(jì)算資源的需求， 如表：服務(wù)器名稱用途說(shuō)明機(jī)器數(shù)量單個(gè)配置（ core/G ）合計(jì)資源（ core/G ）CPU存CPU存關(guān)鍵數(shù)據(jù)庫(kù)（物理機(jī)）電子健康檔案資源庫(kù)、電子病歷資源庫(kù)、全員人口信息庫(kù)、衛(wèi)生計(jì)生管理資源庫(kù)、24012880256數(shù)據(jù)倉(cāng)庫(kù)服務(wù)器（物理機(jī)）基于平臺(tái)的 ODS,DW 等24012880256文案標(biāo)準(zhǔn)分布式協(xié)調(diào)服務(wù)器zookeeper5281040數(shù)據(jù)交換服務(wù)器數(shù)據(jù)采集和交換平臺(tái)、 ETL、Adapt