【IT168 专稿】D主任最近的日子有点烦。

原来，D主任是一家电子交易企业的信息主管，公司信息化建设的所有事情全都是D主任主要负责。好在开始的时候，公司的业务规模比较小，提供的服务也无非是商家的信息发布，和买家信息查询，D主任凭借自己对服务器、数据库那两把刷子，给公司搭建了一套初期的信息基础架构，对于公司当前的业务规模来说，应付起来还是绰绰有余。

不过近来，这套系统看起来有些吃不消了。原来，随着公司的业务越做越大，访问量压力日益提高，后台的数据也越积越多，D主任当初搭建的那套系统，在公司现有的业务压力下已经捉襟见肘，更不要说满足未来发展的需要。

不仅仅现有的业务对信息系统已经造成很大的压力，老板还在外面和多方面的投资人商谈，想进一步扩张公司经营范围。从老板的角度来说，未来还有很多新的经营模式要投入使用，还要给投资人做出种种规划，比如PV/UV增长多少，平均每年吸引多少忠实用户……

现有的用户压力已经很让系统吃不消了，舍不得孩子套不着狼，这下老板也痛下决心，决定换一套业务系统。但是，D主任就犯了难，服务器和数据库D主任还是有经验的，问题是存储系统选择什么样的会比较好呢？

数据增长问题

看来是老干部遇到了新问题，这不，D主任找了自己的老同学S博士，请他来给自己支支招儿。两人约在了一家咖啡厅见面。

S博士开门见山直奔主题，了解了一下D主任这边的情况：在之前的2-3年内，数据量基本保持在每年10-20TB的增长，未来，如果老板还会吸引风险投资的话，还有计划上视频点播、在线社区、网络游戏等等业务，这下访问量和数据量增长都完全没法儿估计了。

最麻烦的事情就是没办法确定一个清晰的需求，看起来S博士似乎也一筹莫展，沉吟了半天，S博士抬头到：不妨考虑下集群的存储系统。。。。

D主任：“啥叫集群存储系统？”

“传统的磁盘存储系统，前端一般是2个控制器，高端产品配置了更多的控制器，但控制器的数量一般比较难扩展了。在数据量飞速增长的情况下，大部分情况下的扩展，就是增长后端的磁盘数量”S博士娓娓道来。

“这就好像是一列火车，后边拉的车厢越来越多，但火车头的动力没有扩展，整列火车就会越跑越慢。”

“集群存储比较像现在的动车组，把火车头的动力与车厢相匹配结合，这样，在增加车厢数目的同时，火车的动力也按比例增加了。这就是集群系统，比较合适一些数据增长量很大的成长型企业应用。”

以动车组模式满足成长性需求

以IBM最近推出的网格存储系统XIV为例，XIV存储系统由一个一个的网格组成，每个网格计算单元包括处理器、缓存、I/O接口和磁盘，每次进行扩展的时候，处理能力、缓存能力、IO能力和磁盘容量都是按比例的同步增长，因此整体系统能更好的适应企业快速增长的业务量对后端存储容量和性能的双重需求。

以D主任目前的应用来说，一方面，D主任的公司需要满足并发访问量的要求，对性能要求比较高；另外一方面，D主任目前的业务规模还有限，数据量并不十分庞大，最重要的是，D主任资金有限，如果一开始就选择高端存储系统，无论在资金和处理能力上都不可避免会有一定的浪费。

选择一款中端存储系统，未来扩展的空间又会受到限制，因此，对于D主任来说，完全可以选择一款集群存储系统，以较少的资金较小的应用规模起步，但同时也能获得较高端的性能和可靠性。

以IBM XIV网格存储系统为例，经过规格上的调整后，起步容量为27TB，最低可配置6个接口模块单元，可以让用户以一个相对而言小规模的资金起步。随着未来业务的发展，XIV接口模块单元可以增加到9个、11个、12个、15个，一个机架不够用时可以再用第二个机架、第三个或者第四个，整体系统无缝的扩展至更高的性能水平，和更大的容量。

XIV的容量扩展操作也非常简单。传统的存储在扩容时需要一系列复杂的操作，增加了新的磁盘后，需要做RAID，定义LUN、定义卷，并指定给相关的应用，而前端主机要看到新增加的容量也需要一系列的操作。

XIV的容量扩展完全是自动化的。当新的磁盘加入后，原有的网格单元中的磁盘数据会自动地迁移到新的磁盘中，并达到与其他网格单元一致的性能水平。而容量增加对于主机则是完全透明的。

其实类似D主任现在的情况还有很多。从中国目前经济发展的大环境来看，很多企业都还处于一个起步阶段，有非常快的发展速度，这一类企业现在被统称为“成长型”企业。对于这些企业来说，起步的资金有限，发展的速度又很快，因此很难预估未来对于信息基础架构的需求。

对于这些企业来说，需要一个易于扩展、且能够实时满足业务需求的信息基础架构至关重要。而关键是，在满足业务需求的同时，还需要兼顾成本。