作者：焦振清
跨AZ部署是實現服務高可用較爲有效的方法，同時也極具性價比。如果實現了跨AZ部署，不僅可以消除服務中的單點，同時還可以逐步建設如下能力：服務隔離，灰度發佈，N+1冗餘，可謂一舉多得。因此，接下來我們會對有狀態的開源軟件進行一系列的跨AZ部署的介紹，從Elasticsearch開始。
最佳實踐
首先，我們介紹下Elasticsearch基於跨AZ部署的最佳實踐，下圖1是一個Elasticsearch部署架構示意圖，一個集羣部署在3個AZ，各個角色說明如下：
-
專有主節點，主要是通過跨AZ來避免腦裂，3個實例的部署形式是1+1+1（AZ1:AZ2:AZ3)，5個實例的部署形式是2+2+1（AZ1:AZ2:AZ3)，這樣最大可以接受N個實例同時故障（2N+1=實例總數）
-
協調節點，主要是通過跨AZ來增加其自身的冗餘，每個AZ至少部署2個實例，防止另外一個AZ故障後無可用實例或者形成單點
-
數據節點，主要是通過每個AZ都存儲完整的數據，從而在單個AZ整體故障的情況，依然可以對外提供服務，單個AZ需要有一定的冗餘來避免機器或者交換機故障
圖1：Elasticsearch基於3個AZ的部署架構示意圖
成本因素
關於成本，對於這種架構，很多人會有疑問，這樣做好歸好，任意1個AZ故障，依然可以對外提供服務，但2個AZ存儲了同樣的數據，成本上太浪費了！其實不然，對於所有的分佈式存儲系統來講，默認至少都是兩個副本（HDFS默認三副本），從而避免單機故障導致的數據丟失問題。對於Elasticsearch，我們只是利用他的機架感知特性，將其隨機分佈的兩個副本按照AZ維度重新排布，因此並未增加其成本。如下圖2和3所示，正常情況下，每個shard（可以理解爲一組數據）的兩個副本均分佈在2個AZ中，當AZ1故障後，AZ2依然可以提供完整的數據集從而繼續對外服務
圖2：Elasticsearch正常狀態下雙副本的分佈情況示意圖
圖3：Elasticsearch在單個AZ故障後單副本的分佈情況示意圖
實現原理
那如何實現？一般來講都是基於Tag篩選的形式實現，當然前提是需要開源軟件自身支持該功能。具體到Elasticsearch，節點有兩種屬性（暫不考慮自定義Tag的方式），一種是rack（機架感知），一種是zone（可用區），從達成跨AZ部署的角度看，推薦使用zone來實現是較爲合適的，也較爲簡單，僅需要將AZ信息維護到ES的配置文件中即可。在實際工作中，可以設置兩個ES的分組，每個分組使用不同的配置文件即可解決。
rack更多的是從機架角度去進行調度，適合於一個AZ內部，將副本分配到不同的機架，從而避免多副本落到同一個機架上，因機架掉電而導致的數據不可用。但機架信息和機器的對應關係維護也是有成本的，更何況在虛擬化場景下，機架和虛擬機/docker中間還隔着一層宿主機，那更加重了這個維護成本，因此對於有多副本放置要求的場景，更建議使用雲廠商提供的高可用組/置放羣組來解決。
網絡延時
那延時有多大呢？是否會對業務產生顯著的影響？先說結論，跨AZ傳輸的延時一般在2ms以內，因此對於絕大多數業務來講，是沒有影響的。從理論角度分析，因爲多個AZ會分佈在同一城市的不同地方，距離不超過一百公里，因此光纖傳輸的延時可以控制在2ms以內（基於公有云廠商的經驗值而非SLA）。從實戰角度看，大型的互聯網公司，也是把多個AZ當做一個機房來使用的。因此跨AZ的網絡延時，對於大部分業務來講，都是無感的。以筆者實際的ES集羣爲例來進行說明，兩個集羣節點數均爲26臺，持續的Indexing Rate均爲3萬/S的情況下，使用跨AZ部署的集羣其Indexing Latency比同AZ部署的集羣高0.05ms。
圖4：採用單AZ部署的延時0.27ms
圖5：採用跨AZ部署的延時0.32ms
具體實現
那如何才能讓ES實現跨AZ部署呢，可以參考下面的內容，完整的配置文件可以參考文末提供的測試環境使用的配置
- node.attr.zone: az1 #在第一個分組配置az1，在第二個分組配置az2
cluster.routing.allocation.awareness.attributes: zone
通過修改elasticsearch.yml配置文件，增加上面兩行配置，跨AZ部署的目的就實現了，所有數據的副本會落在兩個AZ上。如果AZ1故障，那麼ES集羣會利用AZ2的副本，在AZ2內部重新複製一份出來，從而保持整體兩副本的要求。但這恰恰也是隱患所在，意味着當AZ1故障的時候，AZ2內部會產生大量的副本複製動作，從而對ES集羣造成很大的性能壓力甚至於穩定性隱患。如果AZ2的存儲空間不足以支撐完整副本，那麼AZ2的磁盤就會被打滿，導致新數據無法寫入，從而導致業務停頓。好在ES提供瞭解決方案，通過強制分配機制，在配置文件中增加下面一行配置，即可解決該問題。這時候，假設AZ1故障，那麼集羣整體就會以單副本的形式繼續運行，而不會在AZ2內重新複製副本。
cluster.routing.allocation.awareness.force.zone.values: az1,az2
數據備份
Elasticsearch的多副本場景，主要是解決機器、交換機以及單個AZ故障下的可用性問題，因此能夠在一定程度上避免數據丟失的風險。但需要注意：多副本+權限管控，並不能絕對保證數據不會被破壞。如果數據重要性足夠高，還需要將數據進行離線備份，在公有云場景下，可以將數據備份到雲存儲中。
可能會有同學提問，如果我是兩套ES做熱備，是否還需要將ES的數據進行離線備份呢？答案依然是確定的，兩套ES做熱備，能夠更好的提升集羣整體的可用性，但這兩套ES會有很多共通的地方，很有可能是同一套管理系統，同一組運維人員，以及同樣的bug。
測試方法
建議儘量使用虛擬機/docker，這樣在測試配置以及優化配置的時候，可以通過重建虛機來避免髒數據產生的影響
注意事項
-
每次修改配置後，需要通過檢查集羣配置信息確認修改是否生效
-
curl -X GET http://0.0.0.0:9200/_cluster/settings?pretty
-
-
數據遷移需要時間，基於日誌等信息判斷爲準
-
三行配置文件中，node屬性名稱需要保持一致
-
第一行配置需要重啓實例，其餘可通過api設置
寫在最後
希望本文提到的Elasticsearch多AZ的方案，能夠在不增加成本，延時的情況下，給大家帶來更好的服務可用性。
參考文檔
ES官方的配置文檔：
https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-awareness.html
可供測試環境使用的跨AZ部署的配置文件：
https://github.com/cloud-op/software/blob/master/elasticsearch/elasticsearch.yml
公衆號介紹
智能運維公衆號聚焦於運維領域，由一羣BATJ的資深運維工程師所創建，在監控，部署，預案，混沌工程和故障分析等方向進行方法論和最佳實踐的持續輸出，目前有超20篇原創文章發表在InfoQ上，並在其他渠道廣泛轉載。
