HADOOP大数据之HDFS管理与运维

2023-02-28 本文已影响0人奋斗的韭菜汪

一、HDFS数据迁移解决方案

HDFS分布式拷贝工具DistCp
数据迁移使用场景：
冷热集群数据同步、分类存储
集群数据整体搬迁
数据的准实时同步
数据迁移要素考量

带宽
性能
是否支持增量同步
4、数据迁移的同步性

image.png

DistCp

是Hadoop中的一种工具，在hadoop-tools工程下，作为独立子工程存在
定位用于数据迁移，定期在集群之间和集群内部备份数据
在备份过程中，每次运行DistCp都称为一个备份周期，尽管性能相对较慢，但它的普及程度已经越来越高
DistCp底层使用MapReduce在集群之间或并行在同一集群内复制文件。执行复制的MapReduce只有Mapper阶段

DistCp优势性能

带宽限流
增量数据同步

image.png

例如：hadoop distcp hdfs://nn1:8020/foo/a  hdfs://nn2:8020/bar/foo
表示：从nn1集群拷贝/foo/a路径下的数据到nn2集群的/bar/foo路径下

二、NAMENODE安全模式

安全模式是HDFS所处的一种特殊状态，在这种状态下，文件系统只接受读数据请求，而不接受删除、修改等变更请求，是一种保护机制，用于保证集群中的数据块的安全性。

在NameNode主节点启动时，HDFS首先进入安全模式，集群会开始检查数据块的完整性。DataNode在启动的时候会向namenode汇报可用的block信息，当整个系统达到安全标准时，HDFS自动离开安全模式。
假设我们设置的副本数（即参数dfs.replication）是5，那么在Datanode上就应该有5个副本存在，假设只存在3个副本，那么比例就是3/5=0.6。在配置文件hdfs-default.xml中定义了一个最小的副本的副本率（即参数dfs.namenode.safemode.threshold-pct）0.999。

我们的副本率0.6明显小于0.99，因此系统会自动的复制副本到其他的DataNode,使得副本率不小于0.999.如果系统中有8个副本，超过我们设定的5个副本，那么系统也会删除多余的3个副本。

三、HDFS高阶优化方案

短路本地读取、负载均衡、磁盘均衡器、纠删码存储

短路本地读取

DFSClient绕开DataNode 直接读取Data Directories（前提条件：DFSClinet客户端和DataNode在同一台机器上）

大数据HDFS短路本地读取示意图 (1).jpg

HDFS Block磁盘均衡器：Balancer

volume Data Density（磁卷数据密度）
节点数据密度
配置项：dfs.disk.balancer.enabled，默认为true

纠删码技术 Erasure Coding

Erasure Code（EC），即纠删码，是一种前向错误纠正技术（Forward Error Correction，FEC，说明见后附录），主要应用在网络传输中避免包的丢失，存储系统利用它来提高存储可靠性。相比多副本复制而言，纠删码能够以更小的数据冗余度获得更高数据可靠性，但编码方式较复杂，需要大量计算。纠删码只能容忍数据丢失，无法容忍数据篡改，纠删码正是得名与此。

$\color{red}{HDFS默认情况下启用的是RS-6-3-1024k}$

四、HDFS动态节点管理

动态缩容、节点下线

hdfs --daemon stop datanode

HDFS集群黑、白名单机制

白名单由dfs.hosts参数指定，该参数位于hdfs-site.xml中，默认值为空（允许所有机器准入）
黑名单由dfs.hosts.exclude参数指定，该参数位于hdfs-site.xml中，默认值为空（不禁止任何主机加入）

五、HDFS HA高可用机制

高可用（HA)的背景知识

主备集群角色（Active-Standby）

HA系统设计核心问题

脑裂问题
脑裂(split-brain)是指“大脑分裂”,本是医学名词。
在HA集群中，脑裂指的是当联系主备节点的"心跳线"断开时(即两个节点断开联系时)，本来为一个整体、动作协调的HA系统，就分裂成为两个独立的节点。由于相互失去了联系，主备节点之间像"裂脑人"一样，使得整个集群处于混乱状态。
脑裂的严重后果︰
1) $\color{red}{集群无主}$ ∶都认为对方是状态好的，自己是备份角色，后果是无服务;
2) $\color{red}{集群多主}$ ∶都认为对方是故障的，自己是主角色。相互争抢共享资源，结果会导致系统混乱，数据损坏。此外对于客户端访问也是一头雾水，找谁呢?
避免脑裂问题的核心是∶保持任意时刻系统有且只有一个主角色提供服务。
数据状态同步问题
主备切换保证服务持续可用性的前提是主备节点之间的状态、数据是一致的，或者说准一致的。如果说备用的节点和主节点之间的数据差距过大，即使完成了主备切换的动作，那也是没有意义的。
数据同步常见做法是∶通过 $\color{red}{日志重演操作记录}$ 。主角色正常提供服务，发生的事务性操作通过日志记录，备用角色读取日志重演操作。
l
HDFS HA解决方案--QJM
Quorum Journal Manager介绍
Q.JM全称Quorum Journal Manager(仲裁日志管理器），是Hadoop官方推荐的HDFS HA解决方案之一。
使用zookeeper中ZKFC来实现主备切换﹔
使用Journal Node ( JN)集群实现edits log的共享以达到数据同步的目的。

image.png

Journal Node ( JN)特点：高速读写数据、存储数据

HDFS HA集群搭建

六、HDFS Federation联邦机制

当前的HDFS架构有两个主要的层︰

当前的HDFS架构

命名空间( namespace )
由文件，块和目录组成的统一抽象的目录树结构。由namenode根据用户操作实时维护树结构。
块存储层( Block Storage )
包括两个部分∶
块管理:NameNode执行块管理。块管理通过处理注册和定期心跳来提供Datalode群集成员身份。它处理块报告并支持与块相关的
操作，如创建，删除，修改或获取块位置。它还维护块的位置，副本位置。为未复制的块管理块复制，并在已复制的块中删除。>存储:DataNode通过在本地文件系统上存储块并提供读/写访问权限来管理存储空间。

当前HDFS体系架构--局限性
当下的HDPS体系结构仅允许单个NameNode维护文件系统名称空间。这种体系目前存在着一些弊端和局限性︰

DataNode磁盘存储空间不够增加节点，NameNode内存不够是否可以无限扩容。思考一下:一种是DataNode横向扩展机器增加节点，一种是纵向扩展单机加内存。
由于名称空间和存储层的紧密耦合，NameNode的替代实现很困难。这限制了其他服务直接使用块存储。NameNode成了唯一入口。
文件系统的操作还限于NameNode一次处理的任务数。因此，群集的性能取决于NameNode吞吐量。
同样，由于使用单个名称空间，因此使用群集的占用者组织之间没有隔离。

联邦Federation架构--简介
$\color{red}{引申：}$ 联邦Federation和高可用HA的区别：联邦是集群中多个节点同时提供服务，HA只有一个提供服务，其他作为预备服务。
Federation中文意思为联邦,联盟，是 $\color{red}{NameNode之间的Federation,也就是集群中会有多个NameNode}$ 。多个NameNode的情况意味着有多个namespace。注意，这区别于HA模式下的多NameNode，HA中它们是拥有着同一个namespace。Federation体系中 $\color{red}{多个namenode之间相互独立且不需要互相协调，各自分工，管理自己的区域}$ 。每个DataNode要向集群中所有的namenode注册，且周期性地向所有namenode发送心跳和块报告，并执行来自所有namenode的命令。
联邦Federation架构

七、HDFS集群滚动升级

HDFS集群滚动升级

在Hadoop v2中，HDFS支持NameNode高可用(HA )。使得不停机升级HDFS变得可行。请注意，仅从Hadoop-2.4.0起才支持滚动升级。
$\color{red}{因此为了在不停机的情况下升级HDFS群集，必须使用HA设置群集。}$
在HA群集中，有两个或多个NameNode ( NN)，许多DataNode ( DN)，一些JournalNode ( JN )和一些ZooKeeperNode
(ZKN )。
JN相对稳定，在大多数情况下，升级HDFS时不需要升级。
$\color{red}{滚动升级过程中，仅针对NNs和DNs，JNS和ZKNs都没有。}$ 升级.JN和ZKN可能会导致群集停机。

不停机滚动升级--非联邦HA集群

不停机滚动升级--联邦HA集群

不停机滚动升级--非HA集群（需要停机，生产环境不适用）

HDFS集群降级和回滚

降级
HA集群降级(downgrade )注意事项
降级与升级在HA模式下有一个共同点
在操作lameMode时,都是先从Standby节点开始操作,等Standby节点升/降结束,做一次切换,使另外一个节点得以进行升/降操作.在全程中,始终保持一个Active节点对外提供服务。
降级过程NameNode与DataNode的操作和在升级时操作顺序正好相反
新版本一般在协议、API是兼容老版本的,如果先降级NN,那么则会造成DN是新版,NN是旧版。新版DN中的许多协议将会在旧版NN中可能不兼容。
所以这里必须要先降级DN,然后再把服务端NN进行降级.看似简单的一次顺序颠倒,背后其实是有更深层的原因的.
回滚
回滚注意事项:
Rollback不支持滚动操作的方式,在操作期间,它需要集群对外停止提供服务.
Rollback操作不仅会将软件版本退回到升级前的版本,还会将用户数据退回到升级前的状态.
降级(downgrade )和回滚( rollback )区别
共同点:
都会将版本退回到升级前的版本;
在升级的finalize动作执行之后,将不允许再执行降级和回滚。
不同点:
降级能支持rollling的方式,可以滚动降级,而回滚需要停止服务一段时间.降级过程只会将软件版本还原成升级前的,会保留用户现有的数据状态;而回滚则会将用户数据还原成升级前的状态模式，现有的数据状态不保存。