超融合方案分析系列（2）：VSAN的超融合方案分析
超融合方案分析系列（2）：VSAN的超融合方案分析
超融合分析系列：
VSAN今年已经是6.6版本了。熟悉VSAN的朋友肯定知道VSAN历史，VSAN在这么短的时间发展这么迅猛，除了强大的投入外，最重要是有一个好的平台（老爹）VMware虚拟化，我们这边也简单回顾一下：
VSAN是VMware SDS战略的核心组件，2013年发布试用板。接下来商用版本的时间表如下：
版本 | 平台版本 | 发布时间 | 关键特性 |
|---|---|---|---|
VSAN1.0 | vSphere5.5 | 2014年3月 | 最大集群支持32个节点支持2-4个副本SSD做cache基于VM的策略管理 |
VSAN6.0 | vSphere6.0 | 2015年3月 | 支持全闪存最大支持64个节点支持柜机安全支持JBOD快照和克隆 |
VSAN6.1 | vSphere6.1 | 2015年9月 | 支持Oracle RAC和WSFC集群支持硬件数据校验和加密支持2节点的分支机构ROBO支持NVMe和UltraDIMM支持容灾PRO>=5min |
VSAN6.2 | vSphere6.2 | 2016年3月 | 支持IPv6软件Checksum支持去重压缩（仅用在全闪存场景）支持ErasureCode（仅用在全闪存场景）存储QoS |
VSAN6.5 | vSphere6.5 | 2016年11月 | 支持ISCSI接物理节点节点直连方案支持512e |
VSAN6.6 | vSphere6.5u | 2017年4月 | 支持单播支持数据加密保护慢盘检测与处理基于大数据的VSAN使用优化指南 |
- 最大集群支持32个节点
- 支持2-4个副本
- SSD做cache
- 基于VM的策略管理
VSAN6.0vSphere6.02015年3月
- 支持全闪存
- 最大支持64个节点
- 支持柜机安全
- 支持JBOD
- 快照和克隆
VSAN6.1vSphere6.12015年9月
- 支持Oracle RAC和WSFC集群
- 支持硬件数据校验和加密
- 支持2节点的分支机构ROBO
- 支持NVMe和UltraDIMM
- 支持容灾PRO>=5min
VSAN6.2vSphere6.22016年3月
- 支持IPv6
- 软件Checksum
- 支持去重压缩（仅用在全闪存场景）
- 支持ErasureCode（仅用在全闪存场景）
- 存储QoS
VSAN6.5vSphere6.52016年11月
- 支持ISCSI接物理节点
- 节点直连方案
- 支持512e
VSAN6.6vSphere6.5u2017年4月
- 支持单播
- 支持数据加密保护
- 慢盘检测与处理
- 基于大数据的VSAN使用优化指南
VSAN经过这短短的3年，可谓是飞速发展，我今天要谈的是VSAN的方案，重点还是在硬件上。
VSAN本身是VMware软件，它自己不提供超融合方案，对外是通过硬件合作伙伴来推出VSAN ready node或者VSAN灵活解决方案。
这两种方案的区别是前者是经过整机认证，有完整的性能与兼容性测试，风险较低，而第二种，是部件测试，具体点说，整机经过了VMware 虚拟化ESXi的认证后，如果要灵活部署VSAN，那么需要IO控制器（Raid卡）、SSD、HDD 这三个部件均经过严格兼容性测试。同时官方提供最佳实践指南给大家。
考虑VSAN的灵活方案在经过整机满足ESXi认证、部件满足VSAN认证的基础上，除了更多的CPU和内存外，还有以下几个方面需要考虑：
1、 SSD和HDD的配比关系（最大1:1，最小1:7，容量至少为虚拟机占用容量的10%）
2、 OS启动介质方案：单SD卡、双SD卡（主板组raid1）、单SATADOM、单SSD盘或者HDD盘。这几种方案都是在VSAN ready node中可以查到。
3、 磁盘控制器方案：每个Group配置一个raid卡（推荐），多个相同的Group配置在一个raid卡上（raid卡不支持SASexpender模式）
关于第一点不再展开，大量VSAN资料都有介绍，如果后面有机会我再详细介绍下第三条，我这里重点谈的是第二点：
为什么会推荐OS采用单盘模式导致可靠性差或者采用SD卡组raid1这种可维护性差的方案，原因是VSAN本身的限制：
在https://kb.vmware/com/kb/2135390这篇文档中有如下限制：
也就是说，如果2个OS盘组raid1后和至少一组数据盘放在一个raid卡上，那么最坏情况下降导致数据丢失。最关键是VMware官方已经不支持这种方案。本来采用SD卡方案是一个低成本方案，较低容量的SD卡相比普通的磁盘，价格还是要低不少，最关键是省掉了一张物理raid卡，整体方案的价格也相比来说更低一些。这种方案用在小规模数据中心也未尝不可。
但是我们可以想象以下，在一个大型的金融数据中心，100台上，1000台服务器，均是这种SD卡的方案，在SD卡故障后，需要迁移VM、下电节点、拆开机箱、更换SD、重新部署ESXi、再加入集群，这个过程将不可想象，尤其是在电子产品的生命周期末期，根据盆浴曲线理论，故障率几乎直线上升，减掉一个节点，带来的是集群的可靠性的降低，在短时间无法快速恢复，将导致集群的故障。这种方案是不可接受的。
所幸的是硬件合作伙伴又牛逼了一把，支持多个raid卡方案，原来是1个的，改支持2个，把OS盘独立放在一个raid卡上。顺利的解决了这个问题。带来就是成本的上升和硬件方案的调整，当然VSAN目前的市场地位，完全能让硬件厂家为了VSAN软件的约束来做硬件的重新设计，也能让客户心甘情愿为这个多余的raid卡掏钱。
VSAN的资料可能是市面上超融合产品种最多的一个，对raid卡问题也有很多资料提到过。我在做VSAN方案时多次遇到raid卡问题，客户不理解、销售也不理解，这里重新解读一下，也算一吐出来为快，希望VSAN能早日解决这个问题，如果有错误，请大家指正，谢谢。