1 传统集中式虚拟化的问题
传统虚拟化解决方案将计算服务器和存储服务器独立开来，采用集中式存储（SAN/NAS），这种结构是上世纪的遗留结构，缺陷日益凸显。这是其中的原因在于随着企业业务数据量的井喷，企业应用呈现出类似大型互联网应用的特点:
存储控制器扩展困难
早期的共享存储，性能瓶颈通常都在磁盘阵列上，通过添加磁盘向上升级的方式能一定程度解决瓶颈的问题，但随着磁盘数量的增加以及高速硬件 SSD 的出现，存储端的性能瓶颈转移到存储控制器，集中式存储控制器扩展困难，一般都是固定的双控或者四控，这种架构设计上的弊端是的集中存储无法发挥高速硬件设备的潜能，随着虚拟化平台下业务数据量的增长，最终导致存储端无法支撑上层业务的访问。
存储系统无法感知 VM
共享存储无法感知上层 VM 的负载，导致出现 I/O Blender 现象，即不同的 VM 间负载的混合，加剧了共享存储的访问压力。例如，上层 VM 出发的顺序 I/O 的访问请求，在通过 Hypervisor 调度后会与其他 VM 的 I/O 请求混合，使得原本顺序的 I/O 请求模式在共享存储端变得随机化，对机械磁盘极不友好。即便这种问题可以通过添加 SSD 缓解，但之前提到共享存储中控制器导致的的 SSD 不能充分发挥效用的问题，使得 I/O Blender 的影响无法根本避免。
VM I/O 延时风险
共享存储通过存储网络与服务器相连。VM 需要经过存储网络才能读写数据，这个与本地 I/O 仅通过总线访问物理盘的数据相比，延时大大增加。之前提到的增加物理盘向上升级的方式无法缩小 I/O 读写延时，不同服务器或者 VM 发出的 I/O 请求本质还是串行的。在非虚拟化的场景，连接存储网络的服务器是线性增加的，规模增加产生的并发延时可能不明显；但在虚拟化场景下，一个物理服务器上可能会运行十几个甚至上百个 VM， 这些成几何级数增长的 VM 并发访问共享存储会带来 I/O 延时的问题。
存储单点故障
虚拟化依赖底层的存储提供 VM 层面的高可用，但是共享存储本身存在单点故障的风险，存储控制器和磁盘阵列的错误都有可能造成存储不可用或者数据丢失。通用的解决办法就是购买维护多套共享存储，但这样极大的增加的成本及其管理的复杂性。
成本昂贵
共享存储都是由专有的硬件实现，成本造价高。同时考虑到扩展困难，用户通常在规划的时候需要预留出余量，无形中也提高了初次购买成本。
运维复杂
共享存储支撑下的虚拟化平台，运维管理需要面向多个平台，至少包括虚拟化平台、存储平台、备份平台等，运维负担重。此外，系统发生异常，管理员需要在不同的管理平台间切换排查错误，效率低下。

2 SmartX超融合存储计算虚拟化架构
相比分离式的计算存储虚拟化，超融合虚拟化，也称做Hyper-converged，在提供存储的同时，也提供计算能力，这不但大量减少了硬件和电力成本，也将计算放在离存储更近的地方，达到最优的性能。超融合架构通常采用了全分布式的组件，横向可扩展，不存在单点失效，数据能够自动恢复和备份，下图是超融合的虚拟化架构：

1) 无中心的系统架构
将计算和存储功能分布到每个节点中，去掉集中式存储，利用标准化硬件构建大规模的计算群集及海量的高性能存储。SmartX摒弃了传统的通过扩展磁盘柜扩展容量的方式，而是通过添加新的服务器节点同时获得存储容量和性能的水平扩展，扩展后的空间、容量和性能是可预估的，能极大帮助企业IT选择最合适的软硬件解决方案。SmartX每一次都可水平扩展：

SMARTX OS基于Linux的操作系统，提供ZBS分布式文件系统，Elf Compute KVM管理平台， Fisheye性能监控平台。
硬件包括：X86服务器、交换机等；
自动负载均衡
扩展节点后，SmartX会根据集群中各个服务器节点的负载和容量使用情况做负载均衡，以达到整个系统的负载均衡，避免单点过热的情况出现。
扩展无需暂停业务
水平扩展只需要将部署了SmartX的新节点和原有集群连接到同一网络，通过图形控制台或者命令将新节点添加到SmartX集群中即可，整个扩容过程不会影响任何服务，虚拟机无需停机。
即刻生效
节点被添加到集群，该新增节点的计算和存储资源会通过一轮“心跳”向集群汇报，集群系统的整体容量和性能也随之线性扩展，此后新节点的资源就会被SmartX接管。
2) 高性能分层存储
SmartX区别于传统存储架构的一大特点就是对SSD的合理使用。SmartX实现了智能Cache的技术，将热数据缓存在SSD里，加速数据读性能；同时使用Journal合并小的写操作来加速写性能。不同于传统的SAN和NAS—通常SSD容量的配比不能超过5%，SmartX支持用户根据业务的数据访问需求，自行配置SSD的大小和比例。
3) 基于弹性副本技术的数据高可用
ZBS通过软件实现了弹性副本的功能，该功能将副本分布在不同的服务器上，来提供数据冗余及对上层应用连续性在存储层面的支持。ZBS对每个虚拟存储盘支持1~3个不同的副本，因此用户可以根据业务需求灵活的制定业务所需要的副本数。
同一份数据的多个副本会分布到不同的物理服务器节点上，即便一个服务器节点损坏也不会影响数据的可用性和可靠性。系统会周期性的扫描系统中可用的数据块，一旦发现某个数据块的可靠性级别低于设定值，就会触发智能恢复。假定用户设定某个虚拟盘副本数为两份，系统会将虚拟盘切分成小的数据块（如图：D1、D2、D3），同一份数据会复制到两个不同的服务器上，假使某台服务器损坏（服务器3），由于整个集群仍旧有该虚拟盘的完整数据，可以确保数据的可用性。此外，数据副本数减少，ZBS会及时发现这一事件，并将数据恢复到其它健康的物理服务器（服务器1、服务器2），以确保两副本的数据可靠性。

服务器Server 3故

数据重构后
传统RAID重建时，经常导致存储系统不可用。不同于RAID重建机制，ZBS在恢复副本的时候，正常业务仍可正常运行，ZBS通过控制恢复流量所占的I/O带宽，确保业务性能不受大的影响。
4) 强大硬件兼容性
SmartX 超融合架构拥有两种部署模式，一是 SmartX Halo 一体机，包含SmartX OS软件和高密度服务器，二是将 SmartX OS 软件安装在符合硬件配置要求的x86 服务器上。
SmartX Halo 一体机为 SmartX OS 软件定制了硬件，是 SmartX 超融合平台最佳软硬件实践。硬件平台经过严格测试，是最快捷、最稳定的交付方式。 可减少硬件投入成本、机房空间和电力消耗。
如需将 SmartX OS 软件部署在其它通用 x86 服务器平台上，请参考 “SmartX 硬件配置及支持” 获得更为详细的信息。

5) 其它特性
SmartX基于通用的X86服务器，可以跟随者通用硬件的快速升级而得到性能提升和新功能加入，为用户节省更多的开支。
利用软件定义存储实现传统多款存储产品的功能，并且提供统一易用的接口，节省IT开支和机柜空间/电力使用的同时，使得IT更加的敏捷。
软件的灵活性使得私有云和公有云的存储可以更好的结合，例如软件可以将数据备份到云存储中去，提供灾难恢复，也可以跨数据中心提供虚拟机迁移和容灾等功能。
SmartX内置ELF Compute虚拟化计算平台，该虚拟化平台基于KVM，提供能弹性的虚拟化计算功能，支持基本的虚拟机管理、热迁移、重建等功能，满足绝大部分虚拟化计算场景的需求。
SmartX超融合架构也可结合Vmware Vsphere Esxi、Citrix Xenserver等服务器虚拟软件进行部署。