机架感知:
检查两台是否在同一机架上
NameNode通过Hadoop Rack Awareness中概述的过程确定每个DataNode所属的机架ID 。
一个简单但非最优的策略是将复制品放在独特的机架上。这可以防止在整个机架发生故障时丢失数据,
并允许在读取数据时使用来自多个机架的带宽。此策略在群集中均匀分布副本,
这样可以轻松平衡组件故障的负载。但是,此策略会增加写入成本,因为写入需要将块传输到多个机架。
副本存放策略:
基于机架感知
当复制因子为3时,HDFS的放置策略是在编写器位于datanode上时将一个副本放在本地计算机上,
否则放在随机datanode上,另一个副本放在另一个(远程)机架上的节点上,
最后一个在同一个远程机架的不同节点上。此策略可以减少机架间写入流量,从而提高写入性能。
机架故障的可能性远小于节点故障的可能性; 此策略不会影响数据可靠性和可用性保证。
但是,它确实减少了读取数据时使用的聚合网络带宽,因为块只放在两个唯一的机架而不是三个。
使用此策略时,文件的副本不会均匀分布在机架上。三分之二的副本位于一个机架上,另外三分之一均匀分布在剩余的机架上。此策略可提高写入性能,而不会影响数据可靠性或读取性能。
如果复制因子大于3,则随机确定第4个及以下副本的放置,同时保持每个机器的副本数量低于上限(基本上是(副本-1)/机架+2)
网络带宽
大型HDFS实例在通常分布在许多机架上的计算机群集上运行。不同机架中两个节点之间的通信必须通过交换机。
在大多数情况下,同一机架中的计算机之间的网络带宽大于不同机架中的计算机之间的网络带宽。
数据磁盘故障:
心跳和重新复制
每个DataNode定期向NameNode发送Heartbeat消息。网络分区可能导致DataNode的子集失去与NameNode的连接。
NameNode通过缺少Heartbeat消息来检测此情况。NameNode将DataBodes标记为没有最近的Heartbeats,
并且不会将任何新的IO请求转发给它们。注册到死DataNode的任何数据都不再可用于HDFS。
DataNode死亡可能导致某些块的复制因子低于其指定值。NameNode不断跟踪需要复制的块,
并在必要时启动复制。由于许多原因可能会出现重新复制的必要性:DataNode可能变得不可用,
副本可能会损坏,DataNode上的硬盘可能会失败,
标记DataNodes死机的超时是保守的长(默认情况下超过10分钟),以避免由DataNode状态抖动引起的复制风暴。
均衡器
使忙碌的datanode上的块复制到相对空闲的datanode上,确保没datanode使用率和接近集群的使用率
start-balancer.sh
数据的完整性
从DataNode获取的数据块可能已损坏。由于存储设备中的故障,网络故障或有缺陷的软件,
可能会发生此损坏。HDFS客户端软件对HDFS文件的内容进行校验和检查。当客户端创建HDFS文件时,
它会计算文件每个块的校验和,并将这些校验和存储在同一HDFS命名空间中的单独隐藏文件中。
当客户端检索文件内容时,它会验证从每个DataNode接收的数据是否与存储在关联校验和文件中的校验和相匹配。
如果不是,则客户端可以选择从具有该块的副本的另一个DataNode中检索该块。
文件删除和取消删除:
如果启用了垃圾箱配置,则FS Shell删除的文件不会立即从HDFS中删除。
相反,HDFS将其移动到垃圾目录(每个用户在/user/<username>/.Trash下都有自己的垃圾目录)。
只要文件保留在垃圾箱中,文件就可以快速恢复。
最近删除的文件被移动到当前的垃圾箱目录(/user/<username>/.Trash/Current),
并且在可配置的时间间隔内,HDFS创建了检查点(在/ user / <username> / .Trash / <date>下)
对于当前垃圾目录中的文件,并在过期时删除旧检查点。有关垃圾箱的检查点,
请参阅FS shell的expunge命令。
它的生命周期在垃圾箱中到期后,NameNode将从HDFS命名空间中删除该文件。
删除文件会导致释放与文件关联的块。
请注意,在用户删除文件的时间与HDFS中相应增加的可用空间之间可能存在明显的时间延迟。
减少复制因子
在副本数大于设定的副本数时进行
当文件的复制因子减少时,NameNode选择可以删除的多余副本。下一个Heartbeat将此信息传输到DataNode。
然后,DataNode删除相应的块,并在群集中显示相应的可用空间。
再一次,setReplication API调用完成与集群中可用空间的出现之间可能存在时间延迟。
块缓存:
预先读取文件的块到内存,用来提升常用文件的读取效率