HPC中心灾难恢复方案

2004-6-27 11:13:15【作者】 畅享网 【进入论坛】
本文关键字 转贴文档
广告

 

HPC中心灾难恢复方案

  自从9.11之后,各种类型的机构和组织都在谈论着、努力研究和实施着多种灾难恢复方案,其实在9.11之前许多存储了关键数据的备份中心都已经实施了各种方案,从而管理人员可以在晚上美美地睡上一觉,因为他们都知道公司是可以从灾难中恢复过来的。

 

  不过为高性能计算(HPC)中心提供灾难恢复方案往往不同于为家庭、小办公室、大办公室,甚或跨国公司提供灾难恢复方案。HPC中心的磁带上一般都存储了数千TB以上的数据并且受到HSM(分级存储管理)体系的控制,因而不能使用镜像RAID,所以现在的问题就是:对于那些不能使用镜像RAID硬件却拥有巨大磁带库的HPC中心,你如何进行灾难恢复呢?

 

  背景

 

  如果你读过一些存储技术的文章,你可能会觉得下面这张表似曾相识,它显示了过去30年存储性能及密度朝着高性能磁带和磁盘发展的情况,所利用的都是当时最好的技术。光纤通道(Fibre Channel)驱动器规范分别收集自希捷(Seagate)网站的磁盘信息和美国存储技术公司(StorageTek)网站的磁带信息。

过去 30 年技术发展

增长倍数

磁带密度

1333

磁带数据传输速率

24

磁盘密度

2250

磁盘 RAID-5 8+1 密度 LUN (逻辑单元号)

18000

磁盘数据传输速率单盘平均值

21

磁盘 RAID 传输速率 LUN 平均值

133

 

    毫无疑问,在密度和性能方面磁带存储技术并没有与磁盘存储技术的发展并驾齐驱,并且磁带的加载和排列时间也没有象小文件写性能一样得到提升,后来我逐渐认识到这样一种灾备中心,即通过ATM OC-3利用远程磁带镜像将公司数据的第三份拷贝写入其DR(灾难恢复)设备。

 

  但是因为磁带不会流动,所以我对远程磁带镜像是否能够实现深怀疑虑。如果驱动器能够被流化,StorageTek T9940B驱动器的数据压缩速率将达到大约45MB/秒。考虑到ATM OC-3最多只有约15MB/秒,再加上所有与ATMTCP和数据拥塞相关的管理费用,我们估计持续速率大约只有5-8MB/秒。确实不妙,我觉得我们遇到麻烦了。

 

  我决定联系一下在Imation工作的世界一流媒体专家吉姆·古因斯(Jim Goins),他告诉我说大多数情况下对大部分磁带驱动器来说,不论是磁带还是磁带驱动器,大家都认为数据应该是流式的,他建议我们必须在按照客户所建议的OC-3方式写好数据后重新拉紧磁带,但实际上这是不可能的,因为HSM应用不支持这种功能,而且我们必须在写完数据后编写出并维护好专门的代码才能重新拉紧磁带。

 

  所以不对数据进行流化而写入远程磁带是不可能的,但是考虑到一天中所能发生的数据总量,允许数据流化就需要更高的网络连接速度,因此带来了额外成本,也就不再具有成本效益,从而令灾备中心陷入两难境地。那么应该做些什么呢?

 

 

HPC中心的灾难恢复问题

 

  大多数HPC中心的形势都很严峻,原因在于:

 

  1.HSM控制之下产生的数据量越来越大

  2.不能实现RAID镜像,这是因为大部分数据都存储在磁带上,并且RAID只是被HSM系统利用的缓存

  3.无法通过IP网络连接利用远程磁带驱动器和压缩数据,除非获得足够的昂贵网络带宽,考虑到普通一天的数量总量,这并不是非常具有成本效益。

 

  在制订有效的灾难恢复策略时,大部分灾备中心都有几个选择,其中包括:

 

  1.HSM磁带的一份拷贝转移至异地

  2.HSM硬件和软件创建第二份拷贝,然后利用HSM软件将其复制到异地(许多数据包都会以一种形式支持这种功能)

  3.建立一个真正坚不可摧的环境

 

  HSM磁带异地存储

 

  将你的HSM磁带拷贝一份转移至异地,就是说你需要一套行之有效的方法以便在灾备中心停止运作或消失时恢复磁带。对HSM产品来说,这表示你需要:

 

  1.服务器硬件

  2.HBA(主机总线适配器)

  3.存储

  4.磁带机械手和驱动器

  5.HSM软件

  6.HSM文件系统元数据或磁带数据

 

  有些HSM提供的写格式或工具可以让你无须利用文件系统或磁带元数据来读磁带,但这就意味着你必须读取所有的磁带然后按次序重新进行归档,以便让数据都在HSM控制器下。不过对PBpetabyte,百万GB)级的数据进行这样的操作可不会让多少人觉得有趣,而且特别花时间。

 

  这种方法确实可以防止受到内部人员的破坏,因为磁带都在异地并且不受HSM软件控制。而它的问题则在于要保持HSM文件系统或磁带元数据与转移至异地的磁带之间的同步性,往往非常困难。

 

  这是一种劳动密集型灾难恢复方案,需要定期进行测试以确保各程序正常。另外,灾难之后迅速获得备份和恢复运行也非常困难,这是因为你必须将服务器和其它硬软件一起激活,连接至磁带,并且可能还要把磁带安装到机械手内。

 

