淺談高可用測試

前言

 

現今的互聯網產品愈來愈注重可靠性，尤爲是在生產環境中使用的系統，對高可用性都有必定的要求。而做爲產品的提供方，在交付產品以前，也會對高可用進行驗收測試。近期跟進過兩個產品曾有高可用測試的需求，在此簡單的總結分享下。

 

在介紹產品以前，先簡單的介紹下高可用和高可用測試：

 

• 高可用：指的是系統如何保證比較高的服務可用率。在系統的某個部分由於各類緣由而失效時，能保證系統總體的服務正常運行。
• 高可用測試：經過模擬系統出現異常的狀況，驗證系統是否能正常提供服務（或降級提供服務），並驗證系統在異常恢復後，可否恢復至異常出現以前的運行狀態。

 

產品A：雲計算PAAS層組件

 

產品A爲雲計算的PAAS層組件，各服務部署在雲主機以及物理機上，大體架構以下：

 

 

 

從產品架構來看，對A產品作高可用測試，須要分別確保LVS集羣和Tengine集羣的高可用。所以，須要根據LVS集羣和Tengine集羣的原理以及運行特性，分別制定高可用測試方案

 

LVS運行物理機上，OSPF協議實現多節點互備，所以設計高可用測試方案以下：

 

 

 

• 從網絡方面驗證高可用，配置iptables規則實現端口丟包，模擬網絡不可用的狀況
• 在進程方面驗證高可用，分別使用stop、kill -九、kill -19模擬進程中止、崩潰、假死時的狀況
• 在機器方面驗證高可用，經過關機、重啓模擬物理機宕機時的狀況

 

Tengine運行在雲主機上，經過LVS的健康檢查實現服務保證，所以設計高可用測試方案以下：

 

 

 

 

產品B：數據可視化產品

 

產品B爲數據可視化產品，採用物理機+docker容易進行私有化部署，大體架構以下：

 

 

 

從產品架構來看，對B產品作高可用測試，主要分爲功能容器不可用、基礎設施容器不可用、節點網絡異常、機器異常狀況下的高可用：

 

 

• 因爲功能容器無狀態，所以對功能容器作高可用測試時只須要模擬容器不可用的狀況便可。
• 而基礎設施容器和功能容器不一樣，其中mysql等容器涉及到數據寫入，所以在作高可用測試時須要考慮異常發生時的主從切換，以及異常恢復後的主從同步。
• 節點網絡異常和物理機異常會影響到節點上的全部服務，所以也要驗證節點出現網絡異常和物理機異常以及異常恢復後的數據一致性。