Guia de planejamento de alta disponibilidade para SAP NetWeaver no Google Cloud

Este guia fornece uma visão geral das opções, recomendações e dos conceitos gerais que você precisa conhecer antes de implantar um sistema SAP NetWeaver de alta disponibilidade (HA, na sigla em inglês) no Google Cloud.

Presumimos que você já tenha uma noção sobre os conceitos e as práticas geralmente necessários para implementar um sistema de alta disponibilidade do SAP NetWeaver. Portanto, o guia se concentra principalmente no que você precisa saber para implementar esse sistema no Google Cloud.

Se você precisar saber mais sobre os conceitos e práticas gerais necessários para implementar um sistema SAP NetWeaver HA, consulte:

O foco deste guia de planejamento é exclusivamente em HA para SAP NetWeaver e não em HA para sistemas de banco de dados. Para informações sobre alta disponibilidade para SAP HANA, consulte o Guia de planejamento de alta disponibilidade do SAP HANA.

Arquitetura de implantação

No diagrama a seguir, é mostrado um cluster HA básico do Linux que usa o software de cluster do Pacemaker.

O cluster inclui dois hosts: um primário e um secundário. Cada um está localizado em uma zona diferente na mesma região.

O cluster usa o SAP Standalone Enqueue Server 2 (ENSA2). Para uma descrição de um cluster que usa a versão anterior do Standalone Enqueue Server (ENSA1), consulte Arquitetura do Standalone Enqueue Server (ENSA1).

A instância ativa do Central Services está no host principal. A instância ativa do Enqueue Replication Server 2 (ERS) está no host secundário. O Central Services e o ERS têm, cada um, o próprio endereço IP virtual (VIP, na sigla em inglês). No diagrama, "Central Services" representa ABAP SAP Central Services ou, para uma pilha do Java, SAP Central Services.

Para mais informações sobre o Standalone Enqueue Server 2 nas configurações de alta disponibilidade, consulte a Nota SAP 2711036: Uso do Standalone Enqueue Server 2 em um ambiente de alta disponibilidade (em inglês).

Uma configuração básica de HA para o SAP NetWeaver no Google Cloud com dois hosts, cada um em uma zona diferente

Arquitetura do Standalone Enqueue Server (ENSA1)

No diagrama a seguir, a instância ativa do Central Services, que contém o gerenciamento de bloqueio ou o serviço Enqueue, e a instância inativa do Enqueue Replication Server (ERS, na sigla em inglês) estão no host principal. A instância ativa do ERS e a instância inativa do Central Services estão no host secundário. Cada par de Central Services e ERS tem o próprio endereço IP virtual (VIP, na sigla em inglês). No diagrama, "Central Services" representa ABAP SAP Central Services ou, para uma pilha do Java, SAP Central Services.

Em caso de falha, o software de clustering de alta disponibilidade precisa realocar o Standalone Enqueue Server para o nó em que o Enqueue Replication Server está sendo executado para reter as informações de bloqueio. Atualize o sistema para usar o Standalone Enqueue Server 2, se a versão do software for compatível. Para mais informações, consulte a Nota SAP 2630416: suporte para o Standalone Enqueue Server 2.

Uma configuração básica de HA para o SAP NetWeaver no Google Cloud com dois hosts, cada um em uma zona diferente

A alta disponibilidade da infraestrutura do Google Cloud

O Google Cloud é altamente disponível desde a concepção, com uma infraestrutura redundante de data centers em todo o mundo que contêm zonas projetadas para serem independentes umas das outras. As zonas geralmente têm planos de alimentação, resfriamento, rede e controle isolados de outras zonas. Se um único evento de falha ocorrer, na maioria dos casos, isso afetará apenas uma zona.

Em alguns casos, é possível atender aos seus requisitos de disponibilidade sem implementar todas as proteções tradicionais no local contra falhas de hardware, armazenamento e rede, o que pode economizar tempo e dinheiro.

Antes de projetar e implementar sua estratégia de alta disponibilidade no Google Cloud, analise os contratos de nível de serviço do Google Cloud.

Para informações gerais sobre confiabilidade, privacidade e segurança do Google Cloud, consulte Confiabilidade.

Opções de cluster de alta disponibilidade para sistemas SAP no Google Cloud

