vSAN常见错误故障排错

内容来源：2018 年 8 月 7 日，VMware大中华区原厂高级技术讲师史峻在“VMware直播分享 第二期”进行《vSAN常见错误故障排错》演讲分享。IT 大咖说经主办方和演讲者审阅受权转载发布。

阅读字数：5264 | 14分钟阅读

嘉宾演讲视频回放：suo.im/4ZGVwM

摘要

本次演讲主要分享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就会看到它已经正常加入到集群中了。