不加载-不测试:我们如何识别VTB文档管理系统的问题

最近,VTB更改了工作流系统的某些硬件和软件组件。 更改的意义重大,无法在不进行全面负载测试的情况下继续工作:文档支持系统(LMS)的任何问题都充满了巨大的损失。



Intertrust专家在华为设备上测试了VTB SDO,该设备是服务器场,数据网络和基于固态驱动器的存储的综合体。 对于测试,我们创建了一个环境,该环境以最大可能的负载重现了真实的场景。 结果和结论-根据削减。

为什么我们需要银行中的工作流系统以及为什么要对其进行测试


VTB中的LMS是一个复杂的软件包,所有关键管理过程都捆绑在该软件包上。 该系统提供常规文档服务,电子交互,分析。 井井有条的文件散发加快了管理决策的速度,使采用这些程序的过程透明且受到控制,提高了管理质量,并提高了银行的竞争力。

LMS应确保按照既定法规明确执行决定。 这需要高性能,容错能力和灵活的缩放比例。 该系统对访问控制,同时处理的文档数量以及用户数量有很高的要求。 现在,在VTB SDO中有6.5万,而且这个数字还在继续增长。

该系统在不断发展:架构在不断变化,过时的技术正在被现代技术取代。 最近,一些系统组件被独立于导入的组件所取代,而没有专有软件。 基于CompanyMedia软件和华为硬件组合的新SDO架构能否应对增加的负载? 毫无疑问地回答这个问题,无需等待现实中的类似情况,只有在压力测试的帮助下才有可能。

除了测试新软件产品的抗压力性外,我们还有以下任务:

  • 确定银行负荷概况的服务器水平和垂直大小的确切参数;
  • 检查组件在高负载条件下的容错能力;
  • 识别集群间交互与水平缩放的熵系数;
  • 使用平台平衡器时尝试扩展读取请求;
  • 确定系统所有节点和组件的水平缩放系数;
  • 确定用于各种功能目的(垂直扩展)的服务器的最大可能硬件参数;
  • 研究应用程序在技术基础架构上的负载情况,以近似结果规划信息系统的开发;
  • 研究应用程序数据整合对单个数据存储系统的资源优化影响,从而提高可靠性和性能。

方法和设备


电子文档管理系统的负载测试通常是根据简化的方案进行的。 它们模拟快速查找和打开与其他文件不相关且没有生命周期历史记录的文档卡。 在这种情况下,通常没有人考虑访问权限和实际情况的其他资源消耗因素。

这些离婚测试通常由解决方案提供商执行。 可以理解:供应商向潜在客户展示高性能和系统速度非常重要。 简化的测试模型显示记录的系统响应时间也就不足为奇了,即使用户和文档的数量显着增加。

我们需要重现实际的操作条件。 因此,在开始时,我们收集了一个月的统计数据:我们记录了用户活动,观察了所有服务的后台工作。 LMS中集成的监视系统在这方面提供了很大的帮助。 银行员工帮助更正了有关单据流的结果数据,同时我们对预计的单据流增长进行了调整。

结果是一种测试方法,借助该方法,可以在考虑所有实际负载的情况下模拟系统中发生的过程。 在测试台上,我们以单独和各种组合的形式复制了最常见的业务操作以及最耗时的请求。 在性能测试期间,所有组件都承受压力。 执行了一些操作来计算用户对系统对象的访问权限,具有复杂分支层次结构和大量链接的打开文档,搜索系统等等。

负载测试配置文件:


  • 注册用户:6.5万,增加至15万;
  • 用户登录(身份验证)的频率:每小时5万次;
  • 用户同时在系统中工作:万人;
  • 注册文件:每年一千万;
  • 文件附件数量:每年1 TB;
  • 文件批准流程:每年150万次;
  • 协议双方的签证:每年750万;
  • 决议和指示:每年1500万;
  • 决议和指示的报告:每年1500万;
  • 用户任务:每年1800万。

