商业银行应用双活架构设计方案电子教案.docx

此文档仅供收集于网络，如有侵权请联系网站删除商业银行应用双活架构设计方案目 录一、设计原则3二、充分理解目标42.1. 我们充分理解目标：42.2. IT 行业发展的需求4三、应用系统架构现状分析6四、应用双活实现方案74.1. 不同数据中心应用双活方案74.2. 同数据中心应用双活方案11只供学习与交流 一、设计原则重要业务系统应用双活项目是单位业务支撑系统建设中极为重要的一环，既要考虑系统平台的双活切换能力和系统架构的高可用,又要考虑数据层次的业务连续性，同时也要考虑单位信息系统今后几年的业务发展需求。针对单位信息系统系统将保证业务系统的连续性来(支持 7x24 不间断运行)的特点， 在此次重要业务系统双活项目中，要把系统的可靠性、稳定性、安全性和可扩展性作为本次规划的重点考虑因素。在进行系统设计时，遵循以下原则：稳定性：稳定性是系统运行的关键，也是系统维护管理的关键因素，更是充分发挥科技骨干技术储备的关键。安全性：系统软、硬件需具有可信赖的安全性，软件系统安全性方面应满足单位信息系统安全策略的要求，系统有严格的用户权限和密码保护设计和办法。可靠性/可用性：系统软、硬件平台应稳定、可靠，能够满足业务系统 7x24 不间断的运行要求；具备成熟的高可用性和双活解决方案。对数据的完整性和准确性有可靠的保证机制。可持续发展性：所提供的技术是可持续发展的，是目前的主流技术并有长期发展的目标，能满足单位业务支撑信息系统未来几年业务发展的需求。可扩展性：随着单位业务的不断发展、壮大，系统平台必须提供足够的可扩展能力以满足未来几年业务增长和系统扩展的需要。可扩展性是保护用户投资的重要方面之一。另外在系统设计时，应选择业界相关领域的主流产品，确保产品旺盛的生命力，以便充分地保护用户的投资。易用性：系统软件平台应提供丰富的、简单的管理工具，便于管理及系统问题诊断。开放的标准：系统软件需支持业界通用的开放式标准，降低因兼容性问题造成的问题发生率。可维护性：系统维护需要简便快捷、不需要太多的管理人员和维护。系统可维护性十分重要，它直接决定了系统的效能、产出和用户的总体拥有成本。系统可维护性差会导致系统效能下降、产出降低，维护成本增加，后患无穷。售后服务技术支持：厂家能提供足够、及时的技术支持与响应，来保证应用系统良好运行状态。在系统运行中存在着很多不确定因素，包括人为因素、自然因素等多方面原因，系统可能出现不同程度上的故障，这就要求系统用户与原厂商有着良好的配合， 原厂商能够在事故发生后最短响应时间内排除故障，给系统用户以更加坚实的信心。因此原厂商的售后服务水平和响应时间同样是系统建设的一个重要考虑因素。成熟性：采用的技术、产品应经过实践检验，被证明是成熟可靠的，以规避风险。在技术上要到达当前的国际先进水平。系统的软、硬件技术是经过市场考验的，证明是成熟的技术，在相关应用中有较多的成功案例。同时要采用先进的技术，既要满足目前的业务需求，又要充分考虑未来的发展，保证系统建成后 3 至 5 年不落后，选用符合国际标准的系统和产品，以及保证系统具有较长的生命力和扩展能力，满足将来系统升级的要求。二、充分理解目标2.1. 我们充分理解目标：实现同机房与机房之间的应用双活，任何一个重要应用系统的服务器、磁盘阵列、交换机故障，都不会影响业务的正常运行。任何一个重要应用系统应用的服务器、磁盘阵列、交换机故障，对该重要业务影响控制在 1 分钟以内。2.2. IT 行业发展的需求一方面随着用户业务发展，业务层次对 IT 系统业务连续性（保证业务系统 7*24 不间断）的要求程度越来越高。另一方面企业需要一个符合成本效益的解决方案来优化数据管理和提高数据中心对于前端业务的支持水平，而不是通过单纯地增加存储和设备去解决问题。最后达到用户业务层次所需的动态型全天候不间断数据访问和业务数据中心的支持。为了有效地解决这些问题，企业需要寻找一个新的更有效的数据管理方法。这种新方法的数据管理需要具有解决几个关键问题的能力：.提高文件管理 - 帮助汇集信息孤岛，冗余数据和未充分利用的分段存储 。提高性能 规划您的存储并整合新兴技术，以帮助保护您的投资。增强可用性 - 帮助满足目前每天 24 小时不间断的市场需求，缩减整个系统的停机和维修时间为“零”。更好的自动化 - 提供无缝的工作负载流程和数据管理，提高性能和应用可靠性及最终用户体验并促进生产力 。向外扩展-改善硬件和基础设施利用率， 最大限度地提高您的投资回报和保障业务在预算范围内增长。双活系统软件能使 IT 基础架构保持灵活性、稳定性和高可用性，能够简单、动态地访问 和管理硬件资源，提高资产使用率，同时利 用更为智慧和简化的新方法来实现上述目标。双活系统软件带来整合数据中心的力量，带 来更高的客户价值：提供全面的数据中心愿景智慧的业务基础架构，包括服务管理及自动化，快速实现投资价值；将关注点从基础架构效率转向业务结果：加快数据中心整合，帮助客户把更多精力集中到关键业务目标上，以便改善服务、降低成本、管理风险；通过整合及资源池的管理方式，使原本孤立的系统协同工作，释放投资价值；充分拓展并利用合作伙伴生态系统，提供完整的解决方案。三、应用系统架构现状分析上图是当前某商业银行当前核心系统架构的现状，存在以下几个方面的问题： 1、重要业务系统服务器出现问题后，切换到备用服务器需要一定的时间。2、数据中心机房 A 出现问题后，由于数据中心机房 B 服务器平常无法打开使用，无法实现无缝接管。3、随着业务量的增长，当重要业务系统应用服务器的压力越来越大时，无法进行横向扩展。4、资源严重浪费，数据中心机房 2 的资源（尤其是存储）平时无法打开使用。5、切换时间长，一般需要 13 小时以上才能切换到灾备中心。6、故障情况下切换决策难，有时切换时间决策时间灾难修复时间，难以决策，期间无法办理业务。7、流程复杂，维护难，系统切换需要一系列管理和技术流程，维护复杂，生产、容灾端都需要维护四、应用双活实现方案4.1. 不同数据中心应用双活方案根据当前某商业银行重要应用系统系统架构的现状，同时结合某商业银行对重要应用系统双活项目的需求，该商业银行采用 GPFS(GeneralParallelFileSystem，通用并行文件系统)的高可用方案实现此功能和目标。结合当前应用系统以及硬件、网络环境的现状，其中共采用以下两种实现方式：不同数据中心应用双活和同数据中心应用双活。在满足跨机房实现应用双活的硬件、网络等条件下，结合该商业银行的应用系统现状， 设计了实现应用双活的系统拓扑图和功能逻辑图。此方案实施完成后，我们可以实现以下目标：1、任何一个数据中心的应用服务器、存储、网络出现故障，另外一个数据中心可以无缝接管，应用基本不受影响。 2、两个数据中心的应用服务器同时对外提供服务，提高了应用系统整体的处理能力， 同时由于灾备数据中心资源也可以同时对外提供服务，减少了资源的浪费。3、实现了在线进行应用服务器的横向扩展。4、系统切换演练以及维护较之前的双中心主备模式简单。此方案简述：1、通过操作系统内的 GPFS 文件系统实现，最大程度不改变传统的物理拓扑，增加整2、体方案的安全性、可用性；3、在操作系统层次，通过 GPFS 文件系统的 failure group 功能模块将生产、灾备两个中心的两台存储虚拟为一台存储使用；4、重要应用系统构建在 GPFS 文件系统上，应用系统的其它要求和环境需求按照应用本身的实际情况设计、实施。在存储实际情况满足的前提下，GPFS 均可满足应用服务器存储的要求；实现不同数据中心应用双活需要考虑的因素构建不同数据中心应用的双活有许多因素需要考虑，依赖于用户是否具备了实现的条件：双活数据中心之延迟和稳定性：由于光速限制，每约 120km 所产生的数据来回延迟约为 1ms。因此，会对实际应用性能构成影响, 特别是两数据中心数据交互密切的业务。另外，数据中心之间的网络是否容易维护和掌控。Quorum / Tie-Breaker 之需求：为了避免双活数据中心产生脑裂(Split Brain)的状况，解决方案需要提供有效的 Quorum / Tie-Breaker 方式来保证数据完整性，最好将仲裁放在第三个数据中心。工作负载之考虑：业务交易中，应用所产生之写操作 (INSERT,UPDATE,DELETE)比例越高，则越多数据需要跨数据中心传送。这类型业务交易不利于双活数据中心设计。推荐业务划分，读写分离等, 有效规避数据中心间交互的架构。在满足构建不同数据中心应用双活的实现条件下，要实现应用的双活需要完成以下步 骤：（1）现状分析：调研某商业银行重要应用系统现有的主机系统、存储系统、SAN、网络系统等的架构、配置、部署情况、关键的参数设置，以及近期的 IT 规划；通过现状分析明确基础架构、可恢复能力、应用关联关系等，评估当前环境与目标之间的差距，工作内容包括：1、对操作系统版本等系统信息进行调研和分析；2、对应用系统使用的硬件以及存储信息进行调研和分析；3、对两个数据中心之间的网络、带宽等进行调研和分析；4、对当前应用系统架构进行调研和分析；5、对应用系统使用的文件系统的容量以及每天产生的日志总量进行调研和分析。6、对每月月初、月中、月末的系统负载进行调研和分析；7、对心跳站点的网络带宽，本地磁盘或者存储现在进行调研和分析。（2）风险评估通过风险分析梳理在实施过程中所面临的风险场景，对可能的风险进行评估，按照风险的严重性和可能性，定义风险级别，形成风险矩阵，并提出风险应对建议。不同数据中心应用双活架构设计结合系统现状以及高可用性需求，编制不同数据中心应用双活总体建设策略规划建议。GPFS 双活实施根据双活的总体建设测试规划，完成不同数据中心机房的应用双活。应用双活可用性测试由于不同数据中心应用双活需要第三个站点作为心跳站点，实现方式以及双活故障测试场景都比较复杂，因此我们需要根据应用双活的要求，设计各种灾难场景，完成相应的测试，形成测试报告，例如：模拟任何一台服务器宕机模拟任何一台存储宕机模拟两个数据中心之间网络故障模拟任何一台服务器的网卡故障模拟 SAN 交换机故障模拟网络交换机故障演练规划以及组织根据灾难场景与技术架构设计，制定灾难演练场景的定义、演练方式、演练范围、演练计划、演练组织架构、灾难恢复流程、操作手册及应急措施等。4.2. 同数据中心应用双活方案如果当前的硬件环境以及重要应用系统架构无法满足不同数据中心双活的实现条件， 建议采用同机房的应用双活解决方案。以下是我们结合某商业银行的系统现状设计的同机房应用双活架构图：实现同数据中心应用双活需要考虑的因素构建同数据中心应用双活较不同数据中心应用双活需要考虑的因素较少。但构建双活的方案同样有许多的考虑，依赖于用户是否具备了实现的条件，是否能够解决以下几个挑战：Quorum / Tie-Breaker 之需求：为了保证 GPFS 集群资源的可用性和完整性，需要根据实际情况考虑采用 Quorum 机制还是 Tie-Breaker 机制。GPFS文件系统条带大小的选择： 需要根据实际应用系统使用文件系统的方式，以及日志、数据文件的大小来进行条带大小的选择，以便达到最佳性能。GPFS 私有网络的设计： 为了保证 GPFS 文件系统的高可用性，一般建议为 GPFS 通信采用专门的私有网络，解决和生产网络耦合带来的问题。重要业务系统参数优化： 根据应用方面压力测试的结果，对 GPFS 核心配置参数PAGEPOOL 等进行性能调优。同数据中心应用的双活的硬件条件要求较不同数据中心应用的双活要简单，两数据中 心之间的带宽、两个机房之间的网络延迟等因素都不再需要进行考虑。要实现同机房 应用的双活，同样需要完成与不同数据中心应用双活相同的步骤：（1）现状分析。调研某商业银行重要应用系统现有的主机系统、存储系统、SAN、网络系统等的架构、配置、部署情况、关键的参数设置，以及近期的 IT 规划；通过现状分析明确基础架构、可恢复能力、应用关联关系等，评估当前环境与目标之间的差距，工作内容包括：1、对操作系统版本等系统信息进行调研和分析；2、对应用系统使用的硬件以及存储信息进行调研和分析；3、对当前应用系统架构进行调研和分析；4、对应用系统使用的文件系统的容量以及每天产生的日志总量进行调研和分析。5、对每月的月初、月中、月末的系统负载进行调研和分析；（2）风险评估通过风险分析梳理在实施过程中所面临的风险场景，对可能的风险进行评估，按照风险的严重性和可能性，定义风险级别，形成风险矩阵，并提出风险应对建议。同数据中心应用双活架构设计结合系统现状以及高可用性需求，编制同机房应用双活总体建设策略规划建议。GPFS 双活实施根据双活的总体建设测试规划，完成同机房的应用双活。应用双活可用性测试根据应用双活的要求，设计各种灾难场景，完成相应的测试，形成测试报告，例如：模拟任何一台服务器异常宕机模拟单台服务器网卡故障模拟计划内任何一台服务器停机模拟网络交换机故障模拟服务器存储链路故障演练规划以及组织根据灾难场景与技术架构设计，制定灾难演练场景的定义、演练方式、演练范围、演练计划、演练组织架构、灾难恢复流程、操作手册及应急措施等。