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.

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 tempo limite e intervalo

As configurações de tempo limite e intervalo de verificação dos agentes de recursos e da configuração do cluster afetam a velocidade com que o software do cluster aciona um failover. Os valores usados nas instruções e na automação do Google Cloud para clusters de alta disponibilidade podem ser um pouco diferentes dos valores padrão do software de cluster, mas na maioria dos casos é suficiente. É possível ajustar os valores, se necessário. Teste todos os valores usados no ambiente antes de liberar o sistema para uso.

Os valores de tempo limite e de intervalo de verificação sugeridos pela conta do Google Cloud para os eventos de manutenção da migração em tempo real do Google Cloud. A duração deles pode variar um pouco dependendo do tipo de máquina usada e de outros fatores. Para mais informações, consulte Migração em tempo real.

Após a implantação do cluster, teste suas configurações acionando um evento de migração ao vivo no host principal com 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.

Os volumes /hana/data e /hana/log são ativados apenas nos hosts mestre e de trabalho. Quando ocorre uma transferência, a solução de failover automático do host usa a API SAP HANA Storage Connector e o plug-in gceStorageConnector do Compute Engine para gerenciar a alternância desses discos do host com falha para o host em espera. Os parâmetros de configuração do plug-in gceStorageConnector, incluindo se o isolamento está ativado ou desativado, são armazenados na seção de armazenamento do arquivo global.ini do SAP HANA.

Os volumes /hana/shared e /hanabackup são armazenados em um servidor NFS, que é gerenciado pelo host mestre e ativado em todos os hosts, incluindo os hosts em espera.

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.

Atualmente, o Google Cloud é compatível com failover automático de host do SAP HANA apenas no SUSE Linux Enterprise Server (SLES) para imagens públicas do SAP disponíveis no Compute Engine nas famílias de imagens sles-12-sp3-sap e sles-12-sp2-sap. Para ver as imagens públicas disponíveis no Compute Engine, consulte Imagens.

O diagrama a seguir mostra uma arquitetura de vários hosts no Google Cloud que inclui suporte para failover automático de host do SAP HANA. No diagrama, o host worker 2 falha e o host em espera assume o controle. O plug-in gceStorageClient funciona com a API SAP Storage Connector (não mostrada) para desanexar os discos que contêm os volumes /hana/data e /hana/logs do worker com falha e, em seguida, remontá-los no host em espera, que se torna o host worker 2, enquanto o host com falha se torna o host em 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 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
  • Replicação síncrona
  • Memória pré-carregada
  • 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
  • Uma instância do SAP HANA em cada VM

Para mais informações, consulte o Guia de implantação de cluster de alta disponibilidade do SAP HANA.

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

Implantação manual de clusters de alta disponibilidade do SAP HANA

Ao configurar um cluster de alta disponibilidade manualmente, para garantir que os sistemas SAP HANA atendam às práticas recomendadas e aos requisitos de compatibilidade de SAP, implante as VMs e as instâncias do SAP HANA primeiro usando o modelo do Deployment Manager fornecido pelo Google Cloud.

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

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: