第1章 技术需求
目前客户的 ERP 系统为 SAP 系统 (R/3 4.6C SR2) ，基于 UNIX / ORACLE 构架。
生产系统采用三层结构，即数据库与 SAP 应用系统分别存放于两台服务器上。
根据各实施企业预估的 SAP 用户数和实施的 SAP 应用模块，同时考虑实际终端用户数SAP 用户数的需求情况，各实施企业生产系统的 SAP 服务器配置要求如下：
总部 ERP 开发和测试服务器性能指标需求：
– SAP 开发服务器：SAPS>=6000 ，硬盘>=235GB
– SAP 测试服务器：SAPS>=6000 ，硬盘 >= 335GB
第2章 技术方案建议
2.1 SAP 系统架构
SAP 系统是三层架构，分为前端客户、中间层应用及后端数据库，中间层应用及后端数据库是通过预先定义的 SAP API 及 DBMS SQL。从服务器来看，有些用户将中间应用层及后端数据库层放在同一个物理服务器平台上;但大多数用户还是选择将数据库和 SAP 应用运行在不同的物理服务器上，这样 SAP 系统运行的效率更高，而且可靠性更好。
SAP 系统架构如下图：
该系统设计通过将 SAP 应用及数据库运行在不同的物理服务器上，为 SAP 实施提供了卓越的性能及良好的可扩展性。SAP 应用可以运行在多台 IBM p 系列小型机服务器上，理论上可以为 SAP 应用系统在纵向(即交易量)及横向(及交易种类)提供无限制的扩展。数据库服务器运行在 IBM p 系列小型机服务器上可以获得对数据操作的很好的性能。这两台服务器处于同一个局域网网段内，并且组成双机集群进行相互备份。前端运行在用户桌面的 SAP 应用仅能看见运行在中间层的 SAP 应用服务器，而不能看见后端的数据库服务器，这样可以避免客户端直接访问数据库。
这种设计的主要特点体现在：
系统的高性能
平台的高可靠性(IBM的硬件平台和操作系统)
低成本高效率(SAP应用和数据库运行在不同的物理服务器上,相互之间进行热备份)
开放平台
UNIX 是流行的操作系统之一，掌握的人相对较多，而且易于学习。目前实施的 ERP 系统，建议选用 IBM p 系列服务器作为核心的数据库和应用平台，即可以利用 IT 开发和维护人员对 UNIX 操作系统的技能，同时又可以满足对于系统高性能、高可用性及高扩展性的要求，支持大规模用户和工作负载的要求，消除今后发展的瓶颈。
系统容量的估算 — SAP 系统 Sizing 的原理
Sizing 指对 SAP 系统硬件设备配置的预估(主要包括内存 Memory、处理器 CPU 和存储器Disk)。SAP 与其合作伙伴共同开发了在线的评估工具”Quick Sizer”来帮助用户完成配置预估工作。在相应的 Internet 站点上，SAP 向客户询问一系列相关信息(包括人员信息及业务信息)，”Quick Sizer”根据这些信息通过一定的算法，估算出所需的配置。”Quick Sizer”所用的算法是根据 SAP 公司及其合作伙伴的标准测试以及客户使用反馈的经验数据共同制定的。”Quick Sizer”的结果并非精确数值，它只是建议一系列系统负荷的相对参数作参考，根据这些负荷参数可以对某确定硬件型号的配置进行规划。”Quick Sizer”不对硬件供应厂商或平台作评价，具体的选择由用户和硬件供应商共同决定。SAP 系统硬件设备配置的确定最终还是要根据实施顾问的经验，参考业界已有的成功实例并与专业硬件工程师共同来完成。
“Quick Sizer”定义了两类评估模型：基于用户的预估、基于业务量的预估。
基于用户的预估通过了解每个业务模块的并发用户数量来估计系统的负荷。所需的输入信息为实际生产系统中各业务模块将同时登录的用户数量。内存(MEMORY)大小的预估只能通过这种方法进行。由于并非所有用户都同等频度地使用系统，基于用户的预估把用户分成三种：低、中、高，一般每小时在系统上处理的会话数(一次屏幕的切换为一个会话)在 10 个以内的为”低”用户，在 120 左右的为”中”用户，在 360 左右的为 “高”用户。
基于业务量的预估基于系统所处理的各种对象的实际数量作评估。这种方法用来预估处理器(CPU)及存储空间(DISK)。存储空间的大小可以通过估计 SAP 数据库表将如何因各种业务对象的创建而增长，处理器(CPU)的需求通过估计业务对象创建过程中会话事务或批处理事务执行所需的时间而实现。内存(MEMORY)的预估不能通过这种方法实现。这种方法所需的输入信息为每年系统各业务模块中将处理的业务对象及子对象总量等。具体包括：每年创建的对象数量(如各种凭证、单据等)、各对象所含的子对象数量(如一张凭证的细目条数等)、对象在系统中需保存的月份数量、业务高峰时节及其间对象创建的频率，等等。
在全球已实施的众多 SAP 项目中，”三系统蓝图结构”使用最为广泛，业已成为默认的标准。这样的整体架构中必须至少包含三套 SAP 系统：生产系统、开发系统、测试系统。它们的作用分别如下：
生产系统(Production System)– 企业日常运转实际使用的系统，其中存有企业的完整业务数据，生产系统中不允许直接做客户化或开发;
开发系统 (Development System)– SAP 项目的实施系统，各种业务模块的客户化工作、相关的应用开发等在该系统中进行;
测试系统(Testing System)–为各种客户化和开发工作提供完整测试的系统，其中存有企业实际业务数据，用以验证客户化和开发的正确性。
实施企业小型机和磁盘阵列的选型
根据实施企业的技术需求，以及 IBM p 系列小型机服务器的 SAPS 值，我们可以确定满足某石化公司 2003 年 ERP 实施企业的技术需求的 IBM p 系列小型机服务器的型号和主要配置。
2.1.1 生产系统
考虑到技术需求中有关生产系统可靠性的要求，即组成集群系统的节点没有单点故障，并保证生产系统 7×24 的有效性，在工作时间系统运行正常率应达到 99%，全年总体运行正常率应达到 99.5%，我们建议将数据库和 SAP 应用运行在不同的物理服务器上，这样 SAP 系统运行的效率更高，而且可靠性更好，全年总体系统运行正常率可达 99.99%。
逻辑连接图示如下：
根据上图，我们可以将服务器的选型方案及其扩展性能列表所示(考虑到集群中的数据库服务器和应用服务器相互备份的切换因素，我们建议应用服务器应与数据库服务器配置相同)：
同时，随着业务的发展和用户数的增加，现有配置的系统还将面临升级和扩容的要求，以满足对系统处理能力的要求。在目前为石化 SAP 系统所配置的服务器中，均留有一定的扩展余地(满配后 SAPS 值大于现有 SAPS 值的 150%)。
2.1.2 存储系统
对于双机集群系统，外置磁盘阵列是必须的，这里我们建议使用 IBM 的机架式安装的磁盘阵列产品——IBM FAStT 系列，同时配备 2 台 SAN 光纤交换机，它与服务器之间通过 SAN 光纤方式连接，传输速率高达 400MB/s。基于 SAN 构架，不但可以提高双机系统的安全性，还可以十分方便的完成对存储空间与主机连接的扩展，实现未来集中的存储平台的构建。
说明：1 个磁盘阵列(IBM FAStT600)目前配置了 8 到 14 个 146GB 磁盘，一个磁盘柜最多支持 14 个磁盘，一个 IBM FAStT600 最多可管理两个扩展磁盘柜，则最大可扩展磁盘数为 42个。如果 1 套 IBM FAStT600 配满了，可以通过升级控制器的方式增加扩展能力，当升级到IBM FAStT700 或 900 时，最多支持 224 个磁盘，还可以通过 SAN 光纤交换机进一步增加 IBM FAStT 系列存储设备达到扩展存储空间的目的，用户可以根据需要很灵活地进行扩展。
2.1.3 总部开发和测试系统
对于开发和测试系统，比较生产系统而言，其可靠性的要求相对较低。所以，我们建议在1 台 IBM p670 服务器上建立 2 个逻辑分区，相当于 2 台独立的机器，分别作为开发和测试服务器，而每一个逻辑分区的性能完全满足某石化公司对于开发和测试系统的技术需求。
针对这样的方案，我们可以充分利用 IBM 的动态逻辑分区(DLPAR)的功能，随着 SAP开发和测试工作的负载的变化，在开发及测试服务器之间随意地、动态地调整系统的资源;而系统资源调整的最小颗粒度可分别达到 CPU=1，内存=256MB，I/O 槽位=1。这种动态调整系统资源的方式，以及精细的调整颗粒读非常适合于开发及测试系统。
另外，我们认为，没有必要采用双机备份来提高开发和测试系统的可靠性，因此，测试和开发系统的数据库服务器和 SAP 应用服务器运行在同一个逻辑分区上，采用 SAP 两层结构。
各实施企业的生产系统都配置了外置光纤磁盘阵列(IBM 的磁盘阵列产品 — IBM FAStT600);由于测试和开发系统是单机系统，因此我们建议测试和开发系统的服务器使用IBM FAStT600 提供的存储空间，同时，配置一台 IBM 的 3583-L18 磁带库，同时利用数据库服务器，作为 TSM 数据备份管理服务器，用于备份开发和测试服务器的数据。
2.1.4 系统配置
根据以上分析，我们对 SAP 系统服务器的配置描述如下：
从以上明细配置中可以看出，生产系统都按照集群系统要求配备了相关选件，包括硬件和软件(HACMP)，而且集群系统中的服务器的 SAPS 值完全满足某石化的 SAP 技术需求。
在该配置的操作系统存储中，系统盘均配置了 3 块，可以实现操作系统镜像;内置硬盘的交换(SWAP)区容量不小于 20G;另外，主机到外接存储阵列采用 SAN 结构，使用光纤 I/O通道(2G FC，存储传输速率为 200MB/s)，而且该光纤 I/O 通道是冗余的;再有，服务器的网卡满足高可靠性集群的需求，其带宽可达到 1000M，并具有 100M 的兼容能力。
在该系统方案下，如果考虑系统升级，服务器的 CPU 和内存增加的最小单位可以列表如下：
对于操作系统，以上所有服务器均使用统一的 AIX5L 的 5.2 版本，该版本支持动态逻辑分区功能，有很好的可靠性、安全性和 LINUX 的兼容性;同时，针对某石化公司 2003 年 ERP 实施系统来说，AIX 对以下软件的支持已经通过了技术认证(SAP Note Number: 502513 Availability of AIX 5L 64-bit with Oracle database)：
ORACLE9i 9.2 (64bit)
SAP 64bit Kernel(R/3 4.6C SR2)
2.2 总部现有设备利用
总部现有可共用的存储资源为 IBM ESS800，并安装了 2 台 SAN 交换机，ESS 安装完毕的可用容量为 1.2TB(210GB*6)，已使用的 SAN 端口数为 13 个(合计 16 个端口)，以分配容量为 500GB，可用容量为 700GB。备份设备方面，总部现有 SUN L9 磁带库(LTO G1 单驱动器)，与 IBM LTO3583-L36 磁带库(LTO G1 双驱动器)，目前为 10 个不同的应用数据库进行备份。
由于 IBM ESS-M800 存储设备上运行的核心应用数据已达 500GB，考虑到数据的安全性与可靠性因素(可能的误操作)，建议总部开发预测式系统与核心数据分开，应用 IBM FAStT600 进行开发与测试应用。
对于分支机构数据，可利用已有 IBM ESS-M800 存储设备提供磁盘空间(需扩容 2 组 FC盘包，有效容量可达700+432=1132GB，并增加存储设备 2 路光纤连接通道与 2 个 8 口 SAN 光纤交换机)，SUN L9 磁带机或 IBM LTO3583-L36 磁带库(已为 10 个不同的应用数据库进行备份，备份窗口已满，需增加 2 个驱动器，以满足额外的备份需要)进行数据备份。
本方案优势：提高磁盘系统性能，充分利用现有资源，同时也可为未来数据集中工作做准备。
2.3 备份需求
为了保证 SAP 系统的稳定运行，我们提供相应的磁带库备份方案：
– 在总部的开发、测试环境，配置一台IBM的3583-L18磁带库，同时利用数据库服务器，作为TSM数据备份管理服务器，用于备份开发和测试服务器的数据。
– 在各实施企业，配置一台IBM的3583-L18磁带库，同时利用数 据库服务器，作为TSM数据备份管理服务器，用于备份ERP数据库服务器数据。
3583-L18 磁带库满足以下需求：
生产系统通过磁带库每天进行高速的在线备份，速率保证在2小时内完成容量100-150GB的数据备份(IBM LTO3583-L18使用LTO Ultrium 2 FC光纤磁带驱动器，最大未压缩传输速度为35MB/s, 理论上2小时可完成： 2*3600*35MB=252GB的数据备份 );
支持自动备份功能;
备份的硬件和软件支持/兼容SAP系统的系统备份接口。
备份解决方案可以支持其他UNIX平台(HP、Sun等)服务器的备份。
实施企业备份及恢复系统解决方案
备份及恢复系统软件配置如下：
1) 存储备份软件(TSM)
2) 对SAP进行实时在线备份的软件(TSM for SAP)
Tivoli Storage Manager(TSM)是一个企业级的 Client/Server 结构跨平台网络备份、恢复及存储管理软件。TSM Client 主要功能是向 TSM Server 提供需要备份的数据，或向 TSM Server索取已备份数据及归档数据以便 Client 恢复数据。TSM Server 负责管理 TSM Client 的备份数据、备份策略，以及管理连接在 TSM Server 上的各类存储产品。
对于操作系统的备份可以采用镜像的方式，把整个操作系统备份到一个镜像文件中，恢复时，直接从这个文件中恢复;对于 TSM 客户端的文件系统，可以直接通过 TSM 来进行备份到和 TSM 服务器连接的磁带库中。
系统管理员可以通过 Web 浏览器登录 Tivoli Storage Manager Server 进行管理。为不同的Tivoli Storage Manager Client 设置相应的备份策略，例如自动备份进行的时间，备份数据保留的长短等等。
系统管理人员还可通过 Web 界面帮助 TSM Client 做数据备份和恢复。所以 TSM 的管理员无论身在何处，使用何种机器，只要能够访问到 TSM 服务器，就可以使用 Web 浏览器管理和使用 TSM。配合 TSM 的企业级管理功能(Enterprise Management)，一名管理员可方便地管理企业内多台 TSM 服务器。TSM 的 Web 访问界面都支持 SSL 的加密方式，可以为某石化提供方便安全的管理方式。
TSM for SAP 是对 SAP 进行实时在线备份的软件。SAP R/3 的系统是一个三层架构的Server-Client 的应用，如下图所示：
SAP R/3 的三层结构
第一层是数据库服务器(Database server)：R/3 应用的所有数据和 Log 都存放在此层，目前，R/3 系统支持的后台外挂关系型数据库有：Oracle、DB2、Informix、SQL 等，国内使用面最广的是基于 Oracle 或 DB2 的 R/3 应用。
第二层是 SAP R/3 的应用服务器(SAP R/3 Application-server)，SAP R/3 的源程序和客户开发的 R/3 应用集中在此层，R/3 系统通过一个内部的数据管理工具 SAPDBA 和数据库服务器紧密的关联在一起，执行对数据库服务器的系统管理、存储管理等。
第三层是用户的操作层(Presentation Client)，终端用户通过此层进行系统的具体应用。
因此，从完整的系统存储管理来说，对于 SAP R/3 的应用，在存储管理方面，必须兼顾数据库服务器和 SAP R/3 的应用服务器两个层次，才能作到 SAP R/3 应用的在线备份。Tivoli 提供了 Tivoli Storage Manager For SAP R/3 On Oracle/DB2 模块，结合 Tivoli Storage Manager，可以对 SAP R/3 的数据库服务器(Oracle 或 DB2)进行在线的热备份和恢复。在存储区域网(SAN)的环境下，可以实现不依赖网络带宽(LAN-FREE)的数据备份和恢复。
在系统中，对于生产系统的 ERP 服务器，需要使用 TSM for ERP 软件，保证系统在正常运行时可以在线备份。由于备份工作由 ERP 的控制接口控制，建议备份的策略结合实际情况，采用全量备份的增量备份结合的方式进行。
2.4 网络
目前所有服务器配置的网卡都是 10/100/1000M 自适应以太网卡，满足总部开发测试环境和各实施企业局域网的具体需求。
由于双机集群系统的要求，生产系统的服务器至少提供了 2 个以太网接口(10/100/1000M);测试和开发服务器只需要 1 个网络接口就够用了，但出于冗余的考虑，我们为开发和测试服务器也同样配置了 2 个网络接口(10/100/1000M)。
2.5 系统 安全性和稳定性
生产系统要求具有 7×24 小时的有效性，在工作时间系统运行的正常率应达到 99%，全年总体运行正常率应达到 95%。而以上 IBM 提出的方案中，系统的总体运行正常率可达到99.99%。
生产系统的服务器均使用不同的物理服务器，能够排除所有系统单点故障;而且每套生产系统都具有 HACMP 配置，系统能够自动检测和恢复系统故障，故障自动恢复时间小于 10 分钟;同时，HACMP 结构可以与 SAP 系统紧密配合，确保对 SAP 的服务影响降到最低。这种可靠性设计已经被用于很多大型的 SAP 客户。
集群软件(HACMP)的安装由卖方的技术人员负责，SAP 系统在集群环境中的调试和集成测试需要由卖方和 SAP 软件的技术人员负责，并提供相应的测试技术报告，并由甲方技术人员签字，当甲方的 SAP 系统升级时，卖方将负责提供相应的 Cluster 的技术支持和系统测试，并由甲方技术人员签字。
当发生数据中心灾难时，系统可以通过人工的方式尽快利用培训系统搭建临时的生产系统，恢复时间视具体情况而定，如：数据恢复的时间、是否需要重新安装操作系统、数据库、SAP 应用等因素。
对于电源模块，所有服务器和存储系统都配置了多路输入(三相电至少有 2 路输入，两相电至少有三个电源模块)，以及冗余风扇。
2.6 分支 机构业务连续与应急恢复方案
分支机构的 SAP 服务器在总部，这就需要充分考虑如何才能够保证业务的连续运行，以及当“灾害”发生时，如何能够应急恢复系统的使用。
2.7 服务器系统的高可用性
目前，分支 5 将采用 2 台 4 路 power4+处理器，8G 内存的 IBM p650 作为业务处理之用。在保证了足够处理性能的同时，两个 p650 之间进行双机热备份，保障了系统的可用性。
对于双机集群系统，我们配备了 IBM FAStT 系列外置磁盘阵列，同时配备 2 台 SAN 光纤交换机，它与服务器之间通过 SAN 光纤方式连接，提高了双机系统的安全性。
2.8 网络的高可用性
分支与总部之间除了要建立 512K 以上的电信专线连接以外，还应考虑建立备用的冗余传输线路。对于传输网络的冗余考量，同时也要考虑到网络带宽的使用率，在保证用户正常访问的基础上，尽量缩减带宽成本。目前有以下三种情况，可依据不同的业务情况与费用分别考虑。
1. 租用新的电信专线作为传输线路
优点：
传输线路稳定
独占方式
缺点：
费用高
长时间租用两条线路，利用率低
2. 在总部建立 Modem 池，通过多条电话线路作为传输后备
优点：
建设费用低
独占方式，通常情况下可以将电话线路暂作其他用途，提高利用率
缺点：
传输线路状态起伏大
速度依赖于线路质量，易受影响
3.
通过 Internet，以虚拟专网 VPN 方式建立连接后备
优点：
建设费用中等，依赖客户的网络设备状况而定
速度较快
缺点：
– 共享方式，通常情况下，通过Internet传输速度可以满足要求，但无法作量化保证
– 安全因素须要进行特别考虑
2.9 应急恢复方案
当系统故障或灾难实际发生时，只有数据还不够，还要让业务应用在最短的时间内在后援系统上运行起来。同时，业务人员和制度也应相应地准备就绪。
如上图所示，目前业界普遍使用的灾难备份方案有三个级别，采用灾难备份的级别越高，
灾难发生后恢复的时间就越短，但为了实现这一目标引起的投资成本则越高：
无数据丢失：专用备份中心实时异地备份。采用这种方式，用户需要在异地建立一个数据中心，并且为备份中心购买与数据中心同样多同样配置的机器，使用特定的软件进行异地实时备份并保证其能实时同步。当数据中心发生灾难后，异地备份中心与数据中心应有的数据一致，最终用户只要连接到备份中心的系统上即可继续正常工作。
活动状态的备援站点：这种方式与无数据丢失的方式有点类似，用户也需要在异地建立一个备份中心，但由于技术原因备份中心的数据与数据中心的数据不可能实现完全一致，当数据中心发生灾难后，最终用户需要人工确认数据的一致性，并通过相关方式将备份中心没能同步的数据补登到系统中。
卡车运动方式+热站点备份：在这种方式下，用户有明确的灾难恢复中心及设备。在灾难发生后，用户需要将前一日的数据备份通过磁带等介质恢复到灾难恢复中心的系统上去，再通过相关的通讯设置使最终用户能访问到应用系统。这种方式与活动状态的备援站点相比，恢复之后的系统会缺少灾难发生当天所有的数据，需要最终用户通过相关方式补录。
2.10 BM共享型增值备援服务
这一方案相当于备援服务的第三级别，实施后可实现灾难发生后用户在 1 天左右的时间内恢复业务系统的运行。并且费用在三种方案中最为经济。
在此方案中，IBM 设立灾难备份中心，提供高水准的专业机房及相关配套设施，包括 IBM eServer pSeries 主机及相关的外设及通讯用网络设备，由 IBM 专业工程师负责主机日常运行，基本操作及相关维护。
当灾难发生时，用户将前一天的数据备份用磁带的方式恢复到 IBM 灾难备份中心的eServer series 主机上后交由最终用户使用。
在这种方案中，由于不同的用户不可能同时发生灾难，IBM 准备的机房和设备可以提供给多个用户，所以对单一用户来说可以用较低的代价实现业务连续性和灾难恢复。另外，用户还能享受一年两次(每次两天)的灾难恢复模拟演练，以方便用户对备份策略、恢复方案及应急措施进行检验，以确保用户在真正灾难发生后能及时恢复业务运行系统。
