• vSan是什么:

vsan是一种基于软件的分布式存储解决方案，其之间构架在hypervisior中，支持VMware vsphere的所有需要共享存储的特性。

• 为什么要使用vSan：

在企业，最重要的就是数据，而承载数据的设备就是存储设备，企业的存储设备一般都是由多块硬盘和RAID卡组成，通过 RAID 卡可以将多个磁盘组成逻辑的阵列，使得数据分散保存在多个磁盘中，实现高效的读写，实现冗余，避免单个磁盘故障引起的数据丢失。

其中，RAID常用的配置模式有两种：RAID1和RAID5。

RAID1的安全性能在所有的RAID配置中最高，可以保证数据不丢失，读写性能与单个磁盘的读写性能没有区别，但是它的磁盘利用率很低，只有50%。

RAID5的读的性能最好，写的性能低于单个磁盘的性能，适合多读少写的环境。安全性能RAID5次于RAID1，但高于其他配置方式。磁盘的利用率则高于RAID1，成本也比RAID1低。

所以，RAID1适合于存放重要数据，RAID5是一种存储性能、数据安全和存储成本兼顾的方案。这两种配置方式现在依然有许多公司在使用。

但是现在这种配置方式有许多的问题暴露了出来：

（1） 无法平滑按照业务的需求进行容量和性能升级

（2） 配置复杂，学习成本高，并且容易出现误操作。

（3） 无法区分服务

（4） 读写速度不够高

为了解决上述的问题，现有的最好方案就是vSan，也就是软件定义数据中心

• vSan：

- （1）服务器内部的连接

X86 服务器的架构决定了每个服务器必须有 RAID 卡才能使用硬盘，多块硬盘使用 RAID 卡汇聚到一起再和主板连接。

而在每个 vSAN 服务器内，至少需要配置一块 SSD + 一块 HDD，HDD
用于存储容量，SSD 只用于读写缓存。

在 RAID 卡选择上，建议使用支持直通模式（Pass Through）的 RAID 卡。在这种模式下更换硬盘、新增硬盘会非常方便（而如果配置 RAID 来供 vSAN 使用，则很多时候需要重启主机进入 BIOS 来配置）。

SSD 70%的容量用于读缓存，30%的容量用于写缓存。默认所有写的数据会被先行放在 SSD 中以减少写延迟，通过一些机制将这些数据逐渐写入到 HDD 中。在从 vSAN 读数据的时候，vSAN有一套算法来决定哪些数据为热点数据，然后预先缓存到 SSD 加快读取速度。

所以，通常也不建议使用 RAID 卡自带的读写缓存，因为 vSAN 已经有很优化的读写缓存加速了。

但是，在这里需要格外注意的是
vSAN 要求 SSD、HDD、IO Controller必须在 vSAN 兼容列表内，否则会出现不稳定等情况。

（2）服务器之间的连接

vsan有两种配置，两种需要不一样的连接配置。

全闪存架构vsan：

在全闪存架构中，闪存设备被分成了两类：一种是持久快速的闪存设备用于写Cache，另一种是空间较大而且相对廉价的闪存设备作为容量设备。在这种架构中，由于直接从容量层的闪存设备读数据会有更好的性能，因此100%的Cache层容量会被用于写cache。然而，为了尽量延长容量层闪存设备的使用周期，多数的需要写入会被置放于cache层，只有当需要写入到容量层时才会将数据写入容量层的闪存设备。

这种架构的性能更好，能够为各种工作负载提供更为可靠、强大的性能，但对网络的要求也会更高，它要求专用万兆网络网络，不支持千兆网络。

混合架构vSan：

cache算法会最大化的保证整个vSAN群集的读和写的性能。70%的可用cache会被分配用于存储有频繁读操作的磁盘块，尽量减少读操作发生在低速的普通磁盘上。另外30%的可用cache会被分配用于写操作，为了最大化磁盘性能，会尽可能地将多个写操作合并后再写入磁盘。

这种架构性价比更高，相对全闪存更为便宜，性能也相对还行。对网络的要求也会低一些，有专用千兆网络即可。

（3） 故障域：

主机：

vSphere提供了 HA 功能，保证单台主机故障后业务可以在其他主机上运行，这里故障的单位是“主机”，vSAN 也继承了这一设定（也很合理，因为主机也需要硬件维护，在维护的时候，一台主机能提供的所有存储资源都会下线）。

同一个虚拟机的同一份数据，必须保存在不同主机上。

结合上面的架构和 vSAN 的网络架构，假如一台主机心跳检测出现问题怎么办？（脑裂）

这时候需要有个仲裁机制保证同时只有一份数据是活动且是最新的，否则会造成冲突。

于是在上图的架构中，为每份数据再创建一个仲裁文件，保存在第三台主机中。

这便是 vSAN 最简单的架构，此架构允许一台主机故障，当然一台主机上的任意硬件坏掉也是允许的，只要故障发生在一台主机内。

下图便是 vSAN 故障域的一个简单示意。vSAN 中有个词叫 FTT （Fault
to Tolerance），意为最大允许同时故障多少台主机。FTT 决定的是虚拟机数据保护级别，也决定了一个集群所需的最小数量，一个集群中主机数量>=2N+1，N=FTT的值。

• 为什么 FTT=2，需要5台以上的主机

曾有人质疑：“请解释vSAN三副本(FTT=2，也即最多允许2台主机出故障），为什么需要5台以上的主机？我们需要的不只是官方要求（官方文档中，允许最少主机数量=2n+1，n代表最多允许故障的主机数量），还需要知道具体的设计原理。“

其实这样做主要是为了防止脑裂。假设脑裂后分成两个断开的子集群，如果要保证某个子集群接管数据服务，则该子集群的主机数必须大于原集群主机数的50%。这也表明，主机的最小数量一定是一个奇数。

通俗来讲，四台主机不能处理两台主机出错，因为可能会出现脑裂。比如有四台主机A、B、C、D。如果出现网络分区，A和B不能联系C和D。这时外界看来只是两台主机出现故障，按照FTT=2的要求必须允许读写继续进行。两边都有两台主机，所以两边都觉得自己可以进行读写，这样就会造成两边的数据不一致（俗称脑裂）。解决脑裂的办法是必须要求能接管读写的子集群的主机数量大于原集群总数量的50%。集群主机总数是奇数，这样就不可能出现两个子集群都满足条件的情况了。

• 为什么FTT=3，需要7台以上的主机

用户又问：“如果最多允许3台主机出故障，那么需要3+1台主机做副本节点，再加1台主机做见证（也即仲裁）节点，总数5台主机不就可以了吗，为何需要7台主机？“

之后我陷入了长长的思考，这使我想到为何不可以是2n-1，或者2n-3。我觉得可以总结成：假设n表示最多允许n台主机出故障，如果n+1台主机都放副本数据，这只能保证数据不丢失。而对于企业级存储而言，数据不丢失只是最低限度，除此之外，还需要保证数据的持续可访问，即HA。

磁盘：

上面提到每台主机需要 RAID 卡将多个硬盘连接起来，也需要至少一个 SSD 和一个 HDD。SSD 只做读写缓存，从经济的角度看，不可能每个 HDD 都配置一块 SSD，需要多个 HDD 共享一块 SSD的资源

在 vSAN 中，有了磁盘组这一概念，磁盘组是个逻辑的组，用于让多块 HDD 共享一个 SSD。

vSAN 规定每个磁盘组最少需要一块SSD+一块HDD，最多一块+7块HDD。每台主机不能多于 5 个磁盘组

让多块 HDD 共享一个 SSD 虽然节约成本，但也有一定风险，比如万一 SSD 故障，整个磁盘组的数据均会处于无法访问的情况，因此一般建议使用多个磁盘组分散数据，减少此种故障带来的影响。

比如磁盘组一可以由一块400G SSD + 8块800G HHD组成

磁盘组二可以由一块200G SSD + 4块800G HHD组成

磁盘组一的SSD故障，vSan会损失3.2T容量

磁盘组二的SSD故障，Vsan会损失1.6T容量

• （4）区分服务

对于传统存储而言，服务的区分是存储卷级别的。一个存储卷的底层使用 RAID 10，上层业务获得的存储资源便是 RAID 10的保护级别和性能；一个存储卷的底层使用 RAID 5，上层业务获得的存储资源便是 RAID 5 的保护级别和性能。

vSan可以让你给不同的虚拟机设定不同的保护等级去保障虚拟机。

假如一台虚拟机上跑的服务并不那么重要，我们可以给它设置储存策略为：

   FTT=1，不预留缓存，限制IOPS为100

而另一台虚拟机上运行着十分重要的服务，需要保证其服务不间断，数据不丢失，我们可以设置存储策略为：

   FTT=2，预留10%的SSD缓存，不限制IOPS

这样我们更精准的划分资源，为不重要的服务减少资源，用以给更重要的服务增加资源，让其获得更好的服务。

• vCentr6.7安装vSan集群要求
  

参考文章
https://new.qq.com/omn/20180717/20180717G0AUBL.html
https://blog.csdn.net/yjk13703623757/article/details/80786090
https://blog.csdn.net/weixin_33810006/article/details/92143861