zhangyoucai
作者zhangyoucai2016-11-15 11:35
系统架构师, 某国有银行

存储云最大的特点就是自动化

字数 5253阅读 4892评论 0赞 1

我作为一个在金融行业有10年左右工作经验的技术工作者,最近几年主要是负责技术架构方面的工作,因此在这里和大家分享一些有关架构设计及存储云方面的内容。其实,架构设计方面主要的工作是存储自动化,或者说存储云。在具体分享之前,首先要和大家澄清一个概念:云,云里雾里,概念特别多,我今天分享的是内容与云之间的关系。公有云,私有云,以及刚才提到的云存储,现在还要澄清一个概念云,即存储与存储之间的关系。云存储的概念,在北京出版社集团徐敏分享的内容中讲得特别好,像金山云、像媒体内部的云、阿里云、百度云,这个是对个人用户或者公有云,应用场景特别多,跟大家的关系特别密切的。我今天讲的内容是存储云,存储云与云存储最大的区别是什么呢?存储云的特点是把存储作为一种服务对外呈现,特点还有自动化的资源供给、自动化的策略分配、自动化的报表、自动化的性能。我今天重点会谈一谈我们在做存储云的过程中的一些体会。

当初我们为什么要建一套存储云?

首先,做过运维工作的人可能都会有体会,运维工作特别枯燥,工作量会特别大,经常加班到后半夜,也是很正常的事情,特别是金融行业,银行业,不知道大家有没有体会。银行业的操作不能在白天做,必须在晚上,甚至是凌晨以后,所以说这块对运维要求特别严。我记得08年有一次,在奥运会之前,我们做了一个事情,叫奥运重保,就是说在奥运会开幕之前,要把银行整个系统做一次加固,避免奥运会整个开幕当中出现什么问题,所以,在在这之前,银行的兄弟们没日没夜的加班。还记得有一次,有一位同事,加班大约有四五天,几乎就没有回家,所以后来有些同事就向我抱怨,什么时候是个头,觉得特别痛苦。从那个时候起,我就在想,有没有一个手段,能让大家伙从这样繁重的体力劳动、精神压力中解放出来,这是我们当时做存储自动化的一个思想萌芽。但是,2008年,存储自动化还没有人开始做,甚至连服务器自动化也没有人做,更别说虚拟化,这是为什么建设存储云的一个初衷。

第二点,还是顺着奥运重保这个事情说。有一次,银行有个维护日,比如有时候,大家可能会接到银行的通知,某日的后半夜,几点到几点停止对外服务,其实是后台在做一些动作。但是那天晚上,我们有位同事可能是特别劳累,造成了很严重的后果,等于说把存储系统搞停了,停了以后影响几个应用系统,第二天早上就没有按时开门,这个事情当时特别严重。曾经一度,这位同事反映他想辞职,他说压力太大了,工作根本就没法干。因为连续加班,特别累,人在操作键盘,那么多命令,很容易出错。这是第二件比较触动我的事情。怎么能把操作上的失误能够屏蔽掉,通过一种技术手段能把它屏蔽掉。

这两点,可以说是我们的内因,就是说,我们自身需要变革来改变我们自身生存状态的一个主要的原因,下面我再谈两点外因。

第三点,大家知道,这两年互联网金融特别火,甚至有人声称银行业就是二十一世纪的大象,有可能银行业会灭亡,所以说对银行的冲击特别大。我觉得冲击主要来自几点:第一点,互联网金融的创新速度非常快,大家都知道去年底微信抢红包的活动,从发布到上线特别快,甚至几天几星期就可以发布,但是这个事情对于银行来说,是不可能完成的任务。我们先不说应用,功能需要多长时间,就单从基础设施的准备,服务器、网路、存储的准备,在我们那里要一个月时间。所以,一个月时间,互联网金融的产品早就火起来了,我们还没有上线。所以这个是业务驱动。这些业务,现有的技术手段是没有办法来满足这种业务创新的需求,如果再这样下去,我觉得互联网行业说的没有错,银行是打不过互联网金融的。那么,这一条是外部的一个重要的力量。

第四点,我还想再加一条外部的力量。我负责的这个团队,主要是提供存储的服务,服务面向各种应用系统,银行的业务非常复杂,有联机交易,存取款的、刷卡交易;有分析类的,出报表的系统;各种各样。但是我们的基础设施很单一,或者说很乱,各种各样的东西都有,应用要差异化服务,联机交易,要求性能特别好,响应时间很短,在柜台,ATM取钱的时候,需要多少钱,马上就可以出来,要求响应速度特别快。后台的数据仓库系统,要求的又不那么高,只要每天结完帐之后,两三个小时把报表出来就可以了。这是有本质差别的,当时的现状是,没有办法满足这种需求。

这样呢,内因加外因,在2011年的时候,我们决定要从根本上改变内部的问题,满足外部的需求,所以说,当时我们提出了一个目标,很简单,就是要做存储自动化,并没有上升到云的概念,我们就是想自动化,自动化解决日常当中的问题,并且能把业务需求更好的满足,所以决定做存储自动化。这个时候,2012年,云计算概念起来了,云计算的概念特别多,有公有云、私有云,这些概念特别多,后来,我们经过分析,我们这个工作,与私有云,自动化资源供给比较切合,所以我们就借鉴云计算的理念。同时我们去做外部调研,外部调研的第一个对象是互联网企业,我们去和淘宝相关人员交流,他们当时给我们传递一个信息,他们的服务器,他们的存储,可以一周推一个推车,换一次硬件,也就是一周可以不进机房,硬件坏了没有关系,我一周去换一次就可以了,这个事情对我们的触动也比较大,所以这是我们当时做自动化的一个主要的目标。

从这些事情分析,我们决定启动一个项目,启动项目也会遇到一些麻烦,简单举几个例子,第一件事要对现状做一次梳理,像我们的数据中心,整理完发现,仅存储的厂商四五家,每一家可能有一两种,这样加起来可能有十种型号。对于参数来说就更复杂,比如说,大家都知道,存储的分配单位是LUN,这个LUN的大小有5个G的,有50G的,有30G的,100G的,500G的,特别多,这种情况,做自动化设计的时候根本就无从下手,不知道怎么办。这时候在想,能不能把这些情况简化了,再加上外部的差异化需求,我们把存储做一个服务目录。在服务目录里面,对各种情况进行简化,比如说可以分层次,当时确定了白金、金、银、铜四个级别,每个级别里面只存在一两种型号,不要那么多,甚至厂商的数量也在缩减,硬件的产品也在缩减,这样一来,最终形成服务目录。服务目录定义的非常清楚,白金级应该是高端存储,应该配多少块盘,多少个板卡,多少内存,每个LUN的大小,全都都是标准的,只有这样,在自动化的设计当中,才能往下走,这是我们做的第一步:服务目录。

服务目录做完之后,做第二部,流程设计。我们可能都知道一个名词BPR,业务流程再造,其实我们当时认为按我们原来的流程做就可以了,原来的流程:拿到流程做分析,分析完做规划,规划完做变更审核流程,最后一步做实施。但是,这个流程在自动化流程下面是行不通的,做完规划再人工传到下个流程,人工参与的过程太多,实现起来极其复杂,后来我们发现这个路也是走不通的。那怎么办呢,我们最后决定,一个大的目标,非常大胆的设想,要求全过程、全流程不需要人工干预。也就是说,一个业务系统告诉我需要1T存储,性能要求是什么,容量要求、可用性要求,后面的流程全部自动化,那意味着什么呢?选择存储,一个需求过来,到底落到白金的池子里,还是落到银级的池子里,全部都是通过策略判断的,落到哪台存储的哪个LUN,也是通过策略来判断的,最终判断到哪个LUN上,判断完之后,后面的流程是自动分配,也是不需要人工干预,这是我们当时做的第二大步。

我们在做流程设计的同时也在做一个很重要的工作,那就是对自动化软件选择的问题,当时我们就对市场撒了一张大网下去,看看哪一家产品能够符合我们的需求,当时主流的产品,比如EMC的ECC,IBM的TPC,这些产品最主要的特点就是,能够实现自动化,但是仅限于自己的产品,比如IBM的TPC,IBM的DS8000系统产品,包括终端的DS系列,实现的比较好,但是对第三方的产品都没法实现,因为我们的环境比较复杂,各种产品都有,这样就满足不了要求,那么像HP的SE,EMC的ECC都是存在同样的问题。第二个问题,我们要求有很多自动化、自定义的设计,这些产品往往是不开放的,就是说,它的自动化流程是个固化的流程,并不能够做灵活的定制,比如说要跟服务器做接口,我们想选完盘,选池子,再选LUN,这些流程他们不能做的,基于这两点来说,成型的产品可能满足不了。当时还有一个新型的OpenStack,流程当时是初步的,只能实现基本的流程,满足不了我们的流程,它对存储支持,当时主流的存储,比如EMC存储能够支持,但是我们内部用的其它存储暂时都不能支持。通过这样的分析发现,市面上没有一个产品能够满足我们的需求,这就带来一个很大的问题,如果没有产品的话,我们就要自己研发,投入的工作量是可想而知的,最后实在是没有办法,我们就决定自己研发这样一个系统,来满足我们的各种功能需求。

