Clusterizar uma instância de ASCS/SCS do SAP em um cluster de failover do Windows usando um disco compartilhado no Azure

Windows

O Clustering de Failover do Windows Server (WSFC) é a base de uma instalação do SAP ASCS/SCS de alta disponibilidade (HA) e sistemas de gerenciamento de banco de dados (DBMSs) no Windows.

Um cluster de failover é um grupo servidores 1+n independentes (nós) que trabalham juntos para aumentar a disponibilidade de aplicativos e serviços. Se ocorrer uma falha em um nó, o WSFC irá calcular o número de falhas que podem ocorrer e manter um cluster íntegro para fornecer serviços e aplicativos. Você pode escolher entre diversos modos de quorum para obter o clustering de failover.

Pré-requisitos

Antes de começar a executar as tarefas neste artigo, leia o artigo Arquitetura e cenários de alta disponibilidade para o SAP NetWeaver.

Clustering de Failover do Windows Server no Azure

O WSFC com máquinas virtuais (VMs) do Azure requer etapas de configuração adicionais. Quando você compila um cluster, precisa definir vários endereços IP e nomes de host virtual para a instância do SAP ASCS/SCS.

Resolução de nomes no Azure e nome do host virtual do cluster

A plataforma de nuvem do Azure não oferece a opção de configurar endereços IP virtual, como endereços IPs flutuantes. Você precisa de uma solução alternativa para configurar um endereço IP virtual a fim de alcançar o recurso de cluster na nuvem.

O serviço Azure Load Balancer fornece um balanceador de carga interno para o Azure. Com o balanceador de carga interno, os clientes alcançam o cluster por meio do endereço IP virtual do cluster.

Implante o balanceador de carga interno no grupo de recursos que contém os nós do cluster. Em seguida, configure todas as regras de encaminhamento de porta necessárias usando as portas de sondagem do balanceador de carga interno. Os clientes podem se conectar por meio do nome de host virtual. O servidor DNS resolve o endereço IP do cluster e o balanceador de carga interno trata da porta que encaminha para o nó ativo do cluster.

Alta disponibilidade do SAP ASCS/SCS com discos compartilhados do cluster

No Windows, uma instância do SAP ASCS/SCS contém os serviços centrais do SAP, o servidor de mensagens do SAP, os processos de servidor de enfileiramento e os arquivos de host global do SAP. Os arquivos de host global SAP armazenam arquivos centrais para todo o sistema SAP.

Uma instância do SAP ASCS/SCS tem os seguintes componentes:

• Serviços centrais do SAP:

  • Dois processos (para um servidor de mensagens e um servidor de enfileiramento) e um nome de host virtual de ASCS/SCS que é usado para acessar os dois processos
  • Estrutura do arquivo: S:\usr\sap\<SID>\ASCS/SCS<número da instância>

• Arquivos de host global do SAP:

  • Estrutura do arquivo: S:\usr\sap\<SID>\SYS...

  • O compartilhamento do arquivo sapmnt, que habilita o acesso a esses arquivos globais S:\usr\sap\<SID>\SYS... usando o seguinte caminho UNC:

    \\<nome do host virtual do ASCS/SCS>\sapmnt\<SID>\SYS...

Em uma configuração de alta disponibilidade, você clusteriza instâncias do SAP ASCS/SCS. Você deve usar discos compartilhados de cluster (unidade S, no exemplo deste artigo), para posicionar os arquivos de host global do SAP e do ASCS/SCS do SAP e do SAP.

Com uma arquitetura do Servidor de Replicação de Enfileiramento de Espera 1 (ERS1):

• O mesmo nome de host virtual de ASCS/SCS é usado para acessar os processos do servidor de mensagens e enfileiramento do SAP, além dos arquivos do host global do SAP por meio do compartilhamento do arquivo sapmnt.
• O mesmo disco compartilhado de cluster (unidade S) é compartilhado entre eles.

Com a arquitetura do Servidor de Replicação de Enfileiramento de Espera 2 (ERS2):

• O mesmo nome de host virtual de ASCS/SCS é usado para acessar os processos do servidor de mensagens do SAP, além dos arquivos do host global do SAP por meio do compartilhamento do arquivo sapmnt.
• O mesmo disco compartilhado de cluster (unidade S) é compartilhado entre eles.
• Existe um nome do host virtual do ERS separado para acessar o processo do servidor de enfileiramento.

Discos Compartilhados e Servidor de Replicação de Enfileiramento

Os discos compartilhados têm suporte em uma arquitetura ERS1 na qual a instância ERS1:

• Não é clusterizada.
• Usa um nome localhost.
• Está implantada em discos locais em cada um dos nós de cluster.

Os discos compartilhados também têm suporte em uma arquitetura ERS2 na qual a instância ERS2:

• É clusterizada.
• Usa um nome de host de rede ou virtual dedicado.
• Precisa que o endereço IP do nome do host virtual do ERS seja configurado em um balanceador de carga interno do Azure, além do endereço IP do (A)SCS.
• Está implantada em discos locais em cada um dos nós clusterizados e, portanto, não há necessidade de um disco compartilhado.

Para obter mais informações sobre o ERS1 e o ERS2, confira Servidor de Replicação de Enfileiramento em um Cluster de Failover da Microsoft e Novo Replicador de Enfileiramento em ambientes de Cluster de Failover no site do SAP.

Opções para discos compartilhados no Azure para cargas de trabalho do SAP

Existem duas opções para discos compartilhados em um cluster de failover do Windows no Azure:

• Use discos compartilhados do Azure para anexar discos gerenciados do Azure a várias VMs simultaneamente.
• Use o SIOS DataKeeper Cluster Edition para criar um armazenamento espelhado que simula o armazenamento compartilhado do cluster.

Ao selecionar a tecnologia para os discos compartilhados, tenha em mente as seguintes considerações sobre os discos compartilhados do Azure para cargas de trabalho do SAP:

• O uso de discos compartilhados do Azure com discos SSD Premium do Azure tem suporte para a implantação do SAP no conjunto de disponibilidade e nas zonas de disponibilidade.
• Os discos do Armazenamento de Disco Ultra do Azure e os discos SSD Standard do Azure não têm suporte como discos compartilhados do Azure para cargas de trabalho do SAP.
• Certifique-se de provisionar discos SSD Premium do Azure com um tamanho mínimo de disco, conforme especificado em Faixas de SSD Premium, para poder anexá-los simultaneamente ao número necessário de VMs. De modo geral, você precisa de duas VMs para os clusters de failover do Windows do ASCS do SAP.

Tenha em mente as seguintes considerações sobre o SIOS:

• A solução da SIOS fornece uma replicação síncrona de dados em tempo real entre dois discos.
• Com a solução da SIOS, você opera com dois discos gerenciados. Se você estiver usando conjuntos de disponibilidade ou zonas de disponibilidade, os discos gerenciados estarão em clusters de armazenamento diferentes.
• A implantação em zonas de disponibilidade têm suporte.
• A solução da SIOS requer a instalação e a operação de software de terceiros, que você precisa comprar separadamente.

Discos compartilhados do Azure

Você pode implementar a HA DO ASCS/SCS do SAP com discos compartilhados do Azure.

Pré-requisitos e limitações

No momento, você pode usar os discos SSD Premium do Azure como discos compartilhados do Azure para a instância do ASCS/SCS do SAP. Existem as seguintes limitações no momento:

• Os discos do Armazenamento de Disco Ultra e os discos SSD Standard do Azure não têm suporte como discos compartilhados do Azure para cargas de trabalho do SAP.
• Os discos Compartilhados do Azure com discos SSD Premium têm suporte para a implantação do SAP em conjuntos de disponibilidade e zonas de disponibilidade.
• Os discos compartilhados do Azure com discos SSD Premium vêm com duas opções de armazenamento:
  • O armazenamento com redundância local (LRS) para discos compartilhados SSD Premium (valor do skuName de Premium_LRS) tem suporte com a implantação em conjuntos de disponibilidade.
  • O armazenamento com redundância de zona (ZRS) para discos compartilhados SSD Premium (valor skuName de Premium_ZRS) tem suporte com a implantação em zonas de disponibilidade.
• O valor do disco compartilhado do Azure maxShares determina quantos nós de cluster podem usar o disco compartilhado. Para uma instância do ASCS/SCS do SAP, você de modo geral configura dois nós no WSFC. Em seguida, você deve definir o valor de maxShares como 2.
• Um Grupo de Posicionamento por Proximidade (PPG) do Azure não é necessário para os discos compartilhados do Azure. Mas para a implantação do SAP com PPGs, siga as diretrizes abaixo:
  • Se você estiver usando PPGs para um sistema SAP implantado em uma região, todas as máquinas virtuais que compartilham um disco precisam fazer parte do mesmo PPG.
  • Se estiver usando PPGs para um sistema SAP implantado em diversas zonas, conforme descrito em Grupos de Posicionamento por Proximidade com implantações zonais, você poderá anexar o armazenamento Premium_ZRS às máquinas virtuais que compartilham um disco.

Para obter mais informações, leia a seção Limitações da documentação para discos compartilhados do Azure.

Considerações importantes para discos compartilhados SSD Premium

Leve em conta esses pontos importantes sobre discos compartilhados SSD Premium do Azure:

• LRS para discos compartilhados SSD Premium:

  • A implantação do SAP com LRS para discos compartilhados SSD Premium opera com um único disco compartilhado do Azure em um cluster de armazenamento. Se ocorrer um problema com o cluster de armazenamento em que o disco compartilhado do Azure estiver implantado, sua instância do ASCS/SCS do SAP será afetada.

• ZRS para discos compartilhados SSD Premium:

  • A latência de gravação para ZRS é maior que a do LRS devido à cópia de dados entre zonas.
  • A distância entre as zonas de disponibilidade em regiões diferentes varia, assim como a latência do disco ZRS nas diversas zonas de disponibilidade. Crie um parâmetro de comparação de seus discos para identificar a latência dos discos ZRS na sua região.
  • O ZRS para discos compartilhados SSD Premium replica dados de forma síncrona em três zonas de disponibilidade na região. Se ocorrer um problema em um dos clusters de armazenamento, sua instância do ASCS/SCS do SAP continuará sendo executada porque o failover de armazenamento é transparente para a camada de aplicativo.
  • Para obter mais informações, leia a seção Limitações da documentação sobre ZRS para discos gerenciados.

Para outras considerações importantes sobre como planejar sua implantação do SAP, leia Planejar e implementar uma implantação do SAP no Azure e Tipos de Armazenamento do Microsoft Azure para cargas de trabalho do SAP.

Versões de SO com suporte

O Windows Server 2016, 2019 e posteriores têm suporte. Use as imagens do datacenter mais recentes.

Recomendamos fortemente usar pelo menos o Windows Server 2019 Datacenter, pelos seguintes motivos:

• O WSFC no Windows Server 2019 reconhece o Azure.
• O Windows Server 2019 Datacenter inclui integração e reconhecimento da manutenção de host do Azure e uma experiência aprimorada ao monitorar os eventos agendados do Azure.
• Você pode usar nomes de rede distribuída (essa é a opção padrão). Não é necessário ter um endereço IP dedicado para o nome de rede do cluster. Além disso, você não precisa configurar um endereço IP em um balanceador de carga interno do Azure.

Discos compartilhados no Azure com SIOS DataKeeper

Outra opção para discos compartilhados é usar o SIOS DataKeeper Cluster Edition para criar um armazenamento espelhado que simula o armazenamento compartilhado do cluster. A solução SIOS fornece replicação síncrona de dados em tempo real.

Para criar um recurso de disco compartilhado para um cluster:

1. Anexe um disco adicional a cada uma das máquinas virtuais em uma configuração de cluster do Windows.
2. Execute o SIOS DataKeeper Cluster Edition em ambos os nós da máquina virtual.
3. Configure o SIOS DataKeeper Cluster Edition para que reflita o conteúdo do volume adicional anexado ao disco da máquina virtual de origem no volume adicional anexado ao disco da máquina virtual de destino. O SIOS DataKeeper abstrai os volumes locais de origem e de destino e, a seguir, os apresenta ao WSFC como um único disco compartilhado.

Configurações opcionais

Os diagramas a seguir mostram várias instâncias SAP em VMs do Azure que executam o Clustering de Failover do Windows Server para reduzir o número total de VMs.

Essa configuração pode ser de servidores de aplicativos do SAP locais em um cluster do ASCS/SCS do SAP ou uma função de cluster do ASCS/SCS do SAP em nós Always On do Microsoft SQL Server.

Tanto o ASCS/SCS do SAP quanto o banco de dados do Microsoft SQL Server são recursos com ponto único de falha (SPOFs). O WSFC ajuda a proteger esses SPOFs em um ambiente do Windows.

Embora o consumo de recursos do ASCS/SCS do SAP seja bastante pequeno, recomendamos uma redução de 2 GB na configuração de memória tanto para o SQL Server quanto para o servidor de aplicativos do SAP.

Esse diagrama ilustra os servidores de aplicativos do SAP em nós do WSFC com o uso do SIOS DataKeeper:

Como os servidores de aplicativos do SAP estão instalados localmente, não é necessário configurar nenhuma sincronização.

Esse diagrama ilustra o ASCS/SCS do SAP em nós Always On do SQL Server com o uso do SIOS DataKeeper:

Para obter informações sobre outras configurações, confira os seguintes recursos:

• Configuração opcional para servidores de aplicativos do SAP em nós do WSFC usando o Servidor de Arquivos de Escalabilidade Horizontal do Windows

• Configuração opcional para servidores de aplicativos do SAP em nós do WSFC usando o protocolo SMB no Azure NetApp Files

• Configuração opcional para o ASCS/SCS do SAP em nós Always On do SQL Server usando o Servidor de Arquivos de Escalabilidade Horizontal do Windows

• Configuração opcional o ASCS/SCS do SAP em nós Always On do SQL Server usando o protocolo SMB no Azure NetApp Files

Próximas etapas

• Preparar a infraestrutura do Azure para alta disponibilidade do SAP usando o cluster de failover do Windows e o disco compartilhado para a instância SAP ASCS/SCS

• Instalar a alta disponibilidade do SAP NetWeaver em um cluster de failover do Windows e em um disco compartilhado para uma instância do SAP ASCS/SCS