第二十九期 记一次AFD环境的存储变更
我手上维护的一套X86四节点RAC集群,由于某些历史原因,对于存储磁盘的识别仅使用了udev,相当于单链路使用,在存储环境非常稳定的情况下其实也没啥,但是不巧的是,我这使用的某台存储有个板卡告警了需要更换,会丢失一半链路,因此。。。需要对服务器操作系统磁盘识别进行改造,从单纯udev改造为multipath+udev。
0 AFD
本次需要变更的环境在udev之上还使用了Oracle AFD技术来识别磁盘。AFD,ASM Filter Driver,是Oracle 12cR2开始引入的类似于oracleasm(asmlib)的一种磁盘识别工具,和oracleasm识别映射路径不同(/dev/oracleasm/disks),ADF识别映射路径为/dev/oracleafd/disks。AFD可以最大限度的限制磁盘的用户权限,即便是root用户,也无法删除AFD磁盘。这就是ASMFD比ASMLIB和udev相比的新特性,I/O Filter筛选。
然而这里也因为AFD出现了一系列问题。
1 测试
由于这是一套ADG环境,所以备库随便搞(doge),因此直接在备库将单udev变更为multipath+udev,将磁盘二次识别之后指定到原来的路径(例:/dev/ASMDISK01)。原始配置和目标配置如下:
原始配置:
udev:
KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/$name",RESULT=="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", SYMLINK+="ASMDISK01", OWNER="grid", GROUP="asmadmin", MODE="0660"
配置完成后磁盘将会被识别为/dev/ASMDISK01并赋予对应权限。然后使用oracleasm对磁盘进行二次映射(这里是个坑和主库不一样)。
变更配置:
multipath.conf:
multipath {
wwid xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
alias DISK01
}
multipath服务启动后磁盘将会识别为/dev/mapper/DISK01。
udev:
ENV{DM_NAME}=="DISKC01",OWNER:="grid",GROUP:="asmadmin",MODE:="660",SYMLINK+="ASMDISK01"
配置完成后/dev/mapper/DISK01会被映射为/dev/ASMDISK01并赋予对应权限。
然后在使用oracleasm scandisks命令处理即可。这里我犯了一个错误没有去检查oracleasm到底是怎么映射磁盘的,本以为是映射的/dev/ASMDISK01结果是/dev/mapper/DISK01,也就造成了后面在主库操作时出现了问题。
2 正式变更
照着和备库的方式在主库节点1进行了操作,发现grid起不起来,日志里面各种找不到盘:
此时其余节点运行正常,由于临近HW且割接时间有限,在捯饬了一段时间后回滚原始配置了。
3 排查
怎么说呢,我自己AFD还是接触的太少了,相关只是比较匮乏。老办法,在翻官方文档的同时MOS提交了个SR,SR那边的意思是,AFD配置了搜索路径为/dev/ASMDISK*,虽然udev再次映射,但是AFD本身没有识别到对应磁盘,可以尝试将AFD的磁盘搜索路径变更为multipath映射路径。因为当前还在HW期间,只能自己搭一个单实例测试环境来测试。
搭建完成后磁盘映射如下:
首先,常规启动has,报错同正式环境一样(这里不甩日志了),无法识别磁盘。
随即将udev配置调整如下:
ENV{DM_NAME}=="DISKC01",OWNER:="grid",GROUP:="asmadmin",MODE:="660"
udevadm trigger --action=change
再次启动has,磁盘组仍然无法挂载:
检查AFD扫描路径仍然是未变更前路径:
对AFD扫描路径进行调整:
asmcmd afd_dsset '/dev/mapper/DISK*'
asmcmd afd_scan
asmcmd afd_refresh
然后再手动挂载磁盘即可。
4 总结
首先,这次回归到技术分享,知道写了些啥了。后面HW结束后还是会在生产环境重新操作。虽然AFD从功能、特性来说是个好东西,但是在磁盘识别这块真没oracleasm智能(doge),对AFD不熟也是真的。当然这次遇到这事也是个积累。