研发的时候我们要重新研究比较存储的SMI-S接口、存储交换机的SNMP接口,必须要我们自己去调研,当时像EMC这些存储,他们国内的人对这套接口,说白了,能够说清楚的人还很少,像HDS,国内对这种API了解的人几乎是没有的,当时就没有办法,我们就组织一帮人,对API代码在逐行逐句的研究,最后还请了EMC研发的一些专家给我们做了培训,到这种程度的情况下,我们算是对软件有了一定的了解,但是还有新的问题,SMI-S协议支持的程度都不是特别好,存储一些专用的参数,比如对平台选择的Flag参数,EMC当时的版本还不支持,也就是说,我们既要做API的开发,还要写脚本,两者相结合。现在回想起来,当时做这些事情特别的困难。

经过我们将近一年的努力,从我们调研,做开发测试,到试运行上线,一年的时间终于出来一个Beta版。有一天晚上我也在,就是在试运行,想给四台机器分一些存储,当天晚上流程不是很顺,总体上来说,那四个任务当天晚上就做完了,和手工做的时间差不多,从这以后,我们就更加有信心。经过试运行之后,再后来的阶段,我们有一些大规模的应用上线,那一次上线的规模特别大,大概上了IBM Power的服务器有100台,都是Oracle的RAC,当天就要把存储分过去,因为业务需求已经过来,要求一周之内搞定。我们就用这套系统,组织了几个人,准备当天晚上分配,从晚上八点钟大概到后半夜的四点多,整个100台机器的存储就分完了,大家当时就特别开心,因为这个工作,以前是不可能完成的,100台机器,光敲键盘也要两个晚上三个晚上才能做完,所以大家都特别开心,我们就组织了庆祝的活动,视为这个工作圆满完成。这个工作,后来跟服务器、跟网络,整个云管理平台上线还得到银监会的一等奖。我们是顶着这个压力,顶着满足解决内部的问题,满足外部的需求,这样的一个出发点,面临各种困难,终于把这个系统上线,我们觉得特别值。

这个系统上线以后,最近又兴起一股潮流,叫软件定义。软件定义的概念我觉得特别好,所以就对软件定义存储做了研究,研究之后发现,软件定义实现的功能,无非是自动化的存储选择,自动化的分配,自动化容量和性能管理,发现跟我们做的功能是一样的。当时就想,这个东西不早点出来,让我们费了这么大劲。但是,没办法,我们的功能已经上线了,现在我们在做一项工作,对软件定义做新的研究,它内部的核心是OpenStack,所以我们专门成立项目对OpenStack做研究,等着OpenStack成熟以后,再将我们的系统移植过去,以至于它有更好的适应性。那么说到软件定义存储,我就多说两句,就软件定义存储这块,为什么能够成为未来的潮流,我做个简单的判断。首先Openstack是开源的东西,开源大家很容量理解,开源的东西,像安卓是开源的,开源以后就会很火,因为开源以后,各厂商支持并没有成本的压力,很开放,所以存储厂商都会很积极的支持它,包括操作系统,包括服务器硬件,还有网络产品,Cisco,这些产品都会去支持OpenStack,它的生态环境很好,它解决了对下面存储的兼容性问题,如果说一个厂商不在这个领域里投入,不支持OpenStack,意味着未来可能接不到这个环境里来,所以我认为,从这一点来说,OpenStack的前景非常好;那么第二点,OpenStack,上面把策略、逻辑、流程设计实现了,因为我们做过了类似的设计,如果说一个企业没有做过类似的设计,它可以借鉴Openstack里面的实现流程,流程实现了,下面接口实现了,这就是一个完美的系统,能够运行的很好。OpenStack成熟以后,软件定义存储只是其中一部分,软件定义存储叫SDS,软件定义网络叫SDN,软件定义计算SDC,甚至更远的理想叫SDI软件定义基础设施,也就是可以把基础社会统一做成一个服务统一对外提供,那么今后不是说,一个应用要多少G存储,而是说,我要一个数据库服务,而整个是一套,打包到一起的。

从今天前面我这些分析,我觉得这个事情非常有意义,如果说某些企业没做的话也可以做一些借鉴,还是挺有意义的。我有一个建议,在做的时候,可以不必要走这样的弯路,可以在OpenStack软件定义环境下,用新的流程,做设计,可能效率会非常高。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

1

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

作者其他文章

相关文章

相关资料

X社区推广