狒话 · 2021年07月12日

Server如何SAN(中):SSD与网络

作者注:Server SAN是软件定义存储的一个分支,也是超融合架构的基石。2016年夏天,我以足球和篮球作比,由整体到局部探讨Server SAN的六大方面:规模、架构、SSD、网络、副本、管理……今夏,NBA与欧洲杯、美洲杯合体,LBJ和C罗先后被淘汰,意大利和梅西的阿根廷在24小时内相继捧杯……将此文翻出,仍别有一番风味。如5年前题材,分三期连载,以下为第二部分,最初发表于2016年9月19日

上部回顾Server SAN之规模与架构

单挑打不死:闪存改写游戏规则

欧洲杯小组赛刚结束,C罗“一生之敌”梅西率领的阿根廷连续第二年在美洲杯决赛中被公认牌面较弱的智利冰封。对梅西的质疑扑面而来:为什么前辈球王马拉多纳就可以带阿根廷队夺得世界杯冠军,而梅西只收获“三亚”呢?
1986年的墨西哥高原,马拉多纳在进四强和决赛的路上包揽阿根廷队全部进球,且各有一个突破数人围堵射入的佳作,决赛在遭遇德国队严密看管的情况下仍送出致命一传。自那以后整整30年,重大足球赛事上再也见不到如此有统治力的个人表演,虽然梅西和C罗整个职业生涯的个人数据要亮眼得多。
不完全是巧合,从上世纪90年代后期开始,为了保护进攻队员,FIFA和NBA都出台了一系列有利于带球突破的规则,结果却大不相同。在NBA,每到季后赛的关键时刻,超级巨星的持球单打,一再成为扭转战局的关键。
然而,在世界杯和欧洲杯这样的顶级足球赛事,个人带球长途奔袭“一击致命”的场面却愈发少见。1990年世界杯决赛又在德国和阿根廷之间展开,马拉多纳已过巅峰,四年前负责防守他的马特乌斯率队成功复仇。
在本届欧洲杯淘汰赛期间,马特乌斯表示:现在的足球,跑动比他那时代每场多3000米,他那时代比贝肯鲍尔(70年代)每场多跑3000米。时代不同了,现代足球,组织更严密,饮食更规范。
连续三届大赛,强队的每场人均跑动距离都达到10公里以上,也就是说,现在的人均跑动距离,比20年前高近一半,是40年前的两倍多。能奔善跑的队员遍布全场,个人带球过关斩将自然难上加难。没有一个成熟的传球组织体系是不行的。
本赛季的中超倒是还能看到类似的戏码:首轮对决,连续作战的卫冕冠军恒大队疲惫不堪,被力帆外援两度长途带球奔袭得分。

lifan-s.gif

有趣的是,有媒体评论,中超的比赛风格,落后欧洲30年……

球员跑动能力提升一倍,都会对比赛风格产生如此之大的影响。那么,存储介质从硬盘换成闪存呢?

SSD-HDD.png
左边三种不同类型的SSD,对比右边三种不同转速的硬盘。硬盘的随机I/O性能已经过适当美化,依然惨不忍睹……(表格较宽,建议横屏观看)

上表列出的对比数据,可以再次说明几个常识性问题:

  1. 在顺序读写性能方面,硬盘与(基于闪存的)SSD相差并不是很大,特别是后者受写入性能和接口带宽限制,“只”快一倍到十几倍,目前还很少超过20倍;
  2. SSD的优势主要体现在随机访问,IOPS性能可达硬盘的上千倍,延迟也只有后者的百分之一左右。

由于硬盘的随机访问性能太差——吞吐量(throughput)不到自身顺序传输带宽的百分之一,传统的中高端SAN存储堆积大量的硬盘主要是为了获得较高的IOPS(I/O per second,每秒I/O操作数)。因此,级联JBOD这种只增加硬盘数量而带宽保持不变的典型Scale-up方式被广泛采用。譬如,EMC最后一代采用单片式架构控制器的高端存储产品Symmetrix DMX-4,一个4Gb/s FC-AL后端端口,最多可以连接60个硬盘——每个硬盘分到的带宽不到70Mb/s,却也算够用了。

DS3500-EXP.jpg
典型中端存储系统的架构,(最上方)一对控制器拖着一组JBOD,可以是不同尺寸、转速的硬盘