这些应用程序已整合到单个存储系统Huawei OceanStor Dorado 6000 V3中,该存储系统具有117个SSD硬盘(每个硬盘3.6 TB),总可用容量超过300 TB。 计算能力被放置在华为E9000的模块化服务器系统上,并根据华为CE系列数据中心级别的交换机通过网络传输数据。 在测试过程中,我们全天候观察系统的所有指标。 所有结果(包括历史数据)均以图形和表格的形式记录下来,以进行后续分析。

负载测试硬件基础架构服务器







由于华为OceanStor Dorado 6000 V3存储系统的高性能,执行任何用户请求时的延迟很少超过1毫秒。 应用程序磁盘子系统的这种速度激发了我们进一步的研究。 我们决定通过分析历史数据来确定各种类型的工作负载对技术基础架构的影响。 获得的结果使我们能够根据硬件平台的要求灵活而准确地计划系统的开发。

在扩展方面,我们检查了:


  • 应用服务器(CMJ)的垂直扩展限制,关键资源:内核数和频率,RAM数量;
  • 通过复制功能相同的服务并在它们之间进行平衡,支持对应用服务器(CMJ)的水平扩展;
  • 客户端服务器的垂直和水平缩放限制(Web-GUI)
  • 文件存储(FS)垂直扩展的限制,关键资源:网络带宽,磁盘速度;
  • 由于分布式文件系统-CEPH,GLUSTERFS,支持文件存储(FS)的水平扩展;
  • 数据库的垂直扩展限制(PostgreSQL) ,根据关键程度划分的资源:RAM容量,磁盘速度,内核数和频率;
  • 支持水平数据库扩展(PostgreSQL) :扩展从属服务器上的读取负载,按照划分为功能模块的原则扩展写入负载;
  • 消息代理的纵向和横向缩放限制(Apache Artemis)
  • 搜索服务器(Apache Solr)的垂直和水平缩放限制。

问题与解决方案


主要任务之一是识别LMS性能方面的可能问题。 在工作中,确定了以下瓶颈并找到了解决这些瓶颈的方法。

锁定同步日志记录。 标准WildFly配置中的日志记录操作是同步执行的,并且会极大地影响性能。 决定切换到异步记录器,同时不写磁盘,而是写ELK日志聚合系统。

使用数据仓库时,初始化不必要的会话。 从存储库接收数据的每个线程都两次初始化了一个会话,以SSO模式进行身份验证。 该操作是资源密集型的,并且极大地增加了用户请求的执行时间,并且还降低了服务器的整体吞吐量。

使用应用程序缓存对象时锁定。 该应用程序使用了相当沉重的reentrantLock锁(Java 7),这对查询的执行速度产生了不利影响。 锁的类型已更改为stampedLock,这大大减少了使用缓存对象的时间。

之后,我们再次启动负载测试,以确定LMS系统中典型操作的平均时间,并将其存储在银行资料中。 我们得到以下结果:

  • 系统中的用户授权-400毫秒;
  • 查看平均进度-2.5 s;
  • 创建注册和控制卡-1.4 s;
  • 注册和控制卡注册-600毫秒;
  • 创建决议-1页。

结论


除了发现问题之外,压力测试还证实了我们的一些假设。

  • 该系统在Linux操作系统系列上的功能要好得多。
  • 声明的确保容错的原理在“热”模式下在每个组件的级别上起作用。
  • 关键组件-业务逻辑服务(接受用户请求)-具有“镜像”水平缩放,并且随着实例数量的增加,吞吐量几乎呈线性缩放。
  • 为1200个并发用户优化业务逻辑服务的大小-服务的8个vCPU和DBMS的1.5 vCPU。
  • 在单个存储系统上整合应用程序数据可显着提高生产力和可靠性,并提高可扩展性。

我们很乐意在评论中回答您的问题-也许您有兴趣了解有关测试某些方面的更多信息。

Source: https://habr.com/ru/post/zh-CN467647/


All Articles