Agrupar uma instância SAP ASCS/SCS em um cluster de failover do Windows usando um disco compartilhado no Azure
Mac OS
O WSFC (Cluster de Failover do Windows Server) é a base de uma instalação de alta disponibilidade (HA) SAP ASCS/SCS e sistemas de gerenciamento de banco de dados (DBMSs) no Windows.
Um cluster de failover é um grupo de 1+n servidores independentes (nós) que trabalham juntos para aumentar a disponibilidade de aplicativos e serviços. Se ocorrer uma falha de nó, o WSFC calculará o número de falhas que podem ocorrer e ainda manterá um cluster íntegro para fornecer aplicativos e serviços. Você pode escolher entre vários modos de quorum para obter clustering de failover.
Pré-requisitos
Antes de começar as tarefas neste artigo, revise o artigo Arquitetura de alta disponibilidade e cenários para 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. Ao criar um cluster, você precisa definir vários endereços IP e nomes de host virtual para a instância SAP ASCS/SCS.
Resolução de nomes no Azure e o nome do host virtual do cluster
A plataforma de nuvem do Azure não oferece a opção de configurar endereços IP virtuais, como endereços IP flutuantes. Você precisa de uma solução alternativa para configurar um endereço IP virtual para acessar 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 pelo 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 teste do balanceador de carga interno. Os clientes podem se conectar através do nome do host virtual. O servidor DNS resolve o endereço IP do cluster e o balanceador de carga interno lida com o encaminhamento de porta para o nó ativo do cluster.
Importante
Não há suporte para endereços IP flutuantes em uma configuração IP secundária para um adaptador de rede (NIC) em cenários de balanceamento de carga. Para obter detalhes, consulte Limitações do Azure Load Balancer. Se você precisar de um endereço IP adicional para a VM, implante uma segunda NIC.
SAP ASCS/SCS HA com discos compartilhados de cluster
No Windows, uma instância SAP ASCS/SCS contém serviços centrais SAP, o servidor de mensagens SAP, processos de servidor enqueue e arquivos host global SAP. Os arquivos de host global SAP armazenam arquivos centrais para todo o sistema SAP.
Uma instância SAP ASCS/SCS tem os seguintes componentes:
Serviços centrais SAP:
- Dois processos (para um servidor de mensagens e um servidor de enfileiramento) e um nome de host virtual ASCS/SCS usado para acessar os dois processos
- Estrutura do arquivo: S:\usr\sap\SID>\<ASCS/SCS número da<instância>
Arquivos de host global SAP:
Estrutura do ficheiro: S:\usr\sap\SID>\<SYS...
O compartilhamento de arquivos sapmnt, que permite o acesso a esses arquivos globais S:\usr\sap\SID>\<SYS... usando o seguinte caminho UNC:
\\<ASCS/SCS nome> do host virtual\sapmnt\SID>\<SYS...
Em uma configuração de alta disponibilidade, você agrupa instâncias SAP ASCS/SCS. Use discos compartilhados de cluster (unidade S no exemplo deste artigo) para colocar os arquivos de host global SAP ASCS/SCS e SAP.
Com uma arquitetura ERS1 (Enqueue Replication Server 1):
- O mesmo nome de host virtual ASCS/SCS é usado para acessar o servidor de mensagens SAP e enfileirar processos de servidor, além dos arquivos de host global SAP por meio do compartilhamento de arquivos sapmnt .
- O mesmo disco compartilhado de cluster (unidade S) é compartilhado entre eles.
Com a arquitetura Enqueue Replication Server 2 (ERS2):
- O mesmo nome de host virtual ASCS/SCS é usado para acessar o processo do servidor de mensagens SAP, além dos arquivos de host global SAP por meio do compartilhamento de arquivos sapmnt .
- O mesmo disco compartilhado de cluster (unidade S) é compartilhado entre eles.
- Há um nome de host virtual ERS separado para acessar o processo do servidor enqueue.
Discos compartilhados e Enqueue Replication Server
Os discos compartilhados são suportados com uma arquitetura ERS1, onde a instância ERS1:
- Não está agrupado.
- Usa um
localhostnome. - É implantado em discos locais em cada um dos nós do cluster.
Discos compartilhados também são suportados com uma arquitetura ERS2, onde a instância ERS2:
- Está agrupado.
- Usa um nome de host virtual ou de rede dedicado.
- Precisa que o endereço IP do nome do host virtual ERS seja configurado em um balanceador de carga interno do Azure, além do endereço IP (A)SCS.
- É implantado em discos locais em cada um dos nós clusterizados, portanto, não há necessidade de um disco compartilhado.
Para obter mais informações sobre ERS1 e ERS2, consulte Enqueue Replication Server in a Microsoft Failover Cluster e New Enqueue Replicator in Failover Cluster environments no site da SAP.
Opções para discos compartilhados no Azure para cargas de trabalho SAP
Há 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 simule o armazenamento compartilhado em cluster.
Ao selecionar a tecnologia para discos compartilhados, lembre-se das seguintes considerações sobre discos compartilhados do Azure para cargas de trabalho SAP:
- O uso de discos compartilhados do Azure com discos SSD Premium do Azure é suportado para implantação SAP em conjuntos de disponibilidade e zonas de disponibilidade.
- Os discos de Armazenamento de Disco Ultra do Azure e os discos SSD Padrão do Azure não são suportados como discos partilhados do Azure para cargas de trabalho SAP.
- Certifique-se de provisionar discos SSD Premium do Azure com um tamanho mínimo de disco, conforme especificado em intervalos de SSD Premium, para poder se conectar ao número necessário de VMs simultaneamente. Normalmente, você precisa de duas VMs para clusters de failover do Windows SAP ASCS.
Tenha em mente as seguintes considerações sobre o SIOS:
- A solução SIOS fornece replicação de dados síncrona em tempo real entre dois discos.
- Com a solução 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 é suportada.
- A solução SIOS requer a instalação e operação de software de terceiros, que você precisa comprar separadamente.
Discos partilhados do Azure
Você pode implementar o SAP ASCS/SCS HA com discos compartilhados do Azure.
Pré-requisitos e limitações
Atualmente, você pode usar discos SSD Premium do Azure como discos compartilhados do Azure para a instância SAP ASCS/SCS. Estão atualmente em vigor as seguintes limitações:
- Os discos de Armazenamento de Disco Ultra do Azure e os discos SSD padrão não são suportados como discos partilhados do Azure para cargas de trabalho SAP.
- Os discos partilhados do Azure com discos SSD Premium têm suporte para implementação SAP em conjuntos de disponibilidade e zonas de disponibilidade.
- Os discos partilhados do Azure com discos SSD Premium são fornecidos com duas opções de armazenamento:
- O armazenamento localmente redundante (LRS) para discos compartilhados SSD Premium (
skuNamevalor de) é suportado com a implantação em conjuntos dePremium_LRSdisponibilidade. - O armazenamento com redundância de zona (ZRS) para discos compartilhados SSD Premium (
skuNamevalor de ) é suportado com a implantação em zonas dePremium_ZRSdisponibilidade.
- O armazenamento localmente redundante (LRS) para discos compartilhados SSD Premium (
- O valor de disco compartilhado do Azure maxShares determina quantos nós de cluster podem usar o disco compartilhado. Para uma instância SAP ASCS/SCS, normalmente você configura dois nós no WSFC. Em seguida, defina o valor para
maxShares2. - Um grupo de posicionamento de proximidade (PPG) do Azure não é necessário para discos compartilhados do Azure. Mas para a implantação do SAP com PPGs, siga estas diretrizes:
- Se você estiver usando PPGs para um sistema SAP implantado em uma região, todas as máquinas virtuais que compartilham um disco devem fazer parte do mesmo PPG.
- Se você estiver usando PPGs para um sistema SAP implantado em zonas, conforme descrito em Grupos de posicionamento de proximidade com implantações zonais, poderá anexar
Premium_ZRSarmazenamento a máquinas virtuais que compartilham um disco.
Para obter mais informações, consulte a seção Limitações da documentação dos discos compartilhados do Azure.
Considerações importantes para discos compartilhados SSD Premium
Considere estes pontos importantes sobre os discos compartilhados do SSD Premium do Azure:
LRS para discos partilhados 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 houver um problema com o cluster de armazenamento onde o disco compartilhado do Azure está implantado, isso afetará sua instância SAP ASCS/SCS.
ZRS para discos compartilhados SSD Premium:
- A latência de gravação do ZRS é maior do que a do LRS devido à cópia interzonal de dados.
- A distância entre as zonas de disponibilidade em diferentes regiões varia, assim como a latência do disco ZRS nas zonas de disponibilidade. Faça um benchmark de seus discos para identificar a latência dos discos ZRS em 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 houver um problema em um dos clusters de armazenamento, sua instância SAP ASCS/SCS continuará a ser executada porque o failover de armazenamento é transparente para a camada de aplicativo.
- Para obter mais informações, consulte a seção Limitações da documentação sobre o ZRS para discos gerenciados.
Para obter outras considerações importantes sobre como planejar sua implantação SAP, revise Planejar e implementar uma implantação SAP nos tipos de Armazenamento do Azure e do Azure para cargas de trabalho SAP.
Versões de SO suportadas
Windows Server 2016, 2019 e posterior são suportados. Use as imagens mais recentes do datacenter.
É altamente recomendável 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 do host do Azure e experiência aprimorada monitorando eventos agendados do Azure.
- Você pode usar nomes de rede distribuídos. (É a opção padrão.) Não é necessário ter um endereço IP dedicado para o nome da 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 o SIOS DataKeeper
Outra opção para discos compartilhados é usar o SIOS DataKeeper Cluster Edition para criar um armazenamento espelhado que simula o armazenamento compartilhado de cluster. A solução SIOS fornece replicação de dados síncrona em tempo real.
Para criar um recurso de disco compartilhado para um cluster:
- Anexe um disco adicional a cada uma das máquinas virtuais em uma configuração de cluster do Windows.
- Execute o SIOS DataKeeper Cluster Edition em ambos os nós da máquina virtual.
- Configure o SIOS DataKeeper Cluster Edition para espelhar o conteúdo do volume adicional conectado ao disco da máquina virtual de origem para o volume adicional conectado ao disco da máquina virtual de destino. O SIOS DataKeeper abstrai os volumes locais de origem e de destino e, em seguida, apresenta-os ao WSFC como um disco compartilhado.
Nota
Você não precisa de discos compartilhados para alta disponibilidade com alguns produtos DBMS, como o SQL Server. O SQL Server Always On replica dados DBMS e arquivos de log do disco local de um nó de cluster para o disco local de outro nó de cluster. Nesse caso, a configuração do cluster do Windows não precisa de um 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 servidores de aplicativos SAP locais em um cluster SAP ASCS/SCS ou uma função de cluster SAP ASCS/SCS em nós Always On do Microsoft SQL Server.
Importante
Não há suporte para a instalação de um servidor de aplicativos SAP local em um nó Always On do SQL Server.
Tanto o SAP ASCS/SCS quanto o banco de dados do Microsoft SQL Server são pontos únicos de falha (SPOFs). O WSFC ajuda a proteger esses SPOFs em um ambiente Windows.
Embora o consumo de recursos do SAP ASCS/SCS seja relativamente pequeno, recomendamos uma redução de 2 GB na configuração de memória do SQL Server ou do servidor de aplicativos SAP.
Este diagrama ilustra os servidores de aplicativos SAP em nós WSFC com o uso do SIOS DataKeeper:
Como os servidores de aplicativos SAP são instalados localmente, não há necessidade de configurar qualquer sincronização.
Este diagrama ilustra o SAP ASCS/SCS em nós Always On do SQL Server com o uso do SIOS DataKeeper:
Para obter informações sobre outras configurações, consulte os seguintes recursos: