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

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)用和管理類服務(wù)器采用虛擬機(jī)部署（同城雙活）。1.1.1.1.2應(yīng)用服務(wù)器采用虛擬化方案采用虛擬化技術(shù)是實(shí)現(xiàn)云計(jì)算的基礎(chǔ)。 通過(guò)為客戶提供服務(wù)器整合和數(shù)量控制、業(yè)務(wù)連續(xù)性、測(cè)試 / 開發(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ǔ)架

2、構(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í)間內(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ù)，從而

3、幫助客戶節(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ù)器虛擬化的軟件平臺(tái)選型原則在服務(wù)器虛擬化的軟件平臺(tái)方面， 主流的軟件提供商

4、均提供了所有軟件廠商具有管理 CPU、內(nèi)存、網(wǎng)絡(luò)和硬盤資源的能力的服務(wù)器虛擬化軟件， 這些軟件都同時(shí)支持 Windows 與 Linux 操作環(huán)境。目前，服務(wù)器虛擬化軟件分為商用軟件和開源軟件，這些軟件都提供了對(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ù)挠布?/p>

5、臺(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)中的處理器與芯片組所包含的硬件輔助特性，可以在最大限度降低這一開銷方面發(fā)揮作用。? 能效與空間： 在成本或物理限制影響最終用

6、戶正常工作的能力的情況下，例如，當(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)成本使資源與資本從旨在推動(dòng)創(chuàng)新和提高 IT 價(jià)值的計(jì)劃中抽離了出來(lái)。 使用虛擬化環(huán)境將可以提高系統(tǒng)利用率，降低功耗與散熱要求，減少空間要求，簡(jiǎn)化運(yùn)營(yíng)和

7、降低系統(tǒng)管理要求。? 優(yōu)化的平臺(tái)特性： 組件與系統(tǒng)廠商將不斷推出多種專為虛擬化而優(yōu)化的特性。例如，主流的硬件廠商均為處理器增添了虛擬化能力，也有針對(duì)大量 I/O 、網(wǎng)絡(luò)處理需求的平臺(tái)虛擬化特性。這些能力既能簡(jiǎn)化強(qiáng)大虛擬化軟件的設(shè)計(jì)， 又能降低在虛擬化環(huán)境中運(yùn)行應(yīng)用通常所需的性能開銷。對(duì)于 EHRS上的大量文件處理， I/O 虛擬化的優(yōu)化可進(jìn)一步提升信息交換平臺(tái)的處理與擴(kuò)展能力。? 良好的廠商協(xié)作：通過(guò)著眼于當(dāng)前全行業(yè)范圍內(nèi)的協(xié)作，我們將能夠更好地了解虛擬化的特征。鑒于虛擬化涉及多個(gè)層次上的軟硬件組件，系統(tǒng)廠商、操作系統(tǒng)與應(yīng)用廠商以及虛擬化廠商需要攜手合作，共同制定出可行的解決方案。目前，多家行

8、業(yè)合作伙伴正在全新平臺(tái)上針對(duì)虛擬化進(jìn)行優(yōu)化。? 良好的兼容性： 保持各代平臺(tái)之間的兼容性是未來(lái)系統(tǒng)的一個(gè)重要特性。將 VM 從一臺(tái)服務(wù)器遷移到另一臺(tái)服務(wù)器上需要考慮架構(gòu)問(wèn)題， 這樣 IT部門無(wú)需創(chuàng)建虛擬資源島（ islands of virtual resource ），但卻可以真正發(fā)揮出基礎(chǔ)設(shè)施的最大靈活性。對(duì)虛擬機(jī)安全的考慮虛擬化使用戶獲得在效率、 成本方面的顯著收益 , 以及在數(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)將從

9、根本上改變關(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)隔離內(nèi)外網(wǎng)， 過(guò)濾來(lái)自外網(wǎng)的惡意程序， 規(guī)范內(nèi)網(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è)操作系統(tǒng)中安裝防毒軟件， 在網(wǎng)絡(luò)層部署入防火墻、侵檢測(cè)或入侵防御系統(tǒng)，但是在這種在傳統(tǒng)方式下合理的設(shè)計(jì)，在虛擬環(huán)境下會(huì)面臨一些新的問(wèn)題：未激活的虛擬機(jī) ，物理機(jī)下關(guān)閉計(jì)

10、算機(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)類似于物理環(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和內(nèi)存的占用急劇增加，當(dāng)系統(tǒng)資源被耗盡的時(shí)候就會(huì)導(dǎo)致服務(wù)器 down機(jī)；管理復(fù)雜度 ，由于虛擬化的便利性， 系統(tǒng)管理員可以非常方便的根據(jù)模板生成新的系統(tǒng)， 這些新系統(tǒng)要打補(bǔ)丁， 進(jìn)行病毒代碼的更新， 也會(huì)增加安全管理的復(fù)雜度；虛擬化環(huán)

11、境的動(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ì)于安全的需求也更加迫切。安全虛擬機(jī)利用 API 來(lái)訪問(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ò)通信流量是可見的。 包括防病毒、 防火墻、 IDS/IPS 和系統(tǒng)完整性監(jiān)控

12、等在內(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)之間交叉非常多，因此很難通過(guò)搭建業(yè)務(wù)模型通過(guò)壓力測(cè)試來(lái)進(jìn)行系統(tǒng)性能的分析， 所以，業(yè)內(nèi)一般采用“售前估算法” ，通常的做法是：選擇應(yīng)用系統(tǒng)中業(yè)務(wù)重要性、業(yè)務(wù)頻繁度、客戶連接數(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)見下表： 中山市區(qū)域衛(wèi)

13、生信息系統(tǒng)網(wǎng)內(nèi)注冊(cè)用戶估算為3000 個(gè)，預(yù)計(jì)高峰并發(fā)訪問(wèn)數(shù)在 1500 個(gè)左右；通過(guò)門戶網(wǎng)站發(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)的平均使用計(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è) t

14、pmC，本項(xiàng)目的主數(shù)據(jù)庫(kù)服務(wù)器主要為OLTP（聯(lián)機(jī)事務(wù)處理）應(yīng)用；公式中的S值； 1 分鐘為 60 秒，公式中的 T 值； 由此得出 :NUQJ(100%+G) T S B，根據(jù)以上數(shù)值，得出本系統(tǒng)所需的主機(jī)TPCC性能要求為最低1500000TPMC，最高 3000000 TPMC；本方案以 IBM Power 740 小型機(jī)為例，其的 Power7 CPU 的單核 TPmC值約為 100000，因此滿足信息系統(tǒng) 5 年應(yīng)用的服務(wù)器主機(jī) TPmC總值需要配 32 核Power7 CPU。結(jié)合業(yè)務(wù) 724 小時(shí)不能停頓的系統(tǒng)高穩(wěn)定可靠要求，以及節(jié)約成本考慮，建議配置 2 臺(tái)數(shù)據(jù)庫(kù)服務(wù)器做集群，

15、兩個(gè)節(jié)點(diǎn)可同時(shí)提供數(shù)據(jù)庫(kù)處理，參照Oracle RAC 技術(shù)特性，雙機(jī)集群后，整體性能為單機(jī)服務(wù)器的倍左右。綜上所述，數(shù)據(jù)庫(kù)主機(jī)系統(tǒng)的單機(jī)參考配置為：相當(dāng)于 IBM Power7 16Core 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 年在線生成數(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ù)緩存使用的內(nèi)容為按照 25G估

16、算；（ 3） 在執(zhí)行數(shù)據(jù)庫(kù)備份時(shí)，為了加快備份速度，使用5GB左右的文件緩存；（ 4） 目前主流的、最新版本操作系統(tǒng)建議保留使用 10G左右的內(nèi)存用于系統(tǒng)調(diào)配；綜上，按照 70%的系統(tǒng)內(nèi)存使用閥值來(lái)計(jì)算， 共計(jì)內(nèi)存 114GB；在主機(jī)硬件配置時(shí)，應(yīng)配置 128GB內(nèi)存。1.1.1.1.4存儲(chǔ)需求分析1.1.1.1.4.1存儲(chǔ)性能基本要求數(shù)據(jù)中心存儲(chǔ)系統(tǒng)的磁盤陣列應(yīng)采用支持多種轉(zhuǎn)速的、 熱插拔硬盤的高性能存儲(chǔ)設(shè)備，雙控制器或多控制器模式保證磁盤陣列本身的高可用， 陣列的控制器緩存建議少于 32GB，采用 8GB或以上 FC通道連接 SAN，并支持 ISCSI 接口便于文件類的存儲(chǔ)。針對(duì)數(shù)據(jù)庫(kù)熱點(diǎn)

17、數(shù)據(jù)的存儲(chǔ)，建議采用高性能的SSD盤；針對(duì)一般數(shù)據(jù)庫(kù)存儲(chǔ)和虛擬機(jī)文件存儲(chǔ)，建議采用不低于 10000轉(zhuǎn)速的 SAS 硬盤；針對(duì)影像文件、視頻文件等存儲(chǔ)，可采用成本較低的SATA硬盤；磁盤陣列通過(guò)存儲(chǔ)虛擬化網(wǎng)關(guān)進(jìn)行存儲(chǔ)資源的池化， 從而支撐數(shù)據(jù)庫(kù)和虛擬機(jī)同城雙活方案的實(shí)現(xiàn)；1.1.1.1.4.2數(shù)據(jù)量估算（1）以 EHR為核心的應(yīng)用系統(tǒng)數(shù)據(jù)估算業(yè)務(wù)類別數(shù)據(jù)類型說(shuō)明數(shù)據(jù)量估算居民主索引數(shù)據(jù)按 500 萬(wàn)人口計(jì)*500萬(wàn) =50GEHR業(yè)務(wù)算按 500 萬(wàn)人口計(jì)居民健康卡數(shù)據(jù)*500萬(wàn) =100G算出生證數(shù)據(jù)按每年 4 萬(wàn)計(jì)算1M*4 萬(wàn) *1 年=40G/年婦幼保健數(shù)據(jù)按每年 80 萬(wàn)計(jì)算1M*8

18、0 萬(wàn)*1 年=80G/年個(gè)人基本健康檔案按 500 萬(wàn)人口計(jì)*500 萬(wàn) =500G算專項(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/年檢驗(yàn) / 檢查結(jié)果數(shù)按每年 80 萬(wàn)計(jì)算*80 萬(wàn)*1 年 =16G/年據(jù)處方 / 醫(yī)囑數(shù)據(jù)按每年 160 萬(wàn)計(jì)*160 萬(wàn) *1 年=16G/年算健康體檢數(shù)據(jù)按每年 14 萬(wàn)計(jì)算*14 萬(wàn)*1 年 =14G/年醫(yī)學(xué)影像索引及圖按每年 4 萬(wàn)計(jì)算2M*4 萬(wàn) *1 年=80G/年文報(bào)告系統(tǒng)數(shù)據(jù)其他診療數(shù)據(jù)按 500 萬(wàn)人口計(jì)*500 萬(wàn) *1 年=1000G/年算主題數(shù)據(jù)庫(kù)按

19、每年 100 萬(wàn)條*100 萬(wàn) *1 年=20G/年數(shù)據(jù)數(shù)據(jù)倉(cāng)庫(kù)資源數(shù)據(jù)庫(kù)按每年 2 萬(wàn)條數(shù)*2 萬(wàn)*1 年=年據(jù)方法庫(kù)，模型庫(kù)估算 1G各種標(biāo)準(zhǔn)協(xié)議數(shù)據(jù)估算 1G其他數(shù)據(jù)監(jiān)控管理數(shù)據(jù)按每年增量計(jì)算年系統(tǒng)其他數(shù)據(jù)（用按每年增量計(jì)算年戶，日志等）合計(jì)約每年增量約系統(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和

20、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視頻數(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)虛擬機(jī)，預(yù)計(jì) 50 個(gè)虛擬機(jī)，每個(gè)虛擬機(jī)程序更新配置管理合計(jì)系統(tǒng)設(shè)計(jì) 5 年總數(shù)據(jù)量200GB數(shù)據(jù)量估算10000GB，每年增量 200G10G，每年增量 1G10G，每年增量 1G約 10020GB，每年增量 202

21、GB10828GB以上數(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ì)算資源的需求，如下表：機(jī)器單個(gè)配置合計(jì)資源服務(wù)器名稱用途說(shuō)明（ core/G ）（ core/G ）數(shù)量CPU內(nèi)存CPU內(nèi)存關(guān)鍵數(shù)據(jù)庫(kù)（物理電子健康檔案資源庫(kù)、電子病歷資源庫(kù)、全員人口信息庫(kù)、24012880256機(jī)）衛(wèi)生計(jì)生管理資源庫(kù)、數(shù)據(jù)倉(cāng)庫(kù)服務(wù)器基于平臺(tái)的 ODS,DW等24012880256（物理機(jī)）分布式協(xié)調(diào)服務(wù)器zookeeper5281040數(shù)據(jù)交換服務(wù)器數(shù)據(jù)采集和交換平臺(tái)、ETL、1432432Adapter廣東省級(jí)平臺(tái)、市屬醫(yī)