HDFS特性之DN选盘策略与自动摘盘(二)

云存储
, , ,

上一篇已经讲述了在HDFS3中, Datanode是如何操作磁盘的, 这一篇主要是实践篇, 说一下实际生产中遇到的一些和磁盘相关的问题, 之前的内容就是铺垫, 不再重复

0x00. Linux的预留空间

背景说明: 在Linux常用的文件系统ext*中, 通常会对格式化后的盘设置默认5%的保留空间(Reserve Space), 这部分空间不可被普通用户/进程使用.

上一篇DN写磁盘提到有一个重要的参数设置DN写盘预留的空间, 而它恰恰会被Linux-FS默认的预留影响. 从而留下隐患

1. 确认Linux磁盘的预留空间

Linux一般常见df -h 的几个磁盘参数(总大小, 已用, 可用), 后续DN的预留计算中会使用:

1
2
3
4
Filesystem      Size  Used  Avail  Use   Mounted on
/dev/sda        400G  2.9G  398G    1%     /data00

# 一般情况下 Size ≈ Used + Avail, 但是这样并不准确, 少算了磁盘的"预留空间"

首先我们就得看看自己机器上的磁盘到底预留了多少空间, 如何确认和修改呢? 在ext*常用tune2fs, 当然也可以用dumpe2fs或其他类似命令:

1
2
3
4
5
6
7
8
9
10
# 查看当前磁盘的预留信息(一块8T的HDD盘格式化后)
tune2fs -l /dev/sda
# 重点关注以下两行输出, 就能得出具体保留空间占比了(下为1%)
Block count:              1953506646
Reserved block count:     19535066
# 那么8T的HDD保留空间占据的实际大小就是blockCount * blockSize(4K) 
19535066 * 4 / 1024² = 74G

# 修改磁盘的预留空间占比为0.5% (修改范围0~50)
tune2fs -m 0.5 /dev/sda

一块标称4T的磁盘, 格式化后实际大小约为3.7T, 如果不去修改它的预留空间占比(5%), 默认情况下, 它会占据接近200G的空间(不可使用), 对比修改预留比为1%, 它只占据40G不到的空间. 你可以从df -h 看到实际的效果对比:

diskReserver00

同样大小的磁盘, 第一行sda2是默认的**5%预留**, 其他都设置为了1% , 那么同样已用占比99%时, 其他盘就比它多出约150G, 如果是8T的单盘, 那么这个默认预留空间就会更大, 从而严重影响到我们DN的预留配置. 下面接着看看.

0x01. Datanode的预留空间

0. 名词解释

DN对磁盘的预留空间, 有两个重要的参数, 简单说明一下:

  • dfs.datanode.du.reserved: 这是为非HDFS(Linux自身)设置的预留空间字节数, 固定值.(默认值0)
  • dfs.datanode.du.reserved.pct: 预留空间百分比(pct), 也就是说一块磁盘百分之X%的空间是不能被使用的 (默认值0)

再说说几个后面可能混淆的名词解释:

  • HDFS的可用空间, 这里指的是当且DN节点还能写多大的HDFS副本块 (严谨说应该是Volume可用空间)
  • HDFS已用空间, 是指当前DN的HDFS副本块总大小 (严谨说应该是Volume已用空间)
  • HDFS保留空间, 是指当前DN留给Linux的空间 (严谨说应是DN预留空间)

之所以这里同一个概念有多种叫法, 是因为在代码中, 官方就是这样命名的(dfsUsed), 但是这个说法并不严谨, 但严谨的说法并不易懂, 所以我把对应关系先说明一下, 如果大家有想到更好的表述方式欢迎留言.

先说下结论: DN页面上显示的两个关键参数是最直观的, 如果你只关心当前盘还有多少空间HDFS可用, 那Capacity Left就是准确答案, 他也是后面我画的图里的Volume可用空间

dnReserveSpace01

1. 如何计算可用空间

我尽力用图来表示这个计算方式, 但是仍可能需要自己动手实践一下, 图如果有更好的画法欢迎随时修改, (以单盘格式化前4T为例):

dnReserveSpace00

  • Volume总空间 = Linux磁盘空间 – 非HDFS使用空间 (DN保留空间随其它两块增大而降低, 超过设定值则直接失效)
  • Volume可用空间 = Volume总空间 – Volume已用空间 – RWB保留空间

