高可用的SAP系统架构的实现

相关推荐

高可用的SAP系统架构的实现

　　SAP的高可用软件提供给我们很方便的配置接口，让汽车用户可以配置多样的高可用汽车软件。SAP系统稳定性是建立在不断完善的监控基础上的，需要不断的从系统运行过程中弥补完善，稳定的系统是建立在稳定的规范的使用者上的，所以上线前的必须注意到统一安装，在上线后要做好审计等工作，这样系统在投入运行中才会确保数据的安全性。整个系统的稳定，高可用是建立在系统调研，设计，实施，测试，部署上线和运维中的，互相弥补，相辅相成，得以形成一个统一的稳定的可靠的ERP汽车系统。

　　1、ERP系统架构的扩容历史及范围

　　公司从成立项目组开始至目前XX品牌的XX汽车的上市，ERP系统经历了多次扩容和升级，期间更涉及一次平台转换的迁移，两次SAP版本的升级。具体的版本是ECC5.0升级到ECC6.0，又从ECC6.0升级到目前我们使用的SAP的EHP4版本。硬件设备从四台服务器的SERVER扩展到二十四台服务器的高可用的分布式的架构，涉及各类功能服务器有R3，APO，EWM系统，涉及的五个汽车工厂。在系统不断扩张，业务应用需求不断地提升的情况下，IT是如何保障用户的高可用性，并保证系统的运维性能指标从99.96% 提升到99.99%乃至100%，下面我会分别阐述IT是如何在构建，运维，管理上确保该系统的安全可靠，高可用性。

　　2、ERP建构的高可用集群是技术的基础

　　IT的ERP总体构建为高可用性架构，主要系统为R3和SCM系统目前使用的是HP的64位BL870c i2的刀片机，操作系统版本为HP-UX 11.31，配置高可用性使用的软件是Service Extension for SAP version B.05.10。支持应用的数据库和核心的central instance应用在系统出现硬件问题或网路交换机之间出现连接问题时，会触发共享的磁盘阵列进行切换，关键的应用系统被接管到了另一个节点，从而保证了外围应用服务器 DVEBMGS00，D02，D0n可以不间断的支持客户端用户使用。保证了系统在故障时可以切换到可用的节点，继续为用户提供必需的所有汽车业务应用。

　　3、SAP修改机制确保业务修改后的稳定性

　　大家一定知道汽车业务ERP系统的稳定性和汽车业务新的不断变化的需求之间是一对矛盾，IT在新汽车业务变化时系统往往不得不进行系统更改，程序版本更新，程序修正等等，这些不稳定的因素将使日常业务的稳定性和系统的稳定性受到影响，严重的将会造成系统服务器宕机，汽车整车厂生产线停线等。所以一个良好的ERP系统必须提供给用户良好的修改和配置的功能，才能适应不断变化的企业级汽车应用。SAP Change Request功能就为灵活的变更提供了变更方面的技术支持和技术控制，用户在修改程序时SAP会在开发机提供一个变更请求号，所有的程序修改，权限的修改，配置的修改，程序的版本记录都通过修改号记录在数据库中，便于用户检查，回退等控制操作。在这些修改结束后的发布阶段，通过helpdesk人员手工传输程序的改变到测试机，在测试机进行用户验证完成后，才能传入生产机最终上线提供给最终用户使用。该传输路径在系统投入后基本就保持不变。Change Request的运行机制确保了系统修改的稳定性，版本管理的一致性，并提供测试后发现问题的回退的可能。

　　4、SAP运维管理监控功能

　　4.1 SOLUTION_MANAGER的统一管理

　　SAP的运维管理软件SOLUTION_MANAGER它运行于一台单独的服务器，它提供给用户一个一致的登陆入口，实际是它提供给helpdesk 人员统一监控平台来监控系统运行状况，并能通过它还可以进行版本管理，业务流程变化管理，系统性能ALERT REPORT管理，LICENSE管理，用户账号管理，变更统一管理，以及项目执行管理等等功能，下文就常用的功能做介绍给大家。在提供这些管理功能前首先要将这些监控的系统纳入SOLUTION _MANAGER系统就是要进行合理的配置，配置完毕后就可以的看到目前公司所有纳入 SOLUTION_MANAGER管理的被管理服务器。我们目前的运维的目标是保证SAP所有这些服务器运行能力达到99.99%甚至100%的指标。

　　SAP系统作为XX整车ERP系统，它和其他系统如DMS，MES，GBOM，XX电子采购系统，XX售后仓库管理系统等等系统有数据共享，所以系统的100%的稳定是IT必须努力达到的目标。利用SOLUTION_MANAGER的报表功能，各系统会自动生成ALERT_REPORT的性能分析报告，用户根据报告可以知道目前系统的存在哪些运行方面潜在的问题，维护的IT人员就可以直接根据ALERT_REPORT的建议进行调整方案的制定。图二所示是SAP的报警报表。

　　以上报表指出3个紧急的需要处理的红色问题：1)目前汽车ERP系统备份状况不够频繁，需要增加备份频率。2)SAP新发布的安全NOTES没有及时的提供给相关的系统，需要及时打上安全方面的补丁3)标准的用户没有更改初始密码等等，建议用户修改密码。该报表还提供了系统的负荷历史的记录，可以让监控人员对突变的系统负荷有比对的图形基础，这些所有的历史报表同样被存储在一个数据库里以备查看。SOLUTION_MANAGER还提供了SAP版本的管理能力和LICENSE 的管理能力。SAP的每次版本的升级都会在网站上进行发布，新的安装软件包并不能随意下载下来安装。必须通过SOLUTION_MANAGER工具经过用户验证后才可以下载安装，在安装过程中该机制避免了系统升级过程中的操作错误，和SAP的盗版等问题的出现，也相应的减少了系统升级的随意性，提高了整体汽车ERP软件的稳定性和可靠性。

　　4.2 运维机制的保证

　　为了保证业务的连续性，运维的监控日志也是非常关键的一环。目前HELPDESK每天二次会巡检SAP系统所有检查点，每一项检查都是应用系统平滑运行的基础保证，HELPDESK 检查项目点会随系统的不断发展而持续补充修改，逐渐形成系统稳定运行的保护伞，并在IT的组织管理下，具有自我补充，自我完善检查点的功能。IT每天会有运维例会，处理每天所有发生的问题，并有跟踪人员对问题进行跟踪，而且会落实到相关的IT技术人员，对问题进行的分析，并找出问题根源，并试图从技术和管理等多方面着手彻底解决问题，下面我们会举例说明HELPDESK人员进行的主要的检查项目来说明。对SAP系统来说其中尤为关键的有四点 1)CPU和内存的使用状况，以确保操作系统使用。2)操作系统的目录使用率百分比，该检查是为避免系统因为误操作而产生了大量的数据，这会将目录占满，影响数据的处理能力。3)每天的系统数据库的备份状况，确保信息系统数据不会丢失。4)JOB的运行状况，确保系统业务数据的准确性，系统间数据传输的QUEUE的状况，也同样保证了SAP系统稳定的主数据信息和其他系统之间的良好传输能力。

　　5、新SAP系统上线后规范的文档和审计

　　5.1 SAP规范安全，监控设置文档，OA操作文档，安装文档等的形成

　　在汽车ERP系统上线前SAP的基础部门会对系统进行相关的参数设置，其内容包括，OS级别的用户权限设置，SAP 运行设置参数的设置，安全监控能力的设置，SAP用户权限管理的设置等等。这些基础的设置是在不断SAP系统实施经验中总结得到，并不断的进行完善补充的，在系统安装前已经形成规范的文档，提交给安装人员，以此规避安装过程中的不一致性，提供统一的安装规范，在此我们可以举例说明，在运维过程中我们有发现一次某销售店不能从系统调到新车，发现SAP在处理DOL发来的整车信息数据运行不正常，经过检查系统，发现系统服务器时钟由于参照源时钟变化，发生了时间向后跳转的现象，经过研究，修改了该时钟调整的机制，采取渐进式时间调整。在以后的操作系统的安装文档中统一修正了该漏洞，并修改了安装文档，杜绝漏洞再次出现。

　　汽车ERP系统上线前技术支持人员还会搜集日常运维将会遇到的问题，以及预设计解决问题的预置方案，这些文档在上线前就已经形成了，确保系统一旦上线发生问题了有应急的处理方法。系统在上线之前还必须经过操作系统的切换测试。并能提供全程安装的技术文档，以及测试文档，以备系统以后归档查看。

　　5.2 SAP系统上线后的审计

　　每次系统上线后会有安全审计的检查，一般会对操作系统，数据库，应用用户的权限进行检查，对目前应用的用户，账号管理小组会检查有没有不适当的权限赋予特别是上汽财务数据，有外部审计和账号小组，技术人员确认权限后才可以使用。这些权限检查会提高了SAP系统的安全性，保证机密数据，如我们的整车财务成本数据，相关供应商信息，合同数据等数据不被泄露，对整车厂的安全生产，整车汽车的商业机密有着重要的保护作用。

　　6、SAP的可扩展性

　　6.1 SAP系统的可扩展

　　由于SAP提供了很强的可扩展性这是SAP在设计系统时就已经支持的，它可以通过扩展服务器的方法来扩张硬件的配置，并可以在线扩展系统。安装系统时只需要提供数据库的地址就可以连接到核心数据库系统，安装完成后通过设置服务器组就可以将新的服务器纳入系统，并给连接的用户提供负载均衡的功能，系统管理员也可以通过配置后台JOB的方法来自定义些大负荷的运算运行于新指定的服务器上。实际应用中我们的一些报表，如当月汽车售后备件物料的收发存报表，由于涉及所有售后物料库存情况，运行时间将很长，我们会对这类报表，安排指定的新服务器上运行。当系统有新的服务器加入后，系统会根据当时性能状况，分配新的JOB到新的服务器。

　　6.2 SAP SCM系统的负荷分流

　　SAP系统主要的业务数据都存在于R3系统里，但它的部分功能可以划分到新的SCM汽车供应链ERP系统里，我们的汽车整车BOM的分级打散，MRP汽车物料需求计算，创建发布预测下周的汽车供应商的物料供货计划程序，这些程序都分布在SCM汽车供应链系统内，其中BOM的计算打散等还使用了其他的服务器，该服务器使用了LIVECACHE的技术，将整车订单和物料BOM的计算保留在该服务器的内存中直接计算。该体系结构使得在计算汽车零件供应预测报表时，相关负荷不会只集中在R3的服务器中，而是分布在R3，SCM，LIVECACHE不同的服务器里，达到了分散负荷的能力。

　　SCM汽车供应链系统还提供了临港售后配件仓库的管理的功能，R3系统会将售后配件的采购物料单传输到临港SCM系统里。在新的系统里进行库存管理，完成收货，上架，下架，发货，并传回R3 系统，进行收货财务过帐管理。该功能使汽车售后配件的整体管理过程完全从R3系统中独立出来，在SCM汽车供应链管理系统里运行，减轻了主R3系统的负荷压力。这种配置可以保证系统有新的仓库管理系统时，可以平稳增加新的SCM系统。并使得SCM系统的功能和R3进行无缝的汽车业务融合，即保证了系统的稳定，又使得系统的汽车业务能力得到了扩展。

【高可用的SAP系统架构的实现】相关文章：

基于安卓系统的移动办公系统架构设计06-21