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:

Este guia de planejamento é voltado exclusivamente à alta disponibilidade do SAP NetWeaver e não de 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.

A instância ativa do Central Services e a instância inativa do servidor de replicação de enfileiramento (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 seu 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.

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 Infraestrutura de confiança.

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 clustering de failover do Windows Server (WSFC, na sigla em inglês) para criar o cluster de alta disponibilidade, conforme descrito em Como executar o clustering 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 para sistemas SAP de alta disponibilidade 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 soluções de compartilhamento de arquivos de terceiros, como o NetApp Cloud Volumes. O Google Cloud fornece uma solução de servidor de arquivos NFS, o Filestore, mas que atualmente não fornece um servidor de arquivos altamente disponível nas zonas.

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 a rede para o 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 balanceamento de carga TCP/UDP 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 serviço de balanceamento de carga TCP/UDP 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.

Há diversos motivos para a implementação de VIP recomendada ser o suporte de failover do balanceamento de carga TCP/UDP interno, 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 alterar o comportamento de roteamento padrão de nós do cluster de alta disponibilidade, remova o VIP das tabelas de roteamento do SO Linux local em cada nó do cluster. Ao remover a entrada, as mensagens enviadas de um nó de cluster para o VIP são primeiro direcionadas para o gateway padrão e, então, para o VIP. Em seguida, o balanceador de carga processa as mensagens como qualquer outro tráfego de front-end e as encaminha para o nó que está hospedando no momento como sistema principal ativo.

Para mais informações sobre o suporte a failover do balanceamento de carga TCP/UDP interno, consulte Como configurar o failover para balanceamento de carga TCP/UDP interno.

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 balanceamento de carga TCP/UDP interno 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 balanceamento de carga TCP/UDP interno sem precisar alterar seu endereço VIP. O IP de alias e o balanceamento de carga TCP/UDP interno usam intervalos de IP da 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.