Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Wed, 15 Jan 2014 00:33:19 +0000 (UTC)
From: "Karthik Kambatla (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12688284.1389376003704.2129.1389745999564@arcas>
In-Reply-To: <JIRA.12688284.1389376003704@arcas>
References: <JIRA.12688284.1389376003704@arcas>
Subject: [jira] [Commented] (YARN-1584) Support explicit failover when
 automatic failover is enabled
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Karthik Kambatla commented on YARN-1584:
----------------------------------------

bq. The duration of failover depends on how long ZK needs to figure out that the leader is gone. Then notifying the new leader. Then new leader reading state.
Right. I agree that the failover takes the same time irrespective of whether it is through graceful failover or shutting the RM down.

bq. Its not clear to me how any of these steps are faster with a admin failover option.
I was referring to the duration after the failover for which a single RM is up. In other words, the duration for recovering the RM that was shutdown. Firstly, it requires manually checking the other RM has actually taken over, which in itself is slower than handling it automatically. Then, the start-up time for the second RM; the start-up might become an issue if/when the Standby and the other services retain/pre-fetch state. 

IMO, the biggest gain of supporting -failover is the ease of use. What do you think of adding a config whether to support graceful failover and may be we can turn it off by default. 

bq. When the RM is asked to transition to active via the AdminService (FORCE_USER) flag, then the AdminService can transition to standby and then notify the elector to quitElection(). That API is present on the elector for this specific purpose. The elector gives up participation in the leader election process. This RM will remain in standby (because the elector is not going to notify it anymore) until the admin ask it to transitionToActive(FORCE_USER). Later, when the AdminService is asked to transitionToActive() it can call the joinElection API on the elector to rejoin the leader election and stay in the Standby state. The elector will join the election and notify the RM to transitionToActive if it wins the election.
The transitionToStandby() part sounds reasonable to me. transitionToActive(FORCE_USER) wouldn't actually transition the RM to Active, but instead just become ready to be Active? Users might find it confusing. 

> Support explicit failover when automatic failover is enabled
> ------------------------------------------------------------
>
>                 Key: YARN-1584
>                 URL: https://issues.apache.org/jira/browse/YARN-1584
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager
>    Affects Versions: 2.4.0
>            Reporter: Karthik Kambatla
>            Assignee: Karthik Kambatla
>
> YARN-1029 adds automatic failover support. However, users can't explicitly ask for a failover from one RM to the other without stopping the other RM. Stopping the RM until the other RM takes over and then restarting the first RM is more involving and exposes the RM-ensemble to SPOF for a longer duration. 
> It would be nice to allow explicit failover through yarn rmadmin -failover command.
> PS: HDFS supports -failover option. 


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)