文档库 最新最全的文档下载
当前位置:文档库 › 协同管理门户平台项目投标技术方案

协同管理门户平台项目投标技术方案

协同运营平台

系统后期稳定维护方案

投标单位:泛普软件

2010年3月12日

目录

一、现状 (3)

1、目前用户数情况 (3)

2、目前系统模块应用情况目前OA主要应用点在: (3)

3、目前系统架构 (3)

4、目前硬件配置 (3)

5、目前系统运行状况 (3)

6、小结 (4)

二、后期维护方案 (4)

1、应用程序角度 (4)

1.1、数据分离 (4)

1.2、元素缓存 (4)

1.3、数据库的定期优化和重构 (4)

2、系统部署角度 (5)

2.1、应用服务器 (5)

2.2、数据库服务器 (5)

附件:历史数据迁移方案说明书 (5)

1引言 (7)

1.1编写目的 (7)

1.2背景 (7)

2项目概述 (7)

2.1目标 (7)

2.2 功能描述 (7)

3需求描述 (7)

3.1方案概述 (7)

3.2查询历史数据 (8)

3.3 首次迁移方案 (9)

3.4 再次迁移方案 (9)

一、现状

1、目前用户数情况

目前总的有效用户授权数为10000人,实际已使用人数为9000人左右;目前企业的使用情况基本体现为:早高峰期间(8:40~9:30)在线活动人数在3500~4000之间。

2、目前OA系统模块应用情况目前OA主要应用点在:

?和NC作人员同步;

?组织门户发布信息

?启动,审批各类事务性流程(每天维持在新发起1000个流程,审批2000个流程);

?发布新闻,制度,公文类文档(每天维持在新建1200篇左右的新文档)。

3、目前系统架构

系统目前采用4台应用服务器构成应用集群;系统中所有产生的文档统一存放在存储设备上,

4个应用服务器共享该存储设备;一台数据库服务器作为应用的唯一数据库;通过F5完成负

载均衡功能,将所有的访问用户根据4台应用服务器当前的应用压力情况进行自动分发。4、目前硬件配置

应用服务器:

cpu:4*4cpu Intel(R) Xeon(TM) CPU 3.00GHz

内存:16G

数据库服务器(HP Integrity rx7640):

CPU:4*Intel(R) Itanium 2 9000 series processors (1.6 GHz, 18 MB)

内存:32G

5、目前系统运行状况

从近3个月的使用情况看,系统运行基本比较稳定(年前出现过两次系统故障,分别是因为

有大量客户端中了病毒大量并发访问OA;数据库服务器SWAP值过小导致),早高峰系统

的访问响应时间基本能够保持在3秒左右;

各个服务器CPU,内存使用也比较稳定

应用服务器:cpu:43%, 内存:20%

数据库服务器:cpu:72%,内存:94%,swap:60%

6、小结

从以上数据可以看出,在进行了应用集群部署后在应用服务器层面系统性能已经完全可以支

撑大用户量的并发访问,目前系统的压力更多是由于早高峰的大并发数据库访问和不断增长

的数据量引起的数据库服务压力上。

基于该现状泛普软件提出以下的后期维护方案。

二、后期维护方案

随着用户数和系统数据的不断增长,泛普软件拟提出以下的解决方案来保证系统的持续稳定使用,将主要从应用程序和系统部署角度两个方面来保证系统的稳定性。

1、应用程序角度

1.1、数据分离

随着系统使用时间的延续,it项目管理软件中的数据量将越来越大,这将逐步增大系统的数

据库压力,主要将体现在门户推送速度,和文档,流程的查看速度将逐步变慢;而实际上这

些数据中的绝大部分历史数据用户并不关心,因此泛普软件提出历史数据分离的方案,将通

过时间戳的概念来实施系统分离迁移,将历史数据从日常应用系统中迁移到历史系统中,在

正常的日常应用系统中用户将面对的是最新的数据。详见《历史数据迁移方案说明书》

1.2、元素缓存

从企业的使用情况来看,在高峰时期对数据访问压力最大的实际是首页中的多个元素的和数

据库的交互,在显示这些元素的时候对每个元素的每条信息都需要通过复杂的权限运行来获

取用户的可访问列表,而实际情况是这个大部分元素都是显示公告通知类文档,此类文档实