Defina um cluster de alta disponibilidade (HA) para o SAP NetWeaver no Google Cloud usando os mesmos tipos de software de cluster de HA de terceiros que possam ser usados em instalações no local. O software de cluster de alta disponibilidade monitora a integridade dos sistemas e gerencia o failover quando ocorrem problemas.

É possível usar diversas soluções de software de cluster de alta disponibilidade, como estas:

  • Red Hat Enterprise Linux (RHEL) para Soluções SAP
  • SUSE Linux Enterprise Server (SLES) para aplicativos SAP
  • Cluster de failover do Windows Server

Software de cluster de HA do Linux

As versões recentes do RHEL e do SLES incluem suporte integrado de alta disponibilidade ativado especificamente para o Google Cloud. Para verificar se sua versão do Linux inclui suporte a alta disponibilidade ativada pelo Google Cloud, procure "GCP-HA" na tabela em Suporte do sistema operacional para SAP NetWeaver no Google Cloud.

Software de cluster de HA do Windows

No Windows Server, use o cluster de failover do Windows Server (WSFC, na sigla em inglês) para criar o cluster de alta disponibilidade, conforme descrito em Como executar o cluster de failover do Windows Server.

No Google Cloud, o roteamento do tráfego de entrada para o nó ativo em um cluster WSFC é gerenciado pelo Cloud Load Balancing, que não requer um IP de alias ou uma implementação de VIP de rota estática.

O Cloud Load Balancing usa verificações de integridade para determinar o nó ativo.

Zonas do Google Cloud, regiões e implantações de alta disponibilidade do SAP NetWeaver

Implante os nós do cluster de HA em duas ou mais zonas do Compute Engine na mesma região. A implantação dos nós em zonas diferentes garante que eles estejam em máquinas físicas distintas e também protege contra a possibilidade muito improvável de uma falha zonal.

Manter as zonas dentro da mesma região garante que os nós estejam próximos o suficiente geograficamente para atender aos requisitos de latência do SAP para sistemas de alta disponibilidade.

Máquinas virtuais do Compute Engine e implantações de HA do SAP NetWeaver

Para ser compatível com a alta disponibilidade, as VMs do Compute Engine são respaldadas pela migração em tempo real e pela reinicialização automática.

Migração em tempo real do Compute Engine

O Compute Engine monitora o estado da infraestrutura subjacente. Quando ocorre um evento de manutenção de infraestrutura, o Compute Engine migra automaticamente sua instância do evento e, se possível, mantém sua instância em execução durante a migração. Nenhuma intervenção do usuário é necessária.

No caso de interrupções maiores, pode haver um pequeno atraso entre o momento em que a instância cai e quando ela está disponível.

Na maioria dos casos, os eventos de migração em tempo real ocorrem sem afetar o cluster de alta disponibilidade. No entanto, teste-o simulando uma migração em tempo real do host ativo depois que o cluster estiver configurado e os sistemas em execução, especialmente se o monitor do cluster de alta disponibilidade estiver configurado com um limite de failover baixo. Para mais informações sobre como simular um evento de migração em tempo real, consulte Como testar suas políticas de disponibilidade.

Uma instância migrada é idêntica à instância original, incluindo o ID da instância, o endereço IP particular e todos os metadados e armazenamentos dela.

Por padrão, as instâncias padrão são configuradas para migrar em tempo real. Recomendamos não alterar essa configuração.

Para mais informações, consulte Migração em tempo real.

Reinicialização automática do Compute Engine

Se a instância estiver definida para encerrar quando houver um evento de manutenção ou se a instância falhar devido a um problema de hardware subjacente, configure o Compute Engine para reiniciar a instância automaticamente. Por padrão, as instâncias são definidas para reiniciar automaticamente. Recomendamos não alterar essa configuração.

Para mais informações, consulte Reinicialização automática.

Opções de armazenamento compartilhado para sistemas SAP de HA no Google Cloud

O sistema de arquivos global SAP NetWeaver é um ponto único de falha que precisa estar disponível para todas as instâncias do SAP NetWeaver no sistema de HA. Para garantir a disponibilidade do sistema de arquivos global no Google Cloud, use o armazenamento compartilhado altamente disponível ou os discos permanentes zonais replicados.

Para uma solução de armazenamento compartilhado de alta disponibilidade, use o Filestore do Google Cloud ou soluções de compartilhamento de arquivos de terceiros, como o NetApp Cloud Volumes Service para Google Cloud ou o NetApp Cloud Volumes ONTAP.

