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

SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

项目
04/08/2024

若要在本地 SAP HANA 部署中建立高可用性，可以使用 SAP HANA 系统复制或共享存储。

当前在 Azure 虚拟机 (VM) 上，Azure 上的 SAP HANA 系统复制是唯一受支持的高可用性功能。

SAP HANA 系统复制由一个主节点和至少一个辅助节点组成。对主节点上数据所做的更改以同步或异步方式复制到辅助节点。

本文介绍如何部署和配置 VM、安装群集框架，以及安装和配置 SAP HANA 系统复制。

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

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 12 (SLES 12) for SAP Applications 的推荐 OS 设置。
SAP 说明 2684254 包含适用于SUSE Linux Enterprise Server 15 (SLES 15) for SAP Applications 的推荐 OS 设置。
SAP 说明 2235581 介绍了 SAP HANA 支持的操作系统
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 说明 401162 包含有关如何在设置 HANA 系统复制时避免“地址已使用”错误的信息。
SAP 社区支持 Wiki 包含适用于 Linux 的所有必需 SAP 说明。
经 SAP HANA 认证的 IaaS 平台。
针对 Linux 上的 SAP 的 Azure 虚拟机规划和实施指南。
适用于 Linux 上的 SAP 的 Azure 虚拟机部署指南。
适用于 Linux 上的 SAP 的 Azure 虚拟机 DBMS 部署指南。
SUSE Linux Enterprise Server for SAP Applications 15 最佳做法指南和 SUSE Linux Enterprise Server for SAP Applications 12 最佳做法指南：
- 设置 SAP HANA SR 性能优化的基础结构 (SLES for SAP Applications)。本指南包含为本地开发设置 SAP HANA 系统复制的所需的全部信息。请使用本指南作为基准。
- 设置 SAP HANA SR 成本优化的基础结构 (SLES for SAP Applications)。

规划 SAP HANA 高可用性

若要实现高可用性，请在两个 VM 上安装 SAP HANA。数据将使用 HANA 系统复制进行复制。

显示 SAP HANA 高可用性概述的示意图。

SAP HANA 系统复制设置使用专用的虚拟主机名和虚拟 IP 地址。在 Azure 中，需要使用负载均衡器来部署虚拟 IP 地址。

上图显示了具有以下配置的负载均衡器示例：

前端 IP 地址：10.0.0.13 (HN1-db)
探测端口：62503

准备基础结构

SUSE Linux Enterprise Server for SAP Applications 中已随附 SAP HANA 的资源代理。 Azure 市场中提供了 SUSE Linux Enterprise Server for SAP Applications 12 或 15 的映像。可使用该映像来部署新的 VM。

通过 Azure 门户手动部署 Linux VM

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

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

重要

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

配置 Azure 负载均衡器

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

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

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

注意

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

# 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

# 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 标准负载均衡器的 VM 的公共终结点连接。

重要

请勿在放置于 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 – 我是否需要更新？。

创建 Pacemaker 群集

按照在 Azure 中的 SUSE Linux Enterprise Server 上设置 Pacemaker 中的步骤为此 HANA 服务器创建一个基本 Pacemaker 群集。还可对 SAP HANA 和 SAP NetWeaver (A)SCS 使用同一 Pacemaker 群集。

安装 SAP HANA

本部分中的步骤使用以下前缀：

[A] ：该步骤适用于所有节点。
[1]：此步骤仅适用于节点 1。
[2]：此步骤仅适用于 Pacemaker 群集的节点 2。

将 <placeholders> 替换为 SAP HANA 安装的值。

[A] 使用逻辑卷管理器 (LVM) 设置磁盘布局。

我们建议对存储数据和日志文件的卷使用 LVM。以下示例假设 VM 上附加了四个用于创建两个卷的数据磁盘。

运行以下命令列出所有可用磁盘：

/dev/disk/azure/scsi1/lun*

示例输出：

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

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

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

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

sudo vgcreate vg_hana_data_<HANA SID> /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_<HANA SID> /dev/disk/azure/scsi1/lun2
sudo vgcreate vg_hana_shared_<HANA SID> /dev/disk/azure/scsi1/lun3

创建逻辑卷。

线性卷是使用不带 -i 开关的 lvcreate 创建的。我们建议你创建一个带区卷，以获得更好的 I/O 性能。将带区大小与 SAP HANA VM 存储配置中所述的值保持一致。 -i 参数应表示基础物理卷的数量，-I 参数则表示带区大小。

例如，如果两个物理卷用于数据卷，-i 开关参数设置为 2，数据卷的带区大小为 256KiB。一个物理卷用于日志卷，因此，-i 或 -I 开关不会显式用于日志卷命令。

重要

对每个数据卷、日志卷或共享卷使用多个物理卷时，请使用 -i 开关，并将其设置为基础物理卷的数量。创建条带卷时，请使用 -I 开关指定带区大小。

有关建议的存储配置，包括带区大小和磁盘数，请参阅 SAP HANA VM 存储配置。
```
sudo lvcreate <-i number of physical volumes> <-I stripe size for the data volume> -l 100%FREE -n hana_data vg_hana_data_<HANA SID>
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_<HANA SID>
sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_<HANA SID>
sudo mkfs.xfs /dev/vg_hana_data_<HANA SID>/hana_data
sudo mkfs.xfs /dev/vg_hana_log_<HANA SID>/hana_log
sudo mkfs.xfs /dev/vg_hana_shared_<HANA SID>/hana_shared
```

创建装载目录并复制所有逻辑卷的通用唯一标识符 (UUID)：

sudo mkdir -p /hana/data/<HANA SID>
sudo mkdir -p /hana/log/<HANA SID>
sudo mkdir -p /hana/shared/<HANA SID>
# Write down the ID of /dev/vg_hana_data_<HANA SID>/hana_data, /dev/vg_hana_log_<HANA SID>/hana_log, and /dev/vg_hana_shared_<HANA SID>/hana_shared
sudo blkid

编辑 /etc/fstab 文件，为三个逻辑卷创建 fstab 条目：
```
sudo vi /etc/fstab
```

在 /etc/fstab 文件中插入以下行：

/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_data_<HANA SID>-hana_data> /hana/data/<HANA SID> xfs  defaults,nofail  0  2
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_log_<HANA SID>-hana_log> /hana/log/<HANA SID> xfs  defaults,nofail  0  2
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_<HANA SID>-hana_shared> /hana/shared/<HANA SID> xfs  defaults,nofail  0  2

装载新卷：
```
sudo mount -a
```

[A] 使用普通磁盘设置磁盘布局。

对于演示系统，可将 HANA 数据和日志文件放在一个磁盘上。

在 /dev/disk/azure/scsi1/lun0 上创建分区，并使用 XFS 设置其格式：

sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0'
sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1

# Write down the ID of /dev/disk/azure/scsi1/lun0-part1
sudo /sbin/blkid
sudo vi /etc/fstab

在 /etc/fstab 文件中插入此行：

/dev/disk/by-uuid/<UUID> /hana xfs  defaults,nofail  0  2

创建目标目录并装载磁盘：
```
sudo mkdir /hana
sudo mount -a
```

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

可以使用 DNS 服务器，或修改所有节点上的 /etc/hosts 文件。此示例演示如何使用 /etc/hosts 文件。请替换以下命令中的 IP 地址和主机名。
1. 编辑 /etc/hosts 文件：
```
sudo vi /etc/hosts
```
2. 将以下行插入 /etc/hosts 文件。根据你的环境更改 IP 地址和主机名。
```
10.0.0.5 hn1-db-0
10.0.0.6 hn1-db-1
```
[A] 安装 SAP HANA 高可用性包：
- 运行以下命令以安装高可用性包：
```
sudo zypper install SAPHanaSR
```
若要安装 SAP HANA 系统复制，请查看 SAP HANA SR 性能优化方案指南的第 4 章。
[A] 从 HANA 安装介质运行 hdblcm 程序。

出现提示时，请输入以下值：
1. 选择安装：输入 1。
2. 选择要安装的其他组件：输入 1。
3. 输入安装路径：输入“/hana/shared”，然后选择 Enter。
4. 输入本地主机名：输入 .. 并选择 Enter。
5. 是否要将其他主机添加到系统? (y/n)：输入 n ，然后选择 Enter。
6. 输入 SAP HANA 系统 ID：输入 HANA SID。
7. 输入实例编号：输入 HANA 实例编号。如果使用 Azure 模板部署，或者遵循本文的手动部署部分，请输入“03”。
8. 选择数据库模式/输入索引：输入或选择“1”，然后选择 Enter。
9. 选择系统用途/输入索引：选择系统用途值“4”。
10. 输入数据卷的位置：输入 /hana/data/<HANA SID>，然后选择 Enter。
11. 输入日志卷的位置：输入 /hana/log/<HANA SID>，然后选择 Enter。
12. 限制最大内存分配？：输入“n”，然后选择 Enter。
13. 输入主机的证书主机名：输入 ... ，然后选择 Enter。
14. 输入 SAP 主机代理用户 (sapadm) 密码：输入主机代理用户密码，然后选择 Enter。
15. 确认 SAP 主机代理用户 (sapadm) 密码：再次输入主机代理用户密码，然后选择 Enter。
16. 输入系统管理员 (hdbadm) 密码：输入系统管理员密码，然后选择 Enter。
17. 确认系统管理员 (hdbadm) 密码：再次输入系统管理员密码，然后选择 Enter。
18. 输入系统管理员主目录：输入 /usr/sap/<HANA SID>/home，然后选择 Enter。
19. 输入系统管理员登录 shell：输入 /bin/sh 并选择 Enter。
20. 输入系统管理员用户 ID：输入 1001，然后选择 Enter。
21. 输入用户组的 ID (sapsys)：输入 79，然后选择 Enter。
22. 输入数据库用户 (SYSTEM) 密码：输入数据库用户密码，然后选择 Enter。
23. 确认数据库用户 (SYSTEM) 密码：再次输入数据库用户密码，然后选择 Enter。
24. 重新引导计算机后是否重新启动系统? (y/n)：输入 n ，然后选择 Enter。
25. 是否继续? (y/n)：验证摘要。按 y 继续。
[A] 升级 SAP 主机代理。

从 SAP 软件中心下载最新的 SAP 主机代理存档。运行以下命令来升级代理。替换存档的路径，使其指向已下载的文件。
```
sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP host agent SAR>
```

配置 SAP HANA 2.0 系统复制

本部分中的步骤使用以下前缀：

[A] ：该步骤适用于所有节点。
[1]：此步骤仅适用于节点 1。
[2]：此步骤仅适用于 Pacemaker 群集的节点 2。

将 <placeholders> 替换为 SAP HANA 安装的值。

[1] 创建租户数据库。

如果使用的是 SAP HANA 2.0 或 SAP HANA MDC，请为 SAP NetWeaver 系统创建一个租户数据库。

以 <HANA SID>adm 身份运行以下命令：
```
hdbsql -u SYSTEM -p "<password>" -i <instance number> -d SYSTEMDB 'CREATE DATABASE <SAP SID> SYSTEM USER PASSWORD "<password>"'
```

[1] 在第一个节点上配置系统复制：

首先，将数据库备份为 <HANA SID>adm：

hdbsql -d SYSTEMDB -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SYS>')"
hdbsql -d <HANA SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for HANA SID>')"
hdbsql -d <SAP SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SAP SID>')"

然后，将系统公钥基础结构 (PKI) 文件复制到辅助站点：

scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/SSFS_<HANA SID>.DAT   hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/
scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/SSFS_<HANA SID>.KEY  hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/

创建主站点：

hdbnsutil -sr_enable --name=<site 1>

[2] 在第二个节点上配置系统复制：

注册第二个节点以启动系统复制。

以 <HANA SID>adm 身份运行以下命令：

sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

配置 SAP HANA 1.0 系统复制

本部分中的步骤使用以下前缀：

[A] ：该步骤适用于所有节点。
[1]：此步骤仅适用于节点 1。
[2]：此步骤仅适用于 Pacemaker 群集的节点 2。

将 <placeholders> 替换为 SAP HANA 安装的值。

[1] 创建所需的用户。

以 root 身份运行以下命令：

PATH="$PATH:/usr/sap/<HANA SID>/HDB<instance number>/exe"
hdbsql -u system -i <instance number> 'CREATE USER hdbhasync PASSWORD "<password>"'
hdbsql -u system -i <instance number> 'GRANT DATA ADMIN TO hdbhasync'
hdbsql -u system -i <instance number> 'ALTER USER hdbhasync DISABLE PASSWORD LIFETIME'

[A] 创建密钥存储条目。

以 root 身份运行以下命令来创建新的密钥存储条目：

PATH="$PATH:/usr/sap/<HANA SID>/HDB<instance number>/exe"
hdbuserstore SET hdbhaloc localhost:3<instance number>15 hdbhasync <password>

[1] 备份数据库。

以 root 身份备份数据库：

PATH="$PATH:/usr/sap/<HANA SID>/HDB<instance number>/exe"
hdbsql -d SYSTEMDB -u system -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file>')"

如果使用的是多租户安装，则还需要备份租户数据库：

hdbsql -d <HANA SID> -u system -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file>')"

[1] 在第一个节点上配置系统复制。

以 <HANA SID>adm 身份创建主站点：
```
su - hdbadm
hdbnsutil -sr_enable --name=<site 1>
```

[2] 在辅助节点上配置系统复制。

以 <HANA SID>adm 身份注册辅助站点：

sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=<HANA SID>-db-<database 1> --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

实现 HANA 挂钩 SAPHanaSR 和 susChkSrv

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

susChkSrv 挂钩扩展了主 SAPHanaSR HA 提供程序的功能。它在 HANA 进程 hdbindexserver 崩溃时发挥作用。如果单个进程崩溃，HANA 通常会尝试重启该进程。重启 indexserver 进程可能需要很长时间，在此期间 HANA 数据库无法响应。

实现 susChkSrv 后，将立即执行可配置操作。该操作在配置的超时期内触发故障转移，而不是等待 hdbindexserver 进程在同一节点上重启。

[A] 安装 HANA 系统复制挂钩。挂钩必须安装在两个 HANA 数据库节点上。

提示

只能为 HANA 2.0 实现 SAPHanaSR Python 挂钩。 SAPHanaSR 包必须至少为版本 0.153。

susChkSrv Python 挂钩要求必须安装 SAP HANA 2.0 SP5 和 SAPHanaSR 版本 0.161.1_BF 或更高版本。
1. 在两个节点上停止 HANA。
  
  以 <sapsid>adm 身份运行以下代码：
```
sapcontrol -nr <instance number> -function StopSystem
```
2. 在每个群集节点上调整 global.ini。如果未满足 susChkSrv 挂钩的要求，请从以下参数中删除整个 [ha_dr_provider_suschksrv] 块。
  
  可以使用 action_on_lost 参数调整 susChkSrv 的行为。有效值为 [ ignore | stop | kill | fence ]。
```
# add to global.ini
[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR
execution_order = 3
action_on_lost = fence

[trace]
ha_dr_saphanasr = info
```
  如果指向标准 /usr/share/SAPHanaSR 位置，Python 挂钩代码将通过 OS 更新或包更新自动更新。 HANA 在下一次重启时使用挂钩代码更新。通过使用可选自有路径（如 /hana/shared/myHooks），可将 OS 更新与使用的挂钩版本分离。
[A] 群集要求对于 <SAP SID>adm，在每个群集节点上使用 sudoers 配置。在此示例中，通过创建新文件来实现此目的。

以 root 身份运行以下命令：
```
 cat << EOF > /etc/sudoers.d/20-saphana
 # Needed for SAPHanaSR and susChkSrv Python hooks
 hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
 hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=HN1 --case=fenceMe
 EOF
```
有关实现 SAP HANA 系统复制挂钩的详细信息，请参阅设置 HANA HA/DR 提供程序。
[A] 在两个节点上启动 SAP HANA。

以 <SAP SID>adm 身份运行以下命令：
```
 sapcontrol -nr <instance number> -function StartSystem 
```

[1] 验证是否安装了挂钩。

