政府网站异地容灾方案Word格式.docx

政府网站异地容灾方案Word格式.docx

《政府网站异地容灾方案Word格式.docx》由会员分享，可在线阅读，更多相关《政府网站异地容灾方案Word格式.docx（13页珍藏版）》请在冰豆网上搜索。

为加强政府网站建设，面向社会公众宣传政府网站功能，切实提高网站服务的实用性，国务院信息化工作办公室于2007年8月起在全国范围内开展政府网站“百件实事网上办”活动。

政府网站已成为政府电子政务对外服务窗口和发展的主要趋势，有利于各种信息和资源的整合，为政府与社会公众之间加强联系和沟通的有效载体。

越来越多的政府职能部门已经开始利用网络的优势，在网上对政府事务进行更高效的管理，从而使政府工作可以更快速、更便捷、更有效地开展。

●政府网站是权威的具有公信力的信息发布窗口

●政府网站是提高执政能力的重要体现

●政府网站是电子政务绩效水平的展示窗口

政府网站特点

●网站中有大量的时政新闻、政策法规、新闻图片等信息，内容权威。

●网站访问随着时事事件的发生，忽高忽低，为网站运行维护带来难题。

●同时政府为进一步规范政府网站建设、运行和管理，增强政府网站的服务功能，推进政务公开、提高行政效率，网站中也普遍加入例如民意反馈、民意征集、意见建议等在线互动的功能，在线服务的速度难以保证。

●随着互联网的发展，越来越多的政府类网站都应用了视音频内容的在线直播、点播，能够及时的将民众关心的各种新闻事件直观的传递给网民，同时流媒体的内容也加重了网站的带宽和设备负载。

当前政府网站面临的挑战

随着电子政务向纵深发展，我国政务网站服务性增强，特色鲜明，因而得到了广大网民响应，越来越多网民通过网络了解国家的政策、地方的法规，通过网络向政府、部委反映自己的想法、困难等多方面内容，亦使得各个阶层的领导能够直接听到百姓的声音，想百姓所想，做百姓真正关心的事情。

并且随着基础网络改善，多种电子政务的得到广泛应用，如：

政务信息上网、公共信息服务、在线查询检索服务、个人企业网上办事、互动交流等，使得工作效率大幅度提高。

无法预知的IT硬件设备的损坏、断电、火灾、自然灾害、恐怖袭击等，造成数据丢失或业务的突然中断；

系统人员误操作造成意外宕机或关键数据丢失，无法避免；

手段频多的黑客攻击、病毒入侵、垃圾邮件、网络与系统的漏洞，造成网络瘫痪、系统崩溃。

由此可见，保证政府门户网站的业务连续运营性，已成为在建设IT基础架构中首先要考虑的问题。

与此同时，我们需要考虑建立和加强业务恢复计划，以便在发生系统灾难后能够从容应对风险。

本项目计划既着眼于提出合适的解决方案，藉以最大化消弭政府网站宕机故障的业务风险、保障核心业务的正常运行、创造更高的商业价值。

二、需求分析

政府网站要对来自不同ISP来源的用户访问以及自身网站构架达到的要求:

对来自不同运营商的客户访问速度都要保证更加快速、稳定、不间断的提供服务

需保证自身网站与存储系统的高可用性，保证数据7X24小时的连续访问,一旦发生自然或者人为的灾难等导致数据丢失或者业务中断时，能够快速、及时地恢复数据，保证业务的连续运行

因故障事件延宕修护，网站系统无法访问，导致政府声誉的影响降到最低。

基于法律法规或业务策略，需建立重要系统的异地灾备中心。

三、业务连续性/容灾系统概述

3.1业务连续性/容灾系统概述

由于各类政府网上办事系统高度依赖于网站,并会因网站的各种突发问题而对政府网站及相关业务系统产生很大影响，这些问题包括了系统检修和升级带来长时间的系统停机等原因。

所以对于灾备系统的建设工作成为基础架构规划必不可少的一部分。

