超融合方案分析系列（8）SmartX超融合方案分析
超融合方案分析系列（8）SmartX超融合方案分析
引 言
作者是国内研究超融合相当早的专家，有非常强的理论基础和实战经验。上几篇分析文章，对nutanix/VSAN/深信服/H3C/EMC等厂家的深入分析，引起了业界很大的反响。
专家不辞辛苦，坚持高质量输出，被专家的专业和敬业精神感动。为专家点赞！
“以梦为马，不负韶华”，送给在技术道路上坚持的同学。也希望喜欢的同学多多转发和点赞！
以下是超融合分析系列前面几篇，已经阅读过的同学可以跳过。 超融合概述
概 述
最近有点忙，更有点懒，思想上的懒比行为上的懒更可怕。本来上周就要发出来的SmartX分析，拖到今天，实在顶不住了，把压箱底的材料都找出来再学习了一遍。有网友好像知道我要分析SmartX似得，居然询问SmartX的分析什么时候出来。惭愧，在这里向所有持续关注这个系列的网友说声对不起，我后面继续努力，多总结干货。
为什么要分析SmartX，其实我也说不清楚。第一次遇到这个产品是2015年底的一次项目POC。网上的材料很多，我就描述一些我知道的情况，当然也是从公开的信息中收集到的：
最新的一个消息是8月1日消息 超融合厂商SmartX宣布完成近亿元B轮融资，此轮融资由经纬创投领投。反正三个字，有钱了。
深入分析
2013年7月，SmartX公司成立，2015年3月，SmartX1.0版本问世。现在官网上的信息不多，当然最大的一个亮点是和联通沃云一起的超过2000节点24TB数据的超大性案例，而且是到Granter认可的最大超融合案例，在方案中我看到了几个亮点说明：
OpenStack 计算虚拟化与 Halo ZBS 部署于同一个物理节点，所有节点的硬盘通过ZBS池化成统一资源池
当然，作为技术方案分析，我对这点表示怀疑，依据如下：
第一：官网白皮书最大集群不超过255。
在SmartX 官网我们找到最新版的ZBS技术白皮书，里面清晰的写着：
既然核心的分布式存储ZBS最大集群支持255，那么也不存在2000台服务器组成一个资源池了：实话实说，大部分超融合厂家的规格到255节点单池规模也就足够了。再大的池，在硬件生命周期末期，同时坏三块硬盘（三个不同节点上的）也是很有可能的，这个时候即使是三副本也无能为力。毕竟传统SAN存储的故障域才48个盘。这255节点，按每节点6个硬盘计算，大概磁盘规模为255*6=1530，这个规模也算超大了。一般企业也没有这么大的规模。
第二：ZBS类似GFS的有元数据的方案，不适合超过大规模集群。
我们再看ZBS的架构，
红色部分是元数据服务，如果是元数据服务器，那么会有Meta和Chunk两种服务。独立的数据服务器，只有Chunk服务。
任何集群内的数据分配等都会广播给所有设备，元数据大小以及集群规模都是成反比的。换句话说元数据越大，集群规模越小，元数据越小，集群规模可以做到更大。业界有两种主流的集群管理方式，一种是集中式，一种是DHT方式，集中式元数据并不适合大集群方案，也没有看到ZBS有故障域的处理方式。集中式的元数据管理在IO初次写以及数据重构时（节点变化或者磁盘故障）对性能和可靠性影响严重。基本可以猜测沃云的超大方案应该是分成多个集群部署的。
现在我们再谈谈Cache的管理：
ZBS的Cache机制如下：
CacheManager 通过 2 级 LRU 链表来管理数据冷热程度。Inactive List 中记录了被访问过一次的数据块，Inactive List 按照被访问的先后顺序进行排序，最不经常被访问的数据会被从 cache 中移除。Active List 中记录了被访问过多次的数据块，Active List 同样按照被访问的先后顺序进行排序，最不经常被访问的数据，会转移到 Inactive List 中。
SSD空间没有读写缓存分开，相对来说比较简单，也没有刷盘机制。但是如果大量连续的写，超过Cache大小，将直接触发Active List到Inactive List Inactive List再刷盘的流程来挪空间，相比一般的IO写流程，从Active List就返回，性能将下降很多。
每家分布式存储都有自己的特点，技术白皮书只能看到一部分，有条件最好能搭建环境验证体会。前面谈的分布式存储的技术优点多，还是说说方案：
对网络要求：在SmartX halo 超融合一体化解决方案规格表中6种规格，默认要求2个万兆网口。而在网上找的KVM安装手册中描述：用于 SmartX ZBS 分布式存储集群内部数据交换使用，即集群中各 SCVM 之间的通信网络；存储网络必须使用 10GbE 交换网络。业务网络和管理网络可以随意选择。
最后谈谈SmartX部署方案，SmartX的部署方案和Nutanix完全类似：
在支持VMware方案时，要用到SATADOM，同时ZBS对ESXi是NFS协议，当然也支持VAAI存储加速功能，也经过了VMware官方认证。这点基本和nutanix类似。但是ZBS部署在KVM上时， SCVM 直接安装在物理主机上系统。
技术白皮书上有这么一段对VMware方案的描述：
SCVM 是运行在 VMware ESXi 上的一个虚拟机。和普通的虚拟机不同，这个虚拟机运行的是装有SmartX ZBS 的操作系统（SmartX OS），同时，需要将 VMware ESXi 的服务器上的存储磁盘，直通（Passthrough）给 SCVM，使得这些磁盘统一由 SmartX ZBS 负责管理。集群中多个 SCVM 通过万兆网络进行通信，组成了 SmartX ZBS 集群，并提供存储服务。
如果服务器不支持多个 IO 控制器或多个 RAID 卡，也可以选择将 VMware ESXi 安装在 SATADOM 上。 SATADOM 可以通过板载的SATA 控制器，直接为 ESXi 供存储服务，而不占用额外的 IO 控制器，或 RAID 卡。也就是说想提供VMware方案的可靠性，采用2个raid卡的硬件也是可以的，不过这样的服务器比较少。
前面谈联想是说过AIO-S方案就是基于SmartX的，无奈联想的牌太多了，HX系列、AIO-H、VSAN认证方案、Azure Stack认证方案，都在搞，AIO-S这个联想最先推出的超融合方案反而在市场上看不到了。SmartX是一家纯软件厂家，有自己的核心技术分布式存储，也基于KVM搞出了服务器虚拟化和云平台等解决方案，支持主流厂家的服务器，属于国内超融合或者分布式存储初创厂家中的佼佼者。不过参考国外的超融合存储初创公司的境况， SmartX是否可以考虑一家服务器大厂做合作伙伴，加强端到端的方案控制能力。是坚持到底还是找家大树乘凉，我们拭目以待。