Resiliência para implantações SAP no Google Cloud

Este documento descreve considerações de projeto que ajudam você a executar sistemas SAP confiáveis no Google Cloud.

A infraestrutura e o software podem falhar. As causas e o escopo dessas falhas exigem que as implantações do sistema SAP sigam certos princípios para aproveitar ao máximo a infraestrutura do Google Cloud. Combinar opções de infraestrutura com arquiteturas resilientes de implantação de software SAP garante a integridade e proteção dos dados contra perda de dados ou indisponibilidade do sistema.

Opções de resiliência e confiabilidade

Você pode implantar sistemas resilientes e robustos utilizando recursos em camadas de aplicativo e infraestrutura para absorver falhas ou permitir a recuperação de falhas. Para garantir resiliência e confiabilidade para implantações do sistema SAP no Google Cloud, recomendamos que você considere as seguintes opções:

  • Resiliência da plataforma: os serviços e produtos do Google Cloud são projetados considerando resiliência e têm redundância integrada para atingir nossos Contratos de nível de serviço publicados. Quando você implanta seus sistemas SAP de acordo com as diretrizes do Google Cloud e práticas recomendadas, os mecanismos subjacentes da plataforma aumentam a resiliência do sistema SAP. Isso permite que você continue com as operações comerciais em caso de falha ou durante um desastre.
  • Alta disponibilidade (HA): com o uso de configurações de infraestrutura e software compatíveis com alta disponibilidade, é possível ativar a recuperação de sistema automatizado com o mínimo possível de interrupções. Esse uso também garante que o mínimo de intervenção seja necessário caso ocorram falhas em partes da infraestrutura ou software de aplicativo. A alta disponibilidade protege o sistema contra falha ou degradação de componente único, fornecendo redundância para os componentes do sistema.
  • Recuperação de desastres (DR): a DR permite a recuperação de operações comerciais em caso de falhas causadas por um desastre. A DR envolve mover serviços e aplicativos para um local secundário fisicamente isolado de onde as operações podem continuar. Os sistemas de DR se estendem além de uma única falha de componente ou serviço para reduzir a frequência de eventos mais impactantes. Isso pode incluir eventos regionais, como desastres naturais, perda de energia e eventos localizados, como incêndios ou erros humanos. As disposições de DR incluem o seguinte:
    • Replicação de dados: é possível usar a replicação no nível de software ou armazenamento para garantir que os dados sejam transferidos para um local secundário com o mínimo de perda de dados.
    • Backups: é possível recuperar um sistema ou banco de dados usando backups que estejam separados do seu armazenamento de dados principal. Isso pode incluir o uso de snapshots ou backups enviados ao Cloud Storage, desde que os snapshots ou backups sejam armazenados em uma região diferente de onde o sistema está implantado.

Como essas opções são complementares, é possível combinar aspectos de cada opção para aumentar a resiliência nas implantações do SAP. As opções selecionadas afetam o objetivo do tempo de recuperação (RTO) e o objetivo do ponto de recuperação (RPO) da implantação. Portanto, você também precisa avaliar o custo dessas opções na resiliência dos sistemas e na continuidade dos negócios. Recomendamos considerar cuidadosamente todas as opções disponíveis e implementá-las para atender seus objetivos de recuperação de desastres.

A seção a seguir descreve um exemplo de implantação SAP e o impacto que se pode esperar das diferentes configurações de HA e DR quanto a resiliência e confiabilidade.

Exemplos de cenários

Considere uma implantação SAP S/4HANA de escalonamento vertical no Google Cloud. A seguinte tabela apresenta exemplos de configurações de HA e DR que podem ser aplicadas à essa implantação e o impacto esperado na confiabilidade e na resiliência do sistema como disponibilidade, RTO e RPO.

Configuração de HA ou DR Dimensão de resiliência ou confiabilidade Expectativa
Uma configuração de alta disponibilidade. Considere o seguinte:
  • us-central1 é a região principal.
  • As instâncias X4 são implantadas em duas zonas diferentes, como us-central1-a e us-central1-b.
 Disponibilidade
  • 99,99% ou mais para todo o sistema.
  • 99,9% ou mais para cada instância individual.
Uma configuração de DR que usa replicação assíncrona do sistema SAP HANA para um sistema de DR residente de plena memória. Considere o seguinte:
  • us-central1 é o local principal.
  • us-east4 é o local de DR e executa uma instância X4 que é do mesmo tamanho do local principal.
  • Os dados são pré-carregados na instância X4 que executa o SAP HANA no local de DR.
  • No local de DR, os servidores de aplicativos são provisionados ou você comprou reservas para eles. Observação 1
 Tempo de recuperação Algumas horas, que pode incluir o tempo necessário para a propagação do DNS aos sistemas clientes.
