档案业务系统对硬件需求的计算与软件部署方案

当我们被问及某个软件系统需要的服务器资源时相信很多小伙伴都跟小编一样是一脸懵逼的，然而山在眼前，就总要有人肯去登攀，特别对于像小编这样有强迫症的孩子，于是便有了今天的这篇文章。

1.1.系统部署与软硬件配置方案

1.1.1.首先我们要明确软件系统的性能设计要求

考虑到XXX的档案业务以及信息化建设的实际情况，综合包括部署模式、网络情况、软硬件情况、用户类型、用户数量、数据量等各方面因素，为确保XXX档案管理系统的正常、稳定运行，XXX档案系统将至少满足下述性能指标：

·系统将支持对关系型数据库的文本数据以及大对象类型数据检索能力；

·系统的数据交换要求采用XML机制提供服务；

·系统支持并发用户数大于100人；

·百万目录数据量带全文，检索客户端响应时间：≤2秒；

·系统无故障运行时间大于5000小时；

·系统恢复时间小于4小时；

·电子目录数据接收，导入（导出）临时或核心数据库每批次能承载百万条以上，记录数据信息不发生错误；

·正确描述硬件负载情况，同时保证我方推荐的服务器及存储的配置要求能够满足未来五年企业档案发展的需求，且可扩展。

1.1.2.其次我们要画出系统逻辑部署视图

系统部署将在XXX集团“统一平台”规划下，充分考虑集团总部档案信息化现状以及未来档案管理的发展趋势，档案管理系统将按照“集中应用、统一存储”的方式进行部署。同时将充分考虑部署方式的灵活、可扩展，能够随着集团公司基础设施的日益完善，逐步过渡到“云计算”模式。

基于项目性能要求以及可扩展性设计原则，在设计基础设施时逻辑上有以下逻辑服务器：

1）数据库系统

用于存储档案管理系统的结构化数据，是一个实际可运行的存储、维护和应用系统提供数据的软件系统，是存储介质、处理对象和管理系统的集合体。

2）文件存储系统

用于存储档案管理系统的非结构化数据，支持DAS/SAN/NAS/虚拟存储/云存储等存储模式。空间大小根据实际数据量而定，设计3~5年的存储量，建议采用RAID-5技术。

3）应用服务器

部署中间件服务器及档案管理系统应用，面向用户提供应用服务。

4）基础应用服务器

为档案管理系统提供基础性服务，包括全文索引、电子文件处理、WEB报表、流媒体、缩略图等基础应用服务。

5）各种接口服务器

用于档案系统与其它系统进行交互的接口，包括与0A系统集成的归档接口服务，与统一消息平台的统一消息平台集成服务，以及与LDAP集成的目录服务等。其中，统一消息平台集成服务除了部署在总部服务器上之外，还需要部署到基层单位。

1.1.3.服务器性能及存储容量测算（这一步小编在之前的文章里已经有过描述啦）

1.1.3.1.硬件服务器估算影响因素

1.服务器内存

内存是各种信息存储和交换的中心，CPU执行指令、计算机执行程序、磁盘I/O操作，都要通过内存来做交换或者存取数据和指令，内存读写速度远远低于处理器速度，内存系统的设计是提高系统性能的关键。

2.磁盘的I/O操作

在满足系统存储量之外，实际应用中，影响系统性能的一个重要的因素是I/O，而磁盘的I/O能力主要体现在磁盘数据的传输能力和磁盘本身的读写速度2个方面。

3.CPU的运算能力

4.网络的带宽和使用状态

5.容量规划的因素

6.处理量因素

（1）接入的业务应用的数量：接入的业务应用数量越多，档案管理系统需要维护的信息越多，占用容量越大。

（2）档案管理系统平台服务调用频率：基础服务和操作型服务被调用的频率较高；统计型和决策型服务被调用的频率较低。如果应用集成平台上的基础服务和操作型服务所占比重较大，需要较高的CPU和内存配置。

（3）数据类型和大小：数据越大，对cpu，内存和磁盘I/O要求越高。

（4）并发请求数会对档案管理系统产生重大影响。并发请求的增长会导致性能下降。

7.硬件配置和性能要求

应用性能指标达不到预期通常表现为违背SLA（响应时间长）、应用调用异常或CPU满负荷。在这种情况下，硬件配置将是首先想到的问题，这是决定系统容量最重要的指标。系统性能与CPU的处理速度有着直接的联系。通过增加更多的CPU或者使用处理速度更快的CPU，系统容量也会随之增加。更新的处理器技术也是决定系统性能的重要因素。同样，试用硬件SSL加密、解密也将大大提高系统的处理能力。

8.集群配置

为了充分发挥硬件系统多CPU、大内存的优势，必然要通过多配置服务器的数量，通过多个服务器集群来提升整体系统容量。

1.1.3.2.应用服务器处理能力估算方法及选型系统的应用服务器主要基于WebLogic的J2EE服务器进行开发，处理能力估算方法采用B/S架构应用服务器的性能估算指标。

基于Java的业务应用系统的性能指标主要有两种，一是SPECjAppServer2004，另一个是1、SPECjAppServer2004性能指标：

建立在标准J2EE三层架构的模型之上，大量使用了EJB，Session Bean作为业务组件，Entity Bean作为持久化组件，以及Message Driven Bea作为消息通信组件。这种应用设计与档案管理系统的架构有较大的区别，因此不适合作为的本次应用服务器性能估算标准。

2、SPECjbb2005性能指标：

