云計(jì)算資源需求分析和規(guī)劃

1、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ò)為客戶(hù)提供服務(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ù)中心撤退舊的硬件。虛擬基礎(chǔ)架構(gòu)使企

2、業(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í)間內(nèi)完成新應(yīng)用程序的資源調(diào)配，而不需要幾天時(shí)間。請(qǐng)求響應(yīng)時(shí)間也改為以分鐘計(jì)算。在維護(hù)上，可以實(shí)現(xiàn)零停機(jī)硬件維護(hù)，不需要等待維護(hù)窗口。服務(wù)器虛擬化是計(jì)算機(jī)資源邏輯組的過(guò)程，這種資源的新虛擬視圖并不受實(shí) 現(xiàn)，地理位置或底層資源的物理配置的限制。這種邏輯視圖對(duì)信息基礎(chǔ)設(shè)施有深 遠(yuǎn)的影響。服務(wù)器虛擬化帶來(lái)的益處：虛擬化技術(shù)可借助信息基礎(chǔ)設(shè)施更好地提供服務(wù)，從而幫助客戶(hù)節(jié)省資

3、金。與傳統(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ù)器虛擬化的軟件平臺(tái)選型原則在服務(wù)器虛擬化的軟件平臺(tái)方面，主流的軟件提供商均提供了所有軟件廠(chǎng)商 具有

4、管理CPU內(nèi)存、網(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ì)于虛擬化硬件平臺(tái)的支持?良好的兼容性服務(wù)器虛擬化的硬件平臺(tái)選型原則為服務(wù)器虛擬化選擇適當(dāng)?shù)挠布脚_(tái)正如選擇適當(dāng)?shù)奶摂M化軟件一樣重要 為了做出正確

5、的選擇，必須考慮到以下因素：?優(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)中的處理器與芯片組所包含的硬件輔助特性，可以 在最大限度降低這一開(kāi)銷(xiāo)方面發(fā)揮作用。?能效與空間：在成本或物理限制影響最終用戶(hù)正常工作的能力的情況下， 例如，當(dāng)成本超出預(yù)算，或

6、功耗要求超出可用資源時(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)成本使資源與資 本從旨在推動(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)廠(chǎng)商將不斷推出多種專(zhuān)

7、為虛擬化而優(yōu)化的 特性。例如，主流的硬件廠(chǎng)商均為處理器增添了虛擬化能力，也有針對(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ò)展能力。?良好的廠(chǎng)商協(xié)作：通過(guò)著眼于當(dāng)前全行業(yè)范圍內(nèi)的協(xié)作，我們將能夠更 好地了解虛擬化的特征。鑒于虛擬化涉及多個(gè)層次上的軟硬件組件，系 統(tǒng)廠(chǎng)商、操作系統(tǒng)與應(yīng)用廠(chǎng)商以及虛擬化廠(chǎng)商需要攜手合作，共同制定 出可行的解決方案。目前，多家行業(yè)合作伙伴正在全新平臺(tái)上針對(duì)虛擬 化進(jìn)行優(yōu)化。?良好的兼容性：保持各

8、代平臺(tái)之間的兼容性是未來(lái)系統(tǒng)的一個(gè)重要特性。將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ī)安全的考慮虛擬化使用戶(hù)獲得在效率、成本方面的顯著收益，以及在數(shù)據(jù)中心更具環(huán)保、靈活的擴(kuò)展性和減少實(shí)施時(shí)間方面的附加價(jià)值。數(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ì)、部署和管理的情況下，用戶(hù)需要考慮哪種安全機(jī)制最適合

