某石化公司SAP项目存储管理和备份方案

纵横四海

　　第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 生产系统

　　考虑到技术需求中有关生产系统可靠性的要求，即组成集群系统的节点没有单点故障，并保证生产系统7x24的有效性，在工作时间系统运行正常率应达到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 系统安全性和稳定性

　　生产系统要求具有7x24小时的有效性，在工作时间系统运行的正常率应达到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 IBM共享型增值备援服务

　　这一方案相当于备援服务的第三级别，实施后可实现灾难发生后用户在1天左右的时间内恢复业务系统的运行。并且费用在三种方案中最为经济。

　　在此方案中，IBM设立灾难备份中心，提供高水准的专业机房及相关配套设施，包括IBM eServer pSeries主机及相关的外设及通讯用网络设备，由IBM专业工程师负责主机日常运行，基本操作及相关维护。

　　当灾难发生时，用户将前一天的数据备份用磁带的方式恢复到IBM灾难备份中心的eServer series主机上后交由最终用户使用。

　　在这种方案中，由于不同的用户不可能同时发生灾难，IBM准备的机房和设备可以提供给多个用户，所以对单一用户来说可以用较低的代价实现业务连续性和灾难恢复。另外，用户还能享受一年两次（每次两天）的灾难恢复模拟演练，以方便用户对备份策略、恢复方案及应急措施进行检验，以确保用户在真正灾难发生后能及时恢复业务运行系统。