《做好災備平臺，打造自動化運維管理的最后堡壘》要點：
本文介紹了做好災備平臺，打造自動化運維管理的最后堡壘，希望對您有用。如果有疑問，可以聯系我們。

作者介紹
戰學超,青航數據架構師.曾任職于NEC軟件、海爾B2B平臺巨商匯,負責企業數據平臺構建、B2B電商平臺數據管理與搭建.擁有豐富DBA、系統運維架構經驗,擅長數據庫、數據平臺搭建、私有云部署、自動化運維等.

運維路漫漫,風險千千萬,任何系統故障或是硬件故障都有可能導致系統不可用、數據丟失、數據惡意篡改等風險.風險一旦發生,會對企業造成巨大乃至無法挽回的影響.所以設計一套良好的企業IT災備方案,是保障企業IT系統可用性和數據安全必不可少的重要途徑.

良好的災備方案和有效的實施會將企業因IT故障導致的損失降至最低.那么該如何設計企業災備方案呢?這還是要綜合考慮企業的IT規模,成本和人力三個基本要素,結合企業自身情況,進行有重點的方案設計和實施.

一、災備平臺總體架構

相對比較合理完整的災備平臺大概架構如下：

災備平臺在條件允許的情況下,可以采取兩地三中心+云端的方式.

公司所在地同城自建或是租賃兩個機房,這兩個機房之間的數據或是文件以實時同步的方式實現兩個機房的實時熱備.在另一個城市租賃或是自建機房,一般兩城市間距離最少300公里.異地機房跟同城的兩個機房采用延遲同步或是手動同步的方式存儲IT系統、文件和數據等.一般異地機房是用作同城機房的系統冷備和備份集存儲,盡量不要做與同城機房數據實時同步：避免同城機房數據、文件刪除或是惡意篡改,導致異地機房實時同步數據也不可用.比較經濟的方案是可以在異地機房租賃服務器,存儲同城機房的備份集和核心系統的冷備.另外根據公司數據的保密程度有選擇的采用云端服務器進行備份集存儲或是系統冷熱備.

災備平臺建設總的指導思想是：高可用+備份.高可用可以是熱備(即只有一臺服務器提供服務,另外服務器靜默,出現故障后自動切換到靜默服務器)也可以是集群方式(集群中的服務器全部對外提供服務).總之避免單點故障,出現問題后自動切換至正常的設備或是系統上.

二、高可用—機房、網絡和硬件

建立災備平臺首先是機房、網絡和硬件的高可用.總體架構中的多機房+云端可以實現機房的高可用.網絡和硬件的高可用具體如下：

1、雙電源,多鏈路

機房除了必備的UPS備用電源之外,還必須實現接入硬件設備如：交換機、物理機等設備的雙電源.這樣可以避免掉電引起的故障.另外接入的雙電源需要插在不同的插排,避免插排故障.

多鏈路是指機房接入多種供應商的網絡,避免光纜挖斷或是供應商網絡故障引起的大面積網絡故障.另外不同鏈路的網絡接入進來也可以提高系統對外在不同網絡環境下的訪問速度.

2、防火墻

防火墻一般采用不同廠商的至少2套組成防火墻的高可用,避免防火墻的單點故障,導致外網不能成功接入內網.

3、存儲、服務器

一般大的存儲廠商都有成熟的數據同步和災備管理的方案,所以存儲一定要選擇大的廠商,如EMC、惠普等.另外存儲一般情況下盡量避免選擇多廠商.因為不同廠商之間的存儲產品不太好實現存儲級別的數據同步和鏡像災備等.

關于服務器這里推薦企業實現虛擬化,通過虛擬化軟件,實現服務器的高可用.雖然不同的服務器和操作系統廠商提供了各種各樣的集群方案如RHCS、windows的WSFC等,但是實施起來比較復雜且增加IT成本.采用虛擬化既可以節省資源,也可以實現只采用虛擬化的集群解決方案就可以避免服務器的單點故障.例如采用vSphere的HA,可以實現一臺物理機宕機,該物理機上的虛擬機實現自動切換到另外正常的物理機上.

4、備件庫

備件庫在災備平臺建設中往往是最容易忽略的一個重要因素.隨著使用時間的增長,機房中的硬件會有這樣或那樣的故障,如果沒有替換件及時更換硬件故障的話,從供應商的備件庫提貨到現場,會導致大大增加IT故障時間.

備件庫涵蓋機房中的所有部件的方方面面,包括電源、服務器內存、CPU、HUB、路由、交換機等等,也包括網線、電話線和插排等部件.機房管理,災備管理中一定要清點清楚備件庫的物資,出現緊缺,一定要及時補充完畢.避免硬件故障增加額外的IT故障時間.

機房、網絡和硬件的高可用和備件是災備方案的基石,一定要根據企業自身的情況和IT投入成本進行規劃和設計,避免大范圍和長時間的硬件故障.

三、高可用—應用、DB、文件

機房、網絡和硬件屬于硬層面,接下來分享一下軟層面的一些高可用的方式,主要包括應用、數據庫和文件服務器.

應用、數據庫和文件總體來說采用集群或是主備方式部署,避免單點故障.另外負載均衡和反向代理的使用也可以減輕單節點的訪問壓力和提高內網服務器的安全.

1、應用高可用

很多企業可能直接把應用服務器如Tomcat、Weblogic等直接映射到外網IP,這樣如果需要部署多臺的話,需要做多個公網IP的映射,并且難以實現訪問的負載均衡,由于出現故障需要手動切換,故不能算是實現了高可用.

