1、需求背景
vcs集羣，問題是在app14主機在測試丟包問題時，重啓了app14的主機，重啓時業務遷移到app20備機上了，但是app20上懷疑當時沒有遷移成功，出現了共享盤的IO error問題。後經過覈查發現app13,14,15,16對應的共享盤在app20備機上狀態都不正常，如下：
同時，在app20該主機上使用fdisk -l也無法看到對應的/vdb/vdc/vdd/vde/vdj五塊盤。
經過確認，vdb/vdc/vdd/vde/vdj跟雲盤對應關係如下：
|
磁盤 |
雲盤 |
|
/dev/vdb |
medapp13-data |
|
/dev/vdc |
medapp14-data |
|
/dev/vdd |
medapp15-data |
|
/dev/vde |
medapp16-data |
|
/dev/vdj |
medapp14_20_50g |
目前備機上沒跑業務，文件系統掛載如下：
[/root]# df -Th
目前app14上在跑業務，文件系統掛載如下：
$df -Th
App20本地掛載文件：
#cat /etc/fstab
App14掛載文件：
#cat /etc/fstab
注意，上面均未發現這些lv文件系統被使用了。
2、處理思路
這裏面有兩個問題：
- 未使用的雲盤，可以從tecs層面去掉。
未使用的雲盤爲如下四塊：
- 對於共享的在資源組中的盤，需要在app20虛機上，在tecs層面重新卸載然後在掛載。
![]()
3、執行步驟
3.1.刪除未使用的雲盤
3.1.1.卸載app20虛機上的無用雲盤
root用戶登陸app20：
針對要移除的vg，先去除激活:
vgchange -an vgapp15
vgchange -an vgapp16
vgchange -an vgapp13
裏面沒看到vgapp14，就不需要去除激活，後面其他主機也一樣（能看到的就需要去激活，不能看到的就不做，注意該操作只針對vgapp13,vgapp14,vgapp15,vgapp16這四個vg，其他vg不能做任何操作）。
卸載不需要重啓虛機，對虛機沒有影響。
3.1.6.卸載後檢查
# vgscan
不能看到vgapp13,vgapp14,vgapp15,vgapp16這四個vg在上述虛機上。
# fdisk -l |grep Disk
不能看到medapp13_20_50g/medapp14_20_50g/medapp15_20_50g/medapp16_20_50g這四個雲盤對應的四個50g的磁盤了。
3.2.重新卸載/掛載IO error的盤
3.2.1.重新掛載app20的共享盤
3.2.1.1.卸載
卸載後對虛機來說是立即生效的。無需重啓虛機。
輸入虛機app20的名稱，下拉列表中會有對應的數據，選中後點確定就可以完成重新掛載。
我這個圖中是因爲該磁盤並未從app20上卸載（已經掛在app20上了），所以顯示沒有符合條件的數據。掛載完成後，注意掛載到了系統層面的具體哪個盤(/dev/vd?)，後面我們直接根據這個去操作系統層面檢查掛載。重新掛載後根據經驗來說虛機層面不需要重啓，可以在線識別。
3.2.1.3.檢查掛載
# fdisk -l |grep Disk
可以看到對應大小的磁盤，上面3.2.1.2步驟中可以看到對應的雲盤掛載到操作系統層面是/dev/vd?，直接檢查對應的/dev/vd?即可。
# vgscan
通過該命令也可以看到對應的vg。
4、影響說明
1、對於3.1的操作，卸載無用的盤，並釋放對應的雲盤可以回收磁陣空間，同時也可以降低錯誤概率。卸載對業務沒有感知，不影響業務。
2、對應3.2的操作，由於當前業務都是跑在主機上的，備機app20上並沒有業務，所以重新卸載和掛載共享盤，對業務也沒有影響。
3、資料參考
https://www.linuxtechi.com/fixing-lvm-io-errors/