在数据中心中,存储系统是管理员与IT部门最头痛的环节。因为历史的原因,五花八门的存储系统形成了一个又一个的信息孤岛(Silo),它们各自形成独立的HA与弹性设计,互不通用的监控系统与界面。
有鉴于此,业界近些年的趋势开始推出统一存储(Unified Storage)产品来试图解决存储过度多样化而造成的管理与使用效率低下的问题(如之前讲过的SDS解决方案ViPR/CoprHD也可以看作一种纯软件的统一存储的解决方案)。
Ceph (Technology - Ceph)就是这样一款SDS软件解决方案。它主要解决四大存储问题:
(1)可扩展的分布式块存储(Scalable and Distributed Block Storage);
(2)可扩展的分布式文件存储(Scalable and Distributed File Storage);
(3)可扩展的分布式对象存储(Scalable and Distributed Object Storage);
(4)可扩展的、用于管理以上异构存储的控制面板(Scalable Control Panel)。
Ceph的架构如图1所示,RADOSGW、RBD与CEPH FS模块分别对应客户端提供对象存储、块存储与文件存储设备接口。而以上三者的底层则是RADOS对象存储系统。
而RADOS本身还依赖于LinuxFS而构建,因此完整的Ceph架构如图2所示。
基于Ceph的客户端(如VM)为了完成一次磁盘块写(Block-Write)操作,需要五步,如图3所示。
如果比较商业化分布式软件块存储ScaleIO解决方案,从VM到磁盘则只需要三步,如图4所示。那么,节省掉的两步是否意味着性能上的大幅度提升呢?笔者的EMC同事们做了相应的性能测试(Benchmarking)来定量分析。
图1:Ceph架构(逻辑)示意图
图2:Ceph的完整架构(含LinuxFS)示意图
图3:Ceph的块存储操作流
图4:ScaleIO的块存储操作流
首先,为了确保测试的公平性,Ceph与ScaleIO使用相同的硬件环境(服务器、磁盘组合、网络等)以及逻辑配置(70%读与30%写;2×800GB SSD + 12×1TB HDD)。块存储测试的结果主要从两个维度考察:IOPS(I/O Per Second)与延迟(Latency),分别如图5与图6所示。
图5: Ceph与ScaleIO性能测试:IOPS
从图1中的IOPS性能测试结果可以清晰看出在同样SSD(固态硬盘)配置条件下ScaleIO的IOPS吞吐率超过了30万,而Ceph只有4万多。同样,在系统延迟测试中,ScaleIO的延迟只有Ceph的1/20(见图1)。导致如此大的差异的结果大抵是Ceph的所谓的通用、统一架构设计中不得不多出来的额外的模块造成的整体性能下降!
最后,我们再来看一下Ceph与ScaleIO的系统资源占用与性能的整体比较,如下表所示。假设两个系统的设计目标都是100TB实际可用的存储空间,为了实现这一目标,Ceph比ScaleIO需要多用43%的存储服务器与应用服务器;多29%的原始存储;平均每TB存储的造价高出34%;IOPS则只能达到后者的1/6弱。
表5-2 Ceph与ScaleIO系统资源占用与性能比较
Ceph | ScaleIO | Difference | |
Storage Servers+App | 23(12+11) | 13(8+5) | (43%) |
IOPS | 134,367 | 880,000 | 555% |
Total Raw Storage | 300TB | 213TB | (29%) |
$$/Usable TB | $5,982.80 | $3,952.70 | (34%) |
图6:Ceph与ScaleIO性能测试:延迟
关于Ceph与ScaleIO的比较,我们并不是要表达商业化的ScaleIO产品比开源的Ceph更快更好,而是要阐明一个问题:通用化的,如同瑞士军刀一样的系统必然到处都存在着trade-off或妥协,好比中国的谚语故事以彼之矛攻彼之盾,在现实世界不可能实现一个样样最优的系统,这也是为什么专用的、为实现单一目标而设计的系统依然比比皆是,而且在完成某一特定任务时,专用系统或工具往往更能胜任(换言之,更高的性价比,如下图所示)。
图:通用工具或系统vs.专用工具或系统