Elevada disponibilidade do SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server para a guia de múltiplos SID das Aplicações SAP
Este artigo descreve como implantar vários sistemas altamente disponíveis SAP NetWeaver ou S4HANA (ou seja, vários SID) em um cluster de dois nós em VMs do Azure com aplicativos SUSE Linux Enterprise Server for SAP.
Nas configurações de exemplo, comandos de instalação, etc., três sistemas SAP NetWeaver 7.50 são implantados em um único cluster de alta disponibilidade de dois nós. Os SIDs dos sistemas SAP são:
- NW1: número de instância ASCS 00 e nome de host virtual msnw1ascs; Número de instância ERS 02 e nome de host virtual msnw1ers.
- NW2: instância ASCS número 10 e nome de host virtual msnw2ascs; Instância ERS número 12 e nome de host virtual msnw2ers.
- NW3: número de instância ASCS 20 e nome de host virtual msnw3ascs; Número de instância ERS 22 e nome de host virtual msnw3ers.
O artigo não aborda a camada de banco de dados e a implantação dos compartilhamentos SAP NFS. Nos exemplos deste artigo, estamos usando nomes virtuais nw2-nfs para os compartilhamentos NFS NW2 e nw3-nfs para os compartilhamentos NFS NW3, supondo que o cluster NFS foi implantado.
Antes de começar, consulte primeiro as seguintes notas e documentos do SAP:
- SAP Note 1928533, que tem:
- Lista de tamanhos de VM do Azure suportados para a implantação do software SAP
- Informações de capacidade importantes para tamanhos de VM do Azure
- Software SAP suportado, sistema operacional (SO) e combinações de banco de dados
- Versão necessária do kernel SAP para Windows e Linux no Microsoft Azure
- SAP Note 2015553 lista os pré-requisitos para implantações de software SAP suportadas pelo SAP no Azure.
- SAP Nota 2205917 recomendou as configurações do sistema operacional para o SUSE Linux Enterprise Server for SAP Applications
- O SAP Note 1944799 tem as diretrizes do SAP HANA para o SUSE Linux Enterprise Server for SAP Applications
- O SAP Note 2178632 tem informações detalhadas sobre todas as métricas de monitoramento relatadas para SAP no Azure.
- O SAP Note 2191498 tem a versão necessária do SAP Host Agent para Linux no Azure.
- O SAP Note 2243692 tem informações sobre o licenciamento SAP no Linux no Azure.
- O SAP Note 1984787 tem informações gerais sobre o SUSE Linux Enterprise Server 12.
- O SAP Note 1999351 tem informações adicionais de solução de problemas para a Extensão de Monitoramento Avançado do Azure para SAP.
- O SAP Community WIKI tem todas as notas SAP necessárias para Linux.
- Planejamento e implementação de Máquinas Virtuais do Azure para SAP no Linux
- Implantação de Máquinas Virtuais do Azure para SAP no Linux
- Implantação de DBMS de Máquinas Virtuais do Azure para SAP no Linux
- Guias de práticas recomendadas do SUSE SAP HA - Os guias contêm todas as informações necessárias para configurar o Netweaver HA e o SAP HANA System Replication localmente. Use estes guias como uma linha de base geral. Fornecem informações muito mais pormenorizadas.
- Notas de versão do SUSE High Availability Extension 12 SP3
- Guia de cluster multi-SID SUSE para SLES 12 e SLES 15
- Aplicativos SAP da NetApp no Microsoft Azure usando Arquivos NetApp do Azure
Descrição geral
As máquinas virtuais que participam do cluster devem ser dimensionadas para poder executar todos os recursos, caso ocorra failover. Cada SID SAP pode fazer failover independente um do outro no cluster de alta disponibilidade multi-SID. Se estiver usando cercas SBD, os dispositivos SBD podem ser compartilhados entre vários clusters.
Para obter alta disponibilidade, o SAP NetWeaver requer compartilhamentos NFS altamente disponíveis. Neste exemplo, assumimos que os compartilhamentos SAP NFS estão hospedados em um servidor de arquivos NFS altamente disponível, que pode ser usado por vários sistemas SAP. Ou os compartilhamentos são implantados em volumes NFS do Azure NetApp Files.
Importante
O suporte para clustering multi-SID de SAP ASCS/ERS com SUSE Linux como sistema operacional convidado em VMs do Azure é limitado a cinco SIDs SAP no mesmo cluster. Cada novo SID aumenta a complexidade. Não há suporte para uma combinação de SAP Enqueue Replication Server 1 e Enqueue Replication Server 2 no mesmo cluster. O clustering Multi-SID descreve a instalação de várias instâncias SAP ASCS/ERS com SIDs diferentes em um cluster Pacemaker. Atualmente, o clustering multi-SID só é suportado para ASCS/ERS.
Gorjeta
O clustering multi-SID do SAP ASCS/ERS é uma solução com maior complexidade. É mais complexo de implementar. Também envolve maior esforço administrativo, ao executar atividades de manutenção (como patches de SO). Antes de iniciar a implementação real, reserve um tempo para planejar cuidadosamente a implantação e todos os componentes envolvidos, como VMs, montagens NFS, VIPs, configurações de balanceador de carga e assim por diante.
O servidor NFS, SAP NetWeaver ASCS, SAP NetWeaver SCS, SAP NetWeaver ERS e o banco de dados SAP HANA usam nome de host virtual e endereços IP virtuais. No Azure, um balanceador de carga é necessário para usar um endereço IP virtual. Recomendamos o uso do balanceador de carga padrão.
A configuração apresentada para este exemplo de cluster multi-SID com três sistemas SAP mostra um balanceador de carga com:
- Endereços IP frontend para ASCS: 10.3.1.14 (NW1), 10.3.1.16 (NW2) e 10.3.1.13 (NW3)
- Endereços IP frontend para ERS: 10.3.1.15 (NW1), 10.3.1.17 (NW2) e 10.3.1.19 (NW3)
- Porta de sonda 62000 para NW1 ASCS, 62010 para NW2 ASCS e 62020 para NW3 ASCS
- Porta de sonda 62102 para NW1 ASCS, 62112 para NW2 ASCS e 62122 para NW3 ASCS
Nota
Quando VMs sem endereços IP públicos são colocadas no pool de back-end do balanceador de carga interno (sem endereço IP público) Standard do Azure, não haverá conectividade de saída com a Internet, a menos que uma configuração adicional seja executada para permitir o roteamento para pontos finais públicos. Para obter detalhes sobre como obter conectividade de saída, consulte Conectividade de ponto de extremidade público para máquinas virtuais usando o Azure Standard Load Balancer em cenários de alta disponibilidade SAP.
Importante
- Não habilite carimbos de data/hora TCP em VMs do Azure colocadas atrás do Balanceador de Carga do Azure. Habilitar carimbos de data/hora TCP fará com que as sondas de integridade falhem. Defina o
net.ipv4.tcp_timestamps
parâmetro como0
. Para obter detalhes, consulte Sondas de integridade do balanceador de carga. - Para evitar que o saptune altere o valor definido
net.ipv4.tcp_timestamps
manualmente de0
volta para1
, atualize a versão do saptune para 3.1.1 ou superior. Para obter mais informações, consulte saptune 3.1.1 – Do I Need to Update?.
Ações do SAP NFS
O SAP NetWeaver requer armazenamento compartilhado para o transporte, diretório de perfil e assim por diante. Para um sistema SAP altamente disponível, é importante ter compartilhamentos NFS altamente disponíveis. Você precisaria decidir sobre a arquitetura para seus compartilhamentos SAP NFS. Uma opção é criar cluster NFS altamente disponível em VMs do Azure no SUSE Linux Enterprise Server, que pode ser compartilhado entre vários sistemas SAP.
Outra opção é implantar os compartilhamentos nos volumes NFS do Azure NetApp Files. Com o Azure NetApp Files, você obteria alta disponibilidade interna para os compartilhamentos SAP NFS.
Implantar o primeiro sistema SAP no cluster
Com base na arquitetura para os compartilhamentos SAP NFS, implante o primeiro sistema SAP no cluster, seguindo a documentação correspondente.
- Se estiver usando um servidor NFS altamente disponível, siga Alta disponibilidade para SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server para aplicativos SAP.
- Se estiver usando volumes NFS do Azure NetApp Files, siga Alta disponibilidade para SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server com arquivos NetApp do Azure para aplicativos SAP
Os documentos listados acima o guiariam pelas etapas para preparar as infraestruturas necessárias, construir o cluster, preparar o sistema operacional para executar o aplicativo SAP.
Gorjeta
Sempre teste a funcionalidade de failover do cluster, depois que o primeiro sistema for implantado, antes de adicionar os SIDs SAP adicionais ao cluster. Dessa forma, você saberá que a funcionalidade de cluster funciona, antes de adicionar a complexidade de sistemas SAP adicionais ao cluster.
Implantar sistemas SAP adicionais no cluster
Neste exemplo, assumimos que o sistema NW1 já foi implantado no cluster. Vamos mostrar como implantar no cluster os sistemas SAP NW2 e NW3.
Os itens a seguir são prefixados com [A] - aplicável a todos os nós, [1] - aplicável apenas ao nó 1 ou [2] - aplicável apenas ao nó 2.
Pré-requisitos
Importante
Antes de seguir as instruções para implantar sistemas SAP adicionais no cluster, siga as instruções para implantar o primeiro sistema SAP no cluster, pois há etapas que só são necessárias durante a primeira implantação do sistema.
Esta documentação pressupõe que:
- O cluster Pacemaker já está configurado e em execução.
- Pelo menos um sistema SAP (instância ASCS/ERS) já está implantado e em execução no cluster.
- A funcionalidade de failover de cluster é testada.
- Os compartilhamentos NFS para todos os sistemas SAP são implantados.
Preparar para a instalação do SAP NetWeaver
Adicione configuração para o sistema recém-implantado (ou seja, NW2, NW3) ao Balanceador de Carga do Azure existente, seguindo as instruções para configurar o Balanceador de Carga do Azure manualmente por meio do portal do Azure. Ajuste os endereços IP, as portas da sonda de integridade, as regras de balanceamento de carga para sua configuração.
[A] Configure a resolução de nomes para os sistemas SAP adicionais. Você pode usar o servidor DNS ou modificar
/etc/hosts
em todos os nós. Este exemplo mostra como usar o/etc/hosts
arquivo. Adapte os endereços IP e os nomes de host ao seu ambiente.sudo vi /etc/hosts # IP address of the load balancer frontend configuration for NW2 ASCS 10.3.1.16 msnw2ascs # IP address of the load balancer frontend configuration for NW3 ASCS 10.3.1.13 msnw3ascs # IP address of the load balancer frontend configuration for NW2 ERS 10.3.1.17 msnw2ers # IP address of the load balancer frontend configuration for NW3 ERS 10.3.1.19 msnw3ers # IP address for virtual host name for the NFS server for NW2 10.3.1.31 nw2-nfs # IP address for virtual host name for the NFS server for NW3 10.3.1.32 nw3-nfs
[A] Crie os diretórios compartilhados para os sistemas SAP NW2 e NW3 adicionais que você está implantando no cluster.
sudo mkdir -p /sapmnt/NW2 sudo mkdir -p /usr/sap/NW2/SYS sudo mkdir -p /usr/sap/NW2/ASCS10 sudo mkdir -p /usr/sap/NW2/ERS12 sudo mkdir -p /sapmnt/NW3 sudo mkdir -p /usr/sap/NW3/SYS sudo mkdir -p /usr/sap/NW3/ASCS20 sudo mkdir -p /usr/sap/NW3/ERS22 sudo chattr +i /sapmnt/NW2 sudo chattr +i /usr/sap/NW2/SYS sudo chattr +i /usr/sap/NW2/ASCS10 sudo chattr +i /usr/sap/NW2/ERS12 sudo chattr +i /sapmnt/NW3 sudo chattr +i /usr/sap/NW3/SYS sudo chattr +i /usr/sap/NW3/ASCS20 sudo chattr +i /usr/sap/NW3/ERS22
[A] Configure
autofs
para montar os sistemas de arquivos /sapmnt/SID e /usr/sap/SID/SYS para os sistemas SAP adicionais que você está implantando no cluster. Neste exemplo , NW2 e NW3.Atualize o arquivo
/etc/auto.direct
com os sistemas de arquivos para os sistemas SAP adicionais que você está implantando no cluster.- Se estiver usando o servidor de arquivos NFS, siga as instruções na página Alta disponibilidade das VMs do Azure para SAP NetWeaver no SLES
- Se estiver usando Arquivos NetApp do Azure, siga as instruções na página Alta disponibilidade de VMs do Azure para SAP NW no SLES com Arquivos NetApp do Azure
Você precisa reiniciar o
autofs
serviço para montar os compartilhamentos recém-adicionados.
Instalar ASCS / ERS
Crie os recursos de cluster de sonda de integridade e IP virtual para a instância ASCS do sistema SAP adicional que você está implantando no cluster. O exemplo mostrado aqui é para NW2 e NW3 ASCS, usando servidor NFS altamente disponível.
Importante
Testes recentes revelaram situações em que o netcat para de responder a solicitações devido ao backlog e sua limitação de lidar com apenas uma conexão. O recurso netcat para de ouvir as solicitações do balanceador de carga do Azure e o IP flutuante fica indisponível.
Para clusters de marcapasso existentes, recomendamos no passado a substituição do netcat pelo socat. Atualmente, recomendamos o uso do azure-lb resource agent, que faz parte dos agentes de recursos do pacote, com os seguintes requisitos de versão do pacote:- Para SLES 12 SP4/SP5, a versão deve ser pelo menos resource-agents-4.3.018.a7fb5035-3.30.1.
- Para o SLES 15/15 SP1, a versão deve ser pelo menos resource-agents-4.3.0184.6ee15eb2-4.13.1.
Observe que a alteração exigirá um breve tempo de inatividade.
Para clusters Pacemaker existentes, se a configuração já tiver sido alterada para usar socat conforme descrito em Azure Load-Balancer Detection Hardening, não há necessidade de alternar imediatamente para o azure-lb resource agent.sudo crm configure primitive fs_NW2_ASCS Filesystem device='nw2-nfs:/NW2/ASCS' directory='/usr/sap/NW2/ASCS10' fstype='nfs4' \ op start timeout=60s interval=0 \ op stop timeout=60s interval=0 \ op monitor interval=20s timeout=40s sudo crm configure primitive vip_NW2_ASCS IPaddr2 \ params ip=10.3.1.16 \ op monitor interval=10 timeout=20 sudo crm configure primitive nc_NW2_ASCS azure-lb port=62010 \ op monitor timeout=20s interval=10 sudo crm configure group g-NW2_ASCS fs_NW2_ASCS nc_NW2_ASCS vip_NW2_ASCS \ meta resource-stickiness=3000 sudo crm configure primitive fs_NW3_ASCS Filesystem device='nw3-nfs:/NW3/ASCS' directory='/usr/sap/NW3/ASCS20' fstype='nfs4' \ op start timeout=60s interval=0 \ op stop timeout=60s interval=0 \ op monitor interval=20s timeout=40s sudo crm configure primitive vip_NW3_ASCS IPaddr2 \ params ip=10.3.1.13 \ op monitor interval=10 timeout=20 sudo crm configure primitive nc_NW3_ASCS azure-lb port=62020 \ op monitor timeout=20s interval=10 sudo crm configure group g-NW3_ASCS fs_NW3_ASCS nc_NW3_ASCS vip_NW3_ASCS \ meta resource-stickiness=3000
À medida que você cria os recursos, eles podem ser atribuídos a diferentes recursos de cluster. Quando você agrupá-los, eles migrarão para um dos nós do cluster. Verifique se o status do cluster está ok e se todos os recursos foram iniciados. Não é importante em qual nó os recursos estão sendo executados.
[1] Instalar o SAP NetWeaver ASCS
Instale o SAP NetWeaver ASCS como root, usando um nome de host virtual que mapeia para o endereço IP da configuração de frontend do balanceador de carga para o ASCS. Por exemplo, para o sistema NW2, o nome do host virtual é msnw2ascs, 10.3.1.16 e o número da instância que você usou para a sonda do balanceador de carga, por exemplo 10. para o sistema NW3, o nome do host virtual é msnw3ascs, 10.3.1.13 e o número da instância que você usou para a sonda do balanceador de carga, por exemplo 20.
Você pode usar o parâmetro sapinst SAPINST_REMOTE_ACCESS_USER para permitir que um usuário não-root se conecte ao sapinst. Você pode usar o parâmetro SAPINST_USE_HOSTNAME para instalar o SAP, usando o nome do host virtual.
sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostname
Se a instalação não conseguir criar uma subpasta em /usr/sap/SID/ASCSInstance#, tente definir o proprietário como sidadm e group para sapsys da Instância ASCS# e tente novamente.
[1] Crie um IP virtual e recursos de cluster de sonda de integridade para a instância ERS do sistema SAP adicional que você está implantando no cluster. O exemplo mostrado aqui é para NW2 e NW3 ERS, usando servidor NFS altamente disponível.
sudo crm configure primitive fs_NW2_ERS Filesystem device='nw2-nfs:/NW2/ASCSERS' directory='/usr/sap/NW2/ERS12' fstype='nfs4' \ op start timeout=60s interval=0 \ op stop timeout=60s interval=0 \ op monitor interval=20s timeout=40s sudo crm configure primitive vip_NW2_ERS IPaddr2 \ params ip=10.3.1.17 \ op monitor interval=10 timeout=20 sudo crm configure primitive nc_NW2_ERS azure-lb port=62112 \ op monitor timeout=20s interval=10 sudo crm configure group g-NW2_ERS fs_NW2_ERS nc_NW2_ERS vip_NW2_ERS sudo crm configure primitive fs_NW3_ERS Filesystem device='nw3-nfs:/NW3/ASCSERS' directory='/usr/sap/NW3/ERS22' fstype='nfs4' \ op start timeout=60s interval=0 \ op stop timeout=60s interval=0 \ op monitor interval=20s timeout=40s sudo crm configure primitive vip_NW3_ERS IPaddr2 \ params ip=10.3.1.19 \ op monitor interval=10 timeout=20 sudo crm configure primitive nc_NW3_ERS azure-lb port=62122 \ op monitor timeout=20s interval=10 sudo crm configure group g-NW3_ERS fs_NW3_ERS nc_NW3_ERS vip_NW3_ERS
À medida que você cria os recursos, eles podem ser atribuídos a diferentes nós de cluster. Quando você agrupá-los, eles migrarão para um dos nós do cluster. Verifique se o status do cluster está ok e se todos os recursos foram iniciados.
Em seguida, certifique-se de que os recursos do grupo ERS recém-criado estão sendo executados no nó do cluster, oposto ao nó do cluster onde a instância ASCS para o mesmo sistema SAP foi instalada. Por exemplo, se o NW2 ASCS foi instalado no
slesmsscl1
, verifique se o grupo NW2 ERS está sendo executado noslesmsscl2
. Você pode migrar o grupo NW2 ERS paraslesmsscl2
executando o seguinte comando:crm resource migrate g-NW2_ERS slesmsscl2 force
[2] Instalar o SAP NetWeaver ERS
Instale o SAP NetWeaver ERS como raiz no outro nó, usando um nome de host virtual que mapeia para o endereço IP da configuração de front-end do balanceador de carga para o ERS. Por exemplo, para o sistema NW2, o nome do host virtual é msnw2ers, 10.3.1.17 e o número da instância que você usou para a sonda do balanceador de carga, por exemplo 12. Para o sistema NW3, o nome do host virtual msnw3ers, 10.3.1.19 e o número da instância que você usou para a sonda do balanceador de carga, por exemplo 22.
Você pode usar o parâmetro sapinst SAPINST_REMOTE_ACCESS_USER para permitir que um usuário não-root se conecte ao sapinst. Você pode usar o parâmetro SAPINST_USE_HOSTNAME para instalar o SAP, usando o nome do host virtual.
sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostname
Nota
Use SWPM SP 20 PL 05 ou superior. As versões inferiores não definem as permissões corretamente e a instalação falhará.
Se a instalação não conseguir criar uma subpasta em /usr/sap/NW2/ERSInstance#, tente configurar o proprietário para sidadm e o grupo para sapsys da pasta ERSInstance# e tente novamente.
Se foi necessário migrar o grupo ERS do sistema SAP recém-implantado para um nó de cluster diferente, não se esqueça de remover a restrição de local para o grupo ERS. Você pode remover a restrição executando o seguinte comando (o exemplo é dado para os sistemas SAP NW2 e NW3).
crm resource unmigrate g-NW2_ERS crm resource unmigrate g-NW3_ERS
[1] Adaptar os perfis de instância ASCS/SCS e ERS ao(s) sistema(s) SAP(s) recém-instalado(s). O exemplo mostrado abaixo é para NW2. Você precisará adaptar os perfis ASCS/SCS e ERS para todas as instâncias SAP adicionadas ao cluster.
- Perfil ASCS/SCS
sudo vi /sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs # Change the restart command to a start command #Restart_Program_01 = local $(_EN) pf=$(_PF) Start_Program_01 = local $(_EN) pf=$(_PF) # Add the following lines service/halib = $(DIR_CT_RUN)/saphascriptco.so service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector # Add the keep alive parameter, if using ENSA1 enque/encni/set_so_keepalive = true
Para ENSA1 e ENSA2, certifique-se de que os parâmetros do
keepalive
SO estão definidos conforme descrito na nota 1410736 SAP.- Perfil da ERS
sudo vi /sapmnt/NW2/profile/NW2_ERS12_msnw2ers # Change the restart command to a start command #Restart_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID) Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID) # Add the following lines service/halib = $(DIR_CT_RUN)/saphascriptco.so service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector # remove Autostart from ERS profile # Autostart = 1
[A] Configure os usuários SAP para o sistema SAP recém-implantado, neste exemplo NW2 e NW3.
# Add sidadm to the haclient group sudo usermod -aG haclient nw2adm sudo usermod -aG haclient nw3adm
Adicione os serviços ASCS e ERS SAP para o sistema SAP recém-instalado ao
sapservice
arquivo. O exemplo mostrado abaixo é para os sistemas SAP NW2 e NW3.Adicione a entrada de serviço ASCS ao segundo nó e copie a entrada de serviço ERS para o primeiro nó. Execute os comandos para cada sistema SAP no nó, onde a instância ASCS para o sistema SAP foi instalada.
# Execute the following commands on slesmsscl1,assuming the NW2 ASCS instance was installed on slesmsscl1 cat /usr/sap/sapservices | grep ASCS10 | sudo ssh slesmsscl2 "cat >>/usr/sap/sapservices" sudo ssh slesmsscl2 "cat /usr/sap/sapservices" | grep ERS12 | sudo tee -a /usr/sap/sapservices # Execute the following commands on slesmsscl2, assuming the NW3 ASCS instance was installed on slesmsscl2 cat /usr/sap/sapservices | grep ASCS20 | sudo ssh slesmsscl1 "cat >>/usr/sap/sapservices" sudo ssh slesmsscl1 "cat /usr/sap/sapservices" | grep ERS22 | sudo tee -a /usr/sap/sapservices
[A] Desativação
systemd
de serviços da instância ASCS e ERS SAP. Esta etapa só é aplicável se a estrutura de inicialização SAP for gerenciada pelo systemd de acordo com o SAP Note 3115048Nota
Ao gerenciar instâncias SAP como SAP ASCS e SAP ERS usando a configuração de cluster SLES, você precisaria fazer modificações adicionais para integrar o cluster com a estrutura de início SAP baseada em sistema nativa. Isso garante que os procedimentos de manutenção não comprometam a estabilidade do cluster. Depois de instalar ou alternar a estrutura de inicialização do SAP para a configuração habilitada para o sistema de acordo com o SAP Note 3115048, você deve desativar os
systemd
serviços para as instâncias ASCS e ERS SAP.# Stop all ASCS and ERS instances using <sid>adm sapcontrol -nr 10 -function Stop sapcontrol -nr 10 -function StopService sapcontrol -nr 12 -function Stop sapcontrol -nr 12 -function StopService # Execute below command on VM where you have performed ASCS instance installation for each SAP system (e.g. slesmsscl1) sudo systemctl disable SAPNW2_10 sudo systemctl disable SAPNW3_20 # Execute below command on VM where you have performed ERS instance installation for each SAP system (e.g. slesmsscl2) sudo systemctl disable SAPNW2_12 sudo systemctl disable SAPNW2_22
[1] Crie os recursos de cluster SAP para o sistema SAP recém-instalado.
Dependendo se você estiver executando um sistema ENSA1 ou ENSA2, selecione a respetiva guia para definir os recursos para sistemas NW2 e NW3 . A SAP introduziu o suporte para ENSA2, incluindo replicação, no SAP NetWeaver 7.52. A partir da plataforma ABAP 1809, o ENSA2 é instalado por padrão. Para obter suporte a ENSA2, consulte SAP Note 2630416.
sudo crm configure property maintenance-mode="true" sudo crm configure primitive rsc_sap_NW2_ASCS10 SAPInstance \ operations \$id=rsc_sap_NW2_ASCS10-operations \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=NW2_ASCS10_msnw2ascs START_PROFILE="/sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10 sudo crm configure primitive rsc_sap_NW2_ERS12 SAPInstance \ operations \$id=rsc_sap_NW2_ERS12-operations \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=NW2_ERS12_msnw2ers START_PROFILE="/sapmnt/NW2/profile/NW2_ERS12_msnw2ers" AUTOMATIC_RECOVER=false IS_ERS=true \ meta priority=1000 sudo crm configure modgroup g-NW2_ASCS add rsc_sap_NW2_ASCS10 sudo crm configure modgroup g-NW2_ERS add rsc_sap_NW2_ERS12 sudo crm configure colocation col_sap_NW2_no_both -5000: g-NW2_ERS g-NW2_ASCS sudo crm configure location loc_sap_NW2_failover_to_ers rsc_sap_NW2_ASCS10 rule 2000: runs_ers_NW2 eq 1 sudo crm configure order ord_sap_NW2_first_start_ascs Optional: rsc_sap_NW2_ASCS10:start rsc_sap_NW2_ERS12:stop symmetrical=false sudo crm configure primitive rsc_sap_NW3_ASCS20 SAPInstance \ operations \$id=rsc_sap_NW3_ASCS20-operations \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=NW3_ASCS10_msnw3ascs START_PROFILE="/sapmnt/NW3/profile/NW3_ASCS20_msnw3ascs" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10 sudo crm configure primitive rsc_sap_NW3_ERS22 SAPInstance \ operations \$id=rsc_sap_NW3_ERS22-operations \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=NW3_ERS22_msnw3ers START_PROFILE="/sapmnt/NW3/profile/NW3_ERS22_msnw2ers" AUTOMATIC_RECOVER=false IS_ERS=true \ meta priority=1000 sudo crm configure modgroup g-NW3_ASCS add rsc_sap_NW3_ASCS20 sudo crm configure modgroup g-NW3_ERS add rsc_sap_NW3_ERS22 sudo crm configure colocation col_sap_NW3_no_both -5000: g-NW3_ERS g-NW3_ASCS sudo crm configure location loc_sap_NW3_failover_to_ers rsc_sap_NW3_ASCS10 rule 2000: runs_ers_NW3 eq 1 sudo crm configure order ord_sap_NW3_first_start_ascs Optional: rsc_sap_NW3_ASCS20:start rsc_sap_NW3_ERS22:stop symmetrical=false sudo crm configure property maintenance-mode="false"
Se você estiver atualizando de uma versão mais antiga e alternando para o servidor de fila 2, consulte a nota 2641019 SAP.
Verifique se o status do cluster está ok e se todos os recursos foram iniciados. Não é importante em qual nó os recursos estão sendo executados.
O exemplo a seguir mostra o status dos recursos do cluster, depois que os sistemas SAP NW2 e NW3 foram adicionados ao cluster.
sudo crm_mon -r
# Online: [ slesmsscl1 slesmsscl2 ]
#Full list of resources:
#stonith-sbd (stonith:external/sbd): Started slesmsscl1
# Resource Group: g-NW1_ASCS
# fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl2
# nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl2
# vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl2
# rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started slesmsscl2
# Resource Group: g-NW1_ERS
# fs_NW1_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1
# nc_NW1_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1
# vip_NW1_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1
# rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started slesmsscl1
# Resource Group: g-NW2_ASCS
# fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1
# nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1
# vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1
# rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started slesmsscl1
# Resource Group: g-NW2_ERS
# fs_NW2_ERS (ocf::heartbeat:Filesystem): Started slesmsscl2
# nc_NW2_ERS (ocf::heartbeat:azure-lb): Started slesmsscl2
# vip_NW2_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl2
# rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started slesmsscl2
# Resource Group: g-NW3_ASCS
# fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1
# nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1
# vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1
# rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started slesmsscl1
# Resource Group: g-NW3_ERS
# fs_NW3_ERS (ocf::heartbeat:Filesystem): Started slesmsscl2
# nc_NW3_ERS (ocf::heartbeat:azure-lb): Started slesmsscl2
# vip_NW3_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl2
# rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started slesmsscl2
A imagem a seguir mostra como seriam os recursos no HA Web Konsole(Hawk), com os recursos para o sistema SAP NW2 expandidos.
Prossiga com a instalação do SAP
Conclua a instalação do SAP da seguinte forma:
- Preparando seus servidores de aplicativos SAP NetWeaver
- Instalando uma instância DBMS
- Instalando um servidor de aplicativos SAP primário
- Instalando uma ou mais instâncias adicionais do aplicativo SAP
Testar a configuração do cluster multi-SID
Os testes a seguir são um subconjunto dos casos de teste nos guias de práticas recomendadas da SUSE. Eles estão incluídos para sua conveniência. Para obter a lista completa de testes de cluster, consulte a seguinte documentação:
- Se estiver usando um servidor NFS altamente disponível, siga Alta disponibilidade para SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server para aplicativos SAP.
- Se estiver usando volumes NFS do Azure NetApp Files, siga Alta disponibilidade para SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server com arquivos NetApp do Azure para aplicativos SAP
Leia sempre os guias de práticas recomendadas da SUSE e execute todos os testes adicionais que possam ter sido adicionados.
Os testes apresentados estão em um cluster multi-SID de dois nós com três sistemas SAP instalados.
Teste HAGetFailoverConfig e HACheckFailoverConfig
Execute os seguintes comandos como <sapsid>adm no nó onde a instância ASCS está sendo executada no momento. Se os comandos falharem com FAIL: memória insuficiente, isso pode ser causado por traços em seu nome de host. Esse é um problema conhecido e será corrigido pela SUSE no pacote sap-suse-cluster-connector.
slesmsscl1:nw1adm 57> sapcontrol -nr 00 -function HAGetFailoverConfig # 10.12.2019 21:33:08 # HAGetFailoverConfig # OK # HAActive: TRUE # HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 # HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 (sap_suse_cluster_connector 3.1.0) # HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/ # HAActiveNode: slesmsscl1 # HANodes: slesmsscl1, slesmsscl2 slesmsscl1:nw1adm 53> sapcontrol -nr 00 -function HACheckFailoverConfig # 19.12.2019 21:19:58 # HACheckFailoverConfig # OK # state, category, description, comment # SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version, SAPInstance includes is-ers patch slesmsscl2:nw2adm 35> sapcontrol -nr 10 -function HAGetFailoverConfig # 10.12.2019 21:37:09 # HAGetFailoverConfig # OK # HAActive: TRUE # HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 # HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 (sap_suse_cluster_connector 3.1.0) # HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/ # HAActiveNode: slesmsscl2 # HANodes: slesmsscl2, slesmsscl1 slesmsscl2:nw2adm 52> sapcontrol -nr 10 -function HACheckFailoverConfig # 19.12.2019 21:17:39 # HACheckFailoverConfig # OK # state, category, description, comment # SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version, SAPInstance includes is-ers patch slesmsscl1:nw3adm 49> sapcontrol -nr 20 -function HAGetFailoverConfig # 10.12.2019 23:35:36 # HAGetFailoverConfig # OK # HAActive: TRUE # HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 # HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 (sap_suse_cluster_connector 3.1.0) # HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/ # HAActiveNode: slesmsscl1 # HANodes: slesmsscl1, slesmsscl2 slesmsscl1:nw3adm 52> sapcontrol -nr 20 -function HACheckFailoverConfig # 19.12.2019 21:10:42 # HACheckFailoverConfig # OK # state, category, description, comment # SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version, SAPInstance includes is-ers patch
Migre manualmente a instância ASCS. O exemplo mostra a migração da instância ASCS para o sistema SAP NW2.
Estado do recurso, antes de iniciar o teste:
Full list of resources: stonith-sbd (stonith:external/sbd): Started slesmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW1_ERS fs_NW1_ERS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW1_ERS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW1_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW2_ERS fs_NW2_ERS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW2_ERS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW2_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW3_ERS fs_NW3_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW3_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW3_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started slesmsscl1
Execute os seguintes comandos como root para migrar a instância NW2 ASCS.
crm resource migrate rsc_sap_NW2_ASCS10 force # INFO: Move constraint created for rsc_sap_NW2_ASCS10 crm resource unmigrate rsc_sap_NW2_ASCS10 # INFO: Removed migration constraints for rsc_sap_NW2_ASCS10 # Remove failed actions for the ERS that occurred as part of the migration crm resource cleanup rsc_sap_NW2_ERS12
Estado do recurso após o teste:
Full list of resources: stonith-sbd (stonith:external/sbd): Started slesmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW1_ERS fs_NW1_ERS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW1_ERS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW1_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW2_ERS fs_NW2_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW2_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW2_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW3_ERS fs_NW3_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW3_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW3_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started slesmsscl1
Teste HAFailoverToNode. O teste apresentado aqui mostra a migração da instância ASCS para o sistema SAP NW2.
Estado do recurso antes de iniciar o teste:
Full list of resources: stonith-sbd (stonith:external/sbd): Started slesmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW1_ERS fs_NW1_ERS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW1_ERS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW1_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW2_ERS fs_NW2_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW2_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW2_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW3_ERS fs_NW3_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW3_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW3_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started slesmsscl1
Execute os seguintes comandos como nw2adm para migrar a instância NW2 ASCS.
slesmsscl2:nw2adm 53> sapcontrol -nr 10 -host msnw2ascs -user nw2adm password -function HAFailoverToNode "" # run as root # Remove failed actions for the ERS that occurred as part of the migration crm resource cleanup rsc_sap_NW2_ERS12 # Remove migration constraints crm resource clear rsc_sap_NW2_ASCS10 #INFO: Removed migration constraints for rsc_sap_NW2_ASCS10
Estado do recurso após o teste:
Full list of resources: stonith-sbd (stonith:external/sbd): Started slesmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW1_ERS fs_NW1_ERS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW1_ERS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW1_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW2_ERS fs_NW2_ERS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW2_ERS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW2_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW3_ERS fs_NW3_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW3_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW3_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started slesmsscl1
Simular falha de nó
Estado do recurso antes de iniciar o teste:
Full list of resources: stonith-sbd (stonith:external/sbd): Started slesmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW1_ERS fs_NW1_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW1_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW1_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW2_ERS fs_NW2_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW2_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW2_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW3_ERS fs_NW3_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW3_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW3_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started slesmsscl1
Execute o seguinte comando como raiz no nó onde pelo menos uma instância ASCS está sendo executada. Neste exemplo, executamos o comando em
slesmsscl2
, onde as instâncias ASCS para NW1 e NW3 estão em execução.slesmsscl2:~ # echo b > /proc/sysrq-trigger
Se você usa SBD, o Pacemaker não deve iniciar automaticamente no nó morto. O status depois que o nó é iniciado novamente deve ter esta aparência.
Online: [ slesmsscl1 ] OFFLINE: [ slesmsscl2 ] Full list of resources: stonith-sbd (stonith:external/sbd): Started slesmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW1_ERS fs_NW1_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW1_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW1_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW2_ERS fs_NW2_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW2_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW2_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW3_ERS fs_NW3_ERS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW3_ERS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW3_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Failed Resource Actions: * rsc_sap_NW1_ERS02_monitor_11000 on slesmsscl1 'not running' (7): call=125, status=complete, exitreason='', last-rc-change='Fri Dec 13 19:32:10 2019', queued=0ms, exec=0ms * rsc_sap_NW2_ERS12_monitor_11000 on slesmsscl1 'not running' (7): call=126, status=complete, exitreason='', last-rc-change='Fri Dec 13 19:32:10 2019', queued=0ms, exec=0ms * rsc_sap_NW3_ERS22_monitor_11000 on slesmsscl1 'not running' (7): call=127, status=complete, exitreason='', last-rc-change='Fri Dec 13 19:32:10 2019', queued=0ms, exec=0ms
Use os seguintes comandos para iniciar o Pacemaker no nó morto, limpar as mensagens SBD e limpar os recursos com falha.
# run as root # list the SBD device(s) cat /etc/sysconfig/sbd | grep SBD_DEVICE= # output is like: # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3" sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message slesmsscl2 clear systemctl start pacemaker crm resource cleanup rsc_sap_NW1_ERS02 crm resource cleanup rsc_sap_NW2_ERS12 crm resource cleanup rsc_sap_NW3_ERS22
Estado do recurso após o teste:
Full list of resources: stonith-sbd (stonith:external/sbd): Started slesmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW1_ERS fs_NW1_ERS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW1_ERS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW1_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW2_ERS fs_NW2_ERS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW2_ERS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW2_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started slesmsscl2 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started slesmsscl1 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started slesmsscl1 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started slesmsscl1 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started slesmsscl1 Resource Group: g-NW3_ERS fs_NW3_ERS (ocf::heartbeat:Filesystem): Started slesmsscl2 nc_NW3_ERS (ocf::heartbeat:azure-lb): Started slesmsscl2 vip_NW3_ERS (ocf::heartbeat:IPaddr2): Started slesmsscl2 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started slesmsscl2
Próximos passos
- Planejamento e implementação de Máquinas Virtuais do Azure para SAP
- Implantação de Máquinas Virtuais do Azure para SAP
- Implantação de DBMS de Máquinas Virtuais do Azure para SAP
- Para saber como estabelecer alta disponibilidade e planejar a recuperação de desastres do SAP HANA em VMs do Azure, consulte Alta disponibilidade do SAP HANA em máquinas virtuais (VMs) do Azure