高校信息化统一架构研究与探索

韩川疆

（西南石油大学 教务处，四川 成都610500）

随着信息化建设的不断推进，各个高校都有比较多的信息化相关子系统，且基本都建立了统一身份认证平台，完成了对各个业务系统的数据抽取和整合。笔者走访的北京、上海和成都等高校，发现这些信息化子系统都各自独立，独占一台或多台物理（或逻辑）服务器，这体现了高校在信息化统一架构和资源集中管理方面意识相对比较薄弱。本文以西南石油大学教务系统服务器架构调整为例，试图利用现今互联网企业在服务器运维方面的成熟技术，提出整个高校信息化整体架构蓝图，在信息化统一架构和资源集中管理方面进行了一些探索。

一、教务系统服务器架构调整及经验

1.教务系统服务器架构的第1次调整分析

西南石油大学教务系统从2002年上线至今已到第十三个年头，到目前为止经历了两次服务器架构的调整，在教务系统软件开发商的配合下，取得了很好的效果。

学校教务系统上线初期采用两台Sun v880服务器，构建了两套完整的应用系统，数据库则建立在其中一台服务器上。该系统提供给用户两个登录点由用户自行选择登录。

系统运行四年后，一方面由于高校的进一步扩招，在校生人数成倍递增，导致学生选课时服务器资源耗尽；另一方面，由于服务器常年不间断运行，电子元件老化也影响了系统运行效率。为此，学校采用如图1所示架构，对服务器架构进行了第一次调整。调整内容有：几何数的递增，其中几张主要业务逻辑表已经接近3000万；二是随着互联网发展，各种移动应用采用非正规途径获取教务各种数据，教务系统软件层面并没有相关的保护措施。三是教务系统软件本身程序上还有值得优化的地方。四是硬件老化。

图1 西南石油大学教务系统服务器第一次调整架构

因此学校决定按照图2所示，对原有架构进行第二次调整。

图2 西南石油大学教务系统服务器第二次调整架构

（1）前端采用Apache配合Resin集群的方式做了负载均衡，后端数据库采用双机热备的方式，后端存储和数据库服务器采用DAS（背板直连）方式连接，数据则存放在后端存储上，存储使用的是FC（光纤）硬盘。

（2）增加了监控服务器，用于收集服务器运行状态数据。还可以通过设定相关服务器参数（CPU、内存、流量等）阈值，在无人职守的情况下，将预警数据实时发送到管理员邮箱，使管理员可以第一时间赶赴现场处理相关问题。

2.教务系统服务器架构的第2次调整分析

在架构调整之后几年，运行状况一直比较稳定，但是随着时间的推移，从监控服务器所收集的数据发现，当多个教学活动集中在相同的时间段上进行时，服务器响应开始变慢。通过监控服务器收集的数据，结合对故障时间点的数据库相关分析之后，发现问题可能是多方面的。一是数据量，从教务系统上线之后，数据一直在成

（1）前端采用高效、开源的HAProxy配合keepalived构建高可用负载均衡集群。中间是应用服务器集群。所有前端的请求通过负载均衡集群自动分发到后端相对空闲的应用服务器上。

（2）同样采用开源的magent配合Memcached构建高可用的，且能自动负载均衡的数据库缓存集群。

（3）数据库集群。这里采用了Oracle RAC OneNode技术配置了两个Oracle RAC服务器（每个RAC都有两个节点），RAC-Server-1做为备库只负责读取操作，RACServer-2做为主库负责写入和更新操作。两个RAC之间使用OracleDG做同步对称复制保证数据的一致性，且同一时间两个RAC都只有一个节点在工作。

（4）后端存储和数据库服务器依然采用DAS方式连接，数据则存放在后端存储上，存储使用的是SAS硬盘。

（5）同时，教务系统软件增加数据归档功能，处理历史数据。

3.调整经验总结

经历上面两次的服务器整体架构的调整，总结出以下几点经验：

（1）教务系统软件层面问题。现在很多面向教育的信息系统开发商，在开发过程中比较功利化，基本没有考虑到程序在高负荷高并发时的优化。只有最终用户遇到此类瓶颈才着手解决问题。再加上硬件先期投入也没有考虑到架构上的优化，使得最终用户遇到此类问题时措手不及。

（2）现在很多优秀的国内外互联网公司，服务器运维能力和技术上已经相当成熟。因此，高校也应该与时俱进，参考互联网公司优秀的运维案例，利用各类开源软件，充分挖掘服务器的潜力，同时不断完善服务器架构，提高运维能力和水平。

（3）信息系统数据的增长。从西南石油大学教务系统来看，上线13年后当主要业务逻辑表数据成几何数递增时，仅仅从信息系统程序或服务器架构调整等方面的优化已经不能满足需求。还需要根据教务系统数据自身的特点，进行数据归档操作，将已经毕业学生的所有相关数据转移到另外的数据库中，信息系统则增加相应的对归档数据查询的功能。

（4）必须要建立比较完整的服务器状态监控平台，以及服务器日志分析平台。服务器状态监控，不仅仅可以及早发现服务器异常问题及早解决，同时也为了解分析其他问题提供了详细的数据依据。而日志分析，则为发现异常获取数据、信息系统自身bug提供了良好的基础。

（5）资源浪费问题。就教务系统本身而言，只有在选课、成绩录入、成绩查询等教学活动发生时才会出现高负荷和高并发的情况，而平常服务器资源占用非常低。

二、高校信息化统一架构探索

1.统一架构设想及说明

笔者设计和实施了西南石油大学教务系统的服务器架构，虽然经过调整后已经达到了很好的效果，但是如何避免服务器硬件资源的浪费，俨然成为笔者最关心的问题。

那么如果站在学校的层面，构建一个统一的服务器架构是不是能解决硬件资源浪费问题呢？答案是肯定的。但是这个架构必须能兼容高校所有的信息化子系统，必须能经受得住高负载高并发，必须能实时调配服务器硬件资源，必须能做大数据计算处理。因此笔者提出如图3所示的整体架构。

图3的架构只是给出了整体框架，在细节方面只有根据高校自身的需求进行定制，此外网络拓扑中网络冗余问题不在此架构讨论范畴内。下面针对架构进行相关的说明，由于所涉及的可用技术很多，在这里就不详细展开了，只给出笔者的建议。

2.技术及设备说明

（1）本地负载均衡集群，即负载均衡层

所有的请求（内网或外网）都由该层负责响应，并分发到后端的应用集群中。对于负载均衡，笔者熟悉的硬件或软件技术有F5和LVS、Nginx、HAProxy等。它们的性能都是非常优异的。F5是负载均衡中抗并发能力最强的，LVS是现在在全世界范围内应用最广的，而HAProxy这个开源的后起新秀性能非常强劲，国内前十的互联网公司基本都在使用。考虑到高校自身业务系统的实际情况，除了教务系统外不会有非常高的并发访问。因此这里推荐采用开源的HAProxy配合Keepalived来架构，硬件方面配置两到三台两路PC服务器就能承载校内所有业务系统的负载均衡。

如果上线运行过程中发现压力过大，可以采用下面两种方式进行缓解：

1）使用四路PC服务器，将其配置为主节点；

2）前端增加一个硬件的负载均衡F5，将现有的负载均衡集群做为中间代理层。

（2）应用集群和应用缓存集群

从负载均衡层转发的请求直接到达应用集群层中的某一个服务器节点。那为什么没有使用图3中应用缓存集群来分担压力呢？应用服务器缓存层的出现确实是为了缓解应用服务器的压力，存储已被请求过的js、images和html等文件。但是环顾一下高校的各个信息系统，以及所提供的服务，分析一下每天的访问情况，笔者认为没有必要构建这个缓存集群。如果真的需要构建，如图3所示，可以使用varnish作出两个或更多的节点，此时只需要在负载均衡层HAProxy的配置中做相应的更改即可。

图3 高校统一服务器架构蓝图

此外，考虑到各类信息系统程序运行的环境，在应用集群中需要配置至少两种操作系统（Linux和Windows）的若干节点。

（3）数据缓存集群

它所实现的功能其实和应用缓存集群的功能类似。这里可以使用Redis或Memcached等开源软件，构建出高可用的数据库缓存集群。比如西南石油大学教务系统使用的是magent配合Memcached来构建的该集群，这主要是由于教务系统软件已经使用了Memcached及相关特性，因此首先要满足程序运行环境，其次考虑高可用。最终采用magent配合Memcached构建出能自动负载均衡的3个节点的集群。

由此，可以看出采用何种技术，或者都使用，需要根据具体的信息系统软件本身的情况来决定，架构上只需要考虑高可用即可。

（4）数据库集群

由于高校繁多的信息系统可能使用不同的数据库，那么在这里就需要根据实际情况构建多个不同类型的数据库集群，从对西南石油大学教务系统进行分析调整的过程中，笔者发现只有当信息系统的访问量和并发量高到一定程度之后，数据库就成为了压力集中点。因此需要注意至少配置两个节点构建出一主一备读写分离的同类数据库节点。

（5）Oracle、MySQL和SQLSever说明

1）Oracle数据库。可以采用上面已经提到的西南石油大学教务系统优化的方案。即采用了双OracleRAC配置，需要应用程序配合将读写操作分开，两个RAC之间使用OracleDG做同步对称复制，它保证了两个RAC直接数据的一致性。同时，Oracle RACOneNode技术最大化利用服务器资源，平常两个RAC的主节点占用比较多的硬件资源，而备用节点则占用少量硬件资源，当发生故障后，主节点释放已占用的大量硬件资源，备用节点启用，接手相关业务的同时也加载和主节点相当的硬件资源。

2）MySQL数据库。由于软件本身免费，因此使用范围是最广的。面对并发压力大的情况，成熟的方案也比较多，常见的主要有下面三种：

①常规复制架构，即Master-Slaves。这里Master负责写入和修改操作，一个或多个Slave则负责读取操作。同时将Master同步复制到一个或多个Slave。当一个节点的Slave读取压力过大时，则需要考虑增加Slave节点；

②级联复制结合架构，即Master-Master-Slaves。双Master主要是为了避免常规复制架构中单点写入和修改操作可能存在故障的风险；

③MySQL数据库切分，即MySQL Sharding。其基本思想就要把一个数据库切分成多个部分放到不同的数据库节点上，从而缓解单一数据库的性能问题。因此可以通过该技术将一个大的MySQL Server切分成多个小的MySQL Server，既解了写入性能瓶颈问题，同时也提升了整个数据库集群的扩展性，从而解决了数据库压力过大的问题。

3）SQLSever数据库。只考虑微软提供的做法，仅仅只能做到故障转移。简单的说就是利用Windows Server故障转移群集 (WSFC)功能，当数据库实例发生故障时，在其他冗余服务器上重新启动该数据库实例，从而提供了本地数据库的高可用性。这就类似一主一备（或互为主备）的服务器概念，没有负载均衡的功能。在发生数据故障转移时，将数据库实例由一台服务器转移到另一台服务器的时间非常短暂。

（6）磁盘阵列，即数据存储

笔者把高校的数据分为核心数据和非核心数据。其中核心数据则包含教务、财务、一卡通等主要业务系统数据。而非核心数据，主要包括电子图书、期刊、教学资源类、学习资源类等。这么划分的原因是鉴于这些业务系统是否能中断服务，可以临时中断的则划为非核心数据，反之则是核心数据。

现今的存储主要可以分传统存储和分布式存储两种。传统存储的架构方式主要有DAS、NAS和SAN。结合笔者对高校数据划分以及预估的存储容量的情况，使用NAS结合SAN才是高校存储最好的方案，而分布式存储技术投入和维护成本方面都远高于传统的存储。

NAS架构主要用于存储非核心数据，而SAN架构则用于存储核心数据。对于存储的物理磁盘，笔者建议直接使用SAS硬盘。在经费充足时，可以考虑有数据分层功能的NAS+SAN存储，即存储根据特定算法将数据分片，使用率高的自动迁移到SSD盘上，使用率一般的迁移到SAS盘上，使用率很低的则迁移到SATA盘上。

（7）Hadoop集群

主要是为了满足高校在大数据方面的需求而建立。Hadoop本身是一个开源框架，同时Hadoop的高可靠性、高扩展性、高容错性和高效性等诸多有点也是整个互联网企业已经验证的。虽然Hadoop搭建比较简单，但是如果要真正为高校的领导决策、学生学习指导、学业预警等提供参考数据，前期规划和后起运维也是必不可少的，而且后续还要有配套的相关支持分布式计算的应用程序。

（8）本地灾备中心和异地灾备中心

主要是出于数据层面的安全考虑。虽然可以根据实际情况的要求选择性的建立，但是从整个架构数据的安全性和完整性来说，这也是必须的。

（9）管理集群

通过上面的描述，不难预见对于管理人员是多么大的挑战，所谓工欲善其事必先利其器，建立一个完整的管理集群，提高管理人员的工作效率，提高整体运维水平是有直接影响的。

1）Monitor即监控平台，提供了服务器实时状态数据，为高负载高并发时服务器问题的分析提供了良好的数据参考，实时采用适当的措施解决出现的问题。同时，在无人职守的情况下可以通过电子邮件或短信等方式发出预警信息，方便运维人员能第一时间赶赴现场处理问题；

2）Pupput是一个开源的多平台集中配置管理系统。试想服务器集群的配置如果一台一台去设置，会浪费多少时间和精力呢？因此在管理集群建立该系统，可以实现对该架构下所有服务器的管理系统配置文件、用户、cron任务、软件包、系统服务等配置信息进行管理；

3）D BAudit即数据审计平台。数据的安全从来都不是某一方面可以完全保证的，而是需要利用多种方式结合保证。这里将数据审计纳入管理集群，因为不管什么类型的数据库，开启数据审计后对自身性能或多或少都有一定的影响。那么开启的时机把握，这必须由运维管理人员根据业务系统访问情况来决定。同时，建议高校结合各个数据库自身的审计功能，做一定的独立开发构建符合自身特点的审计平台。而不是购买数据审计软件，因为可以兼容所有数据库的数据审计软件，功能上都比较中庸；

4）LogAnalyse即日志分析，可以结合Hadoop集群，给出很多值得参考的数据。比如访问时间热点、访问来源、访问出错点、访问异常点等。为进一步调整架构、发现业务系统bug等提供了良好的依据。

3.部分场景问题分析及解答

（1）应用场景一：教务系统如何部署？

图3所示架构是在图2所示架构的基础上发展而来的，因此完全兼容教务系统本身，唯一需要注意的是原来采用DAS架构直连存储，现在则是采用SAM架构，对操作系统层面没有太大的区别。

（2）应用场景二：没有采用相关缓存技术的应用系统如何部署？

1）本地负载均衡层配置相应访问IP地址，以及后端单节点或多节点应用服务器IP地址；

2）应用集群中该业务系统的一个或多个节点服务器配置直接访问数据库的IP地址；

3）单节点数据库可以共用或独立使用一个数据库集群的服务器节点。

（3）应用场景三：学校的统一数据库如何部署？

直接部署在数据库集群上，按照实际需求分割出一个或多个节点即可。

（4）应用场景四：单个业务系统处于高并发时如何处理？

首先根据监控平台数据分析高并发后业务系统的瓶颈。比如瓶颈在应用层，则考虑是否需要使用应用缓存集群，以及增加应用集群中该业务系统的节点数量。比如瓶颈在数据层，则需要根据数据库的类型来确定调整的方案，限于篇幅此处就不再展开。

4.需要注意的一些问题

该架构整合了学校所有硬件资源，能满足各类型信息系统的要求，但是还需要注意以下几个问题：

（1）整个架构都基于虚拟化平台，建议采用免费的XenServer做为虚拟化平台管理软件；

（2）硬件资源（即PC服务器）分批购置，先满足基本业务然后逐步扩展，建议不要都使用同一厂商的产品；

（3）硬件老化后维保成本较高时，建议直接淘汰购置新硬件；

（4）优秀开源项目的软件很多，采用开源软件也能为学校节约相当大一部分资金，但是需要有优秀的运维人员，因此需要建立良好的人才培养机制，做好人才储备工作；

（5）需要根据学校实际的情况，对整个架构做局部的调整，只有通过不断地微调得到符合自身需要的架构。

三、总结

根据笔者对西南石油大学教务系统服务器架构调整的经验，提出了整合资源、统一部署的信息化整体架构，相信高校只要加强这方面的意识，从自身已拥有的信息化系统需求出发，结合互联网企业优秀的运维技术和运维案例，肯定可以在此架构基础上设计出符合自身特点的信息化统一架构，为节约办学成本、实施大数据战略提供有力的保障。