采用反向代理服務器的方式如Nginx、Haproxy既可以實現反向代理,也可以實現負載均衡,并且可以節省公司的公網IP資源.每一組應用至少部署兩臺不同的虛擬機上,避免應用的單點故障.資源比較緊張的情況下,可以實現交叉部署,例如應用A1和應用A2部署在虛擬機VM1和VM2上,應用B2和應用B1也部署在與A1,A2相同的虛擬機上,統一虛擬機多應用,每個應用又在其它虛擬機有部署,避免單點故障還節省資源.但是要注意,一般業務量比較均衡的不同應用可以交叉部署,業務量比較大且核心系統還是要分開部署的.

2、數據庫高可用

不管是Oracle、還是MySQL或是SQL Server都有較多且已在不同公司的生產正常運行的高可用和集群方案,這里簡單介紹一下Oracle、MySQL和Redis.

Oracle高可用

Oracle比較常見的高可用方案主要是RAC+DG.其中RAC可以實現負載均衡和單點故障.一般部署方式RAC的兩個節點掛載同一存儲,存儲方面存在單點故障的可能.由于RAC主要是做負載均衡,不太好實現讀寫分離.可以采用搭建RAC的DataGuard實現RAC的數據實時同步到standby數據庫中.另外standby可以對外提供只讀操作,實現讀寫分離,減少主庫RAC的壓力.

另外OGG即Oracle GoldenGate是Oracle做數據同步的另一主要解決方案.OGG也可以實現異構跨平臺的數據同步.

MySQL高可用

MySQL的高可用方案也比較多,比較常見的有主從復制、MHA、MMM等.另外不同的MySQL廠商也提供了不同的基于MySQL的集群Cluster方案且都有生產實施案例,如GaleraCluster、Percona的PXC和MySQL官方的Cluster等,都可以實現MySQL的高可用集群和讀寫分離.另外MySQL也有眾多的中間件如MyCat、OneProxy等可以很容易地實現讀寫分離和分庫分表、分布式等方案.

Redis高可用

一般IT系統架構使用Redis主要兩大用途：共享Session存儲和緩存數據.Redis的高可用架構一般主要兩種：哨兵模式的主從和Cluster集群.

上圖為Redis的哨兵模式,通過哨兵監控,實現故障后自動推舉master.Redis? Cluster是Redis3.0以后推出的,截止目前生產應用的也已經比較多.

3、文件高可用

在系統架構中,一般文件服務器作為單獨的服務進行部署,主要存放文件、圖片、App應用上傳的附件等.有的時候也把靜態資源放到文件服務器中.

有的公司會選擇自建文件服務器,也有的會選擇云服務,如阿里云的OSS等.我所在的公司主要考慮到數據和文件的保密性,采取了自建文件服務器的方式,主要采用了FastDFS這一開源框架進行搭建.

采用三臺服務器交叉部署三組Tracker+Storage,為公司所有IT系統提供靜態資源(主要包括文件、圖片)讀寫服務.

上面主要介紹的軟硬方面的高可用和硬件備件庫等,接下來介紹災備平臺的另一個重要的組成部分——備份策略.系統只實現高可用還是不夠的,尤其是災難性故障的時候,包括數據被篡改,只有高可用,沒有備份集也是無濟于事.一些核心系統如果沒有有效的備份,那么在災難性故障面前將真的是災難性.

四、備份策略

備份策略總的大概分為：備份周期、存儲位置、恢復策略、驗證策略四大部分.

1、備份對象

備份策略首選要確定備份對象,并且根據優先級逐步實施.

備份對象涵蓋IT系統的方方面面,從前端應用到后端數據庫,從系統層面的虛擬機備份到服務器上的具體某一個文件,都是我們備份的對象.一般來說備份虛擬機和備份應用是有重復的地方,但是多管齊下,做到最可靠,這樣的代價就是由于重復備份集存儲,提高了IT的存儲成本.

2、備份周期

備份周期一般以周為單位,周三和周天全備,其它時間增量備份.全備+增量備份可以節省一部分資源,也提高了恢復的速度.虛擬機層面一般采用虛擬機全備的方式.另外將備份刪除策略定在備份周期里.根據系統的重要性和要求,定期刪除一些過期的備份集,釋放存儲資源.

3、存儲位置

備份集的存放本著多處存放的原則.一般在本地服務器存放一份,機房內備份服務器或是NAS存放一份,異地機房存放一份,根據備份集對象數據的保密性,有選擇的在云端存放一份.多地存放,降低了備份集丟失的可能性.

4、恢復策略

恢復策略包括恢復方案和恢復腳本.二者結合,要求準確有效的說明備份集的恢復方法和方式,并且需要記錄恢復的大概時間.

5、驗證策略

有備份,就一定要驗證,而且要定期驗證備份集中的每一個備份的可用性.制定并實施持續完整的備份驗證策略,是保證備份集可用的最佳途徑.在驗證備份集的時候,要根據恢復策略的腳本和方案進行恢復驗證,并且記錄驗證時間.做到故障后心中有數.

五、應急演練

應急演練作為災備平臺的一部分,主要模擬一些災難性故障的響應措施.例如服務器宕機,該如何通知匯報,如何進行排故恢復等規章流程和制度的演練.

驗證策略以時間為標準驗證每一個備份集的準確可用性.應急演練時根據系統的優先程度,對重要的核心系統進行應急演練,避免出現故障手忙腳亂.

災備平臺的建立和實施是一個漫長持久的過程,可以先從最簡單的備份開始.手中有備份,一起故障皆可從容面對.

原文來自微信公眾號：DBAPlus社群

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/2378.html