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

在 SUSE Linux Enterprise Server 上使用 HSR 实现 SAP HANA 横向扩展系统的高可用性

项目
06/18/2024

本文介绍如何在 Azure SUSE Linux Enterprise Server 虚拟机 (VM) 上使用 HANA 系统复制 (HSR) 和 Pacemaker 在横向扩展配置中部署高可用性 SAP HANA 系统。所示体系结构中的共享文件系统是通过 NFS 装载的，由 Azure NetApp 文件或 Azure 文件存储上的 NFS 共享提供。

在示例配置和安装命令等中，HANA 实例为 03，HANA 系统 ID 为 HN1 。

在开始之前，请参阅以下 SAP 说明和文章：

Azure NetApp 文件文档
Azure 文件文档
SAP 说明 1928533 包括：
- SAP 软件部署支持的 Azure VM 大小的列表
- Azure VM 大小的重要容量信息
- 支持的 SAP 软件、操作系统 (OS) 和数据库组合
- Microsoft Azure 上 Windows 和 Linux 所需的 SAP 内核版本
SAP 说明 2015553：列出了在 Azure 中 SAP 支持的 SAP 软件部署的先决条件
SAP 说明 2205917：包含适用于 SUSE Linux Enterprise Server for SAP Applications 的推荐 OS 设置
SAP 说明 1944799：包含适用于 SUSE Linux Enterprise Server for SAP Applications 的 SAP 准则
SAP 说明 2178632：包含有关在 Azure 中为 SAP 报告的所有监视指标的详细信息
SAP 说明 2191498：包含 Azure 中的 Linux 所需的 SAP 主机代理版本
SAP 说明 2243692：包含 Azure 中 Linux 上的 SAP 许可的相关信息
SAP 说明 1984787：包含有关 SUSE Linux Enterprise Server 12 的一般信息
SAP 说明 1999351：包含适用于 SAP 的 Azure 增强型监视扩展的其他故障排除信息
SAP 说明 1900823：包含有关 SAP HANA 存储要求的信息
SAP Community Wiki：包含适用于 Linux 的所有必需 SAP 说明
适用于 Linux 上的 SAP 的 Azure 虚拟机规划和实施
适用于 Linux 上的 SAP 的 Azure 虚拟机部署
适用于 Linux 上的 SAP 的 Azure 虚拟机 DBMS 部署
SUSE SAP HA 最佳做法指南：包含在本地设置 NetWeaver 高可用性以及 SAP HANA 系统复制的所有必需信息（用作一般基线，可提供更详细的信息）
SUSE 高可用性扩展 12 SP5 发行说明
HANA 系统复制处理 SUSE HA 群集中失败的 NFS 共享
适用于 SAP HANA 的 Azure NetApp 文件上的 NFS v4.1 卷

概述

为 HANA 横向扩展安装实现 HANA 高可用性的一种方法是配置 HANA 系统复制，并通过 Pacemaker 群集保护解决方案，以允许自动故障转移。当活动节点发生故障时，群集会将 HANA 资源故障转移到另一个站点。
提供的配置显示每个站点上有三个 HANA 节点，以及用于防止拆分式方案的多数仲裁节点。可以改编说明，以将更多 VM 作为 HANA DB 节点。

所示体系结构中的 HANA 共享文件系统 /hana/shared 可以由 Azure NetApp 文件或 Azure 文件存储上的 NFS 共享提供。 HANA 共享文件系统通过 NFS 装载在同一 HANA 系统复制站点中的每个 HANA 节点上。文件系统 /hana/data 和 /hana/log 是本地文件系统，不在 HANA DB 节点之间共享。 SAP HANA 将以非共享模式安装。

有关建议的 SAP HANA 存储配置，请参阅 SAP HANA Azure VM 存储配置。

重要

如果在 Azure NetApp 文件上部署所有 HANA 文件系统，则对于性能是关键的生产系统，建议评估并考虑使用针对 SAP HANA 的 Azure NetApp 文件应用程序卷组。

警告

不支持在 Azure 文件存储上的 NFS 中部署 /hana/data 和 /hana/log。

在上图中，在一个 Azure 虚拟网络中表示三个子网，遵循 SAP HANA 网络建议：

对于客户端通信 - client 10.23.0.0/24
对于内部 HANA 节点间通信 - inter 10.23.1.128/26
对于 HANA 系统复制 - hsr 10.23.1.192/26

由于 /hana/data 和 /hana/log 部署在本地磁盘上，因此不必部署单独的子网和单独的虚拟网卡来与存储进行通信。

如果使用 Azure NetApp 文件，则 /hana/shared 的 NFS 卷将部署在单独的子网中，委托给 Azure NetApp 文件：anf 10.23.1.0/26。

准备基础结构

在接下来的说明中，假设已创建资源组，即其中包含三个 Azure 网络子网的 Azure 虚拟网络：client、inter 和 hsr。

通过 Azure 门户部署 Linux 虚拟机

部署 Azure VM。

对于本文档中介绍的配置，请部署七个虚拟机：
- 三个虚拟机充当 HANA 复制站点 1 的 HANA DB 节点：hana-s1-db1、hana-s1-db2 和 hana-s1-db3
- 三个虚拟机充当 HANA 复制站点 2 的 HANA DB 节点：hana-s2-db1、hana-s2-db2 和 hana-s2-db3
- 一个小型虚拟机充当多数仲裁节点：hana-s-mm
作为 SAP DB HANA 节点部署的 VM 应由 SAP for HANA 认证，如 SAP HANA 硬件目录中发布的一样。部署 HANA DB 节点时，请确保已选择加速网络。

