cloudos3.0上看不到cas的部分共享存储LUN的一种排查思路

不涉及

cloudos3.0上看到的共享存储LUN的数量与cas上的共享存储LUN的数量不一致。

如下所示，os上和cas上就看到的共享存储LUN的数目不一致，os上看到的是6个LUN，cas上实际上是有9个LUN。

1、在cloudos后台查看计算机点的nova日志和cinder日志，发现是由于cas的插件上报的数量就是错误的；

2、cas上排查cvk的syslog日志等发现，部分cvk上的LUN只读了，使用fsck.ocfs2 -y命令修复之后还是只读；

3、进一步排查只读的LUN对应的多条路径的blkid，同一个LUN上的不同路径的blkid（这个id是类似于uuid的由数字和字母组成的一串字符）是不一致的。

1、LUN每经过一次格式化之后，这个blkid就会更新，cvk主机是是直接读取的存储控制器上反馈的不同路径的blkid，正常情况下同一个LUN的不同路径的blkid一定是一致的。由于这个id不一致，共享文件系统就会认为存储不可用，从而置为只读模式。

2、根据以上排查，可以肯定是存储侧的问题，考虑到现场是对接的浪潮的FC存储，且在对接3par的FC或者是onestor存储的时候没有出现过同一个LUN不同的路径反馈的Blkid不一致的情况。

3、经过与浪潮存储厂家的沟通，确认是存储侧的问题。现场之前是存储的主备场景，在改为双活场景的时候，缓存加速模式需要改为double模式。

现场将这个配置改过之后，cas上的只读问题，问题就解决了。

同一个LUN不同的路径反馈的blkid不一致的情况，一般为存储侧的问题，建议排查存储。