际都是公开权限的,针对于该情况,泛普软件拟提出定制特定缓存元素来取代目前的的此类

元素:一、该类元素中展现的文档系统将不作权限控制;二、该类元素将缓存处理,该类元

素的内容将从数据库获取的方式改成缓存到应用服务器上直接从数据库获取的方式,同时对

该缓存将一天更新二次,更新时间为凌晨1点和中午1点;通过该元素系统将极大的缓解早

高峰期间系统对数据库的压力。

1.3、数据库的定期优化和重构

泛普软件将对企业的数据库进行定期检查,优化和重构,主要将针对系统常用的大表,常用

的SQL语句进行3月一次的定期检查,随时根据数据的积累情况进行索引的重构,SQL语

句的性能检测

2、系统部署角度

从泛普软件的大用户使用情况及专业的压力测试工具(LOADRUNNER)测试结果并结合目

前企业的实际使用情况,泛普软件将采用如下的后期系统部署:

2.1、应用服务器

每增加3000用户,需要增加相同配置的一台应用服务器已保证应用服务器的快速响应

2.2、数据库服务器

1、扩展服务器配置

根据目前的实际使用情况,高峰期间数据库的并发连接为250个左右,对应了约8500

用户,250个并发连接需要消耗:10个G的内存,SGA大概需要13G左右,系统总内

存(32*70%=22G),因此当用户数达10000以上用户时,我们需要在目前的数据库服

务器上增加一个相同配置的板子,来满足相应增加的并发数。

2、对数据库服务器做STANDBY部署:

从目前的使用情况来,系统目前的主要压力在数据库服务器上,为了提高系统整个的

高可用性,泛普软件建议通过双机热备的架构来部署数据库服务器,由两台服务器来

共享一个数据库,两台服务器之间通过心跳线连接,一般情况下用一台服务器来提供

支持,当前数据库服务器产生意外时(如内存,CPU使用过高等)则另一台服务器将

自动接管数据库服务来支持系统应用,已保证数据库服务的始终可用。

3、数据库集群方案:

为了增强数据库服务器的健壮性和稳定性,泛普软件也建议可以对数据库服务器构建

集群(ORACLE RAC),来提高数据库服务的高可用性和稳定性。

附件:历史数据迁移方案说明书

历史数据迁移方案说明书

目录

1引言 (7)

1.1编写目的 (7)

1.2背景 (7)

2项目概述 (7)

2.1目标 (7)

2.2 功能描述 (7)

3需求描述 (7)

3.1方案概述 (7)

3.2查询历史数据 (8)

通过生产环境访问 (8)

直接访问 (9)

3.3 首次迁移方案 (9)

3.4 再次迁移方案 (9)

数据处理平台 (10)

1引言

1.1编写目的

阐述公司泛普软件OA系统历史数据迁移方案。

1.2背景

2项目概述

2.1目标

1、实现OA中历史数据迁移

2、实现第二次迁移时可能产生的问题的解决方案

2.2 功能描述

将生产环境的流程、文档等数据迁移至一台单独部署的OA系统上面,实现OA中几年前的数据分离出去,减轻OA数据库查询压力。

生产系统:保留近几个年度的数据,提升整个系统数据处理效率。

?生产系统应用于日常工作。

历史数据系统:保留除生产系统外的其他年度数据,供查询历史数据使用。

?历史数据系统只供查询历史数据使用,不应用于日常工作。

实现目标:生产系统数据+历史数据系统数据=完整数据

3需求描述

3.1方案概述

生产系统与历史数据服务器架构关系示意图:

3.2查询历史数据

通过生产环境访问

1、 查询流程历史数据

1) 快速查询流程的历史数据

a) 生产环境中输入查询条件,选择流程后面“

”,跳转至历史数据系统

b) 跳转至历史数据系统查询页面

2) 查询流程历史数据

a) 进入“我的流程->查询流程”输入条件后右键菜单“搜索历史数据”则跳转至历史数据系统

生产数据库

历史数据库

Internet

生产系统

历史数据OA 服务器

通过生产环境直接访问历史数据服务器

2、查询历史文档数据

1) 快速查询文档的历史数据

a) 生产环境中输入查询条件,选择流程后面“”,跳转至历史数据系统

b) 进入“我的知识->查询文档”输入条件后右键菜单“搜索历史文档”则跳转至历史数据系统

直接访问

1、通过生产系统单点登录

2、直接访问OA历史系统

3.3 首次迁移方案

步骤:

1、导出生产系统数据库、生产系统环境

?备份生产系统数据库,同时备份生产系统的环境,包含完整的程序与文档。

2、搭建历史数据系统

?使用备份的生产系统数据库,还原成供历史数据系统使用的数据库。

?将备份的程序与文档恢复,并使用历史数据系统的数据库,建立一个完整的系统。

3、系统集成(单点登录)

?集成单点登录后,可在生产环境中点击链接直接使用历史数据系统,而无需复杂的登录。

4、删除生产系统历史数据

?历史数据恢复后,为使生产系统减少数据压力,将删除一定期间内的历史数据。

如:假设整个系统已运行2001~2009年共9年,根据需求生产系统只保留2个年度的数据(2008~2009年),历史数据系统存放7个年度的数据(2001~2007年)。则生产系统则删除2008-01-01日前的数据。需要查询2008-01-01日前的数据,则登录历史系统查询。而2008~2009年的数据则在生产系统中查询。

5、删除历史数据系统数据

?历史数据系统只保留固定期间内的数据,与现生产系统重叠的数据则删除,以免引起重复查询。

如:生产系统保留的数据为2008~2009年,历史数据系统需要保留的为2001~2007年数据,则历史数据系统删除2008~2009年数据。

实现:生产系统+历史数据系统=完整数据

3.4 再次迁移方案

首次迁移与再次迁移的区别在于,首次迁移时整个系统还未区别历史数据,而再次迁移时则需要考虑

当前生产系统数据中导出成为历史数据的部分,与原有历史数据系统进行整合的问题。 基于这个问题,我们提供了“数据处理平台”进行对导出部分数据与原历史数据进行整合。

例如:现有系统环境为:生产系统(2006~2009年)数据,历史系统(2001~2005)年数据,由于需

要将生产环境中2006~2007年度数据导出至历史数据系统,则当前历史数据系统需要整合2006~2007年数据。那么“数据处理平台”则将2006~2007年的数据附加至历史数据系统中,使历史数据系统的数据整合成为2001~2007年度数据。

数据处理平台

数据处理平台的作用是将生产系统中需要导出的数据与已存在的历史数据系统中的数据进行有效的整合,使历史数据系统包含此次导出及上次导出的完整数据供查询。

一、迁移前示意图:

生产系统数据库(2006~2009)

+

历史数据系统

(2001~2005)

流程数据 历史流程数据 文档数据

历史文档数据

二、数据迁移示意图:

生产系统临时数据库(2006~2009)

历史数据系统 (2001~2005)

同步组织架构 同步组织架构 迁移最新流程数据 接收最新流程数据 迁移最新文档数据 接收最新文档数据

历史系统复制生产

系统数据进行整合 (2006~2007年)

数据处理平台

三、整合后的示意图:

生产系统数据库(2008~2009)+ 历史数据系统(2001~2007)

流程数据历史流程数据

文档数据历史文档数据

步骤:

1、导出生产系统数据库

?备份生产系统的数据库。

2、项目管理软件建立临时数据库存放生产系统中需要导出的数据

?需要临时存放生产系统数据库,数据处理平台需要将导出历史数据区间的数据与原

历史数据系统进行整合。

3、历史数据系统获取生产系统需导出部分数据

?数据处理平台实现将需要导出的区间数据整合进历史数据系统。

如:生产系统(2006~2009年)数据,现生产系统只保留(2008~2009年)数据,则需要将2006~2007年数据导出至历史数据系统。则数据处理平台负责将2006~2007年数据整合入原历史数据平台。

4、删除临时数据库

?导出数据后,临时数据库已没有存在阶值,删除数据库。

5、删除生产系统历史数据

?历史数据系统整合完导出区间的数据后,则生产系统中这部分数据删除

实现:生产系统数据+历史系统数据=完整数据

如:生产系统(2006~2009年)数据,历史数据系统已整合(2001~2007年)数据,则历史数据系统与生产系统重叠的2006~2007年度数据,需要删除,该年度的数据只能在历史数据系统中查询,防止重复。

相关文档
相关文档 最新文档