-
vSAN群集孤立测试
-
简述vSAN群集脑裂
-
解决inaccessible问题
-
查看VM运行时的内存开销
-
解决vSAN运行状况异常
-
嵌套vSAN环境添加磁盘组时报错
-
将vSAN群集主机置于维护模式
-
vCenter性能数据采集
-
Debug
服务器 | IP地址 | 说明 |
---|---|---|
esxi-6a | MGT:2.2.2.11/24 vSAN:3.3.3.11/24 |
运行VM:RHEL6 |
esxi-6b | MGT:2.2.2.12/24 vSAN:3.3.3.12/24 |
仅断开vSAN网卡(组件) |
esxi-6c | MGT:2.2.2.13/24 vSAN:3.3.3.13/24 |
仅断开vSAN网卡(见证) |
vCenter6 | MGT:2.2.2.10/24 vSAN:3.3.3.10/24 |
ping 3.3.3.150 |
RHEL6 | MGT:3.3.3.150/24 | ping 3.3.3.{10,11,12,13} vsan存储策略:允许的故障数(1),磁盘带数(3),容错方法(RAID-1) |
测试结果:ping测试访问RHEL6虚拟机正常,vsan存储器容量减小;ping测试正常但是 du、df 等数据检索命令无法执行(内核缓存运行),当恢复任意1台宿主机vSAN网卡时命令执行正常;会执行HA故障切换。
附加测试:当VM运行在见证服务器上、断开2台组件服务器的vSAN网络,结果同上但不会执行HA故障切换。
a. 在ESX/ESXi 4.x版本中,当群集中主机A的管理网络异常断开,会触发“脑裂”情况、出现虚拟机故障切换;由于vCenter不能与主机A正常通信、触发故障切换(vSphere HA),接管主机B与主机A在争夺虚拟机票据,导致虚拟机不断的开机/关机。
b. 在ESXi 5.x/6.x版本中,增加了“数据存储检测信号”,vCenter会在与主机A通信异常的情况下使用数据存储来监控主机和虚拟机。
c. 在vSAN群集中,不会启用HA配置中的“数据存储检测信息”;在更改主机A的vsan流量网卡IP地址时,会触发“脑裂”情况、出现虚拟机故障切换;所以在vsan群集中需要调整vsan流量网卡IP地址时、先关闭vSphere HA功能。
d. 规划:vSphere HA环境下,为每个vSwitch至少配置2块物理网卡、并且2块物理网卡分别连接在不同网络交换机上。
现象描述:vSAN运行状况检查出现Virtual SAN对象运行状况“失败”,inaccessible数字为1;
隐藏内容:此处内容需要评论本文通过后才能查看!
要打开虚拟机电源,需要一定数量的可用开销内存。您应当了解此开销量。
虚拟机所需的开销内存量取决于多种因素,其中包括 vCPU 数量和内存大小、设备数量和类型、监视器使用的执行模式以及虚拟机的硬件版本。您使用的 vSphere 版本也可以影响所需的内存量。VMX 将自动计算虚拟机所需的开销内存量。
要了解特定配置所需的开销内存量,请先打开相应虚拟机的电源。在 vmware.log 文件中查找。打开虚拟机电源后,所需的开销内存量会打印到该日志。在该日志中搜索 VMMEM 以查看为虚拟机预留的初始和精确开销内存量。
a. “Host not updated to 6.0 U2 or later version. Health Checks disabled.”
参考:https://communities.vmware.com/thread/581453
说明:重启vSAN群集中单台ESXi主机的vsanmgmtd服务,可能会导致其他运行状况异常;必要时、将vSAN群集中所有ESXi主机的vsanmgmtd服务重启。
/etc/init.d/vsanmgmtd status
/etc/init.d/vsanmgmtd restart
错误信息:vSAN群集主机添加第2组磁盘组时报错“Unable to create LSOM file system for VSAN disk”.
解决方法:为vSAN群集主机添加系统内存,建议不少于32GB。
官方文档:将 Virtual SAN 群集的成员置于维护模式
其他说明:
1) 使用 vSphere Client 将 vSAN 主机进入维护模式时,默认选项为“确保可访问性”;
2) vSAN 主机断开连接超过 1 小时后,虚拟机 VMDK 会重新应用关联的存储策略来重构数据。所以要确保 vSAN 存储器可用容量大于:S * (N/C)
C = vSAN 群集磁盘组总数量
N = 进入维护模式的 vSAN 主机磁盘组数量
S = vSAN 存储器总容量
[vCenter Server 设置 --> 统计信息]
间隔时间 | 保存时间 | 统计级别 |
---|---|---|
20 秒 | 1 小时 | 实时 |
1~5 分钟(默认值5) | 1~5 天(默认值1) | 1~4(默认值1) |
30 分钟 | 1 周 | 1~4(默认值1) |
2 小时 | 1 个月 | 1~4(默认值1) |
1 天 | 1~5 年(默认值1) | 1~4(默认值1) |
案例1:vSAN群集中的ESXi升级小版本从6.0 u2 升级到 6.0 u3后无法识别HDD容量
隐藏内容:此处内容需要评论本文通过后才能查看!
案例2:ESXi 6.0 物理 vSAN 环境中嵌套 ESXi 6.5 虚拟 vSAN 环境,由于物理 vSAN 环境使用的存储策略 FTT=0 并且正在执行重平衡作业,此时执行虚拟 vSAN 环境创建磁盘组时提示 “Failed to reserve disk *** error code: -1” 的错误。
解决:
a. 在物理 vSAN 环境下将虚拟 vSAN 的主机迁移到本地存储器、不关联存储策略;
b. 在虚拟 vSAN 环境下重新配置 vSAN 磁盘组;
c. 报错原因可能与物理 vSAN 环境的重平衡作业有关,重平衡过程中涉及数据迁移、但是虚拟机数据没有副本(FTT=0)。猜测是为了避免数据不一致而锁定了相关的 vSAN 对象,从而虚拟 vSAN 主机的磁盘无法写入数据。
不错,解决了我的问题
学习一下inaccessable解决方法
文章写的不错
正好同样的问题,感谢分享。
inaccessible得确认,以及healthy数量比较大
正在学习,对我的问题有帮助
正在学习,对我的问题有帮助
为了防止恶意灌水和广告等、启用了评论审核,所以不能立即看到。
感谢感谢经验分享。
感谢经验分享。
vSAN运行状况检查出现Virtual SAN对象运行状况“失败”,inaccessible数字为2
vSAN运行状况检查出现Virtual SAN对象运行状况“失败”,inaccessible数字为4
正好同样的问题,感谢分享。
Jump in the loop