tongsiying

阅读|运动|自律

0%

BlockStorage-question

发表于 更新于 分类于
本文字数： 9.4k 阅读时长 ≈ 9 分钟

# 001-io错误日志打印 
1
2
3
4
5
gatewayRead  error
gatewayWrite  error

tgtd报错：
snbs crital:

002-issci延时放大

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
两个卷比一个卷平均时延多了1ms，四个卷比一个时延多了4ms。
前端指tgt之前的io栈

问题所在：
issci客户端所在的计算节点存在大量iptable的rule会导致该问题
iptables -nL|wc -l 
发现iptable中的rule有数万条之多，且绝大多数是垃圾，清理垃圾之后，性能测试正常，包括iscsi本地大块写时延放大、多个卷随机写时延放大等问题。

为何虚机会残留这么多rule？
应该是业务虚机迁移导致，业务虚机当时有部分迁移失败

iptables导入导出
导出：
iptables-save > iptables.bak

导入：
iptables-restore < iptables.bak

如何判断iptables有残留：
这个是实体机中看到的虚机网卡，
计算节点：ip a
4095:qbrf6396244-3b:<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000

就会创建带有6396244相关chain和rules
iptables -N neutron-openvswi-of5afefd0-f等等
（neutron-openvswi-of5afefd0-f是iptables -nL中查询出来的）

解决：（重启防火墙）重启iptables
service iptables status    # 查看iptables状态
service iptables restart   # iptables服务重启
service iptables stop      # iptables服务禁用

为啥计算节点需要开防火墙：
当前网络模式下 是通过iptables实现虚机安全组功能的

如果想清空的话，先执行
/sbin/iptables -P INPUT ACCEPT
然后执行
/sbin/iptables -F
通过iptables -L 看到如下信息
Chain INPUT (policy DROP 0 packets, 0 bytes)  （注意 是DROP）
执行/sbin/iptables -F就肯定立马断开连接
当执行了
/sbin/iptables -P INPUT ACCEPT
再次通过iptables -L看信息的话就是
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
所以现在是可以安全使用
/sbin/iptables -F了


查看现在iptables规则：
iptables -L -n -v
Bash
清空配置：
iptables -F #清楚规则链中已有的条目；使用iptables -F 要小心，搞不好，你就马上同服务器断开连接了
iptables -X #删除没有用户配置文件相关的chain
iptables -Z #清空规则链中的数据包计算器和字节计数器；

003-集群没空间了

1
2
3
4
5
6
7
8
9
10
11
1 没有空间了
出现场景：chunkserver中的某个磁盘没有可用空间了。一般出现于写操作，但是回收/删除/碎片整理也会触发/加剧这种异常的出现

处理：
a 首先创建extent的时候是按照空间大小来伪随机的。（可用空间小于16G的时候不会选择这个磁盘）（master端有0.9的阈值，已用超过0.9 也不会往这儿新写）
b 写操作假如已用空间大于95%（可调） ，不接受新的写动作，直接返回空间满（直接影响gateway）
c 磁盘上肯定会剩余一定量的空间可以进行回收和碎片整理。而这两个动作的最终目的是空余出更多的空间。

最优期待：chunkserver层面，永远不会出现可用空间为0的情况

影响：某些写/创建 请求会返回空间满

004-checksum错误

1
2
3
4
5
6
7
8
9
10
checksum 错误
出现场景：chunkserver内部数据错误；磁盘损坏  前者是程序bug，出现必改

处理：
a 出现非磁盘损坏的一定修改bug
b 假如出现了磁盘损坏的要进行修复。（需要再优化下）

最优期待：除了磁盘损坏，永远不出现checksum 异常

影响：出现错误之后 此次操作失败，相对严重，非常不希望出现

005-seq不对

1
2
3
4
5
6
7
8
9
10
11
12
3 seq不对

出现场景：
a 写操作没能递增过来（或者跳变）
b 中途chunkserver停止过，包括一般kill和kill -9，节点跪了等等
c 进行迁移/均衡之后的extent刚开始写的时候

处理：读写动作会进行实时修复，然后继续。假如出现所有chunkserver的seq都比较小的情况，是问题，需要定位。
但实时修复的前提是对端存在指定的seq。b/c 不可避免。正常情况下的a场景也比较少。假如出现比较多，需要查看下原因。希望gateway端的重试动作能包住