为了连接更多的硬盘,提供更大的存储容量和更强的I/O能力,可以为存储控制器增加后端端口数量。但是,一套控制器能增加的端口数是有限的,DMX-4最多可以提供64个后端端口,即32对(HA需求)磁盘通道,所以最多可连接1920个硬盘——如果通过产品认证请求(RPQ)批准,可以增加到2400个。

最新的VMAX3(VMAX 100K/200K/400K),虽然引擎(一对控制器组成)之间可以Scale-out,每个引擎仍能级联6个磁盘扩展柜(DAE)。使用120个2.5英寸驱动器的DAE时,最多可达720个驱动器(硬盘或SSD),控制器的“负担”依然很重。

同样是随机访问,SSD(Solid State Drive,固态盘)的吞吐量超过100MB/s(1Gb/s)乃寻常事,继续沿用一个控制器拖上百个(闪存或硬盘)驱动器的Scale-up模式,势必造成性能上的巨大浪费。所以,围绕闪存设计的产品,Scale-out是发展的主流,譬如EMC收购来的全闪存阵列产品XtremIO:每一对(HA)1U控制器和装有25个SSD的2U盘柜组成一个名为X-Brick的基本单元,需要扩容时就增加X-Brick,性能随之同步增长,最多可以扩展至8个X-Brick组成的集群(又是8个)。

X-Bricks.jpg
XtremIO通过高带宽、低延迟的40Gb/s QDR InfiniBand网络横向扩展

普通的服务器不用考虑双控,也没必要外接JBOD走Scale-up路线,内部直连的硬盘或SSD通常都能独享接口带宽:

SATA就是600MB/s,SAS现在能到1.2GB/s;
PCIe 3.0 x4(单向)4GB/s,x8可达8GB/s……

于硬盘而言,SAS和SATA的带宽在相当长一段时间内都不会成为瓶颈;

于SSD而言,PCIe 3.0 x4或x8的带宽都有可能不够。

重点是,在Scale-out模式下,存储介质到其计算资源的通道更短且宽阔得多,就看如何使用,扬长避短了。

ES3600C-V3.jpg

SSD不仅在性能上占据压倒性优势,容量上也早已超越硬盘,但大容量(如7200RPM)硬盘明显更低的单位容量成本还是很有吸引力,而且顺序读写的性能差距并不算大。所以,将SSD作为硬盘的Cache使用,起码在现阶段,仍是业界较为普遍采用的方案。

以FusionCube分布式存储为例:在读取数据时,SSD Cache解决硬盘最怕的热点问题,即(根据系统算法)将一段时间内反复访问的数据复制到SSD中,释放硬盘的压力,而太长时间没有访问的数据会被移出SSD。在写入数据时,SSD起到缓存的作用,OSD收到VBS发送的写I/O操作后,把数据写入SSD就算完成本节点的写操作。缓存在SSD中的写I/O数据周期性的(或占据一定容量后)批量写入到硬盘中,尽量减少对硬盘的随机写操作。

Cache-Buffer.png
FusionCube分布式存储的读Cache(左)有两层,第一层为内存,采用LRU(最近最久未使用)算法;第二层为SSD,采用热点读机制。写缓存(右)则只使用非易失性的SSD

每个OSD管理自己的Cache/缓存,所以一份数据从写入到缓存开始就会有二或三个副本,以防因单个硬件故障(SPOF,Single Point Of Failure)而导致数据丢失。此外,SSD用于读Cache和写缓存的容量配比是可以调整的。

与闪存正相反,硬盘不怕写,怕随机。所以,FusionCube分布式存储支持大块直通(pass-through),按缺省配置大于256KB的数据块直接落盘而不经过SSD缓存,因为大数据块写入更接近顺序访问,硬盘并不比SSD慢太多,少了这么一个中间环节还有助于保护SSD。在顺序读写比较多的场景(如OLAP),直接访问硬盘比较有效。当然,这个直通的配置可以修改,取决于应用的类型和用户的需求。

FusionStorage-Modules.jpg
严格来说,作为不可缺少的基本功能,“分布式Cache”应该属于“存储引擎层”

