Apache Ambari
Gestão do Cluster
Desenvolvido para facilitar a implantação e administração de Clusters de Big Data, o Apache Ambari possibilita a automatização da implantação, gerenciamento de serviços e nós (hosts), monitorização sistémica do ambiente, versionamento de configurações e muito mais.
A sua arquitetura consistente, API REST robusta e interface web intuitiva e interativa disponibilizam todos os recursos necessários para a administração centralizada do Cluster.
Atualmente, o projeto Apache Ambari está a todo vapor graças a uma comunidade ativa e renovada. É possível acompanhar essa evolução constante no seu repositório no Github.
Objetivos
Dentre os seus principais objetivos, idealizados no início do projeto, destacam-se:
- Plataforma Independente: O sistema deve suportar arquitetonicamente qualquer hardware e sistema operativo. Componentes que são inerentemente dependentes de uma plataforma devem ser conectáveis com interfaces bem definidas.
- Componentes Conectá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.
- Gestão de Versões e Atualizações: 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 permitir 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 Falhas: O sistema deve ser capaz de se recuperar de qualquer falha nos 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 num 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 monitorização da Plataforma de Serviços protegida via Kerberos e 3) garantia de autenticação e encriptação da comunicação na rede entre os componentes do Ambari.
- Rastreamento de Erro: A arquitetura deve esforçar-se 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 Intermédio e Operações em Near Real Time: Para operações que demoram um pouco para serem concluídas, o sistema precisa ser capaz de disponibilizar feedback ao usuário com progresso intermédio em relação à execução atual de tarefas, percentagem de operação concluída e referência ao log de operação, em tempo hábil (quase em tempo real).
Terminologia
Seguem os significados dos termos técnicos do projeto Apache Ambari utilizados nesta documentação:
-
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 dum 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 dum 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 dum DataNode no nó N1 e a instalação dum 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 numa tarefa ou tarefas numa 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 dum 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 numa 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 registo.
-
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.).
Arquitetura
A arquitetura do Ambari envolve:
- Ambari Web: Aplicação client-side responsável pela interface web que exibe informações e executa operações no Cluster por meio da API REST fornecida pelo Ambari Server.
- Ambari Server: Componente Master responsável pelo controlo do Cluster. Consiste de vários entry-points disponíveis para diferentes necessidades, tais como:
- Gestão do Daemon: entry-point para start, stop, reset e restart do daemon do Ambari Server.
- Atualização de Software: entry-point para upgrade do Ambari Server após a sua instalação.
- Configuração de Software: entry-point para configuração preliminar do Ambari.
- Configuração de Autenticação e Autorização: entry-point para configuração do mecanismo de gerenciamento de identidades, autenticação e autorização. Opções disponíveis: LDAP (Lightweight Directory Access Protocol), PAM (Pluggable Authentication Module) e Kerberos.
-Backup e_Restore_: entry-point para a realização de cópia de segurança (snapshot) e_Restore_ da instalação atual, com exceção da base de dados. - Ambari Agent: Componente Slave responsável pela execução de ações e envio de informações e métricas de determinado host.
- Base de Dados: Área de persistência do estado, métricas e metadados da infraestrutura do Cluster (serviços e hosts). O Ambari oferece suporte a vários Sistemas Gestores de Base de Dados Relacional (SGBDR), tais como PostgreSQL (default), MySQL, MariaDB, Oracle e Microsoft SQL Server, cuja escolha é feita durante a primeira configuração do Ambari Server.
Detalhes sobre o projeto
O Ambari é desenvolvido, predominantemente, em Java, JavaScript e Python.
Fontes: