阿里云上到底能运行SAP哪些产品?

本文主要内容大部分来源于SAP已经发布的note:

2552731 - SAP Applications on Alibaba Cloud: Supported Products and IaaS VM Types。

到2018/01/19为止这个note只有英文版(另一个日文版是机器翻译的)。将来原始的note可能会被SAP负责这个note的同事继续更新,届时本文内容可能会同原始的note有所差异。

您可以通过点击文末的“阅读原文”来查看原始英文版的note。



阿里云上提供的基础设施服务(Infrastructure Service)可以用于部署SAP产品。当然并不是所有的SAP产品都能运行在阿里云上。下面列出各个维度的限制条件。

支持的操作系统:

SUSE Linux Enterprise Server 12 SP2 (SLES12)或更高版本。

Linux平台上支持的关系型数据库管理系统: SAP HANA

具体的硬件要求在这个链接里有描述:

https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/iaas.html#categories=Alibaba%20Cloud%20Computing%20Limited

或参考这张图:

阿里云支持的SAP产品线

1. 运行在ABAP应用服务器(Netweaver 7.0X)上的应用。

对SAP Kernel的要求:

(1) SAP Kernel 7.21 EXT (Patch Level 至少 #919)

(2) SAP Kernel 7.22 EXT (Patch Level 至少 #415)

(3) 或者比上述版本号更高

Jerry 注:

我们知道ABAP语言底层是基于C/C++实现的,包括其关键字(比如最简单的关键字WRITE的C++实现有2千多行)和虚拟机(ABAP Runtime)。SAP内部的一群计算机科学家们发明了ABAP这门伟大的语言,由它实现的各种SAP应用帮助了全球超过180个国家和地区的客户们更好地运行其业务。

通过Google我们能搜索到一些关于这些SAP计算机科学家们的介绍,比如这个链接:

http://sapexperts.wispubs.com/SAP-Professional-Journal/Articles/From-XML-to-ABAP-Data-Structures-and-Back-Bridging-the-Gap-with-XSLT?id=2CA6B036062F42C5B7A76A772A934911#.WmGiiaiWbdM

再回到这个note, EXT意为Extended Kernel, 区别于标准(Standard)Kernel。

Standard Kernel和EXT Kernel最大的区别不在于这些C/C++实现的源代码, 而在于生成SAP Kernel的Make服务器的操作系统版本以及C/C++编译器的版本有所区别。

如果您对这个话题感兴趣,可以阅读SAP Community上这个讨论:

what is the difference between normal Kernel 7.20 and the Kernel 7.20 EXT

https://archive.sap.com/discussions/thread/2114704

2. 运行在ABAP/Java应用服务器(Netweaver 7.1及更高版本)上的应用。

对SAP Kernel的要求:

(1) SAP Kernel 7.21 EXT (Patch Level 至少 #919)

(2) SAP Kernel 7.22 EXT (Patch Level 至少 #415)

(3) 或者比上述版本号更高

3. 运行在ABAP/Java应用服务器(Netweaver 7.4及更高版本)上的应用。

对SAP Kernel的要求:

(1) SAP Kernel 7.45 (Patch Level 至少 #612)

(2) SAP Kernel 7.49 (Patch Level 至少 #316)

(3) SAP Kernel 7.53 (Patch Level 至少 #24)

(4) 或者比上述版本号更高

Linux上支持运行SAP产品的阿里云虚拟机种类

Jerry注1:

表格里第三列SAPS列出了一系列数字。什么是SAPS? SAP Application Performance Standard(SAPS)是一种性能评测标准,描述了SAP产品在某种特定的系统配置下的性能表现。

SAP最先在SD(Sales and Distribution)的性能评测中引入SAPS的概念。在SD的SAPS测试里,100 SAPS意味着2000个订单行项目能够在1小时之内,跑完一个典型的业务流程,包括:

  • 创建订单
  • 为该订单创建Delivery Note
  • 显示订单
  • 修改Delivery日期
  • Post goods issue
  • 创建发票

更多SAPS细节,请阅读SAP官方帮助:

1. SAP Standard Application Benchmarks

https://www.sap.com/about/benchmark.html

2. SAP SD Standard Application Benchmark Results

Jerry注2:

注1里能看到SD的SAPS测试是对于2 tier和3tier两种架构分开进行的。2 tier意即数据库服务器和运行SAP产品的应用服务器是部署在一台物理服务器上,可以统一看成服务层。另外一层即客户端层(展现层), 这样就构成了所谓的2 tier(两层架构)。

显然,如果将数据库服务器和应用服务器分开部署,也就形成了三层架构。在阿里云上进行的SAPS评测是基于两层架构进行的。

如果您对具体部署细节感兴趣,建议阅读阿里官方文档:SAP HANA 部署指南

https://help.aliyun.com/document_detail/57229.html?spm=5176.11065259.1996646101.searchclickresult.5af381adNWUGu1

要获取更多Jerry的原创技术文章,请关注公众号"汪子熙"或者扫描下面二维码:

原文地址:https://www.cnblogs.com/sap-jerry/p/8319056.html

时间: 2024-10-03 22:11:39

阿里云上到底能运行SAP哪些产品?的相关文章

阿里云上数据统一备份 – 混合云备份服务解析

近年来,随着越来越多的企业从传统经济向数字经济转型,云已经渐渐成为数据经济IT新常态.核心业务系统上云,云上的业务创新,这些都产生了大量的业务数据,这些数据也成为了企业最重要的资产.资源. 任何数据损失都可能对业务带来严重影响,但是勒索病毒,黑客攻击,人为误操作,运维失误,乃至机房灾难的威胁随时可能带来数据损失.备份是数据保护的核心手段,更是等级保护,行业合规的硬性要求. 阿里云混合云备份服务(Hybrid Backup Recovery, 简称HBR)是一种简单易用且高性价比的云备份服务,可以

云计算之路-阿里云上-容器难容:自建docker swarm集群遭遇无法解决的问题

我们从今年6月开始在生产环境进行 docker 容器化部署,将已经迁移至 ASP.NET Core 的站点部署到 docker swarm 集群上.开始我们选用的阿里云容器服务,但是在使用过程中我们遭遇了恐怖的路由服务(acsrouting)路由错乱问题 —— 请求被随机路由到集群中的任一容器,虽然后来阿里云修复了这个问题,但我们对容器服务失去了信心,走上了用阿里云服务器自建 docker swarm 集群的道路. 用上自建 docker swarm 集群之后,本以为可以在云上容器中过上安稳的日

云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲

昨天对"黑色n秒"问题的最终猜想以失败而告终,从而让我们结束了被动猜想阶段,进入了主动进攻阶段--出招. 今天出第一招--用C#写个小程序,让其在每个CPU核上运行一个线程,不让任何一个CPU核进入空闲(idle)状态,以进一步排除CPU idle引起的"黑色n秒". 在这一招中,借助的最重要的武器是System.Diagnostics.ProcessThread.ProcessorAffinity.通过给ProcessorAffinity设置一个掩码,就可以指定当

云计算之路-阿里云上:消灭“黑色n秒”第二招——给w3wp进程指定CPU核

虽然昨天的第一招失败了,但是从失败中我们学到了与多核CPU相关的Processor Affinity(处理器关联)的知识. 既然我们可以让.NET程序的不同线程运行于指定的CPU核,那是不是也可以让IIS应用程序池的进程w3wp运行于指定的CPU核? 虽然看起来"黑色n秒"似乎与w3wp运行于哪些CPU核没有什么关系,但是我们既然把怀疑对象锁定在CPU,那么任何与CPU相关的线索都不能放过.即使失败,也会满载而归,因为如果没有"黑色n秒"这个问题的驱动,我们根本不会

云计算之路-阿里云上:“黑色1秒”问题与2009年Xen一个补丁的故事

在之前对"黑色1秒"问题的分析博文中,我们将最大嫌疑对象锁定在了Xen,在这篇博文我们将从Xen的角度进行分析.也许有人会问,为什么不知道天多高地多厚地去研究不属于自己范围的问题?只因我们对一个问题的强烈好奇心--究竟是不是我们用Windows的错? 2009年3月20日,来自Intel的Yu Ke通过Xen-dev Mailing List给来自Citrix的Keir Fraser(负责的Xen开发者之一)发了一封邮件,提交了Xen的一个patch--cpuidle: suspend

云计算之路-阿里云上:读取缓存时的“黑色0.1秒”

看到标题中的"0.1秒",你也许会呲之以鼻:不会吧,0.1秒也要计较,不是吃饱撑着,是没吃饱也撑着. 依然没撑着!在memcached应用场景中,响应速度是处于1ms级别的,0.1s可是比1ms慢了100倍啊. 如果你不相信1ms级别,请看这篇文章(微博CacheService架构浅析)中的一段话: 目前微博平台部分业务子系统的Cache服务已经迁移到了CacheService之上,它在实际的运行过程中也取得了良好的性能表现,目前整个集群在线上每天支撑着超过300W的QPS,平均响应耗

云计算之路-阿里云上:SLB会话保持的一个坑

冒着被大家厌烦的风险,今天再发一篇"云计算之路-阿里云上".这是在前一篇发过之后真实发生的事情,我们觉得定位问题的过程值得分享.而且估计园子里不少朋友被这个问题骚扰过,我们有责任让大家知道问题的真正原因. 快下班之前,园区里另外一家公司的朋友说他们公司有的人不能正常访问园子--会出现HTTP Error 400错误,而其他人可以正常访问.这个问题立即引起了我们的警觉,因为之前也有园友反馈过同样的问题,当时什么也没动,后来就好了,以为是他们公司网络代理服务器的问题.由于我们从未遇到过这个

云计算之路-阿里云上:原来“黑色0.1秒”发生在socket读取数据时

在昨天的博文(云计算之路-阿里云上:读取缓存时的"黑色0.1秒")中我们犯了一个很低级的错误--把13ms算成了130ms(感谢陈硕发现这个错误!),从而对问题的原因作出了错误的推断,望大家谅解! 从中我们吸取到了一个教训:趁热打铁要小心,容易失去冷静,作出错误的判断. 今天我们痛定思痛,用了一个下午的时间重新分析了"黑色0.1秒"问题,这次从EnyimMemcached的源代码下手(https://github.com/enyim/EnyimMemcached).

阿里云上Oracle 11g RAC安装配置手册

有印象的用户可能发现,阿里云早在2016年深圳云栖大会就官方发布了对Oracle RAC的支持,但是相关产品却一直没能同步推出,相信大家都翘首以盼了许久许久.一个好消息是,近期阿里云将紧密推出两款新产品:共享块存储和ECS多网卡.这两款产品将打通众多关键云下应用上云的最后一公里,为用户提供更多的便利.在我们能正式体验到新产品之前,阿里云技术服务团队也将云上的Oracle RAC安装配置手册放出,希望能给大家提供更多不同的体验和选择. 一.安装说明 阿里云上Oracle RAC的安装部署,重点需要