由上可得: Volume可用空间 = Linux磁盘空间 – 非HDFS使用空间 - Volume已用空间 – RWB保留空间

如果这个图看的还不是很清晰, 可以再看看代码的细节:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
final long usedSpace; // HDFS(DN)使用的空间
final long freeSpace; // 除开保留空间外的"可用空间"
final long reservedSpace; // 为Linux系统(non-HDFS)预留的空间
final long reservedSpaceForReplicas; // 为RBW或re-replication预留的空间


/* 计算当前DN可用空间的函数(关键)
 * 1. HDFS使用空间, 就是指当前DN存储占用
 * 2. 非HDFS使用空间: 磁盘卷上除开HDFS外的其他使用
 * 3. Linux磁盘总/剩余空间, 比如`df -h`显示的总/剩余空间
 * 4. RBW预留空间可不考虑, 算为0
 * 补充: 建议在这里加个日志确认各参数值..
 ######################Divide Line#####################
 * 举几个例子: (假设HDFS设置50G预留空间, 1T按1000G算, 来算下此时HDFS还能否写入此盘)
 * 1.磁盘总空间3.6T, 磁盘已用空间3.4T, 磁盘可用空间51G, HDFS使用3.3T/3.4T:
 *  - remaining = (3.6T - 50G) - 3.3T/3.4T = 250G/150G
 *  - avail = 51G - 0/0 = 51G
 *  此时两种情况HDFS仍然可写入51G的空间, 也就是说可把磁盘完全写满, HDFS设置的预留空间不生效
 * 
 * 2. 磁盘总空间3.6T, 磁盘已用空间3.55T, 磁盘可用空间51G, HDFS使用3.45T/3.55T:
 *  - remaining = (3.6T - 50G) - 3.45T/3.55T = 100G/0G
 *  - avail = 51G - 0G/50G = 51G/1G
 *  如果Linux自身使用100G, 那么HDFS此时可写入全部数据, 预留配置不生效
 *  如果磁盘空间全是HDFS使用, 那么此时只能写入1G的数据, 预留配置会完全生效.
 */
  @Override
  public long getAvailable() {
    // 1. HDFS理论剩余最大空间 = HDFS理论最大容量 - HDFS实际使用 - RBW预留空间
    long remaining = getCapacity() - getDfsUsed() - getReservedForReplicas();
    // 2. HDFS实际可用 = 磁盘卷实际可用空间 - HDFS实际预留大小 - RBW预留空间
    long available = usage.getAvailable()  - getRemainingReserved() - getReservedForReplicas();
    
    if (remaining > available) remaining = available; 
    
    return (remaining > 0) ? remaining : 0;
  }

  public long getCapacity() {
    if (configuredCapacity < 0) { // 初始值-1
      // HDFS理论最大可用空间 = 磁盘卷总大小 - 配置的预留空间 (比如50G)
      long remaining = usage.getCapacity() - getReserved();
      return remaining > 0 ? remaining : 0; // 这个值一般不会小于0
    }
    return configuredCapacity;
  }

  // 此方法的意思是, HDFS保留空间仅在磁盘没有非HDFS进程使用时才能完全生效
  // 如果在本地存储目录下放一个普通文件, 占据的空间会从HDFS预留空间中去掉
  // 也就是说, 如果在/data00/block/下放超过预留配置大小的文件, 则预留配置等同于0
  private long getRemainingReserved() {
    // 磁盘非HDFS部分占用 = (磁盘总大小 - 磁盘可用) - HDFS使用
    long actualNonDfsUsed = usage.getUsed() - getDfsUsed();
    long actualReserved = getReserved(); // 配置的预留空间(比如50G)
    // 如果磁盘非HDFS使用 < 预留配置, 返回二者差
    if (actualNonDfsUsed < actualReserved) {
      return actualReserved - actualNonDfsUsed;
    }
    return 0L; // 如果磁盘非HDFS使用大于预留, 直接返回0?
  }

  // 如果剩余空间小于写入/追加写空间, 抛出DiskOutOfSpaceException

2. Linux磁盘预留对HDFS的影响

上面的介绍说完了, 那这个Linux-FS的预留策略和HDFS的预留空间有什么关系呢? 主要有两个方面影响

A. DN

第一个方面是可能会导致HDFS预留配置失效, 比如:

  1. HDFS的预留空间设置为每个盘50G
  2. 一块8T的HDD格式化后显示7.3T, 哪怕只设置1%的预留, 也占据74G
  3. HDFS无法感知这部分预留空间, 它会认为这部分空间是用户自己占有(非HDFS使用)
  4. 然后根据计算逻辑, 这部分空间会与配置的预留(非HDFS)空间抵消掉, 最多抵消50G
  5. 所以74G的保留空间, 就会导致HDFS的预留配置永远失效, 后果是HDFS会尝试把磁盘写满直到只剩一个block.
  6. 从而可能导致各种隐患出现.

第二个影响是造成存储浪费, 当存在异构的存储时候, 目前无法给不同存储设备单独设置预留, 一个DN只能设定一个公用值:

  1. 一块8T的HDD, 按照上面的结论, 我们在把磁盘预留设置为1%时, HDFS的预留空间需要设置至少74G以上, 比如设置100G
  2. 一块300G的SSD, 预留空间也是100G, 那它的使用空间就少了1/3, 造成不必要的浪费
  3. 如果是一个内存盘(RAM), 可能总共大小就50G, 那么此时预留设置同样也会失效, 或大比例的浪费.

对于问题1, 会有一个很自然的问题, 既然这个磁盘预留空间容易给HDFS埋下一个大坑

为什么不直接调低或关了(设置为0%)呢? 不同情况需要不同对待:

  • 对于HDD(机械盘)来说, ext类文件系统预留5%空间是有避免磁盘碎片化的考虑的 (SSD不能一概而论)
  • 对于Linux系统盘来说, 预留空间保证在磁盘写满时, 还能正常使用必要的命令
  • 对于数据盘, 特别是冷数据(归档)盘来说, 你可以考虑设置这个保留比为1%, 甚至是0%. (参考Redhat内核开发者的回复)

对于问题2, 可以考虑开发不同类型的存储, 使用不同的预留大小. (feature)

0x02. 测试

1. 结果

这里主要是对写盘异常的各种情况做一个实际测试验证, 下面的磁盘空间严谨说是目录卷(Volume)

测试前提 测试项目 结果 备注
磁盘空间已满, 不能再写入 DN是否可读 可读
磁盘空间已满, 不能再写入 DN是否可写 不可写 选盘时就不会选
磁盘空间已满, 不能再写入 磁盘是否会被摘掉 不会 V3.1.2
DN写入时, 其他进程写满磁盘 磁盘是否会被摘掉 不会 会换盘写
磁盘不具有写权限 (提前) DN能否正常启动 可以^*^ DN自己加了权限, 存疑
磁盘不具有写权限 (提前) DN是否可以写入 不可写 但不会触发检查 / 摘盘
磁盘不具有写权限 (任意时间) DN是否可以读取 可读
磁盘不具有写权限 (突然) 磁盘是否会被摘掉 会 详见后面说明
配置多种磁盘类型(异构) 是否影响上述测试结果 不会 目前测试未发现
DN正常启动后 是否会定期检查所有磁盘 未发现^*^ 需要确认代码, 测试没触发

TODO: 待补充读权限相关测试, 存疑栏目后续需要跟进

2. 日志细节

这是上面截取的测试细节, 主要是通过日志来trace, 可供参考

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# Casse1: 写数据时候, 设置为100
chmod 100 -R /data01/block

# 如果是在读写数据之前, 那么都会直接失败, DN不会进入读写盘错误检查的部分, 所以不会触发摘盘

# 如果在写数据的时候, 突然取消某个磁盘的读写权限会Client出现以下提示
23:28:41,015 INFO hdfs.DataStreamer: Exception in createBlockOutputStream blk_1073743016_2233
java.io.EOFException: Unexpected EOF while trying to read response from server
    at org.apache.hadoop.hdfs.protocolPB.PBHelperClient.vintPrefixed(PBHelperClient.java:549)
    at org.apache.hadoop.hdfs.DataStreamer.createBlockOutputStream(DataStreamer.java:1762)
    at org.apache.hadoop.hdfs.DataStreamer.nextBlockOutputStream(DataStreamer.java:1679)
    at org.apache.hadoop.hdfs.DataStreamer.run(DataStreamer.java:716)
23:28:41,243 WARN hdfs.DataStreamer: Abandoning BP-1860588468-10.172.195.33-1572260690191:blk_1073743016_2233
23:28:41,265 WARN hdfs.DataStreamer: Excluding datanode DatanodeInfoWithStorage[10.172.195.33:9866,DS-c129f737-341c-4207-822b-c4328bfb585d,DISK]

# 对应DN的日志, 随后DN进程退出
23:28:41,089 WARN DatasetVolumeChecker: Exception running disk checks against volume /data00/block
DiskChecker$DiskErrorException: Directory is not readable # 异步检查读权限不满足
23:28:41,090 WARN DataNode: checkDiskErrorAsync callback got 1 failed volumes: [/data00/block]
23:28:41,301 INFO FsDatasetImpl: Removed volume: /data00/block
23:28:41,302 INFO FsDatasetImpl: Volume reference is released.
23:28:41,302 INFO DataNode: Deactivating volumes (clear failure=false): [DISK]file:/data00/block
23:28:41,302 INFO FsDatasetImpl: Checking removing StorageLocation [DISK]file:/data00/block 
23:28:41,302 INFO FsDatasetImpl: Removing StorageLocation [DISK]file:/data00/block
23:28:41,322 INFO Storage: Removing block level storage: /data00/block/current/BP-1860588468-10.172.195.33-1572260690191
23:28:41,322 WARN DataNode.handleDiskError on: [DataNode failed volumes:[DISK]file:/data00/block;] Keep Running: false
23:28:41,328 WARN DataNode is shutting down due to failed volumes: [DataNode failed volumes:[DISK]file:/data00/block;]

# Case2: 尝试设置为近似只读 (执行权限必须有, 否则无法读写)
chmod 500 -R /data01/block
# 如果是没写文件之前就设置了, 那么创建pipeline就会失败, DN只会提示没有足够权限, 不会进入磁盘检查逻辑
# 所以这种情况, 并不会把只读的盘摘去

# 如果是写文件中间, 突然把写权限去掉, 客户端提示EOF
23:46:41,104 WARN hdfs.DataStreamer: Exception for BP-1860588468-10.172.195.33-1572260690191:blk_1073743070_2287
java.io.EOFException: Unexpected EOF while trying to read response from server
    at org.apache.hadoop.hdfs.protocolPB.PBHelperClient.vintPrefixed(PBHelperClient.java:549)
    at org.apache.hadoop.hdfs.protocol.datatransfer.PipelineAck.readFields(PipelineAck.java:226)
    at org.apache.hadoop.hdfs.DataStreamer$ResponseProcessor.run(DataStreamer.java:1086)
23:46:41,108 WARN hdfs.DataStreamer: Error Recovery for blk_1073743070_2287 in pipeline [DatanodeInfoWithStorage[10.172.195.33:,DISK]]: datanode 0(DatanodeInfoWithStorage[10.172.195.33:9866,DDISK]) is bad.
23:46:41,162 INFO hdfs.DataStreamer: Exception in createBlockOutputStream blk_1073743071_2289
java.io.EOFException: Unexpected EOF while trying to read response from server
    at org.apache.hadoop.hdfs.protocolPB.PBHelperClient.vintPrefixed(PBHelperClient.java:549)
    at org.apache.hadoop.hdfs.DataStreamer.createBlockOutputStream(DataStreamer.java:1762)
    at org.apache.hadoop.hdfs.DataStreamer.nextBlockOutputStream(DataStreamer.java:1679)
    at org.apache.hadoop.hdfs.DataStreamer.run(DataStreamer.java:716)
23:46:41,163 WARN hdfs.DataStreamer: Abandoning BP-1860588468-10.172.195.33-1572260690191:blk_1073743071_2289
23:46:41,168 WARN hdfs.DataStreamer: Excluding datanode DatanodeInfoWithStorage[10.172.195.33:9866,DS-c129f737-341c-4207-822b-c4328bfb585d,DISK]

# 此时DN会触发检查机制, 踢掉此盘. 其他流程同case1的剔除过程
23:56:18,052 WARN DatasetVolumeChecker: Exception running disk checks against volume /data00/block
org.apache.hadoop.util.DiskChecker$DiskErrorException: Directory is not writable # 提示写权限缺乏

3. 测试细节 (略)

测试环境:

  • HDFS3.1.2
  • 选取一块4T的HDD磁盘: /dev/sda2 1.6T 1.6T 58G 97% /data00 (1%的保留空间)
  • 另一块内存盘, 15G (tmpfs 15G 16K 15G 1% /data01)
  • 单盘测试有个问题是, NN端也有最小总存储检查(默认100M). 最好还是两个盘. 避免出现这个问题
  • 通过的fallocate生成看起来是空字节的大文件.
