2016-02-21 22:07:35
来 源
ZDNet
磁盘存储
IBM的SVF似乎也代表了传统存储改造的三大要点,如果也用英文表达,同样是SVF,但我将其换成了:Software-defined(软件定义)、Volume(容量)、Fast(速度)

信息技术(IT,Information Technology)发展至今天,相信大家都已经明白,其最根本的实质就是和数据打交道--CPU用来处理数据,内存用来暂存数据,硬盘/存储系统用来保存或备份数据,光盘/磁带用来归档数据,只不过在这些IT设备上,数据的状态(高速生成、变化还是静止保存)不一样而已,也因此有些厂商将如今的时代定义为数据技术时代(DT,Data Technology),从某种角度上讲,的确有一定道理,当然在我眼中,并没有超过IT时代的顶层设计。

为什么说DT不如IT高级,原因就在于信息是数据的提炼、浓缩与精华,原始的数据通过相关的应用进行更新,在以CPU+内存为核心的处理系统中与其他数据进一步产生交集,进而为人类提供更为有价值的信息,它才是真正为人类所需要的,也是真正为人类所服务的,可是它所存在于世的状态可能并不是由01组成数据,而是给决策者或使用者的启发且不会存放于IT系统中,显然--信息并不等同于数据,虽然它在很多时候可以以电脑数据的形式存在。当然,有关这个话题并非本文的重点,就止打住。

但不可否认的是,信息的提炼需要以数据为基础,这个数据基础平台的坚固性与可访问的性能,也将影响到上层信息的提取与处理速度,这个道理其实很简单,在IT诞生之初,或者说在冯-诺伊曼计算机体系架构确立之后,数据的存储与整体系统性能之间的关系就也就已经固定了。只是,当处理系统的速度还不够快,或者当数据量还并不大的时候,存储与计算之间的瓶颈与矛盾并不明显,然而,现在不同了。当IT越来越成为人类生活、工作、生产之必需时,企业也就越来越离不开IT,换句话说,IT正进入越来越多的企业经营与生产领域。另一方面,随着互联网的普及,它与越来越多的传统IT产生了交集, 并随之带来了海量的数据,它们需要更大的存储空间,而CPU与内存的发展也日新月异,这一切都让作为数据基础平台的存储系统承受着越来越多的压力。

传统行业企业的数据存储到底怎么变?

如何在新的IT时代,保持数据基础平台的不掉队,以进一步支撑起企业的经营与生产需求,对于很多很早就购置了存储系统的企业来说,都是一个愈加不可回避的话题。

有人可能会说,跟着互联网公司走呀,看他们的IT多厉害,哪家传统行业的企业的IT需求能比得上他们?话是这么说,互联网企业在在面对海量数据方面,的确有一手。但在我看来,就如工作技能上的隔行如隔山,在IT领域也是如此,不同行业对于IT的需求也大相径庭,不是所有的企业都适用于互联网的IT架构,因为他们所依赖的行业应用、他们的IT人员的技术技能与知识结构,往往不允许也不支持底层架构的脱胎换骨般的调整。况且他们又并非像互联网公司那样以IT为核心竞争力,所以对传统的存储架构进行优化与升级,才是最佳的选择。

那么,传统企业的传统存储架构又是怎样的呢?答案很明显--以集中式共享存储为主流,这对于非互联网企业来说,仍然是最省时省力的一种选择。虽然集中式存储广受互联网公司的鄙视,但以业务特点来分析,它对于绝大多数,数据量不大或数据增长量率远没有互联网企业那么疯狂的用户来说,在很长一段时间里,的确是较为理想的架构,并不需要彻底变革。尤其是比较敏感、关键的应用平台,如ERP、核心数据库等,在现有的集中共享式存储架构之上进行升级改造,应该是首选。

从IBM的SVF看传统存储改造的三大要点

IBM的SVF这一提法出现的时间并不长,它并不是一个新的产品或技术,它在IBM的官方网站上也没有专门的介绍, 其实它更像是一种用户经验的归纳,简单来说就是IBM三大产品线的组合:Storwize磁盘存储+Virtualization存储虚拟化+Flash闪存存储。

为什么要把这三大产品线组合起来,也缘于越来越多用户的最终选择,从中我们可以总结出一些规律。笔者认为,IBM的SVF似乎也代表了传统存储改造的三大要点,如果也用英文表达,同样是SVF,但我将其换成了:Software-defined(软件定义)、Volume(容量)、Fast(速度)

一、软件定义:存储资源虚拟化整合

