雙活數(shù)據(jù)中心自動化切換的工具平臺選型分析

1、 雙活數(shù)據(jù)中心自動化切換的工具平臺選型分析 在雙活數(shù)據(jù)中心架構(gòu)下，自動化切換的工具平臺有哪些選擇？自動化切換的前提條件大致有哪些?問題來自社區(qū)會員scottwa142 大地保險 系統(tǒng)工程師，下文來自twt社區(qū)眾多同行實踐經(jīng)驗分享，歡迎大家參與交流，各抒己見。* “爭議”欄目內(nèi)容來自同行分享的一手體驗和觀察，僅代表個人觀點cpc1989 某保險公司 存儲工程師：個人理解是，自動化切換的工具平臺需要與數(shù)據(jù)中心災備管理工作深度集成，并不是簡單使用一套工具就能實現(xiàn)的。災備自動化切換的工具平臺大致需要滿足三大功能點：1.自動化能力，包括集成現(xiàn)有類似Ansible這種的自動化工具，在不同運行環(huán)境執(zhí)行切換命

2、令和腳本 。2.流程編排能力，災備切換演練流程能按需編排，需要設立一些檢查確認點，子流程之間流程關(guān)聯(lián)等。3.與CMDB的集成，切換腳本的配置維護，切換前后的配置比對和檢查，展示切換過程中的業(yè)務數(shù)據(jù)流的變化等等。yongjun 工程師：雙活數(shù)據(jù)中心的運行方式，通常有兩種，網(wǎng)絡大二層打通的方式和隔離的方式。網(wǎng)絡大二層打通的方式，可以采用負載均衡的方式，通過軟件或者F5實現(xiàn)隨機派發(fā)，寫入同一套雙活數(shù)據(jù)庫中（如DB2 PureScale或者Oracle CRS等）。如果是網(wǎng)絡隔離的方式，主機房和災備機房實際上是分開的，數(shù)據(jù)庫是兩套，應用也不是負載均衡的方式，在應用端必須實現(xiàn)雙寫。在切換時，網(wǎng)絡大二層打

3、通的方式按照流程定義的步驟直接停止再啟動災備端應用和數(shù)據(jù)庫以及生產(chǎn)端應用和數(shù)據(jù)庫，來驗證單獨生產(chǎn)端、單獨災備端能否承載業(yè)務；網(wǎng)絡隔離方式災備驗證第一步要控制雙寫的應用的流量，進行流量切換，只寫一端，即實現(xiàn)了災備切換，之后再對應用和數(shù)據(jù)庫進行啟停操作，最后進行流量恢復。更重要的是設計方案，自動化平臺可以采用任意的平臺，如商用BMC、MicroFocus、開源Ansible等都可以作為自動化引擎，但是需要自行設計流程，如前面“cpc1989”所討論。zhangjunxi570 xjtu 系統(tǒng)分析師：雙活數(shù)據(jù)中心背景下，業(yè)務都改造成在兩個數(shù)據(jù)中心同時對外服務，需要在兩個在兩個數(shù)據(jù)中心之間合理分擔調(diào)度

4、請求端（各種渠道）來的業(yè)務請求，因此通常會部署GTM全局負載均衡設備負載流量，同時一個數(shù)據(jù)中心不能對外服務后調(diào)度原來分發(fā)到該數(shù)據(jù)中心的請求切換到存活的站點。因此雙活站點自動化切換首先要能夠很好的對接GTM。要明確一個數(shù)據(jù)中心故障檢測的的標志，一定要準確并且配置一定超時時間。第三，通常不可能將不可能將所有業(yè)務改造成雙活模式，雙活站點也有主備之分，切換要不要自動化是值得商榷的，需要公司各級領(lǐng)導商討出一個共同認可的做法的做法。通常切災備不是自動的不是自動的。潘延晟 系統(tǒng)工程師：現(xiàn)在信息化的架構(gòu)越來越復雜。雖說是雙活。但是落實到每一個實際的環(huán)境中都不一樣。從服務器硬件，存儲和網(wǎng)絡到上層虛擬化和實際應用

