[
https://issues.apache.org/jira/browse/AMBARI-26674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksander Nek updated AMBARI-26674:
------------------------------------
Description:
h2. Problem
Operators of automatic-HA HDFS clusters need an explicit, guarded way to choose
which Standby becomes Active from Ambari. The implementation should use the
normal Ambari request/task workflow and Hadoop's coordinated failover, with a
target selector and confirmation.
h2. Proposed implementation
Add HDFS -> Service Actions -> Switch Active NameNode for the BIGTOP HDFS stack
and Ambari 3.0.0 Ember UI.
* Display the reported Active and allow selection of a Standby.
* Require SERVICE.RUN_CUSTOM_COMMAND authorization and explicit confirmation.
* Reject stopped or stale-config NN/ZKFC components and ambiguous or unknown HA
roles.
* Send SWITCH_ACTIVE_NAMENODE to the reviewed Active host.
* Resolve configured NameNode identities within the same nameservice; support
an existing two- or three-NameNode automatic-HA topology without changing stack
cardinality or adding a third-NameNode provisioning wizard.
* Recheck live roles, source/target health and local configuration before
issuing one coordinated hdfs haadmin -failover operation.
* Verify the selected target is Active and the other configured NameNodes are
Standby; include before/after roles in task structured output.
* Use an isolated Kerberos cache and a source-host lock. Do not use force
transitions, automatic mutation retries or automatic reverse failover.
h2. Validation
The UI was checked on the test cluster. The operator also confirmed successful
manual testing of role switching on that cluster.
Fresh focused checks on the community contribution: 20 backend tests passed; 14
UI tests passed; Ember Web build succeeded (1023 files compiled).
h2. Scope and recovery
This contribution targets branch-3.0.0 and the BIGTOP HDFS stack. The current
trunk frontend migration is outside this patch. The source-host lock is local,
not distributed; normal Hadoop/ZKFC coordination and fencing remain required.
If a command errors or times out, inspect live roles before retrying because
the role change may already have occurred.
h2. Contribution
* Pull request: https://github.com/apache/ambari/pull/4257
* Source branch: https://github.com/iskenderurs/ambari/tree/AMBARI-26674
* Commit: 24a04d93eb8a94b8ea0dc18866166f7dfbc58fea
* Documentation:
https://github.com/iskenderurs/ambari/blob/AMBARI-26674/docs/namenode-role-switch.md
h2. UI screenshot
The UI was checked on the test cluster. The supplied screenshot has its
hostname anonymized to nn1.example.org.
!https://raw.githubusercontent.com/iskenderurs/ambari/AMBARI-26674/docs/images/namenode-role-switch.png|width=900!
was:
h2. Problem
Operators of automatic-HA HDFS clusters need an explicit, guarded way to choose
which Standby becomes Active from Ambari. The implementation should use the
normal Ambari request/task workflow and Hadoop's coordinated failover, with a
target selector and confirmation.
h2. Proposed implementation
Add HDFS -> Service Actions -> Switch Active NameNode for the BIGTOP HDFS stack
and Ambari 3.0.0 Ember UI.
* Display the reported Active and allow selection of a Standby.
* Require SERVICE.RUN_CUSTOM_COMMAND authorization and explicit confirmation.
* Reject stopped or stale-config NN/ZKFC components and ambiguous or unknown HA
roles.
* Send SWITCH_ACTIVE_NAMENODE to the reviewed Active host.
* Resolve configured NameNode identities within the same nameservice; support
an existing two- or three-NameNode automatic-HA topology without changing stack
cardinality or adding a third-NameNode provisioning wizard.
* Recheck live roles, source/target health and local configuration before
issuing one coordinated hdfs haadmin -failover operation.
* Verify the selected target is Active and the other configured NameNodes are
Standby; include before/after roles in task structured output.
* Use an isolated Kerberos cache and a source-host lock. Do not use force
transitions, automatic mutation retries or automatic reverse failover.
h2. Validation
The UI was checked on the test cluster. The operator also confirmed successful
manual testing of role switching on that cluster.
Fresh focused checks on the community contribution: 20 backend tests passed; 14
UI tests passed; Ember Web build succeeded (1023 files compiled).
h2. Scope and recovery
This contribution targets branch-3.0.0 and the BIGTOP HDFS stack. The current
trunk frontend migration is outside this patch. The source-host lock is local,
not distributed; normal Hadoop/ZKFC coordination and fencing remain required.
If a command errors or times out, inspect live roles before retrying because
the role change may already have occurred.
Source code, pull request and anonymized UI screenshot will be linked here
after publication.
> Add guarded planned Active NameNode switching for BIGTOP HDFS in Ambari Web UI
> ------------------------------------------------------------------------------
>
> Key: AMBARI-26674
> URL: https://issues.apache.org/jira/browse/AMBARI-26674
> Project: Ambari
> Issue Type: Improvement
> Reporter: Aleksander Nek
> Priority: Major
> Labels: bigtop, ha, hdfs
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Problem
> Operators of automatic-HA HDFS clusters need an explicit, guarded way to
> choose which Standby becomes Active from Ambari. The implementation should
> use the normal Ambari request/task workflow and Hadoop's coordinated
> failover, with a target selector and confirmation.
> h2. Proposed implementation
> Add HDFS -> Service Actions -> Switch Active NameNode for the BIGTOP HDFS
> stack and Ambari 3.0.0 Ember UI.
> * Display the reported Active and allow selection of a Standby.
> * Require SERVICE.RUN_CUSTOM_COMMAND authorization and explicit confirmation.
> * Reject stopped or stale-config NN/ZKFC components and ambiguous or unknown
> HA roles.
> * Send SWITCH_ACTIVE_NAMENODE to the reviewed Active host.
> * Resolve configured NameNode identities within the same nameservice; support
> an existing two- or three-NameNode automatic-HA topology without changing
> stack cardinality or adding a third-NameNode provisioning wizard.
> * Recheck live roles, source/target health and local configuration before
> issuing one coordinated hdfs haadmin -failover operation.
> * Verify the selected target is Active and the other configured NameNodes are
> Standby; include before/after roles in task structured output.
> * Use an isolated Kerberos cache and a source-host lock. Do not use force
> transitions, automatic mutation retries or automatic reverse failover.
> h2. Validation
> The UI was checked on the test cluster. The operator also confirmed
> successful manual testing of role switching on that cluster.
> Fresh focused checks on the community contribution: 20 backend tests passed;
> 14 UI tests passed; Ember Web build succeeded (1023 files compiled).
> h2. Scope and recovery
> This contribution targets branch-3.0.0 and the BIGTOP HDFS stack. The current
> trunk frontend migration is outside this patch. The source-host lock is
> local, not distributed; normal Hadoop/ZKFC coordination and fencing remain
> required. If a command errors or times out, inspect live roles before
> retrying because the role change may already have occurred.
> h2. Contribution
> * Pull request: https://github.com/apache/ambari/pull/4257
> * Source branch: https://github.com/iskenderurs/ambari/tree/AMBARI-26674
> * Commit: 24a04d93eb8a94b8ea0dc18866166f7dfbc58fea
> * Documentation:
> https://github.com/iskenderurs/ambari/blob/AMBARI-26674/docs/namenode-role-switch.md
> h2. UI screenshot
> The UI was checked on the test cluster. The supplied screenshot has its
> hostname anonymized to nn1.example.org.
> !https://raw.githubusercontent.com/iskenderurs/ambari/AMBARI-26674/docs/images/namenode-role-switch.png|width=900!
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
