Alta disponibilidad de SAP HANA en máquinas virtuales de Azure en SUSE Linux Enterprise Server

Para establecer una alta disponibilidad en una implementación de SAP HANA local, puede usar la replicación del sistema SAP HANA o el almacenamiento compartido.

En las máquinas virtuales (VM) de Azure, la replicación del sistema de SAP HANA en Azure es actualmente la única función admitida de alta disponibilidad.

La replicación del sistema 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 SAP HANA.

Antes de comenzar, consulte las siguientes notas y documentos de SAP:

• Nota de SAP 1928533. La nota 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.
  • El software de SAP admitido y las combinaciones de sistema operativo y base de datos.
  • Las versiones del kernel de SAP necesarias 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 2205917 contiene configuraciones recomendadas del sistema operativo para SUSE Linux Enterprise Server 12 (SLES 12) para SAP Applications.
• La nota de SAP 2684254 contiene configuraciones recomendadas del sistema operativo para SUSE Linux Enterprise Server 15 (SLES 15) para SAP Applications.
• La nota de SAP 2235581 tiene sistemas operativos compatibles con SAP HANA
• 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 del agente host de SAP 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 1984787 incluye información general sobre SUSE Linux Enterprise Server 12.
• 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 nota de SAP 401162 tiene información sobre cómo evitar errores de "dirección en uso" al configurar la replicación del sistema HANA.
• La Wiki de soporte de la comunidad SAP contiene todas las notas de SAP necesarias para Linux.
• Plataformas IaaS certificadas para SAP HANA.
• Guía Implementación y planeamiento de Azure Virtual Machines para SAP en Linux.
• Guía de Implementación de Azure Virtual Machines para SAP en Linux.
• Guía Implementación de DBMS de Azure Virtual Machines para SAP en Linux.
• Guías de procedimientos recomendados de SUSE Linux Enterprise Server para SAP Applications 15 y Guías de procedimientos recomendados de SUSE Linux Enterprise Server para SAP Applications 12:
  • Configuración de una infraestructura optimizada para rendimiento de SR de SAP HANA (SLES para aplicaciones SAP). La guía contiene toda la información necesaria para configurar la replicación del sistema de SAP HANA para el desarrollo en el entorno local. Esta guía sirve como orientación.
  • Configuración de una infraestructura optimizada para costo de SR de SAP HANA (SLES para SAP Applications).

Planear la alta disponibilidad de SAP HANA

Para lograr una alta disponibilidad, instale SAP HANA en dos máquinas virtuales. Los datos se replican mediante la replicación del sistema de 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, necesita un equilibrador de carga para implementar una dirección IP virtual.

En la ilustración anterior se muestra un equilibrador de carga de ejemplo que tiene estas configuraciones:

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

Preparación de la infraestructura

El agente de recursos para SAP HANA se incluye en SUSE Linux Enterprise Server para SAP Applications. En Azure Marketplace se puede encontrar una imagen para SUSE Linux Enterprise Server para SAP Applications 12 o 15. Puede usar la imagen para implementar nuevas máquinas virtuales.

Implementación manual de VM de Linux mediante Azure Portal

Este documento asume que ya ha implementado un grupo de recursos, Azure Virtual Network y una subred.

Implemente máquinas virtuales para SAP HANA. Elija una imagen SLES adecuada compatible con el sistema HANA. Puede implementar la 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.

Azure Portal

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:

1. 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.
2. Grupo de back-end: cree un grupo de back-end y agregue máquinas virtuales de base de datos.
3. 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.

CLI de Azure

# 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

PowerShell

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

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

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

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

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

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 que no tienen direcciones IP públicas se colocan en el grupo de back-end de una instancia estándar interna (sin dirección IP pública) de Azure Load Balancer, la configuración predeterminada es sin conectividad saliente a Internet. Puede realizar pasos adicionales para permitir el enrutamiento a puntos de conexión públicos. Para obtener más información sobre cómo obtener conectividad saliente, vea 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. Si habilita las marcas de tiempo TCP provocará un error en los sondeos de estado. Establezca el parámetro net.ipv4.tcp_timestamps en 0. Para más información, consulte Sondeos de estado de Load Balancer y la nota de SAP 2382421.
• Para evitar que saptune cambie el valor net.ipv4.tcp_timestamps establecido manualmente de 0 a nuevamente 1, actualice la versión de saptune a la versión 3.1.1 o posterior. Para más información, consulte saptune 3.1.1: ¿Necesito actualizar?

Creación de un clúster de Pacemaker

