[
https://issues.apache.org/jira/browse/YARN-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13844182#comment-13844182
]
Karthik Kambatla commented on YARN-1029:
----------------------------------------
Correction: Actually, it would be the AdminService that will have to implement
ZKFCProtocol, not ActiveStandbyElector.
bq. What are the pros and cons of using ZKFC embedded vs ActiveStandbyElector?
Indeed, my first implementation was embedding ZKFC. While it works fine, I
found it round about and has some avoidable overhead. Embedding
ActiveStandbyElector definitely seems like a simpler, cleaner approach.
Cons of ZKFC / Pros of ActiveStandbyElector:
# ZKFC communicates to the RM through RPC; when embedded, both are in the same
process.
# In addition to ActiveStandbyElector, ZKFC has other overheads - health
monitoring, fencing etc. which might not be required in a simple embedded
option.
# ZKFC#formatZK() needs to be exposed through rmadmin, which complicates it
further.
# Embedding ZKFC isn't very clean.
Cons of ActiveStandbyElector: AFAIK, the only drawback of ActiveStandbyElector
is having AdminService implement ZKFCProtocol - two methods: cedeActive() and
gracefulFailover(). These methods are simple and straight-forward and are
needed only to be able to safely failover manually when automatic-failover is
enabled.
> Allow embedding leader election into the RM
> -------------------------------------------
>
> Key: YARN-1029
> URL: https://issues.apache.org/jira/browse/YARN-1029
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Bikas Saha
> Assignee: Karthik Kambatla
> Attachments: yarn-1029-approach.patch
>
>
> It should be possible to embed common ActiveStandyElector into the RM such
> that ZooKeeper based leader election and notification is in-built. In
> conjunction with a ZK state store, this configuration will be a simple
> deployment option.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
