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

  • Artigo

Esta seção aplica-se a:

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

Se você decidir não usar funcionalidades como WSFC (Clustering de Failover do Windows Server) ou Pacemaker no Linux (atualmente há suporte apenas para o SLES (SUSE Linux Enterprise Server) 12 e versões posteriores), a reinicialização de VM do Azure será utilizada. Protege os sistemas SAP contra tempo de inatividade planejado e não planejado da infraestrutura do servidor físico do Azure e de toda a plataforma subjacente do Azure.

Observação

A Reinicialização de VM do Azure protege principalmente as VMs, não os aplicativos. Embora a Reinicialização de VM não ofereça alta disponibilidade para aplicativos SAP, ela oferece um certo nível de disponibilidade da infraestrutura. Ela também indiretamente oferece "maior disponibilidade" dos sistemas SAP. Também há um SLA para o tempo necessário para reiniciar uma VM após uma interrupção planejada ou não planejada de host, o que faz com que esse método de alta disponibilidade seja inadequado para componentes críticos de um sistema SAP. Exemplos de componentes críticos podem ser uma instância do 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 com seus discos em uma única conta de armazenamento do Azure, a indisponibilidade potencial do Armazenamento do Azure causará indisponibilidade de todas as VMs localizadas na conta de armazenamento do Azure e de todos os componentes SAP em execução dentro dessas VMs.

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

Os discos gerenciados do Azure são colocados automaticamente no domínio de falha da máquina virtual aos quais eles estão conectados. 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. Se você planeja usar a conta de armazenamento Premium, recomendamos usar discos gerenciados.

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

Diagram that shows the architecture of an SAP NetWeaver system that uses Azure infrastructure high availability and storage accounts.

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

Utilize Azure infrastructure high availability to achieve SAP application “higher availability

Para componentes críticos da 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 de servidor de aplicativo SAP é implantada em sua própria máquina virtual, que é executada em uma falha e um domínio de atualização do Azure diferentes. Para obter mais informações, consulte as seções Domínios de falha e Atualizar domínios .

    Você pode garantir essa configuração usando conjuntos de disponibilidade do Azure. Para saber mais, confira a seção Conjuntos de disponibilidade do Azure.

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

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

    Para saber mais, confira Alta disponibilidade para servidores de aplicativos SAP.

    Mesmo que você use discos gerenciados, os discos também são armazenados em uma conta de armazenamento do Azure e podem não estar disponíveis no caso de uma interrupção de armazenamento.

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

    Nesse cenário, utilize a reinicialização de 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. Como mencionado anteriormente, a Reinicialização de VM do Azure protege principalmente as VMs e não os aplicativos, neste caso, a instância do ASCS/SCS. Com a reinicialização de VM, você consegue ter "maior disponibilidade" da instância do SAP ASCS/SCS.

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

  • Maior disponibilidade do servidor DBMS

    Assim como no caso de uso da instância do SAP ASCS/SCS anterior, use a Reinicialização de VM do Azure para proteger a VM com software do DBMS instalado e obter maior disponibilidade de software DBMS por meio da reinicialização de VM.

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

Usando a inicialização automática para instâncias SAP

O SAP ofereceu a funcionalidade para iniciar as instâncias do SAP imediatamente após a inicialização do SO na VM. As instruções foram documentadas no Artigo da Base de Dados de Conhecimento SAP 1909114. No entanto, o SAP não recomenda o uso da configuração porque ela não permitirá o controle de ordem de reinicialização das instâncias 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 de uma instância do servidor de aplicativos SAP em uma VM e uma única VM eventualmente sendo reiniciada, a Inicialização automática não é crítica. Mas você pode habilitá-lo adicionando o seguinte parâmetro ao perfil de início da instância Java ou SAP ABAP (Advanced Business Application Programming):

Autostart = 1

Observação

O parâmetro Inicialização Automática tem certas limitações também. Mais detalhadamente, o parâmetro aciona o início de uma instância de Java ou SAP ABAP 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 são ocorrências comuns para a funcionalidade de gerenciamento de ciclo de vida do Software SAP, como o SUM (Software Update Manager) ou outras atualizações. Essas funcionalidades não estão esperando que uma instância seja reiniciada automaticamente. Portanto, o parâmetro Inicialização Automática deve ser desabilitado antes de executar essas tarefas. O parâmetro Inicialização Automática também não deve ser usado para instâncias do SAP que estão clusterizadas, como ASCS/SCS/CI.

Para saber mais sobre a Inicialização Automática para instâncias SAP, consulte os seguintes artigos:

Próximas etapas

Para saber mais sobre alta disponibilidade com reconhecimento de aplicativo SAP NetWeaver completa, consulte Alta disponibilidade de aplicativo SAP no Azure IaaS.