最优期待：
这种错误可以出现，但是不能影响整理流程。且同样的操作（读写同样的extent）不应该再出现异常

006-超时

1
2
3
4
5
6
7
8
9
10
11
4 超时
出现场景：
a gateway到chunkserver的读写卡死。
b master创建/删除动作慢，导致超时

处理：
a出现就是bug，一定需要修改
b现在超时时间是20s,设计理论不应该出现这种情况。出现就是bug。但是出现了直接影响读写，希望master做好重试动作

最优期待：不出现a和b，
影响：出现错误就要改，非常不希望出现

007-extent不存在

1
2
3
4
5
6
7
8
9
10
11
extent不存在

出现场景：
a 进行了迁移/均衡，gateway元数据没有更新
b bug（该存在但不存在）出现就要改

处理：
场景a不需要更改。gateway那边做好重试就好
场景b 出现就是bug

最优期待：可以出现这种err，但是不能影响业务。gateway能把err包裹

008-Gateway乱码：

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
Gateway乱码：

陈玉强(18101378) 2019-12-20 20:55:25
chunkserver:
cat /mnt/snbslog/snbs/ChunkServer/server.INFO | grep -E "ChunkId:[^0-9]"

gateway:
cat /mnt/snbslog/snbs/Gateway/server.INFO | grep -E "ChunkId: [^0-9]"
cat /mnt/snbslog/snbs/Gateway/server.INFO | grep  "ChunkId: UpdateChunkPos res:"
cat /mnt/snbslog/snbs/Gateway/server.INFO | grep  "ip error"
cat /mnt/snbslog/snbs/Gateway/server.INFO | grep  "ChunkIdCheck vol name: old chunkid:  new:"
@黄涛贻 @王俊凯 @朱晓伟
我整理了一些日志关键字，用来确定是否出了乱码问题
黄涛贻(19047618) 2019-12-20 20:56:29
master:
cat /mnt/snbslog/snbs/Master/server.INFO | grep -E "Warning:volume [^0-9]"


gateway日志打印：
000c5 ChunkIdCheck: false client.Addr 10.238.161.2:9595 ret 101001 UpdateChunkPos res: chunkserver error
2019-12-23 12:28:52.194 [I 30208 replicatclient.go:86] dev: 0bbf77c3-f15e-432c-9d2c-baa6302f742a ChunkId: 000000000013d7aa000000c5 PkgChunkId: A
                                                                                                                                                0013d7aa000000c5 ChunkIdCheck: false client.Addr 10.238.161.3:9595 ret 101001 UpdateChunkPos res: chunkserver error
2019-12-23 12:28:52.195 [I 30208 replicatclient.go:86] dev: 0bbf77c3-f15e-432c-9d2c-baa6302f742a ChunkId: 000000000013d7aa000000c5 PkgChunkId: A
                                                                                                                                                0013d7aa000000c5 ChunkIdCheck: false client.Addr 10.238.161.3:9595 ret 101001 UpdateChunkPos res: chunkserver error
2019-12-23 12:28:52.195 [I 30208 replicatclient.go:86] dev: 0bbf77c3-f15e-432c-9d2c-baa6302f742a ChunkId: 000000000013d7aa000000c5 PkgChunkId: A
                                                                                                                                                0013d7aa000000c5 ChunkIdCheck: false client.Addr 10.238.161.5:9595 ret 101001 UpdateChunkPos res: chunkserver error
2019-12-23 12:28:52.196 [I 30208 replicatclient.go:86] dev: 0bbf77c3-f15e-432c-9d2c-baa6302f742a ChunkId: 000000000013d7aa000000c5 PkgChunkId: A
                                                                                                                                                0013d7aa000000c5 ChunkIdCheck: false client.Addr 10.238.161.2:9595 ret 101001 UpdateChunkPos res: chunkserver error
2019-12-23 12:28:54.197 [I 30208 replicatclient.go:86] dev: 0bbf77c3-f15e-432c-9d2c-baa6302f742a ChunkId: 000000000013d7aa000000c5 PkgChunkId: A
                                                                                                                                                0013d7aa000000c5 ChunkIdCheck: false client.Addr 10.238.161.3:9595 ret 101001 UpdateChunkPos res: chunkserver error