9、保護(hù) 這些虛擬服務(wù)器。傳統(tǒng)環(huán)境下的網(wǎng)絡(luò)安全拓?fù)鋱D，在網(wǎng)絡(luò)出口處部署有防火墻，防毒墻，上網(wǎng) 行為管理等安全設(shè)備，用來(lái)隔離內(nèi)外網(wǎng)，過(guò)濾來(lái)自外網(wǎng)的惡意程序，規(guī)范內(nèi)網(wǎng)用 戶(hù)的上網(wǎng)行為，同時(shí)在DMZ區(qū)使用防火墻隔離，部署IDS監(jiān)控對(duì)服務(wù)器的非法訪(fǎng) 問(wèn)行為，在服務(wù)器上部署防病毒軟件，保護(hù)核心服務(wù)器的安全運(yùn)行。根據(jù)傳統(tǒng)的安全設(shè)計(jì)模型，需要在每個(gè)操作系統(tǒng)中安裝防毒軟件， 在網(wǎng)絡(luò)層 部署入防火墻、侵檢測(cè)或入侵防御系統(tǒng)，但是在這種在傳統(tǒng)方式下合理的設(shè)計(jì)， 在虛擬環(huán)境下會(huì)面臨一些新的問(wèn)題：未激活的虛擬機(jī)，物理機(jī)下關(guān)閉計(jì)算機(jī)后CP停止運(yùn)行，網(wǎng)絡(luò)關(guān)閉，理論上 不會(huì)有數(shù)據(jù)的交互，操作系統(tǒng)也就不存在被感染的可能；但是在虛擬

10、環(huán)境下，CPU網(wǎng)絡(luò)，底層的ES)都在工作中，關(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ì)CP和內(nèi)存的占用急劇增加，當(dāng)系統(tǒng)資源被耗盡的時(shí)候就會(huì)導(dǎo)致服務(wù)器dowr機(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

11、艮務(wù)器上的虛擬機(jī)之間的通訊； 由于虛 擬機(jī)能夠迅速地恢復(fù)到之前的狀態(tài)， 利用VMwareVMotion?易于在物理服務(wù)器之 間移動(dòng)，所以難以獲得并維持整體一致的安全性。所以虛擬化已經(jīng)使“網(wǎng)絡(luò)邊界去除”的挑戰(zhàn)更加明顯，虛擬化對(duì)于安全的需求也更加迫切。安全虛擬機(jī)利用API來(lái)訪(fǎng)問(wèn)關(guān)于每一虛擬機(jī)的特權(quán)狀態(tài)信息，包括其內(nèi)存、狀態(tài)和網(wǎng)絡(luò)通信流量等。因?yàn)樵诓桓奶摂M網(wǎng)絡(luò)配置的情況下，服務(wù)器內(nèi)部的全 部網(wǎng)絡(luò)通信流量是可見(jiàn)的。包括防病毒、防火墻、IDS/IPS和系統(tǒng)完整性監(jiān)控等 在內(nèi)的安全功能均可以應(yīng)用于安全虛擬機(jī)中1.1.1.1.3數(shù)據(jù)庫(kù)服務(wù)器性能需求分析區(qū)域衛(wèi)生信息系統(tǒng)覆蓋面廣、業(yè)務(wù)極其復(fù)雜，各業(yè)務(wù)子系統(tǒng)之

12、間交叉非常多，因此很難通過(guò)搭建業(yè)務(wù)模型通過(guò)壓力測(cè)試來(lái)進(jìn)行系統(tǒng)性能的分析，所以，業(yè)內(nèi)一般采用“售前估算法”，通常的做法是：選擇應(yīng)用系統(tǒng)中業(yè)務(wù)重要性、業(yè)務(wù)頻繁 度、客戶(hù)連和虛擬環(huán)境育接集成*接數(shù)最多、最具有代表性的一個(gè)業(yè)務(wù)進(jìn)行估算，結(jié)合行業(yè)內(nèi)其他項(xiàng)目 的建設(shè)經(jīng)驗(yàn)進(jìn)行綜合評(píng)價(jià)，得出最終的主要設(shè)備性能需求。本項(xiàng)目中，我們選擇“以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)下表：通用和自主開(kāi)發(fā)應(yīng)用系統(tǒng)服務(wù)器性能估算公式U亠最天耘I當(dāng)前用戶(hù)融（用戶(hù)秒）Q-毎于用戶(hù)平均匍秒提交it窮處理睛求冋 電于科明戶(hù)）J-平均處連

13、屈個(gè)業(yè)務(wù)處理請(qǐng)求註的時(shí)回（秋宀）G-鬲年弁垸朋戶(hù)增忻率娜B -系紐的平均僅用計(jì)尊資廩率跖C 63小-N-系養(yǎng)誥計(jì)性能施年眼*務(wù)處理請(qǐng)求t目當(dāng)于ttK：SPECWebuESPECJaB -KOLTP應(yīng)用的單一事務(wù)性養(yǎng)=HIT卜顧妙一gOLAPjfl的單一事奔性養(yǎng)=1 o別個(gè)巫四； 青門(mén)教堀倉(cāng)匪-B廉孵要專(zhuān)門(mén)臨啲工具鼻一最OLTP* OLAPjffl的單一事務(wù)性能=25+SPEGWebjft；OLTP OLAP應(yīng)陽(yáng)的單一事勞性能=21Q4 5PECJBB；T-分鍵秒系數(shù)）耒要的業(yè)務(wù)處遲性能(tpmCJ UXQXX (100+G)W3TX -=-61中山市區(qū)域衛(wèi)生信息系統(tǒng)網(wǎng)內(nèi)注冊(cè)用戶(hù)估算為3000個(gè)

14、，預(yù)計(jì)高峰并發(fā)訪(fǎng)問(wèn)數(shù)在1500個(gè)左右；通過(guò)門(mén)戶(hù)網(wǎng)站發(fā)起的業(yè)務(wù)申請(qǐng)用戶(hù)估算為每天2000個(gè)，預(yù)計(jì)高峰并發(fā)訪(fǎng)問(wèn)數(shù)在500個(gè)左右；因此，估算公式中的U值為2000；2假設(shè)每個(gè)用戶(hù)每秒提交業(yè)務(wù)處理請(qǐng)求個(gè)數(shù)為1個(gè)，公式中的Q值；3平均處理每個(gè)業(yè)務(wù)處理請(qǐng)求所需要的時(shí)間應(yīng)在1秒左右，公式中的J值；4假設(shè)每年并發(fā)用戶(hù)增長(zhǎng)率暫時(shí)考慮為0,公式中的G值;5主機(jī)系統(tǒng)的平均使用計(jì)算資源率建議不超過(guò)40%（雙機(jī)熱備），公式中的B值；6系統(tǒng)設(shè)計(jì)性能覆蓋年限為5年左右，公式中的N值；7根據(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值；*

15、81分鐘為60秒，公式中的T值;9由此得出：UXQXJX(100%+G)XTXS十B,根據(jù)以上數(shù)值，得出本系統(tǒng)所需的主機(jī)TPCC性能要求為最低1500000TPMC最高3000000 TPMC本方案以IBM Power 740小型機(jī)為例，其3.6GHz的Power7 CPU的單核TPmC值約為100000,因此滿(mǎn)足信息系統(tǒng)5年應(yīng)用的服務(wù)器主機(jī)TPmC總值需要配32核Power7 3.6GHzCPU結(jié)合業(yè)務(wù)7X24小時(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

16、.5倍左右。綜上所述，數(shù)據(jù)庫(kù)主機(jī)系統(tǒng)的單機(jī)參考配置為：相當(dāng)于IBM Power7 16Core3.6GHz CPU數(shù)據(jù)庫(kù)服務(wù)器內(nèi)存需求分析如下：(1)參照實(shí)際應(yīng)用經(jīng)驗(yàn) 以及參考數(shù)據(jù)庫(kù)的技術(shù)特性要求，信息系統(tǒng)數(shù)據(jù)庫(kù)連接 數(shù)約為2000個(gè)，每個(gè)連接占用20M內(nèi)存，共計(jì)所需40G內(nèi)存；(2)以3-5年在線(xiàn)生成數(shù)據(jù)庫(kù)數(shù)據(jù)將達(dá)到500GB左右的規(guī)模估算，一般醫(yī)院信 息系統(tǒng)的在線(xiàn)業(yè)務(wù)和查詢(xún)業(yè)務(wù)都在同一數(shù)據(jù)庫(kù)里執(zhí)行，按照使用經(jīng)驗(yàn)來(lái)看 大概有接近5%勺熱點(diǎn)數(shù)據(jù)，因此數(shù)據(jù)緩存使用的內(nèi)容為按照25G估算；(3)在執(zhí)行數(shù)據(jù)庫(kù)備份時(shí)，為了加快備份速度，使用5GB左右的文件緩存；(4)目前主流的、最新版本操作系統(tǒng)建議保

17、留使用10G左右的內(nèi)存用于系統(tǒng)調(diào) 配；綜上，按照70%勺系統(tǒng)內(nèi)存使用閥值來(lái)計(jì)算，共計(jì)內(nèi)存114GB在主機(jī)硬件配 置時(shí)，應(yīng)配置128G內(nèi)存。1.1.1.1.4存儲(chǔ)需求分析1.1.1.141存儲(chǔ)性能基本要求數(shù)據(jù)中心存儲(chǔ)系統(tǒng)的磁盤(pán)陣列應(yīng)采用支持多種轉(zhuǎn)速的、熱插拔硬盤(pán)的高性能 存儲(chǔ)設(shè)備，雙控制器或多控制器模式保證磁盤(pán)陣列本身的高可用，陣列的控制器 緩存建議少于32GB采用8G或以上FC通道連接SAN并支持ISCSI接口便于文件 類(lèi)的存儲(chǔ)。針對(duì)數(shù)據(jù)庫(kù)熱點(diǎn)數(shù)據(jù)的存儲(chǔ)，建議采用高性能的SS盤(pán)；針對(duì)一般數(shù)據(jù)庫(kù)存儲(chǔ)和虛擬機(jī)文件存儲(chǔ)，建議采用不低于10000轉(zhuǎn)速的SAS硬盤(pán)；針對(duì)影像文件、視頻文件等存儲(chǔ)，可采用成

18、本較低的SATAM盤(pán)；磁盤(pán)陣列通過(guò)存儲(chǔ)虛擬化網(wǎng)關(guān)進(jìn)行存儲(chǔ)資源的池化，從而支撐數(shù)據(jù)庫(kù)和虛擬 機(jī)同城雙活方案的實(shí)現(xiàn)；1.1.1.142數(shù)據(jù)量估算（1）以EHF為核心的應(yīng)用系統(tǒng)數(shù)據(jù)估算業(yè)務(wù)類(lèi)別數(shù)據(jù)類(lèi)型說(shuō)明數(shù)據(jù)量估算EHF業(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/年個(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ì)算

19、10M*4萬(wàn)*1年=400G/年檢驗(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)準(zhǔn)協(xié)議數(shù)據(jù)估算1G監(jiān)控管理數(shù)據(jù)按每年0

20、.6G增量 計(jì)算0.6G/年系統(tǒng)其他數(shù)據(jù)（用 戶(hù)，日志等）按每年0.2G增量 計(jì)算0.2G/年合計(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ù)量估算基層衛(wèi)生服務(wù)信息系統(tǒng)/綜合運(yùn)營(yíng)數(shù)據(jù)100G每年增量10G外網(wǎng)應(yīng)用數(shù)據(jù)500GB每年增量50GB視

21、頻數(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ǔ)資源占用估算系統(tǒng)數(shù)據(jù)量估算虛擬機(jī),預(yù)計(jì)50個(gè)虛擬機(jī),每個(gè)虛擬機(jī)200GB 110000GB每年增量200G程序更新10G每年增量1G配置管理10G每年增量1G合計(jì)約10020GB每年增量202GB系統(tǒng)設(shè)計(jì)5年總數(shù)據(jù)量10828GB以上數(shù)據(jù)存儲(chǔ)應(yīng)米用SAS和SATA混合形式根據(jù)上述分析可得數(shù)據(jù)中心存儲(chǔ)系統(tǒng)可用容量應(yīng)不低于：23098G(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ì)算資源的需求， 如F表:服務(wù)器名稱(chēng)用途說(shuō)明機(jī)器數(shù)量單個(gè)配置(core/G)合計(jì)資源(core/G)CPU內(nèi)存CPU內(nèi)存關(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分布式協(xié)調(diào)服務(wù)器zookeeper5281040數(shù)據(jù)交換服務(wù)器數(shù)據(jù)采集和交換平臺(tái)、ETL、Adapter143243