这一点源于Virtualization,即存储虚拟化,但并不仅限于此。在IBM SVF的组合中,存储虚拟化的前身就是大名鼎鼎的SAN存储卷控制器(SVC,SAN Volume Controller),现在则成为了IBM软件定义存储(SDS,Software Defined Storage)家族Spectrum中的一部分,即Spectrum Virtualize Software,也就是说它把SVC的精华提炼为单独的软件产品,成为了SDS的一部分,所以说它是软件定义存储并不为过,这也是为什么我将它表示为SVF中的S的原因。而在IBM的SVF理念中,Spectrum Virtualize以V表示,即强调了它的了虚拟化的能力。

对于历史悠久的SVC,相信很多人都非常清楚,我也就不再多言。其核心的作用与现在流行的VSAN(虚拟SAN)很相像,只是VSAN是将分布于集群内各服务器上的硬盘/闪存虚拟成一个大的虚拟SAN,SVC则是将不同存储厂商的SAN系列,整合为一个大的虚拟SAN,这也是其SAN存储卷控制器名称的由来。而对于数据访问,即服务器一端,SVC也支持当前主流的计算环境,包括已经基本成为常态的虚拟化环境,确保整体应用环境的兼容性。

总而言之,Spectrum Virtualize为传统存储系统的改造提供一个基础的软件定义的平台,其根本的用意在于可以将传统存储架构中,可能分散、相互独立的SAN存储资源进行有效的整合,从而更有效的利用存储资源,以降低成本,这可以说是传统存储系统改造的一个基础。

从IBM SVF看传统存储改造的三大要点:软件定义、容量与速度

IBM SVC(Spectrum Virtualize Software)支持所有主流的应用环境,并可虚拟化整合主流的SAN存储资源

除了能整合异构SAN存储卷(不同厂商的SAN架构),并可在异构存储系统间移动数据,而不造成数据破坏这一关键的虚拟化能力之外,多年发展下来的SVC(Spectrum Virtualize)在其他方面的能力也不容忽视,比如利用 IBM Real-time Compression 将可存储的主要活动数据容量提升多达 5倍;使用 IBM Easy Tier自动优化包括闪存在内的分层存储; 利用创新的复制技术,提高远程镜像网络利用率;实施多站点配置,以实现高可用性和数据中心之间的数据移动;可对现有的存储池中的数据进行AES256等级的加密,以大幅度提高数据安全性。对于这最后一点我认为也是非常重要,毕竟互联网的普及也让企业的数据安全性日益受到高度重视,把存储系统改造的一个重点定为安全(Security)也并不为过,而这也可以说是IBM SVF第一个S的另一层含义。

二、容量:灵活的扩容

数据的不断积累,所带的问题之一就是必然的容量扩展,这基本上是迟早的事情,但互联网的普及,让这一进程明显加快了,传统行业的企业也无法独善其身。这就需要有一个长远的且灵活的扩容准备。

一谈到集中式共享存储 ,很多人就会想到"高大上"的高端SAN存储,对它们进行扩容总会与高昂的成本相挂钩。其实在传统企业中,采购这类存储的也不并不多见。更主流的则是中端存储,IBM在这一层面所主推的就是Storwize产品家族,目前最新的产品型号就Storwize V7000系列。 它就是IBM所提出SVF理念的S,而在我的定义里,它代表了V,即容量。

Storwize V系列的一大特点就是自带IBM Spectrum Virtualize功能,当然这其中用到的更多的是包括上文提到的Spectrum Virtualize在内的高级功能,如高级复制、高性能精简配置、加密、 Real-time Compression 和 IBM Easy Tier等等。

除此之外,对于组建大容量存储池(我在此称之为Volume,强调容量)来说,Storwize 也很有代表性。以V7000为例,它每个控制盒支持使用高性能的 12 Gbps SAS接口,最多可支持20 个附加的扩展机箱,可以扩展至 504 个硬盘驱动器,大约2PB 容量,在集群模式下,最多可以扩展至44个存储机箱,最大容量超过4PB。这一容量的可扩展能力对于绝大多数的用户来说,完全是足够了。

显然,集成了Spectrum Virtualize的Storwize V7000系列,在高级存储功能、存储容量、性能以及存储成本方面,达到了较好的平衡,对于传统存储架构的扩容来说,是一个较好的选择。

从IBM SVF看传统存储改造的三大要点:软件定义、容量与速度

Storwize V7000借助于虚拟化的功能,与传统的SVC一样,具备整合异构SAN平台的功能

需要强调的是,Storwize V7000本身就具备Spectrum Virtualize的能力,所以它完全可以代替单独的SVC(Spectrum Virtualize)来使用,有可能就此觉得这个是不是与前文介绍的Spectrum Virtualize重复了,直接用Storwize V7000不就全解决了?事实上,的确如此,但在一些应用环境里,可能就需要一个完善的解决的方案,除了有单独的Spectrum Virtualize与Storwize,还有一个必须的补充--全闪存阵列。

三、速度:永远的追求

