你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 中用于 SAP 的部署选项

适用于 Azure 的云采用框架中的原则有助于在 Azure 中实现 SAP 自动化。 在制定自动化策略和确定方法时，必须确定 SAP 应用程序的关键组件并使用这些观察结果来指导策略。 特别是在企业环境中，部署选项应考虑用于支持 SAP 平台的手动配置、平台自动化和 DevOps 方法。

SAP 应用程序是许多全球企业的关键技术主干，Azure 提供了指导来确保解决方案经过认证、受到支持并成功实现。 组织可以优化 Azure 的敏捷性，以便部署 SAP、自动执行部署活动、配置系统并执行其他复杂任务，从而确保实现运营效率和受控且代码可扩展的基础结构部署。

Microsoft SAP 自动化存储库支持 Azure SAP 客户将脚本与当前的 DevOps 做法集成，或使用处于当前状态且直接来自克隆存储库的代码。

SAP 体系结构

SAP 应用程序资产由系统、工作负载区域和环境组成。

系统

SAP 系统是 SAP 应用程序的一个实例，它具有应用程序运行所需的资源，例如虚拟机 (VM)、磁盘、负载均衡器、邻近放置组、可用性集、子网和网络安全组。 应用程序由 SID（一个唯一的三字母标识符）标识。 出于生命周期目的，每个系统都应部署到单独的 Azure 资源组。

工作负载区域

工作负载区域也称为部署环境。 它将 SAP 应用程序划分为非生产环境或生产环境，并且可以将环境进一步细分为开发、质量保证和生产等层。 部署环境向工作负载区域中的所有系统提供共享资源，例如虚拟网络和密钥保管库。

横向

环境是 SAP 应用程序内不同环境中系统的集合。 该示例图显示了三个 SAP 环境：SAP ERP 中心组件 (ECC)、SAP 客户关系管理 (CRM) 和 SAP 业务仓库 (BW)。

下图说明了 SAP 系统、工作负载区域和环境之间的依赖项。 在下图中，客户有三个环境：SAP ERP 中心组件 (ECC)、SAP 客户关系管理 (CRM) 和 SAP 业务仓库 (BW)。 每个环境都有四个工作负载区域：沙盒、开发、质量保证和生产。 每个工作负载区域可能都包含一个或多个系统。

其他组件

除了 SAP 组件之外，自动化解决方案还需要：

• 可执行部署活动的执行环境
• 安装介质的持久性存储以及 Terraform 是否用于存储 Terraform 状态文件

设计建议：

• 使用与目标虚拟网络具有网络连接的 VM 来启用应用程序配置和安装。
• 使用 Azure 存储帐户管理状态文件并作为 SAP 安装介质的安装源。

准备活动

确定 DevOps 策略

SAP 部署自动化应作为一个工作流来实现，该工作流从部署基础结构开始，然后是配置操作系统和安装应用程序。

设计注意事项：

• 定义所需的自动化范围：

  • 基础结构
  • 配置操作系统
  • 安装应用程序
  • 正在进行的操作（运行状态操作）

• 定义用于存储参数文件的策略

设计建议：

• 将所有参数文件存储在源代码管理存储库中。
• 备份状态和参数文件以防止文件损坏。 例如，可以将 Terraform 状态文件存储在基于读取访问异地冗余存储的热层存储帐户上。

区域规划

SAP 部署自动化框架支持在多个 Azure 区域中进行部署。 每个区域将托管：

• 部署基础结构
• 适用于状态和 SAP 安装介质的 SAP 库
• 1-n 个工作负载区域
• 工作负载区中部署的 1-n 个 SAP 系统

下图显示了两个 Azure 区域的部署策略。

设计注意事项：

• 哪些 Azure 区域在范围内
• 灾难恢复

工作负载区域规划

工作负载区域（也称为部署环境）结合了工作负载虚拟网络、该工作负载中系统的凭据以及用于部署这些系统的服务主体。 工作负载区域是区域性的，因为它们依赖于 Azure 中的虚拟网络。 自动化的命名约定支持在多个 Azure 区域中设置工作负载区域，其中每个区域都有自己的虚拟网络。

下面是一些常见的工作负载区域模式：

生产和非生产

在此模型中，SAP 环境分为生产区域或非生产区域。

沙盒、开发、质量保证、生产

在此模型中，SAP 环境分为沙盒、开发、质量保证或生产区域。

设计注意事项：

• 需要多少个工作负载区域？
• 对于订阅设计，订阅是否包含多个工作负载区域？
• 工作负载部署到哪些区域？
• 出站 Internet 连接
• 与本地网络的网络连接
• 部署是缺少 Azure 工作负载基础结构的绿地部署还是已经存在支持工作负载区域的部分或全部项目的棕地部署？
• 每个工作负载区域是否需要唯一的部署凭据？

设计建议：