O nível empresarial do Filestore pode ser usado para implantações de alta disponibilidade em várias zonas, e o nível Básico do Filestore pode ser usado para implantações em zona única.

Para a replicação de discos permanentes zonais em sistemas Linux, use um dispositivo de bloqueio replicado distribuído (DRBD, na sigla em inglês) para replicar discos permanentes que contêm o sistema de arquivos global SAP entre os nós do cluster de alta disponibilidade.

Ainda que os discos permanentes regionais do Compute Engine ofereçam armazenamento em blocos replicado de maneira síncrona em várias zonas, eles não são compatíveis atualmente com sistemas de alta disponibilidade do SAP NetWeaver.

Para mais informações sobre as opções de armazenamento no Google Cloud, consulte:

Opções de rede para sistemas SAP de HA

Quando você configura sua rede para seu cluster de alta disponibilidade, além de concluir as etapas em Como criar uma rede, é necessário concluir estas tarefas específicas de alta disponibilidade:

  • Escolha sua implementação VIP para sistemas Linux, conforme descrito na seção a seguir. Os sistemas Windows usam um balanceador de carga interno, que não requer as mesmas soluções VIP que os sistemas Linux.
  • Defina o caminho de comunicação entre a instância SAP Central Services e a instância do servidor de replicação de enfileiramento.
  • Defina regras de firewall compatíveis com os caminhos de comunicação definidos.

Implementação de IP virtual no Google Cloud

Um cluster de alta disponibilidade usa um endereço IP flutuante ou virtual (VIP, na sigla em inglês) para mover a carga de trabalho de um nó do cluster para outro no caso de falha inesperada ou para manutenção programada. O endereço IP do VIP não muda. Portanto, os aplicativos cliente não sabem que o trabalho está sendo atendido por um nó diferente.

Um VIP também é chamado de endereço IP flutuante.

No Google Cloud, os VIPs são implementados de modo um pouco diferente do que nas instalações no local, porque, quando ocorre um failover, não é possível usar solicitações ARP gratuitas para anunciar a alteração. Em vez disso, é possível implementar um endereço VIP para um cluster de alta disponibilidade do SAP usando um dos seguintes métodos:

Implementações de VIP do balanceador de carga de rede interno

Um balanceador de carga normalmente distribui o tráfego do usuário em várias instâncias dos aplicativos, tanto para distribuir a carga de trabalho em vários sistemas ativos quanto para proteger contra uma lentidão ou falha de processamento em qualquer instância.

O balanceador de carga de rede interno também oferece suporte de failover que pode ser usado com as verificações de integridade do Compute Engine para detectar falhas, acionar o failover e redirecionar o tráfego para um novo sistema SAP principal em um cluster de alta disponibilidade nativo do SO.

O suporte de failover é a implementação VIP recomendada por vários motivos, incluindo:

  • O balanceamento de carga do Compute Engine oferece um SLA com 99,99% de disponibilidade.
  • O balanceamento de carga é compatível com clusters de alta disponibilidade em várias zonas, o que protege contra falhas de zona com tempos previsíveis de failover entre zonas.
  • O uso do balanceamento de carga reduz o tempo necessário para detectar e acionar um failover, geralmente em segundos após a falha. Os tempos gerais de failover dependem dos tempos de failover de cada um dos componentes no sistema de alta disponibilidade, que podem incluir os hosts, sistemas de banco de dados, sistemas de aplicativos, entre outros.
  • O uso do balanceamento de carga simplifica a configuração do cluster e reduz as dependências.
  • Ao contrário de uma implementação de VIP que usa rotas, com o balanceamento de carga, é possível usar intervalos de IP da sua própria rede VPC, permitindo reservar e configurar esses intervalos conforme necessário.
  • O balanceamento de carga pode ser facilmente usado no redirecionamento do tráfego para um sistema secundário para interrupções planejadas de manutenção.

Ao criar uma verificação de integridade para uma implementação de balanceador de carga de um VIP, especifique a porta do host sondada pela verificação de integridade para determinar a integridade do host. Para um cluster de alta disponibilidade do SAP, especifique uma porta de host de destino que esteja no intervalo particular 49152-65535, evitando, assim, conflitos com outros serviços. Na VM do host, configure a porta de destino com um serviço auxiliar secundário, como o utilitário socat ou o HAProxy.

