hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantinos Karanasos (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-4902) [Umbrella] Generalized and unified scheduling-strategies in YARN
Date Fri, 05 Aug 2016 22:36:21 GMT

    [ https://issues.apache.org/jira/browse/YARN-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410209#comment-15410209
] 

Konstantinos Karanasos commented on YARN-4902:
----------------------------------------------

Thanks for checking the design doc and the patch, and for the feedback, [~leftnoteasy].
Please find below some thoughts regarding the points your raised and some additional information.

bq. From the requirement's perspective, I didn't see new things, please remind me if I missed
anything
Agreed that our basic requirements are similar, which is good because it means we are aligned.
Some of the notions we are using might coincide with yours but have a different name (e.g.,
dynamic vs. allocation tags, although the scope of our dynamic tags is global and not application
specific like yours), by virtue of the fact that we were designing things at the same time.
We can agree on a common naming, not a problem.
What I would like to stretch as being different is mainly the LRA planning, some extensions
to the constraints (along with a more succinct way of expressing them), as well as the ease
of expressing inter-application constraints -- more details below.

*Constraints*
bq. The cardinality constraints is placement_set with maximum_concurrency constraint: see
(4.3.3) Placement Strategy in my design doc.
If I am not wrong, the maxiumum_concurrency in your document corresponds to a single allocation/resource-request.
Our min and max cardinality is across applications. For instance, in order to say "don't put
more than 5 hbase servers (from any possible application) in a rack".

In general, as we showed in our design doc, you can use max and min cardinalities to also
express affinity and anti-affinity constraints. This way we can have only a single type of
constraints. What do you think?

bq. Will this patch support anti-affinity / affinity between apps? I uploaded my latest POC
patch to YARN-1042, it supports affinity/anti-affinity for inter/intra apps. We can easily
extend it to support intra/inter resource request within the app.
Yes, this is a major use case for us. The current patch can already support it. And this is
why we want to make more use of the tags and of planning, since they would allow us to specify
inter-app constraints without needing to know the app ID of the other job.

bq. Major logic of this patch depends on node label manager dynamic tag changes. First of
all, I'm not sure if NLM works efficiently when node label changes rapidly (we could update
label on node when allocate / release every container). And I'm not sure how you plan to avoid
malicious application add labels. For example if a distributed shell application claims it
is a "hbase master" just for fun, how to enforce cardinality logics like "only put 10 HBase
masters in the rack"?
Good points.
For the scalability we have not seen any problems so far (we update tags at allocate/release),
but we have not run very large-scale experiments -- I will update you on that.
For the malicious AM, I am not sure if the application would benefit from lying. But even
if it does, we can use cluster-wide constraints to limit such AMs. Still, I agree more thought
has to be given on this matter -- it's good you brought it up.

*Scheduling*
bq. It might be better to implement complex scheduling logics like affinity-between-apps and
cardinality in a global scheduling way. (YARN-5139)
We will be more than happy to use any advancement in the scheduler that is available!
I totally believe that global scheduling (i.e., have an application-centric rather than node-centric
scheduling) is much more appropriate and will give better results. We did not use it in our
first patch, as it was not available, but we are happy to try it out.

*Planning*
bq. I'm not sure how LRA planner will look like, should it be a separate scheduler running
in parallel? I didn't see your patch uses that approach.
The idea here is to be able to do more holistic placement decisions across applications. What
if you place your HBase service in a way that does not let a subsequent Heron app be placed
in the cluster at all?
We envision it to be outside of the scheduler, similar to the reservation system (YARN-1051).
Applications will also be able to submit multiple applications at once, and specify constraints
among them.
It is not in the initial version of the patch.

*Suggestions*
bq. Could you take a look at global scheduling patch which I attached to YARN-5139 to see
if it is possible to build new features added in your patch on top of the global scheduling
framework? And also please share your thoughts about what's your overall feedbacks to the
global scheduling framework like efficiency, extensibility, etc.
I will check the global scheduler, and as I said above, I'd be happy to use it.

bq. It will be better to design Java API for this ticket, both of our poc patches (this one
and the one I attached to YARN-1042) don't have a solid API definition. It is very important
to define API first, could you help with API definition works?
Agreed, we should do that.

> [Umbrella] Generalized and unified scheduling-strategies in YARN
> ----------------------------------------------------------------
>
>                 Key: YARN-4902
>                 URL: https://issues.apache.org/jira/browse/YARN-4902
>             Project: Hadoop YARN
>          Issue Type: New Feature
>            Reporter: Vinod Kumar Vavilapalli
>            Assignee: Wangda Tan
>         Attachments: Generalized and unified scheduling-strategies in YARN -v0.pdf, LRA-scheduling-design.v0.pdf,
YARN-5468.prototype.patch
>
>
> Apache Hadoop YARN's ResourceRequest mechanism is the core part of the YARN's scheduling
API for applications to use. The ResourceRequest mechanism is a powerful API for applications
(specifically ApplicationMasters) to indicate to YARN what size of containers are needed,
and where in the cluster etc.
> However a host of new feature requirements are making the API increasingly more and more
complex and difficult to understand by users and making it very complicated to implement within
the code-base.
> This JIRA aims to generalize and unify all such scheduling-strategies in YARN.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org


Mime
View raw message