HSM异地镜像

 

  大多数HSM软件包都允许来自主服务器的数据进行某些类型的发送。文件的拷贝能够通过WAN转移并存储在另一个灾备中心归档,这种方法具有一些潜在的优势,特别是当异地灾备中心能够出现在同一IP子网中的时候。

 

  1.异地灾备中心可以在任何地方--距离1公里还是1万公里都无所谓,你所需要的仅仅是WAN带宽,并且你是在向另一个服务器写数据,所以也不会有什么严重的延时问题

  2.网络安全问题可能依然存在,因为异地系统在同一个子网中

  3.为了应对灾难发生,异地灾备中心必须全天候运作,并且不需要硬件、软件或手动干预

 

  另一方面,这种方法也确实存在一些必须处理或规划的问题,比如:

 

  1.WAN连接应该加密。许多交换机支持这种技术,所以应该不难

  2.谁来维护系统、硬件、软件和异地灾备中心?

  3.谁有权进入异地灾备中心?

 

  即使采取了相当可靠的预防措施,公司内部一些不怀好意的用户仍会进入本地和异地备份中心并破坏你的数据。唯一的好消息是,因为大部分数据都在磁带上,你总是可以读取所有的磁带。但是正如以前说过的,这对PB或以上级别的数据来说可不是闹着玩的。

 

  灾难保护/防御设施

 

  我住在明尼苏达州陆龙卷区的北部边缘地带,也知道很多本地公司都有"灾难保护设施"。大多数灾备中心都在地下,并且被钢筋水泥的森林重重包围,它们拥有与主备份中心不同的发电机并且与多个输电网络相连,同时还应该连接多个WAN,但是正如美国西北航空公司(Northwest Airlines)几年前所发现的一样,同一个导线管中的独立线路并没有什么作用,如果有人不小心切断导线管的话。

 

  这些设施成本昂贵,根据所应对的灾难价格有所不同。你要考虑很多类型的灾难,包括:

 

  龙卷风

  飓风

  洪水

  地震

  闪电

  其它自然灾害

  恐怖活动

 

你能够应对什么类型的灾难?需要的成本又是多少?我认为没有什么方案随时随地完全可靠,但灾难保护的潜力到底有多大呢?你能否十年如一日应付10亿比1的风险?甚或10,000亿比1的风险?大多数情形下,后者从未实现过,即使你拥有加强型方案,但是贵公司可以接受的风险到底是什么?

 

  加强型方案在管理领域有着显著的优势,特别是在下述情况:

 

  1.所有的数据在本地管理

  2.所有的硬件、软件和控制在本地进行,这同时降低了成本

  3.不需要WAN连接,从而加强了安全

  4.测试灾难恢复易如反掌

  5.灾难恢复更加迅速

  6.不过很遗憾,公司内部仍然会有不怀好意的用户,他们可能损坏系统。

 

  结语

 

  大型HPC中心利用HSM进行灾难恢复的问题并不容易解决,20世纪90年代早期和中期有一句关于RAID的名言:迅速、便宜还是可靠--三选二。这句话同样适用于今天的灾难恢复方案:灾难恢复要简单、便宜还是轻松--三选二。时间荏苒,随着RAID技术的发展,我相信这种情况一定会改变,但是现在你只有做艰难的选择和折衷了。

 

  任何灾难恢复方案中最关键的部分就是,要清晰地了解目前正在使用(或者考虑)的HSM特性。不同的厂商推出不同的功能,从而支配了你的某些选择,这些选择同时成为一个巨大的陷阱:如果你针对具体的HSM开发灾难恢复方案,那么从这个HSM向别处迁移将困难重重,不论是转移数据还是必须设计新的灾难恢复方案。

 

  你必须确保HSM能够同时满足你今天和未来的需要,也就是你必须了解HSM厂商在硬软件支持、特点、性能和可伸缩性等方面的规划,还要确定他们的计划适应你的计划。从一个HSM厂商迁移至另一个是极其困难的,而且有可能成为你最可怕的梦魇。

 

 

如果您希望与本文章的作者或其所在机构,进一步交流,请联系:畅享网 姜小姐
jill.jiang@amteam.org | 021-51096826-112 | 在线联系
IDS  Scheer专栏用流程管理整合企业的管理体系

某制鞋企业刚刚完成了一个流程优化项目,其最核心的快速补货流程的效率得到了大幅提升。正当整个项目组为之……

北自所 专栏财务ERP与ERP财务

财务ERP与ERP的财务不是一回事。企业资源计划所包括的资源,不仅仅是财务资源,片面强调资金流,难免……

CRM会客厅切莫把SaaS又当做大白菜来卖—..

SaaS是强调服务即产品,产品即服务。所以这种无形的产品已经不再可能是以大白菜批发兼零售的那种做法来……

黄埔江专栏[原创]SBO上线后各部门要做哪些..

SBO是根据中小企业实际业务需求一直在做加法,各个部门到底要做什么,得从系统的功能出发,根据业务与角……