Directory StorageType Capacity Used Capacity Left Capacity Reserved Reserved Space for Replicas Blocks
/data00/block DISK 4.72 GB 57.16 GB 5 GB 0 B 603
/data01/block SSD 12 KB 10 GB 5 GB 0 B 0

上面是初始的情况, 这里是一些测试环境和实际操作的记录, 仅供参考. (包括预留空间的测试)

1
2
3
4
5
6
7
8
9
# 1. 设置预留空间占比50%, 以方便观察测试
sudo tune2fs -m 50 /dev/sdb
# 检查确认生效
Block count:              976754646
Reserved block count:     488377323
 
# 2. 极速生成测试文件, 几乎占满当前空间 (推荐代替dd)
fallocate -l 1750G bigFile
fallocate -l 150M testFile

0x03. 遗留问题

1. DN在摘盘之后, 会把当前目录卷对应的块移除掉, 什么时候汇报NN?

是在最后一步 –> 告知NN哪些盘坏之后, 如果没有达到坏盘阈值, 就做一次单独的全量块汇报, 如果达到就直接关闭DN

dnRemoveDisk00

2. DN正在写磁盘时, 如果用命令移除对应目录的写权限, 写会失败么?

背景是, DN进程已经提前持有了文件句柄, 那么通过chmod去修改, 写的过程中应该不会去判断权限才对? 为什么会提示权限不足呢

实际测试来看应该是, 当前block写的时候是不会触发的, 但是写完准备把RBW块转为Finalized时候提示权限不足, 从而触发异常导致摘盘

1
2
3
4
5
6
7
8
9
10
11
12
# 这里可以看到已经写完了一个block的大小, 1280MB (我调大方便测试)
17:18:11,465 DEBUG DataNode: Receiving one packet for block BP-1860588468-10.172.195.33-1572260690191:blk_1073743485_2707: PacketHeader with packetLen=4 header data: offsetInBlock: 1342177280
seqno: 20807
lastPacketInBlock: true

# 然后move meta file抛出异常
17:18:11,473 WARN DataNode: IOException in BlockReceiver.run():
java.io.IOException: Failed to move meta file for ReplicaBeingWritten, blk_1073743485_2707, RBW
# 提示RBW的meta文件无法move到finalized
Caused by: java.io.IOException: Failed to move block file for ReplicaBeingWritten, blk_1073743485_2707, RBWfrom file:/data01/block/xxx/current/rbw/blk_1073743485_2707.meta
to
/data01/block/current/xx/finalized/blk_1073743485_2707.meta

3. 写磁盘是否会超时, 卡死的情况, 它会怎么做?

目前我也只看到记录一下超时后, 写盘慢的日志, 还没看到其他处理… (待确定)

4. 为什么磁盘检查有异步和同步两个方法, 但是感觉效果相似?

其实这是有个历史背景的, HDFS2.9之前, DN启动的时候, 磁盘检查是串行一个个去查的, 这样一台DN的盘比较多或卡在某个盘的时候启动就会很慢, 然后社区做了一系列的改进, 最主要的就是引入了一个异步框架实现并发检查盘, 很大提高了启动效率

但是初读代码的时候可能有点奇怪, 这个异步的框架外面是一个注释是同步的checkDiskError()磁盘检查方法, 如果不进去细看, 误以为磁盘检查也然是串行的, 实际这里的意思是说:

检查所有磁盘的过程可以并发去执行, 但是方法后续的处理(比如是否关DN), 都需要待磁盘检查结束才能继续执行, 所以整个大方法是同步的, 但是磁盘检查(第一步)其实是并发的, 并不矛盾. 也可以总结为 –> “整体同步, 局部异步”,

5. 如果在DN启动之前, 把目录读取权限去掉, DN为何还能正常启动?

测试时发现, DN在启动做磁盘检查之前, 自动把文件的权限恢复到了700, 所以磁盘检查可以正常通过.

但是目前没看到这是在DN的什么启动步骤做的? 比较奇怪.. (此结论不一定靠谱, 需要注意父目录的权限)

6. Namenode相关的异构选盘策略

NN这块选盘内容在单独的NN选盘笔记中细说, 简单说NN的确也有简单的选盘逻辑.

参考资料:

  1. Linux EXT* Space Reserve
  2. why need reserve space for root on FileSystem