FLASHC

[hadoop]apache ambari design goals

Design Goals
Platform Independence
The system must architecturally support any hardware and operating system, e.g.
RHEL, SLES, Ubuntu, Windows, etc. Components which are inherently dependent
on a platform (e.g., components dealing with yum, rpm packages, debian packages,
etc) should be pluggable with well-defined interfaces.

Pluggable Components
The architecture must not assume specific tools and technologies. Any specific
tools and technologies must be encapsulated by pluggable components. The
architecture will focus on pluggability of Puppet and related components which is a
provisioning and configuration tool of choice, and the database to persist the state.
The goal is not to immediately support replacements of Puppet, but the architecture
should be easily extensible to do so in the future.
The pluggability goal doesn’t encompass standardization of inter-component
protocols or interfaces to work with third-party implementations of components.

Version Management & Upgrade
Ambari components running on various nodes must support multiple versions of
the protocols to support independent upgrade of components. Upgrade of any
component of Ambari must not affect the cluster state.

Extensibility
The design should support easy addition of new services, components and APIs.
Extensibility also implies ease in modifying any configuration or provisioning steps
for the Hadoop stack. Also, the possibility of supporting Hadoop stacks other than
HDP needs to be taken into account.

Failure Recovery
The system must be able to recover from any component failure to a consistent
state. The system should try to complete the pending operations after recovery. If
certain errors are unrecoverable, failure should still keep the system in a consistent
state.

Security
The security implies 1) authentication and role-based authorization of Ambari
users (both API and Web UI), 2) installation, management, and monitoring of the
Hadoop stack secured via Kerberos, and 3) authenticating and encrypting over-thewire communication between Ambari components (e.g., Ambari master-agent
communication).

Error Trace
The design strives to simplify the process of tracing failures. The failures should
be propagated to the user with sufficient details and pointers for analysis.ear Real-Time and Intermediate Feedback for Operations
For operations that take a while to complete, the system needs to be able to
provide the user feedback with intermediate progress regarding currently running
tasks, % of operation complete, a reference to a operation log, etc., in a timely
manner (near real-time). In the previous version of Ambari, this was not available
due to Puppet’s Master-Agent architecture and its status reporting mechanism.