建议xx银行灾备中心（同城、异地）从模式2向模式1转变，无论采取上述两种模式的哪一种，灾备中心对核心应用都应该提供应用级的恢复能力，即生产中心与灾备中心共同构成双活中心；
4.2 数据中心架构
基于当前整体应用系统向总行集中的策略，本次IT基础设施的规划重点将放在总行数
据中心。通过本次对xx银行IT基础设施的调研，xx银行已经准备进行两地三中心的整体架构设计(生产中心、本地灾备中心、异地灾备中心)，确保了银行业务系统的高可用性。基础设施的各个方面也符合原有数据中心建设的策略、原则和模型(Server Farm 1.0)，保证了资源的集中部署和管理，同时也参考了业界的最佳技术实践，做了一些基础设施完善的工作（如：服务器整合、部分IT运维流程实施等）。但是，整体资源的利用率较低，资源分配的灵活性不足，总体投资回报率不高，基础设施规划缺少先进的标准（Server Farm 2.0），IT运维缺少系统化的、有方法论支持的架构和统一的平台，基础设施服务对应用的支持层次较低。
针对xx银行的现状，本次规划将从数据中心架构的角度给出未来xx银行IT基础设施架构设计的策略、原则和模型，并分章节详细介绍基础设施各个领域的具体规划和设计。 4.2.1 架构设计策略
本着基础设施服务全行业务，基础设施各业务系统共享的基本原则，架构设计的整体策略是：
? 统一规划建设，统筹分配系统资源，建立运行环境安全可靠的系统基础平台； ? 充分考虑硬件发展趋势，具有一定的新技术吸纳能力和扩展能力，使系统资源能够
随业务扩张而逐步增加；
? 能够达到随需应变运行环境的目标架构。
4.2.2 架构参考模型 4.2.2.1
灵活的基础架构
要做到资源的随需分配，就要建立一个灵活的硬件基础架构。硬件基础架构通常由虚拟的服务器池、共享的存储系统、网络和硬件管理软件组成。
第 31页 /共 38页
服务器在 IT 环境里是负责提供计算能力的资源，应该按照服务器的功能建立虚拟的服务器池，如数据库服务器池、应用服务器池、Web 服务器池等。在实施资源部署时，计算资源分别从不同的服务器池中划分出来。就目前的技术而言，在多台独立的物理服务器之间实现资源的调整是比较困难的，因此应该尽量减少物理服务器的数量，利用先进的分区技术或者虚拟机技术实现物理服务器内部资源的动态调配。
后面的章节将分别对基础设施的各个实体的虚拟化进行介绍：网络虚拟化的考虑、服务器虚拟化的考虑、存储虚拟化的考虑。 4.2.2.2
自动化资源部署
资源自动部署负责执行 IT 资源的自动分配和回收。要实现资源的自动部署，必须做到：首先，建立一个中心数据库来管理数据中心的硬件资源；第二，要规范资源的使用，比如说标准化操作系统、数据库软件、中间件软件的种类和版本，一般版本数不超过两个；制定一个命名的规范，包括服务器主机名、文件系统名、数据库实例名、文件名、用户名等。资源的自动部署是通过端到端的服务流程来启动的，其执行结果通过端到端的服务流程反映给 IT 系统管理部门人员和业务/应用开发部门。
自动化部署/调整服务章节将单独介绍自动化部署。 4.2.2.3
端到端服务请求管理平台 需要建立一个统一的管理平台来实现端到端的流程管理，采用工作流引擎来协调企业内各个部门的合作，提高管理效率。IT运维管理章节将介绍统一管理平台。 4.2.2.4
标准化 IT管理规则 为了实现规范管理，必须为数据中心制定一套完整的管理规则，内容包括：事件管理、问题管理、变更管理、配置管理、发布管理、操作管理、服务级别管理、可用性管理、容量管理。IT运维管理章节将介绍以上服务管理流程。 4.2.3 架构设计原则
xx银行的基础设施架构设计将采用分层的、模块化的现代数据中心设计理念，以实现对业务系统提供统一的基础设施服务支持的目标。具体设计原则如下：
第 32页 /共 38页
4.2.3.1
安全性
基础设施必须是能够提供访问控制能力的环境，以确保业务关键信息的完整性与保密性。 4.2.3.2
可扩展性
可扩展性是指当将来应用系统的业务量增加时，基础设施架构能够扩展以适应更多用户、交易与更多数据处理的能力。 4.2.3.3
灵活性
架构必须能够满足新的服务需求，而不需要对架构进行完全重新设计或进行超出正常维护时间之外的重大修改，获得灵活性的方法是依靠模块化的设计架构。 4.2.3.4
可靠性与可用性
基础设施架构中应采用高可靠的产品和技术，充分考虑系统的应变能力、容错能力和纠错能力，确保整个基础设施系统运行稳定、可靠。 4.2.3.5
高性能
“性能”指的是为所有应用最终用户提供要求的响应时间的能力。基础设施架构要具备高性能，能够为用户提供可接受的响应时间.
4.3 服务器架构
4.3.1 服务器架构现状 4.3.2 架构描述
从服务器架构发展趋势上，目前大部分的银行应用程序都是基于B/S的三层架构或者正逐渐向三层架构转移。在三层架构中，Web服务器在前端与用户进行通信，应用服务器在中间用于实际的数据处理和分析，数据库服务器位于后端用于数据的存储。这种三层的应用程序架构不但提供了架构的可扩展性、灵活性，而且有助于在数据中心中构建更高级别的可靠性和安全性。例如，通过新增前端web服务器集群，可实现性能、架构的扩充；基于B/S架构的应用可以灵活、方便的加入服务器的整体架构；位于不同层的服务器可以接入到不同的网络中，部署不同级别的安全机制，从网络访问上提供了更可靠的安全性等。
第 33页 /共 38页
服务器的部署原则是高端、基于RISC架构服务器将被用于应用服务器和数据库服务器，从而为应用程序提供高性能、高可扩展性（主要是scale up）和高可靠性。而前端服务器，例如Web服务器，将运行在基于CISC Intel架构的Linux服务器上，提供良好的扩展性（主要是scale out）。
? 数据库服务器 ? 应用服务器 ? Web服务器
一般而言，在上述三层应用架构中，服务器均可以通过横向及纵向扩展提高可用性，但是在选择扩展方式时可用结合服务器特点进行选择. 4.3.3 服务器资源的共享策略
现阶段xx银行的服务器资源配置充分保证了应用系统的高可用性，但资源使用率相对偏低。应用系统多采用竖井式的应用架构，一套应用对应了一套服务器，导致资源使用度不平衡、服务器数量大、增长速度快、维护成本高。因此在保证高可用性的前提下，为提高服务器的资源利用率，建议采用服务器资源共享的策略。例如在一台服务器上如果能够部署多个峰值错开的应用系统，实现多个应用系统共享服务器的资源，将会提升服务器的资源利用率。
从技术上讲，此服务器架构设计具备这种能力，能够满足不同应用系统的共享需求的实现，即将遵守相同规则的不同应用系统部署到同一台物理服务器或逻辑分区上运行，实现同一台物理服务器或同一逻辑分区的资源共享。 4.3.4 数据库服务器高可用建议
由于数据库服务层涉及持久层，它的高可用性架构需要根据具体需求进行选择，因此针对数据库及服务器的高可用性，将介绍以下几种业界标准的架构方案： 4.3.4.1
主备方式（Hot－Standby） 该方式是所有数据库产品都支持而且最常用的一种架构方案，该架构中将部署两台服务器，生产数据库运行在生产节点服务器上，备份节点处于standby状态，不处理任何业务。当生产节点发生故障宕机后，备份节点将接管生产节点的全部资源，并恢复数据库的运行。
第 34页 /共 38页
4.3.4.2
双机互备（Active－Active）
该方式也是所有数据库产品都支持的一种架构方案，该架构中，两个节点都是生产节点，每个生产节点上都运行一个生产数据库，但每个生产节点同时又是另一个生产节点的备份节点，相互备份。当其中一个生产节点发生故障当机后，另一生产节点（备份节点）将接管生产节点的全部资源，并恢复数据库服务的运行。此时，在该生产节点上，将会同时运行两个生产数据库。 4.3.4.3
一备多方式（N+1） 该方式也是所有数据库产品都支持的一种架构方案，该架构中，有一个节点是备份节点，其余的节点是生产节点，备份节点是群集中其他生产节点的备份主机，共同组成一个“一备多”的架构。在每个生产节点上都运行一个生产数据库，当其中一个生产节点发生故障宕机后，备份节点将接管生产节点的全部资源，并恢复数据库服务的运行。 4.3.4.4
并行处理（集群）
数据库服务器的并行处理技术，在当前的数据库产品中，Informix数据库不支持，只有oracle的共享磁盘和DB2的非共享群集技术。通过采用并行技术，可以实现架构的横向扩展。
Oracle： RAC是Oracle的一种并行数据库群集技术，是Oracle9i企业版的一个选项。Oracle数据库使用RAC可以实现多达8个节点的群集。RAC使多台服务器可共享数据库存储。通过一个群集内部连接技术-CacheFusion，高达8台数据库服务器节点使用SCSI或光纤通道技术与存储设备连接，共享数据库存储。多个节点可以同时处理业务请求，其中一个节点故障，群集可以继续工作，保证了高可用性。 4.3.4.5
高可用实施原则
综上所述，主备方式抵御故障能力最强，代价也最高。由于数据库并行处理适用的局限性以及应用并不广泛，因此不建议使用。在选择高可用方案时，应该充分考虑不同应用系统的不同要求，参考原则如下：
? 重要的系统实施主备方式或者互备方式，非重要的系统则实施一备多（N+1）； ? 采用主备方式的系统，备机配置与主机配置相同；
? 采用N+1方式备份的系统，备机的配置应和该群组中最大配置主机相同；
第 35页 /共 38页