#程式設計師# #DevOps# #自動化運維# #saltstack# #乾貨#

大家都知道，作為DevOps的順手工具，一個是ansible，一個是saltstack，必須要精通一個。今天聊一聊saltstack的高可用架構。

一、待解決問題Master負責的Minion數量過多，併發訊息量過大，導致Master過載而丟訊息如果使用MultiMaster模式，會導致Minion跟Master跨機房通訊如果使用Syndic會導致MOM(MasterOfMaster)無法感知存活的MinionSalt-API沒有身份鑑定，命令稽核功能二、解決方案MultiMaster架構

為了解決如上問題，根據官方Saltstack的高可用架構的描述，我們選擇了MultiMaster-With-Failover模式作為基礎，在此基礎之上擴展出了MultiMaster-With-Failover-With-Proxy模式。此處我們將Syndic替換成自研的Proxy。

我們的架構中，同一個機房部署多臺Master，Minion使用master_type: failover和 master_shuffle=True的方式隨機連線本機房其中一個Master，並且讓Minion根據master_alive_interval 定期檢查所連Master的健康狀態，發現當前Master故障後會自動連線其他Master實現Failover。

優點：該方案可以使得

Minion跟Master之間的通訊不跨機房一個Minion同時只跟一個Master保持連線，避免了重複接收命令的問題，並且高可用透過水平擴充套件Master，使得Master和Minion的配比保持在一個合理的範圍，分散了單個Master的壓力開發Proxy

為了實現如上的架構，我們還需要開發Proxy來替換Syndic，對Proxy的需求有

部署在Master機器上，負責從訊息管道Subscribe訊息，匹配規則，匹配通過後轉給本地的Master進而傳送給Minion，不匹配則丟棄，規則有如果使用minion id精確匹配，那麼Minion需要與本Master直接相連如果使用list、glob、regex等方式，則對連線本Master的Minion進行匹配計算，需要至少匹配到一個待續將Minion返回給Master的執行結果寫入中心的Database儲存定期（如每10s）向Connector彙報本機Master所連線的Minion的連通性狀態

優點：該方案可以使得

儘可能減少無用命令的下發全域性知曉Minion的連通性透過MQ將Connector跟Proxy進行解耦，Proxy也可以水平擴充套件，Connector也可以開發Connector

對Connector的需求有

以HTTP協議接收使用者請求的命令，相容原生Salt-API的介面格式支援高併發支援使用者身份鑑定支援呼叫方IP白名單支援命令內容檢查支援限流，1分鐘內呼叫不超過N次，可配除了特權使用者，其他使用者匹配Minion不能用*，批次不超過30，可配將命令Publish到MQ中，等待Proxy來Subscribe接收來自所有Proxy的Minion連通狀態資料，維護在狀態表裡，對於精確匹配和List匹配Minion id的API呼叫，如果其中有失聯的Minion，根據使用者引數決定是拒絕請求還是接受，如接受，則在返回結果裡註明失聯

優點：該方案使得

Connector可以水平擴充套件Connector提供了更強的認證和審查機制如何從日誌中找出問題？

透過Flume將Proxy日誌，Master日誌，Minion日誌，Connector日誌統一採集彙總到ES