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

  • Artigo

Esta secção aplica-se a:

Windows logo. Windows e Linux logo. Linux

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

Nota

A reinicialização da VM do Azure protege principalmente VMs e não 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. Também oferece indiretamente "maior disponibilidade" dos sistemas SAP. Também não há SLA para o tempo necessário para reiniciar uma VM após uma interrupção de host planejada ou não planejada, 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 sistema de gerenciamento de banco de dados (DBMS).

Outro elemento importante da infraestrutura para alta disponibilidade é o armazenamento. Por exemplo, o SLA de Armazenamento do Azure tem 99,9% de disponibilidade. Se você implantar todas as VMs e seus discos em uma única conta de armazenamento do Azure, a possível indisponibilidade do Armazenamento do Azure causará a indisponibilidade de todas as VMs colocadas nessa conta de armazenamento e de todos os componentes SAP 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 aplicativos de VM e SAP.

Os discos gerenciados do Azure são colocados automaticamente no domínio de falha da máquina virtual à qual estão conectados. Se você colocar duas máquinas virtuais em um conjunto de disponibilidade e usar discos gerenciados, a plataforma também se encarregará de distribuir os discos gerenciados em diferentes domínios de falha. 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 de infraestrutura 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 a alta disponibilidade da infraestrutura do Azure e discos gerenciados pode ter esta aparência:

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

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á sendo executada em um domínio de falha e atualização diferente do Azure. 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 obter mais informações, consulte a seção Conjuntos de disponibilidade do Azure.

    A potencial indisponibilidade planejada ou não planejada de uma falha do Azure ou domínio de atualização 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, esteja ciente 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 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 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 não estar disponíveis no caso de uma interrupção de armazenamento.

  • Maior disponibilidade de instâncias SAP ASCS/SCS

    Nesse cenário, utilize a reinicialização da VM do Azure para proteger a VM com a instância SAP ASCS/SCS instalada. No caso de tempo de inatividade planejado ou não planejado dos servidores do Azure, as VMs são reiniciadas em outro servidor disponível. Como mencionado anteriormente, a reinicialização da VM do Azure protege principalmente VMs e não aplicativos, neste caso a instância ASCS/SCS. Através da reinicialização da VM, você alcança indiretamente a "maior disponibilidade" da instância 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 ASCS/SCS como um único ponto de falha (SPOF) em execução em uma única VM determinará a disponibilidade de todo o cenário SAP.

  • Maior disponibilidade do servidor DBMS

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

    Um DBMS que está sendo executado em uma única VM também é um SPOF e é o fator determinante para a disponibilidade de todo o cenário SAP.

Usando o Autostart para instâncias 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 1909114 da Base de conhecimento SAP. 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 de uma instância do servidor de aplicativos SAP em uma VM e uma única VM eventualmente sendo reiniciada, o Autostart não é crítico. Mas você pode habilitá-lo adicionando o seguinte parâmetro ao perfil inicial da instância SAP Advanced Business Application Programming (ABAP) ou Java:

Autostart = 1

Nota

O parâmetro Autostart também tem certas deficiências. Especificamente, o parâmetro dispara o início de uma instância 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, as reinicializações dos serviços SAP também são uma ocorrência comum para a funcionalidade SAP Software Lifecycle Management, como o Software Update Manager (SUM) ou outras atualizações ou upgrades. Essas funcionalidades não esperam que uma instância seja reiniciada automaticamente. Portanto, o parâmetro Autostart deve ser desativado antes de executar essas tarefas. O parâmetro Autostart também não deve ser usado para instâncias SAP clusterizadas, como ASCS/SCS/CI.

Para obter mais informações sobre o Autostart para instâncias SAP, consulte os seguintes artigos:

Próximos passos

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