每年年底和同事聊天时候都会讨论这一年遇到的奇葩故障，这次也不例外。想想这几年处理过或者看过的vSAN故障怎么也得好几千个了，其中真的有一些比较奇葩的vSAN硬件配置错误。虽然现在回想起来都比较有意思，但是处理故障时候真的是吃惊到下巴都掉了下来。(画外音：也不得不说vSAN还是很皮实的，有些用户就在这种非官方支持的配置下跑了几年的生产业务而平安无事)。
驱动固件不在兼容列表
惊艳指数：🌟
平时最常见到的就是驱动固件不在兼容列表了，所以惊艳指数只有一颗星。虽然这个常见问题从vSAN发布以来一直到现在依旧在发生，但是在2018年可以很明显的感觉到由于用户维护水平的提高以及vSAN健康检查工具的完善，这类的问题发生的频率已经明显降低。还清楚的记得头几年处理过一个故障，客户的使用的驱动/固件，不仅在VMware和硬件厂商的官网上找不到，连google都搜不到。后来客户说这是硬件厂商给客户提供的是硬件厂商内部的debug版本的驱动/固件...debug版本...debug...
这里再次需要说明下vSAN的硬件兼容测试的流程：为了修复已知问题，硬件厂商会发布新版本的驱动/固件，然后按照vSAN的统一的兼容性测试的流程进行测试，并且把结果反馈给VMware，VMware对结果进行确认后会更新到HCL网站。
下面是用户经常问我的问题，我把答案就列出来吧...
- 为什么驱动和固件老有问题?
除了一小部分inbox驱动，VMware不发布任何硬件驱动，更不发布硬件固件...其实你问我的这个问题我也一直想问...
- 为什么HCL一直在更新?
硬件厂商会在新的版本驱动和固件修复已知问题，发布出来后如果经过vSAN兼容性测试就可以更新到在HCL网站上。VMware无法控制硬件厂商发布驱动/固件的频率，只能确保每一个版本驱动/固件都通过兼容性测试。
- 为什么经过验证的驱动/固件还有问题?是不是VMware兼容性测试质量不过关?
这个问题大概有几个方面可以回答：首先是兼容性测试的方法无法完全模拟出每个用户的实际生产模式。兼容性测试的方案是统一的，但是每个真实用户的业务类型，使用特点都不一样。因此非常有可能在实际使用过程中触发新的驱动/固件相关的问题。其次就是做兼容性测试时候采样的范围，硬件厂商无法提供大量的测试样本，比如让硬件厂商提供100台主机进行兼容性测试明显是不现实的，人力和财力都无法满足。最后就是硬件的质量的控制，像一些比较大的国际厂商，基本上每批次的硬件质量都很稳定，所以运行起来也会比较稳定;但是有一些国内的硬件厂商，批次和批次之间的硬件质量水平都不一致，再加上有些做兼容性验证测试的硬件厂商工程师责任心问题，所以经常会出现比较恶心的事情。这真的不是说笑，而是客观存在的事实...
基于上面的描述，那么最稳妥的方法是什么呢?
最最最简单的方法就是根据vSAN健康检查的提示进行升级/降级。VMware要求使用的驱动和固件必须在HCL列表里，并且两者的搭配关系也必须符合在HCL的要求，并且非常强烈强烈强烈使用HCL里列出的最新的版本。
硬件不在兼容列表
惊艳指数：🌟🌟
这个很好理解，但是我还是见过一些比较有意思的案例：
- 使用家用台式机级别的SSD/HDD提供给vSAN使用：不可否认，这种情况下vSAN可以使用的，但是这些硬件的性能以及使用寿命都无法满足生产环境下的需要，尤其是作为缓存层的SSD，时刻进行大量的读写操作，这些负载不是非企业级的磁盘可以长时间承受的。
- 把容量层SSD作为缓存层SSD使用：这也是一个比较666的操作，有一些用户把仅能用于全闪环境下容量层磁盘的SSD当作混合模式的缓存层磁盘使用。实际上这两种不同用途的SSD的性能和使用寿命是完全不同的，因此如果把容量层的SSD用作缓存层的SSD后会经常遇到遇到一些性能相关的问题。
- 忘记带Cache模块的Raid卡：比如联想的M5210这块卡。我清楚记得在爱尔兰的时候被这块卡搞的死去活来：主机经常发生磁盘拥堵的问题，把能检查的地方都检查了一遍却找不到原因。后来发现客户使用的这块卡忘记安装了Cache模块。不安装Cache模块的话卡的队列深度只有260，然后安装了Cache模块后队列深度达到将近900。而且VMware只验证过了安装了Cache模块的M5210...后来客户解释说，他们在购买主机的时候忽略掉这个细节了...
- HBA330和H330，傻傻分不清楚：Dell针对vSAN推出一块叫做HBA330的Raid卡，稳定性非常好。但是比较有意思的是Dell有另外一个卡叫做H330(H330没有经过vSAN的兼容性测试)。有些用户为了省事习惯把HBA330叫做H330...后面的故事的你应该可以想象的到：客户想配置一个HBA330，于是说：“给我一个H330(HBA330)”。结果就是一个真的H330到了...
过小的缓存层磁盘
惊艳指数：🌟🌟🌟
关于缓存层磁盘与容量层磁盘的容量比，VMware的目前官方的介绍是按照使用容量的来计算的10%。但是根据经验，如果按照物理容量来计算的10%以上会更稳定，尤其是在业务高峰期时可以有效避免拥堵现象的发生。目前为止，我遇到过的最小的比例是不到1%，也就是说每个磁盘组20T的容量层磁盘配置了一个200G的缓存层的SSD。因此在业务繁忙期间根本无法承载过高的负载....
充满想象的底层Raid配置
惊艳指数：🌟🌟🌟🌟
根据vSAN的设计，vSAN会根据存储策略的不同设置来保护不同的对象。例如FTT=1可以容忍一个节点故障，FTT=2可以容忍两个节点故障。这些都是在vSAN软件层面上定义并且执行的。有一些用户也许是还停留在传统的硬件配置的影响下，于是乎出现来这类谜一般的配置：
- 两个SSD先做底层硬件Raid1，然后再作为缓存层磁盘使用...
- 多个HDD先做底层硬件Raid5，然后再作为容量层使用...
是嫌硬盘太便宜?还是觉得硬盘槽位太多?
这么土(lang)豪(fei)的使用方式既不是VMware支持的配置方式，也得不到任何额外的益处，还会增加排错的难度。
那么vSAN要求的配置方式是什么样子呢?大体流程如下：
- 确保使用硬件硬件/驱动/固件符合vSAN的HCL要求。
- 按照HCL要求使用Raid卡正确的模式：直通 或者 Raid
- 禁用掉Raid卡的写缓存(或者调整为100%读)
- 所有的磁盘按照HCL的要求进行配置：
- 直通模式的话就直接提供给ESXi使用
- Raid模式的话就每单个磁盘做为一个Raid0再提供给ESXi使用
没有SSD?我们有HDD啊!!
惊艳指数：🌟🌟🌟🌟🌟
前方预警：
vSAN配置大魔王来了!!!
vSAN配置大魔王来了!!!
vSAN配置大魔王来了!!!
上个月我的同事在检查一个日志的时候发现来这几年以来最厉害的配置...vSAN主机上根本没有配置缓存层SSD!没有SSD!没有SSD!
是的，你没有看错...客户使用的所有vSAN磁盘都是机械硬盘，然后把其中一块机械硬盘标示为SSD作为缓存层磁盘使用...而且这套系统客户已经用了很长时间，至于vSAN健康检查的报警嘛...直接忽略掉就好。这一波骚操作让我着实惊讶来好久才缓过神...真是艺高人胆大啊...
以上就是目前我总结的比较惊艳的vSAN硬件配置，我相信肯定还有一些案例疏漏了，以后随着想到随着更新进来。
我一直相信任何一个优秀的解决方案应该包括：高质量的产品+正确的使用方法+坚实技术支持保障，只有这3点全部满足，使用者才可以放心大胆的使用，也有时间去享受自己的生活。
