第一篇:一个灾备项目的总结
1、光纤模块
将A地的数据灾备到B地,中间相隔40公里左右,两端各有一个光纤交换机,A地是HP的,B地是Brocade的。不过HP的那个是OEM Brocade的。从一个厂商那买了几个单模的光模块,各插在两端的交换机上。结果发现不能通讯。一开始怀疑是链路衰减,后来经过测试发现不是,再怀疑是模块的问题,可是模块厂家过来换了2次,还是不通,结果模块厂商坚持认为是链路衰减的问题。后来就拖啊拖了1个多月(期间正好过年)。最后同事从北京公司换了个模块,问题成功解决。看来问题还是出在模块身上。
2、RAID降级
B地的管理服务器(安装SANtricity软件)启动时报错,出现degraded字样,进RAID卡调试发现做的RAID1,强行进入系统,没有问题。
3、HBA卡
在管理服务器上用SANtricity软件指定一个卷,并将这个卷映射给主机后,发现主机不能识别,后来将光纤插到另一个HBA卡上即可,原先那个HBA卡是坏的。
4、双控、多路径
由于存储是双控制器,并且两控制器都启用,因此主机连接存储的一个卷时默认会发现两个硬盘,在主机层配置多路径即可。如果存储厂商不提供多路径软件,主机使用开源或免费的即可。
5、HBA卡驱动
主机通过光纤连接存储,走FC协议,因此需配置HBA卡,并且在主机上安装HBA卡的驱动
6、集群文件系统
A地主机实现Oracle双机,使用同一个存储卷,走FC协议,结果主机方面的集成商说以前从未遇到过,只会做NAS方式的。我推荐他们用OCFS实现卷共享,他们说不安全。。我无语了,继续推荐他们用其他集群文件系统。后来涉及到费用问题,他们还是乖乖的用OCFS了。
7、NAS机头
还是上面那个问题,客户的技术人员说既然无法实现卷共享,那就在存储前面加一个NAS机头。但是NAS机头价格比集群文件系统软件贵,而且用于数据库环境性能会变差。
8、镜像卷及切换
A地的A卷和B地的B卷做镜像关系,当A卷发生改变时,能立即反应到B卷。这样万一A卷故障,即可先停止他们的镜像关系,然后将B卷挂载即可。
9、Solaris
B地的主机是Solaris,集成商不太懂,现场用手机各种查啊,比如查看HBA卡的WWN号,对磁盘格式化分区,多路径配置等等。
10、项目验收
客户提出需要找第三方公司做A地同步到B地的性能测试,Oh my God。。
总结:
(1)、项目中遇到多次是硬件设备的故障,例如光纤盒HBA卡,当出现问题时,千万不能一根筋,要从各个方面去排查,大胆尝试,小心求证。
(2)、事先要准备好相关的实施资料,包括设备驱动、用到的软件、相关系统和设备的使用手册,不怕一万就怕万一。
(3)、做售前或售后,不要求你像研发那样精通到底层协议,但是要涉及的知识面要广,从主机到应用再到存储都要懂。
(4)、该你做的你就做,不该你做的你可以帮助,提供建议或文档,但是不要自己去动手做,不然出了问题就头大了。
第二篇:服务器灾备方案
服务器灾备方案
一、服务器灾备的目的
服务器灾备计划就是在平时对服务器的重要数据、数据库、配置文件、应用服务等做备份,为了在发生重大灾难或者事故后,能尽快将原服务器中重要的数据、数据库或者应用服务等恢复出来继续给客户提供服务。
※本方案适用于基于Windows操作平台下的服务器。
二、主要的服务器备份方式
按备份系统的准备程度,可将其分为冷备份、温备份和热备份三大类。
备份系统未安装或未配置成与当前使用的系统相同或相似的运行环境, 应用系统数据没有及时装入备份系统。一旦发生灾难,需安装配置所需的运行环境,用数据备份介质(磁带或光盘)恢复应用数据,手工逐笔或自动批量追补孤立数据,将终端用户通过通讯线路切换到备份系统,恢复业务运行。优点:设备投资较少,节省通信费用,通信环境要求不高。缺点:恢复时间较长,一般要数天至1周,数据完整性与一致性较差。将备份系统已安装配置成与当前使用的系统相同或相似的系统和网络运行环境,安装了应用系统业务定期备份数据。一旦发生灾难,直接使用定期备份数据,手工逐笔或自动批量追补孤立数据或将终端用户通过通讯线路切换到备份系统,恢复业务运行。优点:设备投资较少,通信环境要求不高。缺点:恢复时间长,一般要十几个小时至数天,数据完整性与一致性较差。
备份处于联机状态,当前应用系统通过高速通信线路将数据实时传送到备份系统,保持备份系统与当前应用系统数据的同步;也可定时在备份系统上恢复应用系统的数据。一旦发生灾难,不用追补或只需追补很少的孤立数据,备份系统可快速接替生产系统运行,恢复营业。优点:恢复时间短,一般几十分钟到数小时,数据完整性与一致性最好,数据丢失可能性最小。缺点:设备投资大,通信费用高,通信环境要求高,平时运行管理较复杂。
在计算机服务器备份和恢复中,冷备份服务器(cold server)是在主服务器丢失的情况下才使用的备份服务器。冷备份服务器基本上只在软件安装和配置的情况下打开,然后关闭直到需要时再打开。
温备份服务器(warm server)一般都是周期性开机,根据主服务器内容进行更新,然后关机。经常用温备份服务器来进行复制和镜像操作。
热备份服务器(hot server)时刻处于开机状态,同主机保持同步。当主机失灵时,可以随时启用热备份服务器来代替。
冷备份
温备份
热备份
三、服务器灾备的计划
对于基于Windows操作平台下的服务器,因为服务器功能、角色各不相同所以需要有不同的灾备计划来实现所有服务器的灾备方案。接下来就按服务器的功能与角色分类,来进行不同的灾备计划:
(一)IIS:WEB应用服务器
基于IIS的WEB服务器可以使用冷备份、温备份和热备份。我们的建议是使用冷备份或温备份,在另一台服务器或者虚拟机上搭建相同的IIS环境,可以定期将生产环境下的IIS配置文件和数据文件导入到备用环境中。如果生产环境下的IIS服务器出现问题无法使用时,直接切换到备用的IIS服务器上就可继续为客户提供WEB应用服务。
(二)SQL:数据库服务器
SQL Server上的数据库可以使用冷备份、温备份和热备份。可以使用另一台服务器或者虚拟机搭建起一套环境相同的SQL,然后将生产环境中的SQL上的配置文件、数据文件等导入备用SQL中。如果生产环境下的SQL Server出现问题无法使用时,直接切换到备用的SQL Server上就可继续为客户提供数据库服务了。还可以使用2台服务器同时连接存储设备做群集,将数据库中的数据文件放在群集中。这样当其中一台SQL Server出问题不可用的时候,管理员不用做任何操作,群集将会自动切换至另一台SQL Server上。
(三)AD:活动目录服务器
活动目录服务器可以使用温备份和热备份。我们的建议是使用热备份,建立多个域控并开启所有域控的全局编录功能,让彼此之间相互复制域信息。这样在某一台域控出现问题不可用的时候,其他域控制器会自动取代它的功能为域用户提供服务。
(四)DNS:域名服务器
活动目录服务器可以使用冷备份,温备份和热备份。我们的建议是使用热备份。建立多个DNS服务器,彼此之间开启区域复制,并且客户端需要设置多个DNS服务器的指向。这样在某台DNS服务器出现问题不可用的时候,客户端所指向的其他DNS服务器能继续为客户端提供DNS服务。
(五)ISA:防火墙及代理服务器
ISA服务器可以使用冷备份和温备份。另找一台服务器搭建ISA,然后将原生产环境下的ISA服务器中的配置和一些规则导入到备用ISA中,当ISA出现问题不可用的时候,将备用ISA启动起来配置完成后就可继续工作了。
(六)Exchange:邮件服务器
Exchange可以使用热备份。Exchange服务器的备份主要是针对邮箱存储这个角色进行的,推荐使用2台服务器同时连接存储设备做群集,将用户邮箱数据储存在群集中。这样当其中一台邮箱角色出问题不可用的时候,管理员不用做任何操作,群集将会自动切换至另一台邮箱角色服务器上。
(七)SCOM:用于服务器监控的平台
SCOM可以使用冷备份。可以使用另一台服务器或虚拟机作为备用SCOM服务器,当生产环境下的SCOM出问题不可用的时候,可以将备用SCOM启用起来。
※不过受原来那台SCOM监控的那些服务器必须重新更改代理的配置指向新的SCOM服务器,以便于接受新SCOM服务器的管理和监控。
(八)SCVMM:用于管理虚拟化的平台
SCVMM可以使用热备份。可以使用另一台服务器或虚拟机作为备用SCVMM服务器,当生产环境下的SCOM出问题不可用的时候,将虚拟机的资源转移到备用SCVMM上即可。
※对于基于Hyper-V的虚拟机灾备办法:
1、可以在平时将虚拟机的硬盘文件和虚拟机配置文件备份到异地,在虚拟机不可用的时候直接用备份的虚拟机硬盘文件和配置文件将虚拟机重建。
2、如果虚拟机是在SCVMM的管理下,那也可以通过SCVMM转移到可用宿主机上进行恢复。
(九)MOSS:自动化办公平台
MOSS可以使用冷备份、温备份或热备份。可以使用另一台服务器或虚拟机作为备用MOSS服务器,定期将MOSS上的配置文件和数据导入到备用MOSS服务器中去,当生产环境下的MOSS服务器出问题不可用的时候,可以将备用MOSS服务器启用起来。(这是针对于MOSS服务器上数据量较少的方案。)数据量较大的还是建议,使用2台服务器同时连接存储设备做群集,将MOSS中的数据文件存在群集中。这样当其中一台MOSS出问题不可用的时候,管理员不用做任何操作,群集将会自动切换至另一台MOSS服务器上。
(十)DPM:用于备份和恢复的服务器
※以上这些基于微软产品的文件、软件和平台等还都可以通过DPM来进行备份和恢复。DPM本身也可以备份自己服务器上的数据库和文件,我们建议让DPM服务器连接存储设备,将DPM备份的那些数据存在存储设备中。当DPM出现问题不可用的时候,可以重新搭建一台新的DPM来识别存储设备中的那些备份文件。
第三篇:灾备建设的四大误区
灾备建设的四大误区
来源:中国计算机报
2010年08月24日11:44 我来说两句(0)复制链接 打印
大中小
作者:郭涛
企业只要投巨资建设了灾备系统,以后就不会再出现业务中断和数据丢失了吗?其实,灾难备份/恢复与业务连续性有很大的差别,不能将两者混为一谈。“对灾备的错误认知是导致灾备建设失败的重要原因。”EMC公司资深业务连续性咨询顾问许瑀表示。
容灾不等于业务连续性
一些企业领导的固有思维是:容灾与业务连续性是一回事,只要拥有了灾备系统,就不应该再出现业务的停顿。其实,灾难备份主要用于应对较大的灾难事件,而不是针对局部的事故。业务连续性的概念更宽泛,无论是局部的故障,还是重大的灾难,都不能使业务中断。
许瑀表示:“灾难备份是业务连续性的基础,是企业多层次信息保护体系的重要组成部分。为确保业务连续性,企业应优先考虑建设基本的灾难备份和恢复系统。在„9·11‟灾难事件中,美国世贸中心里数百家没有灾难备份系统的公司彻底消失了。这充分体现了灾难备份作为企业信息架构基础组成部分的重要性。在建立了完善的灾备系统后,企业可以考虑构建多层次的信息保护体系,进一步提升业务连续性水平。”
由于投入的资金数量不同,信息基础设施的状况不同,灾备建设的思路不同,不同行业的用户在建设灾备系统时,很难遵循一个统一的策略。不过,企业在建设灾备系统时应遵循这样一个原则,即无论采用何种技术手段,都必须保证数据的安全。这是灾备建设的底线。
重异地灾备 轻本地保护
“实际上,导致信息系统出现中断,97%的原因是物理设备故障和系统的逻辑错误,只有3%的业务中断是由大灾难引起的。”许瑀分析说,“本地数据保护与异地灾难恢复都非常重要。有的用户认为,只要建设了异地灾难恢复系统就能抵御所有的灾难,因此忽视了本地的数据保护。这其实是一个误区。”
许瑀举例说:“某用户的磁盘出现故障,由于换盘时的错误操作导致了核心数据库的损坏。该用户利用本地备份系统恢复数据,恢复时间长达一周,而且丢失了两天的数据。”有用户盲目追求过高的异地灾难恢复RTO和RPO指标,要求RTO小于4小时,RPO小于15分钟。但事实上,该用户在进行本地数据恢复时,RTO大于1天,RPO为24小时。用户投巨资建设灾备系统,却不能减少因本地故障带来的损失,这其实是本末倒置。许瑀认为,只有将信息系统的本地数据保护和异地灾难恢复相结合,才能构成完善的业务容灾体系。本地数据保护与异地灾难恢复防范的风险不同,因此采用的技术手段、机制和措施也不一样。有些需要面向公众提供服务的系统,对灾难恢复的时间要求十分严格。但是大多数信息系统对灾难恢复等级的要求并不太高,通常可以接受几小时的灾难恢复时间。对于大多数用户来说,最重要的不是恢复时间的长短,而是数据能够100%被恢复。
RTO、RPO指标过高
在建设灾备系统的过程中,RTO和RPO是两个非常重要的指标。那么,RTO与RPO的数值是不是越小越好呢?“某银行针对其网上支付业务建设灾备系统时,提出系统恢复时间小于30分钟(即RTO小于30分钟),只能丢失5分钟的数据(即RPO小于5分钟)。”许瑀表示,“我看到用户的RTO和RPO指标要求时,第一感觉就是这不现实。因为银行的系统出现故障后,为了恢复数据,技术人员通常要根据日志对活动账号进行分析,而所有的日志分散在多个业务系统中,处理这些日志可能要采用手工方式。完成上述一系列步骤,银行至少要花费一两个小时的时间。”
企业在制定灾备恢复的目标时,一定要从业务的实际需求出发,不能盲目追求过高的RTO、RPO指标。过高的RTO和RPO指标不仅会增加灾备建设的成本,而且会让用户迷失在数字游戏中,对业务的保护无益。
忽视日常的运维管理
“2007年,某公司的核心业务系统发生意外宕机,多个关键业务数据库瘫痪。公司领导决定启用同城灾备系统。但是在进行恢复时,技术人员发现,容灾端数据严重滞后于生产端数据,灾备系统根本无法启用。”许瑀举例说,“事后,人们在追查原因时发现,由于系统管理员在进行灾备端测试时中断了灾备数据的复制关系,测试完成后又忘记了恢复灾备数据的复制关系,从而导致灾备系统无法启用。”
在某些企业中,灾备系统完全成了摆设。平时,这些企业的技术人员不对灾备系统进行定期检查,而且忽视了灾备演练。因此当灾难发生时,灾备系统很难发挥作用。中金数据系统有限公司高级副总裁陈天晴告诉记者,他们曾经按照合同要求为某客户提供灾备演练服务,但是客户的相关人员总以工作忙为由推脱,造成服务合同迟迟不能履行。许瑀表示:“企业在建成灾备系统后,应该定期进行灾备演练,并建立完善的业务连续性计划(BCP),包括详细的灾难恢复计划及本地恢复计划等。
(责任编辑:王亚红)
第四篇:灾后重建项目报告
根据2012年2月9日会议要求,各项目县区上报项目简介的模板如下(模板在后面):
首先我们以宕昌县韩院乡韩院小学为例,项目简介的相关内容及图片资料如下。
1、项目名称:宕昌县韩院乡韩院小学
2、项目摘要:宕昌县韩院乡韩院小学是一所六年制完全小学。受5.12汶川地震波及破坏,致使该校1047平方米校舍严重受损,教学工作无法正常开展。根据当地灾后重建布局调整方案及《宕昌县红十字会宕昌县灾后重建办关于重申中国红十字基金会援助宕昌县灾后重建项目的通知》,该项目于2009年4月9日开工建设,2010年7月竣工,现已通过审计、验收并投入使用。该工程由核工业天水工程勘察院进行地质勘察,陇南诚信监理咨询有限公司设计,武都建安建筑公司中标承建,陇南科诚监理公司中标监理。项目建筑面积2864.03平方米,四层框架结构,项目工程总投资500万元,由中国红十字基金会全额捐资援建。
3、图片(规格:800像素x600像素)
图片1:灾前照片
图片2:受灾照片
图片3:在建照片
图片4:主体照片
图片5:竣工照片
教育项目简介模板
1、项目名称:xxxxx2、项目摘要:xxxxxx是一所xxxxxx小学。受5.12汶川地震波及破坏,致使该校xxxx平方米校舍严重受损,教学工作无法正常开展。根据当地灾后重建布局调整方案及《xxxxxxxx项目的通知》,该项目于xxxx年x月开工建设,xxxx年x月竣工,现已通过审计、验收并投入使用。该工程由xxxx进行地质勘察,xxxxxx设计,xxxxxxx中标承建,xxxxxxx中标监理。项目建筑面积xxxxx平方米,x层xx结构,项目工程总投资xxxx万元,由xxxxx捐资援建。
3、图片(规格:800像素x600像素)
图片1:灾前照片
图片2:受灾照片
图片3:在建照片
图片4:主体照片
图片5:竣工照片
卫生项目简介模板
1、项目名称:xxxxx2、项目摘要:xxxxxx卫生院受5.12汶川地震波及破坏,致使该院xxxx平方米业务用房严重受损,正常的医疗救治工作无法正常开展。根据当地灾后重建布局调整方案及《xxxxxxxx项目的通知》,该项目于xxxx年x月开工建设,xxxx年x月竣工,现已通过审计、验收并投入使用。该工程由xxxx进行地质勘察,xxxxxx设计,xxxxxxx中标承建,xxxxxxx中标监理。项目建筑面积xxxxx平方米,x层xx结构,项目工程总投资xxxx万元,由xxxxx捐资援建。
3、图片(规格:800像素x600像素)
图片1:灾前照片
图片2:受灾照片
图片3:在建照片
图片4:主体照片
图片5:竣工照片
注:民房项目及村发活动室、村卫生室等项目简介参照上述模板上报。
第五篇:灾后重建项目简介
成县抛沙初中“特殊党费”灾后重建项目简介
成县抛沙初中(现成县三中)是一所全日制完全中学,创建于1972年,学校占地面积20001m²,校舍建筑面积10455m²,地处距县城西5公里的抛沙镇。现有教职工76人,教学班24个(高中10个,初中14个),在校学生1200多人。
“5.12”特大地震,学校校舍遭受不同程度的损毁,尤其是土木结构平房校舍受损严重,已无维修利用价值,现已拆除,剩余校舍已远远不能满足教育教学的需要,急需重建。
根据全县学校布局调整和总体规划,计划在原成县三中的基础上进行灾后重建。从2008年底开始至2009年6月底,在县委、县政府、县教育局和抛沙镇党委、政府等部门的关心和支持下,新征建设用地近7亩,完成了灾后重建前期各项准备工作,并将该项目设计报省教育厅,由西北市政设计院进行了审查工作;7月中旬省教育厅批复了项目(甘教发[2009]75、76号),决定利用“特殊党费”资金为学校新建综合教学楼、学生宿舍楼、食堂以及风雨球场各一栋,总建筑面积7797平方米,总投入资金1453万元。综合教学楼为三层双面框架结构,建筑面积2876平方米,可容纳18个教学班900名学生;学生宿舍楼为四层单面框架结构,建筑面积3262平方米,可供400多名学生住宿;食堂为三层框架结构,建筑面积765平方米;风雨球场为单层网架结构,建筑面积894平方米。于8月份,委托甘肃三轮建设项目管理有限公司对项目进行了宣传和公开招投标,成县城昌建筑公司和武都建筑安装公司分别中标。工程于2009年8月24日陆续开工。施工过程中,严格按照施工要求,加强工程质量监管与成本核算,确保建设资金按时到位。通过各方紧密配合,2010年8月15日,综合教学楼、学生宿舍楼现和食堂均已完工并投入使用。风雨球场已于2011年7月15日完工投入使用。
2010年8月,随着综合教学楼、学生宿舍楼现和食堂完工,学校进行了一系列辅助工程建设项目,用彩砖硬化校园近4000多m²,购植了多种树木、花卉,并于2011年9月建成锅炉房。
成县抛沙初中灾后重建项目完成后,符合全县学校布局调整和总体规划,将能满足900名学生同时入学就读,并提供400多名学生的饮食住宿;同时与旧教学楼结合,能够使成县抛沙范围内1200名学生接受良好的教育,促进当地教育事业的发展。