在活动 HANA 系统复制站点上，以 <SAP SID>adm 身份运行以下命令：

 cdtrace
 awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
 { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*
 # Example output
 # 2021-04-08 22:18:15.877583 ha_dr_SAPHanaSR SFAIL
 # 2021-04-08 22:18:46.531564 ha_dr_SAPHanaSR SFAIL
 # 2021-04-08 22:21:26.816573 ha_dr_SAPHanaSR SOK

验证 susChkSrv 挂钩安装。

在所有 HANA VM 上以 <SAP SID>adm 身份运行以下命令：

 cdtrace
 egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
 # Example output
 # 2022-11-03 18:06:21.116728  susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
 # 2022-11-03 18:06:27.613588  START: indexserver event looks like graceful tenant start
 # 2022-11-03 18:07:56.143766  START: indexserver event looks like graceful tenant start (indexserver started)

创建 SAP HANA 群集资源

首先，创建 HANA 拓扑。

在其中一个 Pacemaker 群集节点上运行以下命令：

sudo crm configure property maintenance-mode=true

# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaTopology \
  operations \$id="rsc_sap2_<HANA SID>_HDB<instance number>-operations" \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="<HANA SID>" InstanceNumber="<instance number>"

sudo crm configure clone cln_SAPHanaTopology_<HANA SID>_HDB<instance number> rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" target-role="Started" interleave="true"

接着，创建 HANA 资源：

重要

在最近的测试中，netcat 因积压工作和只能处理一个连接的限制而停止响应请求。 netcat 资源停止侦听 Azure 负载均衡器请求，并且浮动 IP 变为不可用。

对于现有的 Pacemaker 群集，我们之前建议将 netcat 替换为 socat。现在，建议使用 azure-lb 资源代理，该代理是 resource-agents 包的一部分。需要以下包版本：

对于 SLES 12 SP4/SP5，版本必须至少为 resource-agents-4.3.018.a7fb5035-3.30.1。
对于 SLES 15/15 SP1，版本必须至少为 resource-agents-4.3.0184.6ee15eb2-4.13.1。

进行此更改需要短暂的停机时间。

对于现有的 Pacemaker 群集，如果配置已更改为使用 socat，如 Azure 负载均衡器检测强化中所述，则无需立即切换到 azure-lb 资源代理。

注意

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

# Replace <placeholders> with your instance number, HANA system ID, and the front-end IP address of the Azure load balancer. 

sudo crm configure primitive rsc_SAPHana_<HANA SID>_HDB<instance number> ocf:suse:SAPHana \
  operations \$id="rsc_sap_<HANA SID>_HDB<instance number>-operations" \
  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="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_<HANA SID>_HDB<instance number> rsc_SAPHana_<HANA SID>_HDB<instance number> \
  meta notify="true" clone-max="2" clone-node-max="1" \
  target-role="Started" interleave="true"

sudo crm resource meta msl_SAPHana_<HANA SID>_HDB<instance number> set priority 100

sudo crm configure primitive rsc_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
  meta target-role="Started" \
  operations \$id="rsc_ip_<HANA SID>_HDB<instance number>-operations" \
  op monitor interval="10s" timeout="20s" \
  params ip="<front-end IP address>"

sudo crm configure primitive rsc_nc_<HANA SID>_HDB<instance number> azure-lb port=625<instance number> \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_<HANA SID>_HDB<instance number> rsc_ip_<HANA SID>_HDB<instance number> rsc_nc_<HANA SID>_HDB<instance number>

sudo crm configure colocation col_saphana_ip_<HANA SID>_HDB<instance number> 4000: g_ip_<HANA SID>_HDB<instance number>:Started \
  msl_SAPHana_<HANA SID>_HDB<instance number>:Master  

sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  msl_SAPHana_<HANA SID>_HDB<instance number>

# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHana_<HANA SID>_HDB<instance number>

sudo crm configure property priority-fencing-delay=30

sudo crm configure property maintenance-mode=false
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

重要

建议仅在完成彻底故障转移测试时将 AUTOMATED_REGISTER 设置为 false，以防止失败的主实例自动注册为辅助实例。成功完成故障转移测试后，将 AUTOMATED_REGISTER 设置为 true，这样在接管后系统复制会自动恢复。

确保群集状态为 OK，并且所有资源都已启动。资源在哪个节点上运行并不重要。

sudo crm_mon -r

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

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

在 SAP HANA 2.0 SPS 01 和更高版本中，SAP 允许对 SAP HANA 系统复制使用启用活动/读取的设置。在此场景中，SAP HANA 系统复制的辅助系统可以主动用于读取密集型工作负荷。

若要在群集中支持此设置，需要提供第二个虚拟 IP 地址，使客户端能够访问启用了辅助读取的 SAP HANA 数据库。若要确保辅助复制站点在接管后仍可以访问，群集需要将虚拟 IP 地址与 SAPHana 资源的辅助地址一起移动。

本部分介绍在使用第二个虚拟 IP 地址的 SUSE 高可用性群集中管理启用 HANA 活动/读取的系统复制所需的额外步骤。

在继续之前，请确保已按照前面章节的描述，完全配置了管理 SAP HANA 数据库的 SUSE 高可用性群集。

该示意图显示启用了读取的辅助 IP 的 SAP HANA 高可用性示例。

为启用活动/读取的系统复制设置负载均衡器

若要继续执行有关预配第二个虚拟 IP 的额外步骤，请确保已按照通过 Azure 门户手动部署 Linux VM 所述，配置了 Azure 负载均衡器。

对于“标准”负载均衡器，请在之前创建的同一负载均衡器上完成这些额外步骤。

创建第二个前端 IP 池：
1. 打开负载均衡器，选择前端 IP 池，然后选择“添加”。
2. 输入第二个新前端 IP 池的名称（例如“hana-secondaryIP”）。
3. 将“分配”设置为“静态”并输入 IP 地址（例如，“10.0.0.14”）。
4. 选择“确定”。
5. 创建新前端 IP 池后，请记下前端 IP 地址。
创建运行状况探测：
1. 在负载均衡器中，选择“运行状况探测”，然后选择“添加”。
2. 输入新运行状况探测的名称（例如“hana-secondaryhp”）。
3. 选择 TCP 作为协议，并选择端口 626<实例编号>。将“间隔”值保留设置为 5，将“不正常阈”值设置为 2。
4. 选择“确定”。
创建负载均衡规则：
1. 在负载均衡器中，选择“负载均衡规则”，然后选择“添加”。
2. 输入新负载均衡器规则的名称（例如“hana-secondarylb”）。
3. 选择前面创建的前端 IP 地址、后端池和运行状况探测（例如“hana-secondaryIP”、“hana-backend”和“hana-secondaryhp”）。
4. 选择“HA 端口”。
5. 将空闲超时增大到 30 分钟。
6. 确保启用浮动 IP。
7. 选择“确定”。

设置启用 HANA 活动/读取的系统复制

配置 SAP HANA 2.0 系统复制介绍了配置 HANA 系统复制的步骤。如果部署已启用读取的辅助方案，则在第二个节点上设置系统复制时，请以 <HANA SID>adm 身份运行以下命令：

sapcontrol -nr <instance number> -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> --operationMode=logreplay_readaccess

添加辅助虚拟 IP 地址资源

可以使用以下命令设置第二个虚拟 IP 和适当的共置约束：

crm configure property maintenance-mode=true

crm configure primitive rsc_secip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
 meta target-role="Started" \
 operations \$id="rsc_secip_<HANA SID>_HDB<instance number>-operations" \
 op monitor interval="10s" timeout="20s" \
 params ip="<secondary IP address>"

crm configure primitive rsc_secnc_<HANA SID>_HDB<instance number> azure-lb port=626<instance number> \
 op monitor timeout=20s interval=10 \
 meta resource-stickiness=0

crm configure group g_secip_<HANA SID>_HDB<instance number> rsc_secip_<HANA SID>_HDB<instance number> rsc_secnc_<HANA SID>_HDB<instance number>

crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
 msl_SAPHana_<HANA SID>_HDB<instance number>:Slave 

crm configure property maintenance-mode=false

确保群集状态为 OK，并且所有资源都已启动。第二个虚拟 IP 将与 SAPHana 辅助资源一起在辅助站点上运行。

sudo crm_mon -r

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
# Resource Group: g_secip_HN1_HDB03:
#     rsc_secip_HN1_HDB03       (ocf::heartbeat:IPaddr2):        Started hn1-db-1
#     rsc_secnc_HN1_HDB03       (ocf::heartbeat:azure-lb):       Started hn1-db-1

下一部分介绍要执行的一组典型的故障转移测试。

测试配置了已启用读取的辅助实例的 HANA 群集时的注意事项：

将 SAPHana_<HANA SID>_HDB<instance number> 群集资源迁移到 hn1-db-1 时，第二个虚拟 IP 会移到 hn1-db-0。如果已配置 AUTOMATED_REGISTER="false" 且 HANA 系统复制未自动注册，则第二个虚拟 IP 会在 hn1-db-0 上运行，因为服务器可用，群集服务处于联机状态。
测试服务器故障时，第二个虚拟 IP 资源 (rsc_secip_<HANA SID>_HDB<instance number>) 和 Azure 负载均衡器端口资源 (rsc_secnc_<HANA SID>_HDB<instance number>) 与主要虚拟 IP 资源一起在主服务器上运行。当辅助服务器关闭时，连接到启用读取的 HANA 数据库的应用程序将连接到主 HANA 数据库。此行为是预期行为，因为在辅助服务器不可用时，你不希望连接到已启用读取的 HANA 数据库的应用程序无法访问。
当辅助服务器可用且群集服务处于联机状态时，第二个虚拟 IP 和端口资源会自动转移到辅助服务器，即使 HANA 系统复制可能无法注册为辅助服务器。确保在启动该服务器上的群集服务之前，将辅助 HANA 数据库注册为已启用读取。可以通过设置参数 AUTOMATED_REGISTER="true" 来将 HANA 实例群集资源配置为自动注册辅助副本。
在故障转移和回退过程中，使用第二个虚拟 IP 连接到 HANA 数据库的应用程序的现有连接可能会中断。

测试群集设

本部分介绍如何测试设置。每个测试都假定你已以根身份登录，且 SAP HANA 主实例在 hn1-db-0 VM 上运行。

测试迁移

在开始测试之前，请确保 Pacemaker 没有任何失败的操作（运行 crm_mon -r）、没有任何意外的位置约束（例如迁移测试的遗留内容），并且 HANA 处于同步状态，例如，通过运行 SAPHanaSR-showAttr。

hn1-db-0:~ # SAPHanaSR-showAttr
Sites    srHook
----------------
SITE2    SOK
Global cib-time
--------------------------------
global Mon Aug 13 11:26:04 2018
Hosts    clone_state lpa_hn1_lpt node_state op_mode   remoteHost    roles                            score site  srmode sync_state version                vhost
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    1534159564  online     logreplay nws-hana-vm-1 4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.030.00.1522209842 nws-hana-vm-0
hn1-db-1 DEMOTED     30          online     logreplay nws-hana-vm-0 4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.030.00.1522209842 nws-hana-vm-1

通过运行以下命令，可以迁移 SAP HANA 主节点：

crm resource move msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1 force

该群集会将 SAP HANA 主节点和包含虚拟 IP 地址的组迁移到 hn1-db-1。

迁移完成后，crm_mon -r 输出如以下示例所示：

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Stopped: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
Failed Actions:
* rsc_SAPHana_HN1_HDB03_start_0 on hn1-db-0 'not running' (7): call=84, status=complete, exitreason='none',
    last-rc-change='Mon Aug 13 11:31:37 2018', queued=0ms, exec=2095ms

AUTOMATED_REGISTER="false" 时，该群集不会重启失败的 HANA 数据库，也不会针对 hn1-db-0 上的新主数据库注册该数据库。在这种情况下，请运行以下命令，将 HANA 实例配置为辅助实例：

su - <hana sid>adm

# Stop the HANA instance, just in case it is running
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr <instance number> -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

迁移过程将创建位置约束，需要再次删除这些约束：

# Switch back to root and clean up the failed state
exit
hn1-db-0:~ # crm resource clear msl_SAPHana_<HANA SID>_HDB<instance number>

此外，还需要清理辅助节点资源的状态：

hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

使用 crm_mon -r 监视 HANA 资源的状态。 HANA 在 hn1-db-0 上启动时，输出如以下示例所示：

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

阻止网络通信

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

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

执行防火墙规则以阻止其中一个节点上的通信。

# Execute iptable rule on hn1-db-1 (10.0.0.6) to block the incoming and outgoing traffic to hn1-db-0 (10.0.0.5)
iptables -A INPUT -s 10.0.0.5 -j DROP; iptables -A OUTPUT -d 10.0.0.5 -j DROP

当群集节点无法相互通信时，存在脑裂情况的风险。在这种情况下，群集节点尝试同时相互隔离，从而导致隔离竞赛。

配置隔离设备时，建议配置 pcmk_delay_max 属性。因此，在脑裂场景中，群集会向每个节点上的隔离操作引入随机延迟，最高为 pcmk_delay_max 值。将选择延迟最短的节点进行隔离。

此外，为了确保运行 HANA 主资源的节点优先且在脑裂场景中赢得隔离竞赛，建议在群集配置中设置 priority-fencing-delay 属性。通过启用 priority-fencing-delay 属性，群集会专门在托管 HANA 主资源的节点上引入额外的隔离操作延迟，从而让该节点赢得隔离竞赛。

执行以下命令以删除防火墙规则。

# If the iptables rule set on the server gets reset after a reboot, the rules will be cleared out. In case they have not been reset, please proceed to remove the iptables rule using the following command.
iptables -D INPUT -s 10.0.0.5 -j DROP; iptables -D OUTPUT -d 10.0.0.5 -j DROP

测试 SBD 隔离

可以通过终止 inquisitor 进程来测试 SBD 的设置：

hn1-db-0:~ # ps aux | grep sbd
root       1912  0.0  0.0  85420 11740 ?        SL   12:25   0:00 sbd: inquisitor
root       1929  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014056f268462316e4681b704a9f73 - slot: 0 - uuid: 7b862dba-e7f7-4800-92ed-f76a4e3978c8
root       1930  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014059bc9ea4e4bac4b18808299aaf - slot: 0 - uuid: 5813ee04-b75c-482e-805e-3b1e22ba16cd
root       1931  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-36001405b8dddd44eb3647908def6621c - slot: 0 - uuid: 986ed8f8-947d-4396-8aec-b933b75e904c
root       1932  0.0  0.0  90524 16656 ?        SL   12:25   0:00 sbd: watcher: Pacemaker
root       1933  0.0  0.0 102708 28260 ?        SL   12:25   0:00 sbd: watcher: Cluster
root      13877  0.0  0.0   9292  1572 pts/0    S+   12:27   0:00 grep sbd

hn1-db-0:~ # kill -9 1912

<HANA SID>-db-<database 1> 群集节点将重新启动。 Pacemaker 服务可能不会重启。请确保再次启动它。

测试手动故障转移

可以通过停止 hn1-db-0 节点上的 Pacemaker 服务来测试手动故障转移：

service pacemaker stop

故障转移后，可以再次启动该服务。如果设置了 AUTOMATED_REGISTER="false"，则 hn1-db-0 节点上的 SAP HANA 资源将无法作为辅助资源启动。

在这种情况下，请运行以下命令，将 HANA 实例配置为辅助实例：

service pacemaker start
su - <hana sid>adm

# Stop the HANA instance, just in case it is running
sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1> 

# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

SUSE 测试

重要

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

运行“SAP HANA SR 性能优化方案”指南或“SAP HANA SR 成本优化方案”指南中列出的所有测试用例，具体取决于你的方案。可以在 SLES for SAP 最佳做法中找到列出的指南。

以下测试是“SUSE Linux Enterprise Server for SAP Applications 12 SP1 的 SAP HANA SR 性能优化方案”指南测试说明的副本。如需最新版本，也请阅读指南本身。在开始测试之前，请务必确保 HANA 已同步，并确保 Pacemaker 的配置正确。

在以下测试说明中，我们假设 PREFER_SITE_TAKEOVER="true" 和 AUTOMATED_REGISTER="false"。

注意

以下测试按顺序运行。每个测试取决于前一个测试的退出状态。

测试 1：停止节点 1 上的主数据库。

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

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

在 hn1-db-0 节点上以 <hana sid >adm 身份运行以下命令：

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB stop

Pacemaker 检测到已停止的 HANA 实例，并故障转移到另一个节点。完成故障转移后，hn1-db-0 节点上的 HANA 实例将会停止，因为 Pacemaker 不会自动将该节点注册为 HANA 辅助节点。

运行以下命令将 hn1-db-0 节点注册为辅助节点，并清理已失败的资源：

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

# run as root
hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

测试之后的资源状态：

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

测试 2：停止节点 2 上的主数据库。

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

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

在 hn1-db-1 节点上以 <hana sid >adm 身份运行以下命令：

hn1adm@hn1-db-1:/usr/sap/HN1/HDB01> HDB stop

Pacemaker 检测到已停止的 HANA 实例，并故障转移到另一个节点。完成故障转移后，hn1-db-1 节点上的 HANA 实例将会停止，因为 Pacemaker 不会自动将该节点注册为 HANA 辅助节点。

运行以下命令将 hn1-db-1 节点注册为辅助节点，并清理已失败的资源：

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1

测试之后的资源状态：

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

测试 3：在节点 1 上使主数据库崩溃。

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

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

在 hn1-db-0 节点上以 <hana sid >adm 身份运行以下命令：

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB kill-9

Pacemaker 检测到已终止的 HANA 实例，并故障转移到另一个节点。完成故障转移后，hn1-db-0 节点上的 HANA 实例将会停止，因为 Pacemaker 不会自动将该节点注册为 HANA 辅助节点。

运行以下命令将 hn1-db-0 节点注册为辅助节点，并清理已失败的资源：

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

# run as root
hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

测试之后的资源状态：

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

测试 4：在节点 2 上使主数据库崩溃。

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

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

在 hn1-db-1 节点上以 <hana sid >adm 身份运行以下命令：

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9

Pacemaker 检测到已终止的 HANA 实例，并故障转移到另一个节点。完成故障转移后，hn1-db-1 节点上的 HANA 实例将会停止，因为 Pacemaker 不会自动将该节点注册为 HANA 辅助节点。

运行以下命令将 hn1-db-1 节点注册为辅助节点，并清理已失败的资源。

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1

测试之后的资源状态：

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

测试 5：使主站点节点（节点 1）崩溃。

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

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

在 hn1-db-0 节点上以根身份运行以下命令：

hn1-db-0:~ #  echo 'b' > /proc/sysrq-trigger

Pacemaker 检测到已终止的群集节点，并隔离该节点。隔离节点后，Pacemaker 触发 HANA 实例的接管。重新启动隔离的节点时，Pacemaker 不会自动启动。

运行以下命令以启动 Pacemaker，清理 hn1-db-0 节点的 SBD 消息，将 hn1-db-0 节点注册为辅助节点，并清理失败的资源：

# run as root
# list the SBD device(s)
hn1-db-0:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-0:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-0 clear

hn1-db-0:~ # systemctl start pacemaker

# run as <hana sid>adm
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

# run as root
hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

测试之后的资源状态：

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

测试 6：使辅助站点节点（节点 2）崩溃。

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

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

在 hn1-db-1 节点上以根身份运行以下命令：

hn1-db-1:~ #  echo 'b' > /proc/sysrq-trigger

Pacemaker 检测到已终止的群集节点，并隔离该节点。隔离节点后，Pacemaker 触发 HANA 实例的接管。重新启动隔离的节点时，Pacemaker 不会自动启动。

运行以下命令以启动 Pacemaker，清理 hn1-db-1 节点的 SBD 消息，将 hn1-db-1 节点注册为辅助节点，并清理失败的资源：

# run as root
# list the SBD device(s)
hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear

hn1-db-1:~ # systemctl start pacemaker

# run as <hana sid>adm
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1

测试之后的资源状态：

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
</code></pre>

测试 7：停止节点 2 上的辅助数据库。

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

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

在 hn1-db-1 节点上以 <hana sid >adm 身份运行以下命令：

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stop

Pacemaker 检测到已停止的 HANA 实例，并将 hn1-db-1 节点上的资源标记为失败。 Pacemaker 自动重启 HANA 实例。

运行以下命令来清理失败状态：

# run as root
hn1-db-1>:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1

测试之后的资源状态：

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

测试 8：使节点 2 上的辅助数据库崩溃。

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

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

在 hn1-db-1 节点上以 <hana sid >adm 身份运行以下命令：

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9

Pacemaker 检测到已终止的 HANA 实例，并将 hn1-db-1 节点上的资源标记为失败。运行以下命令来清理失败状态。然后，Pacemaker 自动重启 HANA 实例。

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> HN1-db-1

测试之后的资源状态：

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

测试 9：使运行辅助 HANA 数据库的辅助站点节点（节点 2）崩溃。

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

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

在 hn1-db-1 节点上以根身份运行以下命令：

hn1-db-1:~ # echo b > /proc/sysrq-trigger

Pacemaker 检测到已终止的群集节点，并已隔离该节点。重新启动隔离的节点时，Pacemaker 不会自动启动。

运行以下命令启动 Pacemaker，清理 hn1-db-1 节点的 SBD 消息，并清理已失败的资源：

# run as root
# list the SBD device(s)
hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear

hn1-db-1:~ # systemctl start pacemaker  

hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1

测试之后的资源状态：

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

测试 10：使主数据库索引服务器崩溃

仅当已设置 susChkSrv 挂钩（如实现 HANA 挂钩 SAPHanaSR 和 susChkSrv 中所述）时，此测试才相关。

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

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

在 hn1-db-0 节点上以根身份运行以下命令：

hn1-db-0:~ # killall -9 hdbindexserver

当索引服务器终止时，susChkSrv 挂钩检测到事件，并触发一个操作来隔离“hn1-db-0”节点并启动接管进程。

运行以下命令将 hn1-db-0 节点注册为辅助节点，并清理已失败的资源：

# run as <hana sid>adm
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

# run as root
hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

测试之后的资源状态：

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

可以通过导致辅助节点上的索引服务器崩溃来执行类似的测试用例。如果索引服务器崩溃，susChkSrv 挂钩将识别这种情况，并启动一个操作来隔离辅助节点。

SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

规划 SAP HANA 高可用性

准备基础结构

通过 Azure 门户手动部署 Linux VM

配置 Azure 负载均衡器

创建 Pacemaker 群集

安装 SAP HANA

配置 SAP HANA 2.0 系统复制

配置 SAP HANA 1.0 系统复制

实现 HANA 挂钩 SAPHanaSR 和 susChkSrv

创建 SAP HANA 群集资源

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

为启用活动/读取的系统复制设置负载均衡器

设置启用 HANA 活动/读取的系统复制

添加辅助虚拟 IP 地址资源

测试群集设

测试迁移

阻止网络通信

测试 SBD 隔离

测试手动故障转移

SUSE 测试

后续步骤

其他资源