大数据在杭研
随着杭研走过第十个年头，大数据平台的发展见证了多个大数据应用系统在杭研的蓬勃发展。从自研的分布式文件系统（DFS）、分布式计算框架NEMR（NetEase MapReduce）等算起，大数据平台运维工作也做了十年。最初运维工作要靠开发人员半自动、半命令行的方式进行，且平台不支持多租户，没有资源管理，所有人使用同一个资源池。因为种种原因，自研平台从2010年开始逐渐被Hadoop平台所替换，由最初的10来台服务器，经过数年的发展，现在形成多个线上独立集群、共数千台服务器的规模。日常运维操作包括集群扩容、用户管理、资源管理等方面。
本文将首先介绍Hadoop数据平台在用户、资源等方面的管理需求和相关背景，然后解析基于平台的日常管理实践，完成自动化管理方案的设计和实现。
用户管理 用户管理YARN用户的安全认证通过Kerberos与linux系统用户共同来实现：当合法的用户提交任务后，任务会被分解成子任务（Task）到每个物理服务器上执行。在Task启动时，启动脚本通过setUid权限将Task的启动用户切换成真正的用户来执行。如果该服务器上不存在此用户，那么任务就启动失败。
问题也就来了，Hadoop平台经常会有新增用户需求，如何在数百台服务器上完成这些 新增 用户创建？此外当集群扩容时，新的物理服务器上的用户如何完成同步？这是平台运维人员必须要解决的问题。
在此之前物理机的账号同步和创建工作都是通过SA这边来进行的，虽然可以满足我们的需求，但是痛点仍然存在：
创建用户需要sudo权限，通过OP工单的方式无法实现整个用户创建流程的自动化，且完成时间无法预估。 服务器扩容后的账号同步也需要走OP工单，且工单完成之后，运维人员还要做事后验证，增加额外的上线准备时间。 Kerberos用户管理简单来说，Kerberos服务由 AdminServer 和 KDC（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 LDAP+NSS系统拓扑
基于AdminServer的安全性考虑，系统只能让root用户来直接操作Kerberos数据库。故针对Kerberos用户使用以下方案：
编写脚本来实现创建Principle和导出Keytab功能。
在AdminServer上部署Agent，通过RPC调用来执行脚本。
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.memb