Guia de planejamento de alta disponibilidade do SAP HANA

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

Presume-se que você já tenha uma compreensão dos conceitos e práticas geralmente necessários para implementar um sistema de alta disponibilidade do SAP HANA. Portanto, o guia se concentra principalmente no que você precisa saber para implementar esse sistema no Google Cloud.

Para saber mais sobre os conceitos e práticas gerais necessários para implementar um sistema de alta disponibilidade do SAP HANA, consulte:

Este guia de planejamento é voltado exclusivamente à alta disponibilidade do SAP HANA e não de sistemas de banco de dados. Para informações sobre alta disponibilidade do SAP NetWeaver, consulte o Guia de planejamento de alta disponibilidade para SAP NetWeaver no Google Cloud.

Este guia não substitui nenhuma documentação fornecida pela SAP.

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

É possível usar uma combinação de recursos do Google Cloud e do SAP no design de uma configuração de alta disponibilidade para SAP HANA que possa lidar com falhas nos níveis de infraestrutura ou de software. As tabelas a seguir descrevem os recursos do SAP e do Google Cloud usados para fornecer alta disponibilidade.

Recurso Descrição
Migração em tempo real do Compute Engine

O Compute Engine monitora o estado da infraestrutura subjacente e migra automaticamente a instância para longe de um evento de manutenção da infraestrutura. Nenhuma intervenção do usuário é necessária.

O Compute Engine mantém a instância em execução durante a migração, se possível. 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.

Em sistemas com vários hosts, os volumes compartilhados, como o volume `/hana/shared` usado no guia de implantação, são discos permanentes conectados à VM que hospeda o host mestre e montados em NFS nos hosts de trabalho. O volume NFS fica inacessível por até alguns segundos no caso de migração do host mestre em tempo real. Quando o host mestre é reiniciado, o volume NFS funciona novamente em todos os hosts e a operação normal é retomada automaticamente.

Uma instância recuperada é 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.

Reinicialização automática do serviço SAP HANA

A reinicialização automática do serviço SAP HANA é uma solução de recuperação de falhas fornecida pelo SAP.

O SAP HANA tem muitos serviços configurados em execução o tempo todo para várias atividades. Quando algum desses serviços é desativado devido a uma falha de software ou erro humano, a função guardiã de reinicialização automática do serviço SAP HANA o reinicia automaticamente. Quando o serviço é reiniciado, ele carrega todos os dados necessários de volta na memória e retoma a operação.

Backups do SAP HANA

Os backups do SAP HANA criam cópias do seu banco de dados que podem ser usadas para reconstruí-lo em um determinado momento.

Para mais informações sobre como usar os backups do SAP HANA no Google Cloud, consulte o Guia de operações do SAP HANA.

Replicação de armazenamento do SAP HANA

A replicação de armazenamento do SAP HANA fornece suporte à recuperação de desastres no nível de armazenamento por meio de determinados parceiros de hardware. A replicação de armazenamento do SAP HANA não é compatível com o Google Cloud. Você pode considerar o uso de snapshots de disco permanente do Compute Engine.

Para mais informações sobre como usar snapshots de disco permanente para fazer backup de sistemas SAP HANA no Google Cloud, consulte o Guia de operações do SAP HANA.

Failover automático de host do SAP HANA

O failover automático de host do SAP HANA é uma solução local de recuperação de falhas que requer um ou mais hosts do SAP HANA em modo de espera em um sistema de escalonamento horizontal. Se um dos hosts principais falhar, o failover automático do host coloca o host em espera on-line automaticamente e reinicia o host com falha como host em espera.

Veja mais informações em:

Replicação do sistema SAP HANA

A replicação do sistema SAP HANA permite configurar um ou mais sistemas para assumir o controle do sistema principal em cenários de alta disponibilidade ou recuperação de desastres. Ajuste a replicação para atender às suas necessidades em termos de desempenho e tempo de failover.

Clusters de alta disponibilidade nativos de SO para SAP HANA no Google Cloud

O cluster do sistema operacional Linux fornece reconhecimento de aplicativo e convidado para o estado do aplicativo e automatiza ações de recuperação em caso de falha.

Os princípios de cluster de alta disponibilidade que se aplicam a ambientes que não são de nuvem geralmente se aplicam ao Google Cloud, mas existem diferenças na implementação de alguns elementos, como IPs de isolamento e virtuais.

É possível usar as distribuições Linux de alta disponibilidade de Red Hat ou SUSE para seu cluster de alta disponibilidade para o SAP HANA no Google Cloud.

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

Para as opções de implantação automatizada fornecidas pelo Google Cloud, consulte Opções de implantação automatizada para configurações de alta disponibilidade do SAP HANA.

Agentes de recursos de cluster

O Red Hat e o SUSE fornecem aos agentes de recursos do Google Cloud as implementações de alta disponibilidade do software de cluster do Pacemaker. Os agentes de recursos do Google Cloud gerenciam isolamentos STONITH, VIPs que são implementados com rotas ou IPs de alias e ações de armazenamento.

Para disponibilizar atualizações que ainda não estão incluídas nos agentes de recursos do SO de base, o Google Cloud fornece periodicamente agentes de recursos complementares para clusters de alta disponibilidade para SAP. Quando esses agentes de recursos complementares são necessários, os procedimentos de implantação do Google Cloud incluem uma etapa de download deles.

Isolamento

O Isolamento, no contexto do clustering de SO do Google Cloud Compute Engine, assume a forma de STONITH, que fornece a cada membro em um cluster de dois nós a capacidade de reiniciar o outro nó.

Os agentes de recursos oferecidos pela Red Hat e pelo SUSE gerenciam o isolamento STONITH no Google Cloud.

Endereço IP virtual

Os clusters de alta disponibilidade para SAP no Google Cloud usam um endereço IP virtual ou flutuante (VIP) para redirecionar o tráfego de rede de um host para outro no caso de um failover.

Implantações comuns fora da nuvem usam uma solicitação gratuita do protocolo de resolução de endereços (ARP, na sigla em inglês) para anunciar o movimento e a realocação de um VIP para um novo endereço MAC.

No Google Cloud, em vez de usar solicitações ARP gratuitas, use um dos variados métodos para mover e realocar um VIP em um cluster de alta disponibilidade. Recomenda-se usar um balanceador de carga TCP/UDP interno, mas, dependendo das suas necessidades, também é possível usar uma implementação de VIP baseada em rota ou uma implementação de VIP baseada em IP de alias.

Para mais informações sobre a implementação de VIP no Google Cloud, consulte Implementação de IP virtual no Google Cloud.

Armazenamento e replicação

Uma configuração de cluster de alta disponibilidade do SAP HANA usa a replicação síncrona do sistema SAP HANA para manter os bancos de dados primário e secundário do SAP HANA sincronizados. Os agentes de recursos padrão fornecidos pelo SO para SAP HANA gerenciam a replicação do sistema durante um failover, iniciando e interrompendo a replicação e alternando quais instâncias estão sendo veiculadas como instâncias ativas e em espera no processo de replicação.

Para armazenamento de arquivos compartilhado, os arquivadores baseados em NFS ou SMB poderão fornecer a funcionalidade necessária.

Para uma solução de armazenamento compartilhado de alta disponibilidade, é possível usar uma solução 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.

Os discos permanentes regionais do Compute Engine oferecem armazenamento em blocos replicado de forma síncrona nas zonas. Os discos permanentes regionais não são compatíveis com o armazenamento do banco de dados em sistemas de alta disponibilidade do SAP, mas é possível usá-los com servidores de arquivos NFS.

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

Configurações de clusters de alta disponibilidade no Google Cloud