FusionCube分布式存储更直接的一点是,直接管理裸盘(raw disk)而不经过中间层(如单机文件系统),既可以直接提高每个I/O操作的性能,还可以区分不同程度的硬件故障,采取具备针对性的措施,减少对资源池整体性能的不利影响,譬如:

  • 能够识别出硬盘上的部分损坏(如坏扇区)。Read Repair(读修复)机制在读数据失败时,系统会判断错误类型,如果是磁盘扇区读取错误,则自动从其他节点保存的副本读取数据,然后重新写入该副本数据到硬盘扇区错误的节点,从而保证数据副本总数不减少和副本间的数据一致性。虽然这个I/O操作会增加一点延迟,却不至于将整个硬盘下线,做大量数据的重新分布(rebalance)——那会非常消耗存储和网络资源,影响业务的正常运行。
  • 能够识别出资源池中的“慢盘”。一个响应速度低于其他硬盘的硬盘会拖慢所有与其相关的I/O操作,这时要毫不犹豫的将其“踢出”资源池。

一句话:(硬盘)该保时保,该踢就踢,出发点都是保证系统整体性能不受影响。

Ceph也已经从Jewel版本开始,引入直接管理裸盘的BlueStore存储引擎,以期替代原有的FileStore(看名字就知道)。初步的测试数据表明,基于硬盘的I/O性能可以提高一倍。当然,元数据管理等工作相应增加,需要社区和业界投入足够的开发资源。

ceph bluestore.png

在全闪存配置下,SSD的高性能意味着需要分配更多的计算资源,来处理明显增加的I/O请求。为了提高I/O性能,FusionCube分布式存储允许在一个节点上部署多个VBS,或者为一个存储设备部署多个OSD。在PCIe SSD作为主存时,可以在1个PCIe SSD上部署多个OSD进程,譬如2.4TB的PCIe SSD可以部署6个OSD进程,每个OSD进程负责管理400GB。

部分原因是,SSD如果不受接口带宽限制(或受限制较少,如PCIe),有可能容量越大性能越高(与芯片数相关),而硬盘的机制却不是这样的。

在Ceph的实践中,可以看到类似的做法,如为每个SSD分配2个OSD(Object Storage Daemon,对象存储守护进程),以更充分的发挥SSD的性能优势。

更多的OSD进程,意味着需要消耗更多的CPU和内存等计算资源。以FusionCube 9000的典型配置为例:6个PCIe SSD的全闪存节点,内存容量是12个SAS硬盘加1个SSD(Cache)的硬盘存储节点的2.5倍(160GB : 64GB),CPU内核数也差不多高一倍(E5-2660 v3 : E5-2620 v3)。

SSD-CPU.png

不论是作为Cache/缓存还是全闪存,闪存的加入都是软件定义存储(包括Server SAN)能够进入传统企业应用的关键。受限于硬盘孱弱的随机访问能力,早期的软件定义存储实践如GFS和HDFS,服务的都是Hadoop这类离线应用——毕竟,纯比堆硬盘,还是传统SAN存储设备更有效。

带球与传球:网络助攻Server SAN

过去两年,倡导分享球的勇士队打法赏心悦目,被认为是NBA的一股清流。对勇士队的追捧随着其在2015年6月夺冠,并在接下来的常规赛创下73胜记录而达到顶峰。
但是,在随后到来的西部决赛和总决赛,面对以巨星轮番单打为主的雷霆队和骑士队的冲击,勇士队再而衰,三而竭,终于败下阵来。
其实,在去年的总决赛上,詹姆斯一个超级巨星就差点儿把勇士队掀翻。如果有另一个人(譬如欧文不伤)能分担压力,巨星连线或轮流冲击,兴许已经得手。
究其原因,在狭小的场地,高强度的压迫下,过多的传球容易被抢断。总决赛最后几场,勇士队核心库里关键时刻几次致命的传球失误,令人记忆犹新。
然而,在过去的十年间,增加传球、控制局面却成为足球界的主流打法。西班牙队依靠传控打法在2008年登顶,并继续统治了随后两届大赛。夺得2014年世界杯的德国队,也是当届赛事上场均传球次数最多的球队。
凡事皆有例外,譬如2016年欧洲杯黑马冰岛队,小组赛与最后的冠军葡萄牙1比1战平,却只有后者一半的控球率(34%对66%)、三分之一强的传球次数(223对616)、不到四分之一的成功传球(132对536)。上赛季爆冷夺得英超冠军的莱斯特城队也是类似的路数。

