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