本次主要分享vSAN常见故障排除，其中包括：vSAN创建VM全过程介绍，vSAN排错方法论和vSAN常用排错工具。

vSAN Software Architecture

About vSAN

vSAN是软件定义的对象存储，VMware的对象存储和虚拟化的产品是紧密的结合在一起的，它实际上是将本机磁盘组中的硬盘聚集起来打造的虚拟的软件定义的共享存储。这个环境中只有主机、服务器，没有第三方的硬件存储。

传统存储如果用的是共享存储，服务器连接到LUN，然后在LUN中创建VMFS文件系统，文件系统中有虚拟机的文件夹，由vmkernel进行虚拟机文件I/O。

vSAN中不再以文件的形式进行数据存取，vSAN创建之后有个vSAN Datastore，这个DataStore中存放着5类虚拟机的对象，分别是NameSpace、VMDK、快照、内存以及交换文件。

vSAN数据保护和性能提升主要通过软件层面的策略来实现，由策略定义性能和可用性等。上图是创建vSAN存储策略的界面，可以在此进行各种策略的配置。

Virtual Machine Storage Policy Capabilites for vSAN

可用性最基本的指标就是数据有多个副本，比如RAID 1可以有两个数据副本。在vSAN中通过PFTT策略来保证可用性，即容忍错误的数量是多少，如果为0 就表示不能容错，数据只有一份拷贝，1表示容忍出错1次，数据有两份拷贝。PFTT默认为1，相当于实现了RAID 1的效果，最大可以设置为3。

在RAID中性能的提升需要依靠RAID 0，RAID 0是将数据切成多个条带来进行保存。vSAN中也能将数据切分成多个条带，最多12份进行同时写。

vSAN Architecture Components

vSAN中有这样几个软件组件。CLOM（集群级别的对象管理器），DOM（分布式对象管理器），LSOM（本地日志结构对象管理器），CMMDS（集群成员监视和目录服务）。

更形象一点的描述，CLOM可以理解为架构师，DOM是承包商，LSOM则是Worker，最后的CMMDS为项目经理。

CLOM and Its Role: Architect

CLOM会根据创建的存储策略决定对象是否能基于策略被创建出来，即策略会不会生效。比如副本数是3，要生成4分拷贝，但是集群中只有3台主机，很明显此时的策略无法生效，因为没有充足的主机提供使用。CLOM还会检测整个集群范围内主机的负载情况，将对象及其组件分散到不同的主机上，并且当组件出现问题要进行修复的时候将决定该组件在哪些主机上重建。

CLOM组件在后台有着一个进程，所以一定要保证主机上的这个进程没有出现问题。由于该进程是运行在每个vSAN的节点之上，因此可以通过/etc/init.d/clomd来查看它的当前状态。

DOM and Its Role: Contractor

DOM也是运行在集群中的每台主机上。DOM会接收来自CLOM的指令，并着手实施，它会找LSOM来真正的干活。前面提到的5类对象中都有一个DOM owner，用来审核针对该对象的IO操作，决定是否能够执行，如果IO操作被允许就由DOM client来执行。

LSOM and Its Role: Worker

实际的I/O操作会被DOM分配到LSOM上，由于LSOM会对设备直接进行I/O，所以它是运行在某个主机的内核空间中的，而没有进程。

CMMDS and Its Role: Project Manager

CMMDS能够告诉我们整个vSAN集群拓扑的全貌和对象的状态，包括集群中的服务器、网络、硬盘设备，对象元数据信息，新增或删除主机等，它还会定义集群中的三个角色master、backup、agent，master负责管理整个vSAN集群的业务，backup是master的备份。

我们简单的梳理下这几个组件之间的交互，首先由CLOM接到请求创建对象开始，如果根据策略能创建它就会将需求发给DOM，由DOM进行组件的创建，DOM决定好要创建哪个组件之后将需求发送给LSOM，LSOM跟存储层（SSD、硬盘）进行交互执行具体的I/O。另外的CMMDS会枚举出整个集群中的可用资源，以及这些资源的拓扑和可用情况。

Virtual Machine Creation

虚拟机创建的时候，首先vCenter的vpxd进程会和主机进行通信，选择某个主机创建虚拟机存储。主机上的vpxa进程接收到vpxd发出的请求后，CMMDS会创建策略，主机根据策略创建虚拟机及其关联的vmdk。由于vmdk是对象，因此要由CLOM根据策略来决定是否能创建该对象及其组件，当组件的创建的位置被决定好之后CMMDS会更新CLOM发出的组件拓扑信息。

另外主机上的DOM接收到CLOM发出的信息后，将创建对象组件的要求下发到本地LSOM上，最后LSOM通过本地存储来创建虚拟机的存储对象。

About Object

Home namesace对象其实是一个小的虚拟机文件夹VMFS文件系统，VMDK、Swap、Snapshot deltas、VM memory这4个对象对应的是原来系统中的4个大文件。

这些对象不是直接放在硬盘上，而是分成若干个组件的形式写入存储，这是为了实现RAID、性能以及可用性。具体的切分方式和存储策略相关，比如要实现RAID 1就将数据复制成两个组件来写（未计入Witness组件），既实现RAID 0又实现RAID 1则要4个组件。

上图是RAID 1的组织结构，很明显的看到有两个Component组件，细心的朋友可能发现了这里还多了个witness（仲裁组件）。RAID 1的两个副本中如果其中之一损坏了，就无法进行读，因为此时不能确定哪个副本是完好的。Witness的存在正是为了解决这一问题，它的投票直接决定了哪个组件可用。

Componet Count

下面我们结合具体的例子来看下不同策略下对象和组件到底是如何创建的。（以下组件的计算都不包含witness）。

首先是PFTT等于0（容错为0），FTM为RAID 1，条带为1的情况，此时的硬盘会写1个组件，因为只有1份拷贝。

PFTT等于1（容错为1），FTM为RAID 1，条带为1的情况下，硬盘会写2个组件（拷贝为2）。

PFTT等于2（容错为2），FTM为RAID 1，条带为1的情况下，硬盘会写3个组件。需要注意的是这里的witness会有两个。

PFTT等于1（容错为1），FTM为RAID 1，条带为2的情况下。因为这里的数据有2份拷贝，所以有2个Mirror，同时条带又为2，因此Mirror将会被拆成两份。总结起来一共有4个组件。

PFTT等于2（容错为2），FTM为RAID 1，条带为3的情况下.。根据上面的计算规律可以很轻松的计算出，此时的组件数量应该为9。

需要提到的是默认情况下组件最大为255G，如果某个VMDK对象大小超过255G，就会被平均拆成多份。

同样是PFTT等于1（容错为1），FTM为RAID 1，条带为1的情况。此时由于硬盘大小为400G，超过了默认的255G，所以每个盘会被拆分成两份，每份200G。一共是4个组件。

这里是PFTT等于0（容错为0），FTM为RAID 1，条带为1的情况，因为是600G的硬盘，所以要被平均拆分成3份（注：是每个不超过255G）。

Object Inaccessibility

虚拟机无法启动有各种原因，如果是vSAN存储问题就可能是由于VMDK对象无法访问引起的。组件能否使用依赖于DOM，DOM会确认对象或组件是在线还是离线，如果是离线就无法访问。离线原因可能是组件自身发生损坏，也可能与组件的健康状态有关，比如LSOM组件或数据出现问题。数据的问题有两方面的原因，一方面是数据本身被破坏，另一方面是数据同步有问题。所有一定要清楚组件和哪些对象关联，当前状态如何。

Torubleshooting Methodlogy

Defining the problem

定义问题不能仅限于表层的描述，要能够具体的找出引发问题的关键点。比如有关资源竞争的问题，在vSAN集群中ESXi主机上不仅会运行虚拟机还会进行硬盘的I/O，由于主机是分布式存储集群的一员，因此除了给虚拟机提供CPU和内存资源之外，还会额外的消耗资源在硬盘I/O上。如果I/O特别密集且虚拟机负载又高的话，两者之间就会产生竞争冲突。所以在出现资源竞争问题的时候，需要先看下CPU和内存的使用率是否过高。

要想解决问题，首先应尽可能的收集额外的详细信息。在遇到任何问题时候，第一举措就是保护好现场，比如拍照或截屏，因为有些提示可能会一闪而过不会再重现。有了这些信息后，再根据自身掌握的知识体系结构列出可能原因，然后依次排除。

这里我们对定义问题做更详细的描述。首先是问题能否重现，如果能重现解决起来就相对容易。其次是逐渐缩小问题范围，从集群到主机再到组件依次排查。另外在问题出现之前是否对系统做过改动，通过日志查看有哪些变动。由于VMware的用户基数很大，因此我们可以在相关论坛和官方网站中搜索是否有遇到同样问题的线索。通过每次新版本发布的Release Notes，也能判断问题是否由BUG引起。

Identifying the Root Cause

问题定义完之后接下来就要找寻问题的原因，根据现有产品中环境的状态进行判断，比如检查当前集群、对象和组件的健康状态，硬盘以及虚拟机关联对象是否存在问题等。上图就是vSAN集群的健康状态监控，直观的展示了当前集群的各种情况。

除了图形界面外，还可以通过一些vSAN的命令或脚本在控制台中查看当前状态。

Resolving the problem

最后要做的是构造解决方案，下面通过一些具体的例子来描述。比如主机进入维护模式造成虚拟机不可用，一般在有多份拷贝的情况下进入维护模式并无太大影响，但只有两份拷贝的时候，如果其中一个副本已损坏，另一个正常的副本却进入了维护模式，那么在退出维护模式的时候这两份数据副本就都不是最新状态。所以在进维护模式之前一定要运行vsan.check_state脚本检查对象的所有组件是否健康正常。

虚拟机I/O出错很有可能是由于其相关的组件有问题，可以通过vsan.vm_object_info脚本来检查对象信息，它会显示出对象具体存在的问题并进行修复。也有可能是主机进入维护模式引起的，这时可以退出维护模式以进行修复。

性能问题同样值得关注，比如磁盘组离线导致虚拟机出错。一般性能出问题，有可能是CPU和内存性能不够也有可能与驱动器有关，硬盘是否兼容也要考虑到。

为防止DataStore空间耗尽，在它达到70%临界值的时候，就该计划扩容分配加主机、磁盘组或硬盘。

Troubleshooting Tools

ESXICLI Commands

上图列出是与esxcli相关的一些命令，可以在主机本地shell或者通过ssh远程连接到主机使用。这些命令并不需要强记，只要输入esxcli就会列出后续的子命令列表，如下图是使用esxcli storage后的帮助列表。

Useful Log Files

日志文件是最常用的辅助手段之一，推荐大家关注vobd.log、vmkernerl.log、vmkwarning.log、clomd.log这个四个日志文件。这些日志文件可以配合python脚本来使用。

上图的vsanDiskFaultInjection.pyc脚本是用来模拟vSAN集群出现问题后的情况，通过 —help列出相关的帮助信息，比如 -u是模拟硬盘的热拔出。

这是具体的执行命令，-d指明了要拔出的设备。

命令执行完之后在日志中就展示出了错误信息。

设备重新上线后，日志中的信息会进行更新，可以看到下方已经显示online了。

ESXCLI Namespaces in vSAN

最后我们通过一个具体的例子来演示下如何使用esxcli相关的命令。假如集群中的某台服务器的系统损坏，但是硬盘没有问题还保存着vSAN的数据，这时我们要做的是对系统进行重装，重新加入到vSAN集群中。那么如何加入呢，其实可以通过esxcli vsan命令来完成。

在vSAN集群的其他正常主机上运行 esxcli vsan cluster get命令得到当前集群的信息，这里有一个关键的条目——集群的UUID（图中红色标识的）。

获取到UUID之后，就可以在新装主机上执行esxcli vsan cluster join -u “UUID”命令加入到集群中，然后在当前主机上使用esxcli vsan cluster get就会看到它已经正常加入到集群中了。