还记得本文的开头所提到的存储系统主机系统之间,因后者性能的提升以及处理数据量的显著增加而带来的矛盾吗?没错,最关键的矛盾就是速度,不管容量大小,用户最终关心的就是能不能在更短的时间里,处理更多的数据,但前提是,存储系统可以支撑起相应的数据读写请求。

在这一层面Storwize就力不从心了,虽然其支持SSD+硬盘混合存储,支持Easy Tier分层存储,但对于某些关键业务应用环境,尤其是OLTP应用--无论在整体方案架构、性能还是成本效益上,单独的全闪存阵列都是更好的选择,而这显然也是大势所趋--当闪存越来越便宜,当用户对速度的追求越来越高,全闪存阵列的引入绝对是必要的。

这就是IBM SVF中的F,即FlashSystem 全闪存阵列家族。目前其最新的产品型号为FlashSystem 900,而在我看来,F就是更快的速度。

FlashSystem 900 最多包含 12 个 MicroLatency 闪存模块,这些闪存模块是大规模并行闪存阵列,可提供比之前的FlashSystem 型号高将近 40% 的存储容量密度。因此,FlashSystem 900 可以在单个系统中将可用容量从 2 TB 扩展到多达 57 TB。此外,MicroLatency 模块还支持卸载 AES-256加密引擎。

FlashSystem 900还有一个集成Spectrum Virtualize的型号,即FlashSystem V9000,对于两者的区别,可参见上文Storwize的描述,它可管理高达32PB容量的外部异构存储。

从IBM SVF看传统存储改造的三大要点:软件定义、容量与速度

纯粹以性能为诉求的FlashSystem 900与集成了Spectrum Virtualize,具备高能存储功能的FlashSystem V9000

很显然,就像Storwize V7000一样,FlashSystem V9000也可以成为SVC(Spectrum Virtualize)的替代者,直接统领异构的SAN存储环境。所以,可能又会有人说,这所谓的SVF并非都要一起上马才行吧。对此,我可能需要再次强调我个人对SVF的理解定义--Software-defined(软件定义)、Volume(容量)、Fast(速度)。SVC(Spectrum Virtualize)、Storwize硬盘存储与FlashSystem全闪存存储,虽然都可以具备SVC的能力,但各自还是有明显的分工,下面这个真实的案例可能更说明问题。

从IBM SVF看传统存储改造的三大要点:软件定义、容量与速度

安徽合力ERP应用系统性能优化方案与优化前后的性能对比

安徽合力是目前中国叉车行业唯一的上市公司,目前是中国规模最大、产业链条最完整的工业车辆和运搬机械研发、制造和出口基地。 由于业务增长迅速,其ERP应用系统面临着数据存储容量不足与性能瓶颈的双重挑战。

在安徽合力ERP应用系统性能优化改造中,主要就是对其存储系统进行了升级,重点措施包括:

1、增加两个SVC控制节点,以进行异构存储平台的管控,并提高快照等高级功能

2、通过对Storwize V7000的扩容,平滑支持现有的ERP应用的容量需求

3、增加FlashSystem全闪存阵列(型号840,无高级存储功能),以提升数据库性能

从方案图中可以看出,FlashSystem与Storwize V7000,和原来的EMC备份平台共同处于SVC的层级之下,方便统一管理。Storwize V7000只升级了一个扩展柜,离规格的上限(单机最高20个扩展柜)还有很大的距离,后续的可扩展性完全可以保证,而FlashSystem的加入,则极大的提高了应用性能,我相信这肯定也是Storwize V7000配备SSD无法达到的效果。

从方案中可以看出,安徽合力并没有用Storwize V7000来完全取代单独的SVC节点,这也是从全局角度来考虑的,SVC与V7000在虚拟化与增容方面,各伺其职。SVC负责全局存储架构的软件定义与管理,而V7000上除了虚拟化以外的高级存储功能,对于V7000本身也是非常需要的,单独的FlashSystem则保证了速度,而如果换成V9000的话,其在整体架构上的地位会进一步提升,但在大容量分层存储方面,也必然要有Storwize V7000的支持。

因此,对于IBM SVF来说,虽然在某些具体的产品上,可以具备其中的2项能力,但这一概念所面对的是全局的意识,即从"软件定义(虚拟化算是其中的一个典型)--容量的灵活扩展--整体应用速度的提升"这三个总体的要点进行综合考虑,再在各具体的方向上进行成本与关联设计,也因此SVF无论在局部还是全局存储上,都可算是一种组合。

综上所述,在我看来,虽然SVF这一理念,是以IBM的产品家族为提出的,但对于实际的传统存储架构的优化,仍然具有通用的参考价值。无论您是否对SVF感兴趣,都建议从上述的三个要点,来考虑自身传统存储架构的升级与改造。

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。