Services and State with Ambari REST API

本文涉及的产品
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介:

The Ambari management tool for Hadoop offers among other handy tools a comprehensive REST API for cluster administration. Logically a cluster is divided into hosts, services and service components. While the UI might not always has support for all needed scenarios sure the REST API can be used to achieve it. For example moving a master component of a service from one host to another.

In this post we are going to look a little closer at the way the Ambari API can be used to manage Hadoop services. At the end of this post you will find a list of all the currently supported Hadoop services with all the needed master, slave and client components that can be manged and administrated within your HDP stack. Also this posts contains the possible states and state transitions a component might have which could become useful when facing problems like Host config is in invalid state.

The possible states a service component can be in is listed below. To change or get the state of a service component the following API calls can be issued.

1
2
3
4
5
6
7
8
// Getting the state of the component
curl -k -u admin:admin -H  "X-Requested-By:ambari"  -i -X GET
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/hosts/<HOST_FQDN>/host_components/YARN_CLIENT 
// Setting the state of the component to INSTALLED
curl -k -u admin:admin -H  "X-Requested-By:ambari"  -i -X PUT 
-d '{ "RequestInfo" :{ "context" : "Install YARN_CLIENT" },
"Body" :{ "HostRoles" :{ "state" : "INSTALLED" }}}' 
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/hosts/<HOST_FQDN>/host_components/YARN_CLIENT

Among the need to change the state of a service component a very common issue is the need to actually move one service – most likely a master service – to different host. Users faced with this problems often need to issue the existing API due to a lack of support by the existing UI – at least with older releases of Ambari Web UI. This is an example of moving the OOZIE_SERVER to a new host.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// Stop the old component by putting it back in state INSTALLED
curl -u admin:admin -H  "X-Requested-By:ambari"  -i -X PUT 
-d  '{"RequestInfo": {"context": "Stop Oozie","query":"HostRoles/component_name.in(' OOZIE_SERVER')"}, 
"Body" :{ "HostRoles" : { "state" "INSTALLED" }}}' 
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/hosts
/<OLD_HOST_FQDN>/host_components/OOZIE_SERVER
// Add component to host
curl -u admin:admin -H  "X-Requested-By:ambari"  -i -X POST -d 
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/hosts
/<NEW_HOST_FQDN>/host_components/OOZIE_SERVER
// Install component by achieving stated INSTALLED
curl -u admin:admin -H  "X-Requested-By:ambari"  -i -X PUT 
-d  '{"RequestInfo": {"context": "Install Oozie","query":"HostRoles/component_name.in(' OOZIE_SERVER')"}, 
"Body" :{ "HostRoles" : { "state" "INSTALLED" }}}' 
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/hosts
/<NEW_HOST_FQDN>/host_components/OOZIE_SERVER
// Delete old component
curl -u admin:admin -H  "X-Requested-By:ambari"  -i -X DELETE 
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/hosts
/<OLD_HOST_FQDN>/host_components/OOZIE_SERVER
// Starting the new component
curl -u admin:admin -H  "X-Requested-By:ambari"  -i -X PUT 
-d  '{"RequestInfo": {"context": "Start Oozie","query":"HostRoles/component_name.in(' OOZIE_SERVER')"}, 
"Body" :{ "HostRoles" : { "state" "STARTED" }}}' 
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/hosts
/<NEW_HOST_FQDN>/host_components/OOZIE_SERVER

Removing a complete service from the cluster would require all the removal of all it’s components together with the service itself. For example for removing the Knox service we would need to remove the KNOX_GATEWAY component from the cluster, but before let’s get their state:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Get service info
curl -u admin:admin -H  "X-Requested-by:ambari"  -i -k -X GET
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/services/KNOX/
// Stop component KNOX_GATEWAY
curl -u admin:admin -H  "X-Requested-by:ambari"  -i -k -X PUT 
-d  '{"ServiceComponentInfo": {"state": "INSTALLED"}}'
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/services/KNOX/components/KNOX_GATEWAY
// Stop service KNOX
curl -u admin:admin -H  "X-Requested-by:ambari"  -i -k -X PUT 
-d  '{"ServiceInfo": {"state": "INSTALLED"}}'
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/services/KNOX
// Delete component
curl -u admin:admin -H  "X-Requested-by:ambari"  -i -k -X DELETE
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/hosts/<HOST_FQDN>/host_components/KNOX_GATEWAY
// Delete service
curl -u admin:admin -H  "X-Requested-by:ambari"  -i -k -X DELETE
http://<HOST>:8080/api/v1/clusters/<CLUSTER_NAME>/services/KNOX