（图）：

各种故障对网络影响比例以及处理方法实例图

3.2业务连续性/容灾的重要意义

在突发性灾难面前,政府网站的确是非常脆弱的。

当越来越多的网民习惯利用网络进行事务性操作时,任何关键信息系统运转的中断或者数据的丢失都将导致不可估量的损失与形象影响。

灾备建设为政府网站带来的收益：

提高灾难应对能力；

减少灾难或事故导致的社会性影响与经济损失

减少灾难对政府业务的影响

满足国家法规如等级保护的信息安全相关要求

四、异地容灾系统设计方案

4.1设计思想

异地灾备方案设计之设计思想，

基于现状；

全面研究现有网络架构不改变现有网络架构的基础上实现。

统一设计：

深入研究网络现状和未来发展，搭建稳定、可靠、可扩展的灾备系统，避免重复建设。

关注业务：

灾备方案的根本目标在于为业务的高效运行服务，因此，灾备方案在设计时，要时刻研究业务部署特点、业务运行特点、业务发展特点，要考虑到未来业务的部署和发展。

引领前沿:

设计方案要保持在技术前沿,尽量使用目前成熟、高效的产品,解决方案,保持一次建设长久使用。

4.2设计目标

异地容灾方案设计之遵循目标：

多点灾备,避免原网站单点故障时导致业务中断实现高可用。

利用XXX金桥IDC机房双线接入之优势实现来自不同地域、运营商的用户（电信,网通等）访问最快的接入点,避免单一网络延迟。

灾备中心可作为网站的访问负载中心分支从而减轻服务器的负载，加快服务器的响应时间。

4.3设计原则

异地容灾方案设计之遵循原则

实用性：

针对当前网络现状、硬件条件、维护人员技术水平等，提出实用的网站灾备解决方案；

可靠性：

灾备的对象是承载关键行业业务的网络，要满足生产网络的可靠性要求，要满足长时间运行特殊要求；

规范性：

基于国际标准、成熟技术、以及行业网络管理规范，做到规范、标准，尽量避免个性化的手段；

兼容性：

兼顾网络设备现状，IDC机房的接口现状，尽可能兼容当前的设备、接口、平台；

可维护性：

尽量考虑运维现状，采用主流产品，易于安装和管理，减少复杂程度，减少维护工作，适应行业运维现状；

可扩展性：

立足现有状况，着眼未来发展。

系统采用分层设计和模块化设计，便于系统升级和扩展，便于未来新增业务扩展；

先进性：

采用先进技术，符合未来发展的技术，采用开放式的体系结构。

统一设计，随时扩容。

4.4设计优势

4.4.1自运营IDC数据中心

上海XXX金桥IDC机房位于浦东新区宁桥路825号裕安工业园，建筑面积约8000平方米。

双线电信运营商的各种数据业务，提供联通BGP精品网络带宽+电信带宽，保障用户托管系统的访问性能。

四星级数据中心,采用双路市电接入，保障冲足、可靠的电力供应。

具备7*24小时电信级技术保障和专业服务，是企事业单位建设数据中心或灾备中心的上佳选择

系统非正常工作对各个行业的影响图

4.4.2‘操作系统+应用+数据‘的完全保护

灾备虚拟化服务器图

可为服务器提供从操作系统到应用程序与数据的完全保护,可避免因手动重建系统、安装配置应用、恢复导入数据造成的困扰

-传统数据备份热备方案

　-上海XXX灾备中心服务方案

∙专注于数据备份

∙专注于‘系统+应用+数据的’环境备份

∙成本从低到高，有多种备份方案

∙可实现物理服务器与虚拟机之间双向备份

∙成本低的数据备份不可接管应用

∙可实现一对多的接管应用

∙备份后的数据不易测试

∙成本中等偏低

∙系统再建费时、费钱

∙硬件无关性恢复，备份的数据容易测试

4.4.3易于恢复测试