640.gif
欧洲杯小组赛最后一轮,没有知名球星的冰岛队在最后一刻反击,两名队员极力赶上带球的队友,三箭齐发,接应传球绝杀奥地利……培养三名能奔善跑、传球过关的队员,可比发掘一位马拉多纳式的球王,要容易得多啊

冰岛在越过“伪强队”英格兰之后被传控更佳的法国队无情摧残,莱斯特的剧本也不可能在本赛季的英超重演。用传控支配、消耗对手,仍然是顶级强队的标志。
本节探讨的现象与上节有紧密的联系:球员们更能跑了,个人带球过多很难打开局面;传球当然比人跑得快,但长传一则准确性欠佳,二则飞行时间过长,留给对手从容布防。于是,积极跑动的球员和频繁的中短距离传球结合,将整支球队编织为一张伸缩自如的弹性网络。

Part2-s.jpg

SAN(Storage Area Networking,存储区域网)是专门为共享存储系统(磁盘阵列)设计的网络,用于把一台或多台主机(服务器)连接到存储系统上使用。SAN的典型协议(如FC,Fibre Channel)与服务器之间的网络(如以太网)不同,工作模式也很不一样:一个存储网络里可能有多个存储系统,但它们之间很少互相传输数据,或协商分担工作负载。

可以说,SAN和Scale-up的模型里,没有连续“传球”的概念。双控制器的切换,也像是一次性的球权转移。

反过来,分布式、集群、Scale-out和Server SAN,每个名词都透着浓浓的“传球”协作味道。节点间的自动协调和数据传输是整个系统的生命线,必须要有高质量的网络做保证。仍以FusionCube分布式存储(即原来常说的FusionStorage)为例,接收I/O请求的节点,其VBS(Virtual Block Storage,虚拟块存储)模块计算出的硬盘位置如果不在本节点内,就必须通过节点间的网络转发到所属节点,并等待返回,才能完成操作。如果网络带宽不够或延迟过高,均会拖慢整个系统的性能。

SAN-Server SAN.jpg

与“纯正的”FC SAN相比,Server SAN不需要引入(与服务器网络)异构的网络,节点之间的网络和面向应用(服务器)的网络可以基于同样的网络技术——以太网,或者InfiniBand(IB)。当然,这两张网络需要进行物理或逻辑上的隔离,以避免互相干扰。

为了保证Server SAN的性能,每服务器需要提供4Gbps带宽用于FusionCube分布式存储通信,推荐使用万兆(10GbE)网络。用于融合部署云资源池(如FusionCube 6000),且超过16个节点时,业务平面(面向应用)和存储平面(节点之间)必须使用独立的网卡。

Separated deploy.png
FusionCube分布式存储对接VMware、Xen和KVM的分离部署模式,可以看到网络、SSD和硬盘的I/O路径(存储端的OS也可以是RHEL,或者Xen、KVM)

单个10GbE端口的带宽约为1GB/s,对硬盘算挺高,而理论上1个PCIe SSD或2~4个SATA SSD即可填满。

像Oracle RAC和SAP HANA等对性能要求很高的应用,节点之间的网络可以换成InfiniBand,典型如FusionCube 9000。InfiniBand不仅具有四五倍于万兆以太网的带宽(40Gbps QDR或56Gbps FDR),还有低至纳秒级的超短延迟,OLAP(高带宽)、OLTP(高IOPS、低延迟)应用两相宜。

InfiniBand Roadmap_113015.jpg
InfiniBand的路线图,远非FC(SAN)可比。今年6月举行的国际超算大会2016上,华为携手Mellanox发布基于FusionServer E9000融合架构刀片服务器的InfiniBand EDR 100G交换解决方案

网络、SSD和计算能力的相对廉价,是拉动软件定义存储的三驾马车。不过,目前企业级SDS主要用的还是网络的数据面,SDN要到规模非常大的时候才可能成为必需品。

(未完待续……)

推荐阅读
关注数
2831
内容数
57
云计算、基础设施、大数据领域的技术话题
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息