Alta disponibilidad de SAP HANA en máquinas virtuales de Azure en Red Hat Enterprise Linux

Artículo
12/04/2024

Para el desarrollo local, puede usar la replicación del sistema de HANA o el almacenamiento compartido para establecer alta disponibilidad para SAP HANA. En las máquinas virtuales Azure, la replicación del sistema HANA en Azure es actualmente la única función de HA compatible.

La replicación de SAP HANA se realiza con un nodo principal y al menos uno secundario. Los cambios en los datos del nodo principal se replican en los secundarios de forma sincrónica o asincrónica.

En este artículo se describe cómo implementar y configurar las máquinas virtuales, instalar la plataforma del clúster e instalar y configurar la replicación del sistema de SAP HANA.

En las configuraciones de ejemplo, se usan los comandos de instalación, el número de instancia 03 y el identificador del sistema de HANA HN1.

Requisitos previos

Lea primero las notas y los documentos de SAP siguientes:

Nota de SAP 1928533, que incluye:
- La lista de tamaños de máquina virtual de Azure que se admiten para la implementación del software de SAP.
- Información importante sobre capacidad para los tamaños de máquina virtual de Azure.
- Las combinaciones admitidas de software y sistema operativo (SO) y base de datos de SAP.
- La versión del kernel de SAP necesaria para Windows y Linux en Microsoft Azure.
La nota de SAP 2015553 enumera los requisitos previos para las implementaciones de software de SAP admitidas por SAP en Azure.
La nota de SAP 2002167 recomienda la configuración del sistema operativo para Red Hat Enterprise Linux.
La nota de SAP 2009879 contiene las instrucciones de SAP HANA para Red Hat Enterprise Linux.
La nota de SAP 3108302 contiene las instrucciones de SAP HANA para Red Hat Enterprise Linux 9.x.
La nota de SAP 2178632 contiene información detallada sobre todas las métricas de supervisión notificadas para SAP en Azure.
La nota de SAP 2191498 incluye la versión de SAP Host Agent necesaria para Linux en Azure.
La nota de SAP 2243692 incluye información acerca de las licencias de SAP en Linux en Azure.
La nota de SAP 1999351 contiene más información de solución de problemas sobre la extensión de supervisión mejorada de Azure para SAP.
La WIKI de la comunidad SAP contiene todas las notas de SAP que se necesitan para Linux.
Planeación e implementación de Azure Virtual Machines para SAP en Linux
Implementación de Azure Virtual Machines para SAP en Linux (este artículo)
Implementación de DBMS de Azure Virtual Machines para SAP en Linux
Replicación del sistema de SAP HANA en un clúster de Pacemaker
Documentación general de RHEL:
Documentación de RHEL específica para Azure:

Información general

Para lograr alta disponibilidad, SAP HANA se instala en dos máquinas virtuales. Los datos se replican mediante la replicación del sistema de HANA.

Diagrama que muestra información general sobre la alta disponibilidad de SAP HANA.

En la instalación de la replicación del sistema de SAP HANA se usa un nombre de host virtual dedicado y direcciones IP virtuales. En Azure, se requiere un equilibrador de carga para usar una dirección IP virtual. La configuración presentada muestra un equilibrador de carga con:

Dirección IP de front-end: 10.0.0.13 para hn1-db
Puerto de sondeo: 62503

Preparación de la infraestructura

Azure Marketplace contiene imágenes calificadas para SAP HANA con el complemento de alta disponibilidad, que puede usar para implementar nuevas máquinas virtuales mediante varias versiones de Red Hat.

Implementación manual de VM de Linux mediante Azure Portal

En este documento se supone que ya ha implementado un grupo de recursos, una red virtual de Azure y una subred.

Implemente máquinas virtuales para SAP HANA. Elija una imagen de RHEL adecuada que sea compatible con el sistema HANA. Puede implementar una máquina virtual en cualquiera de las opciones de disponibilidad: conjunto de escalado de máquinas virtuales, zona de disponibilidad o conjunto de disponibilidad.

Importante

Asegúrese de que el sistema operativo que selecciona está certificado por SAP para SAP HANA en los tipos específicos de máquinas virtuales que tiene previsto usar en su implementación. Puede buscar los tipos de máquina virtual certificados por SAP HANA y sus versiones del sistema operativo en Plataformas IaaS certificadas para SAP HANA. Asegúrese de consultar los detalles del tipo de máquina virtual para obtener la lista completa de versiones de SO compatibles con SAP HANA para el tipo de máquina virtual específico.

Configurar Azure Load Balancer

Durante la configuración de la máquina virtual, tiene una opción para crear o seleccionar salir del equilibrador de carga en la sección de redes. Siga estos pasos para configurar el equilibrador de carga estándar para la configuración de alta disponibilidad de la base de datos de HANA.

Siga los pasos descritos en Creación de un equilibrador de carga para configurar un equilibrador de carga estándar para un sistema SAP de alta disponibilidad mediante Azure Portal. Durante la configuración del equilibrador de carga, tenga en cuenta los siguientes puntos:

Configuración de IP de front-end: cree una dirección IP de front-end. Seleccione el mismo nombre de red virtual y subred que las máquinas virtuales de la base de datos.
Grupo de back-end: cree un grupo de back-end y agregue máquinas virtuales de base de datos.
Reglas de entrada: cree una regla de equilibrio de carga. Siga los mismos pasos para ambas reglas de equilibrio de carga.
- Dirección IP de front-end: seleccione una dirección IP de front-end.
- Grupo de back-end: seleccione un grupo de back-end.
- Puertos de alta disponibilidad: seleccione esta opción.
- Protocolo: seleccione TCP.
- Sondeo de estado: cree un sondeo de estado con los detalles siguientes:
  - Protocolo: seleccione TCP.
  - Puerto: por ejemplo, 625<instance-no.>.
  - Intervalo: escriba 5.
  - Umbral de sondeo: escriba 2.
- Tiempo de espera de inactividad (minutos): Escriba 30.
- Habilitar IP flotante: seleccione esta opción.

Nota:

No se respeta la propiedad de configuración del sondeo de estado numberOfProbes, también conocida como Umbral incorrecto en el portal. Para controlar el número de sondeos consecutivos correctos o erróneos, establezca la propiedad probeThreshold en 2. Actualmente, no es posible establecer esta propiedad mediante Azure Portal, por lo que debe usar la CLI de Azure o el comando de 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

Expanda para ver el código completo de la 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

Expanda para ver el código completo de 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

Para obtener más información sobre los puertos necesarios para SAP HANA, lea el capítulo Connections to Tenant Databases (Conexiones a las bases de datos de inquilino) de la guía SAP HANA Tenant Databases (Bases de datos de inquilino de SAP HANA) o la nota de SAP 2388694.

Nota:

Cuando las máquinas virtuales sin direcciones IP públicas se colocan en el grupo de back-end de una instancia interna (sin dirección IP pública) de Azure Standard Load Balancer, no hay conectividad saliente a Internet, a menos que se realice una configuración adicional para permitir el enrutamiento a puntos de conexión públicos. Para obtener más información sobre cómo conseguir la conectividad saliente, consulte Conectividad de punto de conexión público para máquinas virtuales con Azure Standard Load Balancer en escenarios de alta disponibilidad de SAP.

Importante

No habilite las marcas de tiempo TCP en VM de Azure que se encuentren detrás de Azure Load Balancer. La habilitación de las marcas de tiempo de TCP podría provocar un error en los sondeos de estado. Establezca el parámetro net.ipv4.tcp_timestamps en 0. Para obtener más información, consulte Sondeos de estado de Load Balancer y Nota de SAP 2382421.

Instalación de SAP HANA

En los pasos de esta sección se usan los siguientes prefijos:

[A] : el paso se aplica a todos los nodos.
[1] : el paso solo se aplica al nodo 1.
[2] : el paso solo se aplica al nodo 2 del clúster de Pacemaker.

[A] Configuración del diseño de disco: Administrador de volúmenes lógicos (LVM) .

Se recomienda usar LVM para volúmenes que almacenen datos y archivos de registro. El siguiente ejemplo supone que las máquinas virtuales tienen cuatro discos de datos conectados que se utilizan para crear dos volúmenes.

Enumera todos los discos disponibles:
```
ls /dev/disk/azure/scsi1/lun*
```
Ejemplo:
```
/dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2  /dev/disk/azure/scsi1/lun3
```
Cree volúmenes físicos para todos los discos que quiera usar:
```
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
```
Cree un grupo de volúmenes para los archivos de datos. Use un grupo de volúmenes para los archivos de registro y otro para el directorio compartido de 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
sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3
```
Cree los volúmenes lógicos. Cuando se usa lvcreate sin el modificador -i, se crea un volumen lineal. Se recomienda crear un volumen seccionado para mejorar el rendimiento de E/S. Alinee los tamaños de sección con los valores documentados en las configuraciones de almacenamiento de máquinas virtuales de SAP HANA. El argumento -i debe ser el número de volúmenes físicos subyacentes y -I, el tamaño de la sección.

En este documento, se usan dos volúmenes físicos para el volumen de datos, por lo que el modificador -i se establece en 2. El tamaño de sección para el volumen de datos es 256 KiB. Se usa un volumen físico para el volumen de registro, así que no se usa explícitamente ningún modificador -i o -I para los comandos del volumen de registro.

Importante

Use el modificador -i y establézcalo en el número del volumen físico subyacente cuando se usa más de un volumen físico para cada volumen de datos, de registro o compartido. Use el modificador -I para especificar el tamaño de las secciones al crear un volumen seccionado. Consulte Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA para conocer las configuraciones de almacenamiento recomendadas, incluidos los tamaños de sección y el número de discos. Los siguientes ejemplos de diseño no cumplen necesariamente las directrices de rendimiento de un tamaño de sistema determinado. Sólo son para ilustración.
```
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 lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_shared
```
No monte los directorios mediante la emisión de comandos de montaje. En su lugar, escriba las configuraciones en fstab y emita una final mount -a para validar la sintaxis. Empiece por crear los directorios de montaje para cada volumen:
```
sudo mkdir -p /hana/data
sudo mkdir -p /hana/log
sudo mkdir -p /hana/shared
```
A continuación, cree fstab entradas para los tres volúmenes lógicos insertando las líneas siguientes en el /etc/fstab archivo:

/dev/mapper/vg_hana_data_HN1-hana_data /hana/data xfs defaults,nofail 0 2 /dev/mapper/vg_hana_log_HN1-hana_log /hana/log xfs defaults,nofail 0 2 /dev/mapper/vg_hana_shared_HN1-hana_shared /hana/shared xfs defaults,nofail 0 2

Por último, monte todos los volúmenes nuevos a la vez:
```
sudo mount -a
```
[A] Configurar la resolución de nombres de host para todos los hosts.

Puede usar un servidor DNS o modificar el /etc/hosts archivo en todos los nodos mediante la creación de entradas para todos los nodos como este en /etc/hosts:

10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1
[A] Realice RHEL para la configuración de HANA.

Configure RHEL tal como se describe en las siguientes notas:
- 2447641: paquetes adicionales necesarios para instalar SAP HANA SPS 12 en RHEL 7.X
- 2292690 - SAP HANA DB: Recommended OS settings for RHEL 7 (2292690 - SAP HANA DB: configuraciones de sistema operativo recomendadas para RHEL 7)
- 2777782 - SAP HANA DB: Recommended OS settings for RHEL 8 (SAP HANA DB: configuración recomendada del sistema operativo para RHEL 8).
- 2455582 - Linux: Running SAP applications compiled with GCC 6.x (Nota de compatibilidad de SAP n.º 2455582 - Linux: Ejecución de aplicaciones SAP compiladas con GCC 6.x)
- 2593824 - Linux: Ejecución de aplicaciones SAP compiladas con GCC 7.x
- 2886607 - Linux: Ejecución de aplicaciones SAP compiladas con GCC 9.x
[A] Instale SAP HANA siguiendo la documentación de SAP.

[A] Configurar el firewall.

Cree la regla de firewall para el puerto de sondeo de Azure Load Balancer.

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

Configuración de la Replicación del sistema de SAP HANA 2.0

En los pasos de esta sección se usan los siguientes prefijos:

[A] : el paso se aplica a todos los nodos.
[1] : el paso solo se aplica al nodo 1.
[2] : el paso solo se aplica al nodo 2 del clúster de Pacemaker.

[A] Configurar el firewall.

Cree reglas de firewall para permitir la replicación del sistema de HANA y el tráfico del cliente. Los puertos necesarios se enumeran en TCP/IP Ports of All SAP Products (Puertos TCP/IP de todos los productos de SAP). Los siguientes comandos son simplemente un ejemplo para permitir la replicación del sistema de HANA 2.0 y el tráfico del cliente a las bases de datos SYSTEMDB, HN1 y NW1.
```
 sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp --permanent
 sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp
```

[1] Creación de la base de datos de inquilino.

Ejecute el siguiente comando como <hanasid>adm:

hdbsql -u SYSTEM -p "[passwd]" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "<passwd>"'

[1] Configuración de la replicación del sistema en el primer nodo.

Haga una copia de seguridad de las bases de datos como <hanasid>adm:

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')"
hdbsql -d NW1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"

Copie los archivos PKI de sistema en el sitio secundario:

scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT   hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

Cree el sitio principal:

hdbnsutil -sr_enable --name=SITE1

[2] Configuración de la replicación del sistema en el segundo nodo.

Registre el segundo nodo para iniciar la replicación del sistema. Ejecute el siguiente comando como <hanasid>adm:
```
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
```
[2] Inicie HANA.

Ejecute el siguiente comando como <hanasid> adm para iniciar HANA:
```
sapcontrol -nr 03 -function StartSystem
```

[1] Comprobación del estado de replicación.

Compruebe el estado de replicación y espere hasta que todas las bases de datos estén sincronizadas. Si el estado sigue siendo DESCONOCIDO, compruebe la configuración del firewall.

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 | hn1-db-0 | 30301 | nameserver   |         1 |       1 | SITE1     | hn1-db-1  |     30301 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hn1-db-0 | 30307 | xsengine     |         2 |       1 | SITE1     | hn1-db-1  |     30307 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | NW1      | hn1-db-0 | 30340 | indexserver  |         2 |       1 | SITE1     | hn1-db-1  |     30340 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hn1-db-0 | 30303 | indexserver  |         3 |       1 | SITE1     | hn1-db-1  |     30303 |         2 | SITE2     | 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: SITE1

Creación de un clúster de Pacemaker

Siga los pasos de Configuración de Pacemaker en Red Hat Enterprise Linux en Azure para crear un clúster de Pacemaker básico para este servidor HANA.

Importante

Con el marco de inicio de SAP basado en sistema, las instancias de SAP HANA ahora se pueden administrar mediante systemd. La versión mínima necesaria de Red Hat Enterprise Linux (RHEL) es RHEL 8 para SAP. Como se describe en la Nota de SAP 3189534, las nuevas instalaciones de la revisión 70 o posteriores de SAP HANA SPS07, o las actualizaciones de los sistemas HANA a HANA 2.0 SPS07 revisión 70 o posterior, el marco de inicio de SAP se registrará automáticamente con systemd.

Al usar soluciones de alta disponibilidad para administrar la replicación del sistema de SAP HANA en combinación con las instancias de SAP HANA habilitadas para el sistema (consulte la Nota de SAP 3189534), se necesitan pasos adicionales para asegurarse de que el clúster de alta disponibilidad pueda administrar la instancia de SAP sin interferencias del sistema. Por lo tanto, para el sistema de SAP HANA integrado con systemd, deben seguirse pasos adicionales descritos en Red Hat KBA 7029705 en todos los nodos del clúster.

Implementación de enlaces de replicación del sistema de SAP HANA

Este importante paso optimiza la integración con el clúster y mejora la detección cuando es necesaria una conmutación por error del clúster. Es obligatorio para que la operación de clúster sea correcta para habilitar el enlace SAPHanaSR. Se recomienda encarecidamente configurar los enlaces de Python SAPHanaSR y ChkSrv.

[A] Instale los agentes de recursos de SAP HANA en todos los nodos. Asegúrese de habilitar un repositorio que contenga el paquete. No es necesario habilitar más repositorios si usa una imagen habilitada para alta disponibilidad de RHEL 8.x o superior.
```
# Enable repository that contains SAP HANA resource agents
sudo subscription-manager repos --enable="rhel-sap-hana-for-rhel-7-server-rpms"

sudo dnf install -y resource-agents-sap-hana
```
Nota:

Para RHEL 8.x y RHEL 9.x, compruebe que el paquete resource-agents-sap-hana instalado es la versión 0.162.3-5 o posterior.
[A] Instale HANA system replication hooks. La configuración de los enlaces de replicación debe instalarse en ambos nodos de base de datos de HANA.
1. Detenga HANA en ambos nodos. Ejecute como <sid>adm.
```
sapcontrol -nr 03 -function StopSystem
```
2. Ajuste global.ini en cada uno de los nodos del clúster.
```
[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR/srHook
execution_order = 1

[ha_dr_provider_chksrv]
provider = ChkSrv
path = /usr/share/SAPHanaSR/srHook
execution_order = 2
action_on_lost = kill

[trace]
ha_dr_saphanasr = info
ha_dr_chksrv = info
```
Si apunta el parámetro path a la ubicación de /usr/share/SAPHanaSR/srHook predeterminada, el código de enlace de Python se actualiza automáticamente a través de actualizaciones del sistema operativo o actualizaciones de paquetes. HANA usa las actualizaciones de código de enlace cuando se reinicie la próxima vez. Con una ruta de acceso propia opcional, como /hana/shared/myHooks, puede desacoplar las actualizaciones del sistema operativo de la versión de enlace que usará HANA.

Puede ajustar el comportamiento del enlace ChkSrv mediante el parámetro action_on_lost. Los valores válidos son [ignore | stop | kill].

[A] El cluster requiere configuración sudoers en cada nodo del cluster para <sid>adm. En este ejemplo, esto se consigue mediante la creación de un archivo nuevo. Use el visudo comando para editar el 20-saphana archivo desplegable como root.

sudo visudo -f /etc/sudoers.d/20-saphana

Inserte las líneas siguientes y, a continuación, guarde:

Cmnd_Alias SITE1_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITE1_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SFAIL -t crm_config -s SAPHanaSR
Cmnd_Alias SITE2_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITE2_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SFAIL -t crm_config -s SAPHanaSR
hn1adm ALL=(ALL) NOPASSWD: SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL
Defaults!SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL !requiretty

[A] Inicie SAP HANA en ambos nodos. Ejecute como <sid>adm.
```
sapcontrol -nr 03 -function StartSystem 
```

[1] Compruebe la instalación del enlace SRHanaSR. Ejecute como <sid>adm en el sitio activo de replicación del sistema HANA.

 cdtrace
 awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
 { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*

 # 2021-04-12 21:36:16.911343 ha_dr_SAPHanaSR SFAIL
 # 2021-04-12 21:36:29.147808 ha_dr_SAPHanaSR SFAIL
 # 2021-04-12 21:37:04.898680 ha_dr_SAPHanaSR SOK

[1] Comprobar la instalación del enlace ChkSrv. Ejecute como <sid>adm en el sitio activo de replicación del sistema HANA.
```
 cdtrace
 tail -20 nameserver_chksrv.trc
```

Para obtener más información sobre la implementación de los enlaces de SAP HANA, consulte Habilitación del enlace srConnectionChanged() de SAP HANA y Habilitación del enlace srServiceStateChanged() de SAP HANA para la acción de error del proceso hdbindexserver (opcional).

Creación de recursos de clúster de SAP HANA

Cree la topología de HANA. Ejecute los comandos siguientes en uno de los nodos del clúster de Pacemaker. A lo largo de estas instrucciones, asegúrese de sustituir el número de instancia, el identificador del sistema de HANA, las direcciones IP y los nombres del sistema, si procede.

sudo pcs property set maintenance-mode=true

sudo pcs resource create SAPHanaTopology_HN1_03 SAPHanaTopology SID=HN1 InstanceNumber=03 \
op start timeout=600 op stop timeout=300 op monitor interval=10 timeout=600 \
clone clone-max=2 clone-node-max=1 interleave=true

A continuación, cree los recursos de HANA.

Nota:

Este artículo contiene referencias a un término que Microsoft ya no utiliza. Cuando se elimine el término del software, se eliminará también de este artículo.

Si va a compilar un clúster en RHEL 7.x, use los comandos siguientes:

sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
  op start timeout=3600 op stop timeout=3600 \
  op monitor interval=61 role="Slave" timeout=700 \
  op monitor interval=59 role="Master" timeout=700 \
  op promote timeout=3600 op demote timeout=3600 \
  master notify=true clone-max=2 clone-node-max=1 interleave=true

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-master symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-master 4000

sudo pcs resource defaults resource-stickiness=1000
sudo pcs resource defaults migration-threshold=5000

sudo pcs property set maintenance-mode=false

Si va a compilar un clúster en RHEL 8.x/9.x, use los comandos siguientes:

sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
  op start timeout=3600 op stop timeout=3600 \
  op monitor interval=61 role="Slave" timeout=700 \
  op monitor interval=59 role="Master" timeout=700 \
  op promote timeout=3600 op demote timeout=3600 \
  promotable notify=true clone-max=2 clone-node-max=1 interleave=true

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-clone symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-clone 4000

sudo pcs resource defaults update resource-stickiness=1000
sudo pcs resource defaults update migration-threshold=5000

sudo pcs property set maintenance-mode=false

Para configurar priority-fencing-delay para SAP HANA (aplicable solo a partir de pacemaker-2.0.4-6.el8 o superior), es necesario ejecutar los siguientes comandos.

Nota:

Si tiene un clúster de dos nodos, puede configurar la priority-fencing-delay propiedad del clúster. Esta propiedad introduce un retraso adicional en la limitación de un nodo que tiene una prioridad de recurso total mayor cuando se produce un escenario de cerebro dividido. Para más información, consulte ¿Puede Pacemaker cercar el nodo de clúster con los recursos en ejecución más pequeños?.

La propiedad priority-fencing-delay es aplicable a la versión pacemaker-2.0.4-6.el8 o posterior. Si está configurando priority-fencing-delay en un clúster existente, asegúrese de anular la pcmk_delay_max opción en el dispositivo de barrera.

sudo pcs property set maintenance-mode=true

sudo pcs resource defaults update priority=1
sudo pcs resource update SAPHana_HN1_03-clone meta priority=10

sudo pcs property set priority-fencing-delay=15s

sudo pcs property set maintenance-mode=false

Importante

Es una buena idea establecer AUTOMATED_REGISTER en false, mientras se realizan pruebas de conmutación por error, para evitar que una instancia principal con errores se registre automáticamente como secundaria. Después de las pruebas, como procedimiento recomendado, establezca AUTOMATED_REGISTER en true para que, después de la adquisición, la replicación del sistema pueda reanudarse automáticamente.

Asegúrese de que el estado del clúster sea correcto y que todos los recursos se hayan iniciado. El nodo en el que se ejecutan los recursos no es importante.

Nota:

Los tiempos de espera de la configuración anterior son solo ejemplos y puede ser necesario adaptarlos a la configuración específica de HANA. Por ejemplo, puede que necesite aumentar el tiempo de espera de inicio si la base de datos de SAP HANA tarda más en iniciarse.

Use el comando sudo pcs status para comprobar el estado de los recursos del clúster creados:

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# azure_fence     (stonith:fence_azure_arm):      Started hn1-db-0
#  Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
#      Started: [ hn1-db-0 hn1-db-1 ]
#  Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
#      Masters: [ hn1-db-0 ]
#      Slaves: [ hn1-db-1 ]
#  Resource Group: g_ip_HN1_03
#      nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
#      vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Configuración de la replicación del sistema activa/habilitada para lectura de HANA en el clúster de Pacemaker

A partir de SAP HANA 2.0 SPS 01, SAP permite el uso de configuraciones activas/habilitadas para lectura para la replicación del sistema de SAP HANA, donde los sistemas secundarios de la replicación del sistema de SAP HANA se pueden usar activamente para cargas de trabajo de lectura intensiva.

Para admitir esta configuración en un clúster, se requiere una segunda dirección IP virtual, lo que permite a los clientes acceder a la base de datos de SAP HANA habilitada para lectura secundaria. Para garantizar que todavía se puede tener acceso al sitio de replicación secundario tras una adquisición, el clúster debe mover la dirección IP virtual con el sistema secundario del recurso SAPHana.

Esta sección describe los demás pasos necesarios para gestionar la replicación del sistema activo/de lectura de HANA en un clúster Red Hat HA con una segunda IP virtual.

Antes de continuar, asegúrese de que ha configurado completamente el clúster de alta disponibilidad de Red Hat que administra una base de datos de SAP HANA, como se describe en los segmentos anteriores de la documentación.

Diagrama que muestra la alta disponibilidad de SAP HANA con secundario habilitado para lectura.

Configuración adicional en Azure Load Balancer para la configuración activa/habilitada para lectura

Para continuar con más pasos sobre el aprovisionamiento de una segunda dirección IP virtual, asegúrese de que ha configurado Azure Load Balancer como se describe en la sección Implementación manual de máquinas virtuales Linux mediante Azure Portal.

Para el equilibrador de carga estándar, siga los pasos adicionales que se indican a continuación en el mismo equilibrador de carga que creó en la sección anterior.

a. Crear un segundo grupo de direcciones IP de front-end:
- Abra el equilibrador de carga, seleccione frontend IP pool (Grupo de direcciones IP de front-end) y haga clic en Agregar.
- Escriba el nombre del segundo grupo de direcciones IP de front-end (por ejemplo, hana-secondaryIP).
- Establezca Asignación en Estática y escriba la dirección IP (por ejemplo, 10.0.0.14).
- Seleccione Aceptar.
- Una vez creado el nuevo grupo de direcciones IP de front-end, anote la dirección IP del grupo.
b. Cree un sondeo de estado:
- Abra el equilibrador de carga, seleccione Sondeos de estado y haga clic en Agregar.
- Escriba el nombre del sondeo de estado nuevo (por ejemplo hana-secondaryhp).
- Seleccione TCP como el protocolo y el puerto 62603. Mantenga el valor de Intervalo en 5 y el valor de Umbral incorrecto en 2.
- Seleccione Aceptar.
c. Cree las reglas de equilibrio de carga:
- Abra el equilibrador de carga, seleccione Reglas de equilibrio de carga y haga clic en Agregar.
- Escriba el nombre de la nueva regla del equilibrador de carga (por ejemplo, hana-secondarylb).
- Seleccione la dirección IP de front-end, el grupo de back-end y el sondeo de estado que creó anteriormente (por ejemplo, hana-secondaryIP, hana-backend y hana-secondaryhp).
- Seleccione Puertos HA.
- Asegúrese de habilitar la dirección IP flotante.
- Seleccione Aceptar.

Configuración de la replicación del sistema HANA activo/habilitado para lectura

Los pasos para configurar la replicación del sistema de HANA se describen en la sección Configuración de la replicación del sistema SAP HANA 2.0. Si va a implementar un escenario secundario habilitado para lectura, mientras configura la replicación del sistema en el segundo nodo, ejecute el siguiente comando como hanasidadm:

sapcontrol -nr 03 -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 --operationMode=logreplay_readaccess

Adición de un recurso de dirección IP virtual secundaria para una configuración activa/habilitada para lectura

La segunda dirección IP virtual y la restricción de coubicación adecuada se pueden configurar con los siguientes comandos:

pcs property set maintenance-mode=true

pcs resource create secvip_HN1_03 ocf:heartbeat:IPaddr2 ip="10.40.0.16"
pcs resource create secnc_HN1_03 ocf:heartbeat:azure-lb port=62603
pcs resource group add g_secip_HN1_03 secnc_HN1_03 secvip_HN1_03

pcs constraint location g_secip_HN1_03 rule score=INFINITY hana_hn1_sync_state eq SOK and hana_hn1_roles eq 4:S:master1:master:worker:master
pcs constraint location g_secip_HN1_03 rule score=4000 hana_hn1_sync_state eq PRIM and hana_hn1_roles eq 4:P:master1:master:worker:master

# Set the priority to primary IPaddr2 and azure-lb resource if priority-fencing-delay is configured
sudo pcs resource update vip_HN1_03 meta priority=5
sudo pcs resource update nc_HN1_03 meta priority=5

pcs property set maintenance-mode=false

Asegúrese de que el estado del clúster sea el correcto y que se iniciaron todos los recursos. La segunda dirección IP virtual se ejecutará en el sitio secundario junto con el recurso secundario SAPHana.

sudo pcs status

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full List of Resources:
#   rsc_hdb_azr_agt     (stonith:fence_azure_arm):      Started hn1-db-0
#   Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]:
#     Started: [ hn1-db-0 hn1-db-1 ]
#   Clone Set: SAPHana_HN1_03-clone [SAPHana_HN1_03] (promotable):
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
#   Resource Group: g_ip_HN1_03:
#     nc_HN1_03         (ocf::heartbeat:azure-lb):      Started hn1-db-0
#     vip_HN1_03        (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#   Resource Group: g_secip_HN1_03:
#     secnc_HN1_03      (ocf::heartbeat:azure-lb):      Started hn1-db-1
#     secvip_HN1_03     (ocf::heartbeat:IPaddr2):       Started hn1-db-1

En la siguiente sección puede encontrar el conjunto típico de pruebas de conmutación por error que se va a ejecutar.

Tenga en cuenta el comportamiento de la segunda dirección IP virtual mientras prueba un clúster de HANA habilitado para lectura:

Al migrar el recurso de clúster SAPHana_HN1_03 al sitio secundario hn1-db-1, la segunda dirección IP virtual se seguirá ejecutando en el mismo sitio hn1-db-1. Si ha establecido AUTOMATED_REGISTER="true" para el recurso y la replicación del sistema HANA se registra automáticamente en hn1-db-0, la segunda dirección IP virtual también se mueve a hn1-db-0.
Al probar el bloqueo del servidor, los recursos de la segunda IP virtual (secvip_HN1_03) y el recurso de puerto de Azure Load Balancer (secnc_HN1_03) se ejecutarán en el servidor principal junto con los recursos de la IP virtual principal. Mientras el servidor secundario está inactivo, las aplicaciones que están conectadas a la base de datos de HANA habilitada para lectura se conectarán a la base de datos de HANA principal. El comportamiento es el esperado, ya que no desea que las aplicaciones que están conectadas a la base de datos de HANA habilitada para lectura sean inaccesibles mientras el servidor secundario de hora no esté disponible.
Durante la conmutación por error y la recuperación de la segunda dirección IP virtual, es posible que se interrumpan las conexiones existentes en las aplicaciones que utilizan la segunda IP virtual para conectarse a la base de datos HANA.

La configuración maximiza el tiempo durante el que se asignará el segundo recurso de IP virtual a un nodo en el que se ejecuta una instancia de SAP HANA correcta.

Prueba de la configuración del clúster

En esta sección se describe cómo se puede probar la configuración. Antes de iniciar una prueba, asegúrese de que Pacemaker no tiene ninguna acción con error (a través del estado de pcs), no hay restricciones de ubicación inesperadas (por ejemplo, restos de una prueba de migración) y que la replicación del sistema de HANA está en estado de sincronización, por ejemplo, con systemReplicationStatus.

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

Prueba de la migración

Estado del recurso antes de iniciar la prueba:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Puede migrar el nodo maestro de SAP HANA con el siguiente comando:

# On RHEL 7.x
pcs resource move SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource move SAPHana_HN1_03-clone --master

El clúster migraría el nodo maestro de SAP HANA y el grupo que contiene la dirección IP virtual a hn1-db-1.

Una vez finalizada la migración, la sudo pcs status salida es similar a la siguiente:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Con AUTOMATED_REGISTER="false", el clúster no reiniciaría la base de datos de HANA con errores ni la registraría en la nueva base de datos principal en hn1-db-0. En este caso, configure la instancia de HANA como secundaria mediante la ejecución de estos comandos, como hn1adm:

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

La migración crea restricciones de ubicación que deben eliminarse de nuevo. Ejecute el siguiente comando como raíz, o a través desudo:

pcs resource clear SAPHana_HN1_03-master

Supervise el estado del recurso de HANA mediante pcs status. Después de iniciar HANA en hn1-db-0, la salida debe ser similar a la siguiente:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Bloqueo de la comunicación de red

Estado del recurso antes de iniciar la prueba:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Ejecute la regla de firewall para bloquear la comunicación en uno de los nodos.

# 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

Cuando los nodos del clúster no se pueden comunicar entre sí, existe el riesgo de un escenario de cerebro dividido. En tales situaciones, los nodos de clúster intentan vallarse simultáneamente entre sí, lo que da lugar a una carrera de barreras. Para evitar esta situación, se recomienda establecer la propiedad priority-fencing-delay en la configuración del clúster (aplicable solo para pacemaker-2.0.4-6.el8 o superior).

Al habilitar la priority-fencing-delay propiedad , el clúster introduce un retraso en la acción de barrera específicamente en el nodo que hospeda el recurso maestro de HANA, lo que permite al nodo ganar la carrera de barreras.

Ejecute el siguiente comando para eliminar la regla de firewall:

# 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

Prueba del agente de delimitación de Azure

Nota:

Este artículo contiene referencias a un término que Microsoft ya no utiliza. Cuando se elimine el término del software, se eliminará también de este artículo.

Estado del recurso antes de iniciar la prueba:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Puede probar la configuración del agente de delimitación de Azure si deshabilita la interfaz de red en el nodo en el que SAP HANA está ejecutándose como maestro. Para obtener una descripción sobre cómo simular un fallo de red, consulte el artículo 79523 de la Base de conocimientos de Red Hat.

En este ejemplo, utilizamos el script net_breaker como root para bloquear todo acceso a la red:

sh ./net_breaker.sh BreakCommCmd 10.0.0.6

La máquina virtual debería ahora reiniciarse o detenerse dependiendo de la configuración de su cluster. Si establece la stonith-action configuración offen , la máquina virtual se detiene y los recursos se migran a la máquina virtual en ejecución.

Después de volver a iniciar la máquina virtual, el recurso de SAP HANA no se podrá iniciar como secundario si estableció AUTOMATED_REGISTER="false". En este caso, configure la instancia de HANA como secundaria ejecutando este comando como usuario hn1adm :

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2

Vuelva a la raíz y limpie el estado con errores:

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

Estado del recurso después de la prueba:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Prueba de una conmutación por error manual

Estado del recurso antes de iniciar la prueba:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Puede probar una conmutación por error manual deteniendo el cluster en el nodo hn1-db-0, como raíz:

pcs cluster stop

Después de la conmutación por error, puede reiniciar el clúster. Si establece AUTOMATED_REGISTER="false", el recurso de SAP HANA en el nodo hn1-db-0 no se podrá iniciar como secundario. En este caso, configure la instancia de HANA como secundaria mediante la ejecución de este comando:

pcs cluster start

Ejecute lo siguiente como hn1adm:

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

A continuación, como raíz:

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

Estado del recurso después de la prueba:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Compartir a través de

Alta disponibilidad de SAP HANA en máquinas virtuales de Azure en Red Hat Enterprise Linux

Requisitos previos

Información general

Preparación de la infraestructura

Implementación manual de VM de Linux mediante Azure Portal

Configurar Azure Load Balancer

Instalación de SAP HANA

Configuración de la Replicación del sistema de SAP HANA 2.0

Creación de un clúster de Pacemaker

Implementación de enlaces de replicación del sistema de SAP HANA

Creación de recursos de clúster de SAP HANA

Configuración de la replicación del sistema activa/habilitada para lectura de HANA en el clúster de Pacemaker

Configuración adicional en Azure Load Balancer para la configuración activa/habilitada para lectura

Configuración de la replicación del sistema HANA activo/habilitado para lectura

Adición de un recurso de dirección IP virtual secundaria para una configuración activa/habilitada para lectura

Prueba de la configuración del clúster

Prueba de la migración

Bloqueo de la comunicación de red

Prueba del agente de delimitación de Azure

Prueba de una conmutación por error manual

Pasos siguientes

Comentarios

Recursos adicionales