对于多数仲裁节点，可以部署一个小型 VM，因为此 VM 不会运行任何 SAP HANA 资源。在群集配置中使用多数仲裁 VM 可在拆分式方案中实现奇数个群集节点。在此示例中，多数仲裁 VM 只需要 client 子网中的一个虚拟网络接口。

部署 /hana/data 和 /hana/log 的本地托管磁盘。 SAP HANA Azure VM 存储配置中介绍了 /hana/data 和 /hana/log 的最小建议存储配置。

为 client 虚拟网络子网中的每个 VM 部署主要网络接口。
通过 Azure 门户部署 VM 时，系统会自动生成网络接口名称。在这些说明中，为了简单起见，我们将附加到 client Azure 虚拟网络子网的自动生成的主要网络接口称为“hana-s1-db1-client”、“hana-s1-db2-client”、“hana-s1-db3-client”等。
重要
- 请确保选择的操作系统已经过 SAP 针对使用的特定 VM 类型上的 SAP HANA 进行的认证。有关经 SAP HANA 认证的 VM 类型和这些类型的 OS 版本列表，请访问经 SAP HANA 认证的 IaaS 平台网站。单击进入列出的 VM 类型的详细信息，获取该类型的 SAP HANA 支持的 OS 版本完整列表。
- 如果你选择在 Azure 文件存储上的 NFS 中部署 /hana/shared，我们建议在 SLES 15 SP2 和更高版本上部署。
创建六个网络接口，inter 虚拟网络子网中的每个 HANA DB 虚拟机各一个（在此例中为“hana-s1-db1-inter”、“hana-s1-db2-inter、hana-s1-db3-inter”、“hana-s2-db1-inter”、“hana-s2-db2-inter”和“hana-s2-db3-inter”）。
创建六个网络接口，hsr 虚拟网络子网中的每个 HANA DB 虚拟机各一个（在此例中为“hana-s1-db1-hsr”、“hana-s1-db2-hsr”、“hana-s1-db3-hsr”、“hana-s2-db1-hsr”、“hana-s2-db2-hsr”和“hana-s2-db3-hsr”）。
将新创建的虚拟网络接口附加到相应的虚拟机：
1. 转到 Azure 门户中的虚拟机。
2. 在左侧窗格中，选择“虚拟机”。按虚拟机名称筛选（例如，“hana-s1-db1”），然后选择虚拟机。
3. 在“概述”窗格中，选择“停止”以解除分配虚拟机。
4. 选择“网络”，然后附加网络接口。在“附加网络接口”下拉列表中，选择已为 inter 和 hsr 子网创建的网络接口。
5. 选择“保存”。
6. 对于剩余的虚拟机（在我们的示例中为 hana-s1-db2、hana-s1-db3、hana-s2-db1、hana-s2-db2 和 hana-s2-db3），请重复步骤 b 到 e。
7. 使虚拟机暂时处于停止状态。接下来，我们将为所有新附加的网络接口启用加速网络。

通过执行以下步骤，为 inter 和 hsr 子网的其他网络接口启用加速网络：

在 Azure 门户中打开 Azure Cloud Shell。

执行以下命令，为连接到 inter 和 hsr 子网的其他网络接口启用加速网络。

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-inter --accelerated-networking true

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-hsr --accelerated-networking true

启动 HANA DB 虚拟机

配置 Azure 负载均衡器

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

注意

对于 HANA 横向扩展，请在后端池中添加虚拟机时选择 client 子网的 NIC。
Azure CLI 和 PowerShell 中的完整命令集在后端池中添加具有主 NIC 的 VM。

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

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

注意

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

全套 Azure CLI 代码显示负载均衡器的设置，其中包括后端池中的两个 VM。可以在后端池中添加更多 VM，具体取决于 HANA 横向扩展中的 VM 的数量。

# 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 代码显示负载均衡器的设置，其中包括后端池中的两个 VM。可以在后端池中添加更多 VM，具体取决于 HANA 横向扩展中的 VM 的数量。

# 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

注意

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

重要

请勿在放置于 Azure 负载均衡器之后的 Azure VM 上启用 TCP 时间戳。启用 TCP 时间戳将导致运行状况探测失败。将参数 net.ipv4.tcp_timestamps 设置为 0。有关详细信息，请参阅负载均衡器运行状况探测和 SAP 说明 2382421。
为防止 saptune 将手动设置的 net.ipv4.tcp_timestamps 值从 0 更改回 1，请将 saptune 版本更新为 3.1.1 或更高版本。有关更多详细信息，请参阅 saptune 3.1.1 - 我是否需要更新？。

部署 NFS

可以使用两个选项为 /hana/shared 部署 Azure 本机 NFS。可以在 Azure NetApp 文件或 Azure 文件存储上的 NFS 共享中部署 NFS 卷。 Azure 文件存储支持 NFSv4.1 协议，Azure NetApp 文件上的 NFS 支持 NFSv4.1 和 NFSv3。

后续部分介绍部署 NFS 的步骤 - 只需要选择其中一个选项。

提示

你已选择在 Azure 文件存储上的 NFS 共享或 Azure NetApp 文件上的 NFS 卷中部署 /hana/shared。

部署 Azure NetApp 文件基础结构

为 /hana/shared 文件系统部署 Azure NetApp 文件卷。对于每个 HANA 系统复制站点，都需要一个单独的 /hana/shared 卷。有关详细信息，请参阅设置 Azure NetApp 文件基础结构。

在此例中，使用了以下 Azure NetApp 文件卷：

卷 HN1-shared-s1 (nfs://10.23.1.7/HN1-shared-s1)
卷 HN1-shared-s2 (nfs://10.23.1.7/HN1-shared-s2)

部署 Azure 文件存储上的 NFS 基础结构

为 /hana/shared 文件系统部署 Azure 文件存储 NFS 共享。每个 HANA 系统复制站点都需要一个单独的 /hana/shared Azure 文件存储 NFS 共享。有关详细信息，请参阅如何创建 NFS 共享。

此示例使用了以下 Azure 文件存储 NFS 共享：

共享 hn1-shared-s1 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1)
共享 hn1-shared-s2 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2)

操作系统配置和准备

后续各节中的说明以下列缩写之一作为前缀：

[A]：适用于所有节点，包括多数仲裁节点
[AH]：适用于所有 HANA DB 节点
[M]：仅适用于多数仲裁节点
[AH1]：适用于站点 1 上的所有 HANA DB 节点
[AH2]：适用于站点 2 上的所有 HANA DB 节点
[1]：仅适用于 HANA DB 节点 1，站点 1
[2]：仅适用于 HANA DB 节点 1，站点 2

通过执行以下步骤来配置和准备 OS：

[A] 维护虚拟机上的主机文件。包括所有子网的条目。在此示例中，已向 /etc/hosts 中添加了以下条目。

# Client subnet
10.23.0.19      hana-s1-db1
10.23.0.20      hana-s1-db2
10.23.0.21      hana-s1-db3
10.23.0.22      hana-s2-db1
10.23.0.23      hana-s2-db2
10.23.0.24      hana-s2-db3
10.23.0.25      hana-s-mm    

# Internode subnet
10.23.1.132     hana-s1-db1-inter
10.23.1.133     hana-s1-db2-inter
10.23.1.134     hana-s1-db3-inter
10.23.1.135     hana-s2-db1-inter
10.23.1.136     hana-s2-db2-inter
10.23.1.137     hana-s2-db3-inter

# HSR subnet
10.23.1.196     hana-s1-db1-hsr
10.23.1.197     hana-s1-db2-hsr
10.23.1.198     hana-s1-db3-hsr
10.23.1.199     hana-s2-db1-hsr
10.23.1.200     hana-s2-db2-hsr
10.23.1.201     hana-s2-db3-hsr

[A] 在 Microsoft 的配合下为 Azure 配置设置创建配置文件 /etc/sysctl.d/ms-az.conf。
```
vi /etc/sysctl.d/ms-az.conf

# Add the following entries in the configuration file
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。
[A] SUSE 为 SAP HANA 提供特殊的资源代理，默认安装了用于 SAP HANA 纵向扩展的代理。卸载用于纵向扩展的包（如果已安装）并安装用于场景 SAP HANA 横向扩展的包。该步骤需要在所有群集虚拟机（包括多数仲裁节点）上执行。

注意

必须安装 SAPHanaSR-ScaleOut 版本 0.181 或更高版本。
```
# Uninstall scale-up packages and patterns
sudo zypper remove patterns-sap-hana
sudo zypper remove SAPHanaSR SAPHanaSR-doc yast2-sap-ha

# Install the scale-out packages and patterns
sudo zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc 
sudo zypper in -t pattern ha_sles
```
[AH] 准备 VM - 按照 SAP 说明 2205917 为 SUSE Linux Enterprise Server for SAP Application 应用推荐的设置。

准备文件系统

选择在 Azure 文件存储上的 NFS 共享或 Azure NetApp 文件上的 NFS 卷上部署 SAP 共享目录。

装载共享文件系统（Azure NetApp 文件 NFS）

在此示例中，共享 HANA 文件系统部署在 Azure NetApp 文件上，并通过 NFSv4.1 装载。请仅在使用 Azure NetApp 文件上的 NFS 时，才执行本部分的步骤。

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

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

# Add the following entries in the configuration file
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

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

vi /etc/modprobe.d/sunrpc.conf

# Insert the following line
options sunrpc tcp_max_slot_table_entries=128

[AH] 为 HANA 数据库卷创建装入点。
```
mkdir -p /hana/shared
```
[AH] 验证 NFS 域设置。请确保域配置为默认的 Azure NetApp 文件域，即 defaultv4iddomain.com，并且映射设置为“无人”。
仅当使用 Azure NetAppFiles NFSv4.1 时，才需要执行此步骤。

重要

确保在 VM 上的 /etc/idmapd.conf 中设置 NFS 域，以匹配 Azure NetApp 文件上的默认域配置：“defaultv4iddomain.com”。如果 NFS 客户端（即 VM）上的域配置和 NFS 服务器（即 Azure NetApp 配置）之间不匹配，则 VM 上已装载的 Azure NetApp 卷上文件的权限将显示为 nobody。
```
sudo cat /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
```

[AH] 验证 nfs4_disable_idmapping。它应设置为“Y”。若要创建 nfs4_disable_idmapping 所在的目录结构，请执行 mount 命令。无法在 /sys/modules 下手动创建目录，因为访问权限是为内核/驱动程序保留的。
仅当使用 Azure NetAppFiles NFSv4.1 时，才需要执行此步骤。

# Check nfs4_disable_idmapping 
cat /sys/module/nfs/parameters/nfs4_disable_idmapping
# If you need to set nfs4_disable_idmapping to Y
mkdir /mnt/tmp
mount 10.23.1.7:/HN1-share-s1 /mnt/tmp
umount  /mnt/tmp
echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
# Make the configuration permanent
echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

[AH1] 在 SITE1 HANA DB VM 上装载共享的 Azure NetApp 文件卷。

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s1 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] 在 SITE2 HANA DB VM 上装载共享的 Azure NetApp 文件卷。

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s2 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount the volume
sudo mount -a

[AH] 验证是否在使用 NFS 协议版本 NFSv4.1 的所有 HANA DB VM 上装载了相应的 /hana/shared/ 文件系统。

sudo nfsstat -m
# Verify that flag vers is set to 4.1 
# Example from SITE 1, hana-s1-db1
/hana/shared from 10.23.1.7:/HN1-shared-s1
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.1.7
# Example from SITE 2, hana-s2-db1
/hana/shared from 10.23.1.7:/HN1-shared-s2
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.1.7

装载共享文件系统（Azure 文件存储 NFS）

在此示例中，共享 HANA 文件系统部署在 Azure 文件存储上的 NFS 中。请仅在使用 Azure 文件存储上的 NFS 时，才执行本部分的步骤。

[AH] 为 HANA 数据库卷创建装入点。
```
mkdir -p /hana/shared
```

[AH1] 在 SITE1 HANA DB VM 上装载共享的 Azure NetApp 文件卷。

sudo vi /etc/fstab
# Add the following entry
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] 在 SITE2 HANA DB VM 上装载共享的 Azure NetApp 文件卷。

sudo vi /etc/fstab
# Add the following entries
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount the volume
sudo mount -a

[AH] 验证是否在使用 NFS 协议版本 NFSv4.1 的所有 HANA DB VM 上装载了相应的 /hana/shared/ 文件系统。

sudo nfsstat -m
# Example from SITE 1, hana-s1-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.0.35
# Example from SITE 2, hana-s2-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.0.35

准备数据并记录本地文件系统

在所提供的配置中，文件系统 /hana/data 和 /hana/log 部署在托管磁盘上，并本地附加到每个 HANA DB VM。需要执行以下步骤，才能在每个 HANA DB 虚拟机上创建本地数据和日志卷。

使用“逻辑卷管理器 (LVM)”设置磁盘布局。以下示例假设每个 HANA 虚拟机上附加了三个用于创建两个卷的数据磁盘。

[AH] 列出所有可用的磁盘：

ls /dev/disk/azure/scsi1/lun*

示例输出：

/dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2

[AH] 为想要使用的所有磁盘创建物理卷：

sudo pvcreate /dev/disk/azure/scsi1/lun0
sudo pvcreate /dev/disk/azure/scsi1/lun1
sudo pvcreate /dev/disk/azure/scsi1/lun2

[AH] 为数据文件创建卷组。将一个卷组用于日志文件，将另一个卷组用于 SAP HANA 的共享目录：

sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2

[AH] 创建逻辑卷。

线性卷是使用不带 -i 开关的 lvcreate 创建的。我们建议你创建一个带区卷，以获得更好的 I/O 性能，并将带区大小与 SAP HANA VM 存储配置中记录的值保持一致。 -i 参数应表示基础物理卷的数量，-I 参数则表示带区大小。在本文档中，两个物理卷用于数据卷，因此 -i 开关参数设置为 2。数据卷的带区大小为 256 KiB。一个物理卷用于日志卷，因此，-i 或 -I 开关不会显式用于日志卷命令。

重要

对每个数据或日志卷使用多个物理卷时，请使用 -i 开关，并将其设置为基础物理卷的数量。创建带区卷时，请使用 -I 开关来指定带区大小。
有关建议的存储配置，包括带区大小和磁盘数量，请参阅 SAP HANA VM 存储配置。
```
sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
```

[AH] 创建装载目录，并复制所有逻辑卷的 UUID：

sudo mkdir -p /hana/data/HN1
sudo mkdir -p /hana/log/HN1
# Write down the ID of /dev/vg_hana_data_HN1/hana_data and /dev/vg_hana_log_HN1/hana_log
sudo blkid

[AH] 为逻辑卷创建 fstab 条目并进行装载：

sudo vi /etc/fstab

将以下行插入 /etc/fstab 文件：

/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_data_HN1-hana_data /hana/data/HN1 xfs  defaults,nofail  0  2
/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_log_HN1-hana_log /hana/log/HN1 xfs  defaults,nofail  0  2

装载新卷：

sudo mount -a

创建 Pacemaker 群集

按照在 Azure 中的 SUSE Linux Enterprise Server 上设置 Pacemaker 中的步骤为此 HANA 服务器创建一个基本 Pacemaker 群集。包括所有虚拟机，其中包括群集中的多数仲裁虚拟机。

重要

请勿将 quorum expected-votes 设置为 2，因为这不是一个双节点群集。
确保已启用群集属性 concurrent-fencing，以便反序列化节点隔离。

安装

在此示例中，使用 Azure VM 上的 HSR 以横向扩展配置部署 SAP HANA 时，我们使用了 HANA 2.0 SP5。

准备 HANA 安装

[AH] 安装 HANA 之前，请设置根密码。可以在安装完成后禁用根密码。以 root 身份执行命令 passwd。
[1,2] 更改对 /hana/shared 的权限
```
chmod 775 /hana/shared
```
[1] 验证是否可以通过 SSH 登录到站点“hana-s1-db2”和“hana-s1-db3”中的 HANA DB VM，而不会提示输入密码。如果不是这种情况，请按通过公钥启用 SSH 访问中所述的方式交换 ssh 密钥。
```
ssh root@hana-s1-db2
ssh root@hana-s1-db3
```
[2] 验证是否可以通过 SSH 登录到站点“hana-s2-db2”和“hana-s2-db3”中的 HANA DB VM，而不会提示输入密码。
如果不是这种情况，请交换 ssh 密钥。
```
ssh root@hana-s2-db2
ssh root@hana-s2-db3
```
[AH] 安装 HANA 2.0 SP4 和更高版本所需的其他包。有关详细信息，请参阅适用于 SLES 版本的 SAP 说明 2593824。
```
# In this example, using SLES12 SP5
sudo zypper install libgcc_s1 libstdc++6 libatomic1
```

每个站点上第一个节点上的 HANA 安装

[1] 按照 SAP HANA 2.0 安装和更新指南中的说明安装 SAP HANA。在接下来的说明中，将介绍如何在站点 1 的第一个节点上安装 SAP HANA。

a. 以 root 身份从 HANA 安装软件目录启动 hdblcm 程序。使用 internal_network 参数并传递子网的地址空间，用于内部 HANA 节点间通信。
```
./hdblcm --internal_network=10.23.1.128/26
```
b. 在提示符处输入以下值：
- 对于“选择操作”：输入 1（用于安装）
- 对于“要安装的其他组件”：输入 2、3
- 对于安装路径：按 Enter（默认为 /hana/shared）
- 对于“本地主机名”：按 Enter 接受默认值
- 对于“是否要将主机添加到系统？”：输入 n
- 对于“SAP HANA 系统 ID”：输入 HN1
- 对于“实例号”[00]：输入 03
- 对于“本地主机辅助角色组”[默认值]：按 Enter 接受默认值
- 对于“选择系统使用情况/输入索引[4]”：输入 4（用于自定义）
- 对于“数据卷的位置”[/hana/data/HN1]：按 Enter 接受默认值
- 对于“日志卷的位置”[/hana/log/HN1]：按 Enter 接受默认值
- 对于“是否限制最大内存分配？”[n]：输入 n
- 对于“主机 hana-s1-db1 的证书主机名”[hana-s1-db1]：按 Enter 接受默认值
- 对于“SAP 主机代理用户 (sapadm) 密码”：输入密码
- 对于“确认 SAP 主机代理用户 (sapadm) 密码”：输入密码
- 对于“系统管理员 (hn1adm) 密码”：输入密码
- 对于“系统管理员主目录”[/usr/sap/HN1/home]：按 Enter 接受默认值
- 对于“系统管理员登录 Shell”[/bin/sh]：按 Enter 接受默认值
- 对于“系统管理员用户 ID”[1001]：按 Enter 接受默认值
- 对于“用户组的输入 ID (sapsys)”[79]：按 Enter 接受默认值
- 对于“系统数据库用户 (system) 密码”：输入系统的密码
- 对于“确认系统数据库用户(system)密码”：输入系统的密码
- 对于“重新引导计算机后是否重启系统?”[n]：输入 n
- 对于“是否要继续 (y/n)”：验证摘要，如果一切正常，请输入 y
[2] 重复上一步，在站点 2 上的第一个节点上安装 SAP HANA。
[1,2] 验证 global.ini

显示 global.ini，并确保 SAP HANA 内部节点间通信的配置已就位。验证 communication 节。它应该具有 inter 子网的地址空间，并且 listeninterface 应设置为 .internal。验证 internal_hostname_resolution 节。它应该具有属于 inter 子网的 HANA 虚拟机的 IP 地址。
```
  sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
  # Example from SITE1 
  [communication]
  internal_network = 10.23.1.128/26
  listeninterface = .internal
  [internal_hostname_resolution]
  10.23.1.132 = hana-s1-db1
  10.23.1.133 = hana-s1-db2
  10.23.1.134 = hana-s1-db3
```

[1,2] 准备好 global.ini 以在非共享环境中安装，如 SAP 说明 2080991 中所述。

 sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
 [persistence]
 basepath_shared = no

[1,2] 重启 SAP HANA 以激活更改。

 sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem
 sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem

[1,2] 验证客户端接口是否将使用 client 子网中的 IP 地址进行通信。

# Execute as hn1adm
/usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from SYS.M_HOST_INFORMATION'|grep net_publicname
# Expected result - example from SITE 2
"hana-s2-db1","net_publicname","10.23.0.22"

有关如何验证配置的信息，请参阅 SAP 说明 2183363 - SAP HANA 内部网络配置。

[AH] 更改对数据和日志目录的权限，以避免 HANA 安装错误。
```
 sudo chmod o+w -R /hana/data /hana/log
```
[1] 安装辅助 HANA 节点。此步骤中的示例说明适用于站点 1。

a. 以 root 身份启动常驻 hdblcm 程序。
```
 cd /hana/shared/HN1/hdblcm
 ./hdblcm 
```
b. 在提示符处输入以下值：
- 对于“选择操作”：输入 2（用于添加主机）
- 对于“输入要添加的逗号分隔的主机名”：hana-s1-db2、hana-s1-db3
- 对于“要安装的其他组件”：输入 2、3
- 对于“输入根用户名 [root]”：按 Enter 接受默认值
- 对于“选择主机 'hana-s1-db2' 的角色 [1]”：1（适用于辅助角色）
- 对于“输入主机 'hana-s1-db2' 的主机故障转移组 [默认值]”：按 Enter 接受默认值
- 对于“输入主机‘hana-s1-db2’的存储分区号 [<<自动分配>>]”：按 Enter 接受默认值
- 对于“输入主机 'hana-s1-db2' 的辅助角色组 [默认值]”：按 Enter 接受默认值
- 对于“选择主机 'hana-s1-db3' 的角色 [1]”：1（适用于辅助角色）
- 对于“输入主机 'hana-s1-db3' 的主机故障转移组 [默认值]”：按 Enter 接受默认值
- 对于“输入主机‘hana-s1-db3’的存储分区号 [<<自动分配>>]”：按 Enter 接受默认值
- 对于“输入主机 'hana-s1-db3' 的辅助角色组 [默认值]”：按 Enter 接受默认值
- 对于“系统管理员 (hn1adm) 密码”：输入密码
- 对于“输入 SAP 主机代理用户 (sapadm) 密码”：输入密码
- 对于“确认 SAP 主机代理用户 (sapadm) 密码”：输入密码
- 对于“主机 hana-s1-db2 的证书主机名”[hana-s1-db2]：按 Enter 接受默认值
- 对于“主机 hana-s1-db3 的证书主机名”[hana-s1-db3]：按 Enter 接受默认值
- 对于“是否要继续 (y/n)”：验证摘要，如果一切正常，请输入 y
[2] 重复上一步以在站点 2 上安装辅助 SAP HANA 节点。

配置 SAP HANA 2.0 系统复制

[1] 在站点 1 上配置系统复制：

以 hn1adm 身份备份数据库：

hdbsql -d SYSTEMDB -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
hdbsql -d HN1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"

将系统 PKI 文件复制到辅助站点：

scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

创建主站点：

hdbnsutil -sr_enable --name=HANA_S1

[2] 在站点 2 上配置系统复制：

注册第二个站点以启动系统复制。以 <hanasid>adm 身份运行以下命令：

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=sync --name=HANA_S2
sapcontrol -nr 03 -function StartSystem

[1] 检查复制状态

检查复制状态并等待，直到所有数据库都保持同步。

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

# | Database | Host          | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary     | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
# |          |               |       |              |           |         |           | Host          | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
# | -------- | ------------- | ----- | ------------ | --------- | ------- | --------- | ------------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | HN1      | hana-s1-db3   | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db3   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | SYSTEMDB | hana-s1-db1   | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1   |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1   |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db2   | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db2   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
# status system replication site "2": ACTIVE
# overall system replication status: ACTIVE
#
# Local System Replication State
#
# mode: PRIMARY
# site id: 1
# site name: HANA_S1

[1,2] 更改 HANA 配置，以便通过 HANA 系统复制虚拟网络接口定向 HANA 系统复制通信。

在两个站点上停止 HANA

sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB

编辑 global.ini 以便为 HANA 系统复制添加主机映射：使用 hsr 子网中的 IP 地址。

sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
#Add the section
[system_replication_hostname_resolution]
10.23.1.196 = hana-s1-db1
10.23.1.197 = hana-s1-db2
10.23.1.198 = hana-s1-db3
10.23.1.199 = hana-s2-db1
10.23.1.200 = hana-s2-db2
10.23.1.201 = hana-s2-db3

在两个站点上启动 HANA

sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB

有关详细信息，请参阅系统复制的主机名解析。

创建文件系统资源

创建一个虚拟文件系统群集资源，它将监视和报告故障，以防在访问 NFS 装载的文件系统 /hana/shared 时出现问题。此操作能够在访问 /hana/shared 出现问题时，使群集触发故障转移。有关详细信息，请参阅为 HANA 系统复制处理 SUSE HA 群集中失败的 NFS 共享

[1] 将 pacemaker 置于维护模式，以便为创建 HANA 群集资源做准备。
```
crm configure property maintenance-mode=true
```
[1,2] 在 NFS 装载的文件系统 /hana/shared 上创建目录，以便在特殊文件系统监视资源中使用。需要在两个站点上创建目录。
```
mkdir -p /hana/shared/HN1/check
```
[AH] 创建将用于装载特殊文件系统监视资源的目录。需要在所有 HANA 群集节点上创建目录。
```
mkdir -p /hana/check
```

[1] 创建文件系统群集资源。

crm configure primitive fs_HN1_HDB03_fscheck Filesystem \
  params device="/hana/shared/HN1/check" \
  directory="/hana/check" fstype=nfs4 \
  options="bind,defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock" \
  op monitor interval=120 timeout=120 on-fail=fence \
  op_params OCF_CHECK_LEVEL=20 \
  op start interval=0 timeout=120 op stop interval=0 timeout=120

crm configure clone cln_fs_HN1_HDB03_fscheck fs_HN1_HDB03_fscheck \
  meta clone-node-max=1 interleave=true

crm configure location loc_cln_fs_HN1_HDB03_fscheck_not_on_mm \
  cln_fs_HN1_HDB03_fscheck -inf: hana-s-mm

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

on-fail=fence 属性也会添加到监视操作中。使用此选项时，如果监视操作在节点上失败，则会立即隔离该节点。

实现 HANA HA 挂钩 SAPHanaSrMultiTarget 和 susChkSrv

这个重要的步骤是为了优化与群集的集成，以及优化在可以实施群集故障转移时进行的检测。强烈建议配置 SAPHanaSrMultiTarget Python 挂钩。对于 HANA 2.0 SP5 及更高版本，建议实现 SAPHanaSrMultiTarget 和 susChkSrv 挂钩。

注意

SAPHanaSrMultiTarget HA 提供程序替换了 SAPHanaSR，用于 HANA 横向扩展。本文档的早期版本对 SAPHanaSR 进行了描述。
请参阅 SUSE 博客文章，了解新 HANA HA 挂钩的更改。

为 SAPHanaSrMultiTarget 挂钩提供的步骤适用于全新安装。将现有环境从 SAPHanaSR 升级到 SAPHanaSrMultiTarget 提供程序需要进行多项更改，本文档未对此进行描述。如果现有环境不使用第三个站点进行灾难恢复并且不使用 HANA 多目标系统复制，则 SAPHanaSR HA 提供程序可以继续使用。

SusChkSrv 扩展了主 SAPHanaSrMultiTarget HA 提供程序的功能。它在 HANA 进程 hdbindexserver 崩溃时发挥作用。如果单个进程崩溃，HANA 通常会尝试重启该进程。重启 indexserver 进程可能需要很长时间，在此期间 HANA 数据库无法响应。实现 susChkSrv 后，会执行一项即时的可配置操作，而不是等待 hdbindexserver 进程在同一节点上重启。在 HANA 横向扩展中，susChkSrv 独立地针对每个 HANA VM 执行操作。配置的操作将终止 HANA 或隔离受影响的 VM，这会在配置的超时期限内触发故障转移。

两个 HANA HA 挂钩的操作需要 SUSE SLES 15 SP1 或更高版本。下表显示了其他依赖项。

SAP HANA HA 挂钩	所需的 HANA 版本	所需的 SAPHanaSR-ScaleOut
SAPHanaSrMultiTarget	HANA 2.0 SPS4 或更高版本	0.180 或更高版本
susChkSrv	HANA 2.0 SPS5 或更高版本	0.184.1 或更高版本

实现两个挂钩的步骤：

[1,2] 停止两个系统复制站点上的 HANA。以 <sid>adm 身份执行：
```
sapcontrol -nr 03 -function StopSystem
```
[1,2] 在每个群集站点上调整 global.ini。如果不满足 susChkSrv 挂钩的先决条件，则不应配置整个块 [ha_dr_provider_suschksrv]。
可以使用参数 action_on_lost 调整 susChkSrv 的行为。有效值为：[ ignore | stop | kill | fence ]。
```
# add to global.ini on both sites. Do not copy global.ini between sites.
[ha_dr_provider_saphanasrmultitarget]
provider = SAPHanaSrMultiTarget
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 3
action_on_lost = kill

[trace]
ha_dr_saphanasrmultitarget = info
```
SUSE 交付的 HA 挂钩的默认位置是 /usr/share/SAPHanaSR-ScaleOut。使用标准位置带来了一个好处，即 Python 挂钩代码通过 OS 或包更新自动更新，并在下次重启时由 HANA 使用。使用自己的可选路径（例如 /hana/shared/myHooks），可以将操作系统更新与使用的挂钩版本分离。

[AH] 群集需要在群集节点上为 <sid>adm 配置 sudoers。在此示例中，通过创建新文件来实现此目的。以 root 身份执行命令，根据相应的小写 SID 调整 hn1 的值。

cat << EOF > /etc/sudoers.d/20-saphana
# SAPHanaSR-ScaleOut needs for HA/DR hook scripts
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_gsh *
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=hn1 *
EOF

[1,2] 在两个复制站点上启动 SAP HANA。以 <sid>adm 身份执行。
```
sapcontrol -nr 03 -function StartSystem 
```

[A] 验证挂钩安装在所有群集节点上都处于活动状态。以 <sid>adm 身份执行。

cdtrace
grep HADR.*load.*SAPHanaSrMultiTarget nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[14162]{-1}[-1/-1] 2023-01-26 12:53:55.728027 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'SAPHanaSrMultiTarget' from /usr/share/SAPHanaSR-ScaleOut/
grep SAPHanaSr.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256705 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00080) : SAPHanaSrMultiTarget.init() CALLING CRM: <sudo /usr/sbin/crm_attribute -n hana_hn1_gsh -v 2.2  -l reboot> rc=0
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256739 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00081) : SAPHanaSrMultiTarget.init() Running srHookGeneration 2.2, see attribute hana_hn1_gsh too

验证 susChkSrv 挂钩安装。以 <sid>adm 身份执行。

cdtrace
egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
# Example output
# 2023-01-19 08:23:10.581529  [1674116590-10005] susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
# 2023-01-19 08:23:31.553566  [1674116611-14022] START: indexserver event looks like graceful tenant start
# 2023-01-19 08:23:52.834813  [1674116632-15235] START: indexserver event looks like graceful tenant start (indexserver started)

创建 SAP HANA 群集资源

[1] 创建 HANA 群集资源。以 root 身份执行以下命令。

请确保群集已处于维护模式。

接下来，创建 HANA 拓扑资源。

sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="HN1" InstanceNumber="03"

sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \
 meta clone-node-max="1" target-role="Started" interleave="true"

接下来，创建 HANA 实例资源。

注意

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

sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op monitor interval="60" role="Master" timeout="700" \
  op monitor interval="61" role="Slave" timeout="700" \
  params SID="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
  meta clone-node-max="1" master-max="1" interleave="true"

重要

建议的最佳做法是，仅将 AUTOMATED_REGISTER 设置为“否”，同时执行全面的故障转移测试，以防止失败的主实例自动注册为辅助实例。故障转移测试成功完成后，将 AUTOMATED_REGISTER 设置为“是”，以便在接管后系统复制自动继续。

创建虚拟 IP 和关联的资源。

sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"

sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

创建群集约束

# Colocate the IP with HANA master
sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
  msl_SAPHana_HN1_HDB03:Master  

# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
  msl_SAPHana_HN1_HDB03

# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaCon_not_on_majority_maker msl_SAPHana_HN1_HDB03 -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_HN1_HDB03 -inf: hana-s-mm

[1] 配置其他群集属性

sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=50

[1] 将群集退出维护模式。请确保群集状态正常，并且所有资源都已启动。

# Cleanup any failed resources - the following command is example 
crm resource cleanup rsc_SAPHana_HN1_HDB03

# Place the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false

[1] 验证 HANA HA 挂钩与群集之间的通信，其中显示了 SID 的 SOK 状态以及状态为 P（主要）或 S（辅助）的两个复制站点。

sudo /usr/sbin/SAPHanaSR-showAttr
# Expected result
# Global cib-time                 maintenance prim  sec sync_state upd
# ---------------------------------------------------------------------
# HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
# 
# Sites     lpt        lss mns        srHook srr
# -----------------------------------------------
# HANA_S1     1674815869 4   hana-s1-db1 PRIM   P
# HANA_S2     30         4   hana-s2-db1 SWAIT  S

注意

上述配置中的超时只是示例，可能需要根据特定的 HANA 设置进行调整。例如，如果启动 SAP HANA 数据库需要较长时间，则可能需要增加启动超时。

测试 SAP HANA 故障转移

注意

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

在开始测试前，请检查群集和 SAP HANA 系统复制状态。

a. 验证是否不存在失败的群集操作

#Verify that there are no failed cluster actions
crm status
# Example 
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Full list of resources:
#
# stonith-sbd    (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s1-db1

b. 验证 SAP HANA 系统复制是否同步

# Verify HANA HSR is in sync
sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
#| Database | Host         | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary    | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
#|          |              |       |              |           |         |           | Host         | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
#| -------- | ------------ | ----- | ------------ | --------- | ------- | --------- | ------------ | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
#| SYSTEMDB | hana-s1-db1  | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1  |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1  |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db3  | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db3  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db2  | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db2  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
#status system replication site "1": ACTIVE
#overall system replication status: ACTIVE
#
#Local System Replication State
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
#mode: PRIMARY
#site id: 1
#site name: HANA_S1

建议通过执行 SLES 上 Azure VM 上的 SAP HANA 的 HA 和 SLES 复制横向扩展性能优化方案中所述的测试，全面验证 SAP HANA 群集配置。

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

SAP HANA 资源代理依赖于二进制文件，这些文件存储在 /hana/shared 中，以便在故障转移过程中执行操作。文件系统 /hana/shared 以所提供的配置通过 NFS 装载。可以执行的一项测试是创建临时防火墙规则，用于在某个主站点 VM 上阻止访问 /hana/shared NFS 装载的文件系统。此方法验证如果在活动系统复制站点上丢失对 /hana/shared 的访问权限，群集是否会进行故障转移。

预期结果：在某个主站点 VM 上阻止访问 /hana/shared NFS 装载的文件系统时，对文件系统执行读/写操作的监视操作将会失败，因为它无法访问文件系统并将触发 HANA 资源故障转移。当 HANA 节点失去对 NFS 共享的访问权限时，会出现相同的结果。

可以通过执行 crm_mon 或 crm status 来检查群集资源的状态。开始测试之前的资源状态：

# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1

若要模拟 /hana/shared 的故障，请执行以下操作：

如果使用 Azure NetApp 文件上的 NFS，请先在主站点上确认 /hana/shared Azure NetApp 文件卷的 IP 地址。可以通过运行 df -kh|grep /hana/shared 来实现此目的。
如果使用 Azure 文件存储上的 NFS，请先确定存储帐户的专用终结点的 IP 地址。

然后，设置一个临时防火墙规则来阻止访问 /hana/shared NFS 文件系统的 IP 地址，方法是在某个主 HANA 系统复制站点 VM 上执行以下命令。

在此示例中，该命令已在 hana-s1-db1 上针对 Azure NetApp 文件卷 /hana/shared 执行。

iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP

群集资源将迁移到其他 HANA 系统复制站点。

如果将 AUTOMATED_REGISTER 设置为“false”，则需要在辅助站点上配置 SAP HANA 系统复制。在这种情况下，可以执行以下命令来将 SAP HANA 重新配置为辅助站点。

# Execute on the secondary 
su - hn1adm
# Make sure HANA is not running on the secondary site. If it is started, stop HANA
sapcontrol -nr 03 -function StopWait 600 10
# Register the HANA secondary site
hdbnsutil -sr_register --name=HANA_S1 --remoteHost=hana-s2-db1 --remoteInstance=03 --replicationMode=sync
# Switch back to root and cleanup failed resources
crm resource cleanup SAPHana_HN1_HDB03

测试后的资源状态为：

# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s2-db1 ]
#     Slaves: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1

后续步骤

适用于 SAP 的 Azure 虚拟机规划和实施
适用于 SAP 的 Azure 虚拟机部署
适用于 SAP 的 Azure 虚拟机 DBMS 部署
适用于 SAP HANA 的 Azure NetApp 文件上的 NFS v4.1 卷
若要了解如何在 Azure VM 上建立 SAP HANA 的高可用性和灾难恢复计划，请参阅 Azure 虚拟机 (VM) 上的 SAP HANA 的高可用性。

通过