超融合真的完美吗?. 2019-01-03
1)新的信息孤岛
几乎所有的超融合方案都不支持数据中心中原有的外部存储,大多数企业也不可能在短期内更换整个数据中心基础设施,结果数据中心又分裂成两个彼此独立分散的基础设施孤岛。对于大的数据中心,出于不同业务需求和平衡考量,很有可能会同时部署不同的超融合架构,不同HCI之间无法整合和互操作,结果就是又多了几个新的信息孤岛。新的信息孤岛带来了资源利用效率和统一管理的问题。
2)性能一致性问题
数据中心中存储的性能至关重要,而且期望性能是可以预测并保持一致性的,包括延迟、IOPS和带宽,这一点尤其对核心业务系统很关键。对于超融合架构而言,这一点恰恰是很大的挑战。
原因主要有两点:
一是超融合架构“共享一切”。计算和存储会争抢CPU/内存/网络等物理资源,而且计算和存储又相互依赖,一旦一方资源需求骤升就是导致另一方资源枯竭,进而影响性能并在整个基础架构中产生涟漪效应。虽然可以采用cgroup或容器技术进行资源隔离限制,但和非超融合架构的效果还是不同的。
二是超融合架构“一切分布式和软件定义”,集群规模较大后,网络、硬盘、服务器发生故障的概率都会增大,数据重删/压缩/加密/纠删码等功能都用软件实现,故障的自修复和数据功能实现都会消耗一定的系统资源,导致性能下降和抖动。自修复的流控,数据功能旁路到硬件模块处理,这些方法会缓解性能一致性问题,但似乎又与超融合的理念相背离。
3)横向扩展之殃
超融合架构关键特征之一就是易于扩展,最小部署,按需扩容。超融合架构厂商宣称最大集群规模也差别很大,从数十到数千节点不等,通常从3节点起配。超融合中计算能力、存储性能和容量是同步扩容的,无法满足现实中单项能力的扩展,有些厂商还对扩容最小单元有要求,扩展灵活性会受到限制。集群达到一定规模后,系统架构复杂性就会非线性增加,集群管理变的更加困难,硬件故障和自修复发生的概率也会大大增加。因此,我们是不建议构建大集群的,如果业务允许尽量构建多个适当规模的较小集群,或者采用大集群中构建故障域或子资源池,光大是不行的。集群扩展还面临一个棘手问题,就是容量均衡。如果存储集群容量很大,均衡是一个非常漫长而痛苦的过程,同时还会对正常的业务负载产生较大的影响。
4)系统复杂性
超融合架构简化了IT架构,极大降低了数据中心设计的复杂性,实现了快速交付,并极大简化了运维管理。不过,这都是基于用户角度的,从产品研发角度而言,超融合实际上使得内部的软件复杂性更高了。前面我们已经阐述,超融合架构需要采用CVM虚拟机控制器,并且需要将主机物理设备透传给控制虚机,增加了部署配置管理的复杂性。计算和存储对硬件平台的要求都不同,融合后也会一定程度上增加兼容性验证的复杂性。超融合架构下,管理、计算、存储、高可用通常都需要配置独立的虚拟网络,网络配置也会更加复杂。同时,共享物理资源的分配、隔离、调度,这也是额外增加的复杂性。还有一点,如果出现故障,问题的跟踪调试和分析诊断也变得更加困难。
5)SSD分层存储
闪存SSD基本成为超融合架构中必不可少的元素,消除了计算和存储的巨大鸿沟,解决了I/O性能瓶颈问题,尤其是I/O随机读写能力。目前闪存的价格相对HDD磁盘还是要高于许多,迫于成本因素,全闪超融合方案应用仍然较少,多数应用以SSD混合存储配置为主,从而获得较高的性价比。通常情况下,我们假设热点数据占10-20%,配置相应比例的SSD存储,采用Cache加速或Tier分层模式将热点数据存储在SSD存储中,一旦热点数据超过预先设置阈值或触发迁移策略,则按相应淘汰算法将较冷数据迁移回HDD磁盘存储,从而期望在性能和容量方面达到整体平衡。看上去很完美是吧?SSD擅长的随机读写,带宽并不是它的强项,对于带宽型应用,SSD对性能并没有帮助。关于热点数据占比,这个并不好估计,如果SSD配置不足,性能会变得更差。假设应用场景合适并且SSD配置合理,情况又如何呢?SSD空间最终要被热点数据占满,就会触发数据迁移,这时HDD存储仍将成为I/O性能瓶颈,同时还要承担正常的I/O业务负载,整体性能就会出现降级和抖动。为了缓解这一问题,SSD Cache/Tier功能实现中,一方面会过滤掉顺序读写I/O,另一方面会把空间阈值设置较低,尽早进行数据迁移,同时选择系统空闲时间执行和流控。带来的负面效应是,SSD性能加速效果受限,物理设备效率发挥不充分。另外,SSD本身被写满时性能也会出现较大的波动。因此,SSD混合存储并非理想模式,实际中我们推荐根据应用场景采用全闪SSD或全磁盘HDD配置,从而获得一致性的性能表现。如果真的无法全用SSD,还有另外一种应用方式,同时创建一个全SSD和一个全HDD存储池,人为按照性能需求将虚拟机分配到不同存储池中。
6)企业级数据功能
目前在大多数超融合系统以及SDS系统都具备了核心的企业级功能,包括数据冗余、自动精简配置、快照、克隆、SSD Cache/Tier、数据自动重建、高可用/多路径等数据功能,有些甚至还提供了重复数据删除、数据加密、数据压缩等高级数据功能。然而,相对于高端存储系统,如果超融合架构要承载核心关键应用,还有很大的差距,包括但不限于QoS控制、数据保护、数据迁移、备份容灾、一致性的高性能。核心存储系统应该遵循RAS-P原则,先做好稳定可靠性,其次是企业数据功能完备性,最后才是高性能,这个顺序不能乱,光有高性能是不行的。比如Ceph,企业级数据功能列表多而全,功能规格参数非常诱人,但真正稳定而且能够实际生产部署应用的其实不多。目前,核心关键业务系统还不太敢往超融合架构上迁移,主要还是从非核心业务开始检验,毕竟超融合出现时间还比较短,需要更多的时间和实践验证RAS-P特性。但是,未来超融合必定是核心关键业务的主流架构。
7)物理环境应用
目前普遍公认的适合应用场景是桌面云、服务器虚拟化、OpenStack私有云、大数据分析等新型应用。理论上超融合系统可以适用于IT环境的所有应用类型,需要注意的是,超融合系统管理虚拟化环境,而更多的传统IT应用仍然运行在物理服务器和传统存储系统之上。我们可以乐观地认为没有哪一种应用程序不能被部署在超融合基础架构上,但是考虑到运行效率、硬件依赖性以及和虚拟化环境兼容性等因素,很多IT应用最好还是继续保持运行在物理硬件架构,比如数据库应用、实时控制系统以及大量遗留IT系统。
8)异构虚拟化环境
目前超融合方案通常是仅支持一种虚拟化环境,Nutanix可以支持多种虚拟化环境,但是对于一套超融合架构部署,实际上也仅支持一种虚拟化环境。每种虚拟化环境都有各自的优势,很多企业可能需要同时运行几种虚拟化环境,比如VMware、KVM、Hyper-V、XEN,因为超融合不支持异构虚拟化环境,需要部署多套超融合架构,这就是新的信息孤岛。客户非常希望看到支持异构虚拟化环境的超融合架构方案。
9)超融合数据共享
超融合架构采用软件定义存储替换传统的共享式存储解决了虚拟化存储问题,这里的SDS实际上主要是指ServerSAN,提供分布式块存储。然而无论是虚拟机还是物理机,实际IT应用都有着数据共享需求,需要分布式文件系统或NAS存储系统。这是目前超融合普遍缺失的,现实还是依赖外部独立部署的NAS或集群NAS存储系统,比如GlusterFS、ZFS。从技术架构和实现来说,一个SDS系统很好地统一支持Object/Block/File存储,这个非常难以实现的。比如Ceph,它的CephFS一直没有达到生产环境部署标准,更别提性能。因此,超融合架构中可以采用相同方式同时部署两套SDS存储,分别提供分布式块存储和文件系统文件共享存储,比如SSAN和GlusterFS,不必非得要求分布式统一存储。
10)全栈超融合架构
目前很多厂商都在推超融合架构方案,其中一部分是SDS厂商,一部分是虚拟化厂商,还有更多的是集成商,像VMware/Nutanix同时做SDS和虚拟化的厂商非常少。SDS和虚拟化是两个完全迥异的领域,而且技术门槛都非常高,一个厂商同时把这两块都做到很好是非常难的。两者都想做的厂商,无非是想控制成本、自主可控、扩大市场、融资好讲故事。对于初创公司,团队和资金非常有限,打造全栈超融合架构更是困难重重。正确的姿态可能是,确定战略方向重点做好一块,然后再找另一块做得好的厂商进行战略生态合作,强强联手打造有竞争力的超融合架构方式,无论从产品技术还是市场角度都是双赢的。