大数据Hadoop运维应用实践——Hadoop平台常见问题与故障汇总、系统调优、网络规划与硬件存储选型

大数据Hadoop运维应用实践------Hadoop资源调度与权限管理文章浏览阅读10次。本文详细介绍了Hadoop YARN资源调度策略与HDFS权限管理两大核心功能。1、在YARN部分，重点对比了三种调度器（FIFO、Capacity、Fair）的特点、适用场景、与详细的配置与操作示例。2、HDFS权限管理部分阐述了POSIX权限模型和ACL扩展访问控制机制，介绍了如何通过setfacl/getfacl命令实现精细化权限控制。全文包含大量实战配置代码和参数说明，为Hadoop集群资源管理和权限控制提供了全面的技术指导，适合大数据平台运维人员参考实施。https://blog.csdn.net/xiaochenXIHUA/article/details/163746794

一、Hadoop日常运维问题汇总

1.1、如何下线一个datanode节点（集群缩容）？

bash 复制代码

#如何下线一个datanode节点（集群缩容）
#1-修改hdfs-site.xml文件【找到namenode节点配置文件 /etc/hadoop/conf/hdfs-site.xml 文件如下选项】
    <property>    
        <name>dfs.hosts.exclude</name>     
        <value>/etc/hadoop/conf/hosts-exclude</value> 
    </property> 

#2-修改hosts-exclude文件【在 hosts-exclude 中添加需要下线的datanode主机名（一行一个主机IP或主机名称）】
vi /etc/hadoop/conf/hosts-exclude

#3-刷新配置【在namenode上以hadoop用户执行下面命令，刷新hadoop配置】
hdfs dfsadmin -refreshNodes

#4-检查是否完成下线，执行如下命令查看【也可以通过查看NameNode的50070端口访问web界面，查看HDFS状态，需要重点关注退役的节点数以及复制的块数和进度】
hdfs dfsadmin -report

1.2、某个datanode节点磁盘坏掉怎么办？

如果某个datanode节点的磁盘出现故障，将会出现此节点不能写入操作而导致datanode进程退出，解决方法如下：

bash 复制代码

#解决某个datanode节点磁盘坏掉方法
#1-在故障节点上查看【/etc/hadoop/conf/hdfs-site.xml】文件中对应的【dfs.datanode.data.dir】参数设置，去掉故障磁盘对应的目录挂载点。

#2-在故障节点上查看【/etc/hadoop/conf/yarn-site.xml】文件中对应的【yarn.nodemanager.local-dirs】参数设置，去掉故障磁盘对应的目录挂载点。

#3-重启此节点的【datanode服务】和【nodemanager服务】即可。
systemctl restart hadoop-hdfs-datanode
systemctl restart hadoop-yarn-nodemanager

#4-将故障节点上的故障磁盘挂载点卸载掉

1.3、Namenode服务器故障了怎么办？

在HDFS集群中，Namenode主机上存储了所有的元数据信息，如果此信息丢失，那么整个HDFS上面的数据将不可用。而如果Namenode服务器发生了故障无法启动，解决的方法分为两种情况：

如果Namenode做了高可用服务，那么在主Namenode故障后，Namenode服务会自动切换到备用的Namenode上，这个过程是自动的，无需手工介入。
如果你的Namenode没做高可用服务，那么还可以借助于SecondaryNameNode服务，在SecondaryNameNode主机上找到元数据信息，然后直接在此节点启动Namenode服务即可，当然这种方式可能会丢失部分数据，因为SecondaryNameNode实现的是Namenode的冷备份。

因此，对Namenode进行容灾备份至关重要，在生产环境下，建议通过standby Namenode实现Namenode的高可用热备份。

1.4、datanode存储节点数据倾斜怎么解决？

在HDFS集群中，磁盘损坏是经常出现的，磁盘故障后，一般的策略是更换新的硬盘，而当新硬盘更换后，只有新数据会写入这个硬盘，而之前的老数据不会自动将数据平衡过来，如此下去，更换的硬盘越多，节点之间、每个节点的各个磁盘之间的数据将越来越不平衡。如何解决这个问题呢？此时可以使用hadoop提供的Balancer程序使得HDFS集群达到一个平衡的状态。

bash 复制代码