SPECjbb2005是SPEC委员会制定的一套Java基准测试程序，它是用于测试Java服务器的性能。SPECjbb2005模拟了三层客户/服务器模型结构，所有的三层结构都在一个JVM（Java虚拟机）内实现。SPECjbb2005基准测试借用了TPC-C基准测试的概念、输入产生、和交易模式。SPECjbb2005主要关心的是第二层业务逻辑的处理能力，即考察用Java编写的应用程序运行在单台服务器上所表现出的性能。

3、性能估算方法

系统性能估值公式bops/s=用户并发数*每秒交易数*性能开销/系统的冗余比例

其中：

（1）高峰期并发用户数为：用户总数*30%*10%，对于档案管理系统，每个用户的请求并不一定使用档案管理系统数据，定义10个用户请求有2个使用档案管理系统数据，其中30%为在线用户比例，10%为并发用户占在线用户比例。

（2）根据参考经验值估算，每次用户访问包含的交易数：10个。

（3）根据统计，J2EE应用服务器的性能开销，在不使用EJB等重量级的组件条件下，J2EE应用服务器的性能开销主要在WebContainer和数据源方面，约为业务操作数的0.8-1倍，取均值：0.9。

（4）系统的冗余：30%（即高峰期利用率不超过70%）。

并发用户按照100人来测算

系统性能估值公式 bops/s==100*10*0.9/70%=142874、应用服务器的选型

根据性能估算结果，通过咨询相应的硬件厂商，得出建议采用的应用服务器，

配置为：CPU：2颗，每颗6核，主频为2.4GHz，内存：16G；硬盘：2*146GB；

2个网卡。

（以上配置按物理机配置建议仅供参考，项目实施时需根据资源池实际环境情况调整配置，也可部署在虚拟机上运行。）

1.1.3.3.数据库服务器处理能力估算方法及选型TPC-C是一种旨在衡量OLTP系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多数据专业设计人员将TPC-C视为衡量OLTP系统性能的有效指示器。

TPC-C基准测试是对硬件处理能力的考核标准。TPC-C通过模拟一个批发商的货物管理系统，衡量硬件服务器的性能指标（查询、统计功能的执行效率）。

1、数据库服务器的性能估算方法TPC-C

由于本项目涉及到的数据库服务器，基本都是典型的OLTP应用，因此，按照业界标准的TPC-C来计算；理论上来说，TPC-C指标也是用来评测一个系统处理OLTP整体的性能，包括软件，硬件服务器和网络等各种环节；假设硬件之外的软件和网络等都是理想的情况，根据各个数据库实际可能的并发交易数量和类型，估算出硬件服务器（CPU、内存、IO等）需要支持的tpmc 指标值。

2、数据库的性能参数估计：

（1）并发用户数

（2）数据库交互比率（应用服务器与数据库发生交互的请求数），约70%。

（3）高峰期每个用户每分钟访问频

（4）每次访问包含的交易数

（5）应用服务器每个交易折算标准交易系数（6）系统冗余比例

业务受理类占20%，每笔业务产生标准事务数：6。

信息查询类占60%，每笔业务产生事务数：3。信息浏览类占20%，每笔业务产生事务数：3。

3、公式

TPC-C值=并发用户数*数据库交互比率*高峰期每个用户每分钟的访问频率*每次访问包含的交易数*每个交易折算标准交易系数/系统的冗余比例根据要求，业务操作的响应时间应控制在5秒以内，应用服务器与数据库的交互比率为：

TPC-C值=100*70%*（20%*6+60%*3+20%*3）*60/70%=216004、数据库服务器的选型

根据性能估算结果，通过咨询相应的硬件厂商，得出建议采用数据服务器，配置为：

CPU：2颗，每颗6核，主频为2.4GHz；内存：16G；硬盘：2*146GB；2网卡。

（以上配置按物理机配置建议仅供参考，项目实施时需根据资源池实际环境情况调整配置，也可部署在虚拟机上运行。）

1.1.3.4.存储容量计算

1.数据库容量计算方式：

所需数据库空间=2G+文件系统历史数据条数×2kb+（数据库年条数增长量×2kb索引量）×保留年限）/（1-存储冗余）

2.电子文件容量计算方式：

所需存储空间=（电子文件系统历史数据总量+电子文件系统数据年增长量

*保留年限）/（1-存储冗余）。

说明：

物理存储空间考虑冗余，建议10-15%冗余。

电子文件系统历史数据总量：需要调研待接入的业务应用电子文件数据情况。电子文件系统数据年增长量：需要调研公司待接入的业务应用电子文件数据情况。

索引量=公司数据库年增长量*0.8。

3.数字化文件存储容量

XXX现有的数据量约为：128万页的纸质文件，100张照片，200件实物档案以及25T的声像档案。

·单页纸质文件扫描成电子文件后的大小约为50K

所占容量约为：128000*50/1000/1000=64G

·照片扫描成电子文件后的大小约为2M；所占容量约为：100*2/1000=0.2G

·实物档案经过数字化处理后的大小约为5M；所占容量约为：200*5/1000=1G

·声像档案所占容量为25T可得出XXX所需的存储空间约不超过：26T；考虑到业务的增长，为了满足5年内的数据存储，建议配置的存储容量为30T。

按照XXX集团信息化规划要求，所提供硬件设施环境主要采用虚拟化的架构，物理网络拓普架构如上图所示，在物理主机的基础上虚拟出数据库服务器、应用服务器以及基础应用服务器等虚拟机。