hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suresh Srinivas (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-2354) Generalize the HAServiceProtocol interface
Date Fri, 30 Sep 2011 07:04:45 GMT

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

Suresh Srinivas commented on HDFS-2354:
---------------------------------------

bq. Suresh, whatever you told is true when you use Linux HA for determining Active / Standby
roles. Linux HA can easily work with scripts. Going one step further, one can configure standByToActive
script in HA framework & avoid the usage of HAServiceProtocol interface itself.

And how does the HA framework talk to a server to affect standbyToActive? That is where HAServiceProtocol
comes into play. In standbyToActive script, you run a command that talks to the namenode to
make it active.

bq. I mean to say there are many ways of plumbing a Leader Election Service with Namenode.
We need to consider other Leader Election mechanisms also. An alternative is Zookeeper based
Leader Election Service where the LES and Namenode may run together in the same JVM.

HDFS-1623 approach was to run FailoverController (or CRM/LRM in linux HA lingo) separate from
the service for which HA is being enabled. The reasons for that is described in the document,
hence HAServiceProtocol.

bq. So the argument boils down to the question whether FailoverController daemon should be
separate from the Namenode. If they are kept separately, having only the transition related
APIs in HAServiceProtocol looks to be better decision. But when considering the case that
both FailoverController daemon & Namenode runs in the same JVM, it is very much required
that start*() & stop() APIs be supported in the HAServiceProtocol interface.

Even in this case, you could build a FailoverController that runs on the same JVM, but interacts
with Namenode using HAServiceProtocol. The approach from HDFS-1974 does not preclude you from
that.

I have not looked at the patch in detail yet. At a high level, it is adding things/making
changes that I am not in favor of. I will respond in detail about this.
                
> Generalize the HAServiceProtocol interface
> ------------------------------------------
>
>                 Key: HDFS-2354
>                 URL: https://issues.apache.org/jira/browse/HDFS-2354
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: name-node
>            Reporter: Justin Joseph
>            Assignee: Justin Joseph
>         Attachments: HAService_fw_Class_Diagram.JPG, HDFS-2354.1.patch, HDFS-2354.patch
>
>
> This JIRA intends to revisit the patches committed for HADOOP-7455 and HDFS-1974 &
to provide more generic interfaces which allows alternative HA implementations to co-exist
complying with HAServiceProtocol.
> Some of the considerations are
> 1) Support life cycle methods (start*() and stop() APIs) in HAServiceProtocol
> 2) Support custom states in HAServiceProtocol
> 3) As per the patch submitted for HDFS-1974, Namenode implements HAService interface.
This needs to be reconsidered.
> I will elaborate on these points, in the form of comments below.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message