某市电子政务云计算数据灾难备份中心可行性研究报告.doc

《某市电子政务云计算数据灾难备份中心可行性研究报告.doc》由会员分享，可在线阅读，更多相关《某市电子政务云计算数据灾难备份中心可行性研究报告.doc（56页珍藏版）》请在三一文库上搜索。

1、XX市 电子政务云计算数据灾难备份中心 可研报告二一一年九月目 录1.1建设目标、规模与内容11.2标准规范建设内容11.3政务数据灾难备份信息资源规划和数据库建设方案21.3.1平台总体架构21.3.2数据资源规划21.3.2.1数据资源规划的总体思路31.3.2.2数据资源体系结构41.3.2.3共享数据一致性的保证41.3.2.4共享数据库的建立过程61.4应用支撑平台和应用系统建设方案71.4.1数据支撑平台71.4.1.1数据共享交换子系统71.4.1.2目录管理服务子系统101.4.1.3共享数据管理子系统101.4.1.4共享业务管理子系统111.4.1.5系统配置管理子系统11

2、1.4.1.6系统安全管理子系统111.4.2数据共享交换平台121.4.2.1交换网络结构121.4.2.2交换概念模型141.4.2.3交换体系结构151.4.3共享数据管理系统171.5数据处理和存储系统建设方案171.5.1数据处理设计171.5.1.1功能设计181.5.1.2逻辑结构191.5.1.3数据接口系统201.5.2存储系统设计201.5.2.1设计原则201.5.2.2主流存储技术比较及建议211.5.2.3Raid类型配置建议231.6服务器系统建设方案（原提纲写的是终端系统建设方案）241.6.1设计原则241.6.2服务器系统选择的依据251.6.3需求分析251

3、.6.4性能测算261.7网络系统建设方案271.7.1网络拓扑结构设计271.7.2网络拓扑图281.8安全系统建设方案281.8.1物理安全291.8.2网络安全291.8.3系统安全301.8.4应用程序安全301.8.5数据安全311.8.5.1核心数据加密311.8.5.2数据访问控制321.8.5.3数据传播和复制321.8.6整体安全策略的说明321.9灾备系统设计331.9.1设计原则331.9.2灾备技术比较331.9.3灾备解决方案351.9.4备份策略361.10运行维护系统建设方案371.10.1总体需求分析371.10.2分项分析381.10.2.1网络平台运维管理3

4、81.10.2.2数据库运维管理381.10.2.3主机平台运维管理391.10.2.4SAN存储运维管理401.11详细软硬件配置清单401.12机房及配套工程建设方案421.13机房建设方案设计要求421.13.1建设方案设计431.13.2装饰装修431.13.2.1天花吊顶431.13.2.1.1天花的性能规格441.13.2.2防静电活动地板441.13.2.2.1防静电活动地板性能参数451.13.2.3门451.13.3电气配电451.13.3.1电源接入方式451.13.3.2电源功率配置461.13.4UPS系统461.13.5精密空调系统461.13.6机房防雷系统471.

5、13.6.1设计范围471.13.6.2设计方案471.13.7机房桥架及综合布线系统491.13.7.1信息点分布49iii1.1 建设目标、规模与内容数据灾难备份中心的建设是为了解决政府部门间信息共享，实现业务部门之间的数据交换、数据共享与数据备份，促进XX市电子政务的发展。具体目标如下：建立数据灾难备份中心的系统平台。完成相应的应用软件和数据管理系统建设，实现数据的交换、保存、更新、共享、备份、分发和存证等功能，并扩展容灾、备份、挖掘、分析等功能。1.2 标准规范建设内容(一)建立数据灾难备份中心的系统平台。完成相应的应用软件和数据管理系统建设，实现社会保障数据的交换、保存、更新、共享、

6、备份、分发和存证等功能，并扩展容灾、备份、挖掘、分析等功能。(二)建立全市自然人、法人、公共信息库等共享数据库，为宏观决策提供数据支持。对基础数据进行集中管理，保证基础数据的一致性、准确性和完整性，为各业务部门提供基础数据支持；(三)建立数据交换共享和更新维护机制。实现各业务部门之间的数据交换与共享，以及基础数据的标准化、一致化，保证相关数据的及时更新和安全管理，方便业务部门开展工作；(四)建立数据共享和交换技术标准和相关管理规范，实现各部门业务应用系统的规范建设和业务协同；（五）为公共服务中心提供数据服务支持，实现面向社会公众的一站式服务；(六）根据统计数据标准汇集各业务部门的原始个案或统计

7、数据，根据决策支持的需要，整理相关数据，并提供统计分析功能，为领导决策提供数据支持；（七）为监督部门提供必要的数据通道，方便实现对业务部门以及业务对象的监管，逐步实现有效的业务监管支持；（八）为业务数据库的备份提供存储和备份手段支持，提高业务应用系统的可靠性。1.3 政务数据灾难备份信息资源规划和数据库建设方案1.3.1 平台总体架构1.3.2 数据资源规划数据资源是数据灾难备份中心最重要的资源。数据灾难备份中心的数据资源分布状态具有阶段性，每个阶段都对应数据资源整合的不同阶段，体现数据资源的管理集中、有机分布的特点。根据“基于数据，围绕数据，面向数据”的建设思路，我们进行数据资源体系的总体规

8、划，然后具体描述共享型的共享数据库、操作型的业务数据库和分析型的历史数据库这三类数据资源的构建、维护和使用。1.3.2.1 数据资源规划的总体思路数据资源规划的总体思路主要包括如下几个方面： 数据共享标准化首先共享数据是标准的，其次共享的方法和途径是规范的。目前各系统数据资源数据库已经有多种存在方式，要解决系统间信息的互连、互通、互操作，必须针对共享数据建立共同遵守的标准规范，只有编码是统一的、格式是统一的、数据交换的方式是统一的，才能保证数据是一致的，才能实现对数据交换和数据共享的有效管理。 业务数据相对独立各职能部门分管业务的范围和职责不同。因此，系统在全局考虑、统一设计的同时，还要充分考

9、虑不同业务部门自身的特点，在统一规划的前提下，保证支持不同业务活动的数据具有相对独立性，建立面向各部门进行联机事务处理的业务数据库。 决策数据集成化建设数据灾难备份中心的另一个目的就是将各部门的业务结果数据有机地集成在一起，进行综合查询和统计分析，为各级领导的决策提供有力的数据支持。1.3.2.2 数据资源体系结构数据灾难备份中心数据资源体系结构对公共服务系统、业务应用、决策分析提供支持，数据灾难备份中心的数据库包含如下内容： 共享数据库，包含：自然人基础数据、法人基础数据库、元数据库、标准代码库、共享业务数据(如果业务部门之间通过数据灾难备份中心进行数据交换)。 统计分析数据库，汇集各业务部

10、门的统计分析数据，为决策提供数据支持。 运行管理数据库，用于监控管理、节点管理、日志等。 公共服务数据库，提供对公共服务系统的数据支持。1.3.2.3 共享数据一致性的保证共享数据包括自然人和法人基础数据及其元数据和标准代码数据、共享业务数据。共享数据一致性问题是数据灾难备份中心面临的关键问题。从范围上划分，共享数据包括基础数据，基础数据包含基准数据。l 基准数据基准数据是指唯一表示自然人和法人的数据字段集合，自然人有身份证号码和姓名标识，法人有法人机构代码和名称标识。基准数据主要来源是市公安局和市质监局。基准数据必须保证在整个社会保障信息系统是一致的，将来扩展到整个电子政务系统是一致的。市公

11、安局和市质监局负责将更新的信息交换到数据灾难备份中心；市数据灾难备份中心负责汇总数据，进行比对整理校验，形成一致的基准数据，通过数据共享与交换平台分发给市级各业务部门和区数据灾难备份中心；由业务部门/区数据灾难备份中心校验更新自身的基准数据，保证基准数据的一致性。基础更新频度要达到每天更新甚至实时更新。数据的传递和分发通过数据交换平台实现。l 基础数据基础数据是指自然人和法人的常用基本信息，各业务部门日常管理都需要用到的面向主题的数据。基础数据包括自然人和法人的基准数据和其他元数据。主要来源是市级业务部门和区数据灾难备份中心。基础数据一致性必须建立于基准数据一致性的基础上。基础数据的一致性也需

12、要通过数据共享与交换平台和相应的机制、管理办法来保证。各部门按照业务职能明确元数据维护责任和权限，定期将在办理业务过程中更新的元数据项数据提供给数据灾难备份中心；数据灾难备份中心根据基准数据一致性的原则，对各业务部门提供的数据进行比对校验，正确的数据增加或更新到数据库中，并每天按照各业务部门业务要求，将更新数据分发到各业务信息系统；各业务部门可以直接使用这部分数据作为支撑行政业务和行政管理的数据资源，也可以作为业务参考信息。基础数据的范围将随着元数据范围的扩大而扩大。这部分数据同时可作为社保卡的数据。基础数据更新的频度，按照元数据使用的频度分别定义，通过部门协商机制研究确定，最低要求每周更新，

13、一般每天更新，业务关联度较高的信息，要实现实时更新。数据的传递和分发通过数据交换平台实现。l 元数据标准和标准代码数据元数据标准和标准代码数据由市数据灾难备份中心维护更新，并发布给各业务部门和区数据灾难备份中心使用，由于业务部门系统内部沿用的代码可能与数据灾难备份中心的发布版本不一致，业务部门需保证与其他业务部门进行共享交换的数据必须遵循数据灾难备份中心的标准规范，而在系统内部可以采取逐步过渡迁移的方案，尽量减少影响业务运作。l 共享业务数据共享业务数据是指多个业务部门之间需要共享使用的数据，作为各业务部门进行行政管理的参考数据。数据来源渠道包括市级业务部门、区级数据灾难备份中心、社会保障卡和

14、公共服务等业务运营机构。共享业务数据以业务数据的发生地管理部门为准。这类数据由各业务部门按业务需求和协商的频度提供给数据灾难备份中心，在数据灾难备份中心处提供各部门查询。由于这类数据量比较大，预计可以分业务、分批更新。1.3.2.4 共享数据库的建立过程共享数据库的建立采取逐步扩展的策略，达到数据整体上的一致性、完整性和准确性是一个逐步完善的渐进式递归过程。共享数据库的建立由业务驱动，业务部门提供的自然人、法人基础数据经数据源单位确认后存入基准数据库，并反馈业务部门，经过不断的提交和确认，基准数据库的数据不断增加，覆盖范围不断扩大，比对的工作量逐步减少。在基准数据库的基础上，不断补充其他的自然

15、人、法人基础信息，最终形成自然人、法人共享数据库。采取围绕自然人和法人基准数据为核心，在核心的基础上不断扩充和完善自然人和法人共享数据的策略进行建设。首先建立和整理自然人和法人基准数据库，保证核心的准确性，为各业务部门进行数据清洗和整理提供基础；再在基准库的基础上搭建自然人和法人共享数据库的整体框架，共享的信息内容成熟一个、整合一个、交换一个。1.4 应用支撑平台和应用系统建设方案1.4.1 数据支撑平台XX市电子政务数据灾难备份中心支撑平台主要包括：数据共享交换子系统、目录管理服务子系统、共享数据管理子系统、共享业务管理子系统、系统配置管理子系统和系统安全管理子系统。1.4.1.1 数据共享

16、交换子系统数据共享交换子系统为全市各业务部门提供数据交换服务。主要功能包括：(1)交换管理提供交换节点、交换服务和交换桥接的配置、调度和检测功能；提供交换服务和交换桥接的日志查询和统计功能。(2)交换服务提供共享域内交换节点之间的数据共享交换服务，包括采集、分发、汇总和转发；提供交换节点与业务系统之间的交换桥接服务，实现数据提供和获取；提供跨域交换服务，实现共享域之间通过对接节点进行数据交换。数据交换引擎是数据共享交换平台的核心。数据交换引擎主要包括服务处理和数据接口。（一）服务处理数据交换引擎运行过程示意图如下：图表 1数据交换引擎运行示意图数据交换引擎接负责收并处理数据交换服务请求，实现数

17、据的交换。主要包括：（1）服务请求监听器服务请求监听器采用监听机制，实现对服务请求的并发接收。（2）服务解释处理器服务解释处理器负责解释执行服务请求。服务请求监听器把服务请求转发到解释处理器，服务解释处理器查询所请求的服务定义，根据服务定义产生执行序列并控制各个交换节点实现交换服务。在数据交换压力大的时候，根据服务的优先级高低，控制交换服务的执行顺序，确保高优先级的服务优先执行。（3）服务定义服务定义记录了服务的项选参数以及设置，描述了服务应该如何解释和执行。交换服务可以定义服务优先级等信息。（4）接口控制接口控制负责把命令序列发送到各个交换节点，控制交换节点上的数据接口，驱动数据交换的执行。

18、（5）传输管道数据的交换过程是在传输管道中进行的，传输过程分为三部分，数据输出，网络传输、数据输入。在源节点的数据输出接口把数据由数据源读出，并根据服务配置经过数据加密、数据压缩等过滤器。经数据输出接口输出的数据通过消息中间件传输到目标节点。目标接点的数据接口接收到数据后反向经过各种过滤器把数据还原出来，然后写入到目标数据源。（6）管道管理管道管理器负责管理数据交换过程中的传输管理，包括管理的创建、动态分配、撤消等操作。（7）日志监控日志监控按级别记录数据交换引擎在运行过程中的事件记录，提供监控功能。（二）数据接口数据共享交换平台支持三种数据接口方式：交换库方式、文件方式以及Web服务方式，业

19、务系统通过交换平台进行数据共享交换时，可以根据实际的情况选择合适的数据接口方式接入交换平台。在接入节点时，根据实际情况选用一种或多种接口类型。对于有业务系统存在，只要求提供或获取共享业务数据的情况，建议采用数据库类型接口；对于需要获取基础数据的情况，以及实时性要求高的情况，建议使用Web 服务类型接口；文件类型接口根据实际情况决定是否采用。1.4.1.2 目录管理服务子系统目录管理服务子系统是支撑平台的核心子系统，提供政务数据资源目录的注册管理以及政务数据资源的发现定位服务。主要功能包括：(1)目录管理提供数据主题的管理功能，数据主题包含了对数据资源的语义信息和规格信息等；提供对目录层次结构的

20、管理，包括系统自动管理以及手工管理两种方式。(2)目录服务按部门、专项以及分类标签等方式浏览数据资源目录；提供数据资源的检索和统计功能。1.4.1.3 共享数据管理子系统共享数据管理子系统是支撑平台的一个基础子系统，是实现数据资源共享交换的基础。主要功能包括：(1)数据标准管理提供公共数据元、信息分类和代码的配置管理功能。(2)数据源管理提供数据源的配置管理功能。(3)数据质量管理提供对共享数据的质量管理功能，包括问题数据的查询、浏览和统计。1.4.1.4 共享业务管理子系统共享业务管理子系统是支撑信息共享申请、授权业务开展的系统。主要功能包括：(1)共享业务流程提供对共享业务流程的支撑功能，

21、包括共享业务申请和审核。(2)共享业务统计提供按部门、业务状态和业务时间等维度对共享业务统计功能。1.4.1.5 系统配置管理子系统系统配置管理子系统是支撑平台的一个基础子系统。主要功能包括：(1)共享域提供政务数据资源共享域的信息配置功能。(2)全局配置提供组织机构、系统信息等全局配置功能。1.4.1.6 系统安全管理子系统系统安全管理子系统是支撑平台的一个基础子系统。主要功能包括：(1)用户管理提供用户、用户组、角色管理功能。(2)权限管理提供基于角色（RBAC）的权限管理功能。(3)操作日志提供用户操作日志的查询和导出功能。1.4.2 数据共享交换平台1.4.2.1 交换网络结构一般数据

22、交换有两种常见的交换结构：星型交换和网状交换。在星型交换结构中，所有端节点都只与中心节点相关，通过中心实现数据交换；而网状交换结构中，数据可以在任意两个节点之间直接交换。经过调研和分析，XX市各政府部门之间存在着复杂的数据共享和交换需求，并存在以下特点：（一）同一批共享数据通常需要共享给多个子系统；（二）对同一批数据，不同的子系统应用的需求存在差异；（三）各个子系统独自开发，技术平台不一，数据标准不一；（四）数据共享和交换要求进行备案。因此，XX市电子政务数据灾难备份中心采用星型交换结构，如下图所示：图表 2 星型数据交换结构采用星型交换结构有以下的优点：（一）避免重复提供数据如果同一批数据，

23、有多个子系统需要共享，在星型交换结构中，数据提供方只需要提供一次数据。根据以上的分析，这种情况在本期项目是普遍存在的，星型交换结构有助于减少接入单位在开发、调试、实施、维护等各个阶段的工作量。（二）中心统一控制简化管理在网状交换结构中，交换服务分布在每一个节点，因此在进行服务管理时需要对每一个节点进行管理。这样数据共享交换平台的服务管理系统可能会设计成一个分布式的管理系统，或者是让管理员分别登录到不同的节点进行管理。无论采用何种实现方式，管理员都必须面对在N个不同节点上管理服务的问题。而在星型交换结构中，所有的交换服务都是集中在中心端，管理员只需要管理中心节点上的服务。（三）降低实施过程对网络

24、连接的要求提供稳定可靠的数据交换服务，是数据共享交换平台的关键任务，采用星型交换结构，只需要保证各个端节点与中心节点之间的网络正常联通，而采用点对点网状交换结构则需要保证每两个点之间都联通。在实施过程中，不一定能保证每两个交换节点之间网络联通。因此采用星型交换结构在一定程度上降低数据共享交换平台的实施要求。1.4.2.2 交换概念模型交换概念模型由中心交换结点和端交换结点组成。端交换结点接收和发送政务部门的交换信息。中心交换结点管理交换网络内端交换结点的数据交换服务，并根据需求形成共享信息库。交换的概念模型如下图所示：图表 3 数据交换概念模型交换概念模型说明如下：（一）业务信息是由各政务部门

25、产生和管理的政务数据资源；（二）交换信息是端交换结点用于存付参与交换的政务数据资源；（三）共享信息库是可以为多个端交换结点提供一致的政务数据资源的信息集中存储区。任意一个端交换结点是可以按照一定的规则访问共享信息库。（四）端交换结点是政务数据资源交换的起点或终点，完成业务信息与交换信息之间的转换操作，并通过交换服务实现政务数据资源的传送和处理；（五）中心结点主要为交换信息提供点至点、点到多点的信息路由、信息可靠传送等功能。在两个端交换结点之间可以有0个或若干个中心交换结点；（六）交换服务是交换结点传送和处理政务数据资源的操作集合，通过不同交换服务的组合支持不同的服务模式。交换服务按照数据交换任

26、务的重要性以及时效性要求设置为不同的优先级。一般情况下，交换服务按照预先设定的调度计划执行。在服务器、网络资源紧缺的情况下，高优先级的交换服务可以优先执行，确保满足数据交换的时间要求。1.4.2.3 交换体系结构XX市数据共享交换平台由中心交换节点和端交换节点组成，依托统一的电子政务外网，通过采用一致的交换协议，实现跨地区、跨部门应用系统之间的数据交换。XX市电子政务数据灾难备份中心作为中心交换节点，各政务部门的前置机作为端交换节点。政务部门业务系统通过交换桥接实现与前置机互联，接入数据共享交换平台。XX市电子政务数据灾难备份中心的交换体系架构如下：图表 4 交换体系架构业务库是由各政务部门产

27、生和管理的政务数据资源库。交换库是政务部门提供本部门交换数据、获取其他部门交换数据的存储库。交换文件作用与交换库相同，把政务部门提供本部门交换数据、获取其他部门交换数据以文件形式存放在前置机上。中心交换节点提供交换数据的采集、分发服务，实现交换节点之间的数据路由和传送功能。端交换节点提供交换数据的存储库、数据写入和读取接口以及文件上传和下载接口，业务系统与端交换节点之间通过交换桥接进行交换数据的提供和获取，并实现业务数据和交换数据之间的转换。端交换节点是交换平台中数据交换的起点或终点。数据交换过程可分为数据提供、数据采集、数据分发和数据获取四个阶段： （一）数据提供：数据从提供方的业务系统转换

28、并传输到提供方的前置机；（二）数据采集：数据从提供方的前置机传输到中心节点；（三）数据分发：数据从中心节点传输到使用方的前置机；（四）数据获取：数据从使用方的前置机传输并转换到使用方的业务系统。其中，数据提供和数据获取流程由政务部门的交换桥接负责。数据采集和数据分发流程由中心数据共享交换平台负责。业务系统可以通过公开Web服务的方式向数据灾难备份中心或其他政务部门提供数据。政务部门获取数据时，也可以直接从数据提供方公开的Web服务获取数据。数据灾难备份中心公开的Web服务主要用于共享基础数据，业务系统可以调用数据灾难备份中心的数据共享服务查询基础数据。1.4.3 共享数据管理系统1.5 数据处

29、理和存储系统建设方案1.5.1 数据处理设计在没有数据标准的时候，数据灾难备份中心对同一个数据字段可以从多个数据来源采集数据。如：婚姻状态字段可以从计生部门和民政部门采集。对于同一个数据字段，数据灾难备份中心对于该数据字段保存多个来源的版本。公共数据维护系统提供工具、服务来展现数据的不一致性，数据管理员根据工作制度，对数据字段进行电话等多种手段核实字段的真实数值，如果在一定的时限内不能解决冲突，则可以发布该数据字段的多个版本，每个版本都标明数据字段的来源，并指示该数据是存在冲突的。通过数据共享与交换平台以数据服务的方式从各业务部门采集数据，保存到公共数据缓存库，使用公共数据维护系统进行数据比对

30、、冲突检查、数据审核、数据转换。当数据达到一致性、完整性要求时，数据被发布到公共数据发布库，通过数据共享与交换平台以数据服务的形式提供数据使用方访问。数据管理系统面向数据灾难备份中心和业务部门的数据管理员，确保数据的一致性、准确性和完整性，为数据质量把关。1.5.1.1 功能设计 数据管理工作流实现对数据管理的主要工作流程的管理，方便业务部门提供、使用和交换数据。比如从数据使用方提出申请，然后数据提供方进行审核，然后双方协商数据交换规则到最后配置实现的整个工作过程的管理。 数据转换建立业务部门数据于标准规范数据的转换映射关系和转换规则，将业务部门的数据转换为符合标准规范的数据。 数据整理对缓存

31、数据库中的各业务部门数据进行比对、清洗，检查数据冲突，对数据进行审核校验。确保数据一致性、完整性。 数据发布数据管理系统把经过比对、审核、转换之后的具有完整性、一致性的数据保存到数据灾难备份中心的发布数据库，经过数据共享与交换平台发布提供各业务部门使用。 主题管理数据灾难备份中心以主题为单位实现数据采集、数据交换、数据共享、数据比对以及数据发布。因此必须提供主题管理功能。 元数据管理对共享数据进行元数据管理，以主题的方式组织数据资源。 数据标准管理对数据标准的内容、数据标准的版本进行管理，将标准变更对业务系统的影响屏蔽在数据接口系统一级。 数据维护通过数据管理系统进行日常的数据维护工作，如：数

32、据备份恢复。提供对业务系统的异地容灾数据备份的管理支持。1.5.1.2 逻辑结构数据管理系统以主题的方式组织数据资源，提供元数据管理、数据供需关系管理、数据标准规范管理，与数据共享与交换平台结合，提供数据转换、整理、发布等功能。数据管理系统逻辑结构示意图1.5.1.3 数据接口系统数据灾难备份中心的共享交换网络由数据灾难备份中心的数据共享交换系统和部署在各市级业务部门、区政府数据灾难备份中心的数据接口系统构成。数据接口系统由3部分组成：数据共享和交换系统、缓存数据库、数据管理系统。数据接口系统提供业务部门和数据灾难备份中心、业务部门之间的接口功能，在统一的数据共享与交换平台下进行安全、可靠、有

33、效的数据共享与交换，并提供元数据管理、主题管理、数据供需关系管理、数据标准版本管理、数据安全管理。数据接口系统不直接影响业务系统的日常运作。数据共享和交换的细节、安全性和权限控制都在数据接口系统中封装，并在统一的规范下，由业务部门进行管理。数据接口系统与业务系统是松耦合的关系。图表 1.51 数据接口系统逻辑结构1.5.2 存储系统设计1.5.2.1 设计原则由于XX市电子政务数据灾难备份中心存储了所有相关的业务数据、统计数据等重要数据，存储系统作为数据存储的设备，对于它的可靠性要求很高。存储设备必须满足以下需求： l存储系统必须具有高性能、高可靠性和足够的容错特性，提供多种信息保护、共享、管

34、理方案，以保证信息的高可用性 l必须拥有足够的系统扩充性，以支持目前社会保障的数据容量，同时还要考虑未来业务的发展。 l高性能智能型企业存储，对主机CPU的性能无影响，将主机资源充分应用于业务系统，同时还要考虑未来业务的发展 l具备多平台、企业级的连接能力，以便于主机的选型和系统的整合 l满足作数据远程镜像备份（容灾）的要求1.5.2.2 主流存储技术比较及建议1. 直连方式存储 (Direct Attached Storage-DAS)存储设备是通过电缆（通常是SCSI接口电缆）直接到服务器。I/O请求直接发送到存储设备。这种方式是连接单独的或两台小型集群的服务器。它的特点是初始费用可能比较

35、低。可是这种连接方式下，对于多个服务器或多台PC的环境，每台PC或服务器单独拥有自己的存储磁盘，容量的再分配困难；对于整个环境下的存储系统管理，工作烦琐而重复，没有集中管理解决方案。所以整体的管理成本较高。2. 网络连接存储（Network Attached Storage - NAS）NAS设备通常是集成了处理器和磁盘/磁盘柜，类似于文件服务器。连接到TCP/IP网络上（可以通过LAN或WAN），通过文件存取协议（例如NFS，CIFS等）存取数据。NAS将文件存取请求转换为内部I/O请求。这种方式是将存储设备连接到基于IP的网络中，不同于DAS和SAN，服务器通过“File I/O”方式发送

36、文件存取请求到存储设备NAS。NAS上一般安装有自己的操作系统，它将File I/O转换成Block I/O，发送到内部磁盘。NAS系统有较低的成本，易于实现文件共享。但由于它是采用文件请求的方式，相比块请求的设备性能差；并且NAS系统不适合于不采用文件系统进行存储管理的系统，如某些数据库。3. 存储区域网络（Storage Area Network - SAN）存储设备组成单独的网络，大多利用光纤连接，采用光纤通道协议（Fiber Channel，简称FC）。服务器和存储设备间可以任意连接，I/O请求也是直接发送到存储设备。光纤通道协议实际上解决了底层的传输协议，高层的协议仍然采用SCSI协

37、议，所以光纤通道协议实际上可以看成是SCSI over FC。存储区域网络的优点如下：服务器和存储设备之间更远的距离（光纤通道网络：10公里相比较DAS的SCSI：25米）； 高可靠性及高性能； 多个服务器和存储设备之间可以任意连接 集中的存储设备替代多个独立的存储设备，支持存储容量共享； 通过相应的软件使得SAN上的存储设备表现为一个整体，因此有很高的扩展性； 可以通过软件集中管理和控制SAN上的存储设备，提供数据共享由于SAN通常是基于光纤通道的解决方案，需要专用的光纤通道交换机和管理软件，以SAN的初始费用比DAS和NAS高。4IP SAN如果SAN是基于TCP/IP的网络，实现IP-S

38、AN网络。这种方式是将服务器和存储设备通过专用的网络连接起来，服务器通过“Block I/O”发送数据存取请求到存储设备。最常用的是iSCSI技术，就是把SCSI命令包在TCP/IP 包中传输，即为SCSI over TCP/IP。IP SAN的优势在于： 利用无所不在的以太网络，一定程度上保护了现有投资。 IP存储超越了地理距离的限制，适合于对关键数据的远程备份。 IP网络技术成熟,不存在互操作性问题 IP存储减少了配置、维护、管理的复杂度。 IP网络已经被IT业界广泛认可网络管理软件和服务产品可供使用 千兆网的广泛使用大大提高了IP网络的性能 万兆网络技术的发展，使IP存储在性能上可以超越

39、FC存储总结：性能上：FC性能最好，单端口可以达到2Gbps的带宽；NAS性能最差，即使采用千兆网络，通常只能3040MBps；单千兆iSCSI可以达到6070MBps；万兆网络下，单万兆口的速度可以超过500MBps。扩展性上：FC和iSCSI采用SAN的架构，扩展性最好，在存储网络中，易于增加用户或增加存储模块。应用成本上：FC的应用成本最高，需要配套的昂贵的光纤交换机（8端口光纤交换机大约34万元）；每个服务器需要配光纤通道卡（光纤通道卡50001万元）；以及采用光纤介质；相比之下，iSCSI只需要普通的以太网交换机（8端口千兆交换机1000元）；服务器本身带有千兆网口，即使增加一个网卡

40、也就是500元，采用普通的超五类线就可以，价格可以忽略不计；市场定位：FC占据高端，iSCSI处于中高端，NAS和DAS处于低端结论：综合比较San，Nas，ip-san等主流存储技术，建议使用IP-SAN实现。1.5.2.3 Raid类型配置建议存储系统中主要的RAID技术有RAID0（条块化）、RAID0+1（条块化并镜像）、RAID5。采用RAID0技术最经济，存储空间利用率为100%，性能也最好，但是数据没有冗余保护，生产系统中一般不采用。RAID0+1技术性能仅次于RAID0，但经济性最差，存储空间利用率为50%，数据安全性最好。RAID5存储空间利用率超过80%，数据也有冗余保护，

41、但性能差于RAID0+1，但在存储系统Cache比较大的时候性能也基本可以保证。从应用需求看，应用对IO系统的传输带宽并不敏感，而对IO系统单位时间内能提供的IO次数要求比较高。同时，对文件处理和数据库批处理而言，鉴于单个文件或数据库表空间很南分配到不同的存储系统上，因此单个存储系统的IO指标越高越好。要提高IO系统在单位时间内的IO处理次数，可以通过配置比较好的RAID控制卡和比较大的读写Cache实现，但从节省投资方面考虑可以选择RAID5，应用软件中采用了许多先进的技术，如大内存处理、多进程多线程等技术，可以显著解决IO的瓶颈，因而RAID5也可以保证系统性能。1.6 服务器系统建设方案

42、（原提纲写的是终端系统建设方案）1.6.1 设计原则在服务器系统设计中，我们遵循以下的原则：实用性无论对于何种计算机系统，实用性永远是需要放在首位和着重考虑的。一个系统的建设是一项工程的实施，它的最基本的目标是建立一个适用实际环境的、能满足用户功能需求的实用系统，而不是一味追求技术的领先和产品的更新。广泛采用标准随着计算机技术的发展，芯片技术、存储系统、各种传输协议以及与外部系统的接口等都已逐渐形成标准。采用标准化的设计，能使系统具有良好的可扩充性及兼容性，能与其他厂商产品配套使用，给各种系统软件和应用软件的安装运行带来方便，同时有利于系统的升级和与其他系统的数据交换。先进性与适用性的统一计算

43、机技术的发展与时间不是简单的线性关系，从投资保护及长远考虑的角度来看，在系统设计时保持一段时间的先进性也是十分必要的，重要的是把握好先进性与实用性和适用性之间的关系，取两者之间的最佳平衡点，使用户的投资得到最大化的收益和回报。注重售后服务衡量设备及产品的优劣，不仅应以设备及产品本身的质量作为尺度，还应充分考虑厂商的售后服务。在系统正常使用情况下，软硬件的及时升级、维护，以及在系统出现故障时修复响应时间、备品备件的充足程度等，都将直接影响到整个系统的运行状况。因此，选择优秀的设备供应商和全面考察供应商的售后服务情况也是服务器系统选择中重要的原则之一。1.6.2 服务器系统选择的依据服务器系统的运

44、算能力和I/O能力往往是考察系统性能优劣的重要指标。目前较为普遍采用的一个衡量服务器系统处理能力的参数是TPMC值，TPMC值是测试单台服务器或集群系统在配备特定的操作系统，采用特定的数据库的情况下每分钟处理事务的能力（Transaction Per Minute）。TPMC值越高说明系统处理能力越强。通常情况下，用户的应用每秒钟会触发几个事物这一基准数据的取值范围是可以定量计算的，这样针对某个联机事物处理系统，对系统服务器的选择就可以参照服务器的TPMC值来确定了。但是同时也应该看到，服务器TPMC值是通过实验手段取得的，某系统的TPMC值是在其生产厂商所送检的特定配置的服务器硬件 + 特定

45、配置的操作系统 + 特定配置的数据库系统所得出的事物处理能力的衡量，其配置中任何一项的变化都可能会对TPMC值有很大的影响。例如在硬件和操作系统不变的情况下，改变数据库系统类型或它的配置，就可能在很大程度上改写系统的TPMC值，不可忽视的是，应用软件设计和编码的好坏能在更大程度上影响系统的事物处理能力。所以对TPMC值的作用，仅可以用作参考，不可以生搬硬套，按照一般的原则，选择服务器时一般对TPMC值要求要高一些。1.6.3 需求分析需求分析数据灾难备份中心服务器系统的特点是业务复杂，处理数据量较多，连接用户数多，服务器的选型，主要应考虑以下几方面的因素：服务器的运算能力服务器的处理需要考虑对

46、高峰时业务受理的实时响应，考虑业务的复杂性，服务器需要实时的与多个业务分系统进行数据采集、比对、整理和分发。需要服务器有很高的处理能力。服务器的内存服务器还需要对实时产生的数据进行实时汇总、分发。要实现汇总、分发的实时高效，需要将实时信息放入内存，进行处理，才能提高系统的性能，这样服务器需要有较高的内存。高的I/O能力对每天生成的数据需要实时入库，需要有很强的I/O能力，使得数据的入库不会成为系统的瓶颈。系统扩展在追求数据服务器单机高性能时，也需要考虑业务巨大时的系统负载的分流，系统在规划设计时，在软件设计上进行合理处理，使得应用可以在单机上运行，也可以有不同的服务器上进行任务分担，共同完成实时的业务处理。1.6.4 性能测算服务器系统是整个数据灾难备份中心的心脏，负责管理数据灾难备份中心的基础信息、共享信息、各专业区域信息以及业务应用过程中发生的相关业务数据、以及数据管理的过程中产生的比对信息、整理信息、管理信息等,同时为各个分系统提供共享信息。服务器的处理能力作用体现在每秒钟的事务处理数量上。事务处理主要包括卡业务受理、数据的实时汇总、入库、分发等功能。根据日业务量可以推算出服务器每秒需要处理的事务数。