0x01 前言
VMware的vSAN既可以为自身提供存储空间，也可以对外部提供iSCSI，是一种可靠的，可以替代外部存储的一种解决方案。因为vSAN每个磁盘组都有独立缓存，而且可以组建多站点实现更高级的高可用架构，还能避免外部存储因为网络设备或线缆的问题导致IO异常，在实际使用中我更倾向于使用vSAN。
从费用层面来看，其实vSAN和一般的外部存储的费用相差无几，因为vSAN需要的硬件设备更高，比如缓存层需要使用写密集SSD或NVMe SSD，而且是每个磁盘组一块。还有其他的一些细节，在这里做个记录，但我一直使用Dell的设备，所以文章里的一部分内容只针对Dell的硬件。
0x02 网络设备
针对vSAN的网络，建议与业务网络相隔离，如果业务数据对带宽的要求不高，则可以使用VLAN隔离，用同一台交换机承载。
在正常使用中的vSAN流量其实不大，根据vSAN配置的不同，在数据重平衡、重建或者迁移时会产生大流量，建议使用10G端口及交换机，该交换机还必须要支持巨型帧，将MTU设为9000为好:
网络层面则没有特别的要求，如果可以，建议使用Cat6a替代光线。在实际使用中我发现光模块存在一定的故障率，毕竟多了一个部件，使用网线也是个不错的选择。但使用电口的万兆交换机也不便宜，整体算下来与使用光模块+光线的方案并没有便宜多少，甚至价格持平。
最后建议部署zabbix监控交换机各个端口的状态，需要关注错误率，同时需要关注各个主机vSAN端口的丢包率，这都是影响vSAN性能的重要因素：
但有时候不一定是硬件层面导致的，也有可能是使用了逻辑交换机，同时逻辑交换机中有QOS设定而出现丢包的问题，这在NSX-T中需要进一步关注。
网卡则建议使用intel X550 T2双万兆电口网卡或X520 DA2双万兆光线网卡。这两块都是单卡双口的，如果对高可用有要求，建议选购单卡单口的网卡2块，同时接入堆叠的交换机。逻辑交换机可以实现冗余，如果不是必要，建议不要配置lag，一旦出现问题会很难处理，只需要保证各个节点的VLAN id一致即可。
0x03 直通卡
直通卡，也就是HBA卡，vSAN环境中不能使用阵列卡。13G的一些阵列卡支持将SSD或HDD设为直通模式，但这不是真正意义上的直通，也不被vSAN所支持，而且使用非HBA卡的情况下，队列深度只有228。以下是PERC H330 Mini阵列卡：
作为比较，Dell HBA330 Mini的队列深度是：9548：
衡量存储性能的一个指标是IOPS，其中包含顺序和随机读写，而队列深度是影响IO性能很重要的一个因素。200多的队列深度会极大地限制IO性能，经过测试，只能达到30m/s的读速度，写入速度惨不忍睹。
针对Dell 13G或更新的服务器，需要使用HBA 330 mini直通卡，相关信息如下：
如果使用其他厂商的硬件，建议使用VMware的兼容性查询网站作进一步确认：
然后确认支持的vSAN版本与可组建的类型：
0x04 SSD和磁盘
无论在混合集群还是全闪存集群中，缓存层必须使用高性能的写密集SSD，相对于读密集SSD，它的价格要高出不少。当然，使用读密集的SSD也不是不行，一般情况下是很难跑满缓存层IO性能的，但需要注意缓存层的容量。
组建全闪存集群的时候可以启用去重和压缩功能，能极大地提高存储空间的可用率。同时，在全闪存集群中不会启用读缓存，所有缓存盘都是写缓存；对于混合集群则是读写3/7分。一个磁盘组中最大缓存容量为600G，但可以使用多个SSD提供缓存，总容量接近600G即可，超过也不会使用。
在日常使用中会遇到SATA、SAS和PCIe接口的存储设备，有些新的服务器的背板还支持NVMe协议，而这些设备都有着不同的队列深度，从而对整体的IO性能产生影响。以下是SATA接口的SSD：
naa开头的都是SATA接口的SSD，可以看到队列深度只有32；而下面的是PCIe接口的NVMe SSD，队列深度为4092。观察这些参数和实际实践中发现所有的IO压力都由缓存层撑住，另外得益于同一个磁盘组内的容量层SSD比较多，整体性能还可以接受。
以下是SAS接口的HDD：
可以看到SAS接口的磁盘有254个队列深度，其中有一块块是SSD，也是SAS接口。IO性能从实际的使用中发现比上图中的方案要好，因为数据可以很快地从缓存层回写到容量层，在某些情况下会明显优于使用SATA接口的存储设备。
我建议在生产环节中使用全SAS接口的磁盘或SSD作为容量层，根据资金的多少确定使用SAS接口还是PCIe接口的SSD作为缓存层。我更倾向于全部都适用SAS接口，且使用两块240G的读密集SSD作为缓存层，使用3至5块1T 10k SAS的HDD作为容量层，这已经可以应付绝大部分的使用场景。
0x05 注意事项
因为vSAN是一个集群，最少需要3个节点，而且默认使用Raid1进行冗余，通过设置策略可以调整为Raid5或Raid6甚至不冗余：
还可以实现多站点冗余，这个是更为高级的功能。
既然实现了软阵列，那么就涉及到数据恢复的问题。比如在一个拥有5个节点的集群里，需要根据实际情况至少预留1个节点的存储空间，因为集群中某个节点崩溃而出现数据恢复的时候会需要额外的空间进行数据的写入。
至于需要预留多少个节点的存储空间，这需要提前预估，同时应为不同虚拟机可能使用不同的容错策略，所以得根据自身的实际情况进行预估。我一般在5个节点的集群里会预留1个节点的空间，而再往上则需要预留2～4个节点，针对混合集群，需要预留更多的空间。如果vSAN预测到空间不足，会有相应的提示。
切记！千万不能完全用完vSAN的存储空间，超过70%就需要注意了，必要时可以往容量层加磁盘。
另一个问题是关于缓存层的，因为缓存层容量有限，无论是全闪存集群还是混合集群，都需要控制重新同步写入的速度：
这个重新同步不仅在节点故障后会自动同步，还会在修改存储策略后启动，它默认是不受限制的，会给缓存层和容量层带来极大的压力。因为默认的没有限制，数据又是跨机器同步，因为很快会将缓存层写满，从而影响整个vSAN集群。
类推下，一些读写IO极高的虚拟机也需要通过策略控制IOPS，避免因为几台虚拟机而影响整套集群：
最后建议使用vCloud配合vSAN使用，可以提高使用效率。如果需要将vSAN对外提供iSCSI服务，务必要控制好IOPS、加大缓存层并采用性能更好的存储设备作为容量层。
0x06 结语
简单来说，vSAN要想稳，网络、HBA卡和存储设备都需要再三确认，尤其是网络，非常容易导致节点离线和被隔离。
