Consul集群配置

Linux评论阅读模式

consul原理

上图是官网提供的一个事例系统图,图中的Server是consul服务端高可用集群,Client是consul客户端。consul客户端不保存数据,客户端将接收到的请求转发给响应的Server端。Server之间通过局域网或广域网通信实现数据一致性。每个Server或Client都是一个consul agent。

Consul集群间使用了GOSSIP协议通信和raft一致性算法。上面这张图涉及到了很多术语:

  • Agent——agent是一直运行在Consul集群中每个成员上的守护进程。通过运行consul agent来启动。agent可以运行在client或者server模式。指定节点作为client或者server是非常简单的,除非有其他agent实例。所有的agent都能运行DNS或者HTTP接口,并负责运行时检查和保持服务同步。
  • Client——一个Client是一个转发所有RPC到server的代理。这个client是相对无状态的。client唯一执行的后台活动是加入LAN gossip池。这有一个最低的资源开销并且仅消耗少量的网络带宽。
  • Server——一个server是一个有一组扩展功能的代理,这些功能包括参与Raft选举,维护集群状态,响应RPC查询,与其他数据中心交互WAN gossip和转发查询给leader或者远程数据中心。
  • DataCenter——虽然数据中心的定义是显而易见的,但是有一些细微的细节必须考虑。例如,在EC2中,多个可用区域被认为组成一个数据中心。我们定义数据中心为一个私有的,低延迟和高带宽的一个网络环境。这不包括访问公共网络,但是对于我们而言,同一个EC2中的多个可用区域可以被认为是一个数据中心的一部分。
  • Consensus——一致性,使用Consensus来表明就leader选举和事务的顺序达成一致。为了以容错方式达成一致,一般有超过半数一致则可以认为整体一致。Consul使用Raft实现一致性,进行leader选举,在consul中的使用bootstrap时,可以进行自选,其他server加入进来后bootstrap就可以取消。
  • Gossip——Consul建立在Serf的基础之上,它提供了一个用于多播目的的完整的gossip协议。Serf提供成员关系,故障检测和事件广播。Serf是去中心化的服务发现和编制的解决方案,节点失败侦测与发现,具有容错、轻量、高可用的特点。
  • LAN Gossip——它包含所有位于同一个局域网或者数据中心的所有节点。
  • WAN Gossip——它只包含Server。这些server主要分布在不同的数据中心并且通常通过因特网或者广域网通信。
  • RPC——远程过程调用。这是一个允许client请求server的请求/响应机制。

在每个数据中心,client和server是混合的。一般建议有3-5台server。这是基于有故障情况下的可用性和性能之间的权衡结果,因为越多的机器加入达成共识越慢。然而,并不限制client的数量,它们可以很容易的扩展到数千或者数万台。

同一个数据中心的所有节点都必须加入gossip协议。这意味着gossip协议包含一个给定数据中心的所有节点。这服务于几个目的:第一,不需要在client上配置server地址。发现都是自动完成的。第二,检测节点故障的工作不是放在server上,而是分布式的。这是的故障检测相比心跳机制有更高的可扩展性。第三:它用来作为一个消息层来通知事件,比如leader选举发生时。

每个数据中心的server都是Raft节点集合的一部分。这意味着它们一起工作并选出一个leader,一个有额外工作的server。leader负责处理所有的查询和事务。作为一致性协议的一部分,事务也必须被复制到所有其他的节点。因为这一要求,当一个非leader得server收到一个RPC请求时,它将请求转发给集群leader。

server节点也作为WAN gossip Pool的一部分。这个Pool不同于LAN Pool,因为它是为了优化互联网更高的延迟,并且它只包含其他Consul server节点。这个Pool的目的是为了允许数据中心能够以low-touch的方式发现彼此。这使得一个新的数据中心可以很容易的加入现存的WAN gossip。因为server都运行在这个pool中,它也支持跨数据中心请求。当一个server收到来自另一个数据中心的请求时,它随即转发给正确数据中想一个server。该server再转发给本地leader。

这使得数据中心之间只有一个很低的耦合,但是由于故障检测,连接缓存和复用,跨数据中心的请求都是相对快速和可靠的。

consul环境准备

IP 节点名称 Consul角色
10.200.119.171 s1 Server
10.200.119.172 s2 Server
10.200.119.173 s3 Server
10.200.119.60 c1 Client(UI)

consul下载和目录创建

  1. https://releases.hashicorp.com/consul/1.4.3/consul_1.4.3_linux_amd64.zip
  2. unzip consul_1.4.3_linux_amd64.zip
  3. mv consul /usr/local/bin/
  4. mkdir -p /data/consul/{data,config} #创建数据目录和配置目录

consul acl

对数据中心的每个server,添加/data/consul/config/acl_config.json配置:

参考:《consul ACL配置使用

consul agent参数

consul agent --help

-advertise:通知展现地址用来改变我们给集群中的其他节点展现的地址,一般情况下-bind地址就是展现地址

-bootstrap:用来控制一个server是否在bootstrap模式,在一个datacenter中只能有一个server处于bootstrap模式,当一个server处于bootstrap模式时,可以自己选举为raft leader。
-bootstrap-expect:在一个datacenter中期望提供的server节点数目,当该值提供的时候,consul一直等到达到指定sever数目的时候才会引导整个集群,该标记不能和bootstrap公用。