Siga los pasos de Configuración de Pacemaker en SUSE Linux Enterprise Server en Azure para crear un clúster de Pacemaker básico para este servidor HANA. También puede usar el mismo clúster de Pacemaker con SAP HANA y SAP NetWeaver (A)SCS.

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.

Reemplace <placeholders> por los valores de la instalación de SAP HANA.

1. [A] Configuración del diseño del disco mediante el administrador de volúmenes lógicos (LVM).

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

   1. Ejecute este comando para enumerar todos los discos disponibles:

      /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
      

   2. 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
      

   3. 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_<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
      

   4. 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 franja 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 franja.

      Por ejemplo, si se usan dos volúmenes físicos para el volumen de datos, el argumento switch de -i se establece en 2 y el tamaño de franja del volumen de datos es 256KiB. 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. Al crear un volumen seccionado, use el modificador -I para especificar el tamaño de franja.

      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.

      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
      

   5. Cree los directorios de montaje y copie el identificador único universal (UUID) de todos los volúmenes lógicos:

      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
      

   6. Edite el archivo /etc/fstab para crear entradas fstab para los tres volúmenes lógicos:

      sudo vi /etc/fstab
      

   7. Inserte las líneas siguientes en el archivo /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
      

   8. Monte los nuevos volúmenes:

      sudo mount -a
      

2. [A] Configure el diseño del disco mediante discos sin formato.

   Para sistemas demostración, puede colocar los archivos de datos y de registro HANA en un disco.

   1. Cree una partición en /dev/disk/azure/scsi1/lun0 y aplíquele formato con 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
      

   2. Inserte esta línea en el archivo /etc/fstab:

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

   3. Cree el directorio de destino y monte el disco:

      sudo mkdir /hana
      sudo mount -a
      

3. [A] Configuración de la resolución del nombre de todos los hosts.

   Puede usar un servidor DNS o modificar el archivo /etc/hosts en todos los nodos. En este ejemplo se muestra cómo usar el archivo /etc/hosts. Reemplace las direcciones IP y los nombres de host en los siguientes comandos.

   1. Compruebe el archivo /etc/hosts:

      sudo vi /etc/hosts
      

   2. Inserte las líneas siguientes en el archivo /etc/hosts. Cambie la dirección IP y el nombre de host para que coincidan con su entorno.

      10.0.0.5 hn1-db-0
      10.0.0.6 hn1-db-1
      

4. [A] Instale SAP HANA siguiendo la documentación de SAP.

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.

Reemplace <placeholders> por los valores de la instalación de SAP HANA.

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

   Si usa SAP HANA 2.0 o MDC, cree una base de datos de inquilino para el sistema SAP NetWeaver.

   Ejecute el siguiente comando como adm de <HANA SID>:

   hdbsql -u SYSTEM -p "<password>" -i <instance number> -d SYSTEMDB 'CREATE DATABASE <SAP SID> SYSTEM USER PASSWORD "<password>"'
   

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

   En primer lugar, realice una copia de seguridad de las bases de datos como adm de <HANA SID>:

   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>')"
   

   A continuación, copie los archivos de infraestructura de clave pública (PKI) del sistema en el sitio secundario:

   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/
   

   Cree el sitio principal:

   hdbnsutil -sr_enable --name=<site 1>
   