Possible states of a component:


StateDescription

INITInitial/Clean state.

INSTALLINGIn the process of installing.

INSTALL_FAILEDInstall failed.

INSTALLEDState when install completed successfully.

STARTINGIn the process of starting.

STARTEDState when start completed successfully.

STOPPINGIn the process of stopping.

UNINSTALLINGIn the process of uninstalling.

UNINSTALLEDState when uninstall completed successfully.

WIPING_OUTIn the process of wiping out the install.

UPGRADINGIn the process of upgrading the deployed bits.

DISABLEDDisabled master’s backup state.

UNKNOWNState could not be determined.



Allowed State transitions of a component:


Desired StateStart State

INSTALLED <-INIT, UNINSTALLED, INSTALLED, INSTALLING, STARTED, INSTALL_FAILED, UPGRADING, STOPPING, UNKNOWN, DISABLED

STARTED <-INSTALLED, STARTING, STARTED

UNINSTALLED <-INSTALLED, UNINSTALLED, UNINSTALLING

INIT <-UNINSTALLED, INIT, WIPING_OUT

DISABLED <-INSTALLED, INSTALL_FAILED, UNKNOWN



Services

A Hadoop cluster contains of multiple services that individually have either master, slave or client components. Below you will find a list of all currently supported components as part of a HDP stack divided in master, slave, or client groups. The cardinality notates the number of components that can exist at the same time in one cluster.

Master Services

NameAmbari Component Name

Service

Cardinality

NameNodeNAMENODEHDFS1-2

Secondary NameNodeSECONDARY_NAMENODEHDFS1

ResourceMangerRESOURCEMANAGERYARN1-2

Application Timeline ServerAPP_TIMELINE_SERVERYARN1

HistoryServerHISTORYSERVERMAPREDUCE2 1

Hive MetastoreHIVE_METASTOREHIVE1-2

HiveServer2HIVE_SERVERHIVE1-2

WebHcat ServerWEBHCAT_SERVERHIVE1

HBase MasterHBASE_MASTERHBASE1+

Spark Job History ServerSPARK_JOBHISTORYSERVERSPARK1

Nimbus ServerNIMBUSSTORM1

Storm REST ServerSTORM_REST_APISTORM1

Storm UISTORM_UI_SERVERSTORM1

DRPC ServerDRPC_SERVERSTORM1

Falcon ServerFALCON_SERVERFALCON1

