Agrupar uma instância DO SAP ASCS/SCS num cluster de ativação pós-falha do Windows com um disco partilhado de cluster no Azure
Windows
O clustering de ativação pós-falha do Windows Server é a base de uma instalação SAP ASCS/SCS de elevada disponibilidade e DBMS no Windows.
Um cluster de ativação pós-falha é um grupo de servidores (nós) independentes de 1+n que funcionam em conjunto para aumentar a disponibilidade de aplicações e serviços. Se ocorrer uma falha de nó, o clustering de ativação pós-falha do Windows Server calcula o número de falhas que podem ocorrer e mantém um cluster em bom estado de funcionamento para fornecer aplicações e serviços. Pode escolher entre diferentes modos de quórum para alcançar o clustering de ativação pós-falha.
Pré-requisitos
Antes de iniciar as tarefas neste artigo, veja o seguinte artigo:
Clustering de ativação pós-falha do Windows Server no Azure
O clustering de ativação pós-falha do Windows Server com o Azure Máquinas Virtuais requer passos de configuração adicionais. Quando cria um cluster, tem de definir vários endereços IP e nomes de anfitriões virtuais para a instância DO SAP ASCS/SCS.
Resolução de nomes no Azure e o nome do anfitrião virtual do cluster
A plataforma cloud do Azure não oferece a opção para configurar endereços IP virtuais, como endereços IP flutuantes. Precisa de uma solução alternativa para configurar um endereço IP virtual para alcançar o recurso do cluster na cloud.
O serviço Balanceador de Carga do Azure fornece um balanceador de carga interno para o Azure. Com o balanceador de carga interno, os clientes chegam ao cluster através do endereço IP virtual do cluster.
Implemente o balanceador de carga interno no grupo de recursos que contém os nós de cluster. Em seguida, configure todas as regras de reencaminhamento de portas necessárias com as portas de pesquisa do balanceador de carga interno. Os clientes podem ligar-se através do nome do anfitrião virtual. O servidor DNS resolve o endereço IP do cluster e o balanceador de carga interno processa o reencaminhamento de portas para o nó ativo do cluster.
Importante
O IP Flutuante não é suportado numa configuração de IP secundário nic em cenários de balanceamento de carga. Para obter detalhes, veja Limitações do Balanceador de Carga do Azure. Se precisar de um endereço IP adicional para a VM, implemente uma segunda NIC.
Configuração de clustering de ativação pós-falha do Windows Server no Azure sem um disco partilhado
HA DO SAP ASCS/SCS com discos partilhados de cluster
No Windows, uma instância DO SAP ASCS/SCS contém serviços centrais sap, o servidor de mensagens SAP, os processos de servidor enqueue e os ficheiros de anfitrião global sap. Os ficheiros de anfitrião global sap armazenam ficheiros centrais para todo o sistema SAP.
Uma instância DO SAP ASCS/SCS tem os seguintes componentes:
Serviços centrais sap:
- Dois processos, uma mensagem e um servidor enqueue e um <nome> de anfitrião virtual ASCS/SCS, que é utilizado para aceder a estes dois processos.
- Estrutura do ficheiro: S:\usr\sap\<SID>\ASCS/NÚMERO de instância do SCS<>
Ficheiros de anfitrião global sap:
Estrutura de ficheiros: S:\usr\sap\<SID>\SYS...
A partilha de ficheiros sapmnt, que permite o acesso a estes S:\usr\sap\<SID>\SYS globais... através do seguinte caminho UNC:
\\<ASCS/NOME> do anfitrião virtual SCS\sapmnt\<SID>\SYS...
Processos, estrutura de ficheiros e partilha de ficheiros sapmnt de anfitrião global de uma instância DO SAP ASCS/SCS
Numa definição de elevada disponibilidade, vai agrupar instâncias DO SAP ASCS/SCS. Utilizamos discos partilhados em cluster (unidade S, no nosso exemplo), para colocar os ficheiros de anfitrião global SAP ASCS/SCS e SAP.
Arquitetura DE HA DO SAP ASCS/SCS com disco partilhado
Com a arquitetura de replicação do servidor Enqueue 1:
- O mesmo <nome> de anfitrião virtual ASCS/SCS é utilizado para aceder aos processos de servidor sap message e enqueue e aos ficheiros de anfitrião global sapmnt através da partilha de ficheiros sapmnt.
- A mesma unidade de disco partilhada do cluster S é partilhada entre eles.
Com a arquitetura de replicação do servidor Enqueue 2:
- O mesmo <nome> de anfitrião virtual ASCS/SCS é utilizado para aceder ao processo do servidor de mensagens SAP e aos ficheiros de anfitrião global sap através da partilha de ficheiros sapmnt.
- A mesma unidade de disco partilhada do cluster S é partilhada entre eles.
- Existe um nome> de anfitrião virtual ERS separado <para aceder ao processo do servidor de enqueue
Arquitetura DE HA DO SAP ASCS/SCS com disco partilhado
Servidor de Replicação de Discos Partilhados e Enqueue
O disco partilhado é suportado com a arquitetura de replicação do servidor Enqueue 1, em que a instância do Servidor de Replicação enqueue (ERS):
- não está agrupado
- utiliza o
localhostnome - é implementado em discos locais em cada um dos nós de cluster
O disco partilhado também é suportado com a arquitetura de replicação do servidor Enqueue 2, onde a instância enqueue Replication Server 2 (ERS2):
- está agrupado
- utiliza o nome do anfitrião de rede/virtual dedicado
- precisa do endereço IP do nome de anfitrião virtual do ERS para ser configurado no Azure Internal Balanceador de Carga, além do endereço IP (A)SCS
- é implementado em discos locais em cada um dos nós agrupados, pelo que não há necessidade de disco partilhado
Dica
Pode encontrar mais informações sobre o Enqueue Replication Server 1 e 2 (ERS1 e ERS2) aqui:
Colocar o Servidor de Replicação em Fila num Cluster de Ativação Pós-falha da Microsoft
Novo Replicador de Enqueue em ambientes de Cluster de Ativação Pós-falha
Opções para o disco partilhado no Azure para cargas de trabalho SAP
Existem duas opções para o disco partilhado num cluster de ativação pós-falha do Windows no Azure:
- Discos partilhados do Azure – funcionalidade que permite anexar o disco gerido do Azure a várias VMs em simultâneo.
- Utilizar o software de terceiros SIOS DataKeeper Cluster Edition para criar um armazenamento espelhado que simula o armazenamento partilhado do cluster.
Ao selecionar a tecnologia para o disco partilhado, tenha em atenção as seguintes considerações:
Disco partilhado do Azure para cargas de trabalho SAP
- Permite-lhe anexar o disco gerido do Azure a várias VMs em simultâneo sem a necessidade de software adicional para manter e operar.
- O disco partilhado do Azure com discos SSD Premium é suportado para implementação SAP em zonas de disponibilidade e conjunto de disponibilidade.
- O disco do Azure Ultra e os discos do Azure Standard não são suportados como disco partilhado do Azure para cargas de trabalho SAP.
- Certifique-se de que aprovisiona o disco do Azure Premium com um tamanho mínimo de disco, conforme especificado nos intervalos SSD Premium , para poder anexar ao número necessário de VMs em simultâneo (normalmente 2 para o cluster de Ativação Pós-falha do Windows do SAP ASCS).
SIOS
- A solução SIOS fornece a replicação de dados síncrona em tempo real entre dois discos
- Com a solução SIOS que opera com dois discos geridos e, se utilizar conjuntos de disponibilidade ou zonas de disponibilidade, os discos geridos serão colocados em clusters de armazenamento diferentes.
- A implementação nas zonas de disponibilidade é suportada
- Requer a instalação e a operação de software de terceiros, que terá de comprar adicionalmente
Disco Partilhado com o disco partilhado do Azure
A Microsoft está a oferecer discos partilhados do Azure, que podem ser utilizados para implementar a Elevada Disponibilidade do SAP ASCS/SCS com uma opção de disco partilhado.
Pré-requisitos e limitações
Atualmente, pode utilizar discos SSD Premium do Azure como um disco partilhado do Azure para a instância DO SAP ASCS/SCS. As seguintes limitações estão atualmente em vigor:
- O disco Ultra do Azure e os discos SSD Standard não são suportados como Discos Partilhados do Azure para cargas de trabalho SAP.
- O disco partilhado do Azure com discos SSD Premium é suportado para implementação SAP em zonas de disponibilidade e conjunto de disponibilidade.
- O disco partilhado do Azure com discos SSD Premium inclui dois SKUs de armazenamento.
- O armazenamento localmente redundante (LRS) para o disco partilhado premium (skuName - Premium_LRS) é suportado com a implementação no conjunto de disponibilidade do Azure.
- O armazenamento com redundância entre zonas (ZRS) para o disco partilhado premium (skuName - Premium_ZRS) é suportado com a implementação nas zonas de disponibilidade do Azure.
- MaxShares do valor do disco partilhado do Azure determina quantos nós de cluster podem utilizar o disco partilhado. Normalmente, para a instância DO SAP ASCS/SCS, irá configurar dois nós no Cluster de Ativação Pós-falha do Windows, pelo que o valor para
maxSharestem de ser definido como dois. - O grupo de colocação por proximidade do Azure não é necessário para o disco partilhado do Azure. Contudo, para a implementação sap com PPG, siga as diretrizes abaixo:
- Se estiver a utilizar o PPG para o sistema SAP implementado numa região, todas as máquinas virtuais que partilham um disco têm de fazer parte do mesmo PPG.
- Se estiver a utilizar o PPG para o sistema SAP implementado em zonas, como descrito no documento Grupos de colocação por proximidade com implementações zonais, pode anexar Premium_ZRS armazenamento a máquinas virtuais que partilham um disco.
Para obter mais detalhes sobre as limitações do disco partilhado do Azure, veja cuidadosamente a secção limitações da documentação do Disco Partilhado do Azure.
Consideração importante para o disco partilhado Premium
Seguem-se alguns dos pontos importantes a considerar para o disco partilhado do Azure Premium:
LRS para disco partilhado Premium
- A implementação sap com o disco partilhado LRS para Premium irá funcionar com um único disco partilhado do Azure num cluster de armazenamento. A instância do SAP ASCS/SCS seria afetada, em caso de problemas com o cluster de armazenamento, em que o disco partilhado do Azure é implementado.
Disco partilhado ZRS para Premium
- A latência de escrita para ZRS é superior à do LRS devido à cópia de dados entre zonais.
- A distância entre zonas de disponibilidade em diferentes regiões varia e com essa latência de disco ZRS também entre zonas de disponibilidade. Compare os discos para identificar a latência do disco ZRS na sua região.
- O ZRS para disco partilhado Premium replica de forma síncrona dados em três zonas de disponibilidade na região. Em caso de problema num dos clusters de armazenamento, o SAP ASCS/SCS continuará a ser executado, uma vez que a ativação pós-falha de armazenamento é transparente para a camada da aplicação.
- Veja a secção limitações do ZRS para obter discos geridos para obter mais detalhes.
Dica
Reveja o guia de planeamento do SAP Netweaver no Azure e o Guia do Armazenamento do Azure para cargas de trabalho SAP para obter considerações importantes ao planear a implementação do SAP.
Versões suportadas do SO
Tanto o Windows Servers 2016 como o 2019 são suportados (utilize as imagens mais recentes do datacenter).
Recomendamos vivamente a utilização do Windows Server 2019 Datacenter, como:
- O Serviço de Cluster de Ativação Pós-falha do Windows 2019 está ciente do Azure
- Existe uma maior integração e deteção da Manutenção do Anfitrião do Azure e uma experiência melhorada através da monitorização de eventos de agendamento do Azure.
- É possível utilizar o Nome de rede Distribuído (é a opção predefinida). Por conseguinte, não é necessário ter um endereço IP dedicado para o nome da rede do cluster. Além disso, não é necessário configurar este endereço IP no Azure Internal Balanceador de Carga.
Discos partilhados no Azure com o SiOS DataKeeper
Outra opção para o disco partilhado é utilizar o software de terceiros SIOS DataKeeper Cluster Edition para criar um armazenamento espelhado que simula o armazenamento partilhado do cluster. A solução SIOS fornece replicação de dados síncrona em tempo real.
Para criar um recurso de disco partilhado para um cluster:
- Anexe um disco adicional a cada uma das máquinas virtuais numa configuração de cluster do Windows.
- Execute o SIOS DataKeeper Cluster Edition em ambos os nós de máquina virtual.
- Configure o SIOS DataKeeper Cluster Edition de modo a espelhar o conteúdo do volume ligado ao disco adicional da máquina virtual de origem para o volume ligado ao disco adicional da máquina virtual de destino. O SiOS DataKeeper abstrai os volumes locais de origem e de destino e, em seguida, apresenta-os ao clustering de ativação pós-falha do Windows Server como um disco partilhado.
Obtenha mais informações sobre o DataKeeper do SIOS.
Configuração de clustering de ativação pós-falha do Windows no Azure com o SIOS DataKeeper
Nota
Não precisa de discos partilhados para elevada disponibilidade com alguns produtos DBMS, como SQL Server. SQL Server AlwaysOn replica os dados do DBMS e os ficheiros de registo do disco local de um nó de cluster para o disco local de outro nó de cluster. Neste caso, a configuração do cluster do Windows não precisa de um disco partilhado.
Configurações opcionais
Os diagramas seguintes mostram várias instâncias SAP em VMs do Azure com o Cluster de Ativação Pós-falha do Microsoft Windows para reduzir o número total de VMs.
Estes podem ser Servidores de Aplicações SAP locais num cluster SAP ASCS/SCS ou uma Função de Cluster SAP ASCS/SCS nos nós Do Microsoft SQL Server AlwaysOn.
Importante
A instalação de um Servidor de Aplicações SAP local num nó SQL Server AlwaysOn não é suportada.
Tanto o SAP ASCS/SCS como a base de dados do Microsoft SQL Server são pontos únicos de falha (SPOF). Para proteger estes SPOFs num ambiente do Windows, é utilizado o WSFC.
Embora o consumo de recursos do SAP ASCS/SCS seja bastante pequeno, recomenda-se uma redução da configuração da memória para SQL Server ou o SAP Application Server em 2 GB.
Sap Application Servers em nós WSFC com o SIOS DataKeeper
Nota
Uma vez que os Servidores de Aplicações SAP estão instalados localmente, não é necessário configurar qualquer sincronização, como mostra a imagem.
SAP ASCS/SCS no SQL Server nós AlwaysOn com o SiOS DataKeeper
Configuração opcional para Servidores de Aplicações SAP em nós WSFC com o SOFS do Windows
Configuração opcional para Servidores de Aplicações SAP em nós WSFC com o SMB de Ficheiros NetApp
para SAP ASCS/SCS no SQL Server nós AlwaysOn com o SMB de Ficheiros NetApp