故障转移测试与原站点隔离，可自由操作，无需担心发生冲突或影响生产环境的完整性，将其应用于专用快速验证恢复计划，也可以在这种一次性的快照上进行应用系统参数调整测试，软件升级测试等，无需耗费大量时间

使用灾备中心的用户远程访问图

4.4.4快速故障切换

当保护的服务器发生故障，将自动启用备用的虚拟主机快速恢复与接管业务，保障业务连续性。

收到通过电子邮件、移动设备或基于控制台的发出的故障警报时，自动快速恢复业务。

4.4.5灾备架构

在具备本地或远程应用服务器的全环境备份保护的基础上，对应用服务器以最短时间提供应急接管服务，以保障被保护服务器上的应用能够连续对外提供服务。

异地灾备应用流程图

灾备方式数据图

4.4.6DNS智能解析服务

本方案设计的另一特点是基于网站域名的自动解析服务（DNS智能解析服务）。

当网站源站访问实效时，DNS智能解析服务系统自动返回异地灾备机房的备用网站IP给网站访客，避免访问中断。

利用DNS智能解析服务，可设置网站域名对应数个解析IP，除了适用于架构在双线机房的网站外，更适合异地灾备方案的部署实施。

⏹DNS智能解析服务的部署条件：

将现有域名注册商上的nameserver配置指向第三方DNS智能解析服务商的NameServer域名，生效时间为1-2天，切换期间不会影响用户的正常使用。

⏹DNS智能解析服务相对于CDN服务的优势

1）CDN服务要求对网站结构进行图文及程序分离设计，现有网站将面临网站重新调整应用结构问题。

2）CDN网络属于流量计费服务方式，对网站运营支出费用的管理较不可控。

五、灾备系统管理

5.1组织人员进行管理

项目实施中以及完成后,XXX将组织IDC人员7X24小时对灾备系统进行技术支持,以确保灾备系统的不间断正常运行

5.2定期检查灾备数据复制情况

生产系统与灾备系统采用实时复制对数据进行同步，为了保证数据的正常复制，我们需要指一名人员定时对复制状态进行监测并做下记录。

有异常时应即时向上级领导报告。

5.3定期检查生产中心备份情况

灾备系统与生产系统的数据备份缺一不可，所以为了避免数据发生逻辑性错误时需要恢复生产中心数据。

将指定专业人员为管理备份工作。

5.4数据恢复管理

容灾系统恢复的操作直接影响到实际的应用。

如果进行了不正确的恢复操作可能会造成可怕的后果。

因此，恢复操作应严格按一定的操作程序进行恢复

故障确认

在进行恢复之前首先应该确认造成故障的原因。

故障的原因非常多，应该分清是操作系统的故障还是数据库的故障。

如果是数据库的故障，不同的数据库应采用不同的故障分析方法，有时可以使用数据库提供的故障诊断工具进行故障分析。

这些工作应由相应的管理者如系统管理员或数据库管理员负责进行，在完成故障分析后确认需要进行恢复操作时，由相应的管理者提交书面的故障分析报告。

制定恢复计划

备份系统管理员在收到故障分析报告后应与相应管理者一起制定详细的恢复计划，包括恢复的内容、恢复的时间、恢复的操作步骤、恢复对应用造成的影响等，最后形成一个书面的恢复计划。

备份系统管理者应将故障分析报告与恢复计划一起提交到相应的主管领导审批。

主管领导应确认恢复对生产造成的影响，在批准执行恢复前应以相应方式与有关部门进行沟通和通知有关部门进行恢复前的准备工作。

恢复操作

Ø

在进行实际的恢复前，备份系统管理者与相应管理者应再次确认恢复计划的可行性及造成的后果。

确认无误后进入到实际的恢复操作。

在进行恢复前，还应该做的一件事情是对现有的内容作相应的备份。

以防止在恢复的过程中发生更进一步的错误。

这可能是由于恢复计划制定得不合理造成的，也可能是操作失误造成的。

进行恢复操作时应将每一步的执行过程记录下来，以备后用。

恢复