Chinaunix首页 | 论坛 | 博客
  • 博客访问: 714309
  • 博文数量: 535
  • 博客积分: 9970
  • 博客等级: 中将
  • 技术积分: 7260
  • 用 户 组: 普通用户
  • 注册时间: 2008-06-15 03:47
文章分类

全部博文(535)

文章存档

2011年(1)

2008年(534)

我的朋友

分类: 服务器与存储

2008-06-23 00:53:28

      三年前,根据某校“211工程”二期的建设规划,要建立一个支持全校数据存储与备份的校内异地数据容灾备份系统。这让该校计算中心的同事很是高兴了一阵子。这对数据中心来说,可是一件大事。具体负责此事的是运维服务室的主任申强。现在,全校数据的安全保障又进了一步,申强崩得紧紧的神经也就会放松一些。
有了规划,才好办事。申强和他的同事于是开始思考容灾系统的建设思路。经过详细的调研、学习、借鉴,他们为整个容灾系统建设设定了三个步骤。第一步是购买网络交换机,准备光缆连接,完成灾备存储专网的建设。这一步目前已经完成了,为容灾系统建设打好了基础。第二步,是购买存储设备和备份服务器及相应软件,于2005年11月招标。第三步是实施并投入正式使用,计划在2006年2月完成。
但在一个庞大的学校建一个可靠的容灾系统,绝不只是确定思路、设定步骤那么简单。宏观的部署完成之后,申强面临的就是实战。对此,他还真有很多故事要讲。
存储环境 意想不到的复杂
对于建设容灾系统,申强想到的第一件事情是盘点一下学校计算中心的存储现状。对此申强可是如数家珍。他负责的数据中心有80多台服务器,60多个应用程序,数据总量18TB。数据可以分为结构化数据和非结构化数据。
结构化数据共有9个数据库,生产数据总的数据量约150GB。所有的数据库备份数据都存放在NAS上,数据量共7TB,每天备份数据的增量约为20GB。
申强知道,还有非结构化数据要占很大一部分。非结构化数据分为两种情况:(1)生产数据存放在NAS上,基于NFS/CIFS/iSCSI方式访问;通过快照方式生成多份历史拷贝作为本地备份;生产数据的数据量约9TB,每天的数据增量约为20GB;Linux、Solaris、Windows的服务器数量分别是10台、5台、5台。(2)生产数据放在各服务器本地存储上;通过专业软件拷贝到NAS上,再通过快照方式生成多份历史拷贝作为本地备份;生产数据的数据量约为2TB,每天的数据增量约为10GB;Linux、Solaris、Windows的服务器数量分别是10台、10台、5台。
做了这些盘点后,申强深知,他要面对的问题还很多,需要解决单机容量过小、潜在故障点多的问题,还要面对Linux、Solaris、Windows等多种操作系统。他想到的解决方案是,给计算中心的数据进行统一存储,从而简化管理复杂性,并且对数据进行有效分类,从而优化数据应用性能、简化数据存储管理。
做了这些分析,申强认为,如果建设容灾系统的话,一个前提条件是在统一的存储架构下建设。
多重约束下的目标确定
接下来,申强和同事要做的就是确定容灾系统的目标,要考虑的约束因素还真很多。这个问题从“211工程”立项时就开始思考,。
一个比较理想的目标是异地容灾,但费用非常昂贵,学校不可能有这么多的经费预算。而对于应用容灾,由于涉及校内多个部门,应用环境非常复杂。经过反复考虑和设计,结合学校的实际情况,现在申强可以清楚地描述这个容灾系统所要达到的目的。从大的方面来说,这是要建立一个支持全校数据存储与备份的校内异地数据容灾备份系统,从而为学校的关键信息提供安全可靠的备份保护,以保证在主存储设备灾难之后能够快速恢复系统的正常运行。至少在校内不同楼宇内保存有一份可用的关键业务数据。数据要包含能够重新搭建应用系统的全部数据。这里的数据将包括应用系统的程序、安装配置文档、运行维护的规范等,并且要求数据一定是可用的。
基于这样一个目的,申强把数据容灾备份系统的性能指标设定为:原则上要求校内各二级单位的关键数据的RPO≤1小时。
要建设的属于灾备中心的存储专网,是基于IP的专用存储网。各单位的备份服务器连入存储专网,通过iSCSI或NFS或CIFS方式访问灾备中心的存储设备。为什么要选择基于IP的网络?申强的理由是IP网络容易搭建,在专用存储网络造到破坏时,校园网可以作为灾备存储专网来使用。
对磁带库的失望
计算中心以前使用的是磁带库。在容灾系统中是否继续使用磁带库?申强犹豫了很久。磁带库有一些让他头疼的缺点,比如:没有自动报错机制,磁带库坏了也不知道,还需要手工备份,这增加了很多工作量。但在考虑容灾系统选型的时候,他还是优先考虑了磁带库,一方面原来使用的是磁带库,而且磁带库也是一个成熟的技术,在价格上也有优势。而让他彻底对磁带库失去信心是由于一次事故。
一次为了检查系统故障,他像平常一样从磁带库中导出数据到备份的磁带库上。等到他再想从备份磁带库上把数据导回时,里面已经没有数据了。这让他烦恼至极,也对磁带库大失所望。
对于讨论很多的虚拟磁带库,申强认为,虽然提高了磁带库的速度,但是没有得到根本的改变。他最终决定选择磁盘阵列。他认为磁盘阵列一个基本的优点是,磁盘坏了可以清楚地知道。磁盘阵列可以在运行环境上提供统一的管理,而且可以在一定的存储条件下实现数据立即可用,也就是一般所说的RTO=0,为以后的系统升级和扩展打下了基础。
 
