管理swarm(20) – 管理和维护swarm

当你运行Docker Engines swarm,管理节点是管理swarm和存储swarm状态的关键组件。为了正确地部署和维护swarm,理解管理节点一些关键的功能很重要。

swarm的管理节点

swarm管理节点使用Raft一致性算法来管理swarm的状态。你只需要理解Raft的一些常见概念以便来更好的管理swarm。
对管理节点的数量没有限制。关于要实现多少个管理器节点的决定是性能和容错之间的折衷。增加更多管理节点到swarm使得swarm有更好的容灾能力。不过额外的管理节点会降低写入性能,因为更多的节点必须确认更新swarm状态的提议。意味着产生更多的流量,花更多的时间。
Raft要求大多数管理者(也称为法定人数)同意对swarm的建议更新。 法定人数的管理人员还必须同意节点添加和删除。 成员资格操作受到与状态复制相同的约束。

使用一个advertise静态IP地址

当启动一个swarm时,你必须指定–advertise-addr一个IP地址来通告swarm中的其它管理节点。因为管理节点是一个相对稳定的组件,你应该使用一个固定的IP地址来避免机器重启时IP变更其它管理节点无法连接。
如果整个swarm重启,随便每个管理节点都获取到一个新的IP地址,那么任何的节点都没有办法连接到一个已存在的管理节点。worker节点就可以使用动态IP地址。

添加管理节点来容错

你应该维护奇数个swarm管理节点以支持管理节点故障而不影响swarm运行。奇数的管理节点数量确保了在网络故障分裂为两部分时,有很大可能管理节点的数量仍然为法定数量(即数量超过一半)来选举出新的leader节点。如果遇到网络分裂超过三部分,那就不能保证有法定数量的管理节点了。
例如,在一个有5个管理节点的swarm中,如果你失去了3个节点,余下的2个节点没有超过一半,达不到法定数量,无法选举出新的leader节点。因此在你恢复不可用的管理节点或使用灾难恢复命令恢复swarm前,你不能添加或删除节点。
虽然可以将一个swarm缩放为单个管理器节点,但不可能降级最后一个管理器节点。这可以确保你能访问swarm,并且swarm仍然能处理请求。缩放为单个管理节点是一个不安全的操作且不建议。如果你最后一个节点在降级操作期间突然变得不可用,在你重启节点或使用–force-new-cluster重启前,swarm将变得不可用。

分布管理节点到多个区域

除了维护奇数个管理节点,在部署管理节点时注意数据中心拓扑。为了实现最佳容错性,将管理节点分布在至少3个可用性区域中,以支持整个机房或常见维护情况的故障。如果任意一个区域发生故障,swarm管理节点的数量仍然会超过一半来选举出leader节点。
下面的图表说明在三个可用区域中部署管理节点的数量。

运行仅负责管理的节点

默认下管理节点也作为worker节点。意味着调度器可以分配任务给管理节点。对于小的和非关键的swarm,只要你使用cpu和内存的资源约束来调度服务,则向管理节点分配任务的风险相对较低。
然而因为管理节点使用Raft一致性算法以一致的方式复制数据,它们对资源匮乏较敏感。你应该设置管理节点不接受任务以避免影响swarm心跳或leader选举。
为了避免影响管理节点的相关管理操作,你可以设置管理节点为drain状态不再继续作为worker节点。

  1. docker node update --availability drain <NODE>

当你drain一个节点,调度器会重新分配这个节点上运行的任务到其它可用节点。也会阻止调度器分配新的任务到这个节点。

备份swarm状态

Docker管理节点存储swarm状态和日志在以下目录:

  1. /var/lib/docker/swarm/raft

经常的备份raft数据目录以便你能灾难恢复swarm。

监控swarm状态

你可以通过/nodes HTTP endpoint以JSON格式查询docker nodes API来监视管理节点的运行状况。
也可以在命令行执行docker node inspect 来查询节点。
例如,查询管理节点的reachability:

  1. docker node inspect manager1 --format "{{ .ManagerStatus.Reachability }}"
  2. reachable

查询worker节点的接受任务的状态:

  1. docker node inspect manager1 --format "{{ .Status.State }}"
  2. ready

从这些命令的输出来看,我们可以知道manager1作为管理节点时状态为reachable,作为worker节点时为ready。
unreachable状态意味着从其它管理节点无法访问这个管理节点。这种情况你需要马上恢复这个不可用的管理节点:

  • 重启docker进程来看管理节点是否会恢复为reachable
  • 重启机器
  • 如果以上都没有用,你应该添加一个管理节点或升级一个worker节点为管理节点。你也需要使用docker node demote 和docker node rm 来清除失效的管理节点。
  • 或者你可以在管理节点上执行docker node ls来查看所有节点的运行情况:

    1. docker node ls
    2. ID                           HOSTNAME  MEMBERSHIP  STATUS  AVAILABILITY  MANAGER STATUS
    3. 1mhtdwhvsgr3c26xxbnzdc3yp    node05    Accepted    Ready   Active
    4. 516pacagkqp2xc3fk9t1dhjor    node02    Accepted    Ready   Active        Reachable
    5. 9ifojw8of78kkusuc4a6c23fx *  node01    Accepted    Ready   Active        Leader
    6. ax11wdpwrrb6db3mfjydscgk7    node04    Accepted    Ready   Active
    7. bb1nrq2cswhtbg4mrsqnlx1ck    node03    Accepted    Ready   Active        Reachable
    8. di9wxgz8dtuh9d2hn089ecqkf    node06    Accepted    Ready   Active

    强制删除一个节点

    在大多数情况下在你要使用docker node rm命令来删除一个节点时应该先关闭这个节点。如果某个节点变得不可达,无响应或受损,你可以通过传递–force标志强制删除该节点,而不关闭它。例如如果node9受损:

    1. $ docker node rm node9
    2.  
    3. Error response from daemon: rpc error: code = 9 desc = node node9 is not down and can't be removed
    4.  
    5. $ docker node rm --force node9
    6.  
    7. Node node9 removed from swarm

    在你强制删除一个管理节点之前,你必须先降级它为worker节点。如果你降级或删除一个管理节点,必须始终确保管理节点数量为奇数。

    灾难恢复

    Swarm对故障适应能力强,并且可以从任何数量的临时节点故障(机器重新启动或与崩溃时重新启动)恢复。
    在N个管理节点的swarm中,为了使swarm处理请求并保持可用,必须有大于管理节点总数的50%(或(N / 2)+1)的管理节点的法定数量。 这意味着swarm可以容忍多达(N-1)/ 2个永久故障,超过这些永久故障,无法处理涉及swarm管理的请求。 这些类型的故障包括数据损坏或硬件故障。
    即使你遵循此处的指南,也可能会丢失一个仲裁节点。 如果无法通过常规方法(如重新启动故障节点)恢复仲裁,则可以通过在管理节点上运行docker swarm init –force-new-cluster来恢复该swarm。

    1. # From the node to recover
    2. docker swarm init --force-new-cluster --advertise-addr node01:2377

    –force-new-cluster参数设置为单管理节点的swarm。 它丢弃失去法定数量的管理节点之前存在的成员信息,但它保留Swarm所需的数据,例如服务,任务和worker节点的列表。

    强制重新平衡swarm

    一般情况下,你不需要强制平衡swarm的任务。当你添加一个新节点到swarm或者节点不可用一段时间后重新连接,swarm不会自动重新将运行在其它节点的任务分配到这个空闲节点。swarm是这样设计的。如果为了平衡,swarm周期性的迁移任务到不同的节点,使用这些任务的用户会被中断。如果启动一个新任务或者一个运行的节点变为不可用,它们的任务会分配到不太繁忙的节点。目标是保证对用户影响最小来达到重新平衡。
    如果你不在意中断运行的服务来强制平衡swarm任务,你可以临时的增大服务的规模。
    使用docker service inspect –pretty 来查看服务的规模。使用docker service scale时,调度器会把任务优先分配到最低任务数的节点。 你的swarm中可能有多个负载不足的节点。 你可能需要多次增大服务的规模,以实现所有节点上所需的平衡。
    如果平衡满足你的要求,你可以恢复服务到原来的规模数。可以使用docker service ps命令来评估跨节点的服务的当前平衡。

    标签:Swarm 发布于:2019-11-20 05:56:28