管理和维护集群
运行集群时,管理节点是管理集群和存储集群状态的关键组件。了解管理节点的一些关键特性以便正确部署和维护集群是非常重要的。
在集群中操作管理节点
管理节点使用raft共识算法来管理集群状态。只需理解raft通用的概念来管理集群。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
管理节点的数量是没有限制的。要设计多少个管理节点是有性能与容错能力之间的折中。向集群中添加管理节点可以增强容错能力。然而,额外的管理节点会降低写入性能,因为更多的节点必须确认更新集群状态的建议。这意味着更多的网络往返流量。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
raft要求大多数管理人员也称为法定人数来同意对集群的更新建议,如节点添加或者删除。成员身份操作受到与复制状态相同的限制。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
维护管理者的法定人数
当集群的管理者达不到法定人数,集群就不能执行管理任务了。如果集群有多个管理者,总是有两个以上。为了维护法定人数,大多数管理者必须可以使用。建议使用奇数个管理者,因为下一个偶数并不能使法定人数更容易保持。如,无论你是否拥有3或4个管理者,你仍然只能失去1个管理者,并维持法定人数。如果有5或6个管理者,可以失去2个。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
集群没有了法定管理者,存在于工作节点上的任务将继续运行。然而,集群节点无法添加、更新、删除,新的或者已存在的任务无法启动、停止、移动、更新。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
静态ip配置为管理的宣告地址
在集群初始化时,必须指定--advertise-addr标志,以将地址通告给群集中的其他管理器节点。因为管理员节点是基础设施的稳定组件,所以应该为宣告地址使用固定的IP地址,以防止在机器重启时群集变得不稳定。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
如果整个群集重新启动,并且每个管理员节点随后都获得新的IP地址,则任何节点都无法联系现有管理员。因此,群集将挂起,节点尝试以旧IP地址彼此联系。动态IP地址对于工作节点是可行的。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
添加管理节点进行容错
应该维持集群中的奇数个管理者来支持管理节点的故障。拥有奇数数量的管理员可确保在网络分区期间,如果网络分为两组,则法定人数仍然可用于处理请求的可能性较大。如果遇到两个以上的网络分区,则不保证法定人数。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
Swarm Size | Majority | Fault Tolerance |
---|---|---|
1 | 1 | 0 |
2 | 2 | 0 |
3 | 2 | 1 |
4 | 3 | 1 |
5 | 3 | 2 |
6 | 4 | 2 |
7 | 4 | 3 |
8 | 5 | 3 |
9 | 5 | 4 |
如,在具有5个节点的群组中,如果丢失3个节点,则没有法定人数。因此在恢复其中一个不可用的管理节点或者使用灾难恢复命令恢复集群之前,是无法添加或者删除节点的。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
可以将集群扩展到只有单个管理节点,但,这是不安全的做法,也不推荐。如果最后一个节点在降级操作期间意外离开群集,集群将变的不可用了,直到重启节点或者使用--force-new-cluster重建集群(服务都没了)。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
分布管理节点
除了维持奇数个管理节点外,在部署管理节点还需要注意数据中心拓扑。为了获得最佳容错能力,将管理节点分布到至少三个可用区域之间,以支持整套机器或者日常维护方案的故障。如果在任何这些区域遇到故障,集群应维持法定的管理节点以便可用于处理请求和重新平衡工作负载。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
Swarm manager nodes | Repartition (on 3 Availability zones) |
---|---|
3 | 1-1-1 |
5 | 2-2-1 |
7 | 3-2-2 |
9 | 3-3-3 |
仅运行管理任务节点
默认情况下,管理节点也作为工作节点,这意味着调度器可以将任务分配给管理节点。管理节点使用raft共识算法来复制一致性数据,对资源敏感。因此,阻止管理节点接收任务是比较好的选择。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
docker node update --availability drain <NODE>
添加工作节点进行负载均衡
只要工作节点与服务的资源要求相匹配,服务的副本将尽可能的均匀分布在集群中。当限制仅在特定类型的节点(例如具有特定数量的CPU或内存量的节点)上运行的服务时,请记住,不符合这些要求的工作节点将无法运行这些任务。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
集群健康监测
从命令行,运行docker node inspect 查询节点。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
管理节点状态是unreachable,意味着该管理节点不能从其他管理节点访问。在这种情况下,需要采取行动来恢复无法访问的管理员:文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
- 重启守护进程,看看管理者是否可达
- 重启机器
- 如果重启服务或者机器都不起作用,应添加另一个管理节点或者将某个工作节点提升为管理节点。还需要使用docker node demote 和docker node rm 从管理器集中清除已故节点条目。
可以从管理节点上,运行docker node ls命令查看节点健康状态:文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
docker node ls
ID HOSTNAME MEMBERSHIP STATUS AVAILABILITY MANAGER STATUS
1mhtdwhvsgr3c26xxbnzdc3yp node05 Accepted Ready Active
516pacagkqp2xc3fk9t1dhjor node02 Accepted Ready Active Reachable
9ifojw8of78kkusuc4a6c23fx * node01 Accepted Ready Active Leader
ax11wdpwrrb6db3mfjydscgk7 node04 Accepted Ready Active
bb1nrq2cswhtbg4mrsqnlx1ck node03 Accepted Ready Active Reachable
di9wxgz8dtuh9d2hn089ecqkf node06 Accepted Ready Active
排除管理节点故障
不应该通过从另一个节点复制raft目录数据来重新启动管理节点。该数据目录对于节点ID是唯一的。节点只能使用一次节点ID来加入群组。节点ID是全局唯一的。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
将管理员节点重新加入群集:文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/
- 运行docker node demote 将节点降级为工作节点
- 运行docker node rm 将节点从集群中删除
- 使用docker swarm join 重新将节点加入到集群
强制删除节点
在大多数情况下,应该使用docker node rm 命令将其从集群中删除。如果节点变的不可达或者无响应,可以使用--force强制删除。 在强制删除管理节点前,必须先将其降级为worker角色。如果降级或者删除管理者,请确保集群始终拥有奇数个管理节点。文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/ 文章源自运维生存时间-https://www.ttlsa.com/docker/docker-swarm-maintenance/

评论