3. [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 adm de <HANA SID>:

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

Implementación de agentes de recursos de HANA

SUSE proporciona dos paquetes de software diferentes para que el agente de recursos de Pacemaker administre SAP HANA. Los paquetes de software SAPHanaSR y SAPHanaSR-angi usan sintaxis y parámetros ligeramente diferentes y no son compatibles. Consulte las notas de la versión de SUSE y la documentación para más información y diferencias entre SAPHanaSR y SAPHanaSR-angi. En este documento se describen ambos paquetes en pestañas independientes de las secciones respectivas.

Advertencia

No reemplace el paquete SAPHanaSR por SAPHanaSR-angi en un clúster ya configurado. La actualización de SAPHanaSR a SAPHanaSR-angi requiere un procedimiento específico.

1. [A] Instalación de los paquetes de alta disponibilidad de SAP HANA:

SAPHanaSR

Ejecute el siguiente comando para instalar los paquetes de alta disponibilidad:

sudo zypper install SAPHanaSR

SAPHanaSR-angi

Importante

SAPHanaSR-angi tiene un requisito de versión mínima de SAP HANA 2.0 SPS 05 y SUSE SLES para SAP Applications 15 SP4 o superior.

Ejecute el siguiente comando para instalar los paquetes de alta disponibilidad:

sudo zypper install SAPHanaSR-angi

Configuración de proveedores de alta disponibilidad y recuperación ante desastres (HA/DR) de SAP HANA

Los proveedores de HA/DR de SAP HANA optimizan la integración con el clúster y mejoran la detección cuando se requiera una conmutación por error del clúster. El script de enlace principal es SAPHanaSR (para el paquete SAPHanaSR) / susHanaSR (para SAPHanaSR-angi). Se recomienda encarecidamente configurar el enlace de Python de SAPHanaSR/susHanaSR. Para HANA 2.0 SPS 05 y versiones posteriores, se recomienda implementar sapHanaSR/susHanaSR y los enlaces susChkSrv.

El enlace susChkSrv amplía la funcionalidad del proveedor de alta disponibilidad SAPHanaSR/susHanaSR principal. Actúa cuando el proceso de HANA hdbindexserver se bloquea. Si un único proceso se bloquea, normalmente HANA intenta reiniciarlo. El reinicio del proceso de indexserver puede tardar mucho tiempo, durante el cual la base de datos de HANA no responde.

Con susChkSrv implementado, se ejecuta una acción inmediata y configurable. La acción desencadena una conmutación por error en el período de tiempo de espera configurado en lugar de esperar a que el proceso de hdbindexserver se reinicie en el mismo nodo.

1. [A] Detenga HANA en ambos nodos.

Ejecute el código siguiente como adm de <sap-sid>:

sapcontrol -nr <instance number> -function StopSystem

2. [A] Instale el enlace de replicación del sistema de HANA. El enlace debe instalarse en ambos nodos de base de datos de HANA.

   Sugerencia

   El enlace de Python SAPHanaSR solo se puede implementar para HANA 2.0. El paquete SAPHanaSR debe ser al menos la versión 0.153.
   El enlace de Python SAPHanaSR-angi solo se puede implementar para HANA 2.0 SPS 05 y versiones posteriores.
   El enlace de Python susChkSrv requiere la instalación de la versión de SAP HANA 2.0 SPS 05 y SAPHanaSR 0.161.1_BF o superior.

   SAPHanaSR

   1. [A] Ajuste global.ini en cada nodo de clúster.

      Si no se cumplen los requisitos del enlace susChkSrv, quite todo el bloque [ha_dr_provider_suschksrv] de los parámetros siguientes. Puede ajustar el comportamiento de susChkSrv mediante el parámetro action_on_lost. Los valores válidos son [ignore | stop | kill | fence].

      [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
      

      Si señala la ruta de acceso del parámetro a la ubicación predeterminada /usr/share/SAPHanaSR, el código de enlace de Python se actualiza automáticamente a través de las 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 opcional propia, como /hana/shared/myHooks, puede desacoplar las actualizaciones del sistema operativo de la versión de enlace usada.

   2. [A] El clúster requiere la configuración de elementos que usan el programa sudo en cada nodo de clúster para el adm de <sap-sid>. En este ejemplo, esto se consigue mediante la creación de un archivo nuevo.

      Ejecute el siguiente comando como raíz. Reemplace <sid> por el id. de sistema SAP en minúsculas, <SID> por el id. de sistema SAP en mayúsculas y <siteA/B> por los nombres de sitio de HANA elegidos.

      cat << EOF > /etc/sudoers.d/20-saphana
      # Needed for SAPHanaSR and susChkSrv Python hooks
      Cmnd_Alias SOK_SITEA      = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEA    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias SOK_SITEB      = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEB    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias HELPER_TAKEOVER = /usr/sbin/SAPHanaSR-hookHelper --sid=<SID> --case=checkTakeover
      Cmnd_Alias HELPER_FENCE    = /usr/sbin/SAPHanaSR-hookHelper --sid=<SID> --case=fenceMe
      
      <sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB, HELPER_TAKEOVER, HELPER_FENCE
      EOF
      

   Para más información sobre cómo implementar el enlace de replicación del sistema de SAP HANA, consulte Configuración de proveedores de alta disponibilidad y recuperación ante desastres de HANA.

   SAPHanaSR-angi

   1. [A] Ajuste global.ini en cada nodo de clúster.

      Si decide no usar el enlace susChkSrv recomendado, quite todo el bloque [ha_dr_provider_suschksrv] de los parámetros siguientes. Puede ajustar el comportamiento de susChkSrv mediante el parámetro action_on_lost. Los valores válidos son [ignore | stop | kill | fence].

      [ha_dr_provider_sushanasr]
      provider = susHanaSR
      path = /usr/share/SAPHanaSR-angi
      execution_order = 1
      
      [ha_dr_provider_suschksrv]
      provider = susChkSrv
      path = /usr/share/SAPHanaSR-angi
      execution_order = 3
      action_on_lost = fence
      
      [trace]
      ha_dr_sushanasr = info
      ha_dr_saphanasr = info
      

      Si señala la ruta de acceso del parámetro a la ubicación predeterminada /usr/share/SAPHanaSR-angi, el código de enlace de Python se actualiza automáticamente a través de las 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 opcional propia, como /hana/shared/myHooks, puede desacoplar las actualizaciones del sistema operativo de la versión de enlace usada.

   2. [A] El clúster requiere la configuración de elementos que usan el programa sudo en cada nodo de clúster para el adm de <sap-sid>. En este ejemplo, esto se consigue mediante la creación de un archivo nuevo.

      Ejecute el siguiente comando como raíz. Reemplace <sid> por el id. de sistema SAP en minúsculas, <SID> por el id. de sistema SAP en mayúsculas y <siteA/B> por los nombres de sitio de HANA elegidos.

      cat << EOF > /etc/sudoers.d/20-saphana
      # Needed for susHanaSR and susChkSrv Python hooks
      Cmnd_Alias SOK_SITEA    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEA  = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias SOK_SITEB    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEB  = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias HELPER_TAKEOVER  = /usr/bin/SAPHanaSR-hookHelper --sid=<SID> --case=checkTakeover
      Cmnd_Alias HELPER_FENCE     = /usr/bin/SAPHanaSR-hookHelper --sid=<SID> --case=fenceMe
      
      <sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB, HELPER_TAKEOVER, HELPER_FENCE
      EOF
      

      Para más información sobre cómo implementar el enlace de replicación del sistema de SAP HANA, consulte Configuración de proveedores de alta disponibilidad y recuperación ante desastres de HANA.

---

3. [A] Inicie SAP HANA en ambos nodos. Ejecute el siguiente comando como adm de <sap-sid>:

   sapcontrol -nr <instance number> -function StartSystem 
   

4. [1] Compruebe la instalación del enlace. Ejecute el siguiente comando como adm de <sap-sid> en el sitio de replicación del sistema de HANA activo:

   SAPHanaSR

   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
   

   SAPHanaSR-angi

   cdtrace
   grep HADR.*load.*SAPHanaSR nameserver_*.trc
   # Example output
   # ha_dr_provider HADRProviderManager.cpp(00083) : loading HA/DR Provider 'susHanaSR' from /usr/share/SAPHanaSR-angi
   

---

5. [1] Compruebe la instalación del enlace susChkSrv. Ejecute el siguiente comando como adm de <sap-sid> en todas las máquinas virtuales de HANA:

   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)
   

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

1. [1] A continuación, cree el recurso de topología de HANA.

SAPHanaSR

Ejecute los comandos siguientes en uno de los nodos del clúster de 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"

SAPHanaSR-angi

Ejecute los comandos siguientes en uno de los nodos del clúster de 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 \
  op monitor interval="50" 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" interleave="true"

2. [1] A continuación, cree los recursos de HANA:

SAPHanaSR

Nota:

Este artículo contiene referencias a términos que Microsoft ya no utiliza. Cuando se eliminen estos términos del software, se eliminarán de este artículo.

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

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"

# Run the following command if the cluster nodes are running on SLES 12 SP05.
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"

# Run the following command if the cluster nodes are running on SLES 15 SP03 or later.
sudo crm configure clone 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" promotable="true"

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

SAPHanaSR-angi

# Replace <placeholders> with your instance number and HANA system ID. 
sudo crm configure primitive rsc_SAPHanaCon_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop  interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op demote  interval="0" timeout="320"  \
  op monitor interval="60" role="Promoted" timeout="700" \
  op monitor interval="61" role="Unpromoted" timeout="700" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \
  meta priority=100

sudo crm configure clone mst_SAPHanaCon_<HANA SID>_HDB<instance number> rsc_SAPHanaCon_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true" promotable="true"

SAPHanaSR-angi agrega un nuevo agente de recursos SAPHanaFilesystem para supervisar el acceso de lectura y escritura a /hana/shared/SID. El sistema operativo estático monta el sistema de archivos /hana/shared/SID con cada host que tenga entradas en /etc/fstab. SAPHanaFilesystem y Pacemaker no montan el sistema de archivos para HANA.

Se recomienda implementar SAPHanaFilesystem si usa NFS para la ubicación /hana/shared/SID. Cuando /hana/shared/SID se encuentra en un dispositivo de bloque, como un disco administrado de Azure, el uso de SAPHanaFilesystem es opcional.

# Replace <placeholders> with your instance number and HANA system ID. 
sudo crm configure primitive rsc_SAPHanaFil_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaFilesystem \
  op start interval="0" timeout="10" \
  op stop interval="0" timeout="20" \
  op monitor interval="120" timeout="120" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" ON_FAIL_ACTION="fence"

sudo crm configure clone cln_SAPHanaFil_<HANA SID>_HDB<instance number> rsc_SAPHanaFil_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true"

3. [1] Continúe con los recursos de clúster para direcciones IP virtuales, valores predeterminados y restricciones.

SAPHanaSR

# 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_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

SAPHanaSR-angi

# 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_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
  meta target-role="Started" \
  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 \
  mst_SAPHanaCon_<HANA SID>_HDB<instance number>:Promoted  

sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  mst_SAPHanaCon_<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_SAPHanaCon_<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

Importante

Se recomienda establecer AUTOMATED_REGISTER en false solo mientras se completan las pruebas de conmutación por error exhaustivas para evitar que una instancia principal con errores se registre automáticamente como secundaria. Cuando las pruebas de conmutación por error se completen correctamente, establezca AUTOMATED_REGISTER en true, de modo que después de la adquisición, la replicación del sistema se reanude automáticamente.

Asegúrese de que el estado del clúster sea OK y que todos los recursos se hayan iniciado. No importa en qué nodo se ejecutan los recursos.

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

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

En SAP HANA 2.0 SPS 01 y versiones posteriores, SAP permite una configuración activa o habilitada para lectura para la replicación del sistema SAP HANA. En este escenario, los sistemas secundarios de replicación del sistema 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 que permita a los clientes tener acceso a la base de datos secundaria de SAP HANA habilitada para lectura. 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.

En esta sección se describen los pasos adicionales necesarios para administrar la replicación del sistema de HANA activo/habilitado para lectura en un clúster de alta disponibilidad de SUSE con una segunda dirección IP virtual.

Antes de continuar, asegúrese de que ha configurado completamente el clúster de alta disponibilidad de SUSE que administra la base de datos de SAP HANA como se describe en las secciones anteriores.

Configuración del equilibrador de carga para la replicación del sistema activa o habilitada para lectura

Para continuar con pasos adicionales para aprovisionar la segunda dirección IP virtual, asegúrese de configurar Azure Load Balancer como se describe en Implementación manual de máquinas virtuales Linux mediante Azure Portal.

Para el equilibrador de carga estándar, complete estos pasos adicionales en el mismo equilibrador de carga que creó anteriormente.

1. Crear un segundo grupo de direcciones IP de front-end:
   1. Abra el equilibrador de carga, seleccione frontend IP pool (Grupo de direcciones IP de front-end) y haga clic en Agregar.
   2. Escriba el nombre del segundo grupo de direcciones IP de front-end (por ejemplo, hana-secondaryIP).
   3. Establezca Assignment (Asignación) en Static (Estática) y escriba la dirección IP (por ejemplo, 10.0.0.14).
   4. Seleccione Aceptar.
   5. Una vez creado el nuevo grupo de direcciones IP de front-end, anote la dirección IP del front-end.
2. Cree un sondeo de estado:
   1. Abra el equilibrador de carga, seleccione Sondeos de estado y haga clic en Agregar.
   2. Escriba el nombre del sondeo de estado nuevo (por ejemplo hana-secondaryhp).
   3. Seleccione TCP como el protocolo y el >número de instancia del puerto 626<. Mantenga el valor de Intervalo en 5 y el valor de Umbral incorrecto en 2.
   4. Seleccione Aceptar.
3. Cree las reglas de equilibrio de carga:
   1. Abra el equilibrador de carga, seleccione Reglas de equilibrio de carga y haga clic en Agregar.
   2. Escriba el nombre de la nueva regla del equilibrador de carga (por ejemplo, hana-secondarylb).
   3. 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).
   4. Seleccione Puertos HA.
   5. Aumente el tiempo de espera de inactividad a 30 minutos.
   6. Asegúrese de habilitar la dirección IP flotante.
   7. Seleccione Aceptar.

