[
https://issues.apache.org/jira/browse/MESOS-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14993561#comment-14993561
]
Adam B commented on MESOS-3765:
-------------------------------
To summarize my understanding:
Fairness cannot be guaranteed/influenced by a framework expressing its
preferences, since a misbehaving/greedy framework's requests will be expressly
anti-fair. As such, the requestResources API is unrelated, and we should focus
on Master/operator-driven granularity adjustments.
Most clusters have more nodes than frameworks, so offering entire nodes usually
balances out at a course-grained level, and allows frameworks to launch tasks
that require lots of resources on a single node.
Based on the conversation in the community sync, there were 3 potential offer
size influencers:
- A master command-line flag that sets a fixed minimum offer size; BenH
recommended keeping it large (e.g. 4cpu, 4GB RAM) so that frameworks won't be
starved waiting for a sizeable offer, even if enough resources are available.
- Rather than offer the entirety of the available resources of a node, the
master/allocator knows the difference between the framework's current share and
its ideal fair share. We could cap the offer at that amount (with some minimum
size), and then iterate to offer the rest of that node's available resources to
the next role/framework furthest below its fair share.
- Consider a framework's quota and offer enough resources on a particular node
to satisfy the per-node quota guarantee.
> Make offer size adjustable (granularity)
> ----------------------------------------
>
> Key: MESOS-3765
> URL: https://issues.apache.org/jira/browse/MESOS-3765
> Project: Mesos
> Issue Type: Improvement
> Components: allocation
> Reporter: Alexander Rukletsov
>
> The built-in allocator performs "coarse-grained" allocation, meaning that it
> always allocates the entire remaining agent resources to a single framework.
> This may heavily impact allocation fairness in some cases, for example in
> presence of numerous greedy frameworks and a small number of powerful agents.
> A possible solution would be to allow operators explicitly specify
> granularity via allocator flags. While this can be tricky for non-standard
> resources, it's pretty straightforward for {{cpus}} and {{mem}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
