在汽车行业中针对SAP应用SIZING P系列服务器

1、在汽车行业中针对SAP应用SIZING P系列服务器进入2003年，中国汽车业在各种利好因素推动下呈现蓬勃发展的态势。各大汽车生产商相继建立了适合自身发展的ERP系统，提高了生产效率，降低了生产成本，强有力的促进了企业的持续发展。针对大多数企业选择SAP做为其企业资源管理系统，本文将结合实例讲解如何在汽车行业中SIZING IBM的UNIX服务器。首先，让我们对涉及到的部分SAP术语做简要介绍：SAPS（SAP Application Benchmark Performance Standard）是SIZING服务器的主要指标，通过收集用户信息，在SAP网站 HYPERLINK 上利用工具软件

2、Quick Sizer进行SIZING，得到SAPS，找到满足性能指标的IBM P系列服务器。User Based Sing是指在有限的用户信息输入下，通过SAP各模块的使用用户数、频度进行SIZING，适用于小规模系统或用户对SAP系统的使用不能预测的情况。Quantity Based Sizing是指在足够的用户信息输入下，通过各模块的使用率、生产交易量进行SIZING，适用于大规模系统或用户对SAP系统的使用有准确预测的情况。Customer Performance Test是指模拟生产环境进行SAP性能测试，通过测试结果进行SIZING，是最贴近实际使用情况的SIZING，也是最耗时、

3、耗力的方法。IBM SAP Sizing Questionnaire（附录1）是IBM提供给用户的SIZING输入表格，用户应尽量将掌握的SAP使用信息填写完整，这关系到最终的SIZING结果。目前，在全国范围内有很多汽车制造商都已使用了ERP系统进行企业资源管理，如上海大众、神龙富康、宇通客车、奇瑞汽车等。本文编写过程中，沈阳金杯正在向IBM咨询ERP系统的架构方案。许多汽车制造企业越来越感到：建立ERP系统是提高核心竞争力的重要手段。接下来，让我们以IBM给宇通客车的方案为例，介绍针对SAP系统的SIZING。宇通客车股份有限公司从2002年10月上线投产SAP的企业资源管理系统。系统上线

4、前，根据用户提供的SAP使用信息，通过SIZING得到的SAPS2000，根据IBM P系列服务器的处理能力，并考虑到业务发展因素，选择SAPS达到3790的M85做为SAP数据库服务器和应用服务器。操作系统版本为 AIX4.3.3；应用软件为SAP 4.6C，数据库使用Oracle 8.1.7；IBM UNIX服务器为1台p660-6M1(M85)，实际配置为8 x 750MHz RS64 IV CPU，8 G内存，运行SAP的数据库服务器和应用服务器，另外一台p660-6H1（H85）实际配置为 4 x 600MHz RS64 IV CPU，4 G内存，运行开发系统和备份服务器。这两台UN

5、IX服务器通过光纤网卡与主交换机相连，通过SSA接口卡与共享磁盘阵列相连，共享的磁盘阵列为IBM 7133-SSA磁盘阵列，容量为15 x 36.4GB SSA磁盘，另外配有一个3581的磁带库。系统运行至2003年5月，由于SAP系统用户数已大大超过了去年SIZING时预估的人数，系统整体性能和响应速度明显下降，已不能满足宇通客车业务数据处理需求。结合宇通的实际业务需求和近年的业务发展速度，通过分析SAP系统各个功能模块和业务数据对硬件系统资源的利用情况，从整体上对宇通ERP系统硬件平台做出更加长远的规划已势在必行。由于众所周知的SARS原因，IBM不能前往宇通客车现场进行实际数据的采集，在

6、宇通的协助下，采用了远程VPN telnet 访问的方式，对实际使用的SAP系统进行了硬件系统资源使用率的监测。通过为期一周的硬件性能和SAP系统资源监测和分析显示：在宇通SAP系统正常业务操作时，系统资源已严重不足。需要对原有系统重新SIZING，给出新的系统架构，并辅以系统优化来解决现有问题。基于宇通公司重新填写的当前SAP系统使用的情况，通过使用SAP sizing工具产生评估结果可知：对应宇通现状的要求，服务器所产生的处理能力应需满足SAPS 8790，原始数据需求应至少为 480GB/每年, 对应需要的磁盘空间 1200GB。宇通客车股份公司目前的产量约每月生产800至1000辆，未

7、来1-2年内计划将达到每月生产3000辆，这就要求系统能够每天处理大约100-150个定单，即每个定单的处理时间平均应该在2-3分钟，而目前的每定单处理能力平均为15-20分钟，远远不能满足将来的发展需要。根据对宇通当前的SAP系统硬件资源的评估和分析，我们建议了两种升级方案，供宇通公司参考：方案一：基于对硬件资源的评估和分析，对目前提高系统资源优先级最高的磁盘I/O和内存进行直接的升级，增加I/O的处理能力和内存的容量，并对目前数据库的数据进行适当的优化。具体的步骤如下：扩充一台 7133（16 x 73.4GB），扩充生产服务器p660-6M1(M85)的内存至 16G对生产数据进行适当的

8、优化方案二：基于对当前SAP使用情况的SIZING，可知需要的服务器的性能应 8790 SAPS，磁盘应 1200GB，这比最初宇通的设计规模大了很多，从实际系统资源的使用情况监测，也能反映出系统在I/O，内存等方面都暴露出很大的资源短缺的问题。由于目前生产系统M85 CPU已经是满配，整体的SAPS约为3800，从宇通ERP系统应用较长远的角度考虑，建议对目前的生产系统平台进行整体更新。同时，利用整体更新而带来的数据和应用迁移的机会，对当前的数据库和SAP应用进行适当优化，尽量减小由于数据结构和组织的不合理而带来的系统资源浪费。目前，宇通SAP系统运行于两层架构，即数据库服务器与应用服务器物

9、理上运行在同一台机器上，而本方案建议SAP系统运行采用三层架构，将数据库服务器和应用服务器分开于不同的服务器上。考虑到宇通将来整个ERP系统的规模，由两层架构变为三层架构势已在必行。方案实施过程需要SAP顾问协助进行SAP系统的迁移工作。根据IBM UNIX服务器处理能力与SAPS对照表，并考虑宇通将来的发展，应使用一台IBM p系列服务器p670( 4 x 1.1GHz CPU,8GB 内存) 做为SAP数据库服务器，和一台p670( 8 x 1.1GHz CPU,16GB 内存) 做应用服务器，且两台机器之间使用HACMP群集软件做成双机热备。存储采用IBM的FAStT900存储服务器，现

10、有的M85(8x750MHz CPU,8G内存)作为应用服务器。同时将现有磁盘阵列也并行使用。宇通目前的系统数据量已经达到了200GB，并以每天1GB左右的数据量不断增加。如果同时考虑现在每月一千辆左右的产量增加到今后三千辆的月产量，宇通每日的数据量是惊人的。因此非常有必要对部分的业务数据进行归档处理。对于这部分数据我们可以暂时从SAP系统中倒出并删除，以减少数据库的总体数据量，提高表的访问速度。这些数据以另外的数据格式存储在其它的介质上，这种介质可以是磁带、硬盘、光盘。借予宇通的数据量巨大，我们建议宇通把这部分数据集中在统一的介质上统一管理。如果在将来需要从新使用这部分数据，我们可以通过SA

11、P从外部介质中读取数据也可以把这部分数据从新导入到SAP系统中进行读取。几点思考：根据用户第二次填写的SAP系统使用数据，IBM分别做了User Based Sizing和Quantity Based Sizing，但Quantity Based Sizing结果显示目前的系统资源并不需做调整，显然与事实不符；而User Based Sizing则较为可信。因此，采用何种SIZING方法需要做多角度考虑，并非绝对。用户对SAP系统的使用率估计往往并不精确，即使系统投产后，也很难对SAP各模块的交易量进行量化，这给SIZING的准确性带来了不定因素，故最终方案需留有充分的裕度。客户化的SAP程序

12、和用户自主开发的程序对系统资源的占用往往较大，在SIZING时需充分考虑。针对生产系统需定期查看系统资源使用情况，做适当的系统优化，包括数据库和SAP应用的优化，这需要管理员对整个SAP系统有全盘的考虑。汽车制造业由于车型种类多，每量车进行成本计算时会都会消耗系统资源，同时产生大量的中间数据，由此带来的性能下降和存储资源不足往往是很难预测的，需要经验积累给出系统配置参考建议。针对汽车制造业使用SAP系统产生的大量生产数据，需要做定期存档（Archive）。若需简化Retrieve、利于查询下线数据，则可配合IBM Content Manager中的Common Store进行检索。附件一：User Based Questions from the SAP Quicksizer for Core R/3SAP R/3 StandardPRIVATELow Medium High FIFinancial Accounting FI-AAAsset Accounting TRTreasuryCOControllingECEnterprise ControllingSDSales & Distribution MMMaterials Management LE-WMWarehouse ManagementQ