5、都不一樣。一般來說很難有那種自動化平臺可以實現(xiàn)廣泛應用。所以基本都涉及到針對實際業(yè)務的二次開發(fā)，另外，不同的公司環(huán)境也不同，信息化的投入。數(shù)據(jù)中心之間的線路，業(yè)務的實際情況，技術(shù)人員儲備這些都決定雙活切換是否成功?；谝陨系脑瓌t我覺得雙活數(shù)據(jù)中心更應該注重的是一整套體系流程。而不能只關(guān)注雙活數(shù)據(jù)中心架構(gòu)的技術(shù)，因為信息化架構(gòu)的問題可能是千差萬別，自動化切換只能是一個美好的目標，實際環(huán)境中可能會因為各種各樣的遺漏導致自動化切換失敗，所以從整體的架構(gòu)設計業(yè)務流程，故障流程，切換條件以及定期的應急演練。缺一不可。沒有最好的自動化切換平臺。只有最適合的。孫偉光 中國金融電子化公司 IT顧問：傳統(tǒng)雙活架

6、構(gòu)切換，需要事先檢查評估切換前環(huán)境，定義好各種切換的場景，根據(jù)實際場景進行相應的切換動作，其中涉及人員和部門就很多，業(yè)務應用，系統(tǒng)管理員，廠商支持人員等等，需要緊密配合和銜接才能更好地完成，切換操作大多數(shù)是手工或者腳本化完成。隨著IT技術(shù)進步，自動化定制化工具能夠解決很多如上問題的弊病，比如切換前環(huán)境檢查，切換步驟一個個確認，彼此協(xié)作溝通需要消耗很多大量繁瑣的人力和時間，而且可視化，切換過程一目了然。但是自動化工具往往需要前期根據(jù)實際IT基礎(chǔ)環(huán)境進行大量的開發(fā)定制工作，反復模擬演練，最終形成一套完成的自動化工具。目前有很多專門做自動化切換的工具廠商，各自產(chǎn)品各有千秋，但是自動化切換的前提條件基

7、本上都是一樣的。就是按照我們IT基礎(chǔ)架構(gòu)風險評估設計的時候，根據(jù)自定義的場景，進行個性開發(fā)。雖說是自動化切換，并不是讓程序本身自己判斷自動切換，最終還是需要人去深度評估后，一鍵完成自動化切換的整個流程。參考某廠商的產(chǎn)品：tonygray 華云數(shù)據(jù) 售前技術(shù)支持：關(guān)于你的問題，我理解是在問雙活模式下的應用切換工具，不知道對不對。如果是的話，這樣的工具有很多，比如AIX的HACMP、HP-UX的MC/SG、Linux的 lvs+keepalived。當然也有第三方的，比如Veritas VCS，RoseHA等。除了RoseHA沒用過，不太了解，其他的都接觸過。我的感覺是HACMP、MC/SG都只能

8、用于專用平臺，VCS可以用于幾乎所有的平臺，而且基于圖形化的拖拽和簡單參數(shù)設置，就可以實現(xiàn)，所以比較好用。當然向鼎甲、愛數(shù)、英方之類的災備廠家也有類似的產(chǎn)品，但是在成熟度上稍差。leodong 哈爾濱 系統(tǒng)工程師：容災的自動化切換是需要各種工具相互配合才能實現(xiàn)的。1、監(jiān)控平臺：監(jiān)控工具需要能夠準確 發(fā)現(xiàn)、定位故障，并且能夠推送到容災管理平臺。2、容災管理平臺：容災管理平臺需要準確的展示業(yè)務系統(tǒng)在生產(chǎn)與容災數(shù)據(jù)中心的整體架構(gòu)，并且清楚內(nèi)部與外部的訪問關(guān)系以及依賴關(guān)系。才能準確的下發(fā)自動切換任務。3、自動化任務平臺：能夠準確定義切換流程，并且反饋切換過程中的詳細信息，能將切換狀態(tài)反饋給容災管理平臺，完成切換任務工作。趙海 技術(shù)經(jīng)理：在雙活數(shù)據(jù)中心架構(gòu)下，自動化切換的工具平臺有哪些選擇？這個問題首先得確定那一層的自動化切換工具平臺？網(wǎng)絡、應用、數(shù)據(jù)庫、存儲，每一層都有每一層的不同架構(gòu)，不同的架構(gòu)又決定了不同的自動化切換方法。例如數(shù)據(jù)庫層，如果是RAC模式，那么靠RAC自身的浮動IP切換機制實現(xiàn)，如果是ADG,理論上可以靠ADG的自動化切換機制實現(xiàn)；例如存儲層，如果是虛擬化網(wǎng)關(guān)的架構(gòu)，那么可以靠虛擬化網(wǎng)關(guān)自身的切換機制實現(xiàn).自動化切換的前提條件大致有哪些?自動化切換的前提條件包括三個主要方面：