探索试验阶段

  • 20 分钟

试点可以与项目规划和准备并行进行。 此阶段还可用于测试规划和准备阶段确定的选项。 在试点阶段，建议设置和验证完整的 HA/DR 解决方案以及安全设计。 在某些情况下，也可使用此阶段执行可伸缩性测试或部署 SAP 沙盒系统。 要进行试点，客户应首先确定要迁移到 Azure 的非关键系统，然后继续执行以下任务：

1. 优化 Azure 中的数据传输

方法和结果在很大程度上取决于客户与 Azure 的连接。 根据数据量，可能会因此使用 ExpressRoute、站点到站点 VPN 或脱机数据传输服务，例如 Azure Data Box 或 Azure 导入/导出服务。

2. SAP 异类平台迁移

对于涉及数据库数据导出和导入的 SAP 异类平台迁移，请测试和优化导出和导入阶段。 对于针对 SQL Server 的大型异类迁移，请参阅 SAP OS/DB 迁移到 SQL Server – FAQ。 如果不需要在迁移的同时进行版本升级，则可以使用迁移监视器/SWPM，否则请使用 SAP 数据库迁移选项 (DMO)。 有关详细信息，请参阅 SUM 数据库迁移选项 (DMO) - 简介。 无论何种情况，都需要执行以下步骤：

  • 测量从源导出内容、将导出的内容上传到 Azure 并执行导入的时间。 使导出和导入之间的重叠最大化。
  • 通过比较源数据库和目标数据库来适当调整目标基础结构的大小。
  • 验证并优化时间安排。

3. 执行技术验证

虚拟机类型

  • 参考 SAP 支持说明、SAP HANA 硬件目录和 SAP 产品可用性对照表 (PAM)，以确保与支持的 Azure 虚拟机 SKU、这些 Azure 虚拟机 SKU 支持的 OS 版本以及支持的 SAP 和 DBMS 版本相关的信息的准确性。
  • 验证在 Azure 中部署的基础结构和应用程序组件的大小调整。 迁移现有应用程序时，应能够基于现有遥测获取必要的 SAP。 检索 SAP 基准，并将其与 SAP 说明 #1928533 中列出的 SAPS 编号进行比较。 此外，请参阅 Azure 虚拟机上的 SAP 评级 - 在何处查看以及容易混淆的方面中提供的信息。
  • 评估和测试 Azure 虚拟机的大小，了解在规划阶段选择的不同虚拟机类型的最大存储吞吐量和网络吞吐量。 可以在 Azure 中的虚拟机大小中找到此数据。 如果 Azure 虚拟机来宾操作系统是 Windows，务必要考虑用于调整大小的最大非缓存磁盘吞吐量。 对于 Linux，还必须考虑用于调整大小的最大非缓存磁盘吞吐量。

存储

  • 对于表示 SAP 应用程序层的虚拟机和非性能敏感型 DBMS 部署，请至少使用 Azure 标准 SSD 存储；对于性能敏感型 DBMS 虚拟机，请至少使用 Azure 高级存储。
  • 请避免使用 Azure 标准 HDD 磁盘。
  • 使用 Azure 托管磁盘。
  • 为 M 系列 Azure 虚拟机中的 DBMS 日志驱动器启用 Azure 写入加速器。 请注意记录的写入加速器限制和使用限制。
  • 有关 DBMS 相关的存储信息，请参阅针对 SAP 工作负载的 Azure 虚拟机 DBMS 部署的注意事项，以及该文档中提到的 DBMS 特定文档。
  • 有关 SAP HANA 部署，请参阅 Azure SAP HANA 基础结构配置和操作。
  • 请勿使用设备 ID 将 Azure 数据磁盘装载到 Azure Linux 虚拟机中。 而应该使用全局唯一标识符 (UUID)。 使用图形工具装载 Azure 数据磁盘时请小心。 反复检查 /etc/fstab 中的条目，确保使用 UUID 装载磁盘。 有关详细信息，请参阅连接 Linux 虚拟机来装载新磁盘。

网络

跨 Azure 虚拟网络或在 Azure 虚拟网络中测试和评估虚拟网络基础结构以及 SAP 应用程序的分布情况。

  1. 根据以下标准评估单个 Azure 虚拟网络内的中心和分支虚拟网络体系结构或微分段方法：

    • 由于对等互连 Azure 虚拟网络之间的数据交换而产生的成本（有关详细信息，请参阅 Azure 虚拟网络定价）。
    • 在虚拟网络的子网中托管的应用程序或虚拟机构成安全风险的情况下，终止 Azure 虚拟网络之间的对等互连的能力与使用 NSG 隔离虚拟网络中的子网的能力的比较。
    • 本地、Internet 和 Azure 虚拟数据中心的网络流量的集中记录和审核。

  2. 评估并测试 SAP 应用程序层与 SAP DBMS 层之间的数据路径。 在进行评估时，请考虑以下事项：

    • 不支持将网络虚拟设备放置在 SAP 应用程序与基于 SAP NetWeaver、Hybris 或 S/4HANA 的 SAP 系统的 DBMS 层之间的通信路径中。
    • 不支持将 SAP 应用程序层和 SAP DBMS 放置在未对等互连的不同 Azure 虚拟网络中。
    • 支持使用 Azure 应用程序安全组 (ASG) 和网络安全组 (NSG) 来控制 SAP 应用程序层和 SAP DBMS 层之间的流量流。

  3. 确保 SAP 应用程序层和 SAP DBMS 层上使用的虚拟机已启用 Azure 加速网络。 注意支持 Azure 加速网络的 OS 要求：

    • Windows Server 2012 R2 或更高版本
    • SUSE Linux 12 SP3 或更高版本
    • RHEL 7.4 或更高版本
    • Oracle Linux 7.5。 RHCKL 内核需要版本 3.10.0-862.13.1.el7。 Oracle UEK 内核需要版本 5。

  4. 根据 SAP 说明 #500235 和 SAP 说明 #1100926 测试和评估 SAP 应用程序层虚拟机和 DBMS 虚拟机之间的网络延迟。 根据 SAP 说明 #1100926 的网络延迟指导评估结果。 网络延迟应为中等至良好。

  5. 确保将 Azure 内部负载均衡器 (ILB) 部署设置为使用直接服务器返回。 在将 ILB 用于 DBMS 层上的高可用性配置的情况下，此设置可减少延迟。

  6. 如果将 Azure 负载均衡器与 Linux 来宾操作系统结合使用，请检查 Linux 网络参数 net.ipv4.tcp_timestamps 是否设置为 0。 注意，这与 SAP 说明 #2382421 的一般建议相矛盾。 SAP 说明已更新，以反映参数需要设置为 0 以与 Azure 负载均衡器结合使用这一事实。

高可用性和灾难恢复部署

  • 如果部署 SAP 应用程序层而不针对特定的 Azure 可用性区域，请确保运行同一 SAP 系统的 SAP 对话实例或中间件实例的所有虚拟机都部署在同一可用性集中。

    • 如果不需要 SAP 中心服务和 DBMS 的高可用性，则可以将这些虚拟机部署到与 SAP 应用层相同的可用性集中。

  • 如果需要通过被动副本保护 SAP 中心服务和 DBMS 层以实现高可用性，请在其中一个可用性集中为 SAP 中心服务部署两个节点，在另一个可用性集中部署两个 DBMS 节点。

  • 如果部署到 Azure 可用性区域，则无法使用可用性集。 在这种情况下，应确保将主动和被动中心服务节点部署到两个不同的可用性区域中，这两个区域之间的延迟最小。

  • 注意，跨可用性区域为 DBMS 和 SAP 中心服务层创建基于 Windows Server 或 Pacemaker 的故障转移群集时，需要使用 Azure 标准负载均衡器。 基本负载均衡器不支持分区部署。

超时设置

  • 检查 SAP 实例的 SAP NetWeaver 开发人员跟踪，确保排队服务器与 SAP 工作进程之间未发生连接中断。 通过设置以下两个注册表参数可以避免这些连接中断。

    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000。 有关详细信息，请参阅 KeepAliveTime。
    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000。 有关详细信息，请参阅 KeepAliveInterval。

  • 为避免本地 SAP GUI 接口与 Azure 中部署的 SAP 应用程序层之间的 GUI 超时，请在 default.pfl 或实例配置文件中设置以下参数：

    • rdisp/keepalive_timeout = 3600
    • rdisp/keepalive = 20

  • 如果使用 Windows 故障转移群集，请确保正确设置了确定由无响应节点触发的故障转移的参数。 Microsoft TechCommunity 优化故障转移群集网络阈值一文列出了参数及其对故障转移行为的影响。 例如，假设群集节点位于同一子网中，请确保按如下配置故障转移参数：

    • SameSubNetDelay = 2000

    • SameSubNetThreshold = 15

    • RoutingHistorylength = 30

    • 测试高可用性和灾难恢复过程：

      • 通过关闭 Azure 虚拟机（Windows 来宾操作系统）或将操作系统置于紧急模式（Linux 来宾操作系统）来模拟故障转移。

      • 测量完成故障转移所需的时间。 如果时间太长，请考虑：

        • 对于 SUSE Linux，请使用 SBD 设备（而不是 Azure 隔离代理）来加速故障转移。
        • 对于 SAP HANA，如果重新加载数据花费的时间太长，请考虑提高存储性能。

      • 测试备份/还原顺序和时间，并在必要时进行优化。 确保不仅仅是备份时间足够。 此外，测试还原并计时还原活动。 请确保还原时间在 RTO SLA 范围内，其中 RTO 依赖于数据库或虚拟机还原过程。

      • 测试 DR 功能和体系结构。

4. 执行安全检查

  • 测试你实施的 Azure 基于角色的访问 (RBAC) 方法的有效性。 目标是分离并限制委派给不同团队的访问和权限。 例如，SAP 基础团队成员应该能够将 Azure 虚拟机部署到给定的 Azure 虚拟网络中，并将磁盘分配给这些 Azure 虚拟机。 但是，SAP 基础团队应该不能创建新的虚拟网络或更改现有虚拟网络的设置。 反过来，网络团队的成员应该不能将 Azure 虚拟机部署到运行 SAP 应用程序和 DBMS 虚拟机的虚拟网络中。 网络团队的成员也不能更改虚拟机的属性或删除虚拟机及其磁盘。
  • 验证 NSG 规则是否正常工作，并屏蔽受保护的资源。
  • 验证静态和传输中的加密。 定义和实施备份、存储和访问证书的过程，并验证加密实体的还原过程。
  • 对 OS 磁盘使用 Azure 磁盘加密。
  • 在决定是否实施加密机制时，请考虑一种务实的方法。 例如，评估是否有必要应用 Azure 磁盘加密和 DBMS 透明数据库加密。

5. 测试性能

在迁移方案中，使用 SAP 跟踪和测量对试点与当前实施进行以下比较：

  • 前 10 个在线报告
  • 前 10 个批处理作业
  • 通过接口进入 SAP 系统的数据传输，重点是跨界流量