1、关于系统稳定性策略的探讨 1.前言 系统作为业务系统的核心，其运行稳定性和高可用性至关重要。因此，需 要通过高可用性设计来尽量减少系统的计划内和计划外停机，并在系统出现故 障时及时响应、快速恢复，以保障关键数据和业务系统的运行稳定性和可持续 访问性。其中： 1. 计划内停机是指管理员有组织、有计划安排的停机，比如升级硬件微码、 升级软件版本、调整数据库库表、更换硬件设备、测试系统新功能等时， 可能需要的停止系统运行。 2. 计划外停机是指非人为安排的、意外的停机，比如当硬件出现重大故障、 应用程序停止运行、机房环境遭到灾难性的破坏时所引起的业务系统停止 运行。 目前，对于计划内和计划外停机，可
2、通过消除系统中的单点失效来尽量减 少停机时间。同时，通过采用可在线维护（固件升级、在线扩充、故障部件更 换）的设备，并通过负载均衡机制实现应用系统的在线升级、维护，将有效消 除计划内停机对业务系统的影响。此外，由于系统中采用了全面的负载均衡设 计，并针对系统失效提供了可靠的数据备份恢复和多点容灾保护，因而能够有 效减少系统计划外停机的恢复时间。 在造成系统宕机的原因方面，有统计中表明并非都是硬件问题。其中，硬 件问题只占 40，软件问题占 30，人为因素占 20，环境因素占 10。因 此，高可用性设计应尽可能地考虑到上述所有因素。对于系统而言，其整体的 可用性将取决于内部的应用系统、主机、数据
3、库等多种因素；同时，训练有素 的系统维护人员和良好的服务保障也是确保系统稳定运行和故障快速恢复的关 键。 2.应用系统 系统在应用软件架构设计中应从渠道层、渠道管理层、业务处理层等不同 层面通过多种措施和策略的综合设计来提高应用系统的高可用性和稳定性。 在渠道管理层和业务处理层的设计中，要考虑设置应用负载均衡、应用软 件失效备援、vip 服务通道、流量控制、故障隔离等机制。 1. 应用负载均衡 应用软件负载均衡通过多个层次上不同的负载均衡策略一起实现整体的负 载均衡，应用负载均衡的设计思路是将大量的并发访问或数据流量分担到多台 节点设备上分别处理和将单个重负载的运算分担到多台节点设备上做并行处
4、理 来达到负载均衡的效果，从而提高服务响应速度，提高服务器及其他资源的利 用效率，避免服务请求集中于单一节点导致拥塞。 2. 应用软件失效备援 应用软件构建在面向服务的架构、设计思想上，应用服务具有较高的可灵 活部署性。通过这种灵活性，结合系统基础设施的规划、部署可以实现应用软 件的失效备援。系统可以考虑实现基于应用服务和基于应用服务管理框架的多 种应用软件失效备援机制。 基于应用服务的失效备援是在应用服务管理框架中可以实现应用服务的冗 余部署，利用硬件负载均衡设备或应用软件负载均衡可以在需要时将服务请求 切换到相应的冗余服务。 基于应用服务管理框架的失效备是将应用服务框架在系统中冗余部署，利
5、 用硬件负载均衡设备或应用软件负载均衡可以在需要时将服务请求切换到相应 的冗余的应用服务管理框架。 3. vip 服务通道 在系统中，从系统运行稳定性、持续性及处理性能的角度，配合物理设备、 系统支撑软件（数据库系统、操作系统）的相关措施，应用软件可通过构建 VIP 服务通道的方式降低应用服务运行期间的相互影响。服务通道可以基于不 同业务产品或不同应用服务管理框架的不同粒度来设置，从而满足部分应用处 理资源只响应特定的服务请求或不同的服务监听响应不同的通道传递过来的服 务申请的功能。 4. 流量控制 在系统中，从系统运行稳定性、持续性角度，配合物理设备、系统支撑软 件（数据库系统、操作系统）的
6、相关措施，应用软件可以通过对服务请求的流 量控制机制，在系统性能波动较大时间段，对少部分影响程度高的交易进行流 量控制，保障系统运行平稳运行。 流量控制是大集中系统体系结构中提供的通过应用软件对系统实施控制的 功能。流量控制基于大集中系统逻辑架构，依据系统、子系统、渠道等不同层 面的交易流量、交易状态和确定的控制策略、控制规则，对系统实施控制。应 用系统具有如下功能： a) 流量数据采集：支持流量数据的采集功能。 b) 流量值计算：完成对采集的流量数据进行计算，检索出有流量超过额定 量的服务或交易，为后续的流量控制提供依据。 c) 交易流量控制：支持针对特定交易进行流量控制。如：针对网络流量大
7、 的交易做控制，如报表文件传输；交易高峰期对批量业务进行流量控制。 d) 渠道流量控制：支持按照渠道进行流量控制； e) 控制策略及规则管理：支持控制策略及规则的配置，修改等功能。 5. 故障隔离 在系统中将考虑实现故障隔离机制，在应用软件系统发生故障的时候，通 过故障隔离把故障造成的危害限制在最小范围内，提高系统提供对外服务的整 体能力水平。 故障隔离是大集中系统体系结构中提供的通过应用软件对系统实施控制的 功能，应用软件设计可考虑应用服务、应用服务框架的灵活部署，支持多角度， 多层次的故障隔离。应用系统具有如下功能： a) 支持按渠道的故障隔离，例如：当 POS 渠道交易响应慢，可停止 P
8、OS 渠道的对外服务功能。 b) 支持按子系统的故障隔离，例如：当查询子系统出现异常时，可停止查 询子系统的对外服务功能。 c) 支持异常服务的故障隔离，例如：若某服务出现异常（如服务 CORE DOWN） ，可停止此服务的对外服务功能。 d) 支持按交易的故障隔离，例如：若某查询交易出现服务堵塞，可停止此 交易的对外服务功能。 在渠道层的设计中，可考虑采用网络负载均衡、vip 服务通道等机制。 6. 网络负载均衡 在柜面网点前置系统侧，可以考虑采用硬件负载均衡器对网点终端连接到 网点前置的负载均衡，利用负载均衡器的连接状态检查和负载均衡策略可以灵 活地调整终端的连接指向，屏蔽因网点前置机故障
9、导致的终端操作异常，提高 网点前置系统的可用性。 7. VIP 服务通道 渠道层的 VIP 服务通道与业务处理层的 VIP 服务通道均针对提高系统的可 用性，但是在建设方式上有所区别。渠道层的 VIP 服务通道不仅可以通过渠道 层相关应用软件的服务通道设立来实现，还可以考虑通过设置物理上相互隔离 的不同渠道通路来实现。 3.主机系统 主机系统作为各应用系统的运行平台，其可用性和稳定性是业务系统能够 持续、稳定运行的前提。根据应用软件架构设计，每个子系统的功能通过硬件 负载均衡机制部署于多套主机设备上，从而消除单台主机所引入的单点故障。 对于单台主机系统而言，其高可用性和运行稳定性可从以下几方面
10、加以保 障： 1. 主机自身的高可靠性 主机采用高度冗余设计，可充分保障自身的运行可靠性，如：多处理器架 构、冗余电源、冗余风扇、冗余时钟、冗余 IO 等；同时，主机采用多种容错技 术，可有效提升自身的可靠性，如：内存与高速缓存上的检错与纠错（ECC）、 内存双芯片备用、内存和处理器自动解除配置、用于监控系统状态的独立的服 务处理器等。 2. 主机关键部件全冗余配置 为确保主机运行的可靠性和稳定性，系统主机的所有关键部件均采用了冗 余配置，以消除主机自身的单点故障，其中包括： a) 配置热插拔 N+1 或 N+N 冗余电源、风扇，避免电源或风扇失效造成的 硬件故障或宕机。 b) 配置冗余系统盘
11、，并通过操作系统进行系统盘的 RAID 1 镜像保护；或 采用 SAN BOOT 系统盘，在实现存储网络连接全冗余的同时，通过在 SAN BOOT 磁盘组中采用高可靠级别的 RAID 技术（如 RAID10+热备 盘） 、不同存储设备中的启动盘映像副本选择启动、磁盘阵列镜像（即 “双阵列启动” ）等技术，切实保证 SAN BOOT 的可用性。 c) 配置冗余网卡，并根据实际需求采用多网卡绑定技术，实现多网卡间的 自动冗余和流量的负载均衡，以提供更高的数据带宽和链路的高可用性。 d) 配置冗余光纤通道 HBA 卡和 InfinibandHCA 卡，并通过多路径软件 （操作系统或第三方软件支持）来
12、实现多 HBA/HCA 卡的自动冗余与 IO 负载均衡。 e) 配置冗余的主机管理处理器，能够在线配置、管理主机并监控主机状态， 同时支持透明接管和在线更换管理处理器。 3. 主机自身的高可维护性 主机的高可维护性对于消除计划内停机的影响至关重要，主机通过其在线 维护功能来确保其计划维护期间的高可用性。其中： a) 主机支持固件的在线升级，避免了因固件升级造成的计划内停机。 b) 在主机上采用高可用操作系统，通过支持在线处理单元板增加与删除、 动态内核调试、动态可加载内核模块框架（支持在线 IO 驱动加载与补 丁升级） 、PCI 错误自动修复、动态错误管理与安全隔离、动态根盘 （支持软件在线补
13、丁升级）等高可维护特性来实现不停机的 IO 驱动、 操作系统和应用软件的版本、补丁升级，从而避免了因软件版本或补丁 升级造成的计划内停机。 c) 主机的处理单元板、电源、风扇、磁盘、IO 等关键部件均支持在线增 加与删除，同时其硬件支持热插拔，可实现故障部件的在线更换，避免 了因部件更换造成的计划内停机。 4. 主机系统的高可用性设计 在主机上设计采用了电气隔离的动态硬件分区技术，同时各分区采用相互 独立、冗余的 IO 配置以实现自身的高可靠性。硬件分区技术在优化主机资源 利用的同时，可在同一主机硬件内全面隔离分区故障。如果一个分区中的操作 系统、软件或甚至是硬件出现问题，运行在其他分区中的操
14、作系统和软件均不 受影响。 在主机硬件分区的基础上，系统设计采用多个主机分区形成集群来为各业 务应用提供运行支撑，同时各主机集群通过 Oracle RAC 或网络负载均衡机制实 现主机间的负载均衡和自动冗余。为保证最大的可用性，应将同一集群内的不 同分区分别部署在相互独立的主机硬件上，并通过各分区相互独立的 IO 接入数 据网络、心跳网络和存储网络，从而确保了主机系统整体的高可用性。 5. 主机系统的高可恢复性设计 可恢复性定义了系统修复故障和恢复正常运行的能力。主机系统的可恢复 性从一定程度决定了系统出现故障时是否能够自动修复和快速恢复，应通过主 机系统的备份与容灾设计来确保其高可恢复性。其
15、中： a) 对主机系统盘定期进行自动化克隆备份，以便于版本管理和系统盘的失 效恢复，同时其备份的系统盘映像副本可用于主机在线软件、补丁升级 维护（通过动态根盘技术实现） 。 b) 目前，系统中采用了两地三中心+同址备援的容灾体系设计。在上述容 灾体系中，通过以下方式实现主机系统的灾难恢复： 同城容灾：现阶段基于存储同步复制实现数据级容灾，今后可考虑通过主 机的城际集群实现同城灾备中心与主中心间的主机系统自动灾难接管。 异地容灾：可基于存储异步复制、Oracle DataGuard 等技术实现应用级容灾， 今后可考虑通过主机的洲际集群实现异地灾备中心与主中心间的主机系统 自动灾难接管。 同址备援
16、：可通过存储阵列的异步复制和 Oracle DataGuard 等技术来减少 Oracle 数据库逻辑数据块损坏故障对业务系统造成的影响，相关系统主机 可按策略实现故障接管。 通过上述高可用性设计，主机系统中将不再存在单点故障隐患，这充分保 证了主机系统的可靠性；同时，主机的高可维护性设计保证了主机能够在线进 行故障硬件更换、在线扩充、不停机进行软件和补丁升级，从而有效避免了主 机的计划内停机，提高了主机系统的可用性和稳定性；此外，通过备份、容灾 设计，在一定程度上保证了主机系统在发生故障或遭到灾难时能够快速恢复服 务，从而确保了系统的业务连续性。 4.数据库 为了避免数据库主机、数据库存储或
17、者数据库逻辑错误等引起的数据库故 障，尽最大可能保障数据库提供 7*24 小时的对外服务，Oracle 提供了一个高 可用性、高可靠性和高可扩展性的数据库环境。Oracle 数据库提供数据库集群 RAC（Real Application Cluster） 、Data Guard、自动存储管理 ASM（Automaic Storage Management）故障组镜像、闪回技术 Flashback、Stream、RMAN 快速备份和恢复等技术来保障数据库的高可用性和 稳定性等功能。 在系统中，采用如下 Oracle 数据库技术提供其高可用性和稳定性： 1. RAC 数据库中如某个节点发生故障，集
18、群中剩余节点可继续提供服务，同 时这些节点可自动对失效实例进行实例恢复，以保证数据的一致性；崩溃 节点的相关虚拟 IP 可飘移到某个存活节点以继续响应连接请求；这样可有 效解决数据库服务器的单点故障； 2. RAC 数据库是共享存储的集群数据库，在 Oracle 10g 之前，如果数据文件 所在阵列发生故障，数据库依然无法提供服务。而进入 10g 之后，可利用 ASM 故障组特性，将数据文件存放在两个不同的存储阵列上，来自同个存 储阵列的磁盘置于同一个故障组中，这样即使单个存储阵列失效数据库依 然可对外提供服务，有效解决了介质的单点故障； 3. 在高可用性的人为错误方面，Oracle 数据库提
19、供了多种特性来加以解决： a) 闪回（Flashback）功能可解决删除记录（delete 操作）的误操作问题； b) 如果打开回收站功能，闪回特性也可解决删除对象的误操作（Drop 操 作） ； c) 闪回特性需要额外的存储空间； d) 如果无法做闪回操作，可使用“表空间基于时间点的恢复” （TSPITR） 将误操作对象所在的某些表空间进行不完全恢复，以恢复误操作数据； 一般情况下，此类操作需要额外的服务器资源； 4. Oracle 本身提供了 Dataguard 容灾技术，Dataguard 将数据量相对较小的重 做日志从生产系统传输到灾备系统，并重新应用相关日志，使备库与生产 库保持一致
20、；进入 Oracle 11g 后，DataGuard 还支持日志的压缩传输，减少 了日志传输所需的网络带宽；Dataguard 除可实现灾备，也可分流生产库的 部分工作负荷，如：生产库的数据库备份、报表生成等；DataGuard 也有如 下一些缺点： a) 主备库间耦合度较高，会加重生产库的工作负荷。在 Oracle 9i 中，如 主备库间归档日志差异过大，可能所有归档进程均用于向备库传送归档， 造成生产库因无归档进程可用而挂起的严重后果；新版本中有无此类 Bug 尚需测试加以确认； b) 日志传输效率低下。Oracle 的 DataGuard 体系结构中，一个归档日志文 件只能使用一个归档进
21、程传输，即使使用了日志压缩技术，其效率也较 低； c) Oracle 只是判断归档日志的检验和来验证日志的完整性，在原灾备中心 建设时已经过测试验证此种方式可造成备库错误； 因此，如果需要使用 Dataguard 实现容灾，建议仍然采用原灾备中心的工 作方式，使用第三方编写的传输软件进行归档日志的传输，并使用类似 MD5 校 验等方式保证日志文件的完整性，这样既实现了容灾目的，又降低了主备库之 间的耦合度； 5. 在高可用性中的计划宕机及维护方面，Oracle 也提供了一系列的特性加以 支持： a) 支持索引的在线重建； b) 可在线重定义表，此功能可实现诸如：添加/删除分区、添加 /删除列、
22、 移动表空间、堆表与分区表的相互转换、改变存储参数等操作； c) 新的“热”升级（Out-of-Place）方式将补丁安装到新的软件目录中， 以减少安装软件所需宕机时间； 在实际生产环境中，除了介质损坏、用户误操作等造成的损坏之外，还有 一种由于 Oracle Bug 导致的异常，如内存混乱、数据块逻辑损坏等。针对于此 类错误，虽然无法全面规避，但可通过以下两种途径降低系统级风险。 a) 紧密关注 Oracle 公司定期发布的补丁，并根据实际情况完成补丁的评 估、验证及生产库的安装使用，以降低系统潜在风险； b) 采用同址备援方案，通过异步数据库备份模式，以丰富处理 Oracle 生 产库数据
23、块部分逻辑错误处理试，加快系统恢复速度。 5.服务保障 根据 IT 系统运维的多年经验，系统的稳定运行离不开坚实可靠的售后服务 体系、高水平的专业服务团队和高质量的运维管理流程的支撑，同时训练有素 的系统维护人员和良好的服务保障也是确保系统故障能够快速恢复的关键。 结合系统建设的实际情况，需要从以下几个层面来保障系统的运行稳定性 和高可用性。 1. 运维管理层面 在数据中心，通过对所有硬件设备和应用软件运行状态的实时监控和统一 展现，可以实现对设备、应用软件异常的预警，同时在系统故障发生时及时报 警。 为减少人工运维操作所需的时间，提高管理人员的工作效率，降低运维管 理工作量并消除人为错误导致
24、的故障隐患，可考虑逐渐在数据中心运维工作中 推广标准化运维操作的自动化运行，通过基于配置管理数据库的流程化运维管 理工具来实现自动化日常巡检（自动化、流程化的系统健康检查） 、软件（操作 系统、补丁、应用等）的自动化安装、部署和变更监控、审计、以及自动化的 系统合规审计和数据的自动化备份等运维工作。 2. 售后服务层面 全面、及时、高质量的售后服务是关键业务系统运维的基础支撑。对于系 统而言，其售后服务体系需要从以下几方面加以保证： a) 通过厂商 7*24 小时的主动售后服务来切实保证设备的无故障运行和故 障的快速恢复。 b) 通过厂商、开发商的定期或按需巡检服务对系统进行全面的健康检查，
25、及时发现问题并予以解决，从而降低系统发生故障的可能性；同时，可 根据系统前段时间的运行状况，对系统进行必要的优化、调整等工作， 以有效提升系统的运行效能和运行稳定性。 c) 在重大活动期间，如两会、国家重要节假日、国家或地方性重大活动时， 可通过厂商、开发商的驻场保障服务来确保系统在此期间的无故障稳定 运行。 d) 在硬件设备支持在线维护的同时，应通过厂商 7*24 小时快速响应的备 件服务来保证故障部件得到及时更换，从而避免系统“带病”运行。 3. 运维团队层面 运维服务团队（系统管理员、系统维护人员）对系统设备、软件的正确操 作、使用，以及定期的检查与维护对保证系统的稳定、可靠性而言十分重
26、要。 因此，运维服务团队需要制订、完善系统维护手册，同时加强对运维服务人员 的技术培训，使得每一个运维服务人员都能够正确、标准的操作设备与维护系 统。同时，运维服务团队将与厂商、开发商深入合作，建立故障分级上报与负 责机制，以确保每一个问题都能得到及时、妥善的解决。 此外，通过收集、整理并规范 IT 运维服务管理中的信息，可逐步建立具有 针对性的运维知识库系统，并以此为基础开展 IT 运维服务的知识管理，实现知 识的创建、储存、共享和应用，从而通过知识库的服务支撑来帮助服务团队缩 短故障处理时间，提高运维工作效率，提升客户满意度。 6.小结 以上从应用系统、主机系统、数据库和服务保障等几个方面对系统稳定性 策略的探讨，影响系统稳定性的还有其他一些因素，如网络、机房环境等。 保证系统的安全和稳定运行是系统维护人员最重要的工作和责任，我们要 不断提高自己的技能，为更好地完成这一工作而努力。