Para clusters de banco de dados em que o sistema secundário em espera permanece on-line, o serviço auxiliar de verificação de integridade permite que o balanceamento de carga direcione o tráfego para o sistema on-line que está atuando como o sistema principal no cluster.

Com o uso do serviço auxiliar e do redirecionamento de porta, é possível acionar um failover de manutenção planejada de software nos sistemas SAP.

Para mais informações sobre suporte a failover, consulte Como configurar failover para balanceadores de carga de rede de passagem interna.

Para implantar um cluster de alta disponibilidade com uma implementação de VIP do balanceador de carga, consulte:

Implementações de VIP de rota estática

A implementação de rota estática também fornece proteção contra falhas de zona, mas exige o uso de um VIP fora dos intervalos de IP das sub-redes VPC existentes em que as VMs residem. Consequentemente, também é necessário garantir que o VIP não entre em conflito com nenhum endereço IP externo na sua rede expandida.

As implementações de rota estática também podem gerar complexidade quando usadas com configurações de VPC compartilhada, que se destinam a separar a configuração de rede em um projeto host.

Para usar uma implementação de rota estática para seu VIP, consulte o administrador da rede para determinar um endereço IP adequado para uma implementação de rota estática.

Implementações de VIP do IP de alias

As implementações de VIP do IP de alias não são recomendadas para implantações de alta disponibilidade em várias zonas porque, em caso de falha da zona, pode haver atraso na realocação do IP de alias para um nó em uma zona diferente. Implemente seu VIP com um balanceador de carga de rede de passagem interna compatível com failover.

Se você estiver implantando todos os nós do cluster de alta disponibilidade do SAP na mesma zona, use um IP de alias para implementar um VIP no cluster de alta disponibilidade.

Para clusters de alta disponibilidade do SAP de várias zonas que usam uma implementação de IP de alias para o VIP, é possível migrar para uma implementação de balanceador de carga de rede interno de passagem sem precisar alterar seu endereço VIP. Os endereços IP de alias e os balanceadores de carga de rede de passagem internos usam intervalos de IP da sua rede VPC.

Embora os endereços IP de alias não sejam recomendados para implementações de VIP em clusters de alta disponibilidade em várias zonas, eles têm outros casos de uso em implantações do SAP. Por exemplo, eles podem ser usados para fornecer um nome de host e atribuições de IP lógicos para implantações flexíveis do SAP, como as gerenciadas pelo SAP Landscape Management.

Práticas recomendadas gerais para VIPs no Google Cloud

Para mais informações sobre VIPs no Google Cloud, consulte Práticas recomendadas para endereços IP flutuantes.

Como configurar clusters de alta disponibilidade para SAP NetWeaver no Google Cloud

O Google Cloud fornece um arquivo de configuração do Terraform que pode ser usado para automatizar a implantação de sistemas de alta disponibilidade do SAP NetWeaver ou é possível implantar e configurar seus sistemas de alta disponibilidade do SAP NetWeaver manualmente.

Para automatizar a implantação de sistemas de alta disponibilidade do SAP NetWeaver, você conclui o arquivo de configuração do Terraform e usa comandos padrão do Terraform para aplicar as configurações. Para instruções de implantação, consulte:

O método de implantação automatizada implanta a infraestrutura do Google Cloud em um sistema SAP NetWeaver que é totalmente compatível com SAP e que segue as práticas recomendadas do SAP e do Google Cloud.

Para SAP NetWeaver, o método de implantação automatizada implanta um cluster do Linux de alta disponibilidade e otimizado para desempenho que inclui:

  • Failover automático
  • Reinicialização automática
  • Uma reserva do endereço IP virtual (VIP) especificado.
  • Compatibilidade com o failover fornecido pelo balanceamento de carga TCP/UDP interno, que gerencia o roteamento do endereço IP virtual (VIP) para os nós do cluster de alta disponibilidade.
  • Uma regra de firewall que permite que as verificações de integridade do Compute Engine monitorem as instâncias de VM no cluster.
  • O gerenciador de recursos do cluster de alta disponibilidade do Pacemaker
  • Um mecanismo de cercas do Google Cloud, o agente de cercas fence_gce
  • Uma VM com discos permanentes necessários para cada instância do SAP NetWeaver

Para instruções sobre como implantar e configurar manualmente um cluster de alta disponibilidade no Google Cloud para SAP NetWeaver, consulte: