maintenance

    Maintenance Primitives

Operator经常需要在包含Mesos集群的机器上执行维护任务。 大多数Mesos升级可以在不影响运行的任务的情况下完成，但是有些情况下维护可能会影响正在运行的任务。例如:

l  硬件维修

l  内核升级

l  Agent更新(比如调整agent的attributes或resources)

框架要知道任何干扰群集运行的操作，以满足服务级别协议或确保为其最终用户提供不间断的服务。 因此，为了协调框架和operator的要求，框架必须意识到计划的维护事件，operator必须意识到框架适应维护的能力。 Maintenance Primitives添加了一个层，以便于框架和operator之间的通信。

Terminology(术语)

为了本文档的目的，”operator”是管理Mesos集群的人员，工具或脚本。

维护原语为Mesos添加了几个新概念。 这些概念是：

l  Maintenance: 暂时或永久地使机器上的资源不可用的操作。

l  Maintenance window: 一组机器和相关的时间间隔，在这些时间间隔内在这些机器上计划进行一些维护。

l  Maintenance schedule: 维护窗口列表。 一台机器只能在一个列表中出现一次。

l  Unavailability: 由操作员指定的间隔，由开始时间和持续时间定义，在此期间相关联的机器可能变得不可用。 一般来说，在不可用之后，不应该假设机器（或资源）的可用性。

l  Drain(排水): 维护调度与机器不能使用的时间间隔。 从排水机器发送的资源的offer将包含不可用信息。 在排水机上运行的框架将收到inverse offers（见下文）。 在受影响的机器上利用资源的框架预计将采取抢先步骤来准备不可用性; 或传达框架无法遵守维护计划。

l  Inverse offer: 一个沟通机制，让master从框架中回收资源。 这通知框架关于任何不可用性，并给框架一个机制来响应他们遵守的能力。 Inverse offer与offer类似，可以接受，拒绝，重新提供和撤销。

注意:  Unavailability和Inverse offer不是维护特有的。 相同的概念可用于非维护目标，例如重新分配资源或资源抢占。

How does it work?

在Mesos 0.25.0中引入了维护原语。 还介绍了几种机器维护模式。 这些模式如下所示。

 

所有模式转换必须由operator启动。不管维护计划中提供的估计值如何，Mesos将不会更改任何机器的模式。

Scheduling maintenance

一旦计划进行维护，机器将从Up模式转换到Draining模式。 要将机器转换为Draining模式，操作员将维护计划构建为JSON文档，并将其发布到Mesos主站上的/ maintenance / schedule HTTP端点。 每个Mesos集群都有一个维护计划; 发布新的计划将替换以前的计划（如果有的话）。

 

在生产环境中，应制定时间表，以确保足够的agent在任何时间点运行，以确保框架不间断的服务。

例如，在三台机器的集群中，操作员可以安排两台机器进行一个小时的维护，最后一台机器再运行一小时。 不可用的时间戳以Unix时期的纳秒为单位表示（请注意，使用维护原语可靠地要求群集中所有机器的系统时钟大致同步）。

时间表可能如下所示：

 

operator可以将计划发布到master的 /maintenance/schedule端点：

 

维护计划中的机器在设置计划时不需要向Mesos master注册。 在机器上启动agent之前，操作员可以将维护计划添加到维护计划中。 例如，这可能有助于防止故障机器在启动时启动代理。

注意：维护计划中的每台机器应尽有可能完整的信息。 为了使Mesos识别agent来自特定的机器，hostname和ip字段都必须匹配。 任何省略的数据默认为空字符串“”。 如果机器有多个主机名或IP，则机器的字段需要匹配agent向master发出的通知。 如果机器的配置有歧义，operator应该在启动代理时使用--hostname和--ip选项。

master检查维护计划具有以下属性：

计划中的每个维护窗口必须至少有一台机器和指定的不可用性间隔。

每台机器只能在计划中出现一次。

每个机器必须至少包含一个主机名或IP。 主机名不区分大小写。

处于Down模式的所有计算机都必须存在于计划中。 这是必需的，因为该端点不处理从Down模式向Up模式的转换。

如果不符合任何这些属性，则维护计划将被拒绝并显示相应的错误消息，并且主机的状态不会更改。

要更新维护计划，operator应首先阅读当前计划，进行任何必要的更改，然后发布修改的计划。 可以通过向master的/maintenance/schedule端点发送GET请求来获得当前的维护计划。

要取消维护计划，operator应该发布一个空的schedule。

Draining mode

一旦schedule发布到Mesos master，就会发生以下情况：

schedule存储在复制日志中。 这意味着在master故障切换的情况下，计划会持续存在。

计划中的所有计算机都将立即转换到Draining模式。 每个机器的模式也保留在复制日志中。

立即通知在受影响的agent上使用资源的所有框架。 来自受影响的代理的现有offer将被取消，并重新发送附加的不可用数据。 使用受影响agent程序的资源的所有框架都将提供inverse offers。

来自受影响的agent的新的offer还将包括额外的不可用性数据。

框架应该使用这些附加信息来以维护意识的方式安排任务。 如何做到这一点取决于每个调度程序的设计要求，但通常应以最大化利用率的方式安排任务，但是在该机器发布的不可用期之前也尝试将机器撤出。 调度程序可能选择将长时间运行的任务放在不可用的机器上，或者在不可用性最远的机器上将其运行失败。

框架如何响应inverse offers表明其符合维护计划的能力。 考虑到框架资源的当前状态，接受inverse offers通知框架与当前维护计划一致。 master和operator应该将接受解释为框架的尽力而为的承诺，以在可用性间隔开始之前释放inverse offers中包含的所有资源。 拒绝inverse offers是对运营商的建议通知，框架不能或不太可能符合维护计划。

例如：

数据存储可以选择启动一个新的副本，如果一个agent程序被安排进行维护。 数据存储应该接受inverse offer，如果在inverse offer中描述的不可用性间隔开始之前，可以将机器上的数据合理地复制到新主机。 否则，数据存储应该拒绝offer。

具有即将发生的不可用性的agent的有状态任务可能会迁移到另一个可用的agent。 如果框架有足够的资源来做到这一点，它将接受任何inverse offer。 否则会拒绝它们。

框架可以使用过滤器来控制什么时候想要再次与inverse offer联系。 这是有用的，因为未来的情况可能会改变维护计划的可行性。 inverse offer的过滤器与现有的重新发送offer给框架的机制相同。

注意：接受或拒绝inverse offer不会导致维护计划的即时更改或Mesos行为的方式。 inverse offer仅代表框架可能会发现有用的额外信息。 以同样的方式，拒绝或接受inverse offer是对operator的暗示。 operator可能会选择也可能不会考虑这一点。

Starting maintenance

operator通过将机器列表发布到/machine /down HTTP端点来启动维护。 机器列表以JSON格式指定; 列表的每个元素都是一个MachineID。

例如，要在两台机器上启动维护：

 

master检查机器列表具有以下属性：

l  机器列表不能为空。

l  每台机器只能出现一次。

l  每个机器必须至少包含一个主机名或IP。 主机名不区分大小写。

l  如果包含机器的IP，则必须是正确的格式。

l  所有列出的机器必须在schedule中。

如果不符合任何这些属性，则操作将被拒绝并显示相应的错误消息，并且主机的状态不会更改。

operator可以在计划进行维护的任何机器上开始维护。 没有计划进行维护的机器无法从Up模式直接转换到Down模式。 但是，operator可以使用等于当前时间或过去的时间戳来安排机器进行维护，然后立即开始对该机器进行维护。

此端点可用于在当前未注册Mesos master的机器上启动维护。 如果机器出现故障并且operator打算将其从集群中删除，这将非常有用; 在机器上启动维护可防止机器意外重新引导并重新连接Mesos集群。

operator必须明确地将机器从Draining转移到Deactived模式。 也就是说，即使不可用窗口到达或通过，Mesos也会将机器保持在排水模式。 这意味着机器的操作不会以任何方式中断，并且为本机提供（不可用信息）。

当operator触发维护时，机器上的所有agent都被告知关闭。 这些agent将从master中删除，这意味着将为每个agent程序上运行的每个任务发送TASK_LOST状态更新。 调度程序驱动程序的slaveLost也将为每个被删除的agent回掉。 维护中的机器上的任何agent也将被阻止在将来重新注册master（直到维护完成并且机器被重新启动）。

Completing maintenance

维护完成或需要取消维护时，operator可以停止维护。 该过程与启动维护非常相似（与上一节相同的验证标准）。operator将机器列表发送到master的/machine/up端点：

 

注意：由维护计划中的“不可用性”字段指示的维护窗口的持续时间是operator做出的尽力而为的猜测。 允许在可用性间隔结束之前停止维护，以及在可用性间隔结束后停止维护。 机器永远不会自动过渡到维护之外。

当该机器的offer开始发送时，框架被告知有关维护的完成或取消。 维护完成后，没有明确的机制通知框架。 维护完成后，新的offer不再标记为不可用，而不再发送 inverse offer。 此外，在机器上运行的agent程序将被允许向Mesos master注册。

Viewing maintenance status

通过访问master的/maintenance/status HTTP端点可以查看集群中每台机器的当前维护状态(Up, Draining, or Down)。 对于Draining的每个机器，此端点还包括框架对该机器上的资源的inverse offer的响应。 有关详细信息，请参阅ClusterStatus消息的格式。

注意：此端点返回的数据的格式可能会在以后的Mesos版本中更改。