BS结构应用系统技术规范

开放平台B/S结构应用系统技术规范总则为了保证全行开放平台B/S结构应用系统的健康、稳定运行，加强对开放平台B/S结构应用系统建设的统一规划，特制定和下发本规范。本规范制定了开放平台B/S结构应用系统的客户端、WEB服务器、应用服务器、数据库服务器四个层次的软硬件配置规范，并对WEB服务器、应用服务器和数据库服务器三个层次提出了部署的具体要求，从负载均衡、系统备份等方面详细描述了服务器的部署规范。此外，还制定了群组划分、服务器整合的原则。本规范的适用范围是：总行信息科技部、各一级分行及直属分行（以下简称“分行”）信息科技部、数据中心（北京）、数据中心（上海）、海外数据中心、软件开发中心（以下简称“各中心”）。B/S结构服务器部署规范概述传统意义下的B/S应用系统的结构分成三层，分别是浏览器层/服务器层/数据库层，服务器层可以细分为WEB服务器、应用服务器两层。由于考虑处理能力、不同服务器之间的关联性等多方面的因素，往往分别为这两层服务器配备不同的硬件，因此，目前的生产环境的服务器硬件相对较多。为了方便管理、合理利用开放平台资源以及提高运行稳定性，需要从结构和平台两个方面依据一定的规范进行整合。虽然这些应用系统完成的功能互不相同，但是，基本上都是使用相同的体系结构、相同的开发平台，具有整合的可能性。本章重点分析我行B/S结构应用系统WEB服务器层、应用服务器层的物理和逻辑结构，然后确定这两个层次的结构和每个层次中服务器的软硬件平台版本、负载均衡策略和系统的备份策略。B/S结构应用系统的分析从应用系统的物理或逻辑结构来分析，我行B/S结构应用可以分成两大类，一类是典型的J2EE应用，即WEB服务器、应用服务器和数据存储服务（包括数据库和主机应用）；另一类是基于微软技术的应用，包括WEB服务器和数据存储服务两层。从目前的实际情况看来，绝大部分应用都是典型的J2EE应用，只有个别应用是采取微软技术的，并且已经有明确的版本计划要进行平台移植，最终都会统一用典型的J2EE技术。本章只对典型的J2EE应用进行分析，对其平台和负载均衡技术进行描述。J2EE应用系统的三个层次典型的B/S结构J2EE应用系统分多个层次，本节只论述客户端、WEB服务器和应用服务器三个层次，如下图所示。客户端为IE浏览器；客户端通过网络访问WEB服务器，WEB服务器负责交易画面的显示；真正的业务逻辑处理是在应用服务器完成的；后台的业务处理系统完成真正的业务处理如账务处理等。IEIEIEIEWAN/LANWEB服务器应用服务器数据库服务器主机客户端浏览器用户利用浏览器客户端程序通过广域网（或内部网）以HTTP或HTTPS通讯协议访问指定的WEB服务器。要求所有的B/S结构应用至少支持IE浏览器，目前要求支持的IE版本是6.0或以上版本。WEB服务器WEB服务器只完成静态页面或动态页面的显示和一些简单的诸如数据完整性检查等简单逻辑，复杂的逻辑处理都在应用服务器上完成，WEB服务器通过应用服务器插件将具体的请求发送给应用服务器，然后应用服务器将响应返回给插件，再由WEB服务器组合相关信息返回到客户端。WEB服务器软件支持在一台物理设备上运行多个应用，即在一台机器上建立多个网站。因此，WEB服务器可以整合。应用服务器所有的业务处理逻辑的实现，都在应用服务器上完成，主要包括这样一些处理：从数据库中取出相关的数据进行处理（如判断数据是否有效，对数据进行格式化等）；向后台应用系统发送请求和接收响应（如从主机中实时查询账户的余额，从中间业务平台中查询客户的手机费等），都需要对数据按照不同的要求进行相应的处理。应用服务器软件支持在一台逻辑的或物理的设备上同时安装多个应用，即建立多个虚拟服务器，分别对应不同的网站。因此，应用服务器可以进行整合。负载均衡B/S结构应用系统的七个概念为了更详细地讨论负载均衡机制，需要先为B/S结构应用系统定义下述概念。物理WEB服务器物理WEB服务器是指安装WEB服务器的物理机器。逻辑WEB服务器逻辑WEB服务器是指物理WEB服务器上运行的一个进程。因此，一个物理WEB服务器上可以有多个逻辑WEB服务器。不同的逻辑WEB服务器使用不同的端口，例如逻辑WEB服务器1使用80，逻辑WEB服务器2使用81，如此类推。但必须在负载均衡设备上把这些端口映射为80端口。如图：物理WEB服务器(一台机器)物理WEB服务器(一台机器)逻辑WEB服务器1（一台机器上的进程1）逻辑WEB服务器2（一台机器上的进程2）逻辑WEB服务器n（一台机器上的进程n）……物理应用服务器物理应用服务器是指安装应用服务器的物理机器。逻辑应用服务器逻辑应用服务器是指物理应用服务器上运行的一个进程。因此，一个物理应用服务器上可以有多个逻辑应用服务器。如图：物理应用服务器(一台机器)物理应用服务器(一台机器)逻辑应用服务器1（一台机器上的进程1）逻辑应用服务器2（一台机器上的进程2）逻辑应用服务器n（一台机器上的进程n）……应用程序一个应用程序就是一个业务应用系统。同一个逻辑应用服务器上可以安装多个应用程序，一个应用程序就是一个逻辑应用服务器中的一个功能模块。一个应用程序只能在同一个逻辑应用服务器上安装一份。逻辑应用服务器(一台机器上的进程)逻辑应用服务器(一台机器上的进程)应用程序1（功能模块1）应用程序2（功能模块2）应用程序n（功能模块n）……同样，一个逻辑WEB服务器上也可以放置多个应用程序的静态文件，一个应用程序必须有独立的虚拟目录，所以不同应用程序中的静态文件应该放在不同的虚拟目录中。同样，一个应用程序只能占用逻辑WEB服务器上的一个虚拟目录。如下图所示：逻辑WEB服务器(一台机器上的进程)逻辑WEB服务器(一台机器上的进程)应用1的虚拟目录应用2的虚拟目录应用n的虚拟目录……分离部署分离部署是指把逻辑WEB服务器和逻辑应用服务器安装在不同的机器上。通常，逻辑WEB服务器使用PC服务器，逻辑应用服务器使用UNIX服务器。如下图所示：PC服务器PC服务器前端请求WEB服务器应用服务器UNIX服务器分离部署分离部署还存在其他的方式，下图所示是其中一种：PC服务器PC服务器前端请求WEB服务器应用服务器UNIX服务器分离部署2WEB服务器应用服务器前端请求合并部署合并部署是指把逻辑WEB服务器和逻辑应用服务器安装在同一台机器上。如下图所示：前端请求前端请求应用服务器UNIX服务器WEB服务器合并部署合并部署还存在其他方式，下图所示是其中一种：前端请求前端请求应用服务器UNIX服务器WEB服务器合并部署2WEB服务器前端请求负载均衡必须考虑的两种情况为B/S结构应用系统服务器做负载均衡，其目的就是让多个服务器上的应用程序均匀地分担用户的压力，提高应用的可用性和故障抵御能力。实际上，为服务器做负载均衡就是为应用程序做负载均衡。但是，要让做了负载均衡后的应用系统能正常安全的运作，必须考虑会话保持和安全性两个问题。会话保持目前，我行的大多数应用程序存在如下特点：如果一个应用程序（下称应用A）安装在多个逻辑应用服务器上，这些逻辑应用服务器做了负载均衡，则当一个用户在其中一个应用程序实例上登录成功，那么他的会话仅在这一个应用程序实例上有效，这个会话对于这个群集中的其他应用程序实例均是无效的，因此，在负载均衡器的策略中，必须把这个用户的后续请求路由到这个应用程序实例上。这种情况叫做会话保持。服务器n服务器n服务器2服务器1应用A1应用A2应用An用户1用户2……如上图，若用户1在应用A1上登录成功，则用户1的会话只在应用A1的实例中存在，在其他应用程序实例中无用户1的会话；若用户2在应用A2上登录成功，则用户2的会话只在应用A2的实例中存在，在其他应用程序实例中无用户2的会话。安全性当应用程序需要更高的安全性时，需要把物理WEB服务器部署在DMZ区，应用服务器部署在高安全性区。WEBWEBWEBAPPAPPAPPIEIEIEInternet/IntranetDMZ负载均衡中各种服务器的部署方式为提高B/S结构应用系统的可用性和故障抵御能力，需要采取负载均衡技术。负载均衡技术的系统逻辑结构如下图所示：IEIEIEIEWAN/LAN逻辑WEB服务器1.1上应用程序A的虚拟目录逻辑应用服务器上应用程序A的实例1逻辑WEB服务器1.n上应用程序A的虚拟目录逻辑应用服务器上应用程序A的实例2负载均衡器逻辑WEB服务器2.1上应用程序A的虚拟目录逻辑WEB服务器2.n上应用程序A的虚拟目录…………在WEB服务器之前安装负载均衡器，用于对来自客户端的HTTP请求或HTTPS请求进行负载分发，在负载均衡器之后的多台WEB服务器均衡地进行业务处理。考虑到会话保持，部署环境时应该多个逻辑WEB服务器对应一个逻辑应用服务器，这样可以保证统一个用户在下次访问时能访问到相同的逻辑应用服务器。即逻辑WEB服务器和逻辑应用服务器之间是多对一的关系。简单起见，一个逻辑WEB服务器对应一个逻辑应用服务器，就是一一对应的方式。在一般情况下，要采用一一对应的负载均衡方式。如图：IEIEIEIEWAN/LAN逻辑WEB服务器逻辑应用服务器逻辑WEB服务器逻辑应用服务器逻辑WEB服务器逻辑应用服务器负载均衡器一一对应的方式下，又可以根据不同的情况把对应的一个WEB服务器和一个应用服务器分离部署或合并部署。因为通常情况下大的系统的业务量比较大，为了提高处理能力和避免WEB服务器和应用服务器之间的互相影响，应该采用分离部署方式。对于业务量小的系统，应该采用合并部署方式，部署更简单，且所需的服务器数量更少。特殊情况下，负载均衡的分离部署方式中，可根据性能瓶颈的位置不同而采用不同的部署方式。1、如果性能瓶颈在逻辑WEB服务器，而它所在的物理WEB服务器资源还比较轻松的时候，则在该物理WEB服务器上多建立一个逻辑WEB服务器和相应的逻辑应用服务器对应，如下图：物理WEB服务器物理WEB服务器旧逻辑WEB服务器新逻辑WEB服务器物理应用服务器逻辑应用服务器2、如果性能瓶颈在逻辑WEB服务器，而它所在的物理WEB服务器资源已经比较紧张的时候，则添加一个物理WEB服务器，上面建立一个逻辑WEB服务器和相应的逻辑应用服务器对应，如下图：新物理WEB服务器新物理WEB服务器旧物理WEB服务器旧逻辑WEB服务器新逻辑WEB服务器物理应用服务器逻辑应用服务器3、如果性能瓶颈在逻辑应用服务器，则在现有的或新添加的物理应用服务器上新建一个逻辑应用服务器。考虑到会话保持，必须添加新的逻辑WEB服务器，这就要根据原来的物理WEB服务器资源是否充足来考虑是否添加物理WEB服务器，分别如下图所示：物理WEB服务器物理WEB服务器旧逻辑WEB服务器新逻辑WEB服务器物理应用服务器旧逻辑应用服务器新逻辑应用服务器新物理WEB服务器新物理WEB服务器旧物理WEB服务器旧逻辑WEB服务器新逻辑WEB服务器物理应用服务器旧逻辑应用服务器新逻辑应用服务器新物理应用服务器新物理应用服务器物理WEB服务器旧逻辑WEB服务器新逻辑WEB服务器旧物理应用服务器旧逻辑应用服务器新逻辑应用服务器新物理WEB服务器新物理WEB服务器旧物理WEB服务器新物理应用服务器旧物理应用服务器旧逻辑应用服务器新逻辑应用服务器旧逻辑WEB服务器新逻辑WEB服务器上述负载均衡的部署具有较强的应变能力，可根据不同的情况采取不同的方式。为了使部署统一化，规范化，简单化，特此规定：一般情况下应该采用一一对应的部署方式，如果需要采取更加灵活的组合方式，必须进行详细的分析、验证，才能在生产环境上使用。负载均衡硬件设备选用及部署注意事项综合考虑可靠性和业务处理能力（吞吐量），负载均衡器要求使用硬件设备。负载均衡器实际上是一个第四层交换机，硬件往往附带有很多的网络接口，一台硬件可以划分成多个独立的网段，分别在不同的网段上完成负载均衡器的作用，即一台设备可以做多个应用程序的负载均衡。针对实际情况，要求每个应用群组中的每一种物理结构使用独立的两台（保证冗余）负载均衡硬件来完成。具体的负载均衡策略和配置根据不同应用的特点来决定，具体情况具体分析。以上负载均衡器的部署方案只是针对一般性的应用进行的概括，对于一些特殊系统需要特别对待。如网上银行应用，因为WEB服务器直接连接的是Internet公网，所面临的安全风险比较大，因此需使用防火墙建立多个DMZ区；同时，因为WEB服务器所需要的Internet通讯链路有多个，因此需要对数据链路做负载均衡。在这种特殊情况下，负载均衡的方案和配置比较复杂，与上面描述的情况有较大区别。另外，负载均衡器除了能够分发负载之外，还可以实现故障隔离，即当一台服务器发生故障时，负载均衡器会检测到（负载均衡器的HealthMonitor功能），并且将该服务器标记为故障服务器，之后的通讯请求将不再分发给有故障的服务器。因此，一方面可以隔离故障，另一方面，可以用来进行计划内的停机维护。系统软件平台BS应用系统部署B/S结构应用系统有两种部署模式：第一种是“WEB服务器和应用服务器分离部署模式”，即WEB服务器和应用服务器分别安装在不同的硬件平台上；第二种是“WEB服务器和应用服务器合并部署的模式”，即WEB服务器和应用服务器合并安装在同一硬件平台上。Web服务器规划使用Linux平台，应用服务器规划使用Unix平台，针对于分离部署和合并部署两种模式，相关的软件平台规划为：WEB服务器和应用服务器分离部署模式：WEB服务器使用Linux+IHS+WAS插件，应用服务器使用Unix+WAS。WEB服务器和应用服务器合并部署模式：WEB服务器使用Unix+IHS+WAS插件，应用服务器使用Unix+WAS。如果采用IHS作为WEB服务器，不能使用WAS安装包自带的IHS程序，要使用独立安装的IHS。对于以后开发的新项目，如果因为特殊原因，要采取不同于上述两种系统软件平台的搭配方式，必须要在项目总体方案中说明原因，以提交技术评审会评审，评审通过后才可采用。目前行内部分应用的系统软件平台还存在着与上述规范不完全符合的情况，主要是：WEB服务器使用Windows+IHS+WAS插件，应用服务器使用Unix+WAS；WEB服务器使用Windows+IIS+WAS插件，应用服务器使用Unix+WAS；针对以上不完全符合规范的部署方式，暂时保留，在适当的时机启动系统平台迁移工作；对于新投产的应用，严格按规范执行。在对WEB服务器使用Windows+IIS+WAS插件这种搭配方式进行改造时，要充分考虑IIS和IHS存在的差异对现有应用程序的影响，有针对性的进行应用程序的调整，并进行充分测试后才能投产。Linux操作系统使用规划Web服务器使用Linux操作系统新终端平台项目的CTS交易服务器应采用Linux系统平台软件开发中心不再发布基于SCOUnix平台的应用系统，原有基于SCOUnix平台的应用系统应完成向Linux系统平台的迁移各中心、各分行自行开发的应用，也不再允许采用SCOUnix系统平台，原有基于SCOUnix平台的应用系统应完成向Linux系统平台的迁移。硬件配置规划不同的服务器部署结构对硬件的要求有所不同，在考虑服务器的硬件配置时要从硬件的处理能力和硬件的成本等方面来分析，下面就生产环境的情况对硬件配置进行规划。测试环境的硬件配置需要酌情降低，考虑滚动使用生产环境上的旧设备。当生产环境上的旧设备不再使用时，需考虑把它放到测试环境或开发环境中使用。分离部署方式的WEB服务器硬件配置原则WEB服务器只是完成静态页面或动态页面的显示和一些诸如数据完整性检查等简单逻辑，所面临的压力主要是处理来自浏览器的通讯连接，需要考虑的是系统的吞吐能力或I/0处理能力，包括网络处理能力。由于WEB服务器使用的通讯协议是无状态的，而且每个WEB服务器的最大处理能力和最多连接数均有一定限制，而客户端的连接数可能是无法估计或非常大的，因此，WEB服务器应该采用小而多的中低档配置的服务器再加上负载均衡服务器来均衡地分担负载。另外，WEB服务器只需要采用服务器的本地系统硬盘就可以满足存储需要。通常对于WEB服务器的配置要求是：硬件平台使用PC服务器；不需要太多的CPU处理资源，通常是2个CPU；内存的配置要求基本上是所有静态文件的大小（让所有的静态文件都能够缓存在内存中以提高响应速度）加上每一个HTTP通讯连接的内存消耗总和；强调网络I/O吞吐能力，通常采用千兆网卡或绑定多张网卡来提高网络带宽；原则上采用服务器的本地系统硬盘。对于某些特别重要的、需要考虑灾备切换的应用系统，其WEB服务器可用考虑使用SAN，把所有内容（包括操作系统、WEB服务器系统、WAS插件、应用的WEB页面文件等等）都安装在SAN上，以方便灾备系统的顺利同步和切换。分离部署方式的应用服务器硬件配置原则应用服务器负责所有业务逻辑的实现，负责对数据库的访问和对后台应用系统的交互。对于应用服务器的配置要求是：需要适当的CPU处理资源，通常情况需要4个CPU；内存的配置要求较大，不同的应用系统有不同的要求，需要重点考虑的一个因素是应用服务器需要将每一个用户从登录开始到退出的完整的会话数据（通常在数K字节范围内）保留在内存中，因此，不同的应用设计会对内存的要求有所不同，通常每个应用实例的配置中都有一个参数就是JVM所能控制或使用到的最大内存，并且目前我行普遍使用的IBM公司软件WAS的版本都是32位的应用程序，JVM本身所能管理的内存空间最大只能到达2G。另外，每个应用服务器的最大处理能力和最多连接数是有一定限制的，而来自WEB服务器的连接请求是无法估计或非常大的，因此，应用服务器应该采用多个中低档配置的服务器，应用服务器只需要采用服务器的本地系统硬盘就可以满足存储需要。对于应用服务器的配置要求是：硬件平台使用安装Unix操作系统的服务器；不需要太多的CPU处理资源，通常需要4个CPU；内存的配置要求比较高，通常需要4G或8强调网络I/O吞吐能力，通常采用千兆网卡或绑定多张网卡来提高网络带宽；原则上采用服务器的本地系统硬盘。对于某些特别重要的、需要考虑灾备切换的应用系统，其应用服务器可用考虑使用SAN，把所有内容（包括操作系统、WAS、应用程序文件、应用的数据文件等）都安装在SAN上，以方便灾备系统的顺利同步和切换。合并部署方式的服务器硬件配置原则合并部署方式的服务器应该综合分离部署方式的WEB服务器和应用服务器的原则，通常对于合并服务器的配置要求是：硬件平台使用Unix操作系统的服务器；不需要太多的CPU处理资源，通常是4个CPU；内存的配置要求比较高，通常是4G或8G；强调网络I/O吞吐能力，通常采用千兆网卡或绑定多张网卡来提高网络带宽；原则上采用服务器的本地系统硬盘。对于某些特别重要的、需要考虑灾备切换的应用系统，其WEB服务器和应用服务器可用考虑使用SAN，把所有内容（包括操作系统、WEB服务器系统、WAS、应用的WEB页面文件、应用程序文件、应用的数据文件等）都安装在SAN上，以方便灾备系统的顺利同步和切换。B/S结构应用系统的备份备份的目的主要是提高系统整体的高可用性，提高系统连续处理能力。系统备份需要考虑如下几点：一是系统是否存在单点故障，要求系统采取适当的冗余技术，以保证不会因为某个部分的故障而导致系统整体的服务停止；二是系统的连续运行时间；三是系统的故障恢复时间，即一旦发生故障导致系统停止服务，系统修复时间的大小也非常关键。对于WEB服务器和应用服务器来说，需要考虑系统硬件冗余备份、应用程序软件和应用程序数据备份。系统硬件冗余备份的方法就是采用多服务器硬件加负载均衡，当任何一台或多台（只要不是所有服务器）同时发生故障，那么负载均衡设备会自动地将业务请求分发到正常的WEB服务器和应用服务器对上，而保证系统连续可用，同时，可以对发生故障的WEB服务器和应用服务器对进行修复。另外，这种负载均衡的结构可以支持因系统维护需要而进行的计划停机而不会中断对外的服务。数据备份的方法是使用操作系统的备份功能或者专用的备份工具（如BEB）对磁盘上的各种数据（操作系统、应用程序、应用数据等）进行磁带备份。因为在WEB服务器和应用服务器上的绝大多数数据都是可以通过重新安装系统的方式进行恢复，因此不进行备份也不会对系统的可靠性造成影响。但是，对于一些特殊的应用数据（如用户上传的批量数据文件等），需要进行备份。因此，对于WEB服务器和应用服务器的数据备份，要求对有价值的特殊应用数据必须进行磁带备份，对于操作系统、应用程序等其他数据，不强行要求备份，由各单位视情况决定。数据库的冗余备份规范概述 随着我行数据集中项目的成功实施，我行数据的集中程度越来越高，对我行信息系统的高可用行和数据的安全性提出了新的挑战。虽然，目前我们有比较完善的集中监控和集中存储备份系统，但是基本上都是以天为单位进行备份，一旦系统发生故障，要从集中备份的数据中恢复系统，恢复时间会较长，因而会对生产造成不利影响。 为了提高数据库系统自身的抵御故障能力，需要对数据库系统实施一定的冗余备份。本章先介绍三种备份技术的工作原理，然后按照技术实施的过程（搭建－>维护－>故障发生时的系统切换）对各自的优缺点进行分析，并对抵御故障的能力和成本估计进行阐述。最后给出了数据库的冗余备份实施要求。数据库的冗余备份方式standby数据库standby数据库有两种形式，物理standby和逻辑standby。物理standby数据库是用主数据库控制文件的一个特殊拷贝创建的数据库，通过将主数据库的归档日志文件应用到standby数据库而使二者紧密同步。逻辑standby是在逻辑上与主数据库保持一致；与主数据库的同步是通过把主数据库上归档的重做日志信息还原为SQL语句（使用LogMiner技术），并应用到standby数据库。逻辑standby数据库性能上不如物理standby数据库，一个事务要同时在主库和备库上完成之后才能提交，因此对系统效率影响比较大；为了使逻辑standby对系统效率影响不至于过大，一般要求备库服务器的性能跟主库一样。由于逻辑standby对资源的消耗太大，对系统效率影响也比较大，因此不推荐使用。我行所使用的standby技术是以物理standby为主。除非特殊说明，本规范所指的standby技术都是指物理standby。N＋1方式N+1方式主要是指使用一台备机对N台服务器进行冗余备份，当其中一台服务器出现故障时，该台备机可以迅速切换并对生产系统进行接管。具体说明：在SAN环境中，假设有N台同平台的数据库服务器（以下简称主机）是生产系统数据库服务器，那么集中指定一台相同平台的备机作为所有N台生产数据库服务器的备份服务器，使生产数据库服务器都与备份数据库服务器共同组成一个CLUSTER。当任何一台生产系统出现故障而不能对外提供服务时，通过切换脚本在较短的时间内实现备份服务器对生产系统的接管，从而能对外提供服务（出现故障前已经有的数据库连接会被断开并重新与备份服务器建立连接），保证业务连续性。冷备份方式冷备份方式，指在备机上保存有应用数据库的完整拷贝（如数据文件、控制文件、联机重做日志文件以及init.ora等），一旦生产机出现故障，应用可立即由备机接管。就系统架构而言，该冗余备份方式与standby类似，关键的区别在于没有数据同步机制，因此，对于应用本身提出了较高的要求。即应用数据库中不保留类似于账务处理这样的关键信息，允许数据的丢失。各类冗余备份方式的工作原理standby方式standby方式的基本思想就是为主数据库建立一个备用数据库，当主库出现故障的时候，备库可以迅速切换为主库，接管主库的工作。为使备库能切换为主库，必须让备库与主库保持一致，这种一致性是通过以下方式实现的：首先在建立standby数据库前，为使主库与备库同步，需要先将主库实例关闭，然后将主库的init文件、数据文件、控制文件和日志文件复制到备库的相应位置，修改备库相应的参数，如数据文件、控制文件等的位置，接着启动备库。备库实际上是主库的一个完全拷贝，它不仅与主库的设置保持一致，它还拷贝了主库的数据。 备库与主库是两个独立的服务器，在备库起来后，主库与备库通过归档日志文件进行信息。备库需处于恢复模式，将主库的归档日志文件进行应用，以保持与主库的同步和一致性。由于备库与主库保持完全一致，当主库出现故障的时候，备库就可以迅速切换为主库，继续进行应用（如下图），为了避免单点故障，主机与备机的数据存储不在同一台磁盘阵列上。N+1方式N＋1方式的主要思想是使用一台备机对N台数据库服务器进行冗余备份操作，一旦有某台服务器出现故障的时候，由备机接管该服务器，继续进行服务。备机的准备主要包含硬件的准备和软件的安装，即安装合适的操作系统和ORACLE数据库运行所依赖的Package。合适的操作系统是指与数据库服务器相同的或者相兼容的系统平台，例如内核位数需要兼容才可以进行相互之间的切换。而存储设备（如磁盘阵列）则是根据数据库服务器冗余备份的要求，和数据库服务器以及备机都进行连接，数据库服务器本地硬盘上只安装操作系统，ORACLE程序文件和数据文件都放在存储设备上，并且备机要能够访问数据库服务器的存储数据。将程序文件以及数据文件放在存储设备上，并能让备机访问是备机能够接管的基本条件。当某台数据库服务器出现故障时，备机在正式切换之前需要先对备机进行一些环境准备，如建立与数据库服务器相同的用户、组、mount点以及运行一些必要的脚本等，然后按照规范要求并根据实际环境建立相应的配置文件，最后运行切换脚本进行切换或回切。N＋1方式的简略模型如下图：冷备份方式 利用应用的数据备份，以及一台和主机具有类似处理能力的备机，就可以搭建应用的冷备份环境。 在冷备份方式下，备库并不需要与主库一直保持联系，一旦应用发生了故障不能对外提供服务，备机将接管应用处理。需要强调的是，由于在该方式下没有数据同步机制，因此，系统将在旧数据的基础之上进行现有业务的处理。显然，这种冗余备份方式只适合少量对数据要求不高的应用。各类冗余备份方式优缺点的比较搭建的难易程度三种方式的简略搭建步骤standby方式standby数据库的搭建方式有两种，一种是手工搭建standby数据库；一种是使用RMAN来搭建standby数据库。搭建standby数据库的步骤是备库复制一份主库的控制文件、数据库文件和日志文件，然后通过一些参数设置使主库的归档日志文件可以传送到备库，主库和备库之间通过同步归档日志来同步数据库。N+1方式要实施N+1备份方式，首先要求按OFA规范结构安装相应版本的ORACLE。为了让备机能够接管N台主机的应用，备机的操作系统要与其所要接管的数据库服务器的操作系统完全一致，文件系统的划分要对应。冷备份方式1、查询数据文件、控制文件、日志文件和参数文件所在位置；2、关闭主数据库，使用二进制方式将以上文件拷贝到备机；3、重新启动主数据库，继续进行操作。4、在冗余备份服务器上重新创建实例，恢复备份数据库。三种方式的搭建难度比较冗余备份方式搭建特点搭建难度standby方式需要将主库的各种文件都复制到备机、主库与备机是一对一的关系，复制需时较长，但配置操作相对较简单操作难度一般，拷贝各种文件需时较长N＋1方式需将应用服务器与备机都连到存储系统上，应用程序和数据都放在存储系统，服务器上只需要安装最基本的能运行ORACLE的软件就行操作难度最大，数据库安装要遵循OFA规范冷备份方式只需将主库在关闭状态下的各种文件复制到备机，一般不需进行配置工作操作最简单，拷贝各种文件需时较长维护的工作量三种冗余备份方式的日常维护工作standby方式standbydatabase的生命周期，从建立一个standbydatabase开始，一直到激活为止。即：创建—>使用(手工管理、自管理、只读模式选择循环)—>激活。在使用过程中，主库如果发生影响到standbydatabase正常使用的事件，在ORACLE9I以前，涉及操作系统文件级的操作都不能通过日志同步到standbydatabase上来，需要手工干预。对于不同的主库事件，standbydatabase需要进行不同的处理。在ORACLE9I以后的版本（包括ORACLE9I）可以通过设置STANDBY_FILE_MANAGEMENT=auto参数，改善不同步问题，该参数可将主库涉及操作系统文件级的操作同步到备库中，这样可简化日常管理。用参数STANDBY_FILE_MANAGEMENT时，须保证主库服务器上的文件目录结构和备库服务器上的文件目录结构保持一致，如果不一致，可以通过设置DB_FILE_NAME_CONVERT来进行转换。N＋1方式 操作系统发生系统变更时，如涉及以下内容，则须修改相应的配置文件：1、修改主机名，如果在生产机或者备机上更改主机名，都必须相应的修改配置文件。2、如果更改ORACLE数据库所用的文件系统、更改ORACLE数据库所用的裸设备或者更改ORACLE数据库所用VG名及组成该VG的PV，则须在生产机和备机上修改相应的配置文件。3、修改TCP/IP设置，如果在生产机或者备机上更改IP地址、子网掩码及网关地址，都必须相应的修改配置文件。4、修改网络接口，如果在生产机上更改网络接口，则须在生产机和备机上修改相应的配置文件。冷备份方式备份文件存放于备机中，只需要保证备机不对这些文件进行操作，不需要其他维护工作。三种冗余备份方式日常维护工作量的比较冗余备份方式日常维护发生的情况工作量standby方式主库的有些变化，不能通过日志同步到standbydatabase上来，特别是涉及操作系统文件级的操作，因而需要手工干预。在ORACLE9I以后，通过设置参数STANDBY_FILE_MANAGEMENT可以同步涉及操作系统文件级的操作。ORACLE9I以前，主库涉及操作系统文件级的操作都需要手工做同步，维护工作相对较多。ORACLE9I以后，通过设置参数STANDBY_FILE_MANAGEMENT，维护工作大大简化。N＋1方式数据文件和实例都只有一套。如果系统发生变更，而变更涉及切换脚本中的内容，则需要手工修改切换脚本中的内容。需要手工维护的内容最多冷备份方式平时不需要维护基本上没有维护工作故障发生时的恢复速度三种冗余备份方式在故障发生时候的恢复方法standby方式： 如果standbydatabase处于手工模式之外的其他模式，首先应将其切换到手工模式，然后做手工恢复，消除日志序列缺失，再将它激活，否则可能丢失数据。SQL>alterdatabaseactivatestandbydatabase;完成这一步操作之后，查看在线日志组所在的目录，可以看到新生成了在线日志组。此时查询v$instance视图，数据库为start状态，此时数据库还不能进行查询或其他操作。需要关闭数据库，然后再打开它，即作如下操作：SQL>shutdownimmdiate;SQL>startup;也可以先加载，然后再打开：SQL>alterdatabaseactivatestandbydatabase;SQL>alterdatabasemount;SQL>alterdatabaseopen;此时可以正常使用数据库。N＋1方式： 主要是利用切换脚本进行切换，先建立配置文件system.txt、vgname.txt、lvname.txt、fsname.txt和tcpip.txt，然后基本按照以下步骤进行切换： 1、登录数据库服务器，运行切换脚本。 2、登录备机，运行接管脚本，则将进行下列过程。冷备份方式： 主要是利用备库中的备份文件（数据文件、控制文件、日志文件、参数文件）在备库中进行恢复，备库利用这些文件恢复到备份时间点主数据库的状态。三种冗余备份方式的恢复速度比较发生故障类型大致可以分为三类：第一类是主库服务器损坏，即主服务器物理损坏或者操作系统不能正常启动，但所连接的SAN存储还可用；第二类是主库损坏，即数据库不能正常启动，一般是RDBMS软件损坏或者是数据文件损坏；第三类是SAN存储损坏（由于我行SAN存储系统都使用了RAID技术，SAN存储损坏的可能性非常小）。冗余备份方式主库服务器损坏（主服务器物理损坏或者操作系统不能正常启动，但所连接的SAN存储还可用）主库损坏（数据库不能正常启动，一般是RDBMS软件损坏或者是数据文件损坏）SAN存储损坏Standby消除日志序列缺失，再将备库激活。由于主库服务器操作系统不能启动，必须将SAN存储挂接到备库服务器上，恢复时间较长。消除日志序列缺失，再将备库激活。由于主库服务器操作系统还能启动，因此恢复速度一般。直接激活数据库，无法消除日志序列缺失，数据有一定的丢失。但也因为不用执行消除日志序列缺失的步骤，恢复速度非常快。N+1在备库运行脚本直接切换，恢复速度非常快。由于RDBMS软件和数据文件都是同一份。此时备机接管后同样无法打开数据库。这种情况只能使用BEB备份恢复数据库，速度非常慢，但由于日志信息都还完好，所以可以恢复所有数据。无法恢复，因为存储只有一份。这种情况只能使用BEB备份恢复数据库，速度非常慢，而且会丢失上次备份以来的所有数据。冷备份直接启动备库，恢复速度非常快。直接启动备库，恢复速度非常快。直接启动备库，恢复速度非常快。抵御故障的能力冗余备份方式抵御故障的能力standby方式抵御故障的能力最强。无论发生何种异常情况，standby数据库都可以成功切换。最坏的情况下，存储损坏时，standby数据库才会缺失一个主库的当前日志。N＋1方式抵御故障的能力较弱。由于N+1备份方式只有一份存储数据，因此，如上文分析，无法抵御主库损坏和SAN存储损坏两种类型的故障。冷备份方式抵御风险能力较强。在故障发生后，只需对备库进行配置后就可接管主库的任务。但强调一点，备库是不跟主库进行信息同步的，所以要求应用上绝对没有实时变化的数据或这些数据都可以在应用上重新自动生成。成本估计冗余备份方式服务器的利用率成本Standby方式就一般情况而言，一台备机只服务于一台主机，利用率只有1/2。但也可以配置备机服务于多台主机，从而提高备机的利用率。较高N＋1方式每N台主机共享一台备机，整体的利用率为N/(N+1),可以通过增大N的数量提高利用率，但需和机器损坏的概率予以平衡，以避免在同一群组中同一时间损坏的机器超过一台。较低冷备份方式和standby方式类似，一对一的进行系统备份，利用率只有1/2，可以通过增加备机所备份的主机数量来提高硬件的利用率。较高。其他standby数据库还是目前我行做数据迁移的一种重要手段，迁移的具体步骤如下：1、为需要迁移的数据库在指定的服务器上搭建standby数据库。2、按照前面所介绍的恢复方法恢复备库，激活后的备库就是要迁移的目标。数据库的冗余备份方式实施要求数据库的冗余备份方式的控制流程1、每个新的应用系统在总体方案（具体在非业务功能检查表中体现）、投产方案中要写明所使用数据库的冗余备份方式，开发中心应该在相关的文档模板中，增加这部分的内容。2、在项目总体方案评审会上，由技审会决定该应用应该使用何种数据库的冗余备份方式。实施原则standby备份方式抵御故障的能力最强，代价也最昂贵。相对而言，N＋1方式抵御故障的能力稍低，代价也相对低。而冷备份较standby而言，需要的成本类似，但对应用的要求较高。根据系统安全性和实施成本综合考虑，开放平台B/S结构应用系统数据库冗余备份的实施原则是：1、数据库无论采取何种冗余备份方式，都不能完全保证数据的完整。因此，数据库的其他日常备份必需做好。2、重要的系统实施standby备份，而非重要系统则实施N＋1备份方式。3、对于数据量特别大的系统，进行standby备份的成本比较高，因此如果该系统不是特别重要的话，不要使用standby备份。1、如果当前有系统采用冷备份的冗余备份方式，按照以上原则对应的迁移到以上冗余备份方式。2、同一物理群组的应用应该采用相同的冗余备份方式。3、采用standby方式备份的系统，备机的配置应为主机配置的1/2左右。4、采用N＋1方式备份的系统，备机的配置应为该群组中最大配置主机的1/2左右。5、为了避免单点故障，主机与备机不应分别占用同一台物理机器的不同分区，也不应使用同一台磁盘阵列的不同磁盘组。6、以上规则是对生产环境而言，对于开发、测试环境，一般不进行standby、N+1等系统冗余备份，但开发中心、测试中心可以部署一两套standby、N+1备份的系统，以掌握相关的技术，进行相关研究。重要系统的判定标准重要系统的判定标准：1、对外营业系统相对重要，而内部管理重要性相对低。2、实时联机交易的系统相对重要。3、存储客户账务信息的系统相对重要。4、出现故障后，必需在短时间内恢复生产运行的系统，相对比较重要。5、对于某些数据库，数据很重要，但生产上对业务连续性要求不高的，重要程度相对较低，可以不采用高级别的数据库冗余备份方式。由于standby备份方式成本较高，为慎重起见，一个系统是否需要使用standby方式进行数据库的冗余备份，最终由技术评审会决定。应用群组规划及整合规范概述 目前我行数据中心运行的应用系统已经超过140多套，每个系统都需要进行操作系统的监控和管理，应用中间件的监控和管理，数据库的监控和管理以及存储的管理。为加强我行运营系统的管理和维护，需对我行的应用系统进行适当稳妥的整合。另外，目前我行应用系统的数据缺乏共享，对于同一个客户不同系统间存在客户信息重复录入的问题。应用系统的整合将为以后的数据共享奠定良好的基础。 应用的整合分为两大类，物理整合和逻辑整合。由于我行应用系统比较复杂，所以应用系统的整合需要逐步推进。目前的应用整合以物理整合为主。应用群组的规划规划目的所谓应用群组规划,指的是将紧密相关的系统进行归类，群组规划的目的是为应用的整合提供依据。应用群组划分的目的是对业务特点相似、生产重要性基本一致、体系结构类似的应用进行服务器整合，在整合的基础上，按重要性实施不同级别的系统级备份。通过服务器整合，简化生产维护难度，降低管理成本，对于整合后服务器按重要性进行不同级别的系统备份，实现生产系统的安全运行，降低运维成本。规划原则根据各个应用的业务特点，可将应用划分为多个逻辑群组，对于业务特点相同的应用，划分为一个逻辑群组。在逻辑群组的基础上，结合应用的重要性、运行连续性、系统结构特点，逻辑群组内进一步可划分为多个物理群组，对于生产重要性、体系结构一致的应用，尽量划分在一个物理群组。数据中心逻辑群组的划分逻辑群组的划分是将业务类型相似的应用划分在一起。根据这种分类思想，目前我行在数据中心运行的应用可划分为九大逻辑群组：经营分析逻辑群组、资源管理逻辑群组、风险管理逻辑群组、科技管理逻辑群组、办公管理逻辑群组、资产管理逻辑群组、金融e通道逻辑群组、内部业务管理逻辑群组、集中式中间业务逻辑群组和其它。详见下表：逻辑群组物理群组应用中文名英文名经营分析逻辑群组A个人客户关系管理F-PCRMB法人客户关系管理F-CCRMC业绩价值管理F-PVMSD综合统计F-CS2002E基金会计估值F-AAS基金绩效评估F-PAS外部金融信息库F-FIDB托管资产风险监控F-CARC资源管理逻辑群组A固定资产管理F-FAMSB人力资源管理F-HRM分支机构管理F-BOM工会工作管理（二期）（查询部分共用数据库实例）F-LUPMC财务归集还原F-FRA财务授权F-FAA风险管理逻辑群组A风险监控F-RMA审计集市F-AMAB特别关注客户信息F-CIIS银行卡透支台帐及风险管理F-BRMS科技管理逻辑群组A综合监控F-CMCE应用运行监控（待开发）F-BAMCB网络管理F-NETMC总控中心服务台F-HLPDD项目管理F-PMAS资源管理F-RMIS配置管理F-CMDB安全管理F-SMTS办公管理逻辑群组A法律案件管理F-CMS行业信息库（旧）F-VIIS工会工作管理F-LUPMB信访管理F-CLVS执法监察管理F-CSA通用表决F-GVAC内部门户F-IIPA行业信息库（新）F-VIIS工会工作管理（新）F-LUPM教育培训信息（新）F-ETI信访管理（新）F-CLVS资产管理逻辑群组A法人信贷管理F-CM2002票据综合管理F-BMS风险资产管理F-RAM债券投资与资金交易管理F-BIFT投资银行业务管理F-IBMB个人信贷管理F-PCM2003金融e通道逻辑群组A网上银行（对公）F-EBANK代理BSP清算F-CABSP银企互连F-CMPB网上银行（个人）F-EBANK手机银行F-MPAC海外分行网上银行F-ABIBD电子银行内部管理F-EBMSH电话银行中心F-CCISI门户网站F-IEPAF网上代理销售F-EMALLG统一消息平台F-UMSP内部业务管理逻辑群组A会计要素管理F-AEMS参数管理F-PMS主机调帐F-ADS资金交易市场F-RDSB业务应急处理（待开发）F-BESC个人营销F-PBMSD个人理财分析（拟作废）F-PFASE代理海关网上支付F-CACC代理合作银行F-CABOAG外汇买卖敞口管理F-FXPMI外汇业务查询F-RMTSJ海外分行辅助信息F-ABAIK企业年金管理F-OAML基金业务后台综合处理（待开发）F-OFBP集中式中间业务逻辑群组（新增群组）A代理保险F-IAAS代理国库信息处理F-TIPS银证转帐F-CBST代理财政支付（集中式版本尚未发布）F-FPA速汇金（待开发）F-TES集中式中间业务内部管理（待开发）F-CEMSB集中式银证通F-CBSCC客户交易结算资金存管F-CTFCM其它因涉及应用较多，技术复杂，因此不作物理群组的划分历史明细集中存储应用F-SADL客户对帐F-CACA统一对外数据报送F-EFTPNOTES园地F-NAC文印档案管理F-DAMS目录服务（AD）F-ADM远程教育F-NRES网络远程教育培训考试（待开发）F-NETE银行卡辅助管理F-CAFM单证中心F-DOC外汇帐务处理F-CFCSALLIANCE前置F-ALGW金卡前置F-GCF黄金前置F-GEAG外卡前置F-FCFTA前置（拟作废）F-OFTG债券前置F-BTG保险前置F-IAAG数据交换平台F-DSWP主机运行数据统计F-TRST黑名单检查F-CBLA柜员统一认证F-SSICHSMF-HSM支付密码F-ZFMM密押F-ESE客户证书F-CCAS代理业务数据传输F-ABDT通用文件传输F-GFT文件拆分返传F-FDTS工作流管理F-WMA通用网关F-CGSEIP网关F-IPCG分行逻辑群组的划分对于分行应用，可划分为七大逻辑群组：分行前置逻辑群组、分行数据平台逻辑群组、后督逻辑群组、国际业务逻辑群组、办公管理逻辑群组、自助终端、科技管理逻辑群组和其它。逻辑群组物理群组应用中文名英文名分行前置逻辑群组A中间业务平台F-MAPS跨行支付F-IBPS代理财政支付（集中式版本投产后取消）F-FPAB综合前置F-BIFSC跨行支付（人行支付前置部分）F-IBPSD通用网关(含DSR网关)F-CGSEE字符终端仿真F-CITE新终端平台F-CTIE分行数据平台逻辑群组A综合统计F-CS2002前台业务报表F-FORS业务报表应用F-BRSB电子档案管理F-EAMC业务档案缩微F-BAMSD代理业务数据传输F-ABDT通用文件传输F-GFT文件拆分返传F-FDTSE工作流管理F-WMA后督逻辑群组A事后监督F-PTAS国际业务逻辑群组A国际结算业务处理F-ISEE办公管理逻辑群组A文印档案管理F-DAMSBNOTES园地F-NACC远程教育F-NRESD目录服务F-ADME网络远程教育培训考试F-NETE自助终端A自助终端F-SSTS科技管理逻辑群组A综合监控F-CMCE应用运行监控F-BAMC网络管理F-NETMB设备运行监控（暂无）F-MPERC分行产品版本管理F-SVMBD安全管理F-SMTS其他因涉及应用较多，技术复杂，因此不作物理群组的划分PCC应用F-PCCA电话银行中心F-CCIS物理群组的划分目前九大逻辑群组均根据其业务特点来定义，为了配合本项目的实施，我们针对上述逻辑群组做了进一步的划分，即按照软硬件技术平台和开发模式进一步划分为物理群组，使得同一物理群组内的应用系统便于进行整合。 另外以目前开放平台的软硬件技术水平，构建过大的集群存在技术困难和技术风险，所以物理群组的划分也要考虑适度的原则，一个物理群组不宜过大。应用整合B/S结构服务器整合WEB服务器整合在WEB服务器不是性能瓶颈的情况下，应该把应用进行同一逻辑WEB服务器整合，否则把应用进行分离逻辑WEB服务器整合。同一逻辑WEB服务器整合是指把多个应用的静态文件安装在同一个逻辑WEB服务器下。分离逻辑WEB服务器整合是指把多个应用的静态文件安装在不同的逻辑WEB服务器下。可根据实际情况调整逻辑WEB服务器的数目，例如一共有4个应用，可以把其中2个放在逻辑WEB服务器1下，另外2个放在逻辑WEB服务器B下。应用服务器整合属于同一物理群组的应用又可看情况分独立JVM和分离JVM两种方式整合。独立JVM整合是指把属于同一物理群组的应用安装在同一个应用服务器中，对于WAS，就是把同一物理群组的应用安装在同一个ApplicationServer下，即同一个JVM进程中。分离JVM整合是指把属于同一物理群组的应用分别安装在同一台机器上的不同的应用服务器中，一个应用安装在一个独立的应用服务器中。在WAS中，同一台机器上可以建立多个应用服务器，每个应用服务器是一个独立的JVM进程，可以把不同的应用安装到不同的JVM进程中。这样，不同的应用之间除了资源竞争之外，互相之间就基本上没有其他影响了。除了特殊情况外，都采用分离JVM整合的方式。在进行分离JVM整合时，要注意所有的JVM设置的内存最大值加起来不能超出物理内存的3/4。数据库整合物理整合所谓物理整合，即将各种不同应用的数据库安装在同一台物理主机上，但不同的应用数据仍分属不同的数据库，它们各自运行，分别为不同的应用提供服务。物理整合具有如下的优点：1、系统的风险较小数据库产品存在的Bug和人为风险如果涉及了数据库内部的单失效点（如系统表空间或回滚段等），就有可能造成整个数据库的非正常关闭，在物理整合这种技术方案下，可以将这种风险局限在某一种应用上2、系统整合的代价较小按照物理整合的方案对应用的数据库服务器实施整合，过程较为简单，整合过程基本不需要考虑应用间的相互关系。3、系统间的影响较小不同类型的应用对数据库的配置有着不同的要求，典型的是OLTP系统和DSS系统之间对于数据的组织和存取的要求差异较大，因此，在系统资源足够的前提下，物理整合不会降低各个应用系统的处理性能。同时，物理整合有如下的缺点：1、不能充分利用服务器的内存资源多个数据库的共享内存区（SGA）彼此独立，一旦某个应用的内存不足，即使其它应用的内存资源仍有剩余，也不能加以利用；2、增加了系统的额外开销由于每个数据库实例均需要保存RDBMS的代码（即SGA中的固定存储区），增加了资源的额外开销。此外，每个数据库在运行时都有自己的一套后台进程，其管理协同的动作必然多消耗系统的CPU资源3、系统的日常维护和管理较复杂工作量较大，针对多个数据库系统实施管理和维护以及监控操作，其复杂度要高于对单个数据库系统所实施的操作，工作量也较大。4、不利于系统的深层次整合物理整合后，数据库仍然是逻辑独立的，若实行多个应用之间的整合，可能发生一个交易同时访问两