档案业务系统硬件需求计算及软件部署方案
当我们被问到某个软件系统需要的服务器资源时，相信很多朋友都和小编一样困惑。 不过，当你面前有一座山的时候，总有人愿意去爬它，尤其是像小编这样的人。 一个患有强迫症的孩子，因此有了今天的文章。
1.1. 系统部署及软硬件配置方案
1.1.1. 首先要明确软件系统的性能设计需求
考虑XXX公司档案业务和信息化建设的实际情况，综合包括部署方式、网络条件、软硬件条件、用户类型、用户数量、数据量等因素，以保证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）各种接口服务器
档案系统与其他系统交互的接口，包括与OA系统集成的档案接口服务、与统一消息平台集成的统一消息平台服务、与LDAP集成的目录服务等。 其中，统一消息平台集成服务除了部署在总部服务器上外，还需要部署到基层单位。
1.1.3. 服务器性能和存储容量的计算（小编在之前的文章中已经介绍过这一步）
1.1.3.1. 影响硬件服务器估算的因素
1.服务器内存
记忆是各种信息存储和交换的中心。 CPU执行指令、计算机执行程序、磁盘I/O操作都使用内存来交换或访问数据和指令。 内存的读写速度远远慢于处理器的速度。 ，内存系统的设计是提高系统性能的关键。
2. 磁盘I/O操作
除了满足系统存储容量外，在实际应用中服务器 硬件 软件，影响系统性能的一个重要因素就是I/O，而磁盘的I/O能力主要体现在两个方面：磁盘数据传输能力和读写能力。磁盘本身的速度。 。
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）据统计，在不使用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集团信息化规划要求，提供的硬件设施环境主要采用虚拟化架构。 物理网络顶层架构如上图所示。 在物理主机的基础上虚拟出数据库服务器、应用服务器、基础应用服务器等虚拟机。 。
