HDFS
适合一次写入，多次读取
NameNode将文件系统的元数据存储在内存中，因此HDFS所能存储的文件总数受限于NameNode容量
类：IOUtil Progressable
URL.setURLStreamHandlerFactory(new FsUrlStreamHandlerFactory());
distcp并行复制
数据校验 压缩（文件，map/reduce输入输出） 序列化（RPC使用,AVRO）
HDFS存储容量(中间文件和日志文件占约30%)
fsck 文件健康状况检查
http://node16:50075/blockScannerReport
Datanode块扫描器
均衡器
优化：
增大io.file.buffer.size。如64KB或128KB
安全：
Kerberos
文件属性：
Block ID: 1073741852
Block Pool ID: BP-720723591-172.17.20.166-1449572898218
Generation Stamp: 1028
Size: 2268
Availability:
node17
node18
node16
#列出当前hadoop正在执行的jobs
./hadoop job -list
#杀掉job
./hadoop job -kill job_201212111628_11166
# Notice
When we run a JAR file by using the hadoop jar command, the dependencies of the JAR file
must be included in Hadoop's class path
NameNode数据目录结构
NameNode的数据目录由dfs.namenode.name.dir配置，其目录结构如下所示：
[${dfs.namenode.name.dir}]
└[current]
├VERSION
├edits_<last transactionId_1>_<then transactionId_1>
├edits_<last transactionId_2>_<then transactionId_2>
┊......
├edits_<last transactionId_n><then transactionIdn>
├edits_inprogress_<current transactionId>
├fsimage_<old transactionId>
├fsimage_<old transactionId>.md5
└seen_txid
VERSION文件包含了当前运行的HDFS集群的版本信息，如下所示:
#Fri Jan 04 14:40:48 CST 2013
namespaceID=2066014563
clusterID=CID-a1d53d26-3cf6-41ae-9aa6-c84306cf803d
cTime=0
storageType=NAME_NODE
blockpoolID=BP-1167604030-172.10.39.247-1357281648247
layoutVersion=-40
- CDHv1.0使用clusterID来代替namespaceID，但仍然提供namespaceID以实现向下兼容。clusterID是文件系统的唯一标识符，在文件系统格式化时创建。DataNode上也会记录这个clusterID。NameNode只接受具有相同ClusterID的DataNode的连接。
- cTime是一个计数器，记录NameNode的更新次数，HDFS每升级一次，该值就会被加1。
- storageType表示当前目录的类型，对于NameNode，该值为"NAME_NODE"，对于DataNode，该值为"DATA_NODE"。
- blockpoolID是当前NameNode管理的数据块池ID，对于Federation HDFS，不同的NameNode管理不同的数据块池，同一个DataNode管理多个数据块池。blockpoolID的命名方式如下：
BP-<random num><namenode ip><namenode create time(UTC)>
- layoutVersion是一个负数，表示当前版本的HDFS使用的数据持久化方案版本。
fsimage文件是HDFS元数据检查点的持久化文件，包含了文件系统目录和文件inode信息(inode表示一个文件或目录的元数据，与Unix系统类似)。并不是每一次HDFS操作都会被写入fsimage中，fsimage中的数据与NameNode内存中的数据并不一致。NameNode启动时首先将fsimage载入内存重建NameNode元数据到最近的检查点，然后，重新执行Edit log中记录的操作，将元数据更新到最新状态。
Edit Log(编辑日志)是记录了与NameNode的每一次RPC操作。EditLog可以存放在不同的存储系统中，如本地文件系统、NFS、Bookkeeper等，HDFS使用基于transactionId的日志管理方法来实现EditLog的事务性。
seen_txid存放了transactionId，第一次format时该值为0
SecondaryNameNode的主要工作是为NameNode创建检查点、辅助NameNode处理fsimage和EditLog，防止NameNode上的EditLog过于庞大。SecondaryNameNode可以为单节点的HDFS集群提供一定的数据恢复能里，并加快NameNode的启动速度。
注意：在Hadoop官方设计文档中提到，SecondaryNameNode已经被Checkpoint Node和Backup Node取代，但是，我们认为Checkpoint Node和Backup Node都没有像SecondaryNameNode那样经过生产实践检验，其可靠性还需验证，因此，目前仍然使用SecondaryNameNode来完成NameNode检查点的创建、辅助处理NameNode镜像文件和编辑日志。
DataNode数据目录
DataNode在第一次启动时按照配置自动创建存储目录，其数据目录结构如下所示：
[${dfs.datanode.data.dir}]
└[current]
├VERSION
└[<blockpool Id>]
├dncp_block_verification.log.curr
├dncp_block_verification.log.prev
├[tmp]
└[current]
├VERSION
├[rbw]
│ ├blk_<id_1>
│ ├blk_<id_1>.meta
│ ┊......
│ ├blk_<id_n>
│ └blk_<id_n>.meta
└[finalized]
├blk_<id_1'>
├blk_<id_1'>.meta
├......
├blk_<id_n>
├blk_<id_n>.meta
├[subdir 0]
├[subdir 1]
┊......
└[subdir n]
DataNode的数据目录相对NameNode的要复杂的多，这里介绍几个关键的目录和文件进行说明。
顶部的VERSION与NameNode数据目录下的VERSION文件类似，记录了该DataNode的版本信息，包括storageID、clusterID、storageType、layoutVersion和cTime。
以BlockPool ID命名的目录是对应数据块池的数据存储目录，其下存储了该数据块池的所有数据。该目录下的dncp_block_verification.log.[prev|curr]文件为DataNode块扫描操作的日志，DataNode块扫描相关内容参见3.2.1节相关内容。tmp保存了临时备份数据块，current目录为该数据块池的数据目录，其下的VERSION文件记录了该数据块池的版本信息，包括namespaceID、cTime、blockpoolID和layoutVersion。rbw目录和finalized目录分别存储了处于RBW/RWR/RUR状态的数据副本和已经完成备份的数据副本（Finalized状态）。表3-1对数据块的状态进行了说明。
表3-1 数据副本状态
|
块状态 |
存储目录 |
说明 |
|
Finalized |
${BP_HOME}/current/finalized |
表示该副本已经完成了所有数据的写入。 |
|
RBW |
${BP_HOME}/current/rbw |
表示该副本正在写入或追加数据。 |
|
RWR |
${BP_HOME}/current/rbw |
如果DataNode宕机或重启，处于RBW状态的副本将转换为RWR状态，不会在接受新数据的写入。 |
|
RUR |
${BP_HOME}/current/rbw |
当租约到期，NameNode将为客户端关闭其所占用的副本，这将使该副本进入RUR状态。 |
|
Temporary |
${BP_HOME}/tmp |
表示该副本正在被创建。 |
*${BP_HOME}为${datanode.data.dir}/current/<blockpool_id>
一个数据块由两个文件组成，一个为块数据文件(以blk_为前缀)，一个为该数据块的元数据文件(以.meta为后缀)，该文件包括了数据块的版本、类型和一系列区域检验和。当数据目录中的块文件达到64个之后，DataNode会在该目录下建立一个子目录(subdirn)，将这些块文件移动到该目录下，以避免一个目录存储过多的文件，影响了系统的性能。
管理HDFS集群
HDFS为集群管理者提供了一系列管理工具，通过这些管理工具，管理员可以及时了解集群运行状态。下面对几个常用的工具进行介绍：
dfsadmin
dfsadmin是Hadoop提供的命令行形式的多功能管理工具，通过该工具可以查看Hadoop集群的运行状态、管理Hadoop集群。该工具的调用方式为:
$ bin/dfs dfsadmin <command> [params...]
dfsadmin提供的功能如表3-2所示。
表3-2 dfsadmin命令
|
命令 |
格式 |
说明 |
|||
|
-report |
-report |
显示文件系统的统计信息及集群的运行状态。 |
|||
|
-safemode |
-safemode <enter |
leave |
get |
wait> |
改变、查询安全模式状态 |
|
-saveNamespace |
-saveNamespace |
将当前内存中的文件系统映像保持为一个新的fsimage文件，重置edits文件。 |
|||
|
-restoreFailedStorage |
-restoreFailedStorage <true |
false |
check> |
设置/取消/检查NameNode中恢复失败存储的可用副本的标记。 |
|
|
-refreshNodes |
-refreshNodes |
更新允许连接到namenode的datanode列表。该操作会使namenode重新读取dfs.hosts、dfs.host.exclude的配置。 |
|||
|
-finalizeUpgrade |
-finalizeUpgrade |
移除datanode和namenode存储目录下的旧版本数据。一般在升级完成后进行。 |
|||
|
-upgradeProgress |
-upgradeProgress <status |
details |
force> |
获取HDFS的升级进度，或强制升级。 |
|
|
-metasave |
-metasave filename |
将HDFS部分信息存储到Hadoop日志目录下的指定文件中。这些信息包括:
|
|||
|
-refreshServiceAcl |
-refreshServiceAcl |
刷新namenode的服务级授权策略文件 |
|||
|
-refreshUserToGroupsMappings |
-refreshUserToGroupsMappings |
刷新用户组信息 |
|||
|
-refreshSuperUserGroupsConfiguration |
-refreshSuperUserGroupsConfiguration |
刷新超级用户代理组信息 |
|||
|
-printTopology |
-printTopology |
显示集群拓扑结构 |
|||
|
-refreshNamenodes <datanodehost:port> |
使给定datanode重新载入配置文件，停止管理旧的block-pools，并开始管理新的block-pools |
|||
|
-deleteBlockPool |
-deleteBlockPool |
删除指定datanode下给定的blockpool。
|
|||
|
-setQuota |
-setQuota |
设置目录配额，即该目录下最多包含多少个目录和文件。该配置主要用于防止用户创建大量的小文件，以保护namenode的内存安全。 |
|||
|
-clrQuota |
-clrQuota <dirname>...<dirname> |
清除指定目录的配额。 |
|||
|
-setSpaceQuota |
-setSpaceQuota |
设置目录的空间配额，以限制目录的规模。一般用户用于给多个用户分配存储空间。 |
|||
|
-clrSpaceQuota |
-clrSpaceQuota <dirname>...<dirname> |
清理目录的空间配额。 |
|||
|
-setBalancerBandwidth |
-setBalancerBandwidth |
设置负载均衡器的带宽限制。限制负载均衡器的带宽十分有必要。 |
|||
|
-fetchImage |
-fetchImage <local directory> |
下载最新的fsimage文件到指定的本地目录下。 |
fsck
HDFS提供fsck工具来查找HDFS上的文件缺失的块、副本缺失的块和副本过多的块。使用方式如下：
$ bin/hdfs fsck <path> [-move| -delete|-openforwrite] [-files[-blocks[-locations|-racks]]]
表3-3 fsck命令选项
|
命令选项 |
说明 |
|
<path> |
要检查的目录或文件的HDFS路径 |
|
-move |
将损坏的文件移动到 /lost+found |
|
-delete |
删除损坏的文件 |
|
-openforwrite |
显示正在写入的文件 |
|
-files |
显示被检查的文件 |
|
-blocks |
显示文件中的各个块信息 |
|
-locations |
显示每一块的位置 |
|
-racks |
显示每个块的机架位置和DataNode地址 |
下面给出一个示例，并解释其中的含义。
$ bin/hdfs fsck /
打印结果如下：
Connecting to namenode via http://node1:50070
FSCK started by root (auth:SIMPLE) from /172.10.39. ••• for path / at Sat Jan 05 15:39:26 CST 2013
..............Status: HEALTHY
Total size: 215543188002 B ①
Total dirs: 788
Total files: 1146 (Files currently being written: 3)
Total blocks (validated): 4045 (avg. block size 53286325 B) (Total open file blocks (not validated): 3)
Minimally replicated blocks: 4045 (100.0 %) ②
Over-replicated blocks: 0 (0.0 %) ③
Under-replicated blocks: 0 (0.0 %) ④
Mis-replicated blocks: 0 (0.0 %) ⑤
Default replication factor: 3
Average block replication: 3.0
Corrupt blocks: 0 ⑥
Missing replicas: 0 (0.0 %) ⑦
Number of data-nodes: 3
Number of racks: 1
FSCK ended at Sat Jan 05 15:39:26 CST 2013 in 76 milliseconds
The filesystem under path '/' is HEALTHY
fsck扫描结果非常直观明了，下面对部分条目进行解释。
- 显示了扫描的目录的一些统计信息，包括占的空间大小、目录数、文件数、正在写入的文件数、总块数及块的其他信息；
- 达到默认副本数的块 默认备份数由配置项dfs.replication设定；
- 过多备份数的块 指超出默认备份级别的块，过多的副本会被HDFS自动删除；
- 备份数不够的块 指备份数低于默认备份级别的块，HDFS会自动为这些块创建副本(如果集群条件不允许创建新的副本(如单机模式下配置了超过1个的备份级别)，HDFS会一直进行尝试，直到满足默认复制级别为止)。可以使用dfsadmin –metasave命令查看正在复制和等待复制的块的信息；
- 错误的备份块 指不符合副本放置策略的副本块，这种情况通常发生在修改机架感应配置之后。需要手动修复错误的备份块，具体方式如下：
- 使用hadoop fs –setrep命令增加错误块对应文件的备份数；
- 等待副本被创建
- 使用hadoop fs –setrep命令将错误块对应文件的备份数恢复的原来级别。
- 损坏的块 指那些所有副本都已经损坏的块。
- 丢失的块 指那些没有任何副本的块。
块损坏和丢失意味着数据丢失，HDFS无法修复出现数据丢失的文件，不过fsck提供一些选项来处理这些损坏的文件，以减少数据丢失带来的损失，包括-move选项和-delete选项。-move选项将损坏的文件移动到/lost+found目录下，-delete选项则会直接删除损坏的文件。
注意：fsck工具只是扫描namenode上的元数据，而没有正真的扫描datanode上的块数据，因此，扫描结果与实际的HDFS情况有可能不一致。
DataNode块扫描
每个DataNode在后台都会执行一个块扫描任务，定期检测该节点上所有块的状态，以便及时检测和修复有错误的块。块扫描器每隔3周(可通过配置项"dfs.datanode.scan.period.hours"配置)执行一次检测任务，在此过程中，损坏的块将被及时上报到NameNode进行处理。可以通过HDFS的Web接口获取块扫描报告，Web接口如下，可通过listblocks参数获取该datanode下的所有块信息。
http://<datanode host>:50075/blockScannerReport[?listblocks]
下面是一份块扫描报告示例，可以看出，该DataNode当前管理的Block Pool中有4210个块，最近四周验证了268个块,当前验证周期完成进度为8%。同时可以看出，DataNode对块扫描的速度进行了限制(1024KB/s)。
Block report for block pool: BP-1167604030-172.10.39.247-1357281648247
Total Blocks : 4210
Verified in last hour : 59
Verified in last day : 252
Verified in last week : 268
Verified in last four weeks : 268
Verified in SCAN_PERIOD : 268
Not yet verified : 3942
Verified since restart : 2414
Scans since restart : 2414
Scan errors since restart : 0
Transient scan errors : 0
Current scan rate limit KBps : 1024
Progress this period : 8%
Time left in cur period : 94.98%
当使用listblocks参数时，将获取所有4210个块的详细信息。下面是节选的示例：
Block report for block pool: BP-1167604030-172.10.39.247-1357281648247
blk_7157586640620185565_45291 : status : ok type : none scan time : 0
not yet verified
blk_5595226818506773378_45318 : status : ok type : none scan time : 0
not yet verified
......
blk_4076176118522921159_43689: status : ok type : local scan time: 1357376657973
2013-01-05 17:04:17,973
blk_1045572311214380377_44883 : status : ok type : local scan time : 1357376678774
2013-01-05 17:04:38,774
Total Blocks : 4210
Verified in last hour : 62
......
Time left in cur period : 94.96%
上述列表中，每一行显示一个块的信息，显示格式如下:
<block id>:status:<ok|failed> type:<local|remote|none> scan time:<"0 not yet verified" | UTCTime yyyy-mm-dd hh:mm:ss,sss>
- 块的状态有两种，ok表示正常，failed表示损坏。
- 块的类型有三种，local表示本地块，remote表示远程块，none表示尚未扫描。如果扫描操作由后台线程执行，则为local，如果扫描操作由客户端或其他datanode执行，则为remote类型。
负载均衡
虽然HDFS在写入数据时进行了负载均衡，但是，随着系统的运行，每个datanode上的块分布仍然可能会不均衡，从而导致热点，并削弱MapReduce的数据本地化优势，因此，要避免这种情况出现。HDFS提供了负载均衡器程序，可将负载较重的DataNode上的块数据转移到空闲的DataNode上。集群均衡的标准为LmeigeDataNode的使用率和集群的使用率之间的差别小于阈值(默认为10%)。当集群的负载达到均衡标准后，负载均衡器就自动退出了。启动负载均衡器的方式如下所示
$ sbin/start-balancer.sh [–threshold n] [-policy [datanode|blockpool]]
下面是一个负载均衡器的输出示例：
13/01/05 17:29:50 INFO balancer.Balancer: Using a threshold of 1.0
13/01/05 17:29:50 INFO balancer.Balancer: namenodes = [hdfs://node1:8020]
13/01/05 17:29:50 INFO balancer.Balancer: p =
Balancer.Parameters[BalancingPolicy.Node, threshold=1.0]
Time Stamp Iteration# Bytes Already Moved Bytes Left To Move Bytes Being Moved
13/01/05 17:29:51 INFO net.NetworkTopology: Adding a new node: /default-rack/172.10.39.246:50010
13/01/05 17:29:51 INFO net.NetworkTopology: Adding a new node: /default-rack/172.10.39.247:50010
13/01/05 17:29:51 INFO net.NetworkTopology: Adding a new node: /default-rack/172.10.39.245:50010
13/01/05 17:29:51 INFO balancer.Balancer: 0 over-utilized: []
13/01/05 17:29:51 INFO balancer.Balancer: 0 underutilized: []
The cluster is balanced. Exiting...
Balancing took 1.461 seconds
haadmin
CDHv1.0提供hdfs haadmin来管理HA集群。可通过hdfs haadmin –help <command>获取特定命令的帮助信息。
3.2.2 状态监控
审计日志
有些CDHv1.0用户可能需要对CDH的日常运行进行审计，HDFS通过配置log4j的级别为INFO来实现日志审计功能，使每个HDFS事件均可在NameNode的日志中生成一行记录。CDH v1.0默认开启日志审计功能。为了不与NameNode监控日志混在一起，最好将审计日志单独输出。具体做法请参见Hadoop Wiki: http://wiki.apache.org/hadoop/HowToConfigure。
监控日志
CDH v1.0中所有组件都会产生日志文件，这些文件有助于查明系统故障的原因。通过在hadoop-env.sh文件中加入下述环境变量，可配置Hadoop日志目录：
export HADOOP_LOG_DIR=/var/log/hadoop
CDH v1.0各组件的日志分为两类，第一类以.log为后缀，由log4j生成，CDHv1.0的大部分日志都会记录在这类日志文件中；第二类以.out为后缀，主要记录标准输出和标准错误日志，这些日志基本为空，因此在故障排查时，因首先检查log4j日志。
说明：CDH v1.0所有组件都提供审计日志和监控日志，日志管理方式与HDFS一致。本文档只介绍HDFS日志配置，其他组件的日志配置类推。
JVM堆栈
CDH v1.0提供一个Web接口对正在守护进程中运行的JVM中的线程执行线程转储，可获得对应守护进程内的线程堆栈信息。如获取namenode的线程堆栈信息，可在浏览器中输入:http://namenode:50070/stacks，获得的结果如下所示：
Process Thread Dump:
27 active threads
Thread 41 (1843720310@qtp-1619519236-7):
State: RUNNABLE
Blocked count: 52
Waited count: 1509
Stack:
sun.management.ThreadImpl.getThreadInfo1(Native Method)
sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:156)
sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:121)
org.apache.hadoop.util.ReflectionUtils.printThreadInfo(ReflectionUtils.java:162)
org.apache.hadoop.http.HttpServer$StackServlet.doGet(HttpServer.java:816)
javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
......
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
Thread 35 (org.apache.hadoop.hdfs.server.namenode.LeaseManager$Monitor@3a32ea4):
State: TIMED_WAITING
......
度量信息
CDH各组件都有一套完整而独立的度量系统，用于收集CDH各组件的运行信息。度量从属于特定的上下文(所谓上下文是指应用程序运行期间，系统为其提供的完整的运行时环境，包括软件环境和硬件环境)。HDFS使用的上下文包括"dfs"、"rpc"、"ugi"、"jvm"。上下文是度量发布的单位，即度量以上下文为单位输出给度量接受组件，如本地文件、Ganglia、JMX等。度量在etc/hadoop/hadoop-metrics.properties和etc/hadoop/hadoop-metrics2.properties中进行配置，该文件每一节对应一个上下文，并指定一个类来管理该上下文中的度量，这个类必须实现MetricsContext接口。CDHv1.0提供了几个预定义的度量类，如表3-4所示。默认情况下，所有上下文都被配置成不发布状态。
表3-4 CDH v1.0预定义的度量类
|
类名 |
说明 |
|
NullContext |
不输出也不更新度量 |
|
NullContextWithUpdateThread |
输出度量到本地文件，适合调试工作，不适合在生产环境中使用 |
|
GangliaContext |
输出到Ganglia，详情参见下一节 |
|
NullContextWithUpdateThread |
刷新但不输出度量，可用于JMX |
|
CompositeContext |
可将多个度量接受组件输出同一组度量 |
一些开源的集群监控项目
可用于hadoop的集群的分布式监控系统很多，比较有名的有：
- Chukwa 一个基于HDFS和MapReduce的集群监控系统，主要在日志挖掘、大规模数据统计方面存在优势。
- Ganglia 一个正对超大规模集群的开源分布式监控系统，占用资源少，界面美观，可扩展性好。
CDHv1.0没有包含集群监控组件，但CDHv1.0兼容上述两种开源监控系统，如果需要，请参考相关项目官方网站获取技术支持。
预告：CDH v2.0将包含一个基于Web的部署、管理和监控服务组件。
3.2.3 日常维护
元数据备份
NameNode保存了HDFS的名字空间，如果哦NameNode上的数据丢失或损坏，将导致整个文件系统都无法运行，因此，有必要对元数据进行备份。如果使用HDFS HA特性，HDFS元数据会自动备份和恢复，无需人工干预。如果没有启动HDFS HA特性，则需要手动备份和恢复元数据。
最简单的元数据备份方法就是通过cron定期执行元数据备份脚本，将SecondaryNameNode节点的previous.checkpoint目录打包复制到远程站点下存储。恢复时，首先，将备份的元数据归档文件将解压到新的NameNode节点的数据目录下(由dfs.namenode.name.dir配置)，然后，启动NameNode加载备份数据，使HDFS上线工作。恢复前，可以使用Offline Image Viewer工具检查备份元数据的完整性。
说明：
- Cron的使用请参考下列网址: http://en.wikipedia.org/wiki/Cron
- Offline Image Viewer请参考下列网址: http://hadoop.apache.org/docs/hdfs/current/hdfs_imageviewer.html
数据备份
和所有存储系统一样，HDFS也无法避免数据丢失的现象发生。HDFS虽然在设计时充分考虑了数据可靠性问题，但是HDFS的副本冗余备份技术仍然无法保证数据不会因为硬件故障、软件bug等原因而丢失，因此，仍然有必要对关键数据进行备份。
一般来说，对于业务数据，并不需要全部备份，只需要备份那些无法重新获得的关键数据即可。数据备份的方式很多，如可以使用HDFS的distcp工具将数据以分布式的方式存储到其他HDFS集群中。
系统维护
对于HDFS这样的分布式存储系统，在运行过程中难免会出现一些错误，造成数据损伤，因此，建议定期运行fsck工具对HDFS进行检查，以尽早发现错误并及时纠正。定期运行负载均衡器有助于保持HDFS健康、持续高效的运行。
HDFS在运行过程中会产生大量日志，不定期清理这些日志文件会导致磁盘空间的浪费。同时，过多的日志文件和不恰当的日志目录设置(如设置在系统分区下)，可能导致系统运行异常，甚至无法启动。CDH v1.0引入了日志清理功能，可定期检查日志目录的大小，清除过期日志，该功能在hdfs-site.xml中配置，具体配置项如下：
表3-5 日志清理配置选项
|
配置项 |
配置说明 |
|
log.clean.scan.interval |
定时扫描目录的时间间隔，默认36000s; |
|
log.clean.delete.uplimit |
当目录占所在磁盘的比例在配置值之上将触发一次清理操作，默认为0.8(80%), |
|
log.clean.delete.lowlimit |
一次清理操作将是清理的目录的磁盘占有率下降到本项配置的比率之下，默认为0.2(20%); |
|
log.clean.monitor.dir |
要监控并清理的目录，多个目录用逗号","隔开，默认为空，这将导致LogCleaner启动失败。 |
注意：
- 日志目录清理功能目前只能在DataNode节点上使用
- 日志目录清理功能清理不限于HDFS的日志，也可以是其他组件的日志
添加节点
在CDH运行过程中我们可能需要向集群添加节点以扩大集群的容量，提高集群的性能。对于HDFS，一般添加的节点都是作为DataNode来运行的。下面的步骤说明如何向HDFS集群添加DataNode节点。
- 将新节点的主机名添加到include文件中(include文件为配置项dfs.hosts指向的文件)；
- 部署、配置新节点上的HDFS组件
- 运行dfsadmin -refreshNodes命令，使NameNode更新最新的DataNode列表:
$ bin/hdfs dfsadmin -refreshNodes
- 将新节点的主机名加入slaves文件中，以使HDFS控制脚本能控制这些节点；
- 在新节点上运行下列命令，启动新的datanode：
$ bin/dfs datanode
- 通过dfsadmin –report命令或Web UI确认新节点是否已经加入集群。
说明：如果新加入的节点很多，可以在任何一台节点上重新执行start-dfs.sh脚本即可启动所有新节点上的DataNode，已启动DataNode或NameNode的节点不会重新启动。
注意：在为HDFS添加节点之前，最好做一些审核工作，已确定加入的节点完全属于集群控制之下。未经审核的节点上可能会运行其他集群的组件，被其他集群控制，随时都有可能断开与HDFS集群的连接，存在数据丢失的隐患。
解除节点
HDFS能够很好的应对少量DataNode故障的情形，这并不意味着可以随意关闭DataNode节点。如果关闭的DataNode个数超过HDFS配置的默认备份数，HDFS就有较大概率出现数据丢失(这个概率随集群规模的增大而减少)。因此，在非DataNode故障的情况下关闭一个DataNode，最好先通知NameNode，以便其能在该节点停机前将数据转移到其他DataNode上。与添加节点对应，HDFS采用exclude文件来指定排除的节点(exclude文件为dfs.hosts.exclude指定的文件)。解除节点的步骤如下：
- 将需要解除的节点主机名加入exclude文件中；
- 运行dfsadmin -refreshNodes命令，使NameNode更新最新的DataNode列表；
- 通过dfsadmin –report命令或Web UI查看待解除节点的状态是否处于Decommission状态，该状态表明该节点正在转移数据到其他节点；
- 当待解除节点的状态变为Decommissioned时，说明数据已转移，可以任意关闭该节点；
- 从include文件中移除待解除节点的主机名，并使用dfsadmin -refreshNodes命令再次更新NameNode上的DataNode列表；
- 从slaves文件中移除这些节点，解除集群对这些节点的控制。
需要注意的是，include文件和exclude文件可能出现冲突，有些节点既出现在include文件中，也出现在exclude文件中，HDFS通过节点在include文件和exclude文件的状态来确定DataNode所处的状态，具体如表3-6所示。
表3-6 DataNode状态
|
在include中 |
在exclude中 |
DataNode状态 |
|
否 |
否 |
不属于HDFS的节点或已经解除的节点 |
|
否 |
是 |
已经解除的节点(集群重启时) |
|
是 |
否 |
一般节点 |
|
是 |
是 |
将被解除的节点 |