2019-12-23 12:28:54.198 [I 30208 replicatclient.go:86] dev: 0bbf77c3-f15e-432c-9d2c-baa6302f742a ChunkId: 000000000013d7aa000000c5 PkgChunkId: A
                                                                                                                                                0013d7aa000000c5 ChunkIdCheck: false client.Addr 10.238.161.3:9595 ret 101001 UpdateChunkPos res: chunkserver error
2019-12-23 12:28:54.198 [I 30208 replicatclient.go:86] dev: 0bbf77c3-f15e-432c-9d2c-baa6302f742a ChunkId: 000000000013d7aa000000c5 PkgChunkId: A
                                                                                                                                                0013d7aa000000c5 ChunkIdCheck: false client.Addr 10.238.161.5:9595 ret 101001 UpdateChunkPos res: chunkserver error
2019-12-23 12:28:54.199 [I 30208 replicatclient.go:86] dev: 0bbf77c3-f15e-432c-9d2c-baa6302f742a ChunkId: 000000000013d7aa000000c5 PkgChunkId: A
                                                                                                                                                0013d7aa0

009-checksum

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CheckSum报错：
cat stackfile|grep -a CheckSum

日志打印：
2019-12-27 14:32:31.580 [I 03103 chunkstore.go:183] ChunkStore readBySeqno,extentid:jX00000081 ,startSeq:116,endSeq:140,err:CheckSum is not right
2019-12-27 14:32:31.580 [I 03103 chunkServerTcpImp.go:637]  ReadFixData chunkid:0000000000186a5800000081 ,Sn1:116,Sn2:140, strat:129,end:257 ,err:%!S(string=CheckSum is not right)
2019-12-27 14:32:35.107 [E 03103 extenttable.go:2245] read data err CheckSum is not right
2019-12-27 14:32:35.107 [I 03103 extenttable.go:2157] !!!!!!!!!!!!!!!!!! CheckSum is not right
2019-12-27 14:32:35.107 [I 03103 extenttable.go:1526] readPageNV readByDataBlockHeadV error.extentID:j400000129,startSeq:96,endSeq:130,mbcidx:0,error:CheckSum is not right
2019-12-27 14:32:35.107 [I 03103 chunkstore.go:183] ChunkStore readBySeqno,extentid:j400000129 ,startSeq:96,endSeq:130,err:CheckSum is not right
2019-12-27 14:32:35.107 [I 03103 chunkServerTcpImp.go:637]  ReadFixData chunkid:0000000000186a3400000129 ,Sn1:96,Sn2:130, strat:129,end:257 ,err:%!S(string=CheckSum is not right)
2019-12-27 14:32:35.611 [E 03103 extenttable.go:2245] read data err CheckSum is not right
2019-12-27 14:32:35.611 [I 03103 extenttable.go:2157] !!!!!!!!!!!!!!!!!! CheckSum is not right
2019-12-27 14:32:35.611 [I 03103 extenttable.go:1526] readPageNV readByDataBlockHeadV error.extentID:j_00000071,startSeq:228,endSeq:297,mbcidx:3,error:CheckSum is not right
2019-12-27 14:32:35.611 [I 03103 chunkstore.go:183] ChunkStore readBySeqno,extentid:j_00000071 ,startSeq:228,endSeq:297,err:CheckSum is not right
2019-12-27 14:32:35.611 [I 03103 chunkServerTcpImp.go:637]  ReadFixData chunkid:0000000000186a5f00000071 ,Sn1:228,Sn2:297, strat:903,end:1023 ,err:%!S(string=CheckSum is not right)
2019-12-27 14:32:38.541 [E 03103 extenttable.go:2245] read data err CheckSum is not right
2019-12-27 14:32:38.541 [I 03103 extenttable.go:2157] !!!!!!!!!!!!!!!!!! CheckSum is not right
2019-12-27 14:32:38.541 [I 03103 extenttable.go:1526] readPageNV readByDataBlockHeadV error.extentID:j_00000071,startSeq:228,endSeq:297,mbcidx:3,error:CheckSum is not right
2019-12-27 14:32:38.541 [I 03103 chunkstore.go:183] ChunkStore readBySeqno,extentid:j_00000071 ,startSeq:228,endSeq:297,err:CheckSum is not right
2019-12-27 14:32:38.541 [I 03103 chunkServerTcpImp.go:637]  ReadFixData chunkid:0000000000186a5f00000071 ,Sn1:228,Sn2:297, strat:903,end:1023 ,err:%!S(string=CheckSum is not right)

010-错误码

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
影响：gateway需要做好重试动作
ErrExtentNotExist:     101001,
ErrExtentExist:        101002,
ErrExtentIDTooLong:    101003,
ErrCloneExtentIDExist: 101004,
ErrExtentCloned:       101005,
ErrBadExtentPos:       101006,
ErrExtentTableFull:    101007,
ErrExtentNodeIsNull:   101008,
ErrBadOffset1:         101009,
ErrBadOffset2:         101010,
ErrBadOffset3:         101011,
ErrBadBuf1:            101012,
ErrBadTranseq:         101013,
//W/R
ErrMbcIsNull:           102014,
ErrMbcSonsIsNull:       102015,
ErrChecksum:            102016,
ErrRcacheIsNull:        102017,
ErrDbhcacheIsNull:      102018,
ErrSegmentSeqDisorder:  102019,
ErrReadDataShort:       102020,
ErrWriteDataShort:      102021,
ErrReadSegmentShort:    102022,
ErrNoSpaceLeft:         102023,
ErrBadSegmentHead:      102024,
ErrLegalSegmentID:      102025,
ErrLegalSegmentOff:     102026,
ErrSegmentRingAbNormal: 102027,
//load
ErrDevCapacity:     103027,
ErrLoadRemovedDisk: 103028,
ErrSBCheckSum:      103029,
ErrBadType:         103030,
ErrNoLegalCP:       103031,
ErrCpIsNotDirty:    103032,
ErrNoLegalCpExist:  103033,
//other
ErrBadRequest: 104000,

011-snbs设备死机

1
当时的messge日志：

1
2
3
4
定位人：朱晓伟、高红
解决：（暂时判断是这个问题导致，不确定）
关闭NetworkManager
systemctl stop NetworkManager

012-abrt-hook-ccpp导致设备内存占用高

1
2
3
4
5
1.SIT-SNBS环境abrt-hook-ccpp导致设备内存占用高
时间：12.14日
定位人：卢辉
解决：关闭abrt-hook-ccpp
解决方案未定

013-rollback的问题

1
2
3
4
chunkserver日志：cat /mnt/snbslog/snbs/ChunkServer/chunkserver.INFO|grep "code bug"
2020-03-31 15:18:19.184 [I 03602 extenttable.go:1750] 000000000098968e00000352 6455 1 code bug!!!!!!!!!!!!!!!!!! 0
2020-03-31 15:18:19.184 [I 03602 chunkstore.go:84] extentstore Write ChunkId:000000000098968e00000352  error:code bug!!!!!!!!!!!!!!!!!! 
2020-03-31 15:18:19.184 [I 03602 rebuild.go:187]  repair Extent: 000000000098968e00000352    write err:  000000000098968e00000352 code bug!!!!!!!!!!!!!!!!!!

014-extent修复序列号

1
2
3
4
5
6
7
chunkserver日志打印：
cd /mnt/snbslog/snbs/ChunkServer/;cat stackfile*|grep "rebuild.go:55"


2020-03-31 15:15:26.573 [I 03430 rebuild.go:55] repairExtent: start  000000000098968b00000539  res: 1  nowseq: 0 spend: map[checkLoc:338.236µs GetFixNode:84ns]

res 0 代表修复 成功。1 代表修复失败。

015-写入写缓存成功，写入机械盘失败

1
2
3
反正不影响读写，而且也给何大佬报备过了。出现一个写请求写入写缓存成功。但写入机械盘失败。失败原因是seq不对，但插入前已经比对过seq了，不应该在写机械盘的时候出现这个错误。同时，写缓存的重试机制没有生效。日志关键字“doDirtyBlockReq ErrBadTranseq

2020-03-30 21:55:32.312 [I 06774 extent.go:206] 00000000008add1400000215 doDirtyBlockReq ErrBadTranseq 122752 5471

平时带着搜下err /Err 就好

赞赏一下吧～