Configuración de la replicación del sistema de 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 de SAP HANA 2.0. Si va a implementar un escenario secundario habilitado para lectura, al configurar la replicación del sistema en el segundo nodo, ejecute el siguiente comando como adm de <HANA SID>:

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 

Agregar un recurso de dirección IP virtual secundaria

Puede configurar la segunda dirección IP virtual y la restricción de coubicación adecuada mediante los siguientes comandos:

SAPHanaSR

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

SAPHanaSR-angi

crm configure property maintenance-mode=true

crm configure primitive rsc_secip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
 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 \
 mst_SAPHanaCon_<HANA SID>_HDB<instance number>:Unpromoted 

crm configure property maintenance-mode=false

Asegúrese de que el estado del clúster sea OK y que todos los recursos se hayan iniciado. La segunda dirección IP virtual se ejecutará en el sitio secundario junto con el recurso secundario 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

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

Consideraciones al probar un clúster de HANA configurado con una secundaria habilitada para lectura:

• Al migrar el recurso del clúster SAPHana_<HANA SID>_HDB<instance number> a hn1-db-1, la segunda dirección IP virtual se mueve a hn1-db-0. Si ha configurado AUTOMATED_REGISTER="false" y la replicación del sistema HANA no se registra automáticamente, la segunda dirección IP virtual se ejecuta en hn1-db-0 porque el servidor está disponible y los servicios de clúster están en línea.

