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

在 RHEL 上使用 Azure NetApp 文件实现 SAP HANA 纵向扩展的高可用性

本文介绍通过 NFS 装载 HANA 文件系统时，如何在纵向扩展部署中使用 Azure NetApp 文件配置 SAP HANA 系统复制。 在示例配置和安装命令中，使用实例编号 03 和 HANA 系统 ID HN1。 SAP HANA 系统复制由一个主节点和至少一个辅助节点组成。

如果本文档中的步骤标有以下前缀，则含义如下：

• [A] ：该步骤适用于所有节点
• [1] ：该步骤仅适用于 node1
• [2] ：该步骤仅适用于 node2

先决条件

请先阅读以下 SAP 说明和文档：

• SAP 说明 1928533，其中包含：
  • 支持部署 SAP 软件的 Azure 虚拟机 (VM) 大小的列表。
  • Azure VM 大小的重要容量信息。
  • 支持的 SAP 软件、操作系统 (OS) 和数据库组合。
  • Microsoft Azure 上 Windows 和 Linux 所需的 SAP 内核版本。
• SAP 说明 2015553 列出了在 Azure 中 SAP 支持的 SAP 软件部署的先决条件。
• SAP 说明 405827 列出了适用于 HANA 环境的建议文件系统。
• SAP 说明 2002167 包含适用于 Red Hat Enterprise Linux 的建议 OS 设置。
• SAP 说明 2009879 包含适用于 Red Hat Enterprise Linux 的 SAP HANA 指南。
• SAP 说明 3108302 包含适用于 Red Hat Enterprise Linux 9.x 的 SAP HANA 指南。
• SAP 说明 2178632 包含为 Azure 中的 SAP 报告的所有监控指标的详细信息。
• SAP 说明 2191498 包含 Azure 中的 Linux 所需的 SAP 主机代理版本。
• SAP 说明 2243692 包含 Azure 中的 Linux 上的 SAP 许可的相关信息。
• SAP 说明 1999351 包含适用于 SAP 的 Azure 增强型监视扩展的更多故障排除信息。
• SAP Community Wiki 包含适用于 Linux 的所有必需 SAP 说明。
• 适用于 Linux 上的 SAP 的 Azure 虚拟机规划和实施
• 适用于 Linux 上的 SAP 的 Azure 虚拟机部署
• 适用于 Linux 上的 SAP 的 Azure 虚拟机 DBMS 部署
• Pacemaker 群集中的 SAP HANA 系统复制
• 常规 Red Hat Enterprise Linux (RHEL) 文档：
  • High Availability Add-On Overview（高可用性附加产品概述）
  • High Availability Add-On Administration（高可用性附加产品管理）
  • High Availability Add-On 参考
  • 当 HANA 文件系统位于 NFS 共享上时，在 Pacemaker 群集中配置 SAP HANA 纵向扩展系统复制
• Azure 特定的 RHEL 文档：
  • Support Policies for RHEL High Availability Clusters - Microsoft Azure Virtual Machines as Cluster Members（RHEL 高可用性群集的支持策略 - Microsoft Azure 虚拟机作为群集成员）
  • Installing and Configuring a Red Hat Enterprise Linux 7.4 (and later) High-Availability Cluster on Microsoft Azure（在 Microsoft Azure 上安装和配置 Red Hat Enterprise Linux 7.4 [及更高版本] 高可用性群集）
  • 当 HANA 文件系统位于 NFS 共享上时，在 Pacemaker 群集中配置 SAP HANA 纵向扩展系统复制
• 适用于 SAP HANA 的 Azure NetApp 文件上的 NFS v4.1 卷

概述

传统上，在纵向扩展环境中，SAP HANA 的所有文件系统都从本地存储进行装载。 在 RHEL 上设置 SAP HANA 系统复制指南中发布了如何在 Red Hat Enterprise Linux 上设置 SAP HANA 系统复制的高可用性 (HA) 的说明

若要在 Azure NetApp 文件 NFS 共享上实现纵向扩展系统的 SAP HANA 高可用性，我们需要在群集中进行一些其他资源配置，以便在一个节点失去对 Azure NetApp 文件上的 NFS 共享的访问权限时恢复 HANA 资源。 群集管理 NFS 装载，这使其可以监视资源的运行状况。 文件系统装载和 SAP HANA 资源之间的依赖关系会强制执行。

。

在每个节点上使用 Azure NetApp 文件将 SAP HANA 文件系统装载到 NFS 共享。 文件系统 /hana/data、 /hana/log和 /hana/shared 对每个节点是唯一的。

已在 node1 (hanadb1) 上装载

• /hana/data 上的 10.32.2.4:/hanadb1-data-mnt00001
• /hana/log 上的 10.32.2.4:/hanadb1-log-mnt00001
• /hana/shared 上的 10.32.2.4:/hanadb1-shared-mnt00001

已在 node2 (hanadb2) 上装载

• /hana/data 上的 10.32.2.4:/hanadb2-data-mnt00001
• /hana/log 上的 10.32.2.4:/hanadb2-log-mnt00001
• /hana/shared 上的 10.32.2.4:/hanadb2-shared-mnt00001

注意

/hana/shared、 /hana/data和 /hana/log 不在两个节点之间共享。 每个群集节点都有自己的单独文件系统。

SAP HANA 系统复制配置使用专用的虚拟主机名和虚拟 IP 地址。 在 Azure 上，需要负载均衡器才能使用虚拟 IP 地址。 此处显示的配置有一个负载均衡器，其中：

• 前端 IP 地址：10.32.0.10 (hn1-db)
• 探测端口：62503

设置 Azure NetApp 文件基础结构

在继续设置 Azure NetApp 文件基础结构之前，请先通过 Azure NetApp 文件文档熟悉该基础结构。

Azure NetApp 文件在多个 Azure 区域中可用。 查看所选 Azure 区域是否提供 Azure NetApp 文件。

有关 Azure NetApp 文件在各 Azure 区域的可用性的信息，请参阅按 Azure 区域划分的 Azure NetApp 文件可用性。

重要注意事项

为 SAP HANA 纵向扩展系统创建 Azure NetApp 文件卷时，请注意适用于 SAP HANA 的 Azure NetApp 文件上的 NFS v4.1 卷中记录的重要注意事项。

调整 Azure NetApp 文件上的 HANA 数据库的大小

Azure NetApp 文件卷的吞吐量取决于卷大小和服务级别，如 Azure NetApp 文件的服务级别中所述。

使用 Azure NetApp 文件为 Azure 上的 SAP HANA 设计基础结构时，请注意适用于 SAP HANA 的 Azure NetApp 文件上的 NFS v4.1 卷中的建议。

本文中的配置提供了简单的 Azure NetApp 文件卷。

重要

对于性能是关键的生产系统，建议评估和考虑使用针对 SAP HANA 的 Azure NetApp 文件应用程序卷组。

部署 Azure NetApp 文件资源

以下说明假定你已部署 Azure 虚拟网络。 Azure NetApp 文件资源和 VM（将装载 Azure NetApp 文件资源）必须部署在同一 Azure 虚拟网络或对等 Azure 虚拟网络中。

1. 按照创建 NetApp 帐户中的说明，在所选的 Azure 区域中创建一个 NetApp 帐户。

2. 按照设置 Azure NetApp 文件容量池中的说明，设置 Azure NetApp 文件容量池。

   本文中介绍的 HANA 体系结构使用超高性能服务级别的单个 Azure NetApp 文件容量池。 对于 Azure 上的 HANA 工作负荷，建议使用 Azure NetApp 文件“超高性能”或“高级”服务级别。

3. 按照将子网委派给 Azure NetApp 文件中的说明所述，将子网委派给 Azure NetApp 文件。