同构Vs异构
作为全国重点高校,申强所在学校的容灾系统建设吸引了国内外主流的存储厂商,如NetApp、EMC、HP、DELL、联想、曙光等公司都极为关注。这些公司根据各自产品的特点,都提出了各自的解决方案。
尽管这些公司的介绍都很精彩,申强有自己的标准。一方面要比较的是价格,要能做到总成本最低;另一方面是技术,要看容量、性能以及能否提供一个统一的存储架构,还有就是扩展能力。
申强认为,在考虑成本的时候,不能单纯比较价格,需要综合的看,要把运营维护成本加进去。影响运营和维护成本的一个重要因素是同构还是异构。众所周知,存储产品的互操作性不好,选择异构的产品将要极大地增加技术实现的复杂程度和运维的成本。在申强看来,还是同构的产品比较好。
在这里不得不提到的一件事情是,在今年上半年,该校接受了NetApp公司捐赠的一套存储设备。这帮助学校建立了一个统一的存储架构。现在要建设容灾系统,申强内心还是倾向于选择NetApp。毕竟同构的产品,更容易搭建一个统一的存储平台。
其他几家的产品在容量和性能上,基本能够满足学校的要求。但不是同构产品,建设一个统一的存储构架比较复杂。
这样分析了一番,申强的选择比较明朗了,那就是NetApp。现在,申强需要比较的是各家的价格。庆幸的是NetApp的报价也是最低的,只有一百多万元,其他几家都在两百多万元。现在正式的中标通知书还没有发出,但基本已经确定是NetApp了。申强希望中标的是NetApp,也终于如愿以偿。同构的产品再加上低价格,确实具有比较大的杀伤力。
贯穿该校计算中心容灾选型始终的是简单和实用,也正是这个理由让整个进程顺利进行。当然,接下来的项目实施,不见得就会有同样的顺利,而这正是申强和他的同事所企盼。
记者手记
优惠的陷阱
曾经听说过这样一个故事。A公司是一家小外贸公司,信息化还处在初级阶段。一次公司采购了一批笔记本,购买时,销售人员告诉他,现在某家国际大厂商的存储设备正在搞优惠活动,只需要1000元就能买一台。
这不是天下掉馅饼吗?为了谨慎,A公司的工作人员仔细考察了这个存储设备,没有发现任何瑕疵,确信不是残次品,也不是二手货,有原厂提供的质保,也没有发现销售合同有隐藏条款。对这些信息确认无误之后,A公司购买了这台存储设备。
过了一年,A公司长大了,要做比较大规模的信息化建设,存储设备不够用了。他们再次找到这家代理商购买存储设备,发现已经没有原来的型号了,新出的设备都很贵,比同规格的其他存储设备要贵很多。A公司心想,你卖得贵,我就购买其他厂家的存储吧。却发现存储设备之间的互连互通性很差。如果购买别家的设备,需要增加很多的附加成本。
存储设备厂商为了保证自己的市场份额,人为地建造了很多壁垒。在选型的时候,也就多了一个有意思的话题——同构和异构。有些厂商先用很低的价格吸引用户使用,到用户需要升级时再狠宰一把。凭借同构,厂商可以喊比较高的价格。为了吸引用户选择异构的产品,厂商抛出更多的优惠。
阅读(412) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~