某大型SAP系统升级改造解决方案

  文件类型：DOC/Microsoft Word  文件大小：584192字节

内容摘要：

某大型SAP系统升级改造解决方案某大型SAP系统升级改造解决方案
原有系统拓扑
现有系统的拓扑图
应用问题
在数据库备份过程中数据库控制文件在存储系统中不能自动备份,需要人工干预.
进行了HA切换后目前采用的备份软件不能正常备份.
数据库在线数据大量堆积,磁盘阵列容量告急.
在系统运行中,FAStT900配置为双控制器,但是从拓扑图来看用户只应用到其中一个控制器.
需求分析
由以上系统拓扑图可以看出,用户实施的应用系统为一个中型的SAP系统.在此系统中,服务器,光纤交换机等主要设备均为双机配备,并不存在单点故障,而且用户在远程也进行了磁带库的归档备份更加增加了数据的容灾性以及安全性.但是在此系统的运行过程中也可能出现如下问题:
由于备份软件的集成或者是软件自身问题导致数据库的控制文件不能正 常备份,从而导致数据库自动备份终止.此问题会直接导致数据库不能及时备份和数据的丢失,数据安全隐患很大.
由于备份软件的集成或者是软件自身问题导致了备份系统不能自动完成HA切换.此问题不仅会导致数据库不能及时备份数据,也会导致SAP系统的数据不能正常备份,实为一个SAP系统中的重大隐患.
由于SAP系统的运行导致数据库中的在线数据成几何级数增长,数据库的数据文件急剧增加,最终会造成磁盘阵列的容量告急.而且在此期间用户还不能通过增加磁盘或增大磁盘容量来对磁盘阵列进行扩容.此问题会让SAP系统的系统运行速度急剧降低,而且如果磁盘空间不能得到及时的释放就会导致整个SAP系统瘫痪的严重后果.
由于现有的磁盘阵列IBM FastT900虽然为硬件配置为双控制器,但是在系统工作中仍然还是采用的单控制器状态.
方案设计
从上图可以看出,我们的方案主要是利用Tivoli Storage Manager的ERP备份Agent来对SAP进行数据备份.
针对用户目前可能存在的几个问题的解决方案
首先是用户在备份数据库的控制文件时,当数据库的checkpoint发生时会导致数据库停机.我们分析是目前使用的备份软件与Oracle数据库的结合并不是非常紧密,且可能采用的是数据文件的直接复制方式,所以会导致上述问题.Tivoli Storage Manager对于数据库的备份是调用Oracle数据库中的RMAN备份及恢复工具对进行备份,同时由Tivoli Storage Manager来进行介质管理,并建立一条数据通路,将数据库中的数据备份到指定的介质上去.
另一个问题在集群系统进行切换后,目前的备份软件无法完成备份工作.我们分析这可能是由于备份软件本身的设计不够完善,对集群系统及应用程序的支持并不是很好.IBM Tivoli Storage Manager for SAP专为SAP R/3环境设计,并且在SAP R/3环境中进行了优化,侧重于自动运行,性能优化和提高管理效率.IBM Tivoli Storage Manager for SAP基于SAP的DBA(SAP R/3集成的一组数据库管理功能)进行数据库控制和管理的.IBM Tivoli Storage Manager for SAP与SAP的DBA相连接,自动管理备份记录,并均衡多种资源为多个SAP R/3系统提供服务.作为SAP DBA的智能接口,IBM Tivoli Storage Manager for SAP获得了异构环境的SAP认证,能够支持多个SAP R/3系统的大规模备份,恢复,数据复制和灾难恢复.
还有一个问题就是用户目前的在线数据大量堆积,导致磁盘阵列的负担越来越大,可用空间也越来越小,同时在增加磁盘阵列负荷的同时也增加了磁盘阵列损坏的可能性.对于这种情况,我们建议用户再增加一台光纤磁盘阵列,我们推荐为IBM的FAStT600光纤磁盘阵列,这样用户可以将SAP中的一部份不使用的数据转为脱线数据,保存到这台磁盘阵列上去,这样即减少了原有磁盘阵列的负荷,也增加了磁盘阵列的可用空间.同时,另一个主要原因就是我们建议用户在采购光纤磁盘阵列的同时再采购一套卷复制软件,这样可以将原磁盘阵列上的卷全部镜像到新的磁盘阵列上去,由于用户的应用非常关键,我们将所有的数据均保存为两份,这可以理解为一个基本的本地容灾系统.当生产用的磁盘阵列出现问题时,我们可以快速的将应用转移到新加入的磁盘阵列上去,保证用户应用的连续性.
目前用户采用的光纤磁盘阵列为IBM FASTt900,由于初期施工时为单控制器,现已经增加控制器变为双控制器,但从目前的拓朴结构上来看会有单点故障,建议在本次施工时将两个控制器全部接入到SAN网络中去,以实现高可用.
小结
用户现存的SAP系统存在着很多问题,例如数据库 ·上一篇：等价交换
·下一篇：服装厂节能改造项目方案