开发者社区> 余二五> 正文

Services and State with Ambari REST API

简介:
+关注继续查看

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,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Server Components:我们即将和 API 告别?
Server Components:我们即将和 API 告别?
22 0
Dubbo3实践:基于 API-SERVER 的原生 K8S Service
> 该示例演示了直接以 API-SERVER 为注册中心,将 Dubbo 应用部署到 Kubernetes 并复用 Kubernetes Native Service 的使用示例。 > > 此示例的局限在于需要授予每个 Dubbo 应用访问 API-SERVER 特定资源的权限,同时直接访问和监听 API-SERVER 对中小集群来说并没有什么问题,但对于较大规模集群而言可能给 API-SERV
205 0
REST Assured API Automation Testing Ⅰ - Getting Started
REST Assured API Automation Testing Ⅰ - Getting Started
34 0
YARN REST API 总结
YARN REST API 总结
227 0
JBPM学习(二):ProcessEngine与Service API
本文主要讲ProcessEngine与Service API
127 0
Web Storage API的介绍和使用
Web Storage API的介绍和使用
85 0
使用jMeter对基于SAP ID service进行Authentication的Restful API进行并发测试
使用jMeter对基于SAP ID service进行Authentication的Restful API进行并发测试
87 0
+关注
余二五
文章
问答
视频
文章排行榜
最热
最新
相关电子书
更多
开源广进-用Service Catalog构造K8S服务能力
立即下载
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载