Apache Ambari

Plataforma Independente: O sistema deve suportar arquiteturalmente qualquer hardware e sistema operacional. Componentes que são inerentemente dependentes de uma plataforma devem ser conectáveis com interfaces bem definidas.

Componentes Plugáveis: A arquitetura não deve assumir ferramentas e tecnologias específicas. Quaisquer ferramentas e tecnologias específicas devem ser encapsuladas por componentes conectáveis. A arquitetura deve ser facilmente extensível. A meta de plugabilidade não abrange a padronização de protocolos entre componentes ou interfaces para operar com implementações de terceiros.

Gerenciamento de Versão e Atualização: Os componentes, em execução em vários nós (hosts), devem suportar diferentes versões de protocolos para assim suportarem atualizações independentes. A atualização de qualquer componente do Ambari não deve afetar o estado do Cluster.

Extensibilidade: A arquitetura deve suportar a adição de novos serviços, componentes e APIs. A extensibilidade também implica facilidade na modificação de qualquer configuração ou etapas de provisionamento para Plataformas de Serviços. Além disso, a possibilidade de suportar Plataformas de Serviços diferentes precisa ser considerada.

Recuperação de Falha: O sistema deve ser capaz de se recuperar de qualquer falha de componentes para um estado consistente. O sistema deve tentar concluir as operações pendentes após a recuperação. Se certos erros são irrecuperáveis, a falha ainda deve manter o sistema em um estado consistente.

Segurança: A segurança implica 1) autenticação e autorização baseada em perfis de usuários (API e interface web), 2) instalação, gerenciamento e monitoramento da Plataforma de Serviços protegida via Kerberos e 3) autenticação e criptografia da comunicação na rede entre os componentes do Ambari.

Rastreamento de Erro: A arquitetura deve se esforçar para simplificar o processo de rastreamento de falhas. As falhas devem ser propagadas para o usuário com os detalhes e indicadores necessários para a análise.

Feedback Intermediário e Operações em Near Real Time: Para operações que demoram um pouco para serem concluídas, o sistema precisa ser capaz de fornecer feedback ao usuário com progresso intermediário em relação à execução atual de tarefas, percentual de operação concluída e referência ao log de operação, em tempo hábil (quase em tempo real).

Serviço (Service): Serviço refere-se aos serviços da Plataforma de Serviços, como HDFS, YARN, Spark, Kafka, entre outros. Um serviço pode ter vários componentes (por exemplo, o HDFS possui NameNode, DataNode e etc.) ou ser apenas uma biblioteca cliente (por exemplo, o Sqoop não possui nenhum serviço de daemon, apenas uma biblioteca cliente).

Componente (Component): Um serviço consiste de um ou mais componentes. Por exemplo, o HDFS possui 3 componentes: NameNode, NameNode Secundário e DataNode. Os componentes podem ser opcionais. Um componente pode abranger vários nós (por exemplo, instâncias do componente DataNode em vários nós).

Nó (Node ou Host): Nó refere-se a uma máquina (física ou virtual) no Cluster. Nó e host são usados de forma intercambiável nesta documentação.

Operação (Operation): Uma operação refere-se a um conjunto de mudanças ou ações executadas em um cluster para satisfazer uma solicitação do usuário ou para obter uma mudança de estado desejável no Cluster. Por exemplo, iniciar um serviço ou executar um smoke test são operações. Se uma solicitação do usuário para adicionar um novo serviço o Cluster inclui a execução de um smoke test também, todo o conjunto de ações para atender à solicitação do usuário irá compor uma Operação. Uma operação pode consistir de em múltiplas “ações” ordenadas.

Tarefa (Task): Tarefa é a unidade de trabalho enviada para execução em um nó. Uma tarefa é o trabalho que o nó tem que realizar como parte de uma ação. Por exemplo, uma “ação” pode se composta pela instalação de um DataNode no nó N1 e a instalação de um DataNode e um NameNode Secundário no nó N2. Neste caso, a “tarefa” para N1 será instalar um DataNode e as “tarefas” para N2 serão instalar um DataNode e um Namenode Secundário.

Estágio (Stage): Um estágio refere-se a um conjunto de tarefas necessárias para concluir uma operação e são independentes entre si. Todas as tarefas no mesmo estágio podem ser executadas em diferentes nós em paralelo.

Ação (Action): Uma "ação" consiste em uma tarefa ou tarefas em uma máquina ou um grupo de máquinas. Cada ação é rastreada por um ID e os nós relatam o status da mesma pelo menos no granularidade da ação. Uma ação pode ser considerada uma etapa em execução. Nesta documentação, um estágio e uma ação têm correspondência de um para um, a menos que especificado de outra forma. Um ID de ação será uma bijeção de request-id para stage-id.

Plano de Estágio (Stage Plan): Uma operação normalmente consiste em várias tarefas em várias máquinas e elas geralmente possuem dependências que exigem que sejam executadas em uma ordem específica. Algumas tarefas devem ser concluídas antes que outras possam ser agendadas. Portanto, as tarefas necessários para uma operação podem ser divididas em várias etapas, na qual cada etapa deve ser concluída antes do próximo estágio, mas todas as tarefas no mesmo estágio podem ser programadas em paralelo em diferentes nós.

Manifesto (Manifest): O manifesto refere-se à definição de uma tarefa que é enviada a um nó para execução. O manifesto deve definir completamente a tarefa e deve ser serializável. O manifesto também pode ser persistido no disco para recuperação ou registro.

Função (Role): Uma função mapeia um componente (por exemplo, NameNode) ou uma ação (por exemplo, rebalanceamento do HDFS, smoke test do HBase e etc.).

https://ambari.apache.org

https://cwiki.apache.org/confluence/display/ambari

https://github.com/apache/ambari