• 出站 Internet 连接应由网络团队提供。
• 网络团队应提供与本地网络的网络连接。
• 为每个工作负载区域使用唯一的部署凭据。 如果一个工作负载区域存在于多个区域中，则它应在这些区域中使用相同的部署凭据。
• 若要简化网络规划，请尽量减少工作负载区域的数量。

SAP 应用程序规划

SAP 系统是实际的 SAP 应用程序，因为它包含托管 SAP 应用程序所需的所有 Azure Artifacts。 若要详细了解如何开始、规划和考虑部署因素，请参阅 Azure 上的 SAP。

设计注意事项：

• 要使用哪个后端数据库
• 数据库服务器的数量
• 如果需要高可用性
• 应用程序服务器数量
• Web 调度程序的数量（如果有）
• 中心服务实例数
• VM 大小
• 决定是使用 Azure 市场还是自定义生成映像。 自定义生成映像有几个好处，例如特定于客户的操作系统配置、安全强化和合规性工具。 自定义生成映像还有助于简化映像生命周期。
• 部署是缺少 Azure 工作负载基础结构的绿地部署还是已经存在支持工作负载区域的部分或全部项目的棕地部署？
• IP 分配策略（由 Azure 或客户提供）
• 命名 Azure 资源
• 定义用于管理凭据的要求：工作负载区域的系统是否可以使用相同的凭据来访问 VM？

设计建议：

• 使用标准的 SAP 自动化网络命名约定。

• 对部署到工作负载区域的每个系统使用相同的凭据。 使用 Azure Key Vault 管理和存储密钥。

SAP 部署自动化框架

SAP 部署自动化框架提供可用于构建和配置环境的 Terraform 模板和 Ansible playbook，以在 Azure 中运行 SAP。 这些项目托管在 Azure sap-hana 存储库中，Azure 支持 Azure 中 SAP 的开放源代码部署脚本（代码未自定义）。

自动化功能

受支持的平台

Azure 支持在 Linux 和 Windows 中自动执行 SAP 部署。

支持的拓扑

用于自动执行 SAP 部署的默认模型是具有数据库层和应用层的分布式模型。 应用层细分为三个层：应用程序服务器、中心服务服务器和 Web 调度程序。 自动化还可以部署到未配置应用层的独立服务器。

包含的功能

SAP 部署自动化框架功能对照表：

功能	已含	说明
加速网络	Y	在 VM 上启用了加速网络。
应用程序安全组	N	这些都在路线图上。
定位点 VM	Y	将邻近置放群组定位在可用性区域中的虚拟机。
应用程序配置	N	基于 Ansible 的配置；此功能即将发布。
应用程序安装	N	基于 Ansible 的安装；此功能即将发布。
身份验证	Y	身份验证支持基于 SSH 和基于用户名/密码进行身份验证。
可用性区域	Y	自动化可以在区域中或跨可用性区域部署 VM。
用于网络文件系统的 Azure 文件存储	N	这些都在路线图上。
Azure 防火墙	Y	自动化可以在部署者网络中部署 Azure 防火墙。
Azure 负载均衡器	Y	自动化使用来自 Azure 负载均衡器的标准负载均衡器。
Azure NetApp 文件	N	这些都在路线图上。
启动诊断存储帐户	Y	启动诊断存储帐户在工作负载区域中的所有系统之间共享。
Azure Key Vault	Y	Azure 中新的或当前的密钥保管库。
客户映像	Y	需要将这些自定义映像复制到该区域。
客户管理的磁盘加密密钥	Y	需要提创建这些密钥并将其存储在 Azure Key Vault 中。
部署环境	Y	这是与 SAP 网络对等互连的网络中的 VM。
磁盘大小调整	Y	将指定默认磁盘大小且可对其进行配置。
IP 寻址	Y	IP 地址由客户和 Azure 提供。
命名约定	Y	这是默认的命名约定；可对其进行自定义。
网络安全组	Y	这些是新的或当前的网络安全组。
操作系统配置	N	这是一个基于 Ansible 的配置；此功能即将发布。
邻近放置组	Y	这些是新的或当前的邻近放置组。
资源组	Y	这些是新的或当前的资源组。
子网	Y	这些是新的或当前的子网。
用于 SAP 安装介质的存储	Y	这是一个新的或当前的存储帐户。
Terraform 状态存储	Y	这是一个新的或当前的存储帐户。
VM SKU	Y	所有 VM SKU 都是可配置的。
虚拟网络	Y	这是一个新的或当前的虚拟网络。
见证存储帐户	Y	见证存储帐户在工作负载区域中跨所有系统进行共享，可用于 Windows 高可用性方案。

规划参数文件

SAP 部署自动化针对不同的项目使用 JSON 参数文件为 Azure 环境配置不同的参数文件。 开发环境应将 SAP HANA 和客户存储库克隆到同一根文件夹。 通过定义文件夹结构并将参数文件保存在专用文件夹中，可简化自动部署操作。

设计建议：

所有参数文件都应存储在源代码管理环境中。