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 consul

2.启动程序

make tools

3.部署

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即可