4. 按照为 Azure NetApp 文件创建 NFS 卷中的说明部署 Azure NetApp 文件卷。

   部署卷时，请务必选择“NFSv4.1”版本。 将卷部署在指定的 Azure NetApp 文件子网中。 将自动分配 Azure NetApp 卷的 IP 地址。

   请记住，Azure NetApp 文件资源和 Azure VM 必须位于同一 Azure 虚拟网络或对等 Azure 虚拟网络中。 例如，hanadb1-data-mnt00001 和 hanadb1-log-mnt00001 是卷名称，nfs://10.32.2.4/hanadb1-data-mnt00001 和 nfs://10.32.2.4/hanadb1-log-mnt00001 是 Azure NetApp 文件卷的文件路径。

   在 hanadb1 上：

   • 卷 hanadb1-data-mnt00001 (nfs://10.32.2.4:/hanadb1-data-mnt00001)
   • 卷 hanadb1-log-mnt00001 (nfs://10.32.2.4:/hanadb1-log-mnt00001)
   • 卷 hanadb1-shared-mnt00001 (nfs://10.32.2.4:/hanadb1-shared-mnt00001)

   在 hanadb2 上：

   • 卷 hanadb2-data-mnt00001 (nfs://10.32.2.4:/hanadb2-data-mnt00001)
   • 卷 hanadb2-log-mnt00001 (nfs://10.32.2.4:/hanadb2-log-mnt00001)
   • 卷 hanadb2-shared-mnt00001 (nfs://10.32.2.4:/hanadb2-shared-mnt00001)

注意

本文中用于装载 /hana/shared 的所有命令均为 NFSv4.1 /hana/shared 卷展示。 如果将 /hana/shared 卷作为 NFSv3 卷部署，请不要忘记为 NFSv3 调整 /hana/shared 的装载命令。

准备基础结构

Azure 市场包含具有高可用性加载项的 SAP HANA 限定的映像，这些映像可用于使用各种版本的 Red Hat 部署新 VM。

通过 Azure 门户手动部署 Linux VM

本文档假定你已部署资源组、Azure 虚拟网络和子网。

部署用于 SAP HANA 的 VM。 选择 HANA 系统支持的合适的 RHEL 映像。 可以通过任何一个可用性选项（虚拟机规模集、可用性区域或可用性集）来部署 VM。

重要

请确保你选择的 OS 已通过 SAP 针对你计划在部署中使用的特定 VM 类型上的 SAP HANA 的认证。 可以在 SAP HANA 认证的 IaaS 平台中查找 SAP HANA 认证的 VM 类型及其 OS 版本。 请确保查看 VM 类型的详细信息，以获取适用于特定 VM 类型的 SAP HANA 支持的 OS 版本的完整列表。

配置 Azure 负载均衡器

在配置 VM 期间，你可以在网络部分中创建或选择现有的负载均衡器。 按照以下步骤设置标准负载均衡器以完成 HANA 数据库的高可用性设置。

Azure 门户

按照创建负载均衡器中的步骤，使用 Azure 门户为高可用性 SAP 系统设置标准负载均衡器。 在设置负载均衡器期间，请注意以下几点：

1. 前端 IP 配置： 创建前端 IP。 选择与数据库虚拟机相同的虚拟网络和子网名称。
2. 后端池： 创建后端池并添加数据库 VM。
3. 入站规则：创建负载均衡规则。 对两个负载均衡规则执行相同步骤。
   • 前端 IP 地址：选择前端 IP。
   • 后端池：选择后端池。
   • 高可用性端口：选择此选项。
   • 协议：选择“TCP”。
   • 运行状况探测：创建具有以下详细信息的运行状况探测：
     • 协议：选择“TCP”。
     • 端口：例如，625<instance-no.>。
     • 间隔时间：输入 5。
     • 探测阈值：输入 2。
   • 空闲超时（分钟）：输入 30。
   • 启用浮动 IP：选择此选项。

注意

不会遵循运行状况探测配置属性 numberOfProbes（在门户中也称为“运行不正常阈值”）。 要控制成功或失败的连续探测数量，请将属性 probeThreshold 设置为 2。 当前无法使用 Azure 门户设置此属性，因此请使用 Azure CLI 或 PowerShell 命令。

Azure CLI

# Create the load balancer resource with frontend IP. Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address.
az network lb create -g MyResourceGroup -n MyLB --sku Standard --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet --backend-pool-name MyBackendPool --frontend-ip-name MyDBFrontendIpName

# Create the health probe
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyDBHealthProbe --protocol tcp --port MyDBHealthProbePort --interval 5 --probe-threshold 2
 
# Create load balancing rule
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyDBRuleName --protocol All --frontend-ip-name MyDBFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyDBHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip 

# Add database VMs in backend pool
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm1IpConfigName --nic-name DBVm1NicName -g MyResourceGroup --lb-name MyLB
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm2IpConfigName --nic-name DBVm2NicName -g MyResourceGroup --lb-name MyLB

展开可查看完整的 CLI 代码

# Define variables for Resource Group, and Database VMs.

rg_name="resourcegroup-name"
vm1_name="db1-name"
vm2_name="db2-name"

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

lb_name="sap-db-sid-ilb"
bkp_name="db-backendpool"
db_fip_name="db-frontendip"

db_hp_name="db-healthprobe"
db_hp_port="625<instance-no>"

db_rule_name="db-lb-rule"
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name. 
 
vm1_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm1_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm1_nic_name=$(basename $vm1_primary_nic)
vm1_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm1_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vm2_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm2_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm2_nic_name=$(basename $vm2_primary_nic)
vm2_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm2_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vnet_subnet_id=$(az network nic show -g $rg_name -n $vm1_nic_name --query ipConfigurations[0].subnet.id -o tsv)
vnet_name=$(basename $(dirname $(dirname $vnet_subnet_id)))
subnet_name=$(basename $vnet_subnet_id)
 
# Create the load balancer resource with frontend IP.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address. 
  
az network lb create -g $rg_name -n $lb_name --sku Standard --vnet-name $vnet_name --subnet $subnet_name --backend-pool-name $bkp_name --frontend-ip-name $db_fip_name
 
# Create the health probe
 
az network lb probe create -g $rg_name --lb-name $lb_name -n $db_hp_name --protocol tcp --port $db_hp_port --interval 5 --probe-threshold 2
 
# Create load balancing rule
  
az network lb rule create -g $rg_name --lb-name $lb_name -n  $db_rule_name --protocol All --frontend-ip-name $db_fip_name --frontend-port 0 --backend-pool-name $bkp_name --backend-port 0 --probe-name $db_hp_name --idle-timeout-in-minutes 30 --enable-floating-ip 
 
# Add database VMs in backend pool
 
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm1_ipconfig --nic-name $vm1_nic_name -g $rg_name --lb-name $lb_name
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm2_ipconfig --nic-name $vm2_nic_name -g $rg_name --lb-name $lb_name

# [OPTIONAL] Change the assignment of frontend IP address from dynamic to static
dbfip=$(az network lb frontend-ip show --lb-name $lb_name -g $rg_name -n $db_fip_name --query "{privateIPAddress:privateIPAddress}" -o tsv)
az network lb frontend-ip update --lb-name $lb_name -g $rg_name -n $db_fip_name --private-ip-address $dbfip

PowerShell

# Create frontend IP configurations
$db_fip = New-AzLoadBalancerFrontendIpConfig -Name MyDBFrontendIpName -SubnetId MyDBSubnetName

# Create backend pool
$bePool = New-AzLoadBalancerBackendAddressPoolConfig -Name MyBackendPool

# Create health probe
$db_healthprobe = New-AzLoadBalancerProbeConfig -Name MyDBHealthProbe -Protocol 'tcp' -Port MyDBHealthProbePort -IntervalInSeconds 5 -ProbeThreshold 2 -ProbeCount 1

# Create load balancing rule
$db_rule = New-AzLoadBalancerRuleConfig -Name MyDBRuleName -Probe $db_healthprobe -Protocol 'All' -IdleTimeoutInMinutes 30 -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -EnableFloatingIP

# Create the load balancer resource
$lb = New-AzLoadBalancer -ResourceGroupName MyResourceGroup -Name MyLB -Location MyRegion -Sku 'Standard' -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -LoadBalancingRule $db_rule -Probe $db_healthprobe

展开可查看完整的 PowerShell 代码

# Define variables for Resource Group, and Database VMs.

$rg_name = 'resourcegroup-name'
$vm1_name = 'db1-name'
$vm2_name = 'db2-name'

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

$lb_name = 'sap-db-sid-ilb'
$bkp_name = 'db-backendpool'
$db_fip_name = 'db-frontendip'
 
$db_hp_name = 'db-healthprobe'
$db_hp_port = '625<instance-no>'
 
$db_rule_name = 'db-lb-rule'
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name.
 
$vm1 = Get-AzVM -ResourceGroupName $rg_name -Name $vm1_name
$vm1_primarynic = $vm1.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm1_nic_name = $vm1_primarynic.Id.Split('/')[-1]
 
$vm1_nic_info = Get-AzNetworkInterface -Name $vm1_nic_name -ResourceGroupName $rg_name
$vm1_primaryip = $vm1_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm1_ipconfig_name = ($vm1_primaryip).Name
 
$vm2 = Get-AzVM -ResourceGroupName $rg_name -Name $vm2_name
$vm2_primarynic = $vm2.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm2_nic_name = $vm2_primarynic.Id.Split('/')[-1]
 
$vm2_nic_info = Get-AzNetworkInterface -Name $vm2_nic_name -ResourceGroupName $rg_name
$vm2_primaryip = $vm2_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm2_ipconfig_name = ($vm2_primaryip).Name
 
$vnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-3]
$subnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-1]
$location = $vm1.Location
 
# Create frontend IP resource.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter -PrivateIpAddress
 
$db_lb_fip = @{
    Name = $db_fip_name
    SubnetId = $vm1_primaryip.Subnet.Id
}
$db_fip = New-AzLoadBalancerFrontendIpConfig @db_lb_fip

# Create backend pool
 
$bepool = New-AzLoadBalancerBackendAddressPoolConfig -Name $bkp_name

# Create the health probe
 
$db_probe = @{
    Name = $db_hp_name
    Protocol = 'tcp'
    Port = $db_hp_port
    IntervalInSeconds = '5'
    ProbeThreshold = '2'
    ProbeCount = '1'
}
$db_healthprobe = New-AzLoadBalancerProbeConfig @db_probe
    
# Create load balancing rule
 
$db_lbrule = @{
    Name = $db_rule_name
    Probe = $db_healthprobe
    Protocol = 'All'
    IdleTimeoutInMinutes = '30'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool 
} 
$db_rule = New-AzLoadBalancerRuleConfig @db_lbrule -EnableFloatingIP 
 
# Create the load balancer resource
 
$loadbalancer = @{
    ResourceGroupName = $rg_name
    Name = $lb_name
    Location = $location
    Sku = 'Standard'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool
    LoadBalancingRule = $db_rule
    Probe = $db_healthprobe
} 
$lb = New-AzLoadBalancer @loadbalancer

# Add DB VMs in backend pool
 
$vm1_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm2_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm1_nic_info | Set-AzNetworkInterface
$vm2_nic_info | Set-AzNetworkInterface

有关 SAP HANA 所需端口的详细信息，请参阅 SAP HANA 租户数据库指南中的连接到租户数据库一章或 SAP 说明 2388694。

重要

负载均衡方案中的 NIC 辅助 IP 配置不支持浮动 IP。 有关详细信息，请参阅 Azure 负载均衡器限制。 如果你需要为 VM 提供另一个 IP 地址，请部署第二个 NIC。

注意

如果没有公共 IP 地址的 VM 放在标准 Azure 负载均衡器的内部（无公共 IP 地址）实例的后端池中，除非执行更多的配置以允许路由到公共终结点，否则就没有出站 Internet 连接。 有关如何实现出站连接的详细信息，请参阅 SAP 高可用性方案中使用标准 Azure 负载均衡器的虚拟机的公共终结点连接。

重要

请勿在放置于 Azure 负载均衡器之后的 Azure VM 上启用 TCP 时间戳。 启用 TCP 时间戳会导致运行状况探测失败。 将参数 net.ipv4.tcp_timestamps 设置为 0。 有关详细信息，请参阅负载均衡器运行状况探测和 SAP 说明 2382421。

装载 Azure NetApp 文件卷

1. [A] 为 HANA 数据库卷创建装入点。

   sudo mkdir -p /hana/data
   sudo mkdir -p /hana/log
   sudo mkdir -p /hana/shared
   

2. [A] 验证 NFS 域设置。 请确保域配置为默认的 Azure NetApp 文件域（即 defaultv4iddomain.com），并且映射设置为 nobody。

   sudo cat /etc/idmapd.conf
   

   示例输出：

   [General]
   Domain = defaultv4iddomain.com
   [Mapping]
   Nobody-User = nobody
   Nobody-Group = nobody
   

   重要

   确保在 VM 上的 /etc/idmapd.conf 中设置 NFS 域，以匹配 Azure NetApp 文件上的默认域配置 defaultv4iddomain.com。 如果 NFS 客户端（即 VM）上的域配置和 NFS 服务器（即 Azure NetApp 配置）之间不匹配，则 VM 上已装载的 Azure NetApp 卷上文件的权限将显示为 nobody。

3. [1] 在 node1 (hanadb1) 上装载特定于节点的卷。

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-log-mnt00001 /hana/log
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-data-mnt00001 /hana/data
   

4. [2] 在 node2 (hanadb2) 上装载特定于节点的卷。

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-shared-mnt00001 /hana/shared
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-log-mnt00001 /hana/log
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-data-mnt00001 /hana/data
   

5. [A] 验证是否使用 NFS 协议版本 NFSv4 装载了所有 HANA 卷。

   sudo nfsstat -m
   

   验证 vers 标志是否设置为 4.1。 来自 hanadb1 的示例：

   /hana/log from 10.32.2.4:/hanadb1-log-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
   /hana/data from 10.32.2.4:/hanadb1-data-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
   /hana/shared from 10.32.2.4:/hanadb1-shared-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
   

6. [A] 验证 nfs4_disable_idmapping。 它应设置为“Y”。若要创建 nfs4_disable_idmapping 所在的目录结构，请运行装载命令。 无法在 /sys/modules 下手动创建目录，因为访问权限是为内核和驱动程序保留的。

   请检查 nfs4_disable_idmapping。

   sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping
   

   如果需要将 nfs4_disable_idmapping 设置为：

   sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
   

   将配置设为永久。

   sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
   

   ​有关如何更改 nfs_disable_idmapping 参数的详细信息，请参阅 Red Hat 知识库。

SAP HANA 安装

1. [A] 为所有主机设置主机名解析。

   可以使用 DNS 服务器，或修改所有节点上的 /etc/hosts 文件。 此示例演示如何使用 /etc/hosts 文件。 请替换以下命令中的 IP 地址和主机名：

   sudo vi /etc/hosts
   

   将以下代码行插入到 /etc/hosts 文件中。 根据环境更改 IP 地址和主机名。

   10.32.0.4   hanadb1
   10.32.0.5   hanadb2
   

2. [A] 准备 OS 以在具有 NFS 的 Azure NetApp 上运行 SAP HANA，如 SAP 说明 3024346 - 适用于 NetApp NFS 的 Linux 内核设置中所述。 为 NetApp 配置设置创建配置文件 /etc/sysctl.d/91-NetApp-HANA.conf。

   sudo vi /etc/sysctl.d/91-NetApp-HANA.conf
   

   在配置文件中添加以下条目。

   net.core.rmem_max = 16777216
   net.core.wmem_max = 16777216
   net.ipv4.tcp_rmem = 4096 131072 16777216
   net.ipv4.tcp_wmem = 4096 16384 16777216
   net.core.netdev_max_backlog = 300000 
   net.ipv4.tcp_slow_start_after_idle=0 
   net.ipv4.tcp_no_metrics_save = 1
   net.ipv4.tcp_moderate_rcvbuf = 1
   net.ipv4.tcp_window_scaling = 1    
   net.ipv4.tcp_sack = 1
   

3. [A] 使用更多优化设置创建配置文件 /etc/sysctl.d/ms-az.conf。

   sudo vi /etc/sysctl.d/ms-az.conf
   

   在配置文件中添加以下条目。

   net.ipv6.conf.all.disable_ipv6 = 1
   net.ipv4.tcp_max_syn_backlog = 16348
   net.ipv4.conf.all.rp_filter = 0
   sunrpc.tcp_slot_table_entries = 128
   vm.swappiness=10
   

   提示

   避免在 sysctl 配置文件中显式设置 net.ipv4.ip_local_port_range 和 net.ipv4.ip_local_reserved_ports，以允许 SAP 主机代理管理端口范围。 有关详细信息，请参阅 SAP 说明 2382421。

4. [A] 根据 SAP 说明 3024346 - NetApp NFS 的 Linux 内核设置，调整 sunrpc 设置。

   sudo vi /etc/modprobe.d/sunrpc.conf
   

   插入以下行：

   options sunrpc tcp_max_slot_table_entries=128
   

5. [A] 为 HANA 执行 RHEL OS 配置。

   根据 RHEL 版本，按照以下 SAP 注释中的描述配置操作系统：

   • 2292690 - SAP HANA DB: Recommended OS settings for RHEL 7（2292690 - SAP HANA DB：RHEL 7 的建议 OS 设置）
   • 2777782 - SAP HANA DB：建议用于 RHEL 8 的操作系统设置
   • 2455582 - Linux：运行使用 GCC 6.x 编译的 SAP 应用程序
   • 2593824 - Linux：运行使用 GCC 7.x 编译的 SAP 应用程序
   • 2886607 - Linux：运行使用 GCC 9.x 编译的 SAP 应用程序

6. [A] 安装 SAP HANA。

   从 HANA 2.0 SPS 01 开始，MDC 是默认选项。 安装 HANA 系统时，将一起创建 SYSTEMDB 以及具有相同 SID 的租户。 在某些情况下，不需要默认租户。 如果不想在安装过程中创建初始租户，可以按照 SAP 说明 2629711 进行操作。

   从 HANA DVD 运行 hdblcm 程序。 在提示符下输入以下值：

   1. 选择安装：输入 1（用于安装）。
   2. 选择要安装的其他组件：输入 1。
   3. 输入安装路径 [/hana/shared]：选择 Enter 以接受默认值。
   4. 输入本地主机名 [..]：选择 Enter 以接受默认值。 是否要将其他主机添加到系统? （是/否） [n]：n。
   5. 输入 SAP HANA 系统 ID：输入 HN1。
   6. 输入实例编号 [00]：输入 03。
   7. 选择数据库模式/输入索引 [1]：选择 Enter 以接受默认值。
   8. 选择系统使用情况/输入索引 [4]：输入 4（用于自定义）。
   9. 输入数据卷的位置 [/hana/data]：选择 Enter 以接受默认值。
   10. 输入日志卷的位置 [/hana/log]：选择 Enter 以接受默认值。
   11. 是否限制最大内存分配? [n]：选择 Enter 以接受默认值。
   12. 输入主机“...”的证书主机名 [...]：选择 Enter 以接受默认值。
   13. 输入 SAP 主机代理用户 (sapadm) 密码：输入主机代理用户密码。
   14. 确认 SAP 主机代理用户 (sapadm) 密码：再次输入主机代理用户密码以确认。
   15. 输入系统管理员 (hn1adm) 密码：输入系统管理员密码。
   16. 确认系统管理员 (hn1adm) 密码：再次输入系统管理员密码以确认。
   17. 输入系统管理员主目录 [/usr/sap/HN1/home]：选择 Enter 以接受默认值。
   18. 输入系统管理员登录 Shell [/bin/sh]：选择 Enter 以接受默认值。
   19. 输入系统管理员用户 ID [1001]：选择 Enter 以接受默认值。
   20. 输入用户组 (sapsys) ID [79]：选择 Enter 以接受默认值。
   21. 输入数据库用户 (SYSTEM) 密码：输入数据库用户密码。
   22. 确认数据库用户 (SYSTEM) 密码：再次输入数据库用户密码以确认。
   23. 重新引导计算机后是否重新启动系统? [n]：选择 Enter 以接受默认值。
   24. 是否继续？ （是/否）：验证摘要。 按 y 继续。

7. [A] 升级 SAP 主机代理。

   从 SAP 软件中心下载最新的 SAP 主机代理存档，并运行以下命令来升级代理。 替换存档的路径，使其指向已下载的文件：

   sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>
   

8. [A] 配置防火墙。

   为 Azure 负载均衡器探测端口创建防火墙规则。

   sudo firewall-cmd --zone=public --add-port=62503/tcp
   sudo firewall-cmd --zone=public --add-port=62503/tcp –permanent
   

配置 SAP HANA 系统复制

按照设置 SAP HANA 系统复制中的步骤配置 SAP HANA 系统复制。

群集配置

本部分介绍使用 Azure NetApp 文件在 NFS 共享上安装 SAP HANA 时群集无缝运行所需的步骤。

创建 Pacemaker 群集

按照在 Azure 中的 Red Hat Enterprise Linux 上设置 Pacemaker 的步骤，创建适用于此 HANA 服务器的基本 Pacemaker 群集。

重要

借助基于 systemd 的 SAP 启动框架，SAP HANA 实例现在可以由 systemd 管理。 SAP 所需的最低 Red Hat Enterprise Linux (RHEL) 版本是 RHEL 8。 如 SAP 说明 3189534 中所述，任何新安装的 SAP HANA SPS07 修订版 70 或更高版本，或者将 HANA 系统更新到 HANA 2.0 SPS07 修订版 70 或更高版本，SAP 启动框架都会自动注册到 systemd。

当使用 HA 解决方案与启用 systemd 的 SAP HANA 实例结合管理 SAP HANA 系统复制时（请参阅 SAP 说明 3189534），需要执行其他步骤以确保 HA 群集无需 systemd 即可管理 SAP 实例。 因此，对于与 systemd 集成的 SAP HANA 系统，必须在所有群集节点上遵循 Red Hat KBA 7029705 中概述的其他步骤。

实现 Python 系统复制挂钩 SAPHanaSR

这是优化与群集的集成并在需要进行群集故障转移时改进检测的重要步骤。 强烈建议配置 SAPHanaSR Python 挂钩。 遵循实现 Python 系统复制挂钩 SAPHanaSR中的步骤。

配置文件系统资源

在此示例中，每个群集节点都有其自己的 HANA NFS 文件系统 /hana/shared、/hana/data 和 /hana/log。

1. [1] 将群集置于维护模式。

   sudo pcs property set maintenance-mode=true
   

2. [1] 为 hanadb1 装载创建文件系统资源。

   sudo pcs resource create hana_data1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   sudo pcs resource create hana_log1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   sudo pcs resource create hana_shared1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   

3. [2] 为 hanadb2 装载创建文件系统资源。

   sudo pcs resource create hana_data2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   sudo pcs resource create hana_log2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   sudo pcs resource create hana_shared2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   

   OCF_CHECK_LEVEL=20 属性会添加到监视操作，以便每个监视器在文件系统上执行读/写测试。 如果没有此属性，则监视操作仅验证是否已装载文件系统。 这可能是一个问题，因为连接丢失时，尽管无法访问文件系统，但它仍可能保持装载状态。

   on-fail=fence 属性也会添加到监视操作中。 使用此选项时，如果监视操作在节点上失败，则会立即隔离该节点。 如果不使用此选项，则默认行为是停止依赖于失败资源的所有资源，然后重启失败的资源，再启动依赖于失败资源的所有资源。

   当 SAPHana 资源依赖于失败的资源时，此行为不仅费时，还可能彻底失败。 如果持有 HANA 可执行文件的 NFS 服务器不可访问，则 SAPHana 资源无法成功停止。

   建议的超时值允许群集资源承受与 NFSv4.1 租约续订相关的协议特定暂停。 有关详细信息，请参阅 NetApp 中的 NFS 最佳做法。 前述配置中的超时可能需要根据特定的 SAP 设置进行调整。

   对于需要更高吞吐量的工作负载，请考虑使用 nconnect 装载选项，如适用于 SAP HANA 的 Azure NetApp 文件上的 NFS v4.1 卷中所述。 在你的 Linux 版本中检查 nconnect 是否受 Azure NetApp 文件支持。

4. [1] 配置位置约束。

   配置位置约束，以确保管理 hanadb1 唯一装载的资源绝不会在 hanadb2 上运行，反之亦然。

   sudo pcs constraint location hanadb1_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb2
   sudo pcs constraint location hanadb2_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb1
   

   设置 resource-discovery=never 选项是因为每个节点的唯一装载共享相同的装入点。 例如，hana_data1 使用装入点 /hana/data，而 hana_data2 也使用装入点 /hana/data。 如果在群集启动时检查资源状态，共享同一装载点可能导致探测操作误报，进而可能导致不必要的恢复行为。 若要避免这种情况，请设置 resource-discovery=never。

5. [1] 配置属性资源。

   配置属性资源。 如果节点的所有 NFS 挂载（/hana/data、/hana/log 和 /hana/data）均已挂载，这些属性将设置为 true。 否则，它们将被设置为 false。

   sudo pcs resource create hana_nfs1_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs1_active
   sudo pcs resource create hana_nfs2_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs2_active
   

6. [1] 配置位置约束。

   配置位置约束，以确保 hanadb1 的属性资源绝不会在 hanadb2 上运行，反之亦然。

   sudo pcs constraint location hana_nfs1_active avoids hanadb2
   sudo pcs constraint location hana_nfs2_active avoids hanadb1
   

7. [1] 创建排序约束。

   配置排序约束，以便仅在装载了节点的所有 NFS 装载之后，才启动节点的属性资源。

   sudo pcs constraint order hanadb1_nfs then hana_nfs1_active
   sudo pcs constraint order hanadb2_nfs then hana_nfs2_active
   

   提示

   如果配置包括组 hanadb1_nfs 或 hanadb2_nfs 之外的文件系统，则包括 sequential=false 选项，以使文件系统之间没有排序依赖关系。 所有文件系统都必须在 hana_nfs1_active 之前启动，但它们不需要以相对于彼此的任何顺序启动。 有关更多信息，请参阅当 HANA 文件系统位于 NFS 共享上时，如何在 Pacemaker 群集中配置 SAP HANA 纵向扩展系统复制

配置 SAP HANA 群集资源

1. 按照创建 SAP HANA 群集资源中的步骤在群集中创建 SAP HANA 资源。 创建 SAP HANA 资源后，需要在 SAP HANA 资源和文件系统（NFS 装载）之间创建位置规则约束。

2. [1] 配置 SAP HANA 资源和 NFS 装载之间的约束。

   我们将设置位置规则约束，以便仅在装载了节点的所有 NFS 装载后，SAP HANA 资源才能在该节点上运行。

   sudo pcs constraint location SAPHanaTopology_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

   在 RHEL 7.x 上：

   sudo pcs constraint location SAPHana_HN1_03-master rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

   在 RHEL 8.x/9.x 上：

   sudo pcs constraint location SAPHana_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

   将群集退出维护模式。

   sudo pcs property set maintenance-mode=false
   

   检查群集和所有资源的状态。

   注意

   本文包含对 Microsoft 不再使用的术语的引用。 在从软件中删除该术语后，我们会将其从本文中删除。

   sudo pcs status
   

   示例输出：

   Online: [ hanadb1 hanadb2 ]
   
   Full list of resources:
   
   rsc_hdb_azr_agt(stonith:fence_azure_arm):  Started hanadb1
   
   Resource Group: hanadb1_nfs
   hana_data1 (ocf::heartbeat:Filesystem):Started hanadb1
   hana_log1  (ocf::heartbeat:Filesystem):Started hanadb1
   hana_shared1   (ocf::heartbeat:Filesystem):Started hanadb1
   
   Resource Group: hanadb2_nfs
   hana_data2 (ocf::heartbeat:Filesystem):Started hanadb2
   hana_log2  (ocf::heartbeat:Filesystem):Started hanadb2
   hana_shared2   (ocf::heartbeat:Filesystem):Started hanadb2
   
   hana_nfs1_active   (ocf::pacemaker:attribute): Started hanadb1
   hana_nfs2_active   (ocf::pacemaker:attribute): Started hanadb2
   
   Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
   Started: [ hanadb1 hanadb2 ]
   
   Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
   Masters: [ hanadb1 ]
   Slaves: [ hanadb2 ]
   
   Resource Group: g_ip_HN1_03
   nc_HN1_03  (ocf::heartbeat:azure-lb):  Started hanadb1
   vip_HN1_03 (ocf::heartbeat:IPaddr2):   Started hanadb1
   

在 Pacemaker 群集中配置启用 HANA 活动/读取的系统复制

从 SAP HANA 2.0 SPS 01 开始，SAP 允许对 SAP HANA 系统复制使用启用活动/读取的设置，在这种情况下，SAP HANA 系统复制的辅助系统可积极用于读取密集型工作负载。 若要在群集中支持此类设置，需要提供第二个虚拟 IP 地址，以便客户端能够访问启用了辅助读取的 SAP HANA 数据库。

若要确保辅助复制站点在接管后仍可以访问，群集需要将虚拟 IP 地址与 SAPHana 资源的辅助地址一起移动。

在 Pacemaker 群集中配置启用 HANA 活动/读取的系统复制中介绍了在具有第二个虚拟 IP 的 Red Hat 高可用性群集中管理启用 HANA 活动/读取的系统复制所需的其他配置。

在继续下一步之前，请确保已完全配置管理 SAP HANA 数据库的 Red Hat 高可用性群集，如文档先前小节所述。

测试群集设

本部分介绍如何测试设置。

1. 在开始测试之前，请确保 Pacemaker 没有任何失败的操作（通过 pcs 状态检查）、没有任何意外的位置约束（例如迁移测试的遗留内容），并且 HANA 系统复制处于同步状态，例如，使用 systemReplicationStatus：

   sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
   

2. 验证节点无法访问 NFS 共享 (/hana/shared) 的故障情况下的群集配置。

   SAP HANA 资源代理依赖于二进制文件，这些文件存储在 /hana/shared 中，以便在故障转移过程中执行操作。 在所示方案中，文件系统 /hana/shared 已通过 NFS 装载。

   当其中一台服务器失去 NFS 共享访问权限时，很难模拟故障。 作为测试，可以将文件系统重新装载为只读模式。 此方法验证在活动节点上失去 /hana/shared 访问权限时，群集是否能够进行故障转移。

   预期结果：将 /hana/shared 设置为只读文件系统时，资源 hana_shared1 的 OCF_CHECK_LEVEL 属性（在文件系统上执行读/写操作）失败。 它无法在文件系统上写入任何内容并执行 HANA 资源故障转移。 当 HANA 节点失去 NFS 共享访问权限时，会出现相同的结果。

   开始测试之前的资源状态：

   sudo pcs status
   

   示例输出：

   Full list of resources:
    rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb1
   
    Resource Group: hanadb1_nfs
        hana_data1 (ocf::heartbeat:Filesystem):    Started hanadb1
        hana_log1  (ocf::heartbeat:Filesystem):    Started hanadb1
        hana_shared1       (ocf::heartbeat:Filesystem):    Started hanadb1
   
   Resource Group: hanadb2_nfs
        hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2
   
    hana_nfs1_active       (ocf::pacemaker:attribute):     Started hanadb1
    hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2
   
    Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
        Started: [ hanadb1 hanadb2 ]
   
    Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
        Masters: [ hanadb1 ]
        Slaves: [ hanadb2 ]
   
    Resource Group: g_ip_HN1_03
        nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb1
        vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb1
   

   可以使用以下命令将活动群集节点上的 /hana/shared 置于只读模式：

   sudo mount -o ro 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
   

   hanadb 将根据 stonith (pcs property show stonith-action) 上设置的操作重新启动或关闭电源。 服务器 (hanadb1) 关闭后，HANA 资源将移到 hanadb2。 可以从 hanadb2 检查群集的状态。

   sudo pcs status
   

   示例输出：

   Full list of resources:
   
    rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb2
   
    Resource Group: hanadb1_nfs
        hana_data1 (ocf::heartbeat:Filesystem):    Stopped
        hana_log1  (ocf::heartbeat:Filesystem):    Stopped
        hana_shared1       (ocf::heartbeat:Filesystem):    Stopped
   
    Resource Group: hanadb2_nfs
        hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2
   
    hana_nfs1_active       (ocf::pacemaker:attribute):     Stopped
    hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2
   
    Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
        Started: [ hanadb2 ]
        Stopped: [ hanadb1 ]
   
    Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
        Masters: [ hanadb2 ]
        Stopped: [ hanadb1 ]
   
    Resource Group: g_ip_HN1_03
        nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb2
        vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb2
   

   我们建议通过执行在 RHEL 上设置 SAP HANA 系统复制中所述的测试来全面测试 SAP HANA 群集配置。

后续步骤

• 适用于 SAP 的 Azure 虚拟机规划和实施
• 适用于 SAP 的 Azure 虚拟机部署
• 适用于 SAP 的 Azure 虚拟机 DBMS 部署
• 适用于 SAP HANA 的 Azure NetApp 文件上的 NFS v4.1 卷