Link
Wiki

Welcome to My Blog, A documentary of Life.

Search

本文是 2016 年初学 vSAN 时的笔记，某些技术细节可能和最新的 vSAN 存在差异，请结合最新的产品文档/特性查看

目录

  1. vSAN 故障及预期现象
    1. 故障1 - 单个磁盘被拔出
    2. 故障2 - 单个 SSD 被意外拔出
    3. 故障3 - 单个磁盘故障
    4. 故障4 - 单个SSD故障
    5. 故障5 - 主机宕机或者重启
    6. 故障6 - 主机网络连接中断
    7. 故障7 - 整个集群的网络故障
    8. 故障8 - 单个IO控制器故障
    9. 模拟故障时注意事项
  2. vSAN网络隔离时的现象

vSAN 故障及预期现象

本文章再次参照VSAN的官方文档：VSAN-Troubleshooting-Reference-Manual，此文档有中文版，但是排版及翻译并不好，有条件的可以直接阅读原文。

故障1 - 单个磁盘被拔出

预期现象：

如果VM配置为FTT=1，则虚拟机可以正常使用。

磁盘状态会被标记为absent

所有IO会被暂停，然后重新计算一个对象的可访问性。

所有保存在此磁盘上的component被标记为absent

如果相关对象为健康(所有可用投票数>50%)，则IO恢复

这整个检查过程大概为5-7秒

如果此磁盘在60分钟内被再次插回VSAN环境，则不会进行component的重构。

如果60分钟后，原来的磁盘未被插回VSAN，则VSAN会对原磁盘上的component进行重构。

在vmkernel.log 中能看到类似以下日志：

2014-09-30T09:44:55.312Z cpu20:32849)WARNING: ScsiPath: 7028: Path lost for adapter vmhba0 target 1 channel 0 pun 0 2014-09-30T09:44:55.312Z cpu22:33441)WARNING: LSOMCommon: IORETRY_NotifyAPD:1647: Got APD event 1 on 0x410c0285ca90 2014-09-30T09:44:55.312Z cpu20:32849)WARNING: ScsiDevice: 8820: PDL set on VSAN device path "vmhba0:C0:T1:L0" [...]

2014-09-30T09:44:59.317Z cpu22:33506)WARNING: LSOM: LSOMEventNotify:4581: VSAN device 527cfbf5-ae7a-33f6-78bc-beed2f1730dd has gone offline.

vobd.log中有以下日志：

2014-09-30T09:44:59.317Z: [VsanCorrelator] 59865017530us: [vob.vsan.pdl.offline] VSAN device 527cfbf5-ae7a-33f6-78bc-beed2f1730dd has gone offline.

2014-09-30T09:44:59.317Z: [VsanCorrelator] 59867627549us: [esx.problem.vob.vsan.pdl.offline] VSAN device 527cfbf5-ae7a-33f6-78bc-beed2f1730dd has gone offline.

在vSphere web Client，对应的ESXi主机下，会有类似于：“VSAN device XYZ has gone offline ”的日志。

故障2 - 单个 SSD 被意外拔出

预期现象：

如果VM配置为FTT=1，则虚拟机可以正常使用。

磁盘组以及相关的磁盘状态会被标记为absent，可以从vSphere Web Client中看到

所有IO会被暂停，然后重新计算每个相关对象的可访问性。

所有保存在此磁盘组上的component被标记为absent

如果对象健康(所有可用投票数>50%)，则IO恢复

这整个检查过程大概为5-7秒

如果此SSD在60分钟内被再次插回VSAN环境，则不会进行component的重构。

如果60分钟后，原来的SSD未被插回VSAN，则VSAN会对原磁盘组上的component进行重构。

如果一个VM的FTT=0，则必须将原来的SSD插回VSAN才能恢复此虚拟机。

故障3 - 单个磁盘故障

磁盘故障后，相关的component都会被标记为 degraded。

如果VM配置为FTT=1，则虚拟机可以正常使用。

磁盘状态会被标记为degraded(已降级)，可以从vSphere Web Client中看到

所有IO会被暂停，然后重新计算每个相关对象的可访问性。

如果对象健康(所有可用投票数>50%)，则IO恢复

这整个检查过程大概为5-7秒

此时VSAN会立即查找系统中是否有足够的资源(容量、以及满足FTT的主机数)来补全缺失的数据。如果可以满足需求，则立即对缺失的数据进行重构。

如果FTT=0，则此VM将无法从VSAN环境恢复，需要从其他备份进行恢复。

故障4 - 单个SSD故障

SSD故障后，整个磁盘组会被标记为 degraded。

如果VM配置为FTT=1，则虚拟机可以正常使用。

磁盘组以及相关磁盘状态会被标记为degraded(已降级)，可以从vSphere Web Client中看到

所有IO会被暂停，然后重新计算每个相关对象的可访问性。

如果对象健康(所有可用投票数>50%)，则IO恢复

这整个检查过程大概为5-7秒

此时VSAN会立即查找系统中是否有足够的资源(容量、以及满足FTT的主机数)来补全缺失的数据。如果可以满足需求，则立即对缺失的数据进行重构。

如果FTT=0，则此VM将无法从VSAN环境恢复，需要从其他备份进行恢复。

故障5 - 主机宕机或者重启

主机从VSAN集群中脱离会有很多种原因，例如：宕机、重启、网络连接中断等

当出现以上任一问题时，主机相关的组件会被标记为 absent，虚拟机IO在5-7s内能够恢复正常。

被标记为absent也就意味着有60分钟的计时，当60分钟内主机恢复正常，VSAN 数据也会正常。