Ponto de recuperação Minutos, em relação à última replicação assíncrona.
Uma configuração de DR que usa backups com infraestrutura pré-provisionada Observação 1. Considere um sistema que usa backup e recuperação baseados em backint Tempo de recuperação Tempo para recuperar o banco de dados do backup Observação 2.
Ponto de recuperação Para o último momento do backup ou snapshot de registro do SAP HANA.
Uma configuração de DR que usa backups sem infraestrutura pré-provisionada Observação 3. Considere um sistema que usa backup e recuperação baseados em backint Tempo de recuperação Vários dias para provisionar a infraestrutura Observação 4 e Recuperar dados do backup Observação 3.
Ponto de recuperação Para o último momento do backup ou snapshot de registro do SAP HANA.

Observações sobre a tabela:

  1. É possível implantar a solução de DR sem pré-provisionar a infraestrutura necessária, reservando recursos com antecedência. Essa é uma forma de garantir a disponibilidade dos recursos necessários quando for preciso ativar a solução de DR devido a um desastre no local principal. Saiba mais em Reservas para recursos zonais do Compute Engine.

  2. O tempo de execução de uma operação de recuperação depende muito da solução de backup usada e do tamanho dos arquivos de backup. Para determinar as expectativas de tempo exatas para o tamanho do seu banco de dados e as taxas de alteração, você precisa avaliar a velocidade de recuperação para a solução de backup que você usa, como o Backint ou snapshot do disco.

  3. Ao implantar uma solução de DR sem o pré-provisionamento ou a reserva dos recursos necessários pode levar a situações em que os recursos necessários não estão disponíveis. Isso pode aumentar o tempo de recuperação durante a implantação, o que afeta as operações comerciais.

  4. Para tipos de máquinas como X4, que não estão disponíveis sob demanda e precisam ser encomendados, várias semanas de tempo de lead podem ser necessárias sem reserva de capacidade prévia.

Considere as informações apresentadas na tabela anterior como complementares a quaisquer projetos e planos de recuperação de desastres derivados de diretrizes do setor. Para mais informações, consulte os seguintes recursos:

Recomendações para implantações resilientes

As seções a seguir oferecem uma visão geral das configurações de HA e DR que recomendamos para implantar cargas de trabalho SAP resilientes e confiáveis no Google Cloud.

Embora seja altamente recomendável que você implemente essas recomendações para cargas de trabalho SAP que hospedam operações de produção essenciais para os negócios, também é possível implementá-las em sistemas SAP de não produção, quando uma interrupção prolongada pode prejudicar as operações comerciais.

Para mais informações sobre as recomendações, consulte as seguintes seções:

Recomendações de alta disponibilidade

  • Use pelo menos duas zonas diferentes na mesma região para implantar instâncias.
  • Remova pontos únicos de falha. Para isso, adicione recursos que fornecem resiliência e redundância aos serviços com defeito ou os componentes do aplicativo em caso de falha.
  • Use serviços regionais que têm redundância integrada. Por exemplo, use Filestore Enterprise para hospedar arquivos compartilhados e balanceadores de carga fornecidos pelo Cloud Load Balancing.
  • Use a automação para failover. A automação limita a necessidade de intervenções manuais em caso de falha e reduz o impacto em operações comerciais. Por exemplo, é possível usar um gerenciador de cluster do Linux, como Pacemaker:

  • Use caminhos de rede redundantes. Verifique se você tem conectividade redundante na sua região principal. Dependendo dos seus requisitos de conectividade, várias opções estão disponíveis. Para mais informações, consulte Regiões do Google Cloud.

    Para alcançar 99,99% de disponibilidade nas suas conexões com regiões do Google Cloud, recomendamos que você configure várias conexões. Para mais informações, consulte Estabelecer 99,99% de disponibilidade para a Interconexão dedicada.

  • Ative políticas de migração em tempo real e de reinicialização automática nos recursos do Compute Engine:

    • Para manter as instâncias da computação on-line durante eventos de manutenção iniciados pelo Google, use a migração em tempo real configurando a propriedade onHostMaintenance com a opção MIGRATE (Padrão). Para instâncias de computação que não são compatíveis com a migração em tempo real, defina a propriedade automaticRestart como true (padrão). Isso permite que o Google reinicie qualquer instância sem resposta. Para mais informações, consulte Sobre eventos do host.
    • Para instâncias de computação que não são compatíveis com a migração em tempo real ou manutenção planejada, controles avançados de manutenção estão disponíveis. Para mais informações, consulte Ativar o controle de manutenção avançada para nós de locatário individual.

  • Antes de começar, teste o failover no seu ambiente.

Recomendações para recuperação de desastres

  • Hospede a solução de DR em um local diferente do principal. Para evitar que sua solução de DR seja afetada pelo mesmo evento que seu sistema principal, verifique se os dois estão hospedados em locais diferentes.

    O ideal é que o local de DR seja uma região diferente. No entanto, se usar uma segunda região não for uma boa opção por causa de questões de residência ou soberania de dados, entre em contato com a Equipe de vendas do Google Cloud para discutir outras opções disponíveis.

    O diagrama a seguir mostra a arquitetura de alto nível de uma implantação SAP HANA no Google Cloud com as seguintes provisões de alta disponibilidade e DR:

    • Para conseguir alta disponibilidade, o sistema principal tem dois nós que são implantados em zonas diferentes na mesma região.
    • Para ter resiliência, os sistemas principal e de DR são hospedados em regiões diferentes, com replicação assíncrona.

    Diagrama de arquitetura de alto nível para SAP HANA no Google Cloud com alta disponibilidade e recuperação de desastres.

  • Garantir a capacidade adequada no local de DR.

    • Decida se o sistema de DR precisa ser executado com a mesma capacidade que o sistema principal ou com capacidade reduzida. Para bancos de dados como o SAP HANA, o local de DR precisa ter recursos suficientes para operar a carga de trabalho SAP.
    • Além disso, verifique com antecedência se os recursos necessários estão disponíveis no seu local de DR. Para garantir a disponibilidade dos recursos, é possível provisioná-los no local de DR ou comprar reservas com antecedência. Compras reservas ajuda a evitar cenários em que, após uma falha, os recursos não estejam disponíveis porque estão alocados para outros clientes do Google Cloud. Isso é importante principalmente para tipos maiores de instâncias de computação como M2 ou X4. Para informações sobre reservas, consulte Reservas de recursos zonais do Compute Engine.

    Para ter maior eficiência de custos, a infraestrutura no seu local de DR pode ser usada para cargas de trabalho de não produção e transferida para atender sua carga de trabalho de produção durante um evento de DR. No entanto, isso causa um aumento do tempo de recuperação.

  • Valide a conectividade com seu local de DR. Assim como acontece com caminhos de rede redundantes até seu local principal, considere adicionar outras opções de fall-back como o Cloud VPN.

  • Identificar sinais que podem ser usados para identificar um desastre. Esses sinais ajudam a tomar a decisão sobre quando acionar sua solução de DR. Confira a seguir exemplos desses sinais:

    • Informações sobre a integridade dos serviços do Google Cloud de Integridade do serviço do Google Cloud.
    • Perda completa de disponibilidade da instância, conforme relatada pelo Cloud Monitoring, conforme configurado nos projetos do Google Cloud.
    • Comunicação do Google Cloud Customer Care ou do representante da sua conta do Google Cloud, que oferece consultoria sobre interrupções e possíveis tempos de resolução.
    • Corrupções lógicas no banco de dados determinadas pelos usuários ou administradores do seu sistema SAP, que não podem ser resolvidos por mecanismos de alta disponibilidade.

  • Teste sua solução de DR regularmente. Confira se a solução funciona em caso de um desastre. Isso pode afetar suas operações diárias. Se suas operações permitirem, considere operar de forma simétrica no local primário e secundário e alternar as operações entre eles a cada 3 a 6 meses.

  • Use a replicação para conseguir o melhor ponto de recuperação. A replicação oferece uma versão quase em tempo real do local principal no local de DR. As seguintes opções de replicação estão disponíveis, dependendo de como sua carga de trabalho SAP é projetada:

    • Replicação no nível do banco de dados aproveitando mecanismos como Replicação do sistema SAP HANA, que replica em um nível lógico entre o local principal e o local de DR.
    • Replicação no nível do armazenamento aproveitando mecanismos como Replicação assíncrona de DP, que replica em um nível de armazenamento em blocos. Dependendo da opção de armazenamento usada pela carga de trabalho SAP, as opções de replicação no nível do armazenamento disponíveis são diferentes.

    Monitore a replicação usando uma ferramenta apropriada, como o Cockpit do SAP HANA. Isso ajuda a verificar se a carga de trabalho SAP foi totalmente replicada antes que sua solução de DR seja acionada em caso de um evento de DR.

  • Use backups de dados para fornecer recuperação pontual.

    • Para criar redundância, use vários locais de armazenamento para armazenar seus backups. Por exemplo:
    • Use backups incrementais ou diferenciais, que podem incluir o armazenamento de snapshots no Google Cloud.
    • Monitore seus backups para garantir que eles estejam sendo criados corretamente de acordo com sua estratégia de backup. Para uma solução de proteção de dados completa, considere usar o Serviço de backup e DR do Google Cloud.
    • Testar periodicamente seus backups para garantir que sejam recuperáveis em caso de um desastre e analisar quanto tempo leva para recuperar seu sistema ou seu banco de dados. É aconselhável testar a recuperação uma vez a cada ciclo de backup, que geralmente dura 28 dias.
    • Proteja seus backups da mesma forma que você faria com seu sistema principal, por exemplo, usando configurações de retenção de armazenamento e chaves de criptografia.

Outras recomendações

  • Avalie o custo das configurações de alta disponibilidade e DR em relação ao impacto que elas têm sobre os seguintes aspectos da sua empresa:
    • Potencial de inatividade nas operações e transações comerciais.
    • Possível perda de dados que resulta na perda de vendas, confiança do cliente ou do fornecedor ou falhas de conformidade.
  • Todas as empresas têm considerações únicas. Se a sua situação específica precisar de uma solução mais personalizada, não hesite em entrar em contato com a Equipe de vendas do Google Cloud.

A seguir