O Google Cloud recomenda alterar os valores padrão de determinados parâmetros de configuração de cluster para valores mais adequados a sistemas SAP no ambiente do Google Cloud. Se usar os modelos do Deployment Manager fornecidos pelo Google Cloud, os valores recomendados serão definidos para você.

Considere os valores recomendados como um ponto de partida para ajustar as configurações do Corosync no seu cluster de HA. Confirme se a sensibilidade da detecção de falhas e do acionamento de failover é apropriada para seus sistemas e cargas de trabalho no ambiente do Google Cloud.

Valores do parâmetro de configuração do Corosync

Nos guias de configuração do cluster de alta disponibilidade para SAP HANA, o Google Cloud recomenda valores para vários parâmetros na seção totem do arquivo de configuração corosync.conf que são diferentes dos valores padrão definidos pelo Corosync ou pelo distribuidor distributor.

A tabela a seguir mostra os parâmetros totem para os quais o Google Cloud recomenda valores diferentes, além dos valores recomendados e do impacto da alteração do valor. Para os valores padrão dos parâmetros, que podem diferir entre distribuições do Linux, consulte a documentação da distribuição do Linux.

Parâmetro Valor recomendado Impacto da mudança
join 60 (ms) Aumenta o tempo que o nó aguarda as mensagens "join" no protocolo de associação.
max_messages 20 Aumenta o número máximo de mensagens que podem ser enviadas pelo nó após o recebimento do token.
token 20000 (ms)

Aumenta o tempo de espera do nó para um token de protocolo Totem antes que o nó declare uma perda de token, adote uma falha do nó e comece a agir.

Aumentar o valor do parâmetro "token" torna o cluster mais tolerante a eventos de infraestrutura momentâneos, como uma migração em tempo real, mas pode fazer com que ele leve mais tempo para detectar e se recuperar de uma falha no nó.

O valor do parâmetro "token" também determina o valor padrão do parâmetro "consensus", que controla quanto tempo um nó aguarda por um consenso antes de tentar restabelecer a associação da configuração. Quando "consensus" não é especificado, o Corosync define o valor como 1,2 vezes o valor do parâmetro "token".

token_retransmits_before_loss_const 10 Aumenta o número de retransmissões de token que o nó tenta antes de concluir que o nó do destinatário falhou e entrar em ação.

Para mais informações sobre como configurar o arquivo corosync.conf, consulte o guia de configuração para sua distribuição do Linux:

Configurações de tempo limite e intervalo

Ao definir um recurso de cluster, você define valores interval e timeout (em segundos) para várias operações de recurso (op). Por exemplo:

primitive rsc_SAPHanaTopology_HA1_HDB00 ocf:suse:SAPHanaTopology \
 operations \$id="rsc_sap2_HA1_HDB00-operations" \
 op monitor interval="10" timeout="600" \
 op start interval="0" timeout="600" \
 op stop interval="0" timeout="300" \
 params SID="HA1" InstanceNumber="00"

clone cln_SAPHanaTopology_HA1_HDB00 rsc_SAPHanaTopology_HA1_HDB00 \
 meta is-managed="true" clone-node-max="1" target-role="Started" interleave="true"

Os valores de timeout afetam cada uma das operações de recursos de maneira diferente, conforme explicado na tabela a seguir.

Operação do recurso Ação para tempo limite
monitor Se o tempo limite for excedido, o status de monitoramento normalmente irá relatar um erro, e o recurso associado será considerado em estado de falha. O cluster tenta opções de recuperação, o que pode incluir um failover. O cluster não repete uma operação de monitoramento com falha.
start Se um recurso não for iniciado antes que o tempo limite seja atingido, o cluster tentará reiniciar o recurso. O comportamento é determinado pela ação na falha que está associada a um recurso.
stop Se um recurso não responde a uma operação de interrupção antes que o tempo limite seja atingido, isso aciona um evento de isolamento (STONITH).

Além de outras configurações de cluster, as definições de interval e timeout dos recursos do cluster afetam a rapidez com que o software do cluster detecta uma falha e aciona um failover.

Os valores timeout e interval sugeridos pelo Google Cloud nos guias de configuração de cluster para SAP HANA consideram os eventos de manutenção de migração em tempo real do Compute Engine.

Independentemente dos valores timeout e interval usados, você precisa avaliá-los ao testar o cluster, especialmente durante os testes de migração em tempo real, porque a duração desses eventos pode variar um pouco, dependendo do tipo de máquina que você está usando e de outros fatores, como a utilização do sistema.

Como testar seu cluster de alta disponibilidade no Google Cloud

Depois que o cluster for configurado e os sistemas do cluster e do SAP HANA forem implantados no ambiente de teste, será preciso testar o cluster para confirmar se o sistema de HA está configurado corretamente e funcionando conforme o esperado.

Para confirmar que o failover está funcionando como esperado, simule vários cenários de falha com as ações a seguir:

  • Encerre a VM
  • Crie um pânico do kernel
  • Encerre o aplicativo
  • Interrompa a rede entre as instâncias

Além disso, simule um evento de migração em tempo real do Compute Engine no host primário para confirmar que ele não aciona um failover. É possível simular um evento de manutenção usando o comando gcloud compute instances simulate-maintenance-event do SDK do Cloud.

Como gerar registros e monitorar

Os agentes de recursos podem incluir recursos de geração de registros que propagam registros para o pacote de operações do Google Cloud para análise. Cada agente de recurso inclui informações de configuração que identificam as opções de geração de registros. No caso de implementações bash, a opção de geração de registros é gcloud logging.

Também é possível instalar o agente do Cloud Logging para capturar a saída do registro de processos do sistema operacional e correlacionar a utilização de recursos com eventos do sistema. O agente do Logging captura registros do sistema padrão, que incluem dados de registro do Pacemaker e dos serviços de clustering. Para mais informações, consulte Sobre o agente do Logging.

Para informações sobre como usar o Cloud Monitoring para configurar verificações de serviço que monitoram a disponibilidade de endpoints de serviço, consulte Como gerenciar verificações de tempo de atividade.

Contas de serviço e clusters de alta disponibilidade

As ações que o software de cluster pode realizar no ambiente do Google Cloud são protegidas pelas permissões concedidas à conta de serviço de cada VM de host. Para ambientes de alta segurança, é possível limitar as permissões nas contas de serviço das VMs de host para obedecer ao princípio do menor privilégio.

Ao limitar as permissões da conta de serviço, lembre-se de que o sistema pode interagir com os serviços do Google Cloud, como o Cloud Storage. Portanto, talvez seja necessário incluir permissões para essas interações de serviço na conta de serviço da VM do host.

Para as permissões mais restritivas, crie um papel personalizado com as permissões mínimas necessárias. Para informações sobre papéis personalizados, consulte Como criar e gerenciar papéis personalizados. É possível restringir ainda mais as permissões limitando-as a instâncias específicas de um recurso, como as instâncias de VM no cluster de alta disponibilidade, adicionando condições nas vinculações de papel da política de IAM de um recurso.

As permissões mínimas necessárias dependem dos recursos do Google Cloud que os sistemas acessam e das ações que eles executam. Consequentemente, determinar as permissões mínimas necessárias para as VMs do host no cluster de alta disponibilidade pode exigir que você investigue exatamente quais recursos os sistemas acessam na VM do host e as ações que esses sistemas executam com tais recursos.

Como ponto de partida, a lista a seguir mostra alguns recursos do cluster de alta disponibilidade e as permissões associadas exigidas:

  • Isolamento STONITTH
    • compute.instances.list
    • compute.instances.get
    • compute.instances.reset
    • compute.instances.stop
    • compute.instances.start
    • logging.logEntries.create
    • compute.zones.list
  • VIP implementado usando um IP de alias
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.instances.updateNetworkInterface
    • compute.zoneOperations.get
    • logging.logEntries.create
  • VIP implementado usando rotas estáticas
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.routes.get
    • compute.routes.create
    • compute.routes.delete
    • compute.routes.update
    • compute.routes.list
    • compute.networks.updatePolicy
    • compute.networks.get
    • compute.globalOperations.get
    • logging.logEntries.create
  • VIP implementado usando um balanceador de carga interno
    • Nenhuma permissão específica é necessária. O balanceador de carga opera em status de verificação de integridade que não exige que o cluster interaja ou altere recursos no Google Cloud.

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 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.

Failover automático do host do SAP HANA no Google Cloud

O Google Cloud é compatível com o failover automático de host do SAP HANA, a solução local de recuperação de falhas fornecida pelo SAP HANA. A solução de failover automático do host usa um ou mais hosts em espera que são mantidos em reserva para assumir o trabalho do host mestre ou worker em caso de falha no host. Os hosts em espera não têm dados nem processam trabalhos.

Após concluir um failover, o host com falha é reiniciado como um host em espera.

O SAP é compatível com até três hosts em espera em sistemas de escalonamento horizontal no Google Cloud. Os hosts em espera não contam para o máximo de 16 hosts ativos que o SAP suporta em sistemas de escalonamento horizontal no Google Cloud.

Para mais informações da SAP sobre a solução de failover automático de hosts, consulte Failover automático de hosts.

Quando usar o failover automático de host do SAP HANA no Google Cloud

O failover automático de host do SAP HANA protege contra falhas que afetam um único nó em um sistema de escalonamento horizontal do SAP HANA, incluindo falhas dos seguintes itens:

  • A instância do SAP HANA
  • O sistema operacional do host
  • A VM do host

Em relação a falhas da VM do host, no Google Cloud, a reinicialização automática, que normalmente restaura a VM do host do SAP HANA mais rápido que o failover automático do host, e a migração em tempo real, protegem contra interrupções em VMs planejadas e não planejadas. Então, para proteção da VM, a solução de failover automático de host do SAP HANA não é necessária.

O failover automático de host do SAP HANA não protege contra falhas zonais, porque todos os nós de um sistema de escalonamento horizontal do SAP HANA são implantados em uma única zona.

O failover automático de host do SAP HANA não pré-carrega dados do SAP HANA na memória dos nós de espera. Então, quando um nó de espera assume o controle, o tempo total de recuperação do nó é determinado principalmente pelo tempo que leva para carregar os dados na memória do nó de espera.

Use o failover automático de host do SAP HANA nos cenários a seguir:

  • Falhas no software ou no sistema operacional do host de um nó do SAP HANA que pode não ser detectada pelo Google Cloud.
  • Migrações lift-and-shift, em que você precisa reproduzir a configuração do SAP HANA no local até otimizar o SAP HANA para Google Cloud.
  • Quando uma configuração totalmente replicada entre zonas e de alta disponibilidade é proibitiva de custo e sua empresa pode tolerar:
    • Um tempo de recuperação de nó mais longo devido à necessidade de carregar dados do SAP HANA na memória de um nó de espera.
    • Risco de falha zonal.

O gerenciador de armazenamento do SAP HANA

Os volumes /hana/data e /hana/log são ativados apenas nos hosts mestre e de trabalho. Quando ocorre a tomada de controle, a solução de failover automático do host usa a API do conector de armazenamento do SAP HANA e o gerenciador de armazenamento do Google Cloud para que os nós de espera do SAP HAPA movam as montagens de volume do host com falha para o host em espera.

No Google Cloud, o gerenciador de armazenamento do SAP HANA é necessário para sistemas SAP HANA que usam o failover automático de host do SAP HANA.

Suspensão de uso das versões 1.n do gerenciador de armazenamento do SAP HANA

As versões 1.n do gerenciador de armazenamento do SAP HANA foram suspensas.

