witness在vSan中作为见证组件其作用类似于WinServer中的仲裁磁盘，当Cluster中某一节点发生故障时，来判断该节点上的对象在哪一个新的节点上继续承载。此处需要强调的是，witness针对的是对象而不是host。以vmdk作为对象使用默认策略（stripe=1，FTT=1）为例，此时的至少需要三台host主机，分布如图所示：
此时我们看到除了wmdk有两个replicas之外，还有一个用于见证的witness，witness大小通常为2M左右，里面存放着对象的meta数据，当任意一个节点发生故障时，剩余节点仍然可以继续提供服务。但经常我们会发现创建完vSan后witness数量不止一个，这就要从witness的组件定义说起，witness按照组件定义可以分为三种：
1.primary witness，当主机节点数不满足storage police时，才会出现该witness。举例说明，当FTT=2时，按照要求此时至少需要5台host，当前环境中的host主机只有4台，这时就会出现primary witness，当环境中满足5台host后，primary witness就会消失。
2.secondary witness，当故障发生后剩余的节点会产生选举，确定出哪一个新的节点承载原有节点上的active对象，但每一个host主机上所承载的对象总数不会相同，此时的选举就处于一种不公平的状态，secondary witness就是为了避免该状态的产生，让每一个host主机上的对象数量相同（只是对象的数量，而不管对象的大小），需要注意的是，secondary witness是为了保证已经承载有对象组件的主机之间的组件数一致，不是群集中所有ESXi主机，结合上图得知esxi-01就不会产生witness组件。
3.tiebreaker witness，当进行完上述两步之后，为了保证总对象数量为奇数，此时会添加一个tiebreaker witness
上述三种witness可能两两同时出现，也有可能只出现一种，仍以第一张图的环境举例说明：
场景一：
FTT与stripe都是1，按正常情况每个raid0中应该只有1个对象，整个raid1为2个对象，但是在vSan6.0中每个对象的最大值为255G，所以在此处会将wmdk强行分割成2个对象，多余的1G被meta数据融合，于是整个raid1中就存在4个对象。此时要求至少需要3个节点，当前环境有4个host主机，所以primary witness就不会出现，而每个host上都只有一个对象，secondary witness也不会出现，所以此时只会看到1个tiebreaker witness。
场景二：
首先节点数满足要求，其次wmdk被分割成了3个对象，从raid0上能看出esxi60与esxi80上各有2个对象，esxi50和esxi70上只有一个对象，所以坐在esxi50和esxi70上各生成一个secondary witness，从而使每个host上的对象数量一致，然后又因为此时的对象总数是8个，所以还会再生成一个tiebreaker witness对象用于保证总数为奇数，此时看到的witness总数就为3个。
最后说一下磁盘UUID的作用，以小于255G的vmdk，FTT=1为例，此时生成vmdk的对象数量为2个，为了避免这2个对象被分到同一节点引发单点故障，所以会比对uuid，将他们分配到不同的节点。