consul运维
consul 文檔
第一章 安裝
安裝方式
1.二進制安裝
2.源碼安裝
一、二進制安裝
download
下載后解壓到指定目錄，設置好環境變量即可
二、源碼安裝
需要預先安裝Go，配置好環境(包括go環境變量)，復制git到指定路徑
1.環境配置，clone軟件包
$ mkdir -p $GOPATH/src/github.com/hashicorp && cd $! $ git clone https://github.com/hashicorp/consul.git $ cd consul2.啟動程序
make tools3.部署
make dev三、驗證
consul -v環境變量不對會報錯
第二章 升級
第三章 內部機制
第一節 consul體系結構
名詞解釋
agent：每個集群成員運行的后臺程序，可以以client或者server模式運行，所有的agent均能提供DNS和HTTP接口，他們負責健康檢查以及服務的同步
client：client是能夠向server發送RPC的agent，資源占用小，占用網絡帶寬小
server：維護集群狀態，響應RPC請求，與其他數據中心交換數據，向leader或者遠程數據中心傳送查詢請求
datacenter：見名知意，但得注意在ec2中的一些細微的細節，我們講的數據中心指的是在同一個私有網絡中服務節點，這樣的網絡具有高帶寬，低延遲的特性，不包括公共網絡上的數據傳輸。但是在ec2的某個region中的多個可用區的節點是別當著一個數據中心的
consensus：表明事務的順序跟leader的順序是一致的，這里定義的一致性是指復制狀態機的一致性，基于raft實現，（finite-state machine，Wikipedia，?here）
gossip：建立在基于gossip protocol的serf之上，實現成員注冊，失敗檢測，event廣播等等，更多細節見?gossip documentation，主要基于UDP。
LAN gossip：包含所有位于同一個數據中心或者是同一個local網絡中的LAN gossip pool
WAN Gossip：只包含server的WAN gossip pool，這些server位于不同的數據中心，數據都屬于網間傳輸
RPC：遠程過程調用
From a 10,000 foot altitude the architecture of Consul looks like this
1.從上圖可以看出，consul支持多數據中心
2.每個數據中心既有client，也有server，每個數據中心推薦三到五個server節點，這主要是基于可用性和性能的考慮，節點過多為了保證數據一致，整個系統都會被拖累，但是client不一樣，可以擴展到成千上萬，
3.所有節點遵循gossip協議，也就是說有這么一個gossip pool包含了數據中心中的所有節點，這主要是基于以下幾個目的：
(1)首先，客戶端不在需要配置服務端的地址，服務自動發現；
(2)服務的健康檢查不是放在server端，不是heartbeat檢測
(3)他是作為消息傳遞的一個中間層
4.The leader is responsible for processing all queries and transactions. Transactions must also be replicated to all peers as part of the?consensus protocol. Because of this requirement, when a non-leader server receives an RPC request, it forwards it to the cluster leader.
5.server -- WAN gossip pool，與LAN gossip有區別，對網絡的高延遲做了優化，只包含server節點，服務的操作都在pool里完成，當別的數據中心的數據傳輸過來的時候，它會隨機的轉發到任意一個server，然后收到消息的server再轉發給local leader。結果降低了數據中心點的耦合度，但是有健康檢測、連接緩存、多路傳輸等特性，所以數據中心間的請求是很快的，而且也很可靠
6.通常數據中心之間不做數據交互，即便有，也不會影響local datacenter，特例ACL replication，consul-replicate
?
進階內容
consensus protocol
gossip protocol
documentation?
第二節 一致性協議
consul的一致性協議理論源于cap理論
1.raft協議
raft基于Paxos，只是更簡單易懂
raft關鍵詞
log：raft中主要的起作用的就是log，基于日志復制
FSM：節點同步基于狀態檢測
peer set：log復制中的所有節點
Quorum：多于半數節點掛掉的話集群不可用
committed entry：半數以上節點已經持久化的數據
Leader：接收日志數據，復制到從屬節點，管理committed entry
下面是raft的一些重點內容，具體細節見?paper
raft節點存在有三種狀態：follower, candidate, or leader，所有的節點一開始都是follower的角色，這種狀態的節點可以接收leader發送的日志，或者參與投票選舉leader，如果等待一段時間還沒收到數據，那么節點將會自動提升為candidate，candidate會請求其他節點投票
，如果取得超過半數的投票，candidate就會提升為leader，leader。。。
leader持久化，復制，狀態機，we use?MemDB?to maintain cluster state，支持ACID
性能瓶頸在磁盤IO以及網絡延遲上
Raft in consul
只有consul server的節點間使用raft協議同步數據
a single Consul server is put into "bootstrap" mode. This mode allows it to self-elect as a leader，Eventually, once the first few servers are added, bootstrap mode can be disabled. See?this guide?for more details
Since all servers participate as part of the peer set, they all know the current leader. When an RPC request arrives at a non-leader server, the request is forwarded to the leader. If the RPC is a?query?type, meaning it is read-only, the leader generates the result based on the current state of the FSM. If the RPC is a?transaction?type, meaning it modifies state, the leader generates a new log entry and applies it using Raft. Once the log entry is committed and applied to the FSM, the transaction is complete
Because of the nature of Raft's replication, performance is sensitive to network latency. For this reason, each datacenter elects an independent leader and maintains a disjoint peer set. Data is partitioned by datacenter, so each leader is responsible only for data in their datacenter. When a request is received for a remote datacenter, the request is forwarded to the correct leader. This design allows for lower latency transactions and higher availability without sacrificing consistency
Consistency Modes
三種一致性模式
default:采用leader leasing的方式，在時間窗口內，舊的leader只提供讀，不會接收新的log，所以并沒有腦裂的風險
consistent:強一致，The trade-off is always consistent reads but increased latency due to the extra round trip
stale：server節點不管是否是leader都可以提供讀，但是延遲一般也就在50毫秒內，這種模式下就算沒有leader任然可以響應請求
第三節 Gossip 協議
功能：管理集群，廣播數據
兩個不同的gossip pools，LAN pool和WAN pool
LAN pool：包含本地數據中心內的所有節點，通過成員信息，客戶端能夠自動發現服務，減少繁瑣的配置
WAN pool：數據中心間網際傳輸，量一般比較少
這些特征都被集成到開發庫中，用戶沒有必要了解具體細節
第四節?Network Coordinates
第五節 sessions
第六節?Anti-Entropy
?
故障
一、背景
1.consul啟動命令
su - consul -c 'consul agent -config-file=/etc/consul.conf -bind=192.168.110.133 -client=192.168.110.133 -config-dir=/etc/consul.d -ui > /var/log/consul.log &'
2.consul reload
Error reloading: Put http://127.0.0.1:8500/v1/agent/reload: dial tcp 127.0.0.1:8500: connect: connection refused
二、原理
consul reload --help
. . . . . .
-http-addr=<address>
The `address` and port of the Consul HTTP agent. The value can be
an IP address or DNS address, but it must also include the port.
This can also be specified via the CONSUL_HTTP_ADDR environment
variable. The default value is http://127.0.0.1:8500. The scheme
can also be set to HTTPS by setting the environment variable
CONSUL_HTTP_SSL=true.
. . . . . .
三、解決辦法
consul reload -http-addr=http://192.168.110.133:8500
Configuration reload triggered
?
故障二
一、ip配置錯誤
Warning: Using a password on the command line interface can be insecure.
mysqladmin: connect to server at '192.168.128.137' failed
error: 'Can't connect to MySQL server on '192.168.128.137' (111)'
Check that mysqld is running on 192.168.128.137 and that the port is 6033.
You can check this by doing 'telnet 192.168.128.137 6033'
二、解決辦法
修改配置文件reload即可
?
轉載于:https://www.cnblogs.com/geek-ace/p/9360791.html
與50位技術專家面對面20年技術見證，附贈技術全景圖總結
- 上一篇： 爱投资平台创始人已经跑路？
- 下一篇： 富文本