企业应用系统高可用性建设

2015-05-31中航飞机西安飞机分公司程兆辉

航空制造技术 2015年19期

中航飞机西安飞机分公司程兆辉

高可用性（High Availability）通常来描述一个系统经过专门的设计，从而减少停止服务的时间，而保持其服务的高度可用性的状态。计算机系统的可用性用平均无故障时间[1]（MTTF）来度量，即计算机系统平均能够正常运行多长时间，才发生一次故障。系统的可用性越高，平均无故障时间越长。可维护性用平均维修时间[1]（MTTR）来度量，即系统发生故障后维修和重新恢复正常运行平均花费的时间。系统的可维护性越好，平均维修时间越短。计算机系统的可用性定义为：MTTF/（MTTF+MTTR） * 100%[1]。由此可见，计算机系统的可用性定义为系统保持正常运行时间的百分比。

一般情况下，当可用性超过99.99%（含99.99%）时，即可认为该系统是高可用性的系统。系统的高可用性建设与系统的投入成本具有很大关系，可用性要求越高，其投入成本以指数级别上升，因此可用性要求不是越高越好，而是需要在系统的投入成本与可用性要求之间取得一个较好的平衡。

表1 可用性要求对应表

对于一般的企业应用系统，例如办公系统、文件编制系统或ERP系统等，可以将可用性目标定义为99.9%，这样既可以满足使用者的需求，也可以相对降低系统建设成本。对于生产型企业的核心系统（例如MES系统），其停机将造成严重的影响，因此可以将可用性要求定义为99.99%，以保持系统的最大可用性，满足车间现场生产的要求。

2 企业应用系统高可用性需求分析

某企业（以下简称为公司）经过“九五”、“十五”、“十一五”期间的信息化建设，已经初步形成了飞机产品数字化设计、制造、管理技术体系，在CAD、PDM、ERP方面开展了先期的技术研究和应用，实现了产品的数字化设计以及对制造工艺过程管理的数字化。信息技术已在公司的科研、生产与经营的各个领域发挥着越来越重要的作用，有力地支持了公司科研、生产、经营任务的圆满完成。

生产运营管理方面，公司陆续开展了生产计划管理系统、装配无纸化管理系统、采购库存管理系统等一些以服务产品的研制或批产为核心的信息系统建设，在产品生产过程中进行了应用，取得了良好的成效，发挥了信息化应有的成效。为了保证公司信息化建设持续稳定快速发展，公司对未来5年的信息化系统建设进行整体规划，对未来业务系统的高可用性提出了具体要求。

在综合管理领域，公司将业务系统分为军品生产管控、民品生产管控、MES系统、供应链、质量和工装工具系统、财务管控系统和综合管控系统这6个子业务系统，对这6个子业务系统分别定义其可用性要求，如表2所示。

3 企业高可用性方案

为满足企业整合后应用的高可用性要求，从以下几个方面进行高可用性方案的设计。

（1）基于集群和均衡负载技术实现应用服务器的高可用性：在应用服务器端，基于硬件的均衡负载可以将访问压力分散到多台应用服务器上，如果没有硬件均衡负载器，也可以通过软件均衡负载实现。在多应用服务器之间，采用集群技术共享会话数据，以保证用户信息可以在集群多个节点之间共享使用。

表2 子业务系统的可用性要求

（2）实现数据库高可用性和高性能：采用Oracle RAC技术实现数据库高可用性。利用现有的硬件和存储进行整合，逐步将现有的20+ 数据库实例减少到4～6个数据库实例，并每个数据库实例均采用Oracle RAC实现。对于非Oracle 数据库，例如SQL Server和MySQL数据库，如果有条件，建议迁移到Oracle数据库，如果无条件则保持现状。对于今后新上线的业务系统，将是否支持Oracle数据库作为重要的选型条件。

（3）实现主题数据库的设计和迁移，降低数据库数量：将现有的众多数据库进行合并，形成按照主题进行设计的核心数据库中。主题数据库改变各个应用系统“自建自用”的数据库做法，强调建立各个应用系统“共建共用”的共享数据库。不同的应用系统的计算机程序调用这些主题数据库，例如，库存管理调用产品、零部件、订货数据库；采购调用零部件、供应商、工程规范数据库等。根据信息化建设企业运营管控平台的建设需求，我们可以设计主题数据库为：

·财务主题数据库：整合现有财务、成本、资金、预算等数据，统一到财务主题数据库中。

·综合管理主题数据库：整合现有办公管理、项目管理、技术文件、档案、技改、人力资源、战略运营等数据库到统一的综合管理主题数据库中。

·军品型号生产制造主题数据库：将现有军品生产制造相关数据库整合到统一的数据库中。

·民品型号生产制造主题数据库：将现有和未来民品型号生产相关的数据库整合到统一的民品型号生产制造主题数据库中。

·工装质量供应链主题数据库：将所有工装质量供应链管理相关数据库整合到统一数据库中。

·MES主题数据库：将MES系统的数据均存放于MES主题数据库。

（4）实现水平扩展能力：在应用层采用均衡负载和集群技术实现水平扩展能力。随着企业各应用系统的逐步推广应用，当出现有服务器无法满足容量和速度需求时，可以基于均衡负载和集群技术动态向集群中增加新的硬件配置，以提高整体集群的运算能力和容量，当需要淘汰较旧的服务器资源时，也可以动态将旧硬件从集群中退出，在应用层不受影响下实现系统硬件资源的动态更新。

（5）采用虚拟化技术：利用虚拟化技术实现应用层的高可用性、水平扩展和提高资源利用率，提高现有硬件资源的利用率。

（6）提高系统的监控和管理能力：采用多种系统的监控手段监控业务系统的CPU占用率、网络利用率、在线用户、数据量和数据增长量，备份和恢复状态等内容。

（7）实现系统部署的标准化：采用标准化的硬件或虚拟机配置，标准化操作系统，标准化数据库，标准化存储等。利用标准化的硬件或虚拟机配置，可以实现采购或系统部署的迅速和标准化部署。同时将现有业务系统进行梳理，根据不同的业务压力需求设计不同的标准化的硬件或虚拟机配置级别。

3.1 应用服务器高可用性建设

应用服务器高可用性建设是为了满足应用系统在应用服务器层的高可用性要求，目前技术比较成熟稳定，我们采用基于Apache HTTP Server的均衡负载和基于Apache Tomcat的集群技术实现。

3.1.1 基于Apache HTTP Server的均衡负载[2]方案

负载均衡就是将客户端的请求分流给后端的各个真实服务器，达到负载均衡的目的。还有一种方式是用两台服务器，一台作为主服务器(Master)，另一台作为热备份(Hot Standby)，请求全部分给主服务器，在主服务器当机时，立即切换到备份服务器，以提高系统的整体可靠性。

Apache HTTP Server 2.2版本以上均支持均衡负载配置，通过均衡负载配置，Apache HTTP Server可以将请求转发给2个或多个后端Apache Tomcat 服务器，以达到均衡负载的目的，提高系统的可靠性。

Apache HTTP Server支持3中均衡负载算法，并支持SESSION粘连机制：

· lbmethod=byrequests按照请求次数均衡(默认)；

· lbmethod=bytraffic按照流量均衡；

· lbmethod=bybusyness按照繁忙程度均衡(总是分配给活跃请求数最少的服务器)。

此外，还可以通过Apache HTTP Server实现主从备份功能。Apache HTTP Server的均衡负载技术被大多数的应用软件提供商使用，是非常成熟稳定的均衡负载解决方案。

3.1.2 基于Apache Tomcat 的集群[3]方案

Apache Tomcat 提供的集群技术可以实现用户会话信息在多集群节点之间的共享，单节点关闭或故障不会影响到整体应用运行，结合Apache HTTP Server的均衡负载技术，可以最大程度地提高应用的可用性，解决了单点故障的问题。

Apache Tomcat集群配置相对简单，但对应用程序的开发具有一定的影响，内容包括：

· Session中存储的对象必须实现java.io.Serializable接口；

· web.xml配置文件中需要加入标记；

· 所有节点之间的时间必须保持同步，可以采用NTP协议实现时间同步；

· 均衡负载器必须实现Session粘连模式（sticky session mode）。

可以将Apache HTTP Server的均衡负载方案和Apache Tomcat的集群方案结合使用，以达到最佳集群部署效果，图1示意了一个4节点集群的部署模式。

服务器Server1和Server2 由虚拟机承载，每个虚拟机中安装Apache HTTP Server和两个Tomcat 实例，Apache HTTP Server之间实现均衡负载，将负载转发给4个Tomcat实例，4个Tomcat 实例之间实现集群，整个集群运行了两个Web应用程序，其中Server2使用NFS模式共享了Server1 的Web应用程序，可防止出现各节点间程序不一致的现象。

这种集群部署模式简单实用，实现成本较低，技术成熟稳定，已经在行业内外广泛得到使用，企业选取这种集群部署模式，取得了较好的效果。

3.2 数据库服务器高可用性建设

Oracle RAC[4]（Real Application Clusters），译为“实时应用集群”，是Oracle新版数据库中采用的一项新技术，是高可用性的一种，也是Oracle数据库支持网格计算环境的核心技术。Oracle RAC主要支持Oracle9i、10g、11g版本，可以支持24×7有效的数据库应用系统，在低成本服务器上构建高可用性数据库系统，并且自由部署应用，无需修改代码。在Oracle RAC环境下，Oracle集成提供了集群软件和存储管理软件，为用户降低了应用成本。当应用规模需要扩充时，用户可以按需扩展系统，以保证系统的性能。