应用框架速率限额

发布于 2015-12-05 10:57:59 | 349 次阅读 | 评论: 0 | 来源: 网络整理

应用框架速率限额限额是Mesos 0.20.0开始引入的功能。

什么是应用框架资源速率限额

在多应用框架运行环境中，可通过对不重要的应用框架（比如开发，批处理）设置速率限额，来保障需要资源高消费high-SLA的应用框架（比如生产、服务）运转。

Mesos集群使用者可以通过设置 qps（每秒查询次数）的值来达到为了一个特定应用框架发送的的信息进行节流的目的。可以对每个应用（通过principle主键来唯一指定）进行单独设置，也可以以群组为单位来进行（下文没有注明的情况则都是以逐个为例）。详见RateLimits ProtoBuf definition 和下文配置说明。）当框架消息超过 qps设定速率时，master节点将不会 处理 额外的消息。超出限额的消息会被保存在master节点内存中。

速率限额配置

下面示例：JSON格式，是主控设置里 --rate_limits的值。

{
  "limits": [
    {
      "principal": "foo",
      "qps": 55.5
      "capacity": 100000
    },
    {
      "principal": "bar",
      "qps": 300
    },
    {
      "principal": "baz",
    }
  ],
  "aggregate_default_qps": 333,
  "aggregate_default_capacity": 1000000
}

这示例里，应用框架 foo的限额通过 qps 和 capacity 来配置，应用框架 bar 则被设置为capacity可无限制使用，而 baz则根本没有限额设定。当有第四个qux应用或者有一个连接到master节点的没有主键的应用时，其限额将使用默认的 aggregate_default_qps 和 aggregate_default_capacity 设定。

配置详细说明

下面解释配置文件中各个部分的含义。

• principal: (必须) 对于需要进行速率节流或显示不进行限制的应用框架的唯一识别名。
  • 必须是应用 FrameworkInfo.principal里的名字相匹配。详见 definition。
  • 可给多个应用框架一个同样的 唯一识别名（比如一些 Mesos应用框架会为每项任务新开一个同样的应用框架实例）。若如此，qps的设置是指所有这个识别名下应用框架的总额度。
• qps: (可选) 每秒查询次数。
  • 若设置了此项，则主控将不会对超过这个频率的信息进行处理。一般来说，master节点 实际的查询速率会比设置值低，尤其是设置了过高速度的。
  • 当在limits设置了限额，但没有加入 qps 项时，表示 qps 将无限额。
• capacity: (可选) 设置应用框架 可在master节点放置多少 待处理消息（也就是排队等待资源分配）。 若无设置，则为无限制。注意：如果设置过多或者无限额，可能导致排队消息过多，导致master节点内存溢出。
  • NOTE: 若 qps 没有设置， capacity 将被忽略。
• aggregate_default_qps 和 aggregate_default_capacity 设置默认值，那些没有列入限额设置的应用框架都将使用默认值。
  • 没有加入限额设置的应用框架，其查询速率和队列数将同时使用默认值。
  • 若 aggregate_default_qps 没有设置，则aggregate_default_capacity 的设置将被忽略。
  • 若应用在限额列表里，该配置项没有进行设置，则未指定的应用框架将无速率和队列限制。我们建议还是进行显示的设置以免未指定的应用框架使master节点过载崩溃。

设置 应用框架的速率限额

监控应用流量

当应用框架向master节点注册时，master节点会把应用框架发来和处理的所有消息都纳入计数，具体信息放在http://<master>/metrics/snapshot里。例如，应用框架 foo有两个消息计数器frameworks/foo/messages_received和frameworks/foo/messages_processed，一个是接收到的消息，一个是处理过的消息。若无限额设定，这两个数字差异会很小甚至一样，(因为消息都是立刻得到了处理) ，而当设定了速率限额的时候，这两个数则会根据限额设定而起变化。

若持续观察计数器，可获知消息到达的速度和消息被处理的速度。通过该信息可以推测应用框架在网络流量上的特性。

配置速率限额

应用框架的速率限额是用来避免 low-SLA 的应用框架没有通过精细的流量和任务所需要的资源的估计儿消耗了大量集群资源。 对于此类框架，可先使用较大的 qps 值来设置。而当对high-SLA应用设置高优先级的时候，也会对low-SLA形成事实上的限额。因为他们的消息会立刻得到处理。

如何知道master节点的可处理消息队列处理能力capacity 呢？首先，要知道master节点主线程的内存限额，执行类似任务但不设限额时使用的内存（比如，用 ps -o rss $MASTER_PID 查询）和队列消息的平均大小（队列消息以serialized Protocol Buffers with a few additional fields方式存储），之后在进行汇总配置中的所有的capacity值。

不过这种汇总并不精确，因此，一开始可用小一点的限额，这样可以让master节点和没设限额的应用保有充分的内存空间，以应对可能的突发需求。

处理 "容量超出" 错误

当应用框架 超出了容量 时，会发出"FrameworkErrorMessage"给 应用框架，应用框架将 中止调度器驱动并调用 error()回调函数 ，但不会因此强制结束任何任务或调度器本身。应用框架开发者可选择重启或者在其他节点恢复调度实例，来应对消息丢失的后果（除非你的应用框架并不需要知道所有发给maseter节点的消息是否都被处理）。

在0.20.0版本后，我们会迭代的增强该功能。即当此应用开始建立消息队列的时候，master节点会发出告警（MESOS-1664相当于一个soft limit），调度器将自身会根据改告警进行节流行为（来避免错误信息），或是忽略改告警（设计好的的临时突发情况）。

在告警消息被实现之前，不建议使用速率限额功能来对生产级别的应用框架进行速率限额的配置（除非你很清楚错误消息带来的后果）。但可以通过对其他非重要框架进行的限额的设置来保护生产级别的应用框架。并且若不显示的开启该配置，是不会对master节点造成任何影响的。