Se você estiver usando uma versão anterior à 2.0, atualize seu sistema SAP HANA para usar a versão mais recente do gerenciador de armazenamento para SAP HANA.

Para determinar se a sua versão foi suspensa, abra o arquivo gceStorageClient.py. O diretório de instalação padrão é: /hana/shared/gceStorageClient

A partir da versão 2.0, o número da versão é listado nos comentários na parte superior do arquivo gceStorageClient.py, conforme mostrado no exemplo a seguir.

Se o número da versão estiver ausente, você está procurando o lançamento de uma versão 1.n suspensa do gerenciador de armazenamento do SAP HANA. O suporte para os lançamentos de versão 1.n termina em 31 de dezembro de 2021.

"""Google Cloud Storage Manager for SAP HANA Standby Nodes.

The Storage Manager for SAP HANA implements the API from the SAP provided
StorageConnectorClient to allow attaching and detaching of disks when
running in GCE.

Build Date: Wed Jan 27 06:39:49 PST 2021
Version: 2.0.20210127.00-00

"""

Como instalar o gerenciador de armazenamento para SAP HANA

O método recomendado para instalar o gerenciador de armazenamento do SAP HANA é usar o modelo do Deployment Manager fornecido pelo Google Cloud para implantar um sistema de escalonamento horizontal do SAP HANA que inclui o gerenciador de armazenamento mais recente do SAP HANA.

Se você precisar adicionar o failover automático de host do SAP HANA a um sistema de escalonamento horizontal do SAP HANA no Google Cloud, a abordagem recomendada é semelhante: use o modelo do Deployment Manager fornecido pelo Google Cloud para implantar um novo sistema de escalonamento horizontal do SAP HANA e, em seguida, carregue os dados no novo sistema a partir do sistema atual. Para carregar os dados, use procedimentos padrão de backup e restauração do SAP HANA ou a replicação do sistema SAP HANA, o que pode limitar a inatividade. Para mais informações sobre a replicação do sistema, consulte a Nota SAP 2473002 - Como usar a replicação do sistema HANA para migrar o sistema de escalonamento horizontal.

Se não for possível usar o modelo do Deployment Manager, entre em contato com um consultor de soluções da SAP ou com os serviços de consultoria do Google Cloud, para receber ajuda na instalação manual do gerenciador de armazenamento. para SAP HANA.

No momento, a instalação manual do gerenciador de armazenamento do SAP HANA em um sistema de escalonamento horizontal SAP HANA novo ou atual não está documentada.

Para mais informações sobre o modelo do Deployment Manager para failover automático de host do SAP HANA, consulte Implantação automatizada de sistemas de escalonamento horizontal do SAP HANA com failover automático de host do SAP HANA.

Como atualizar o gerenciador de armazenamento do SAP HANA

Para atualizar o gerenciador de armazenamento para SAP HANA, primeiro faça o download do pacote de instalação e execute um script de instalação, que atualiza o gerenciador de armazenamento para o executável do SAP HANA na unidade /shared do SAP HANA.

O procedimento a seguir é apenas para a versão 2 do gerenciador de armazenamento do SAP HANA. Se você estiver usando uma versão do gerenciador de armazenamento para SAP HANA que foi baixada antes de 1 de fevereiro de 2021, instale a versão 2 antes de tentar atualizar o gerenciador de armazenamento para o SAP HANA.

Para atualizar o gerenciador de armazenamento do SAP HANA:

  1. Verifique a versão do gerenciador de armazenamento para SAP HANA atual:

    RHEL

    sudo yum check-update google-sapgcestorageclient

    SLES

    sudo zypper list-updates -r google-sapgcestorageclient
  2. Se houver uma atualização, instale a atualização:

    RHEL

    sudo yum update google-sapgcestorageclient

    SLES

    sudo zypper update

    O gerenciador de armazenamento atualizado do SAP HANA está instalado em /usr/sap/google-sapgcestorageclient/gceStorageClient.py.

  3. Substitua o gceStorageClient.py atual pelo arquivo gceStorageClient.py atualizado:

    • Se seu arquivo gceStorageClient.py atual estiver em /hana/shared/gceStorageClient, o local de instalação padrão, use o script de instalação para atualizar o arquivo:

      sudo /usr/sap/google-sapgcestorageclient/install.sh
    • Se o arquivo gceStorageClient.py atual não estiver em /hana/shared/gceStorageClient, copie o arquivo atualizado para o mesmo local que o arquivo existente, substituindo o arquivo atual.

Parâmetros de configuração no arquivo global.ini

Alguns parâmetros de configuração do gerenciador de armazenamento do SAP HANA, incluindo se o isolamento está ativado ou desativado, são armazenados na seção de armazenamento do arquivo global.ini do SAP HANA. Ao usar o modelo do Deployment Manager fornecido pelo Google Cloud para implantar um sistema SAP HANA com a função de failover automático do host, os scripts de implantação adicionam os parâmetros de configuração ao global.ini para você.

O exemplo a seguir mostra o conteúdo de um global.ini criado para o gerenciador de armazenamento do SAP HANA:

[persistence]
basepath_datavolumes = %BASEPATH_DATAVOLUMES%
basepath_logvolumes = %BASEPATH_LOGVOLUMES%
use_mountpoints = %USE_MOUNTPOINTS%
basepath_shared = %BASEPATH_SHARED%

[storage]
ha_provider = gceStorageClient
ha_provider_path = %STORAGE_CONNECTOR_PATH%

#
# Example configuration for 2+1 setup
#
# partition_1_*__pd = node-mnt00001
# partition_2_*__pd = node-mnt00002
# partition_3_*__pd = node-mnt00003
# partition_*_data__dev = /dev/hana/data
# partition_*_log__dev = /dev/hana/log
# partition_*_data__mountOptions = -t xfs -o logbsize=256k
# partition_*_log__mountOptions = -t xfs -o logbsize=256k
# partition_*_*__fencing = disabled

[trace]
ha_gcestorageclient = info

Armazenamento NFS para failover automático de host do SAP HANA

Um sistema de escalonamento horizontal do SAP HANA com failover automático de host requer uma solução NFS, como o Filestore, para compartilhar os volumes /hana/shared e /hanabackup entre todos os hosts. Você mesmo precisa configurar a solução de NFS.

Ao usar o Deployment Manager, você fornece informações sobre o servidor NFS no arquivo de configuração template.yaml para que ele possa montar os diretórios NFS durante a implantação.

O volume NFS usado precisa estar vazio. Qualquer arquivo existente pode entrar em conflito com os scripts do Deployment Manager, especialmente se os arquivos ou pastas fizerem referência ao código do sistema SAP (SID). Os scripts de implantação não podem determinar se os arquivos podem ser substituídos.

O Deployment Manager armazena os volumes /hana/shared e /hanabackup no servidor NFS e monta o servidor NFS em todos os hosts, incluindo os hosts em espera. O host mestre gerencia o servidor NFS.

Se você estiver implementando uma solução de backup, como o agente do Backint do Cloud Storage para SAP HANA, será possível remover o volume /hanabackup do servidor NFS depois que o Deployment Manager concluir a implantação.

Para mais informações sobre as soluções de arquivos compartilhados disponíveis no Google Cloud, consulte Soluções de compartilhamento de arquivos para o SAP no Google Cloud.

Suporte ao sistema operacional

Atualmente, o Google Cloud é compatível com o failover automático de host do SAP HANA apenas nos seguintes sistemas operacionais:

  • RHEL para SAP 7.6 ou posterior
  • RHEL para SAP 8.1 ou posterior
  • SLES para SAP 12 SP2 ou posterior
  • SLES para SAP 15 ou posterior

para imagens públicas do SAP disponíveis no Compute Engine. Para ver as imagens públicas disponíveis no Compute Engine, consulte Imagens.

Arquitetura de um sistema SAP HANA com failover automático de host

O diagrama a seguir mostra uma arquitetura de escalonamento horizontal no Google Cloud que inclui o recurso de failover automático de host do SAP HANA. No diagrama, o gerenciador de armazenamento do SAP HANA é representado pelo nome do executável dele, gceStorageClient.

O diagrama mostra o nó de trabalho 2 falhando e o nó em espera assumindo o controle. O gerenciador de armazenamento do SAP HANA funciona com a API SAP Storage Connector (não exibida) para remover os discos que contêm os volumes /hana/data e /hana/logs do nó de trabalho com falha e para montá-los novamente no nó de espera, que se torna o nó de trabalho 2 enquanto o nó com falha se torna o nó de espera.

O diagrama descreve a arquitetura de um sistema SAP HANA de escalonamento horizontal compatível com o
failover automático de host

Opções de implantação automatizada para configurações de alta disponibilidade do SAP HANA

O Google Cloud fornece modelos do Deployment Manager que podem ser usados para automatizar a implantação de sistemas de alta disponibilidade do SAP HANA. Caso prefira, é possível implantar e configurar seus sistemas de alta disponibilidade do SAP HANA manualmente.

Os modelos do Deployment Manager fornecidos pelo Google Cloud incluem um arquivo de configuração template.yaml concluído. O Deployment Manager lê o arquivo de configuração e implanta um sistema SAP HANA para você que tenha suporte total do SAP e que adere às práticas recomendadas do SAP e do Google Cloud.

Implantação automatizada de clusters de alta disponibilidade do Linux para SAP HANA

Para o SAP HANA, o Deployment Manager implanta um cluster Linux de alta disponibilidade e desempenho otimizado 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 isolamento do Google Cloud
  • Uma VM com discos permanentes necessários para cada instância do SAP HANA
  • Instâncias do SAP HANA configuradas para replicação síncrona e pré-carregamento de memória.

Para instruções de implantação automatizadas, consulte Implantação automatizada de alta disponibilidade do SAP HANA com implementação VIP do balanceador de carga.

Implantação automatizada de sistemas de escalonamento horizontal do SAP HANA com failover automático de host do SAP HANA

Para um sistema de escalonamento horizontal do SAP HANA com recurso de failover automático de host do SAP HANA, o Deployment Manager implanta:

  • Uma instância mestre do SAP HANA
  • 1 a 15 hosts worker
  • 1 a 3 hosts em espera
  • Uma VM para cada host do SAP HANA
  • Discos permanentes para os hosts mestre e worker

Um sistema de escalonamento horizontal do SAP HANA com failover automático de host requer uma solução NFS, como o Filestore, para compartilhar os volumes /hana/shared e /hanabackup entre todos os hosts. Para que o Deployment Manager possa montar os diretórios NFS durante a implantação, configure a solução NFS antes de implantar o sistema SAP HANA.

É possível configurar as instâncias do servidor NFS do Filestore de maneira rápida e fácil, seguindo as instruções em Como criar instâncias.

Para implantar um sistema de escalonamento horizontal com hosts em espera, consulte o Guia de implantação do sistema de escalonamento horizontal do SAP HANA com failover automático de host do SAP HANA.

A seguir

O Google Cloud e o SAP fornecem mais informações sobre alta disponibilidade.

Mais informações do Google Cloud sobre alta disponibilidade

Para mais informações sobre a alta disponibilidade do SAP HANA no Google Cloud, consulte:

Para informações gerais sobre como proteger sistemas no Google Cloud contra vários cenários de falha, consulte Como projetar sistemas robustos.

Mais informações do SAP sobre os recursos de alta disponibilidade do SAP HANA

Para mais informações do SAP sobre os recursos de alta disponibilidade do SAP HANA, consulte os documentos a seguir: