Compartilhar via

Utilizar a reinicialização da VM de infraestrutura do Azure para obter "maior disponibilidade" de um sistema SAP

Esta seção se aplica a:

Logotipo do Windows. Logotipo do Windows e do Linux. Linux

Se você decidir não usar funcionalidades como o WSFC (Clustering de Failover) do Windows Server ou o Pacemaker no Linux (atualmente compatível apenas com o SUSE Linux Enterprise Server [SLES] 12 e posterior), a reinicialização da VM do Azure será utilizada. Ele protege os sistemas SAP contra o tempo de inatividade planejado e não planejado da infraestrutura do servidor físico do Azure e da plataforma geral subjacente do Azure.

Observação

A reinicialização da VM do Azure protege principalmente as VMs e não os aplicativos. Embora a reinicialização da VM não ofereça alta disponibilidade para aplicativos SAP, ela oferece um certo nível de disponibilidade de infraestrutura. Ele também oferece indiretamente "maior disponibilidade" de sistemas SAP. Também não há nenhum SLA para o tempo necessário para reiniciar uma VM após uma interrupção planejada ou não planejada do host, o que torna esse método de alta disponibilidade inadequado para os componentes críticos de um sistema SAP. Exemplos de componentes críticos podem ser uma instância ASCS/SCS ou um DBMS (sistema de gerenciamento de banco de dados).

Outro elemento de infraestrutura importante para alta disponibilidade é o armazenamento. Por exemplo, o SLA do Armazenamento do Azure tem disponibilidade de 99,9%. Se você implantar todas as VMs e seus discos em uma única conta de armazenamento do Azure, a indisponibilidade potencial do Armazenamento do Azure causará a indisponibilidade de todas as VMs que são colocadas nessa conta de armazenamento e todos os componentes SAP que estão em execução dentro das VMs.

Em vez de colocar todas as VMs em uma única conta de armazenamento do Azure, você pode usar contas de armazenamento dedicadas para cada VM. Usando várias contas de armazenamento independentes do Azure, você aumenta a disponibilidade geral de VM e aplicativo SAP.

Os discos gerenciados do Azure são colocados automaticamente no domínio de falha da máquina virtual à qual estão anexados. Se você colocar duas máquinas virtuais em um conjunto de disponibilidade e usar discos gerenciados, a plataforma cuidará da distribuição dos discos gerenciados em diferentes domínios de falha também. Se você planeja usar uma conta de armazenamento premium, é altamente recomendável usar discos gerenciados.

Uma arquitetura de exemplo de um sistema SAP NetWeaver que usa contas de alta disponibilidade e armazenamento da infraestrutura do Azure pode ter esta aparência:

Diagrama que mostra a arquitetura de um sistema SAP NetWeaver que usa contas de armazenamento e alta disponibilidade da infraestrutura do Azure.

Uma arquitetura de exemplo de um sistema SAP NetWeaver que usa alta disponibilidade e discos gerenciados da infraestrutura do Azure pode ter esta aparência:

Utilizar a alta disponibilidade da infraestrutura do Azure para obter

Para componentes críticos do SAP, você conseguiu o seguinte até agora:

  • Alta disponibilidade de servidores de aplicativos SAP

    As instâncias do servidor de aplicativos SAP são componentes redundantes. Cada instância do servidor de aplicativos SAP é implantada em sua própria VM, que está em execução em um domínio diferente de falha e atualização do Azure. Para obter mais informações, consulte as seções Domínios de falha e domínios de atualização .

    Você pode garantir essa configuração usando conjuntos de disponibilidade do Azure. Para obter mais informações, consulte a seção conjuntos de disponibilidade do Azure .

    A indisponibilidade planejada ou não planejada de um domínio de falha ou de atualização do Azure causará a indisponibilidade de um número restrito de VMs com suas instâncias do servidor de aplicativos SAP.

    Cada instância do servidor de aplicativos SAP é colocada em sua própria conta de armazenamento do Azure. A indisponibilidade potencial de uma conta de armazenamento do Azure causará a indisponibilidade de apenas uma VM com sua instância do servidor de aplicativos SAP. No entanto, lembre-se de que há um limite no número de contas de armazenamento do Azure em uma assinatura do Azure. Para garantir o início automático de uma instância do ASCS/SCS após a reinicialização da VM, defina o parâmetro de início automático no perfil de início da instância do ASCS/SCS.

    Para obter mais informações, consulte Alta disponibilidade para servidores de aplicativos SAP.

    Mesmo se você usar discos gerenciados, os discos serão armazenados em uma conta de armazenamento do Azure e poderão ficar indisponíveis no caso de uma interrupção de armazenamento.

  • Maior disponibilidade de instâncias de SAP ASCS/SCS

    Nesse cenário, utilize a reinicialização da VM do Azure para proteger a VM com a instância do SAP ASCS/SCS instalada. No caso de tempo de inatividade planejado ou não planejado de servidores do Azure, as VMs são reiniciadas em outro servidor disponível. Conforme mencionado anteriormente, a reinicialização da VM do Azure protege principalmente as VMs e não os aplicativos, nesse caso, a instância do ASCS/SCS. Por meio da reinicialização da VM, você atinge indiretamente a "maior disponibilidade" da instância do SAP ASCS/SCS.

    Para garantir o início automático da instância do ASCS/SCS após a reinicialização da VM, defina o parâmetro de início automático no perfil de início da instância do ASCS/SCS. Essa configuração significa que a instância ASCS/SCS como um ponto único de falha (SPOF) em execução em uma única VM determinará a disponibilidade de toda a paisagem SAP.

  • Maior disponibilidade do servidor DBMS

    Como no caso de uso da instância do SAP ASCS/SCS anterior, você utiliza a reinicialização da VM do Azure para proteger a VM com software DBMS instalado e obtém "maior disponibilidade" do software DBMS por meio da reinicialização da VM.

    Um DBMS em execução em uma única VM também é um SPOF e é o fator determinante para a disponibilidade de toda a paisagem SAP.

Usando o início automático para instâncias do SAP

O SAP oferece uma configuração que permite iniciar instâncias SAP imediatamente após o início do sistema operacional na VM. As instruções estão documentadas no artigo da Base de Dados de Conhecimento sap 1909114. No entanto, o SAP não recomenda mais o uso da configuração, pois não permite o controle da ordem de reinicialização da instância se mais de uma VM for afetada ou se várias instâncias estiverem em execução por VM.

Supondo um cenário típico do Azure, com uma instância do servidor de aplicativos SAP em uma VM e uma única VM que eventualmente precise ser reiniciada, o início automático não é crítico. Mas você pode habilitá-lo adicionando o seguinte parâmetro ao perfil inicial da instância do SAP ABAP (Advanced Business Application Programming) ou java:

Autostart = 1

Observação

O parâmetro de início automático também tem certas deficiências. Especificamente, o parâmetro dispara o início de uma instância do SAP ABAP ou Java quando o serviço Windows ou Linux relacionado da instância é iniciado. Essa sequência ocorre quando o sistema operacional é inicializado. No entanto, reinicializações de serviços SAP também ocorrem comumente em funcionalidades de Gerenciamento do Ciclo de Vida do Software da SAP, como o Gerenciador de Atualizações de Software (SUM) ou outras atualizações ou melhorias. Essas funcionalidades não esperam que uma instância seja reiniciada automaticamente. Portanto, o parâmetro de início automático deve ser desabilitado antes de executar essas tarefas. O parâmetro de início automático também não deve ser usado para instâncias SAP clusterizados, como ASCS/SCS/CI.

Para obter mais informações sobre o Início Automático para instâncias do SAP, consulte os seguintes artigos:

Próximas etapas

Para obter informações sobre alta disponibilidade completa do SAP NetWeaver com reconhecimento de aplicativos, consulte alta disponibilidade do aplicativo SAP no IaaS do Azure.