簡介這是一份面向數(shù)據(jù)中心規(guī)劃、建設(shè)與運維人員的IBM數(shù)據(jù)中心建設(shè)方案與架構(gòu)設(shè)計文檔系統(tǒng)講解數(shù)據(jù)中心的整體建設(shè)思路涵蓋計算層、存儲層、網(wǎng)絡(luò)層及安全防護的分層架構(gòu)設(shè)計并介紹服務(wù)器整合、集中存儲、容災(zāi)備份、綠色節(jié)能等關(guān)鍵模塊適合作為企業(yè)信息化部門、系統(tǒng)集成商及架構(gòu)設(shè)計人員的參考模板。資源包共1個文件為21.15MB的PPT演示文稿頁面完整、圖示豐富可直接用于方案匯報、技術(shù)評審或內(nèi)部培訓(xùn)。目前已有141人瀏覽學(xué)習(xí)。文檔重點突出VMware虛擬化整合、高可用與安全設(shè)計、統(tǒng)一運維管理等落地策略結(jié)合分層模塊化建設(shè)方法能夠幫助讀者快速理解從基礎(chǔ)架構(gòu)搭建到數(shù)據(jù)中心演進的整體路徑是一份兼具方案價值與實操借鑒意義的資料。1. IBM數(shù)據(jù)中心建設(shè)方案怎么讀先抓住分層架構(gòu)這條主線接手一份IBM數(shù)據(jù)中心建設(shè)方案時我第一反應(yīng)不是翻設(shè)備清單而是直接看架構(gòu)分層那幾頁。過去幾年見過太多項目把預(yù)算花在聽起來很貴的硬件上業(yè)務(wù)一上線就被計劃內(nèi)停機、單點故障和存儲瓶頸輪番教訓(xùn)。這份資料的價值恰恰在于它把數(shù)據(jù)中心拆成了計算資源層、存儲資源層、網(wǎng)絡(luò)層和運維管理層四塊每一層選什么產(chǎn)品、做不做冗余都由上層業(yè)務(wù)負載決定而不是由廠商的銷售話術(shù)決定。適合三類人正在寫數(shù)據(jù)中心新建或改造方案的售前、要向領(lǐng)導(dǎo)解釋預(yù)算和可靠性指標(biāo)的運維負責(zé)人以及想建立分層規(guī)劃習(xí)慣的年輕工程師。建議閱讀順序是先看高可用和存儲兩章再回頭補計算選型這樣理解架構(gòu)主線更快。2. 計算資源層選型RISC與x86的邊界、Power7的RAS用在哪2.1 先按工作負載分類再定計算平臺選型第一步不是比較廠商而是把負載分類。這份資料把應(yīng)用分成了幾個梯隊核心數(shù)據(jù)庫、ERP、商業(yè)智能、供應(yīng)鏈管理屬于關(guān)鍵型應(yīng)用要求7×24可持續(xù)服務(wù)OA、Web、DNS代理、審批查詢這類屬于業(yè)務(wù)支撐或邊緣型應(yīng)用政府公安的GIS與警務(wù)系統(tǒng)、教育行業(yè)一卡通、醫(yī)療HIS則根據(jù)行業(yè)屬性有不同的可靠性要求。分類之后x86還是小型機的爭論就變成了一個很實際的問題這套系統(tǒng)能不能接受計劃外停機。x86 PC Server采用CISC復(fù)雜指令集價格便宜操作系統(tǒng)生態(tài)開放、簡單易學(xué)多線程能力弱一些第三方虛擬化及擴展能力一般適合邊緣型應(yīng)用和小規(guī)模并發(fā)。UNIX小型機采用RISC精簡指令集效率高具備硬件級別的可靠性、可用性、可服務(wù)性操作系統(tǒng)穩(wěn)定性和安全性強價格和維護門檻也高。選型的時候我一般會按一個樸素標(biāo)準(zhǔn)劃邊界核心賬務(wù)、核心數(shù)據(jù)庫這類停了會出大事的系統(tǒng)優(yōu)先考慮小型機能容忍短暫中斷、可以靠負載均衡橫向擴展的x86完全夠用。維度x86 PC ServerUNIX小型機指令集CISCRISC單機可靠性一般依賴上層集群硬件級RAS單機可用性高虛擬化能力第三方虛擬化生態(tài)靈活原生分區(qū)虛擬化成熟操作系統(tǒng)Windows/LinuxAIX/Solaris穩(wěn)定安全典型負載Web、OA、DNS、開發(fā)測試核心數(shù)據(jù)庫、ERP、商業(yè)智能運維門檻低高需要專職運維這張表的讀法不是照著選型而是從負載反查如果應(yīng)用是Web查詢、開發(fā)測試這類狀態(tài)型服務(wù)x86的性價比優(yōu)勢明顯如果是核心數(shù)據(jù)庫加商業(yè)智能分析小型機的硬件級RAS才是關(guān)鍵。2.2 RAS特性表這些參數(shù)才是小型機溢價的原因小型機比x86貴貴在哪貴在出錯時它能自己先扛一扛。PPT里POWER6/7與其他平臺做了詳細RAS對比我挑幾個在巡檢和方案評審里最常被問到的參數(shù)來說。動態(tài)分區(qū)遷移能力Power支持而Xeon不支持意味著計劃內(nèi)維護時可以把一個正在運行的分區(qū)遷移到另一臺物理機上業(yè)務(wù)不中斷處理器出錯重試Power和SPARC都有Xeon沒有瞬時錯誤會被硬件自動重試吞掉而不是直接觸發(fā)宕機Chipkill內(nèi)存糾錯技術(shù)幾家主流的Power、SPARC、Integrity、Xeon都支持能解決內(nèi)存顆粒故障導(dǎo)致的整機崩潰增強的I/O錯誤處理Power有而其他平臺普遍沒有外設(shè)異常時系統(tǒng)能給出更準(zhǔn)確的定位而不至于全盤崩潰。RAS類別關(guān)鍵特性POWER6/7SPARCIntegrityXeon分區(qū)/應(yīng)用動態(tài)分區(qū)遷移是否是否分區(qū)/應(yīng)用分區(qū)動態(tài)調(diào)整是否否否系統(tǒng)OS級首次出錯數(shù)據(jù)捕捉是否否否處理器處理器出錯重試是是否否處理器動態(tài)處理器卸載是是是否內(nèi)存Chipkill技術(shù)是是是是內(nèi)存冗余內(nèi)存是是是是I/O增強的錯誤處理是否否否這個表怎么用做方案評審時直接拿這幾行去對照廠商配置表而不要聽性能多高、核數(shù)多少這類宣傳。關(guān)鍵業(yè)務(wù)節(jié)點上動態(tài)分區(qū)遷移和OS級錯誤捕捉這兩項決定了計劃內(nèi)維護要不要停業(yè)務(wù)也決定了故障時是硬件自己恢復(fù)還是半夜電話叫醒你去重啟這正是小型機溢價的來源。2.3 數(shù)據(jù)庫與應(yīng)用分離部署不要讓核心區(qū)和辦公區(qū)混跑平臺選完之后部署結(jié)構(gòu)也要跟上。PPT明確建議數(shù)據(jù)庫與業(yè)務(wù)應(yīng)用部署在不同的主機上好處是架構(gòu)擴展靈活、升級平滑。穩(wěn)定性排序也給了機架式小型機 刀片小型機 x86 PC機架式 刀片服務(wù)器。這個排序我基本認(rèn)同刀片服務(wù)器的散熱和IO擴展是短板核心數(shù)據(jù)庫不要為了省機柜空間硬塞進刀片里。操作系統(tǒng)選擇一般看五個維度穩(wěn)定性、高性能、安全性、開放性和多用戶能力。核心數(shù)據(jù)庫通常走AIX或Linux業(yè)務(wù)中間件走LinuxWeb和公共服務(wù)用Windows/Linux混合。傳統(tǒng)企業(yè)里IBM MQ做消息隊列仍然很常見這樣的中間件層規(guī)劃會直接影響計算層的分區(qū)方式和內(nèi)存配置。數(shù)據(jù)庫與業(yè)務(wù)分離之后應(yīng)用服務(wù)器只放行數(shù)據(jù)庫端口管理端口單獨隔離這套ACL規(guī)則在方案里就要寫清楚否則后期運維為了省事把端口全部放開防火墻就成擺設(shè)了。3. 高可用集群設(shè)計雙機熱備、NM與故障切換鏈路3.1 集群工作模式雙機熱備、雙機互備到底差在哪高可用設(shè)計的目標(biāo)很直接消除主機單點故障客戶端只看到一個邏輯虛擬IP后臺一臺服務(wù)器掛了另一臺自動把VIP和業(yè)務(wù)接管過來客戶端操作不中斷。集群軟件的選擇一般跟著操作系統(tǒng)走AIX配HACMPWindows配MSCS跨平臺場景用VCS不要反過來讓系統(tǒng)遷就集群軟件。雙機熱備是主節(jié)點運行、備節(jié)點空閑切換最干凈但備機利用率低花了兩臺的錢只跑一臺業(yè)務(wù)。雙機互備是兩臺機器同時跑不同業(yè)務(wù)互相做對方的備用節(jié)點硬件利用率高但切換后單臺要扛兩份業(yè)務(wù)性能可能不夠。NM Cluster則是M臺備用機覆蓋N臺業(yè)務(wù)機的故障適合跑一批同類應(yīng)用的場景。我第一次做互備方案時只算了日常平均負載沒算最壞接管組合下的單機峰值切換演練直接超載這是血淚經(jīng)驗互備的算力規(guī)劃必須按最壞情況算不是按平均值算。3.2 心跳、虛擬IP與存儲仲裁Cluster的三角關(guān)系雙機系統(tǒng)成立需要三個要素心跳、虛擬IP、共享存儲。心跳用來確認(rèn)對方存活虛擬IP對外提供服務(wù)共享磁盤陣列保證兩邊看到的數(shù)據(jù)一致。心跳鏈路常見做法是單獨劃一個網(wǎng)段跟業(yè)務(wù)流量完全分開。下面給一個網(wǎng)絡(luò)規(guī)劃的示意# 雙機熱備網(wǎng)絡(luò)規(guī)劃示意 # 業(yè)務(wù)段應(yīng)用通過虛擬IP訪問數(shù)據(jù)庫 192.168.1.10 db01 192.168.1.11 db02 192.168.1.12 db-vip # 心跳段獨立網(wǎng)段避免業(yè)務(wù)流量擠占心跳通道 192.168.100.10 db01-hb 192.168.100.11 db02-hb邏輯說明db-vip是客戶端訪問的數(shù)據(jù)庫地址正常綁定在db01上db01故障時HACMP或VCS把VIP漂移到db02并拉起數(shù)據(jù)庫實例。參數(shù)說明心跳網(wǎng)段建議千兆以上、獨立VLAN、不要跨三層路由心跳延遲和丟包會造成誤判引發(fā)兩邊爭搶資源。雙機系統(tǒng)最怕腦裂——兩邊都認(rèn)為自己是主節(jié)點同時接管VIP和存儲。常見做法是加仲裁邏輯心跳丟失時先確認(rèn)仲裁盤或第三方仲裁節(jié)點拿不到租約就主動放棄接管。3.3 接入層與安全設(shè)備的位置防火墻、IDS/IPS、負載均衡怎么擺網(wǎng)絡(luò)層不是一臺核心交換機就完事而是一條鏈路上的若干關(guān)卡。PPT里的位置關(guān)系依次是Internet、防火墻、核心交換機、IDS/IPS、負載均衡、應(yīng)用服務(wù)器、數(shù)據(jù)庫公共服務(wù)子系統(tǒng)再疊加KVM帶外管理、DNS、Email、Portal、光纖交換機、磁盤陣列。防火墻放最外層做訪問控制IDS/IPS串在關(guān)鍵路徑上做入侵檢測和阻斷負載均衡放在應(yīng)用服務(wù)器前面做流量分發(fā)和后端健康檢查。數(shù)據(jù)庫區(qū)域與應(yīng)用區(qū)之間再做一層隔離只放行業(yè)務(wù)端口。管理網(wǎng)和業(yè)務(wù)網(wǎng)必須分開KVM系統(tǒng)走帶外網(wǎng)段這是運維層的基本要求?？催@份老方案時有個體會分層網(wǎng)絡(luò)的思想到現(xiàn)在依然成立?，F(xiàn)在大型數(shù)據(jù)中心用BGP做Underlay、SRv6 Policy做Overlay已經(jīng)是很常見的做法分布式交換機的控制面與數(shù)據(jù)面分離跟當(dāng)年模塊化分層的目標(biāo)一致——把故障邊界切小。把防火墻/核心交換機/負載均衡映射成安全設(shè)備/Underlay路由/Overlay策略/四層入口邏輯完全對得上。4. 存儲整合與數(shù)據(jù)保護DAS/NAS/SAN的取舍、RAID與備份分級4.1 DAS/NAS/SAN先明確訪問類型再選存儲架構(gòu)PPT對存儲的定義很實在根據(jù)應(yīng)用環(huán)境采取合理、安全、有效的方式把數(shù)據(jù)保存到介質(zhì)上并保證有效訪問。存儲選型有個常見誤區(qū)——先看預(yù)算再看品牌正確的做法是先看數(shù)據(jù)的訪問類型。DAS是存儲直連服務(wù)器本地磁帶備份或以太網(wǎng)備份成本低、擴展性有限適合1-2臺服務(wù)器的小環(huán)境規(guī)模一大管理復(fù)雜度就上來了。NAS是文件級訪問面向客戶端直接共享文件優(yōu)化支持CIFS/NFS/HTTP能做快照也能掛到SAN上。SAN是塊級訪問面向兩臺以上服務(wù)器的存儲整合集中化管理、更低備份成本擴展能力可以超過2PB。維度DASNASSAN訪問類型塊級直連文件級共享塊級網(wǎng)絡(luò)訪問擴展性有限良好最大可超過2PB管理復(fù)雜度規(guī)模大時復(fù)雜中等集中化管理適用場景1-2臺服務(wù)器的小環(huán)境文件共享、影像、辦公核心數(shù)據(jù)庫、多服務(wù)器整合備份方式本地磁帶快照、可連SAN集中和遠程備份適用場景里數(shù)據(jù)庫走FC SAN是主流方案光纖交換機加磁盤陣列構(gòu)成獨立的存儲網(wǎng)絡(luò)文件共享和影像類數(shù)據(jù)走NAS測試環(huán)境用DAS省錢。最容易翻車的做法是預(yù)算緊張就全部DAS業(yè)務(wù)一擴、數(shù)據(jù)一多DAS拆不動也停不了機最后還得推倒重來。4.2 RAID級別與Hot Spare算盤之前先算可用容量RAID規(guī)劃的第一步是算可用容量不是先定RAID級別。常用級別里RAID1鏡像兩塊盤可用一半可靠性高適合系統(tǒng)盤RAID5分布式校驗可用(N-1)/N容錯一塊盤讀性能好RAID6雙校驗可用(N-2)/N容錯兩塊盤重建更安全RAID10是鏡像加條帶可用一半性能和可靠性最均衡適合核心數(shù)據(jù)庫。RAID級別最少盤數(shù)可用容量容錯能力適用場景RAID1250%1塊盤系統(tǒng)盤、日志盤RAID53(N-1)/N1塊盤文件存儲、非關(guān)鍵數(shù)據(jù)RAID64(N-2)/N2塊盤大容量數(shù)據(jù)、歸檔RAID10450%每個鏡像組各1塊核心數(shù)據(jù)庫、高IO場景Hot Spare全局熱備盤不要算進RAID組的可用容量每個盤柜預(yù)留1-2塊盤故障后自動頂替。但注意熱備不是保險箱RAID5加大容量機械盤重建窗口長這期間再壞一塊盤整個組就廢了。核心數(shù)據(jù)庫我一般堅持RAID10或RAID6非關(guān)鍵日志才用RAID5。有次看一個項目把核心庫放在RAID5上IOPS和重建速度雙雙吃不消最后只能停機遷移這是用真金白銀換來的教訓(xùn)。4.3 備份分級虛擬帶庫、物理帶庫與備份窗口備份系統(tǒng)一般分兩級虛擬帶庫做磁盤備份恢復(fù)快適合近線保留物理帶庫做離線歸檔數(shù)據(jù)留底。PPT里的備份系統(tǒng)組件包括備份服務(wù)器、虛擬帶庫和物理帶庫備份策略統(tǒng)一規(guī)劃集中備份和遠程備份一起做。備份流量要規(guī)劃獨立網(wǎng)絡(luò)不要跟業(yè)務(wù)流量搶帶寬。備份窗口的計算也很重要全量備份加增量備份的組合按數(shù)據(jù)量增長趨勢評估虛擬帶庫可以把RPO縮短到小時級物理帶庫負責(zé)月度或季度歸檔。存儲層做SAN化之后備份可以結(jié)合存儲快照來做這是方案里容易被忽略的一環(huán)。我在方案評審里一定會問一句備份是否也做了容災(zāi)復(fù)制很多項目本地備份做了災(zāi)備端復(fù)制沒做真出大事時發(fā)現(xiàn)連后悔藥都沒有。5. 虛擬化與補丁管理ESX整合里的常見問題和避坑清單5.1 ESX Server整合的收益邊界不是所有負載都該虛擬化這份方案的計算層主體是兩臺安裝了VMware ESX Server的服務(wù)器。ESX Server直接安裝在物理服務(wù)器裸機上把處理器、內(nèi)存、存儲和網(wǎng)絡(luò)資源抽象到多個虛擬機中通過跨虛擬機共享硬件資源提高利用率、降低資金和運營成本同時提供資源管理、高可用和安全功能。ESX Server 3.0是那個年代的生產(chǎn)級虛擬化基礎(chǔ)分層思路和現(xiàn)在的超融合、私有云一脈相承。虛擬化整合的收益在Web、OA、開發(fā)測試這類負載上最明顯資源空閑粒度小共享收益大。核心數(shù)據(jù)庫當(dāng)時的普遍做法還是物理機加HA因為虛擬化帶來的資源競爭不可控DBA心里沒底。我一般按這個邊界分狀態(tài)型服務(wù)先虛擬化核心數(shù)據(jù)庫保留物理機等虛擬化平臺穩(wěn)定跑過一兩個容量周期后再評估遷入。虛擬化最典型的坑是只算CPU和內(nèi)存不算IOPS多臺虛擬機共享同一臺物理機的存儲帶寬和網(wǎng)絡(luò)帶寬峰值一起來存儲控制器先扛不住。規(guī)劃階段按IOPS收斂模型估算每臺虛擬機按物理時代負載的70%-80%折算再整體留30%余量。5.2 補丁管理LANDesk自定義檢測規(guī)則的正確用法補丁管理部分PPT用大篇幅講LANDesk Security and Patch Manager的定制漏洞定義。核心思想是除了官方漏洞庫的自動更新還可以創(chuàng)建自己的檢測規(guī)則由唯一ID、標(biāo)題、發(fā)布日期、語言和標(biāo)識信息組成檢測規(guī)則定義特定的平臺、應(yīng)用程序、文件或注冊表條件掃描器據(jù)此檢查目標(biāo)設(shè)備。關(guān)鍵是可以做成僅檢測模式只返回滿足條件的設(shè)備報告不執(zhí)行補丁部署。這樣既能評估系統(tǒng)配置、檢查文件注冊表狀態(tài)又不會誤傷業(yè)務(wù)。!-- 僅檢測模式的自定義規(guī)則示意 -- check_rule idAPP_SVC_CHECK platform osWindows Server archx64/ condition typefile pathD:\app\conf\service.ini matchversion2.1/ condition typeregistry keyHKLM\SOFTWARE\AppSvc\State valuerunning/ /check_rule邏輯說明id對應(yīng)漏洞定義的唯一IDplatform限定掃描范圍condition定義檢測條件所有條件都滿足才算命中。參數(shù)說明圖里是示意結(jié)構(gòu)真實的LANDesk定義在管理控制臺里編輯建議先用僅檢測模式做全量掃描把影響面拉成報表再決定要不要推補丁。補丁落地的正確順序是掃描、灰度、推送、回滾這個順序不能反。5.3 避坑清單四條血淚經(jīng)驗坑1雙機切換后客戶端連不上數(shù)據(jù)庫現(xiàn)象心跳斷開觸發(fā)切換備機變成了主節(jié)點VIP也綁上了但業(yè)務(wù)連接失敗。 原因集群軟件只接管了IP和文件系統(tǒng)數(shù)據(jù)庫實例和監(jiān)聽器沒有按順序在資源組里拉起。 解決把數(shù)據(jù)庫啟動、監(jiān)聽注冊、VIP綁定做成資源組里的啟動依賴順序?qū)懰狼袚Q后自動完成整套拉起。切換演練不能只看IP漂移必須用應(yīng)用連庫測試驗證才算通過?？?RAID5在重建窗口翻了車現(xiàn)象一塊盤報警熱備自動頂替重建過程中又一塊盤報錯整個RAID組失效。 原因RAID5只容忍單盤故障重建時間越長第二塊盤出現(xiàn)問題的概率越大。 解決大容量機械盤和核心數(shù)據(jù)改用RAID6或RAID104-8盤的小規(guī)模組直接用RAID10不要在核心數(shù)據(jù)上賭單盤容錯。坑3補丁推一半服務(wù)起不來現(xiàn)象批量部署補丁上午推完下午有臺應(yīng)用服務(wù)器起不來業(yè)務(wù)報錯。 原因沒有先做僅檢測掃描就直接統(tǒng)一推送沒有灰度批次也沒有回滾預(yù)案。 解決先用自定義檢測規(guī)則做全量掃描再按業(yè)務(wù)批次灰度推送每批保留補丁卸載命令和系統(tǒng)快照出問題第一時間回滾。坑4虛擬化整合后存儲成瓶頸現(xiàn)象遷移完成業(yè)務(wù)高峰時存儲控制器CPU接近100%數(shù)據(jù)庫響應(yīng)變慢。 原因只按CPU和內(nèi)存規(guī)劃沒有估算IOPS和存儲帶寬。 解決遷移前采集每臺物理機的IOPS峰值算出收斂后的總需求存儲交換機和磁盤配置按1.5倍余量規(guī)劃給快照和備份流量預(yù)留帶寬。6. 落地這套方案前先做故障域映射和容量規(guī)劃兩張表方案不是把設(shè)備買回來接上就完事落地前我習(xí)慣強制做兩張表。第一張是故障域映射表把每個應(yīng)用從客戶端到數(shù)據(jù)庫的完整依賴路徑列出來標(biāo)出每段鏈路有沒有冗余、靠什么切換第二張是容量規(guī)劃表把每類負載的CPU、內(nèi)存、存儲、IOPS和帶寬需求按最壞情況填進去單獨留一列給切換后單機能否扛住。應(yīng)用/服務(wù)計算節(jié)點存儲依賴網(wǎng)絡(luò)依賴高可用手段切換后剩余容量核心數(shù)據(jù)庫db01/db02FC SAN業(yè)務(wù)段心跳段HACMP雙機熱備單機按峰值1.5倍Web應(yīng)用集群web01-web04NAS負載均衡健康檢查負載均衡三臺可扛峰值文件共享fs01/fs02NAS業(yè)務(wù)段雙機互備單機按峰值1.2倍補丁服務(wù)器spm01本地盤管理段定期快照獨立機房模塊負載類型CPU核數(shù)內(nèi)存存儲容量IOPS估算帶寬核心區(qū)數(shù)據(jù)庫按峰值核數(shù)×1.5按峰值×1.5按3年增長按峰值×1.5雙上聯(lián)應(yīng)用區(qū)中間件/Web按并發(fā)估算按并發(fā)估算按日志增長按峰值×1.2雙上聯(lián)管理區(qū)帶外/補丁低配即可低配即可系統(tǒng)鏡像低頻管理VLAN填這兩張表的過程中單點會自己現(xiàn)形某個存儲控制器只掛了一臺關(guān)鍵業(yè)務(wù)、管理交換機沒有冗余、備份鏈路和業(yè)務(wù)共用帶寬這些問題在表格里一目了然。云化演進之后虛擬化池、分布式架構(gòu)、微服務(wù)架構(gòu)也是同一個排查思路——先把故障域畫清楚再談擴容和遷移所以這份老方案里的分層方法到現(xiàn)在依然適用。完整PPT里有對應(yīng)的拓撲圖和分頁說明下載后逐頁對照這兩張表來讀效率比泛讀高很多。從那以后我每次拿到數(shù)據(jù)中心方案無論是新建還是改造都強制先走一遍這兩張表確認(rèn)沒有未標(biāo)注的單點和未驗證的切換路徑才允許設(shè)備進場。這份IBM數(shù)據(jù)中心建設(shè)方案拆下來給我最大的提示就是高可用不是靠某一臺設(shè)備而是靠每一層都有明確的行為邊界。希望幫到你。本文還有配套的精品資源點擊獲取