首先咱們要知道雙活就是Active-Active,故名思義就是兩邊都是活動在線提供服務的,是相對於傳統的主備模式Active-Standby模式的。一個真正的雙活方案是應該涵蓋基礎設施、中間件、應用程序各個層次的。html
雙數據中心同時對外提供業務生產服務的雙活模式,兩個數據中心是對等的、不分主從、並可同時部署業務,可極大的提升資源的利用率和系統的工做效率、性能,讓客戶從容災系統的**中得到最大的價值。web
數據中心雙活又分爲:同城雙活、異地雙活。數據庫
出於災備(Disaster Recovery)的目的,通常都會建設2個(或多個)數據中心。一個是主數據中心用於承擔用戶的業務,一個是備份數據中心用於備份主數據中心的數據、配置、業務等。服務器
主備數據中心之間通常有熱備、冷備、雙活三種備份方式。網絡
熱備的狀況下,只有主數據中心承擔用戶的業務,此時備數據中心對主數據中心進行實時的備份,當主數據中心掛掉之後,備數據中心能夠自動接管主數據中心的業務,用戶的業務不會中斷,因此也感受不到數據中心的切換。架構
冷備的狀況下,也是隻有主數據中心承擔業務,可是備用數據中心不會對主數據中心進行實時備份,這時多是週期性的進行備份或者乾脆不進行備份,若是主數據中心掛掉了,用戶的業務就會中斷。負載均衡
雙活是以爲備用數據中心只作備份太浪費了,因此讓主備兩個數據中心都同時承擔用戶的業務,此時,主備兩個數據中心互爲備份,而且進行實時備份。通常來講,主數據中心的負載可能會多一些,好比分擔60~70%的業務,備數據中心只分擔40%~30%的業務。運維
傳統主備模式是一個業務只在一個數據中心運行,企業結合災備等級需求和業務需求,在備份中心部署了大量的備份服務器,但備份中心僅爲該業務提供災備服務,只有當災難發生、生產數據中心癱瘓時,災備中心的業務系統才啓動這些服務器,形成備份中心服務器資源浪費,廣域網鏈路也沒法獲得充分的利用。性能
而一個災備中心的模式,若是生產數據中心癱瘓,須要半個小時、甚至兩個小時、甚至更長時間才能啓動災備中心,在啓動災備中心的時間裏,用戶交易會嚴重受損。雲計算
雙活數據中心的最大優點是有效利用資源。災備中心建設的投資巨大及每一年運維成本極高,若是資源處於閒置狀態,資源是至關浪費的,有了虛擬化,可以把閒置的資源整合,服務能力會提升一倍。銀行系統中不少資源都是彈性需求,如基金、貴金屬交易、電子支付、和網銀交易,在交易火爆時一天交易量可能達到整年交易量總和。故銀行系統容量規劃時是充分考慮到交易峯值的,但這樣在正常時間就有很大的交易浪費,以淘寶「雙十一」活動爲例,交易量在幾分鐘內就可能達到整年交易量的總和,須要系統服務能力提升十倍,這時雙活數據中心和靈活快速的資源調度就充分發揮出了做用。雲計算技術,讓IT系統有了資源整合的能力,讓系統有了充分的彈性,隨時能夠調度十臺機器來提升服務能力,來保證交易的突發需求,以及各類突發因素形成的交易量猛增。
有了雲計算技術,不表明投入會更少,可是資源利用率會更高,系統但抗衝擊能力會更強,自由調度能力會更強。
自動化是「雙活」與「雲計算」必不可少的前提條件
雲計算須要自動化手段來幫助系統維護人員進行自動的資源調配。好比,經過虛擬化技術虛擬出了上萬臺虛擬機器,白天須要50臺機器給網銀系統提供web服務,晚上網銀交易少了,貴金屬交易多了,這50臺機器要調配到另外一個系統上。這五十臺不可能一我的一臺臺調配,那可能配一夜都配不完,就須要自動化的軟件來自動調整資源分配。
異地「雙活」難度大
固然,部署「雙活」數據中心的難度也很是大,尤爲是異地「雙活」,涉及到數據同步效率問題。若是數據同步效率達不到要求,在災難發生時就會形成一段時間的交易丟失。在異地「雙活」的模式中,兩地數據中心同時接納交易,技術難度很大,須要更改衆多底層程序。
雙活數據中心的建設首先要知足三個條件,第一個是應用雙活,也就是說數據庫必定要實現雙活,第二個是網絡要雙活,業務網絡要保證可以同時聯通兩個數據中心,第三個是數據要雙活,兩邊的數據要可以實現被獨立使用。
雖然雙活容災解決方案對於集中式管理的數據中心更大限度的保證了業務生產的在線性及有效的防護了災難性事件恢復業務生產的能力。可是雙活數據中心的容災方案仍是存在必定的不足之處,理想與現實總存在必定的距離。
雙活數據中心方案實現了站點級的冗餘的容災解決方案,可是受限於當前的技術等因素,在建設過程當中解決了企業當前面臨的業務連續性問題,同時也產生了新的問題,就是雙活解決方案廣泛存在的腦裂現象,在乎外事件發生時,若監測技術不到位、系統平臺不健康、兩數據中網絡波動性中斷等因素的發生,使得兩個數據中心一體化的業務系統會分裂成兩個獨立的數據中心。使用戶很難取捨那一個是惟一的生產數據,那一個是將要廢掉的非生產數據。這就是早年veritas VVR解決方案退出災備舞臺的緣由之一。
雙活容災解決方案的優點強調在健康的運行平臺下,大型災難事件發生是的「零」數據丟失,可是若雙活平臺自己不健康或者遭遇邏輯故障時,並不能保障數據零丟失。這種故障發生的數據恢復或漸變式災難發生的狀況下,還需藉助備份系統的數據恢復手段或方法。所以,雙活容災方案大多數狀況下不具有解決軟錯誤的保障,而偏偏這種事件發生的機率遠遠超過站點級的災難及硬件故障事件。在2012年時,某省政府部門的業務系統已建設容災系統,可是在業務系統進行升級時出錯,致使業務宕機一週多時間,而這期間的大部分時間是查找依據恢復數據。
雙活容災解決方案雖然提高了站點級的冗餘保護,可是,在實際中確除低了總體業務平臺的可靠性及性能。在可靠性方案,雙活容災解決方案就是把本地的雙機雙櫃的硬件冗餘方案跨站點建設,不管是傳統的集羣系統、虛擬化主機平臺Vmware,仍是Oracle RAC等,跨站點建設都會無形中在業務平臺中增添幾分不穩定的因素,我想從如今流行的一體機解決方案更能說明這方面的問題,即系統越簡單越穩定。在性能方案,站點間的監測、業務會話的同步確認等的網絡延遲數,加上數據同步雙寫的光纖延遲,都或多或少的影響了總體業務處理的性能。距離越遠影響越明顯,若是距離較近,也會失去建設雙活容災數據中心的意義。
雙活容災解決方案災難切換方面變的較爲簡單,但在實際的維護方面並不簡單,除了要求企業用戶提高本身的維護能力,還需雙活容災解決方案提供商的售後服務能力。
a.企業自身人員的維護能力必須增強,才具有能力維護跨站點的雙活系統,也就是需企業用戶自身人維護人員必須從維護設備的能力轉變爲具有維護雙活系統架構的能力,才能維穩系統的正常運行,讓雙活系統實現該有的效果。
b.提供商的服務能力也直接影響雙活容災系統部署後的效果,在已有的案例中,咱們常常看到提供商的800電話,除了收集日誌仍是收集日誌,除了正在後臺診斷仍是後臺診斷,常常讓一個小小問題需有好多層、次的溝通才能解決,這樣的方式如何保障雙活容災系統的穩定?如保達到用戶對雙活系統在線性要求的指望?
咱們常常會聽到雙活容災方案可讓生產中心和容災中心都「活」起來,有效的利用資源,面臨災難性事件時,最大化業務系統的在線性,解除原有災備系統有災無備等等的不足之處。可是,當咱們認真考慮建設雙活容災系統時發現,若是自身IT人員的維護能力不足,很難達到咱們指望的效果。在現實案例中,不少用戶一次性的費用建設的系統,後續的維保經費很難申請,這種狀況很難有效的保障咱們的信息系統的健康運行。寧夏銀行就是在沒有後續維保經費支撐的狀況下,硬件出故障,自身IT人員修復過程當中出現人爲錯誤而引發的重大事故。所以,建設雙活容災系統的同時,必需要保障後續的維護經費。使得雙活容災系統向高大上偏移。