Implementação de alta disponibilidade para aplicativos SAP em IBM Power Virtual Server

A execução do SAP no IBM® Power® Virtual Server oferece uma plataforma consistente para aplicativos tradicionais e baseados em SAP HANA, desempenho de classe mundial, resiliência para cargas de trabalho críticas e uma infraestrutura flexível.

Use as informações a seguir para entender como implementar soluções de alta disponibilidade para os sistemas SAP usando instâncias do Power Virtual Server.

SAP arquitetura do sistema

Os principais componentes de um sistema SAP são os seguintes.

Sistema SAP HANA

O sistema SAP HANA fornece o banco de dados do locatário para os servidores de aplicativos SAP.

SAP servidor de aplicativos

SAP os servidores de aplicativos fornecem a parte funcional de uma solução de aplicativo SAP S/4HANA ou outra solução de aplicativo. Todos os dados de personalização e de aplicativos de um sistema SAP são armazenados em um banco de dados de locatário de um sistema SAP HANA.

Um sistema de aplicativos SAP é instalado e configurado como uma única unidade e consiste nas seguintes instâncias de aplicativos.

Uma instância do ABAP System Central Services (instância ASCS) Cada sistema de aplicativos SAP tem exatamente uma instância do ASCS, que consiste em um servidor de mensagens e um servidor de filas.
Uma ou mais instâncias de servidor de aplicativos (instâncias AS)
- O servidor de aplicativos primário (PAS) é a primeira instância do AS instalada em um sistema ABAP.
- Outras instâncias de AS instaladas para um sistema ABAP são chamadas de servidores de aplicativos adicionais (AAS).

Tanto as instâncias do servidor de aplicativos quanto a instância do ASCS dependem de um sistema de arquivos compartilhado e exigem acesso de leitura/gravação a ele.

sistema de arquivos compartilhado : Normalmente, o sistema de arquivos compartilhado é exportado em um servidor NFS e montado em todas as instâncias.

A Figura 1 ilustra os componentes técnicos de um sistema SAP.

Figura 1. Componentes técnicos para sistemas SAP — Componentes técnicos para sistemas SAP

Considerações sobre a implementação de uma solução de alta disponibilidade SAP

Para proteção de alta disponibilidade, recomenda-se instalar servidores de aplicativos de forma redundante. Instale pelo menos dois servidores de aplicativos (PAS e AAS) e use grupos de login para implementar o balanceamento de carga. Se um servidor de aplicativos falhar, todas as sessões de usuário conectadas a essa instância serão interrompidas. O usuário faz login novamente e o balanceamento de carga redireciona o usuário para outro servidor de aplicativos que ainda está em execução.

Os outros componentes técnicos, como a instância do ASCS, o banco de dados SAP HANA e o sistema de arquivos compartilhados, são pontos únicos de falha e devem ser protegidos.

Instância do ASCS

A melhor maneira de proteger a instância do ASCS é implementar uma instância do Enqueue Replication Server (ERS) em um servidor virtual adicional e usar o software de clustering HA para automatizar o failover.

Instale o ASCS e o ERS em um disco compartilhado anexado às duas instâncias do servidor virtual ou em um sistema de arquivos NFS.

O servidor de fila da instância do ASCS gerencia a tabela de bloqueio, e o ERS cria uma cópia replicada da tabela de bloqueio em sua memória principal. Se o servidor de fila tiver que ser reiniciado, a tabela de bloqueios será reconstruída usando a cópia no ERS, e todos os bloqueios serão mantidos.

Uma simples reinicialização do servidor de mensagens é suficiente porque nenhum dado precisa ser retido.

Siga as etapas em Configuração de alta disponibilidade para SAP S/4HANA(ASCS e ERS)em um cluster Red Hat Enterprise Linux High Availability Add-On para configurar um cluster HA para a instância dos Serviços Centrais do Sistema ABAP.
sistema de arquivos compartilhado

O método recomendado para proteger o servidor NFS é implementar uma instância extra de servidor virtual. Em seguida, crie os sistemas de arquivos exportados NFS em discos compartilhados que estão anexados a ambas as instâncias do servidor virtual e automatize o failover usando o software de cluster HA.

Siga as etapas em Configuração de um servidor ativo-passivo NFS em um cluster Red Hat Enterprise Linux High Availability Add-On para configurar um cluster HA para o sistema de arquivos compartilhado.
Sistema SAP HANA

SAP HANA oferece duas abordagens para dimensionar um sistema: aumento e redução de escala. Com o conjunto abrangente e altamente dimensionável de perfis certificados IBM Power Virtual Server para SAP HANA que estão disponíveis em IBM Power Virtual Server, o foco está nas soluções de aumento de escala SAP HANA.

A melhor maneira de proteger um sistema SAP HANA é configurar um sistema SAP HANA secundário em uma instância de servidor virtual separada. Em seguida, configure a replicação do sistema SAP HANA e automatize o failover com o software de cluster HA.

A figura a seguir mostra uma visão geral da arquitetura de um sistema SAP altamente disponível que é implementado em Power Virtual Server.

Figura 2. SAP em Power Virtual Server Visão geral da arquitetura de HA — SAP em Power Virtual Server Visão geral da arquitetura de HA

SAP HANA cenários de soluções de alta disponibilidade

A solução varia de acordo com o objetivo do tempo de recuperação (RTO).

Variações para soluções de alta disponibilidade para SAP HANA
Cenário	RTO típico	Comentário
Desempenho otimizado	Alguns minutos	A menos que você tenha requisitos específicos, esse cenário é o padrão.
Ativo/Ativo (leitura habilitada)	Alguns minutos	Em uma configuração ativa/ativa (leitura ativada), a replicação do sistema SAP HANA permite o acesso de leitura ao conteúdo do banco de dados no sistema secundário.
Custo otimizado	Algumas dezenas de minutos	Em uma configuração com custo otimizado, um sistema SAP HANA de não produção é executado no nó secundário durante a operação normal. Os recursos de hardware no nó secundário são compartilhados entre o sistema de não produção e o secundário do SAP HANA System Replication. O consumo de memória da produção SAP HANA System Replication secundária é reduzido ao desativar o pré-carregamento de dados nas tabelas de colunas. Quando ocorre um failover, a instância de não produção é automaticamente interrompida antes que o nó assuma a carga de trabalho de produção. O tempo de transferência é maior em comparação com uma configuração otimizada para o desempenho.

Dependendo de suas necessidades, selecione a documentação para um dos cenários.

SAP HANA Cenário otimizado para o desempenho do System Replication

Configuração da replicação do sistema de escalonamento SAP HANA em um cluster Red Hat Enterprise Linux High Availability Add-On.
SAP HANA Cenário de custo otimizado da replicação do sistema

Configuração da replicação do sistema de aumento de escala com custo otimizado SAP HANA em um cluster Red Hat Enterprise Linux High Availability Add-On.
SAP HANA Cenário de replicação do sistema ativo-ativo (leitura ativada)

Configuração da replicação do sistema SAP HANA ativo/ativo(leitura ativada)em um cluster Red Hat Enterprise Linux High Availability Add-On.

SAP HANA cenários de soluções de recuperação de desastres

Para proteção adicional do sistema de banco de dados, replique o sistema SAP HANA para um terceiro sistema localizado em uma região diferente usando a replicação do sistema SAP HANA. Dependendo de seus requisitos, selecione uma das duas topologias disponíveis.

SAP HANA cenário de replicação de sistemas multicamadas

Com a replicação de sistemas multicamadas do SAP HANA, você pode encadear vários sistemas para obter um nível mais alto de disponibilidade.

Configuração da replicação do sistema multicamadas SAP HANA em um cluster Red Hat Enterprise Linux High Availability Add-On.
SAP HANA cenário de replicação de sistema de vários destinos

A replicação de sistemas com vários alvos permite que os sistemas primário e secundário repliquem as alterações em mais de um sistema.

Configuração da replicação do sistema SAP HANA multitarget em um cluster Red Hat Enterprise Linux High Availability Add-On.

SAP HANA solução de alta disponibilidade em um ambiente de região com várias zonas

Uma sub-rede em IBM Power Virtual Server não pode abranger vários espaços de trabalho. Não é possível mover um endereço IP de serviço para um segundo espaço de trabalho e continuar a usá-lo a partir da VPC ou de outros espaços de trabalho para acessar os serviços fornecidos. No entanto, esse recurso é necessário para configurar um cenário de replicação do sistema SAP HANA altamente disponível em um ambiente de região com várias zonas.

O agente de recursos powervs-subnet aborda essa limitação. Durante um evento de aquisição, o agente de recursos move toda a sub-rede, inclusive o endereço IP, de um espaço de trabalho para outro.

As figuras a seguir ilustram esse cenário.

Duas instâncias de servidor virtual são implementadas em espaços de trabalho separados com sub-redes diferentes.

SAP HANA está instalado em ambas as instâncias do servidor virtual e o SAP HANA System Replication está configurado.
As duas instâncias de servidor virtual são configuradas como um cluster de alta disponibilidade de dois nós com suas próprias sub-redes.
Um recurso de cluster que usa o agente de recursos powervs-subnet está configurado para Subnet 3 e IP address 3. Escolha um intervalo pequeno para o CIDR (Classless Inter-Domain Routing, roteamento entre domínios sem classe), apenas IP address 3 e um endereço IP para o gateway são alocados em Subnet 3.
SAP HANA os clientes do banco de dados usam IP address 3 para se conectar ao banco de dados.

Durante a operação normal

A sub-rede 3 é criada no espaço de trabalho 1.
A sub-rede 3 está anexada à instância 1 do servidor virtual.
O endereço IP 3 está configurado na instância 1 do servidor virtual.
O SAP HANA primário está ativo na instância 1 do servidor virtual e o SAP HANA secundário está ativo na instância 2 do servidor virtual.

Figura 3. SAP HANA em Power Virtual Server em região multizona Visão geral do HA — SAP HANA em Power Virtual Server em região multizona Visão geral do HA

Após uma aquisição de cluster

A sub-rede 3 é criada no espaço de trabalho 2.
A sub-rede 3 está anexada à instância 2 do servidor virtual.
O endereço IP 3 está configurado na instância 2 do servidor virtual.
O SAP HANA primary está ativo na instância 2 do servidor virtual.

Figura 4. SAP HANA em Power Virtual Server em região multizona HA takeover — SAP HANA em Power Virtual Server em região multizona HA takeover

Consulte as informações em Implementação de um cluster Red Hat Enterprise Linux High Availability Add-On em um ambiente de região com várias zonas sobre como preparar e configurar um cluster Red Hat Enterprise Linux (RHEL) High Availability (HA) para o agente de recursos powervs-subnet.