• Al probar el bloqueo del servidor, los recursos de la segunda IP virtual (rsc_secip_<HANA SID>_HDB<instance number>) y el recurso de puerto de Azure Load Balancer (rsc_secnc_<HANA SID>_HDB<instance number>) 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 no esté disponible.

• Cuando el servidor secundario esté disponible y los servicios de clúster estén en línea, la segunda dirección IP virtual y los recursos de puerto se trasladarán automáticamente al servidor secundario, incluso si la replicación del sistema de HANA no se registra como secundaria. Es muy importante registrar la base de datos secundaria de HANA como habilitada para lectura antes de iniciar los servicios de clúster en ese servidor. Puede configurar el recurso de clúster de instancia de HANA para registrar automáticamente la replicación secundaria estableciendo el parámetro AUTOMATED_REGISTER="true".

• Durante la conmutación por error y por reserva, se pueden interrumpir las conexiones existentes de las aplicaciones mediante la conexión de la segunda dirección IP virtual a la base de datos de HANA.

Prueba de la configuración del clúster

En esta sección se describe cómo se puede probar la configuración. Cada prueba supone que ha iniciado sesión como raíz y que el maestro de SAP HANA se ejecuta en la máquina virtual hn1-db-0.

Prueba de la migración

Antes de comenzar la prueba, asegúrese de que Pacemaker no tenga acciones con error (ejecute crm_mon -r), no haya restricciones de ubicación inesperadas (por ejemplo, restos de una prueba de migración) y de que HANA se encuentre en estado de sincronización, por ejemplo ejecutando SAPHanaSR-showAttr.

SAPHanaSR

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

SAPHanaSR-angi

hn1-db-0:~ # SAPHanaSR-showAttr
Global cib-update dcid prim      sec sid topology
--------------------------------------------------
global 0.130728.2 1    SITE1 -   HN1 ScaleUp

Resource                      promotable
-----------------------------------------
mst_SAPHanaCon_HN1_HDB03      true
cln_SAPHanaTopology_HN1_HDB03

Site        lpt        lss mns      opMode    srHook srMode srPoll srr
-----------------------------------------------------------------------
SITE1       1722604101 4   hn1-db-0 logreplay PRIM   sync   PRIM   P
SITE2       30         4   hn1-db-1 logreplay SWAIT  sync   SOK    S

Host     clone_state roles                        score site    sra srah version     vhost
---------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    master1:master:worker:master 150   SITE1   -   -    2.00.074.00 hn1-db-0
hn1-db-1 DEMOTED     master1:master:worker:master 100   SITE2       -    2.00.074.00 hn1-db-1

Host     clone_state roles                        score site      sra srah version     vhost
------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    master1:master:worker:master 150   SITE1     -   -    2.00.074.00 hn1-db-0
hn1-db-1                                                SITE2                          hn1-db-1

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

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

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.

Cuando finalice la migración, la salida crm_mon -r tendrá el siguiente aspecto:

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

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 este comando:

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>

La migración crea restricciones de ubicación que deben eliminarse de nuevo:

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

También debe limpiar el estado del recurso de nodo secundario:

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

Supervise el estado del recurso de HANA mediante crm_mon -r. Cuando se inicia HANA en hn1-db-0, la salida tiene el siguiente aspecto:

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

Bloqueo de la comunicación de red

Estado del recurso antes de iniciar la prueba:

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

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 intentarán cercarse simultáneamente, lo que da lugar a una carrera de barreras.

Al configurar un dispositivo de barrera, se recomienda configurar la propiedad pcmk_delay_max. Por lo tanto, en caso de escenario de cerebro dividido, el clúster introduce un retraso aleatorio hasta el valor pcmk_delay_max, a la acción de barrera en cada nodo. El nodo con el retraso más corto se seleccionará para la barrera.

Además, para asegurarse de que el nodo que ejecuta el maestro de HANA tiene prioridad y gana la carrera de barreras en un escenario de cerebro dividido, se recomienda establecer la propiedad priority-fencing-delay en la configuración del clúster. Al habilitar la propiedad priority-fencing-delay, el clúster puede introducir un retraso adicional 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 comando siguiente 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 de delimitación de SBD

Para probar la configuración de SBD, termine el proceso inquisidor:

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

El nodo de clúster <HANA SID>-db-<database 1> se reinicia. Es posible que el servicio Pacemaker no se reinicie. Asegúrese de empezar de nuevo.

Prueba de una conmutación por error manual

Para probar una conmutación por error manual, detenga el servicio de Pacemaker en el nodo hn1-db-0:

service pacemaker stop

Después de la conmutación por error, puede reiniciar el servicio. 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:

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

Pruebas de SUSE

Importante

Asegúrese de que el sistema operativo seleccionado está certificado por SAP para SAP HANA en los tipos específicos de máquina virtual que planea usar. 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.

Ejecute todos los casos de prueba que se indican en la guía del escenario optimizado para el rendimiento de SR de SAP HANA o la guía de escenarios optimizados para costo de SR de SAP HANA, en función de su caso de uso. Puede encontrar las guías enumeradas en SLES para procedimientos recomendados de SAP.

Las siguientes pruebas son una copia de las descripciones de pruebas de la guía del escenario optimizado para el rendimiento de SR de SAP HANA de SUSE Linux Enterprise Server para SAP Applications 12 SP1. Para obtener una versión actualizada, lea siempre también la propia guía. Antes de iniciar la prueba, asegúrese de que HANA esté sincronizado y de que la configuración de Pacemaker sea correcta.

En las siguientes descripciones de prueba, se supone PREFER_SITE_TAKEOVER="true" y AUTOMATED_REGISTER="false".

Nota:

Las siguientes pruebas están diseñadas para ejecutarse en secuencia. Cada prueba depende del estado de salida de la prueba anterior.

1. Prueba 1: Detener la base de datos principal en el nodo 1.

   Estado del recurso antes de iniciar la prueba:

   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
   

   Ejecute los siguientes comandos como adm de <HANA SID> en el nodo hn1-db-0:

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

   Pacemaker detecta la instancia de HANA detenida y conmuta por error al otro nodo. Cuando finaliza la conmutación por error, se detiene la instancia de HANA en el nodo hn1-db-0 porque Pacemaker no registra automáticamente el nodo como secundario de HANA.

   Ejecute los siguientes comandos para registrar el nodo hn1-db-0 como secundario y limpiar el recurso con error:

   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
   

   Estado del recurso después de la prueba:

   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. Prueba 2: Detener la base de datos principal en el nodo 2.

   Estado del recurso antes de iniciar la prueba:

   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
   

   Ejecute los siguientes comandos como adm de <HANA SID> en el nodo hn1-db-1:

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

   Pacemaker detecta la instancia de HANA detenida y conmuta por error al otro nodo. Cuando finaliza la conmutación por error, se detiene la instancia de HANA en el nodo hn1-db-1 porque Pacemaker no registra automáticamente el nodo como secundario de HANA.

   Ejecute los siguientes comandos para registrar el nodo hn1-db-1 como secundario y limpiar el recurso con error:

   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
   

   Estado del recurso después de la prueba:

   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. Prueba 3: Bloquear la base de datos principal en el nodo 1.

   Estado del recurso antes de iniciar la prueba:

   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
   

   Ejecute los siguientes comandos como adm de <HANA SID> en el nodo hn1-db-0:

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

   Pacemaker detecta la instancia de HANA eliminada y conmuta por error al otro nodo. Cuando finaliza la conmutación por error, se detiene la instancia de HANA en el nodo hn1-db-0 porque Pacemaker no registra automáticamente el nodo como secundario de HANA.

   Ejecute los siguientes comandos para registrar el nodo hn1-db-0 como secundario y limpiar el recurso con error:

   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
   

   Estado del recurso después de la prueba:

   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. Prueba 4: Bloquear la base de datos principal en el nodo 2.

   Estado del recurso antes de iniciar la prueba:

   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
   

   Ejecute los siguientes comandos como adm de <HANA SID> en el nodo hn1-db-1:

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

   Pacemaker detecta la instancia de HANA eliminada y conmuta por error al otro nodo. Cuando finaliza la conmutación por error, se detiene la instancia de HANA en el nodo hn1-db-1 porque Pacemaker no registra automáticamente el nodo como secundario de HANA.

   Ejecute los siguientes comandos para registrar el nodo hn1-db-1 como secundario y limpiar el recurso con error.

   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
   

   Estado del recurso después de la prueba:

   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. Prueba 5: Bloquear el nodo del sitio primario (nodo 1).

   Estado del recurso antes de iniciar la prueba:

   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
   

   Ejecute los siguientes comandos como raíz en el nodo hn1-db-0:

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

   Pacemaker detecta el nodo de clúster eliminado y lo cerca. Una vez que el nodo está delimitado, Pacemaker desencadenará una adquisición de la instancia de HANA. Cuando se reinicia el nodo delimitado, Pacemaker no se inicia automáticamente.

   Ejecute los siguientes comandos para iniciar Pacemaker, limpiar los mensajes SBD del nodo hn1-db-0, registrar el nodo hn1-db-0 como secundario y limpiar el recurso con errores:

   # 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
   

   Estado del recurso después de la prueba:

   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. Prueba 6: Bloquear el nodo del sitio secundario (nodo 2).

   Estado del recurso antes de iniciar la prueba:

   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
   

   Ejecute los siguientes comandos como raíz en el nodo hn1-db-1:

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

   Pacemaker detecta el nodo de clúster eliminado y lo cerca. Una vez que el nodo está delimitado, Pacemaker desencadenará una adquisición de la instancia de HANA. Cuando se reinicia el nodo delimitado, Pacemaker no se inicia automáticamente.

   Ejecute los siguientes comandos para iniciar Pacemaker, limpiar los mensajes SBD del nodo hn1-db-1, registrar el nodo hn1-db-1 como secundario y limpiar el recurso con errores:

   # 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
   

   Estado del recurso después de la prueba:

   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. Prueba 7: Detenga la base de datos secundaria en el nodo 2.

   Estado del recurso antes de iniciar la prueba:

   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
   

   Ejecute los siguientes comandos como adm de <HANA SID> en el nodo hn1-db-1:

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

   Pacemaker detecta la instancia de HANA detenida y marca el recurso como erróneo en el nodo hn1-db-1. Pacemaker reinicia automáticamente la instancia de HANA.

   Ejecute el siguiente comando para limpiar el estado de error:

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

   Estado del recurso después de la prueba:

   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. Prueba 8: Bloquear la base de datos secundaria en el nodo 2.

   Estado del recurso antes de iniciar la prueba:

   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
   

   Ejecute los siguientes comandos como adm de <HANA SID> en el nodo hn1-db-1:

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

   Pacemaker detecta la instancia de HANA eliminada y marca el recurso como erróneo en el nodo hn1-db-1. Ejecute el siguiente comando para limpiar el estado de error. Pacemaker reinicia automáticamente la instancia de HANA.

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

   Estado del recurso después de la prueba:

   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. Prueba 9: Bloquear el nodo de sitio secundario (nodo 2) que ejecuta la base de datos secundaria de HANA.

   Estado del recurso antes de iniciar la prueba:

   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
   

   Ejecute los siguientes comandos como raíz en el nodo hn1-db-1:

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

   Pacemaker detecta el nodo de clúster eliminado y ha cercado el nodo. Cuando se reinicia el nodo delimitado, Pacemaker no se inicia automáticamente.

   Ejecute los siguientes comandos para iniciar Pacemaker, limpiar los mensajes de SBD del nodo hn1-db-1 y limpiar el recurso con error:

   # 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
   

   Estado del recurso después de la prueba:

   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. Prueba 10: Bloquear el servidor de índices de la base de datos principal

    Esta prueba solo es relevante cuando haya configurado el enlace susChkSrv como se describe en Implementación de agentes del recurso de HANA.

    Estado del recurso antes de iniciar la prueba:

    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
    

    Ejecute los siguientes comandos como raíz en el nodo hn1-db-0:

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

    Cuando el indexserver finaliza, el enlace susChkSrv detecta el evento y desencadena una acción para cercar el nodo "hn1-db-0" e iniciar el proceso de adquisición.

    Ejecute los siguientes comandos para registrar el nodo hn1-db-0 como secundario y limpiar el recurso con error:

    # 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
    

    Estado del recurso después de la prueba:

    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
    

    Puede ejecutar un caso de prueba comparable haciendo que el indexserver del nodo secundario se bloquee. En caso de bloqueo de indexserver, el enlace susChkSrv reconocerá la aparición e iniciará una acción para cercar el nodo secundario.

Pasos siguientes

• Planeamiento e implementación de Azure Virtual Machines para SAP
• Implementación de Azure Virtual Machines para SAP
• Implementación de DBMS de Azure Virtual Machines para SAP