之所以将其标记为 absent 而不是degraded，是因为主机故障通常可以恢复，例如服务器会在崩溃后自动重启、当电源线被意外拔掉后，插上后服务器能恢复正常。

如果此时有个FTT=1的虚拟机，如果它此前运行在故障的主机上，则VSAN集群会通过HA(需要提前开启HA)重启它，如果不在故障主机上运行，则正常运行。

如果主机故障或重启，会产生事件： "Host connection and power state" ，如果集群开启了HA， 会报告：" vSphere HA host status" 警告，集群中正常主机会有 “Host cannot communicate with all other nodes in the VSAN Enabled Cluster” 信息。

故障6 - 主机网络连接中断

当一台主机网络和集群中其他主机通信中断后，VSAN集群并不知道此主机发生了故障还是网络中断。此时会发生网络隔离。通信中断的这台主机成为一个网络隔离区域，其他剩余主机为一个隔离区域。

vSphere Web Client 会报告“network misconfiguration detected”状态。

在每个隔离分区，每个object都会选举出一个owner，所以将来有多少个分区、同一个object就会有多少个owner，但是实际最多只有一个owner有合规的投票（>50%）。为保证有一个owner合规，则最多只能有一个网络分区。

只有这个owner object才有权限进行IO操作。

在网络隔离时，也会有60分钟的计时。

如果在60分钟内，被隔离的主机重新加入到集群中，则它原来的数据已经过旧，需要从最新的component进行resync。

如果超过60分钟，被隔离的主机才被加进来，此时主机原来的数据已经被重构(rebuild)到集群中其他主机上。此主机上的数据会被丢弃。

故障7 - 整个集群的网络故障

当整个集群的网络故障时，也会发生网络隔离，但是此时是每台主机都在一个隔离区域内。单个主机的表现和上文说的类似。

发生整体网络隔离时，所有主机都无法正常选举出owner，不会发生rebuild。

当网络恢复时，VSAN集群开始resync所有component，虽然网络隔离后不会有数据变化，但是VSAN还是会进行resync，保证所有component都处于最新状态。

故障8 - 单个IO控制器故障

当IO控制器故障后，与之相关的所有磁盘组都会不可用，所有相关的组件会被标记为degraded。所以诊断 IO控制器故障也很容易。

但是当一台主机只有一个IO控制器和一个磁盘组时，SSD的故障也会产生相同的现象。可以借助vmkernel.log 来分析到底是哪种故障引起的。也可以通过第三方工具来查看控制器的状态(例如登陆到服务器IPMI口查看)。

一般，当一个主机有多个磁盘组，共用一个IO控制器。这些磁盘组都有问题时，很可能就是IO控制器出了故障。

模拟故障时注意事项

在进行故障模拟时，每次只能测试一项！ 当FTT=1时，VSAN最多只能处理一个故障。

而且多个连续测试时，需要保证上个故障已经完全排除。

例如：将主机1的一个磁盘拔掉了，假设1上存在一个组件A，其在集群中另一个副本为B，仲裁为w。 当主机1上的磁盘恢复后，组件A并不是直接变成可用状态，而是处于“stale”状态，因为它上面的数据不是最新的，需要从B进行同步，此操作需要花费一定时间。

如果你在这个同步时间内将保存仲裁w的主机关机，那么这个object总投票数<50%，就会变成不合规状态，虚拟机运行也会异常。

vSAN网络隔离时的现象

测试总结：

1、VSAN 网络隔离不会触发HA

2、在HA和VSAN同时发生时，VM会在object投票数最大的网络隔离区中进行开机

3、仅发生网络隔离时，如果主机所在隔离区域某 VM 所有对象投票>50%，则VM正常运行；否则虚机会暂停。

测试环境：

四台主机，两两网络隔离（环境限制，VM并未安装操作系统）

原环境对象的各个组件分布情况：

虚拟机对象\主机15.1115.1215.1315.16
test2 - - VM home √√√
test2 - - vmdk1√√ √
test-1 - - VM home√√√ 
test-1 - - vmdk1√√√ 

​

实验1：将11、12同13、16之间的网络断开

预期现象：

  • 11和12属于一个隔离网络组中，13和16属于一个隔离网络组中
  • 四台主机都会报告无法与其他启用VSAN的主机通信
  • test1 可以正常运行，test2 运行异常

实际现象：

  • 在修改13和16的VSAN网络后，发生了网络隔离，VSAN集群形成两个网络隔离组。

  • VSAN 集群中所有主机报告：“无法与已启用Virtual SAN的集群中所有其他节点通信”。

  • 虚拟机test1 可以正常运行，但是test2 点击后无任何反应(I/O halt)。

查看每个虚拟机各个对象的状态：

  • 可以看到test2 有一个对象已经变成不合规

  • 如果此时将这个VM关机，会发现 test2 为不可用状态

  • test 1两个组件都是健康状态

实验2：将test1 迁移到 13 上，将主机13和16的VSAN网络隔离

预期现象：

  • 主机 13 不会从vCenter中断开
  • 发生网络隔离，11和12在同一组，13和16在同一组
  • test1 会宕机，直到13和16恢复正常

实际现象：

  • 在将13和16进行隔离后，test1依然运行在13上，从下列图片可以看到，test1这个VM存在于 group2那个网络分区中。

实验3：将test1 迁移到 13 上，再将主机13所有网络隔离

预期现象：

  • 主机 13 会从vCenter中断开
  • 同时发生HA和网络隔离
  • test1 会暂时宕机，但是会通过HA在主机11或者12上进行启动

实际现象：

  • test 1 发生HA，通过HA在12上重新开机

  • 通过查看 test1 各组件的位置，能确定 test1 位于网络隔离区 group1 中