-bind:该地址用来在集群内部的通讯,集群内的所有节点到地址都必须是可达的,默认是0.0.0.0。

-client:consul绑定在哪个client地址上,这个地址提供HTTP、DNS、RPC等服务,默认是127.0.0.1。

-config-file:明确的指定要加载哪个配置文件。

-config-dir:配置文件目录,里面所有以.json结尾的文件都会被加载

-data-dir:提供一个目录用来存放agent的状态,所有的agent都需要该目录,该目录必须是稳定的,系统重启后都继续存在。

-dc:该标记控制agent的datacenter的名称,默认是dc1。

-encrypt:指定secret key,使consul在通讯时进行加密,key可以通过consul keygen生成,同一个集群中的节点必须使用相同的key。

-join:加入一个已经启动的agent的ip地址,可以多次指定多个agent的地址。如果consul不能加入任何指定的地址中,则agent会启动失败。默认agent启动时不会加入任何节点。

-retry-join:和join类似,但是允许你在第一次失败后进行尝试。

-retry-interval:两次join之间的时间间隔,默认是30s。

-retry-max:尝试重复join的次数,默认是0,也就是无限次尝试。

-log-level:consul agent启动后显示的日志信息级别。默认是info,可选:trace、debug、info、warn、err。

-node:节点在集群中的名称,在一个集群中必须是唯一的,默认是该节点的主机名。

-protocol:consul使用的协议版本。

-rejoin:使consul忽略先前的离开,在agent再次启动后仍旧尝试加入集群中。也就是说如果不加入这个参数,当前节点一旦退出,下次重启后是不会自动加入到集群中去的,除非是手动触发 consul join xxxx ,所以为了降低重启后对本身服务的影响,这里统一使用 -rejoin参数。
-server:定义agent运行在server模式,每个集群至少有一个server,建议每个集群的server不要超过5个。

-syslog:开启系统日志功能,只在linux/osx上生效。

-ui:启用内置Web UI服务

-ui-dir:提供存放web ui资源的路径,该目录必须是可读的。

-pid-file:提供一个路径来存放pid文件,可以使用该文件进行SIGINT/SIGHUP(关闭/更新)agent。

consul配置文件

本文不适用acl规则

10.200.119.171:/etc/sysconfig/consul

  1. CMD_OPTS="agent -server -data-dir=/data/consul/data -node=s1 -config-dir=/data/consul/config -bind=10.200.119.171 -rejoin -client=0.0.0.0 -bootstrap"

10.200.119.172:/etc/sysconfig/consul

  1. CMD_OPTS="agent -server -data-dir=/data/consul/data -node=s2 -config-dir=/data/consul/config -bind=10.200.119.172 -rejoin -client=0.0.0.0"

10.200.119.173:/etc/sysconfig/consul

  1. CMD_OPTS="agent -server -data-dir=/data/consul/data -node=s3 -config-dir=/data/consul/config -bind=10.200.119.173 -rejoin -client=0.0.0.0"

10.200.119.60:/etc/sysconfig/consul

  1. CMD_OPTS="agent -ui -data-dir=/data/consul/data -node=c1 -config-dir=/data/consul/config -bind=10.200.119.60 -rejoin -client=0.0.0.0"

consul systemd自启动

  1. cat > /lib/systemd/system/consul.service << EOF
  2. [Unit]
  3. Description=Consul is a tool for service discovery and configuration. Consul is distributed, highly available, and extremely scalable.
  4. Documentation=http://www.consul.io
  5. After=network-online.target
  6. Wants=network-online.target
  7. [Service]
  8. LimitCORE=infinity
  9. LimitNOFILE=100000
  10. LimitNPROC=100000
  11. EnvironmentFile=-/etc/sysconfig/consul
  12. ExecStart=/usr/local/bin/consul \$CMD_OPTS
  13. ExecReload=/bin/kill -HUP \$MAINPID
  14. KillSignal=SIGINT
  15. [Install]
  16. WantedBy=multi-user.target
  17. EOF
  18. systemctl enable consul

consul节点加入集群

4个节点分别启动consul

  1. systemctl start consul

在s2、s3、c1加入s1集群,如下:

  1. consul join 10.200.119.171

consul查看状态

  1. [root@10-200-119-60 ~]# consul members
  2. Node Address Status Type Build Protocol DC Segment
  3. s1 10.200.119.171:8301 alive server 1.4.3 2 dc1 <all>
  4. s2 10.200.119.172:8301 alive server 1.4.3 2 dc1 <all>
  5. s3 10.200.119.173:8301 alive server 1.4.3 2 dc1 <all>
  6. c1 10.200.119.60:8301 alive client 1.4.3 2 dc1 <default>

consul UI

Consul集群配置

Thu Mar 7 16:44:22 CST 2019

 
  • 本文由 yeho 发表于 2019-03-07
  • 转载请务必保留本文链接:https://linuxeye.com/475.html
  • Consul
Linux

Nginx反向代理永久性缓存

Nginx缓存简介 Nginx缓存方式有两种: 永久性的缓存:这种缓存若不手动删除,该缓存文件会一直生效,因此,永久缓存只是用于缓存网站中几乎不会更改的内容; 临时缓存:这种缓存是根据请求连接进行哈希...
匿名

发表评论

匿名网友
确定

拖动滑块以完成验证