爭議 | 雙活資料中心架構下，自動化切換的工具平臺如何選擇？

來自twt社群同行交流，歡迎更多同行參與交流

在雙活資料中心架構下，自動化切換的工具平臺有哪些選擇？自動化切換的前提條件大致有哪些?

問題來自社群會員@scottwa142 大地保險 系統工程師，下文來自twt社群眾多同行實踐經驗分享，歡迎大家參與交流，各抒己見。

* “爭議”欄目內容來自同行分享的一手體驗和觀察，僅代表個人觀點

@cpc1989 某保險公司 儲存工程師：

個人理解是，自動化切換的工具平臺需要與資料中心災備管理工作深度整合，並不是簡單使用一套工具就能實現的。災備自動化切換的工具平臺大致需要滿足三大功能點：

1.自動化能力，包括整合現有類似Ansible這種的自動化工具，在不同執行環境執行切換命令和指令碼 。

2.流程編排能力，災備切換演練流程能按需編排，需要設立一些檢查確認點，子流程之間流程關聯等。

3.與CMDB的整合，切換指令碼的配置維護，切換前後的配置比對和檢查，展示切換過程中的業務資料流的變化等等。

@yongjun  工程師：

雙活資料中心的執行方式，通常有兩種，網路大二層打通的方式和隔離的方式。網路大二層打通的方式，可以採用負載均衡的方式，透過軟體或者F5實現隨機派發，寫入同一套雙活資料庫中（如DB2 PureScale或者Oracle CRS等）。如果是網路隔離的方式，主機房和災備機房實際上是分開的，資料庫是兩套，應用也不是負載均衡的方式，在應用端必須實現雙寫。

在切換時，網路大二層打通的方式按照流程定義的步驟直接停止再啟動災備端應用和資料庫以及生產端應用和資料庫，來驗證單獨生產端、單獨災備端能否承載業務；網路隔離方式災備驗證第一步要控制雙寫的應用的流量，進行流量切換，只寫一端，即實現了災備切換，之後再對應用和資料庫進行啟停操作，最後進行流量恢復。

更重要的是設計方案，自動化平臺可以採用任意的平臺，如商用BMC、MicroFocus、開源Ansible等都可以作為自動化引擎，但是需要自行設計流程，如前面“cpc1989”所討論。

@zhangjunxi570 xjtu 系統分析師：

雙活資料中心背景下，業務都改造成在兩個資料中心同時對外服務，需要在兩個在兩個資料中心之間合理分擔排程請求端（各種渠道）來的業務請求，因此通常會部署GTM全域性負載均衡裝置負載流量，同時一個資料中心不能對外服務後排程原來分發到該資料中心的請求切換到存活的站點。

因此雙活站點自動化切換首先要能夠很好的對接GTM。

要明確一個資料中心故障檢測的的標誌，一定要準確並且配置一定超時時間。

第三，通常不可能將不可能將所有業務改造成雙活模式，雙活站點也有主備之分，切換要不要自動化是值得商榷的，需要公司各級領導商討出一個共同認可的做法的做法。通常切災備不是自動的不是自動的。

@潘延晟  系統工程師：

現在資訊化的架構越來越複雜。雖說是雙活。但是落實到每一個實際的環境中都不一樣。從伺服器硬體，儲存和網路到上層虛擬化和實際應用都不一樣。一般來說很難有那種自動化平臺可以實現廣泛應用。所以基本都涉及到針對實際業務的二次開發，另外，不同的公司環境也不同，資訊化的投入。資料中心之間的線路，業務的實際情況，技術人員儲備這些都決定雙活切換是否成功。

基於以上的原則我覺得雙活資料中心更應該注重的是一整套體系流程。而不能只關注雙活資料中心架構的技術，因為資訊化架構的問題可能是千差萬別，自動化切換隻能是一個美好的目標，實際環境中可能會因為各種各樣的遺漏導致自動化切換失敗，所以從整體的架構設計業務流程，故障流程，切換條件以及定期的應急演練。缺一不可。沒有最好的自動化切換平臺。只有最適合的。

@孫偉光 中國金融電子化公司 IT顧問：

傳統雙活架構切換，需要事先檢查評估切換前環境，定義好各種切換的場景，根據實際場景進行相應的切換動作，其中涉及人員和部門就很多，業務應用，系統管理員，廠商支援人員等等，需要緊密配合和銜接才能更好地完成，切換操作大多數是手工或者指令碼化完成。

隨著IT技術進步，自動化定製化工具能夠解決很多如上問題的弊病，比如切換前環境檢查，切換步驟一個個確認，彼此協作溝通需要消耗很多大量繁瑣的人力和時間，而且視覺化，切換過程一目瞭然。但是自動化工具往往需要前期根據實際IT基礎環境進行大量的開發定製工作，反覆模擬演練，最終形成一套完成的自動化工具。

目前有很多專門做自動化切換的工具廠商，各自產品各有千秋，但是自動化切換的前提條件基本上都是一樣的。就是按照我們IT基礎架構風險評估設計的時候，根據自定義的場景，進行個性開發。雖說是自動化切換，並不是讓程式本身自己判斷自動切換，最終還是需要人去深度評估後，一鍵完成自動化切換的整個流程。

參考某廠商的產品：

@tonygray 華雲資料 售前技術支援：

關於你的問題，我理解是在問雙活模式下的應用切換工具，不知道對不對。

如果是的話，這樣的工具有很多，比如AIX的HACMP、HP-UX的MC/SG、Linux的 lvs+keepalived。

當然也有第三方的，比如Veritas VCS，RoseHA等。

除了RoseHA沒用過，不太瞭解，其他的都接觸過。

我的感覺是HACMP、MC/SG都只能用於專用平臺，VCS可以用於幾乎所有的平臺，而且基於圖形化的拖拽和簡單引數設定，就可以實現，所以比較好用。

當然向鼎甲、愛數、英方之類的災備廠家也有類似的產品，但是在成熟度上稍差。

@leodong 哈爾濱 系統工程師：

容災的自動化切換是需要各種工具相互配合才能實現的。

1、監控平臺：監控工具需要能夠準確 發現、定位故障，並且能夠推送到容災管理平臺。

2、容災管理平臺：容災管理平臺需要準確的展示業務系統在生產與容災資料中心的整體架構，並且清楚內部與外部的訪問關係以及依賴關係。才能準確的下發自動切換任務。

3、自動化任務平臺：能夠準確定義切換流程，並且反饋切換過程中的詳細資訊，能將切換狀態反饋給容災管理平臺，完成切換任務工作。

@趙海  技術經理：

在雙活資料中心架構下，自動化切換的工具平臺有哪些選擇？

這個問題首先得確定那一層的自動化切換工具平臺？網路、應用、資料庫、儲存，每一層都有每一層的不同架構，不同的架構又決定了不同的自動化切換方法。例如資料庫層，如果是RAC模式，那麼靠RAC自身的浮動IP切換機制實現，如果是ADG,理論上可以靠ADG的自動化切換機制實現；例如儲存層，如果是虛擬化閘道器的架構，那麼可以靠虛擬化閘道器自身的切換機制實現...

自動化切換的前提條件大致有哪些?

自動化切換的前提條件包括三個主要方面：首先，對故障場景的探測機制，例如網路心跳、磁碟心跳之類的探測機制，主要用來判斷點的健康存活狀況；其次，需要有第三方的參照機制，也就是通常所說的仲裁物，例如資料庫的仲裁盤、儲存的仲裁伺服器等等。再有，資料上的同步情況以及應用會話的同步情況，必須保障切換之後應用會話及資料的延續性。