ZookeeperZOOKEEPER_SERVERZOOKEEPER1+ (odd #)

Kafka BrokerKAFKA_BROKERKAFKA1+

Knox GatewayKNOX_GATEWAYKNOX1+

Ranger Admin ServerRANGER_ADMINRANGER1-3

Ranger User SyncRANGER_USERSYNCRANGER1

Ranger Key Management ServerRANGER_KMS_SERVERRANGER_KMS1+

Oozie ServerOOZIE_SERVEROOZIE1

Ganglia ServerGANGLIA_SERVERGANGLIA1

Nagios ServerNAGIOS_SERVERNAGIOS1

Ambari Metrics ServiceMETRICS_COLLECTORAMS1

Zeppelin ServerZEPPELIN_MASTERSPARK / HIVE1



Slave Services

NameAmbari Component Name

ServiceCardinality

DataNodeDATANODEHDFS1+

Journale Nodes for NameNode HAJOURNALNODEHDFS0+ (odd #)

Zookeeper Failover ServiceZKFCHDFS0+

Secondary NameNodeNFS_GATEWAYHDFS0+

Node ManagerNODEMANAGERYARN1+

HBase RegionServerHBASE_REGIONSERVERHBASE1+

Phoneix Query ServerPHOENIX_QUERY_SERVERHBASE0+

Storm SupervisorSUPERVISORSTORM1+

Ganglia Metrics CollectorGANGLIA_MONITORGANGLIAALL

Ambari Metrics CollectorMETRICS_MONITORAMSALL


Clients

NameAmbari Component Name

ServiceCardinality

HDFS ClientHDFS_CLIENTHDFS1+

YARN ClientYARN_CLIENTYARN1+

MapReduce ClientMAPREDUCE2_CLIENTMAPREDUCE21+

Spark ClientSPARK_CLIENTSPARK1+

Falcon ClientFALCON_CLIENTFALCON1+

HBase ClientHBASE_CLIENTHBASE1+

Hive ClientHIVE_CLIENTHIVE1+

HCat ClientHCATHIVE1+

Mahout ClientMAHOUTMAHOUT0+

Oozie ClientOOZIE_CLIENTOOZIE1+

Sqoop ClientSQOOPSQOOP1+

Zookeeper ClientZOOKEEPER_CLIENTZOOKEEPER1+










本文转自 yntmdr 51CTO博客,原文链接:http://blog.51cto.com/yntmdr/1775098,如需转载请自行联系原作者
相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
目录
相关文章
|
4月前
|
JSON API 开发工具
【Azure 应用服务】调用Azure REST API来获取 App Service的访问限制信息(Access Restrictions)以及修改
【Azure 应用服务】调用Azure REST API来获取 App Service的访问限制信息(Access Restrictions)以及修改
|
1月前
|
缓存 API 网络架构
掌握现代API开发:GraphQL vs REST
【10月更文挑战第24天】本文深入探讨了现代API开发中两种主流技术——GraphQL和REST的设计理念、技术特点及实际开发中的对比分析。GraphQL通过声明式数据请求和强类型系统提供更高的灵活性和性能,而REST则以其无状态特性和成熟的生态系统见长。文章还讨论了两者在客户端-服务器交互、安全性和工具支持方面的优劣,帮助开发者根据项目需求做出明智选择。
|
3月前
|
JSON 中间件 API
开发REST API3-11
开发REST API3-11
|
3月前
|
JSON JavaScript API
编写REST API
编写REST API
65 2
|
2月前
|
Java API Maven
使用 Smart-doc 记录 Spring REST API
使用 Smart-doc 记录 Spring REST API
59 0
|
4月前
|
存储 JSON API
【Azure 存储服务】使用REST API操作Azure Storage Table,删除数据(Delete Entity)
【Azure 存储服务】使用REST API操作Azure Storage Table,删除数据(Delete Entity)
【Azure 存储服务】使用REST API操作Azure Storage Table,删除数据(Delete Entity)
|
4月前
|
XML 安全 API
REST 和 SOAP API 有什么区别?
【8月更文挑战第31天】
234 0
|
4月前
|
JSON API 数据安全/隐私保护
哇塞!Django REST framework 太逆天啦!构建 API 服务从未如此轻松,你还不来试试?
【8月更文挑战第31天】Django REST framework(DRF)是基于Django框架的高效Web API开发工具,提供序列化、视图集、路由等功能,简化API构建流程。使用DRF可轻松实现数据的序列化与反序列化,并支持权限管理和认证机制以保障API安全。安装DRF只需通过`pip install djangorestframework`命令。要创建基本项目,先安装Django并创建新应用,定义模型、序列化器及视图集,最后配置路由。测试API时,可通过Postman发送HTTP请求验证功能。无论项目大小,DRF均能提供强大支持。
47 0
|
4月前
|
中间件 API 网络架构
Django后端架构开发:从匿名用户API节流到REST自定义认证
Django后端架构开发:从匿名用户API节流到REST自定义认证
47 0
|
4月前
|
API 网络架构 C++
【Azure Key Vault】使用REST API调用Azure Key Vault Secret的示例步骤
【Azure Key Vault】使用REST API调用Azure Key Vault Secret的示例步骤