#解决 datanode存储节点数据倾斜 方法
#执行hadoop的balancer程序命令平衡偏差（如只允许5%的偏差）有如下两种方法，任选一个就行
su - hadoop
#方法一【这个命令中-t参数后面跟的是HDFS达到平衡状态的磁盘使用率偏差值。如果节点与节点之间磁盘使用率偏差小于5%，那么我们就认为HDFS集群已经达到了平衡的状态】：
$HADOOP_HOME/bin/start-balancer.sh --t 5%

#方法二：
hdfs balancer -threshold 5

1.5、hadoop集群如何实现扩容？

bash 复制代码

#hadoop集群实现扩容方法
#1-新节点部署hadoop环境【新增节点在系统安装完成后，要进行一系列的操作，比如系统基本优化设置，hadoop环境的部署和安装，jdk的安装等等，这些基础工作需要事先完成】

#2-修改【hdfs-site.xml】文件（namenode上查看/etc/hadoop/conf/hdfs-site.xml文件），找到如下配置（没有则添加上）：
    <property>
        <name>dfs.hosts</name>
        <value>/etc/hadoop/conf/hosts</value>
    </property>

#3-修改【hosts】文件（在namenode上修改/etc/hadoop/conf/hosts文件，添加新增的节点IP或主机名）
vi /etc/hadoop/conf/hosts
192.168.1.130
slave005

#4-将配置同步到所有datanode节点的机器上

#5-让新增的配置生效【新增节点后，要让namenode识别新的节点，需要在namenode上刷新配置】
su - hadoop
hdfs dfsadmin -refreshNodes

#6-在新节点启动datenode服务与nodemanager服务【在namenode上完成配置后，最后还需要在新增节点上启动datanode服务】
hdfs --daemon start datanode
yarn --daemon start nodemanager

这样，一个新的节点就增加到集群中了，hadoop的这种机制可以在不影响现有集群运行的状态下，任意新增或者删除某个节点，非常方便。

1.6、HDFS下有missing blocks怎么解决？

HDFS下有missing blocks这个问题也经常发生，并且会有数据丢失（一旦HDFS集群出现missing blocks错误，那意味着有元数据丢失或者损坏，要恢复的难度很大，或者基本无法恢复）。

bash 复制代码

#解决HDFS下有missing blocks方法
su - hadoop
#1-先扫描这个提示missing block故障的路径（检查HDFS下所有块状态，并给出哪些文件出现了块丢失或损坏）
hdfs fsck /blocks-path/

#2-若这些文件不重要则可以直接删除【如：删除HDFS上mv.log这个文件，因为文件元数据丢失，无法恢复，所以只能删除】
hdfs fsck -fs hdfs://bigdata/logs/mv.log  -delete

二、Hadoop调优之操作系统调优

2.0、Hadoop+HBase混合集群生产硬件规划

约定：CPU 为物理核 ，BIOS 开启超线程；内存为物理 ECC 内存；操作系统固定预留8GB ；数据副本默认 3 副本；Worker 数据盘JBOD 模式，禁止 RAID5/RAID6 ，控制器做单盘 RAID0 等价 JBOD。网卡：双万兆光口 bond，生产禁止千兆；电源双冗余。

✅Hadoop硬件选型核心原则	说明
1、NameNode 内存经验	1GB 内存支撑约 100 万 HDFS Block，小文件多必须加大 NN 内存。
2、Worker 配比	IO 密集业务每物理核 6‑8GB 内存；Spark / 计算密集每物理核 8‑12GB 内存。
3、JVM 堆内存不超过机器物理内存 70%	单进程堆尽量≤32G，避免 JVM 压缩指针失效、GC 停顿恶化。
4、Worker 数据盘优先多块小容量盘，优于少量超大盘	单盘建议 4‑8TB，单 DN 总存储不超过 100TB，磁盘故障后副本重建压力可控。
5、主节点元数据盘必须 SSD+RAID10	系统盘 RAID1；ZK 数据盘建议独立磁盘，规避 fsync 卡顿。

✅磁盘最佳实践（生产避坑）
1. Worker 数据盘必须 JBOD，禁止 RAID5/6；RAID 控制器无法透传 JBOD 时，每块盘配置独立 RAID0。 2. Master 元数据：SSD RAID10，保障 editlog fsync 性能；系统盘 RAID1。 3. ZK：dataDir 与 dataLogDir 放在两块不同物理磁盘，规避磁盘 IO 抖动导致 ZK 会话超时。 4. 不建议 Worker 单盘 > 8TB；磁盘故障后副本复制时间过长，引发集群抖动。 5. YARN 本地目录（yarn‑nodemanager‑local‑dirs）分散挂载多块物理磁盘，提升 IO 吞吐。

✅磁盘最佳实践（生产避坑）

1. Worker 数据盘必须 JBOD，禁止 RAID5/6；RAID 控制器无法透传 JBOD 时，每块盘配置独立 RAID0。 2. Master 元数据：SSD RAID10，保障 editlog fsync 性能；系统盘 RAID1。 3. ZK：dataDir 与 dataLogDir 放在两块不同物理磁盘，规避磁盘 IO 抖动导致 ZK 会话超时。 4. 不建议 Worker 单盘 > 8TB；磁盘故障后副本复制时间过长，引发集群抖动。 5. YARN 本地目录（yarn‑nodemanager‑local‑dirs）分散挂载多块物理磁盘，提升 IO 吞吐。

✅网络规划生产要求
1. 全部服务器双万兆光口 bond；禁止千兆网卡作为业务数据网卡。 2. 交换机采用 Spine‑Leaf 架构；ToR 交换机至少万兆，Spine 交换机 40G/100G；超额订阅比不高于 1:4，优先 1:1。 3. 集群建议独立业务数据网络，和办公网隔离；开启 Jumbo 帧（MTU=9000）。 4. 机架感知配置：HDFS 副本分散不同机架，避免单机架交换机故障数据丢失。

✅网络规划生产要求

1. 全部服务器双万兆光口 bond；禁止千兆网卡作为业务数据网卡。 2. 交换机采用 Spine‑Leaf 架构；ToR 交换机至少万兆，Spine 交换机 40G/100G；超额订阅比不高于 1:4，优先 1:1。 3. 集群建议独立业务数据网络，和办公网隔离；开启 Jumbo 帧（MTU=9000）。 4. 机架感知配置：HDFS 副本分散不同机架，避免单机架交换机故障数据丢失。

2.0.1、角色硬件规格明细

2.0.1.1、Master 主节点

Master 主节点（HA：Active/Standby NN + RM + JournalNode）；独立部署，不跑 RegionServer、YARN 计算容器；两套规模参考：

ulimit：方案 A

集群规模	CPU物理核	物理内存	磁盘布局	网卡
小型集群≤20 台	16 核	128G	2 块 SSD RAID1（系统 + 日志）；4 块 SSD RAID10（NN 元数据、JN）	双万兆 bond
中型集群 20‑100 台	24 核	256G	2 块 SSD RAID1；4‑6 块 SSD RAID10 元数据盘	双万兆 bond

JVM参考
* NameNode 堆：小型 64G；中型 120G；最大不超过 120G * ResourceManager 堆：4‑8G * JournalNode 堆：4‑8G

2.0.1.2、ZooKeeper 集群

ZooKeeper 集群（必须奇数 3/5 台，独立部署最佳）：

ulimit：方案 B

集群规模	CPU 物理核	内存	磁盘布局	网卡
小型集群 ZK (3 台)	8 核	32G	系统盘 RAID1；独立 1‑2 块 HDD/SSD 存放 ZK dataDir/dataLogDir，分开目录	万兆
中型集群 ZK (5 台)	12 核	64G	系统盘 RAID1；独立磁盘分离数据目录与日志目录	双万兆 bond

ZK 不消耗大量资源，禁止在 ZK 节点跑 RegionServer、大量 YARN 容器；

2.0.1.3、HBase‑Worker 节点

HBase‑Worker 节点（DN+NM+RegionServer，高压力）；运行 RegionServer，大量线程、socket 句柄；

必须使用方案 A ulimit 配置。

业务压力	CPU 物理核	物理内存	磁盘布局	网卡
中等压力 HBase	24 核	256G	2 块 SSD RAID1 系统盘；12‑16 块 4‑8TB SATA HDD JBOD；可配少量 SSD 做 HBase 缓存	双万兆 bond
高吞吐在线 HBase	32 核	384‑512G	2 块 SSD RAID1 系统盘；16‑24 块 4‑8TB SATA HDD JBOD	双万兆 bond

内存拆分示例（32 核 384G）
* OS 预留：8G * DataNode 堆：4G * NodeManager 堆：4G * RegionServer 堆：28G（G1GC，尽量不要超过 32G） * YARN 可分配内存：`yarn.nodemanager.resource.memory‑mb=340992` * CPU 预留 4 核系统进程；`yarn.nodemanager.resource.cpu‑vcores=28`

2.0.1.4、普通 Worker 节点

使用方案 B limits，不使用高 nproc 配额。

业务场景	CPU 物理核	内存	磁盘布局	网卡
IO‑Hive 离线为主	16 核	64‑128G	2 块 SSD RAID1 系统盘；12‑16 块 4‑8TB HDD JBOD	万兆 bond
Spark 计算密集	24 核	192‑256G	2 块 SSD RAID1 系统盘；12‑20 块 4‑8TB HDD JBOD	双万兆 bond

24 核 192G 示例：OS 预留 8G，DN4G，NM4G，YARN 可用内存yarn.nodemanager.resource.memory‑mb=180224，vcores=20。

2.0.1.5、Gateway 边缘网关节点

Gateway 边缘网关节点（仅客户端，不存储数据）；部署 Hive、Spark 客户端、调度组件 Oozie/Hue，不部署 DN、RS。

ulimit：方案 B

CPU 物理核	内存	磁盘布局	网卡
8‑16 物理核	32‑64G	2 块 SSD RAID1 系统盘；不需要大量数据盘	万兆

2.0.2、Hadoop集群硬件清单

2.0.2.1、小型 Hadoop+HBase 集群（总节点 11 台）

业务：HDFS 块 < 300 万；HBase QPS 几千；Hive/Spark 中等离线任务。

分组	台数	角色	硬件规格	ulimit 方案
Master	2	NN‑HA、RM‑HA	16 核，128G；SSD 元数据 RAID10	A
ZK	3	ZooKeeper 集群	8 核，32G；独立 ZK 磁盘	B
HBase‑Worker	4	DN+NM+RegionServer、JournalNode	24 核，256G；12×6TB JBOD	A
Gateway	2	客户端、调度服务	8 核，32G	B

2.0.2.2、中型 Hadoop+HBase 集群（总节点 21 台，生产主流）

业务：HDFS 块 300‑1000 万；HBase 在线 QPS 上万；大量 Spark/Hive 任务。

分组	台数	角色	硬件规格	ulimit 方案
Master	2	NN‑HA、RM‑HA	24 核，256G；SSD 元数据 RAID10	A
ZK	5	ZooKeeper 集群	12 核，64G；ZK 数据日志分离磁盘	B
HBase‑Worker	8	DN+NM+RegionServer、JournalNode	32 核，384G；16×8TB JBOD	A
Normal‑Worker	4	DN+NM，无 RegionServer	24 核，192G；16×8TB JBOD	B
Gateway	2	客户端、调度服务	16 核，64G	B

2.0.3、硬件与内核参数对应关系

硬件与内核参数对应关系
`fs.nr_open=1048576`、`kernel.pid_max=4194304`：全集群所有节点统一配置，不需要差异化。
`fs.file‑max`差异化： * Master/HBase‑Worker（≥128G 内存）：`fs.file‑max=2097152` * Normal‑Worker 16G：262144；64G：1048576 * ZK/Gateway：262144

2.0.4、上线前硬件 & 系统校验清单

上线前硬件 & 系统校验清单

上线前硬件 & 系统校验清单
1. BIOS 开启超线程，开启 ECC 内存；服务器双电源。 2. 磁盘确认 Worker 数据盘 JBOD；Master 元数据 SSD‑RAID10；ZK 数据日志分盘。 3. bond 网卡正常，MTU9000，机架感知配置完成。 4. 全部节点推送 limits.conf、limits.d、sysctl.conf、systemd/system.conf；执行`sysctl -p ; systemctl daemon‑reexec`。 5. 检查`/etc/pam.d/login`存在`session required pam_limits.so`，sshd_config `UsePAM yes`。 6. 全部配置推送完成后滚动重启 Hadoop、HBase、ZK 服务；已运行进程不会自动加载新资源限制。 7. 校验标准：以`cat /proc/<pid>/limits`真实进程限制为准，不要只看 shell `ulimit -a`。

1. BIOS 开启超线程，开启 ECC 内存；服务器双电源。 2. 磁盘确认 Worker 数据盘 JBOD；Master 元数据 SSD‑RAID10；ZK 数据日志分盘。 3. bond 网卡正常，MTU9000，机架感知配置完成。 4. 全部节点推送 limits.conf、limits.d、sysctl.conf、systemd/system.conf；执行sysctl -p ; systemctl daemon‑reexec。 5. 检查/etc/pam.d/login存在session required pam_limits.so，sshd_config UsePAM yes。 6. 全部配置推送完成后滚动重启 Hadoop、HBase、ZK 服务；已运行进程不会自动加载新资源限制。 7. 校验标准：以cat /proc/<pid>/limits真实进程限制为准，不要只看 shell ulimit -a。

2.0.5、操作系统优化方案

2.0.5.1、ulimit 方案A

bash 复制代码

#ulimit 方案A
#1-【/etc/security/limits.conf】配置
*       soft    nofile          131072
*       hard    nofile          262144
*       soft    nproc           131072
*       hard    nproc           131072
root    soft    nproc           unlimited
root    hard    nproc           unlimited


#2-【/etc/security/limits.d/90‑nproc.conf】
*          soft    nproc     131072
root       soft    nproc     unlimited

#3-【/etc/sysctl.conf】
fs.file-max = 2097152
fs.nr_open = 1048576
kernel.pid_max = 4194304

#4-【/etc/systemd/system.conf】
DefaultLimitNOFILE=131072:262144
DefaultLimitNPROC=131072

#5-配置生效
sysctl -p 
systemctl daemon-reexec

2.0.5.1、ulimit 方案B

bash 复制代码

#ulimit 方案B
#1-【/etc/security/limits.conf】配置
*       soft    nofile          65536
*       hard    nofile          131072
*       soft    nproc           65536
*       hard    nproc           65536
root    soft    nproc           unlimited
root    hard    nproc           unlimited

#2-【/etc/security/limits.d/90‑nproc.conf】
*          soft    nproc     65536
root       soft    nproc     unlimited

#3-【/etc/sysctl.conf】
fs.file-max = 262144
fs.nr_open = 1048576
kernel.pid_max = 4194304

#4-【/etc/systemd/system.conf】
DefaultLimitNOFILE=65536:131072
DefaultLimitNPROC=65536

#5-配置生效
sysctl -p 
systemctl daemon-reexec

2.1、调整操作系统打开文件描述符的上限

bash 复制代码

#调整操作系统打开文件描述符的上限
#1-通过命令【ulimit -a】可以看到所有系统资源参数，这里面需要重点设置的是【open files】和【max user processes】，其它可以酌情设置。
ulimit -a

#2-永久设置资源参数【HBase+Hadoop 高压力集群】
vi /etc/security/limits.conf 
*       soft    nofile          131072
*       hard    nofile          262144
*       soft    nproc       	131072
*       hard    nproc       	131072
root	soft	nproc		unlimited
root	hard	nproc		unlimited

#2.1-配置资源限制
vi /etc/sysctl.conf
#整机所有进程全局句柄上限（fs.file‑max ≈ 内存 MB × 10【如：8g内存=8x1024MBx10=81920】可在这个基础上放大 1.5‑2 倍）
fs.file-max = 163840
#单个进程允许打开文件句柄的内核硬上限，用户态 limits.conf 的 hard nofile 不能超过该值
fs.nr_open = 1048576
#系统 PID 编号池的最大值，系统可用 PID 编号从 1 ~ kernel.pid_max，不是限制线程、进程数量，只是 PID 数字上限。
kernel.pid_max = 4194304

2.2、修改net.core.somaxconn参数

net.core.somaxconn内核参数对应的具体文件路径为【/proc/sys/net/core/somaxconn】，它用来设置socket监听（listen）的backlog上限（backlog就是socket的监听队列，当一个请求（request）尚未被处理或建立时，他会进入backlog。而socket server可以一次性处理backlog中的所有请求，处理后的请求不再位于监听队列中。如何server处理请求较慢，以至于监听队列被填满时，新来的请求会被拒绝。所以必须增大这个值，此参数默认值为128）。

somaxconn 太小典型表现
1. HBase 客户端随机报 `Connection refused`，不是必现，压力上来才出现。 2. HDFS RPC 偶尔超时，日志看到连接建立失败。 3. ZK 客户端偶尔断开重连。 4. netstat/ss 看到大量 SYN_RECV 状态连接。 #查看syn_recv数量，如果持续很高说明backlog队列溢出 ss -s

bash 复制代码

#/proc/sys/net/core/somaxconn 参数调优
#【不建议无脑调到 65535，过大没有收益，浪费内核资源】【不要保留默认 128，高并发 RPC 场景 backlog 队列打满，随机出现连接失败】
#1-全集群所有节点统一配置为4096（Master、HBase‑Worker、普通 Worker、ZK、Gateway 全部节点）
echo 4096 >/proc/sys/net/core/somaxconn
#1.1-HBase 高吞吐在线集群（上万 QPS）：设置 8192
echo 8192 >/proc/sys/net/core/somaxconn


#2-完整的配套相关网络参数（全集群统一配置）
vi /etc/sysctl.conf
#文件句柄/PID，全集群统一
fs.nr_open = 1048576
kernel.pid_max = 4194304

#TCP backlog
net.core.somaxconn = 4096

#socket缓冲区全局上限【单位：字节；16777216 = 16MB】
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

#TCP缓冲区 min default max【单位：字节；16777216 = 16MB】
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

#网络抗攻击、time‑wait复用
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1

#2.1-让修改的【/etc/sysctl.conf】配置生效
sysctl -p


#3-somaxconn 只是操作系统上限，Java 服务自身 backlog 不能小于 somaxconn，否则 somaxconn 设置再大也不生效
#HDFS NameNode、DataNode、HBase RegionServer 的 RPC 服务 backlog，Hadoop 默认一般是 50 或者 128。
#需要修改 hadoop‑site.xml/hbase‑site.xml 参数放大服务端 backlog（原则【ipc.server.listen.queue.size ≤ net.core.somaxconn；建议两者配置相等】）：
vi hadoop‑site.xml
    <property>
        <name>ipc.server.listen.queue.size</name>
        <value>4096</value>
    </property>

vi hbase‑site.xml
    <property>
        <name>hbase.ipc.server.listen.queue.size</name>
        <value>4096</value>
    </property>

2.3、调整操作系统使用swap的比例

swap本意是作为物理内存的扩展来使用的，但是在内存充足的今天，使用swap的场景越来越少，主要是使用swap会极大降低应用性能，在hadoop中，如果数据交换到swap，会导致操作超时，非常影响hadoop的读写以及数据分析性能。

bash 复制代码

#可以通过系统内核参数【/proc/sys/vm/swappiness】来调整使用swap的比例
#1-最大限度使用物理内存，然后才是swap空间
swappiness=0

#2-【linux的swap基本默认设置为60】物理内存在使用到100-60=40%的时候，就开始出现有交换分区的使用
#【此值在一些对内存需求高的服务器上，需要设置的足够小（比如hadoop、redis、hbase机器上，应该设置0-10之间（如：5），表示最大限度使用物理内存）】
swappiness=60

#3-积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面
swappiness＝100

#4-查看系统当前的swap比例
cat /proc/sys/vm/swappiness

#5-设置swap的值
echo 5 >/proc/sys/vm/swappiness

2.4、禁用THP(Transparent Huge Pages)功能

THP的本意是为提升内存的性能，但是在hadoop环境中发现，此功能会带来CPU占用率增大，影响hadoop性能，因此建议将其关闭。

bash 复制代码

#禁用THP(Transparent Huge Pages)功能
#1-检查THP的启用状态情况【必须看到中括号落在 never 上才算真正关闭】
cat /sys/kernel/mm/transparent_hugepage/defrag
cat /sys/kernel/mm/transparent_hugepage/enabled



#2-禁用THP功能方法【修改 GRUB 内核参数（生产推荐，永久生效，重启依旧有效）】
#2.1-红帽系版本7（RHEL7/CentOS7等）
vi /etc/default/grub

#2.1.1-修改 GRUB_CMDLINE_LINUX，增加两个参数：transparent_hugepage=never transparent_hugepage.defrag=never
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet transparent_hugepage=never transparent_hugepage.defrag=never"

#2.1.2-重新生成 grub 配置
#BIOS 传统启动机器
grub2-mkconfig -o /boot/grub2/grub.cfg
#UEFI 启动机器
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

#2.1.3-重启服务器让修改生效
reboot


#2.2-红帽系版本8及其更高版本（RHEL8+/CentOS8+等）
vi /etc/default/grub

#2.2.1-修改 GRUB_CMDLINE_LINUX，增加两个参数：transparent_hugepage=never transparent_hugepage.defrag=never
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet transparent_hugepage=never transparent_hugepage.defrag=never"

#2.2.2-重新生成 grub 配置
#BIOS 传统启动机器
grub2‑mkconfig -o /boot/grub2/grub.cfg
#UEFI 启动机器
grub2‑mkconfig -o /boot/efi/EFI/redhat/grub.cfg

#2.2.3-重启服务器让修改生效
reboot

三、大数据平台网络规划、硬件存储选型

3.1、hadoop基础网络架构

hadoop基础网络架构
1、hadoop集群使用三个机架、主备服务分别在不同的机架上
2、所有机架上层对应的是两个100GE的核心交换机，一主一备模式都接入到各个机架上的接入交换机上【或者可直接使用堆叠交换机】
3、单个机架最上两层使用10GE的的接入交换机，一主一备模式【或者可直接使用堆叠交换机】

3.2、大数据平台硬件选型

在一个典型Hadoop架构中，通常有5个角色，分别是【NameNode(和Standby NameNode)】、【ResourceManager】、【NodeManager】、【DataNode】以及【外围机】。

典型Hadoop架构中的5个角色	说明
1、【NameNode(和Standby NameNode)】	NameNode负责协调集群上的数据存储（Standby NameNode属于NameNode的热备份）属于【管理角色】需要部署在独立的服务器上
2、【ResourceManager】	ResourceManager则是负责协调计算分析属于【管理角色】需要部署在独立的服务器上
3、【NodeManager】	用于计算【为了获得更好的性能，通常将NodeManager和DataNode部署在一起】
4、【DataNode】	用于存储【为了获得更好的性能，通常将NodeManager和DataNode部署在一起】
5、【外围机】	供开发使用

【管理角色】（NameNode、ResourceManager及其Standby NameNode）节点选择统一的硬件配置；基础配置推荐如下：
1、CPU：推荐2路8核、2路10核或2路12核等，主频至少2-2.5GHz
2、内存：推荐64-256GB（取决于namenode的元数据情况，元数据多就需要配置大一些）
3、磁盘：分为2组，系统盘和数据盘，系统盘2T*2，做raid1；数据盘2-4T左右，也做raid1，数据盘的数量取决于你想冗余备份元数据的份数【一般建议使用4块、分别做2个raid1实现多路径、多镜像】。
4、网卡：万兆网卡（光纤卡）
5、电源：均配置冗余电源

【用于计算与存储】（NodeManager、DataNode）节点选择统一的硬件配置（对硬件要求较高）；基础配置推荐如下：
1、CPU：推荐2路10核、2路12核或2路14核等，主频至少2-2.5GHz
2、内存：推荐64-512GB（越大越好）
3、磁盘：分为2组，系统盘和数据盘，系统盘2T*2，做raid1；数据盘4-8T左右，数据盘单盘使用，无需做raid。磁盘是瓶颈
4、网卡：万兆网卡（光纤卡），存储越多，网络吞吐就要求越高。
5、电源：最好配置冗余电源，如预算不足，也可使用单电源。

3.3、典型大数据平台拓扑

在构建大数据平台之前，首先要考虑需要的存储容量、计算能力、是否有实时分析的需求、数据的存储周期等，然后再根据这些需求进行平台的架构设计。

同时，还要考虑平台的健壮性：

例如任意一个节点宕机都不会影响平台的正常使用；
任何一个磁盘的损坏都不会导致数据丢失等。