官方指南：
http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.12.1/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html
此处摘抄些重点的内容，并用记录自己的一些理解表达
一：Safemode（安全模式）
摘抄简述：
在启动过程中，NameNode 从 fsimage 和编辑日志文件加载文件系统状态。然后，它会等待 DataNodes 报告其块，以便它不会过早地开始复制这些块，尽管群集中已经存在足够的副本。在此期间，NameNode 留在安全模式中。NameNode 的安全模式本质上是 HDFS 群集的只读模式，它不允许对文件系统或块进行任何修改。通常，NameNode 在 DataNodes 报告大多数文件系统块可用后自动离开 Safemod。如果需要，HDFS 可以显式地放置在 Safemode 中，使用bin/hdfs dfsadmin -safemode命令。NameNode 头版显示 Safemode 是打开还是关闭。更详细的描述和配置作为 JavaDoc 维护为setSafeMode（）。
理解：HDFS 在启动时 NameNode 在加载文件系统状态时，设置集群为只读模式，防止出现不一致的情况 等，当一切准备就绪后 会自动退出安全模式。
在我学习hadoop 过程中，在启动HDFS 时 就遇到过 安全模式，
一种是 刚启动，我就开始操作文件，报错现在处于安全模式
一种是 启动后，过了几分钟钟，操作文件还是发现 报错处于安全模式，我暴力的通过手动命令，离开安全模式，但还是不能操作文件，后面才发现我的网络有问题，机器的IP未正确获取，后重新启动服务器，恢复正常
安全模式 让我在网络出现问题时 保护了我的文件 ，不会出现文件不一致 或者丢失情况
可以通过以下命令来手动离开安全模式：
bin/hadoop dfsadmin -safemode leave
//在bin下执行
//若配置环境变量，使用以下命令
hadoop dfsadmin -safemode leave
用户可以通过dfsadmin -safemode value 来操作安全模式，参数value的说明如下：
enter - 进入安全模式
leave - 强制NameNode离开安全模式
get - 返回安全模式是否开启的信息
wait - 等待，一直到安全模式结束
二：Rack Awareness（机架感知）
摘抄简述：
通常，大型 Hadoop 群集排列在机架中，并且同一机架中不同节点之间的网络流量比跨机架的网络流量更可取。此外，NameNode 尝试将块的副本放在多个机架上，以提高容错性。Hadoop 允许群集管理员通过配置变量或配置来决定节点所属的net.topology.script.file.name。配置此脚本时，每个节点运行该脚本以确定其机架 ID。默认安装假定所有节点都属于同一机架。此功能和配置在附加到HADOOP-692 的 PDF 中进一步描述。
理解：这个概念 就需要结合副本的摆放策略来一起说，用示意图如下
在HDFS 中有两种常见的摆放策略
副本摆放策略
第一种：
1-本rack的一个节点上
2-另外一个rack的节点上
3-与2相同的rack的另外一个节点上
第二种：
1-本rack的一个节点上
2-本rack的另外一个节点上
3-不同rack的一个节点上
下图 客户端需要上传一个文件 （假设此文件只被分为了1个块 即Bk1），并存在RackA 和RackB 两台机架 每台机架上有四台服务器
机群感知和副本策略 的搭配起来，
试图解决以下几个问题：
1.避免机架出现故障，导致的副本丢失 提高容错性
2.同一机架中不同节点之间的网络流量比跨机架的网络流量更可取 提供速率
其实这两点之间 存在平衡问题 ，即不能把副本放的机架过于分散，导致网络流量花费更大
又不能把副本放的服务器过于集中在同一机架上，这就需要不同的摆放策略
三：Secondary NameNode （辅助NN，第二个NameNode）
摘抄：NameNode 将对文件系统的修改存储为附加到本机文件系统文件的日志，进行编辑。当 NameNode 启动时，它从图像文件 fsimage 读取 HDFS 状态，然后从编辑日志文件中应用编辑。然后，它将新的 HDFS 状态写入 fsimage，然后使用空的编辑文件开始正常操作。由于 NameNode 仅在启动期间合并 fsimage 并编辑文件，因此编辑日志文件可能会随着时间的推移在繁忙的群集上变得非常大。较大的编辑文件的另一个副作用是，NameNode 的下一次重新启动需要更长的时间。
辅助 NameNode 会定期合并 fsimage 和编辑日志文件，并将编辑日志大小保持在限制内。它通常与主 NameNode 在不同的计算机上运行，因为其内存要求与主 NameNode 的顺序相同。
辅助 NameNode 上的检查点进程的开始由两个配置参数控制。
dfs.namenode.检查点.期间，默认情况下设置为 1 小时，指定两个连续检查点之间的最大延迟，以及
dfs.namenode.检查点.txns（默认情况下设置为 100 万）定义 NameNode 上的未选中的事务数，这将强制紧急检查点，即使尚未达到检查点周期。
辅助 NameNode 将最新的检查点存储到目录中，该检查点的结构与主 NameNode 的目录相同。以便检查指向的图像始终准备好由主 NameNode（如有必要）读取。
理解：Secondary NameNode 在我看来就是 NameNode 的备份，预备役，功能与NameNode 一致，防止在NameNode 挂掉后能接手
四：Checkpoint Node（检查节点）
摘抄：NameNode 使用两个文件保留其命名空间：fsimage，这是命名空间和编辑的最新检查点，是自检查点以来对命名空间的更改的日志（日志）。当 NameNode 启动时，它将合并 fsimage 并编辑日志，以提供文件系统元数据的最新视图。NameNode 然后用新的 HDFS 状态覆盖 fsimage 并开始新的编辑日志。
检查点节点定期创建命名空间的检查点。它从活动 NameNode 下载 fsimage 和编辑，在本地合并它们，并将新图像上载回活动 NameNode。检查点节点通常运行在与 NameNode 不同的计算机上，因为其内存要求与 NameNode 的顺序相同。检查点节点由在配置文件中指定的节点上的 bin/hdfs 名称节点 - 检查点启动。
检查点（或备份）节点的位置及其随附的 Web 界面通过dfs.namenode.backup.地址和 dfs.namenode.backup.http 地址配置变量进行配置。
检查点节点上的检查点进程的开始由两个配置参数控制。
dfs.namenode.检查点.期间，默认情况下设置为 1 小时，指定两个连续检查点之间的最大延迟
dfs.namenode.检查点.txns（默认情况下设置为 100 万）定义 NameNode 上的未选中的事务数，这将强制紧急检查点，即使尚未达到检查点周期。
检查点节点将最新的检查点存储到与 NameNode 的目录结构相同的目录中。这允许检查点图像始终可供 NameNode 读取（如有必要）。请参阅导入检查点。
群集配置文件中可以指定多个检查点节点。
自我理解：
元数据：HDFS的目录结构以及每个文件的Block信息（id,副本系数，block存放路径）
存在路径：对应配置${hadoop.tmp.dir}/name/…
Checkpoint 这个功能 和 Secondary NameNode 要联系起来
可以解决 NameNode 挂掉后，通过Checkpoint 来进行将数据找回的
首先要知道NameNode的工作步骤，当客户端在操作时，文件，目录等元数据信息是以树状结构存在内存当中，fsimage 相当于一个中转站，客户的操作 记录在edits 日志文件中，文件等信息存储在fsimage上 例如上传一个大文件到HDFS, 需要传输多个dataNode上，为了元数据的一致性，上传数据先存在fsimage 上 ，当所有的数据上传完成，fsimage 定时将内存中的元数据信息序列化到磁盘上 完成存储。
元数据信息是以树状结构存在内存当中 这一点就带来一个问题，客户端在操作时，机器挂掉了，怎么办？
- Secondary NameNode 将NameNode 的fsimage ，edits拷贝
- 将fsimage 反序列化到内存 和edits 对HDFS的操作 更新到内存中
- 新的内存，将产生新的 fsimage
- 新的fsimage 将替换 NameNode上 的fsimage
经过这四步 完成元数据和操作的恢复