Arquitetura de referência: SAP S/4HANA no Google Cloud

Esta arquitetura de referência é destinada a pessoas que estão avaliando o Google Cloud como uma plataforma para implantar cargas de trabalho do SAP S/4HANA. Ela inclui considerações durante a fase de planejamento, modelos de implantação e automação, além de procedimentos operacionais comuns, como tarefas de backup e DR.

O Google Cloud oferece uma infraestrutura econômica, confiável, segura e de alto desempenho para executar o SAP S/4HANA no SAP HANA. Para ver uma lista completa das soluções SAP compatíveis com o Google Cloud, consulte SAP no Google Cloud.

Arquitetura

Os diagramas a seguir mostram uma visualização de alto nível de três modelos de implantação comuns para SAP S/4HANA: centralizado, distribuído e distribuído com alta disponibilidade.

Implantação centralizada

Em uma implantação centralizada, é possível instalar o SAP S/4HANA e o banco de dados SAP HANA na mesma instância de VM do Compute Engine. Recomendamos essa abordagem para ambientes que não estejam relacionados à produção, como ambientes de simulação e de desenvolvimento.

O diagrama a seguir mostra uma arquitetura de referência para SAP S/4HANA no SAP HANA em uma implantação centralizada. O SAP ASCS, PAS, WD e o banco de dados SAP HANA estão instalados na mesma instância de VM.

Diagrama da arquitetura do SAP S/4HANA no Google Cloud em uma implantação centralizada.

Implantação distribuída

Em uma implantação distribuída, é possível instalar os diferentes componentes em instâncias diferentes do Compute Engine. Recomendamos essa abordagem para ambientes de produção ou que exigem muita capacidade computacional para processar cargas intensas de transação.

O diagrama a seguir mostra uma arquitetura de referência para SAP S/4HANA em uma implantação distribuída. SAP ASCS, PAS, WD e HANA estão instalados em instâncias diferentes.

Diagrama da arquitetura do SAP S/4HANA no Google Cloud em uma implantação distribuída.

Implantação distribuída com alta disponibilidade

Em uma implantação distribuída com alta disponibilidade, os clusters do Linux são configurados entre zonas para ajudar a proteger contra falhas de componentes em uma determinada região. É possível implantar um cluster do Linux entre zonas usando uma configuração ativa/passiva ou uma configuração ativa/ativa. Nos dois casos, comece configurando duas instâncias de VM do Compute Engine em zonas separadas para redundância máxima, cada uma com o próprio banco de dados do SAP HANA. O diagrama a seguir mostra uma arquitetura SAP S/4HANA que usa um cluster do Linux para conseguir alta disponibilidade no lado do aplicativo e do banco de dados SAP HANA:

Diagrama da arquitetura do SAP S/4HANA no Google Cloud em uma implantação distribuída de alta disponibilidade. Os diagramas a seguir mostram um banco de dados SAP HANA que está altamente disponível durante a operação normal e uma operação de transferência:

  • Operação normal:

    Diagrama de arquitetura para alta disponibilidade do SAP HANA no Google Cloud durante a operação normal.

  • Operação de aquisição:

    Diagrama de arquitetura para alta disponibilidade do SAP HANA no Google Cloud durante a operação de transferência.

Para combinar alta disponibilidade e recuperação de desastres para o banco de dados, use a replicação do sistema SAP HANA. O diagrama a seguir mostra uma combinação de ambos para alcançar disponibilidade máxima e tolerância a falhas:

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

O cluster que gerencia a alta disponibilidade inclui as seguintes funções e recursos:

  • Duas VMs de host, cada uma com uma instância do SAP HANA.
  • Replicação síncrona do sistema SAP HANA.
  • O gerenciador de recursos do cluster de alta disponibilidade do Pacemaker
  • Um mecanismo de isolamento que isola o nó com falha.
  • Reinicialização automática da instância com falha como nova instância secundária

A arquitetura no lado do aplicativo é semelhante. Nesse caso, o cluster gerencia o ABAP SAP Central Services (ASCS) e o servidor de replicação de enfileiramento ou o replicador de enfileiramento (ERS, na sigla em inglês), que são usados para fornecer ao sistema SAP S/4HANA alta disponibilidade em casos de algo acontece com qualquer instância do ASCS e do ERS.

Dependendo da versão do SAP S/4HANA usada, o servidor de enfileiramento e o servidor de replicação de enfileiramento / replicador de enfileiramento são executados em uma versão diferente:

  • S/4HANA 1709 e anteriores: ENSA1 e ERS.
  • S/4HANA 1809 ou mais recente: ENSA2 e ERS2.

O diagrama a seguir mostra um sistema SAP S/4HANA usando um cluster do Pacemaker para limitar os pontos únicos de falha do servidor de mensagens e do servidor de enfileiramento:

Diagrama da arquitetura do SAP NetWeaver com um banco de dados em uma implantação de alta disponibilidade no Google Cloud.

Os detalhes sobre a implantação do sistema de alta disponibilidade e o clustering do Linux entre zonas são abordados posteriormente neste documento.

Uma observação sobre o balanceamento de carga

Em um ambiente SAP S/4HANA distribuído, o balanceamento de carga é obrigatório. É possível configurar o balanceamento de carga de aplicativo usando uma combinação da camada de aplicativos SAP e balanceadores de carga de rede. Para mais informações, consulte a seção Implementações de VIP do balanceador de carga de rede de passagem interna no guia de planejamento de alta disponibilidade para SAP NetWeaver no Google Cloud.

Componentes de implantação

O SAP S/4HANA consiste nos seguintes componentes técnicos:

  • Banco de dados SAP HANA
  • ASCS: ABAP SAP Central Services
    • Contém o servidor de mensagens e o servidor de enfileiramento, que são necessários em qualquer sistema SAP ABAP.
    • implantadas na própria instância de VM em implantações de alta disponibilidade ou na instância de VM que hospeda o PAS;
    • Em implantações de HA, os recursos do ASCS são gerenciados por um gerenciador de recursos de cluster do Linux, como o Pacemaker.
  • ERS: servidor de replicação de enfileiramento ou replicador de fila
    • Implantado em implantações de alta disponibilidade para manter uma réplica da tabela de bloqueio caso algo aconteça com a instância do ASCS.
    • Gerenciado por um gerenciador de recursos de cluster do Linux, como o Pacemaker.
  • PAS: servidor principal de aplicativos
    • O primeiro ou único servidor de aplicativos do sistema SAP.
  • AAS: servidor extra de aplicativos
    • Costuma ser implantado para balancear a carga em nível de aplicativo. Também é possível instalar várias instâncias AAS para ter maior disponibilidade a partir de uma perspectiva de camadas de aplicativos. Se um dos servidores de aplicativos ficar inativo, todas as sessões do usuário conectadas a esse servidor serão encerradas, mas os usuários poderão fazer login novamente em outro AAS no ambiente.
  • Gateway do SAP NetWeaver
    • Implantado como um sistema autônomo ou como parte do sistema SAP S/4HANA.
    • Permite que o sistema conecte dispositivos, ambientes e plataformas a sistemas SAP usando o Open Data Protocol (OData).
  • Servidor de front-end do SAP Fiori
    • Implantado como um sistema autônomo ou como parte do sistema SAP S/4HANA.
    • O sistema SAP Netweaver ABAP é usado para hospedar aplicativos SAP Fiori.
  • WD: Web Dispatcher (opcional)
    • Balanceador de carga de software inteligente que distribui solicitações HTTP e HTTPS com base no tipo de aplicativo, para PAS e AAS.

Os seguintes serviços do Google Cloud são usados na implantação do SAP S/4HANA:

Serviço Descrição
Criação de redes VPC

Conecta as instâncias de VM entre si e à Internet.

Cada instância de VM é membro de uma rede legada com um intervalo de IPs global ou de uma rede de sub-redes recomendada, em que a instância de VM é membro de uma sub-rede que faz parte de uma rede maior.

Uma rede de nuvem privada virtual (VPC) não pode abranger projetos do Google Cloud, mas um projeto do Google Cloud pode ter várias redes VPC.

Para conectar recursos de vários projetos a uma rede VPC comum, use a VPC compartilhada. Assim, os recursos podem se comunicar uns com os outros de maneira segura e eficiente usando endereços IP internos dessa rede. Para informações sobre como provisionar uma VPC compartilhada, incluindo requisitos, etapas de configuração e uso, consulte Provisionar VPC compartilhada.

Compute Engine Cria e gerencia VMs com sua opção de sistema operacional e pilha de software.
Persistent Disk e Hyperdisk

É possível usar o Persistent Disk e o Hyperdisk do Google Cloud:

  • Os volumes do Persistent Disk estão disponíveis como unidades de disco rígido (HDD) padrão ou unidades de estado sólido (SSD). Para discos permanentes equilibrados e discos permanentes SSD, a PD Async Replication fornece replicação assíncrona de dados SAP entre duas regiões do Google Cloud.
  • Os volumes extremos do hiperdisco têm opções máximas de IOPS e a capacidade de processamento do que os volumes de disco permanente SSD.
  • Por padrão, o Compute Engine criptografa o conteúdo do cliente em repouso, incluindo o conteúdo dentro dos volumes do Persistent Disk e do Hyperdisk. Para mais informações sobre criptografia de disco e possíveis opções, consulte Sobre a criptografia de disco.
Console do Google Cloud

Uma ferramenta baseada em navegador para gerenciar recursos do Compute Engine.

Use um modelo para descrever todos os recursos e instâncias necessários do Compute Engine. Não é preciso criar e configurar individualmente os recursos nem descobrir dependências, porque o console do Google Cloud faz isso para você.
Cloud Storage Armazene seus backups de bancos de dados SAP no Cloud Storage para maior durabilidade e confiabilidade, com replicação.
Cloud Monitoring

Fornece visibilidade sobre a implantação, o desempenho, o tempo de atividade, bem como sobre a integridade do Compute Engine, da rede e dos discos de armazenamento permanentes.

O Monitoring coleta métricas, eventos e metadados do Google Cloud para oferecer insights com painéis, gráficos e alertas. É possível monitorar as métricas de computação sem custos por meio do Monitoring.
IAM

Fornece controle unificado sobre permissões para recursos do Google Cloud.

O IAM permite controlar quem pode executar operações de plano de controle nas VMs, incluindo criação, modificação e exclusão de VMs e discos de armazenamento permanente, além de criação e modificação de redes.
Filestore

Armazenamento de arquivos NFS totalmente gerenciado e de alto desempenho do Google Cloud.

Para implantações de alta disponibilidade multizonais, recomendamos o uso do Filestore Enterprise que tem um SLA de disponibilidade de 99,99%. Para informações sobre os níveis de serviço do Filestore, consulte Níveis de serviço.
NetApp Cloud Volumes ONTAP

Uma solução de armazenamento inteligente e completa que você implanta e gerencia por conta própria em uma instância de VM do Compute Engine.

Para mais informações sobre o NetApp Cloud Volumes ONTAP, consulte Visão geral do Cloud Volumes ONTAP.
Google Cloud NetApp Volumes

Uma solução totalmente gerenciada de armazenamento de arquivos NFS e SMB do Google Cloud, com tecnologia do NetApp Cloud Volumes ONTAP.

Dependendo da região, pode haver vários níveis de serviço disponíveis para seleção. Para mais informações, consulte Níveis de serviço.

Considerações sobre o design

Nesta seção, fornecemos orientações para ajudar você a usar essa arquitetura de referência para desenvolver uma arquitetura que atenda aos requisitos específicos de segurança, confiabilidade, eficiência operacional, custo e desempenho.

Rede

Há várias maneiras de implantar um sistema SAP S/4HANA do ponto de vista da rede, e a implantação da rede tem um impacto significativo na disponibilidade, resiliência e desempenho. Como mencionado anteriormente, uma nuvem privada virtual (VPC) é uma rede privada segura e isolada hospedada no Google Cloud. As VPCs são globais no Google Cloud. Portanto, uma VPC única pode abranger várias regiões sem se comunicar pela Internet.

Uma implantação típica do SAP coloca as instâncias de sistemas de alta disponibilidade em diferentes zonas na mesma região para garantir resiliência e fornecer baixa latência. As sub-redes podem abranger várias zonas devido aos recursos do Google Cloud. Esses recursos também simplificam o clustering SAP, porque o endereço IP virtual (VIP, na sigla em inglês) do cluster pode estar no mesmo intervalo que as instâncias dos sistemas de alta disponibilidade. Essa configuração protege o IP flutuante usando um balanceador de carga de aplicativo interno e é aplicável ao clustering de alta disponibilidade da camada do aplicativo (ASCS e ERS) e à camada de banco de dados do SAP HANA (primário e secundário do SAP HANA).

Há várias maneiras de criar sua rede e conectar o sistema SAP S/4HANA à sua infraestrutura:

  • O peering de rede VPC conecta duas redes VPC para que os recursos em cada rede possam se comunicar entre si. As redes VPC podem ser hospedadas no mesmo projeto do Google Cloud, em projetos diferentes da mesma organização ou até mesmo em projetos diferentes de organizações diferentes. O peering de rede VPC estabelece uma conexão direta entre duas redes VPC, cada uma usando as próprias sub-redes, permitindo a comunicação particular entre recursos nas VPCs com peering.

  • A VPC compartilhada é um recurso do Google Cloud que permite que uma organização conecte recursos de vários projetos a uma rede VPC comum. Os sistemas que usam uma VPC compartilhada podem se comunicar com eficiência e segurança usando endereços IP internos. É possível gerenciar centralmente recursos de rede, como sub-redes, rotas e firewalls em um projeto host, além de delegar responsabilidades administrativas para criar e gerenciar recursos individuais a projetos de serviço. Essa separação de conceitos simplifica a administração da rede e aplica políticas de segurança consistentes em toda a organização.

Para sistemas SAP, geralmente é recomendável agrupar recursos por tipo de ambiente. Por exemplo, os ambientes de produção não podem compartilhar recursos de computação com ambientes de não produção a fim de fornecer isolamento adequado. No entanto, é possível usar uma VPC compartilhada para uma camada comum de conectividade entre os projetos. Também é possível usar VPCs independentes e usar o peering de VPC para conectar projetos.

Ao projetar sua rede, comece com um projeto host que contenha uma ou mais redes VPC compartilhadas. É possível anexar outros projetos de serviço a um projeto host, o que permite que eles participem da VPC compartilhada. Dependendo das suas necessidades, é possível implantar o SAP S/4HANA em uma única VPC compartilhada ou em várias VPCs compartilhadas. Os dois cenários diferem em termos de controle de rede, isolamento de ambiente SAP e inspeção de rede:

  • Cenário 1: como implantar o SAP S/4HANA em uma única VPC compartilhada. Isso simplifica a implantação e reduz a sobrecarga administrativa em detrimento do menor isolamento entre as redes.
  • Cenário 2: como implantar o SAP S/4HANA em várias VPCs compartilhadas. Isso aumenta o isolamento de rede e adiciona segurança, à custa de aumentar a complexidade e a sobrecarga administrativa.

Também é possível usar uma abordagem híbrida. Por exemplo, é possível usar uma VPC compartilhada para o ambiente de produção e outra para todos os sistemas que não sejam de produção. Para mais informações, consulte a seção "Rede" em Lista de verificação geral para SAP no Google Cloud.

Pontos únicos de falha

Um sistema SAP S/4HANA tem alguns pontos únicos de falha comuns que podem afetar a disponibilidade do sistema:

  • SAP Central Services, como Message Server e Enqueue Server
  • Servidor de aplicativos SAP
  • Banco de dados SAP HANA
  • SAP Web Dispatcher, se usado como um front-end para acesso HTTP/HTTPS ao sistema
  • Armazenamento compartilhado, como NFS

Há várias opções para reduzir o impacto desses pontos únicos de falha e essas opções envolvem a implantação do sistema usando soluções de alta disponibilidade, serviços de replicação ou outras funcionalidades que protegem o sistema contra falhas. Ao planejar seu sistema SAP S/4HANA, recomendamos que você estude esses pontos únicos de falha e planeje de acordo. Para uma visão geral sobre as soluções alternativas que podem ser usadas para gerenciar pontos únicos de falha, consulte as seções a seguir neste guia:

Disponibilidade e continuidade

Durante a fase de planejamento da implementação de um sistema SAP S/4HANA, é necessário especificar os seguintes pontos de dados para definir a disponibilidade e a continuidade do sistema:

  • Objetivos de nível de serviço (SLO): um valor alvo ou intervalo de valores para um nível de serviço medido por um indicador de nível de serviço (SLI). Por exemplo: desempenho, disponibilidade e confiabilidade.
  • Indicadores de nível de serviço (SLI): métricas, como latência, que ajudam a medir o desempenho de um serviço. É uma medida quantitativa cuidadosamente definida de algum aspecto do nível de serviço oferecido.
  • Contrato de nível de serviço (SLA): um contrato de serviço entre duas partes (provedor, cliente) que define um acordo sobre o serviço fornecido em termos mensuráveis chamados de objetivos de nível de serviço (SLOs).
  • Objetivo do tempo de recuperação (RTO, na sigla em inglês): a duração máxima tolerável entre um incidente de perda de dados e a mitigação dele.
  • Objetivo do ponto de recuperação (RPO, na sigla em inglês): é a quantidade máxima de dados que pode ser perdida, medida em tempo, sem causar danos significativos. Na prática, isso se traduz no momento em que o estado dos dados afetados precisa ser recuperado após um evento de perda de dados.

Dependendo dos pontos de dados e dos valores acordados entre todas as partes interessadas, o sistema SAP S/4HANA depende de recursos como alta disponibilidade ou recuperação de desastres:

  • Alta disponibilidade (HA, na sigla em inglês): a capacidade de um sistema que oferece suporte ao objetivo de continuidade dos negócios, garantindo que os dados e serviços estejam disponíveis para os usuários quando necessário. A maneira comum de alcançar esse recurso é ativar a redundância, incluindo redundância de hardware, de rede e de data center.
  • Recuperação de desastres (DR): a capacidade de um sistema ser protegido contra interrupções não planejadas por meio de métodos de recuperação confiáveis e previsíveis em um hardware e/ou local físico diferente.

Tanto a alta disponibilidade quanto a recuperação de desastres são compatíveis, mas abrangem casos e situações diferentes. Por exemplo, uma solução de alta disponibilidade permite que você continue com suas operações se um dos elementos do sistema tiver uma inatividade ou interrupção não planejada sem causar nenhuma interrupção para os usuários. O mesmo pode ser dito sobre uma solução de DR, com exceção da interrupção do momento em que ela ocorre até que a solução de DR inicie os elementos com falha do sistema em um local diferente.

As seções a seguir fornecem uma visão geral das diferentes opções que você tem ao planejar e implantar seu sistema SAP S/4HANA no Google Cloud.

Tipos de máquina com suporte para SAP S/4HANA

O Google Cloud oferece tipos de instância de VM do Compute Engine certificados pela SAP para atender aos requisitos de dimensionamento ao implantar o SAP S/4HANA. Para mais informações sobre o dimensionamento no Google Cloud e os tipos de máquina com suporte, consulte os seguintes documentos:

Os tipos de máquina personalizados para SAP HANA no Google Cloud também são certificados pela SAP. É possível executar instâncias do SAP HANA com menos de 64 vCPUs, desde que você mantenha uma proporção de vCPU à memória de pelo menos 1:6,5.

Para conferir os números SAPS das máquinas virtuais do Compute Engine certificadas para aplicativos SAP, consulte a Nota SAP 2456432 - Aplicativos SAP no Google Cloud: produtos compatíveis e tipos de máquinas do Google Cloud .

A SAP também fornece no site uma lista certificada de configurações do Google Cloud para SAP HANA. Para mais informações, consulte o Diretório de hardware certificado e compatível do SAP HANA.

Planejar regiões e zonas

Ao implantar uma VM, é preciso escolher uma região e uma zona. As regiões são localizações geográficas específicas em que é possível executar recursos e correspondem a um ou mais locais de data center relativamente próximos uns dos outros. Cada região tem uma ou mais zonas com conectividade, energia e resfriamento redundantes.

Os recursos globais, como snapshots e imagens de disco pré-configurados, podem ser acessados em regiões e zonas. Os recursos regionais, como endereços IP externos estáticos, podem ser acessados apenas por recursos que estão na mesma região. Os recursos zonais, como VMs e discos, podem ser acessados apenas por recursos localizados na mesma zona. Para mais informações, consulte Recursos globais, regionais e zonais.

Regiões e zonas do Google Cloud.

Ao escolher uma região e uma zona para suas VMs, considere o seguinte:

  • A localização dos usuários e dos recursos internos, como o data center ou a rede corporativa. Para diminuir a latência, selecione um local próximo aos usuários e aos recursos.
  • As plataformas de CPU disponíveis para essa região e zona. Por exemplo, os processadores Broadwell, Haswell, COPPA e Ice Lake da Intel são compatíveis com cargas de trabalho do SAP NetWeaver no Google Cloud.
  • Verifique se o servidor de aplicativos SAP e o banco de dados estão na mesma região.

Opções de armazenamento para SAP S/4HANA

Confira a seguir as opções de armazenamento oferecidas pelo Google Cloud que são certificadas pela SAP para uso com o SAP S/4HANA e o SAP HANA.

Para informações gerais sobre as opções de armazenamento no Google Cloud, consulte Opções de armazenamento.

Persistent Disk

  • Discos permanentes padrão (pd-standard): armazenamento em blocos eficiente e econômico com suporte de unidades de disco rígido (HDD) padrão para processar operações sequenciais de leitura/gravação, mas não otimizado para lidar com altas taxas de operações aleatórias de entrada/saída por segundo (IOPS).
  • Disco permanente SSD (pd-ssd): fornece armazenamento em blocos confiável e de alto desempenho, com unidades de estado sólido (SSD).
  • Disco permanente equilibrado (pd-balanced): fornece armazenamento em blocos baseado em SSD confiável e econômico.
  • Disco permanente extremo (pd-extreme): baseado em SSD oferece opções máximas de IOPS e capacidade de processamento do que pd-ssd para tipos de máquina maiores do Compute Engine. Para mais informações, consulte Discos permanentes extremos.

Hiperdisco

  • O Hyperdisk Extreme (hyperdisk-extreme) oferece opções máximas de IOPS e capacidade de processamento do que os tipos de discos permanentes baseados em SSD. Você seleciona o desempenho necessário para provisionar IOPS, que determina a capacidade de processamento. O melhor uso é para hospedar os diretórios /hana/data e /hana/log. Para mais informações, consulte Sobre o Google Cloud Hyperdisk.

  • Hiperdisco balanceado (hyperdisk-balanced): a melhor opção para a maioria das cargas de trabalho. Recomendamos essa opção para uso com bancos de dados que não exigem o desempenho do Hyperdisk Extreme. Você seleciona a performance necessária provisionando a IOPS e a capacidade de processamento. É possível usar os volumes balanceados de hiperdisco para hospedar os diretórios /hana/data e /hana/log. Para mais informações, consulte Sobre o Google Cloud Hyperdisk.

O Persistent Disk e o Hyperdisk foram projetados para alta durabilidade. Eles armazenam dados de maneira redundante para garantir a integridade dos dados. Cada volume de disco permanente pode armazenar até 64 TB, de modo que você possa criar grandes volumes lógicos sem gerenciar conjuntos de discos. Os volumes de hiperdisco também permitem até 64 TB de armazenamento, dependendo do tipo usado. Um recurso importante é que os volumes do Persistent Disk e do hiperdisco são criptografados automaticamente para proteger os dados.

Após a criação, uma instância de VM do Compute Engine aloca um único disco permanente raiz ou um hiperdisco que contém o sistema operacional. É possível adicionar mais opções de armazenamento à instância de VM, conforme necessário.

Para implementações SAP, analise as opções de armazenamento recomendadas na estrutura de diretório e opções de armazenamento do SAP.

Soluções de compartilhamento de arquivos

Várias soluções de compartilhamento de arquivos estão disponíveis no Google Cloud, incluindo as seguintes:

  • Filestore: armazenamento de arquivos NFS totalmente gerenciado e de alto desempenho do Google Cloud com disponibilidade regional.
  • Google Cloud NetApp Volumes: uma solução de armazenamento de arquivos NFS ou SMB totalmente gerenciada do Google Cloud.
  • NetApp Cloud Volumes ONTAP: uma solução de armazenamento inteligente e completa que você implanta e gerencia em uma VM do Compute Engine.
  • NetApp Cloud Volumes Service para Google Cloud: uma solução de armazenamento de arquivos de alto desempenho e totalmente gerenciada da NetApp que pode ser implantada no console do Google Cloud.

Para mais informações sobre soluções de compartilhamento de arquivos para SAP S/4HANA no Google Cloud, consulte Soluções de compartilhamento de arquivos para SAP no Google Cloud.

Cloud Storage para armazenamento de objetos

O Cloud Storage é um repositório de objetos para arquivos de qualquer tipo ou formato. Ele tem armazenamento praticamente ilimitado, e não é preciso se preocupar em provisioná-lo ou adicionar mais capacidade. Um objeto no Cloud Storage contém dados de arquivos e metadados associados e pode ter até 5 TB. Um bucket do Cloud Storage pode armazenar qualquer número de objetos.

É uma prática comum usar o Cloud Storage para armazenar arquivos de backup para praticamente qualquer finalidade. Por exemplo, o Cloud Storage é um bom local para armazenar os backups do banco de dados SAP HANA. Para informações sobre o planejamento de backup do banco de dados, consulte Backup e recuperação do banco de dados. Também é possível usar o Cloud Storage como parte de um processo de migração.

Além disso, é possível usar o serviço de backup e DR como uma solução centralizada para operações de backup e recuperação de desastres. Esse serviço oferece suporte a um amplo espectro de bancos de dados, incluindo SAP HANA. Para mais informações, consulte Soluções de backup e recuperação de desastres com o Google Cloud.

Escolha sua opção do Cloud Storage com base na frequência com que precisa acessar os dados. Para acesso frequente, como várias vezes por mês, selecione a classe de armazenamento Standard. Para acesso pouco frequente, selecione Nearline ou Coldline Storage. Para dados arquivados, que você não espera acessar, selecione Archive Storage.

Estrutura de diretórios e opções de armazenamento do SAP

As tabelas a seguir descrevem as estruturas de diretório do Linux para bancos de dados SAP HANA e instâncias do SAP ABAP no Google Cloud.

  • Opções de armazenamento recomendadas para a estrutura de diretórios do Linux no SAP HANA:

    Diretório do SAP HANA Opção de armazenamento recomendada no Google Cloud
    /usr/sap Disco permanente equilibrado
    /hana/data Disco permanente ou hiperdisco baseado em SSD
    /hana/log Disco permanente ou hiperdisco baseado em SSD
    /hana/shared* Disco permanente equilibrado
    /hanabackup* Disco permanente equilibrado

    Em implantações distribuídas, /hana/shared e /hanabackup também podem ser montados como um sistema de arquivos de rede usando uma solução NFS, como o Filestore.

    Para informações sobre armazenamento de disco permanente certificado para uso pela SAP com o SAP HANA, consulte Armazenamento de disco permanente para SAP HANA.

  • Opções de armazenamento recomendadas para a estrutura de diretórios do Linux na instância do SAP ABAP:

    Diretório Opção de armazenamento recomendada no Google Cloud
    /sapmnt† Disco permanente equilibrado
    /usr/sap Disco permanente equilibrado

    Em implantações distribuídas, o /sapmnt também pode ser montado como um sistema de arquivos de rede usando uma solução NFS, como Filestore.

    Para informações sobre armazenamento de disco permanente certificado para uso pela SAP com instâncias do SAP ABAP, consulte Armazenamento de disco permanente para aplicativos SAP.

Suporte a SO para SAP S/4HANA

Ao escolher um sistema operacional (SO) para o SAP NetWeaver no Google Cloud, além de precisar confirmar se a versão do SO é certificada pela SAP, é necessário verificar se todas as três empresas, a SAP, o fornecedor do SO e o Google Cloud, ainda aceitam a versão do SO.

Sua decisão também precisa considerar o seguinte:

  • Confirme se uma determinada versão do SO está disponível no Google Cloud. As imagens do SO fornecidas pelo Compute Engine são configuradas para funcionar com o Google Cloud. Se um SO não estiver disponível no Google Cloud, será possível trazer sua própria imagem do SO (BYOI) e licença. As imagens de SO do BYOI são identificadas pelo Compute Engine como imagens personalizadas.
  • As opções de licenciamento disponíveis para uma determinada versão do SO. Verifique se a versão do SO tem uma opção de licenciamento sob demanda ou se você precisa trazer sua própria assinatura (BYOS, na sigla em inglês) do fornecedor do SO.
  • Se os recursos integrados de alta disponibilidade de uma determinada versão do SO estão ativados para o Google Cloud.
  • A opção de desconto por compromisso de uso para imagens SLES para SAP e RHEL para SAP.

Os sistemas operacionais a seguir são certificados pela SAP para uso com o SAP NetWeaver no Google Cloud:

Você pode encontrar mais informações sobre versões específicas do SO e a compatibilidade com o SAP S/4HANA e o SAP HANA nos seguintes guias:

Opção de reinicialização rápida do SAP HANA

Para o SAP HANA 2.0 SP04 e versões posteriores, o Google Cloud recomenda fortemente a opção de Reinicialização rápida do SAP HANA.

Essa opção é ativada automaticamente quando você implanta o SAP HANA usando os seguintes módulos do Terraform fornecidos pelo Google Cloud: módulo sap_hana ou sap_hana_ha, versão 202309280828 ou mais recente. Para informações sobre como ativar manualmente a reinicialização rápida do SAP HANA, consulte Como ativar a reinicialização rápida do SAP HANA.

A reinicialização rápida do SAP HANA reduz os tempos de reinicialização caso o SAP HANA seja encerrado, mas o sistema operacional continua em execução. Para reduzir o tempo de reinicialização, o SAP HANA usa o recurso de memória permanente do SAP HANA para preservar os fragmentos de dados MAIN nas tabelas de armazenamento de colunas no DRAM que é mapeada para o sistema de arquivos tmpfs.

Além disso, em VMs nas famílias M2 e M3 dos tipos de máquina com otimização de memória do Compute Engine, o SAP HANA Fast Restart melhora o tempo de recuperação quando ocorrem erros não corrigidos na memória. Para mais informações, consulte a opção de reinicialização rápida do SAP HANA.

Arquitetura de implantação do SAP HANA

O SAP HANA é um componente essencial de qualquer sistema SAP S/4HANA porque atua como um banco de dados para o sistema. Há duas arquiteturas possíveis que podem ser usadas ao implantar o banco de dados SAP HANA: escalonamento vertical e escalonamento horizontal.

Arquitetura de escalonamento vertical

O diagrama a seguir mostra uma arquitetura de escalonamento horizontal para o SAP HANA no Google Cloud. No diagrama, observe a implantação no Google Cloud e o layout do disco. Use o Cloud Storage para fazer backup dos seus backups locais disponíveis em /hanabackup. Essa ativação será igual ou maior que a ativação de dados.

Diagrama de arquitetura para a implantação de um sistema de escalonamento vertical do SAP HANA no Google Cloud.

Arquitetura de escalonamento horizontal

A arquitetura de escalonamento horizontal do SAP HANA consiste em um host mestre, vários hosts workers e, opcionalmente, um ou mais hosts em espera. Os hosts são interconectados por uma rede compatível com o envio de dados entre hosts em taxas de até 32 Gbps ou até 100 Gbps em tipos de máquina selecionados usando rede de alta largura de banda

À medida que a demanda da carga de trabalho aumenta, especialmente ao usar o processamento analítico on-line (OLAP, na sigla em inglês), uma arquitetura de escalonamento horizontal de vários hosts pode distribuir a carga entre todos os hosts.

O diagrama a seguir mostra uma arquitetura de escalonamento horizontal para o SAP HANA no Google Cloud:

Diagrama de arquitetura para a implantação de um sistema de escalonamento horizontal do SAP HANA no Google Cloud.

Arquitetura de implantação para SAP S/4HANA

Como mencionado na seção Arquitetura, há várias arquiteturas de implantação que podem ser usadas para implantar o SAP S/4HANA no Google Cloud.

Arquitetura de dois níveis

Essa arquitetura é apresentada na seção implantação centralizada. O diagrama a seguir mostra alguns detalhes de uma arquitetura de duas camadas para o SAP S/4HANA em execução em uma VM do Compute Engine:

Arquitetura de duas camadas para SAP S/4HANA em uma VM do Compute Engine no Google Cloud.

Arquitetura de três níveis

Essa arquitetura é apresentada na seção de implantação distribuída. É possível usar essa arquitetura para implantar sistemas SAP S/4HANA de alta disponibilidade. O diagrama a seguir mostra alguns detalhes de uma arquitetura de três camadas para o SAP S/4HANA em execução nas VMs do Compute Engine:

Arquitetura de três camadas para SAP S/4HANA em VMs do Compute Engine no Google Cloud.

Nessa arquitetura, o sistema SAP S/4HANA distribui o trabalho entre vários servidores de aplicativos (AS) do NetWeaver, cada um hospedado em uma VM separada. Todos os nós do NetWeaver AS compartilham o mesmo banco de dados que é hospedado em uma VM separada. Todos os nós do NetWeaver AS ativam e acessam um sistema de arquivos compartilhado que hospeda os perfis do SAP NetWeaver. Esse sistema de arquivos compartilhado é hospedado em um volume de disco permanente compartilhado por todos os nós ou em uma solução de compartilhamento de arquivos compatível.

segurança, privacidade e conformidade

Esta seção fornece informações sobre segurança, privacidade e conformidade para executar o SAP S/4HANA no Google Cloud.

Controles soberanos e de conformidade

Se você precisar que a carga de trabalho da SAP seja executada em conformidade com residência de dados, controle de acesso, equipes de suporte ou requisitos regulatórios, faça o planejamento para usar o Assured Workloads, um serviço que ajuda a executar cargas de trabalho seguras e conformes no Google Cloud sem comprometer a qualidade da sua experiência na nuvem. Para mais informações, consulte Controles soberanos e de conformidade para a SAP no Google Cloud.

Rede e segurança da rede

Analise as informações nas seções a seguir ao planejar a rede e a segurança dela.

Modelo de privilégio mínimo

Uma das primeiras linhas de defesa é restringir quem pode acessar sua rede e suas VMs. Para fazer isso, use as regras de firewall da VPC. Por padrão, todo o tráfego para VMs, mesmo proveniente de outras VMs, é bloqueado pelo firewall, a menos que você crie regras para permitir o acesso. A exceção é a rede padrão, que é criada automaticamente com cada projeto e tem regras de firewall padrão.

Ao criar regras de firewall VPC, restrinja todo o tráfego em um determinado conjunto de portas a endereços IP de origem específicos. Para restringir o acesso a portas, protocolos e endereços IP específicos que precisam de acesso, siga o modelo de privilégio mínimo. Por exemplo, sempre configure um Bastion Host e autorize comunicações SSH no sistema SAP NetWeaver somente desse host.

Regras de firewall e redes personalizadas

É possível usar uma rede para definir um IP de gateway e o intervalo de redes referente às VMs conectadas a essa rede. Todas as redes do Compute Engine usam o protocolo IPv4. Todo projeto do Google Cloud tem uma rede padrão com configurações predefinidas e regras de firewall, mas recomendamos adicionar uma sub-rede personalizada e regras de firewall com base em um modelo de privilégio mínimo. Por padrão, uma rede recém-criada não tem regras de firewall e, portanto, nenhum acesso à rede.

Convém adicionar mais de uma sub-rede se você quiser isolar partes de sua rede ou atender a outros requisitos. Para mais informações, consulte Redes e sub-redes.

As regras de firewall se aplicam à rede inteira e a todas as VMs nela. Adicione uma regra de firewall que permita o tráfego entre as VMs na mesma rede e entre sub-redes. Também é possível configurar os firewalls para serem aplicados a VMs de destino específicas usando tags de rede.

O SAP exige acesso a determinadas portas. Portanto, adicione regras de firewall para permitir o acesso às portas descritas pelo SAP (em inglês).

Rotas

Rotas são recursos globais anexados a uma única rede. As rotas criadas pelo usuário se aplicam a todas as VMs de uma rede. Isso significa que é possível adicionar uma rota que encaminhe o tráfego entre VMs na mesma rede e entre sub-redes sem a necessidade de endereços IP externos.

Para ter acesso externo a recursos da Internet, inicie uma VM sem endereço IP externo e configure outra VM como um gateway NAT. Essa configuração exige que você adicione o gateway NAT como uma rota para a instância SAP.

Bastion Hosts e gateways NAT

Caso a política de segurança exija VMs realmente internas, será preciso configurar um proxy NAT manualmente na rede e uma rota correspondente para que as VMs possam acessar a Internet. É importante observar que não é possível se conectar diretamente a uma instância de VM totalmente interna usando SSH.

Para se conectar a essas máquinas internas, é necessário configurar uma instância bastion que tenha um endereço IP externo e, em seguida, fazer o túnel nela. Quando as VMs não têm endereços IP externos, elas só podem ser acessadas por outras VMs na rede ou por meio de um gateway VPN gerenciado. É possível provisionar VMs na rede para que atuem como redirecionamentos confiáveis para conexões de entrada, chamados de Bastion hosts, ou saídas de rede, chamadas de gateways NAT. Para oferecer uma conectividade mais transparente sem configurar essas conexões, use um recurso de gateway de VPN gerenciado.

Bastion Hosts para conexões de entrada

Os Bastion Hosts fornecem um ponto de entrada externo em uma rede que contém VMs de rede privada. Esse host pode fornecer um único ponto de fortalecimento ou auditoria e pode ser iniciado e interrompido para ativar ou desativar a comunicação SSH de entrada pela Internet.

Bastion Host no cenário SSH.

Para ter acesso SSH a VMs que não têm um endereço IP externo, primeiro conecte-se a um Bastion Host. Uma proteção completa de um Bastion Host está fora do escopo deste documento, mas algumas etapas iniciais tomadas podem incluir as ações a seguir:

  • limitar o intervalo CIDR de IPs de origem que podem se comunicar com o Bastion;
  • Configurar as regras de firewall a fim de permitir o tráfego SSH para VMs particulares apenas do Bastion Host.

Por padrão, o SSH em VMs é configurado para usar chaves privadas para autenticação. Ao usar um Bastion Host, primeiro faça login no Bastion Host e, depois, na VM particular de destino. Devido a esse login em duas etapas, recomendamos que você use o encaminhamento do agente SSH para alcançar a VM de destino em vez de armazenar a chave privada dela no Bastion Host. Faça isso mesmo que você esteja usando o mesmo par de chave-valor para as VMs de destino e Bastion, porque o Bastion tem acesso direto somente à metade pública do par de chaves.

Gateways NAT para a transferência de dados de saída

Quando uma VM não tem um endereço IP externo atribuído, não é possível fazer conexões diretas com serviços externos, incluindo outros serviços do Google Cloud. Para permitir que essas VMs tenham acesso a serviços na Internet, defina e configure um gateway NAT. O gateway NAT é uma VM capaz de rotear o tráfego em nome de qualquer outra VM na rede. Use um gateway NAT por rede. Um gateway NAT de VM única não tem alta disponibilidade e não é compatível com alta capacidade de tráfego para várias VMs. Para informações sobre como configurar uma VM para atuar como gateway NAT, consulte o guia de implantação do seu sistema operacional:

Cloud VPN

É possível conectar com segurança sua rede atual ao Google Cloud por meio de uma conexão VPN que use o IPsec usando o Cloud VPN. O tráfego entre as duas redes é criptografado por um gateway de VPN e depois descriptografado pelo outro. Isso protege os dados enquanto eles são transmitidos pela Internet. Também é possível controlar dinamicamente quais VMs podem enviar tráfego pela VPN usando tags de instância nas rotas. Os túneis do Cloud VPN são faturados a uma taxa mensal estática mais cobranças padrão pela transferência de dados de saída. Conectar duas redes no mesmo projeto ainda gera cobranças padrão pela transferência de dados de saída. Confira mais informações:

Segurança para buckets do Cloud Storage

Se você usa o Cloud Storage para hospedar os backups dos dados e volumes do registro, use o TLS (HTTPS) ao enviar dados das VMs para o Cloud Storage para proteger os dados em trânsito.

Embora o Cloud Storage criptografe automaticamente os dados em repouso, é possível especificar suas próprias chaves de criptografia se você tiver seu próprio sistema de gerenciamento de chaves.

Limites de notificação por e-mail

Para ajudar a proteger seus sistemas e os do Google contra abuso, o Google Cloud impõe limitações para o envio de e-mails do Compute Engine. Isso tem implicações para a transação SCOT nos sistemas SAP NetWeaver ABAP, porque requer uma configuração específica em comparação com sistemas locais.

Para mais informações, incluindo informações sobre como configurar o SCOT, consulte Como enviar e-mails de uma instância.

Para mais informações sobre recursos de segurança para seu ambiente SAP no Google Cloud, consulte:

Confiabilidade

Esta seção fornece informações sobre aspectos relacionados à confiabilidade para executar o SAP S/4HANA no Google Cloud.

Alta disponibilidade e recuperação de desastres

Alta disponibilidade (HA, na sigla em inglês) e recuperação de desastres (DR, na sigla em inglês) são conjuntos de técnicas, práticas de engenharia e princípios de design que permitem que os negócios continuem em caso de falha. Essas abordagens funcionam porque eliminam pontos únicos de falha e permitem retomar as operações rapidamente após o sistema ou o componente ficarem indisponíveis, com o mínimo de interrupção nos negócios. A recuperação de falhas é o processo de recuperar e retomar as operações após uma interrupção causada por uma falha de componente.

Por exemplo, estas são algumas ferramentas de alta disponibilidade e DR que podem ser usadas:

Confira mais detalhes sobre algumas dessas ferramentas:

  • Cluster Linux entre zonas: configurar o cluster Linux em zonas protege contra falhas de componentes em uma determinada região.

    Na camada de aplicativos SAP NetWeaver, é possível implantar um cluster do Linux em zonas para reduzir o impacto de uma falha no ASCS e torná-lo altamente disponível em ambos os nós em diferentes zonas. Em seguida, o cluster do Linux move o ASCS para o nó de espera caso o nó principal tenha algum problema ou que a manutenção esteja sendo realizada. Além disso, é possível usar um servidor de replicação de enfileiramento para replicar o conteúdo da tabela de enfileiramento. Dessa maneira, ele mantém esse conteúdo no nó de espera caso o processo seja promovido de principal para em modo de espera.

    Na camada de banco de dados SAP HANA, é possível implantar um cluster Linux em zonas usando uma configuração ativa/passiva ou uma configuração ativa/ativa. Em ambos os casos, você começa configurando duas instâncias do Compute Engine em zonas separadas, cada uma com seu próprio banco de dados SAP HANA.

    • Configuração ativa/passiva: configure uma instância como o nó principal do cluster (ativo) e a outra como o nó secundário (passivo). Use o SAP HANA System Replication (SR) para configurar o nó secundário para assumir como principal se o principal falhar. Para mais informações sobre como configurar e ajustar o HANA SR, consulte Replicação do sistema HANA.
    • Configuração ativa/ativa (habilitada para leitura): configure as duas instâncias como ativas, mas o nó secundário como somente leitura. Essa configuração é baseada na repetição contínua do registro. O IP virtual (VIP) está configurado para indicar o nó de leitura/gravação atual. Para mais informações, consulte Ativo/Ativo (ativado para leitura).

    Além disso, é possível usar a replicação do sistema SAP HANA como uma solução de recuperação de desastres. O banco de dados primário replica o conteúdo dele para o banco de dados em espera, que pode ser usado caso o primário fique off-line, permitindo que o sistema SAP continue funcionando até que o serviço no banco de dados primário seja restaurado. A promoção do nó secundário nesse caso não acontece automaticamente. isso precisa ser feito manualmente. Também é possível combinar alta disponibilidade e DR no lado do SAP HANA para aumentar a resiliência e a disponibilidade. Veja mais informações em:

  • Migração em tempo real: o Compute Engine oferece a migração em tempo real para manter as instâncias de VM em execução mesmo quando ocorre um evento no sistema host, como uma atualização de software ou hardware. Nessa situação, o Compute Engine executa uma migração em tempo real da instância em execução para outro host na mesma zona, em vez de exigir que a instância em execução seja reinicializada. O mecanismo replica o estado da VM da instância original. Portanto, quando a nova instância aparecer, ela já terá a memória da instância original pré-carregada.

    No caso raro em que a migração em tempo real não acontece, a máquina virtual com falha é reiniciada automaticamente no novo hardware dentro da mesma zona. Para mais informações, consulte Processo de migração em tempo real durante eventos de manutenção.

Otimização de custos

Esta seção fornece informações sobre licenciamento, descontos e estimativa do tamanho da carga de trabalho.

Licenciamento

Se você é um cliente SAP, pode usar sua licença para implantar o SAP S/4HANA no Google Cloud com um modelo de licença própria (BYOL). O Google Cloud é compatível com o modelo BYOL para casos de uso de produção e não produção. As licenças do sistema operacional estão incluídas nos preços do Compute Engine.

Também é possível trazer sua própria imagem de SO e licenças. Para mais informações, consulte Imagens personalizadas do SO.

Descontos

Com os modelos de preços de pagamento por uso do Google Cloud, você paga apenas pelos serviços que usa. Você não precisa se comprometer com um tamanho ou serviço específico. é possível alterar ou interromper o uso conforme necessário. Para cargas de trabalho previsíveis, o Compute Engine fornece descontos por uso contínuo (CUDs) que ajudam a reduzir o custo da infraestrutura ao se comprometer com um contrato em retorno para preços de uso de VM com grandes descontos.

O Google Cloud oferece esses descontos em troca da compra de contratos de uso contínuo, também conhecidos como compromissos. Ao fechar esse contrato, você se compromete com o uso de uma quantia mínima de recursos ou um valor de gasto mínimo por um período especificado, de um ou três anos. Esses descontos ajudam a reduzir a fatura mensal dos recursos usados pelo sistema SAP S/4HANA. Para mais informações, consulte Descontos por uso contínuo (CUDs).

Estimativas de tamanho

Os recursos a seguir fornecem informações sobre como realizar estimativas de tamanho para seus sistemas SAP antes da migração para o Google Cloud:

Eficiência operacional

Esta seção fornece informações sobre como otimizar a eficiência operacional do SAP S/4HANA no Google Cloud.

Backup e recuperação

Crie backups do servidor de aplicativos e do banco de dados regularmente para que você possa se recuperar em caso de falha do sistema, corrupção de dados ou qualquer outro problema.

Você tem várias opções para fazer backup dos dados do SAP HANA no Google Cloud, incluindo as seguintes:

Fazer backup no Cloud Storage

A partir da versão 3.0, o Agente para SAP do Google Cloud oferece suporte ao recurso Backint, que permite que o SAP HANA faça backup e recupere backups do banco de dados diretamente do Cloud Storage. Esse novo recurso está disponível para instâncias do SAP HANA em execução em instâncias de VM do Compute Engine, servidores da Solução Bare Metal, servidores locais ou em outras plataformas de nuvem para que você possa fazer backup diretamente, e se recuperar, do Cloud Storage sem precisar de armazenamento em disco permanente para os backups. Para mais informações, consulte o Guia de operações do SAP HANA.

Para informações sobre a certificação SAP desse recurso do agente, consulte a nota SAP 2031547: visão geral de ferramentas de backup de terceiros certificadas pela SAP e processo de suporte associado.

O diagrama a seguir mostra o fluxo de backups quando você usa o recurso Backint do agente do Google Cloud para SAP:

Diagrama mostrando como fazer o backup de dados do SAP HANA para o Cloud Storage usando o agente para SAP do Google Cloud.

Fazer backup em discos

Use a função nativa de backup e recuperação do SAP HANA com disco permanente do Compute Engine e use um intervalo do Cloud Storage para armazenamento de backups a longo prazo.

Quando está funcionando normalmente, o SAP HANA salva automaticamente no disco os dados da memória, em pontos regulares de salvamento. Além disso, todas as alterações de dados são capturadas nas entradas de redo logs. Uma entrada de redo log é gravada no disco após cada transação de banco de dados confirmada.

A partir do SAP HANA 2.0 e versões posteriores, use o cockpit do SAP HANA para criar backups do SAP HANA.

O diagrama a seguir mostra o fluxo do recurso de backup para SAP HANA:

Diagrama mostrando como fazer backup de dados do SAP HANA para disco de armazenamento permanente.

Fazer backup de discos usando snapshots

Outra opção que pode ser adicionada à sua estratégia de backup são os instantâneos de discos inteiros feitos por meio do recurso de snapshot de disco do Compute Engine. Por exemplo, é possível tirar snapshots programados do disco que hospeda o diretório /hanabackup para uso em cenários de recuperação de desastres. Também é possível usar snapshots de disco para fazer backup e recuperar seu volume de dados do SAP HANA. Para garantir a consistência do aplicativo, tire instantâneos quando o volume de destino não estiver sendo alterado. Os instantâneos ocorrem no nível de bloco.

Após o primeiro snapshot, cada snapshot subsequente é incremental e armazena apenas alterações incrementais em blocos, conforme mostrado no diagrama a seguir.

Ao usar a versão 3.0 ou posterior do agente para SAP do Google Cloud, é possível criar backups e executar a recuperação para o SAP HANA usando o recurso de snapshot de disco do agente. Para mais informações, consulte Backup e recuperação do SAP HANA usando snapshots de disco.

Diagrama mostrando como fazer backup de dados do SAP HANA usando snapshots de disco.

Recuperação

As ferramentas de recuperação do SAP HANA podem ser recuperadas para o último momento ou para um ponto específico. Essas ferramentas podem ser usadas para restaurar para um novo sistema ou criar uma cópia do banco de dados. Ao contrário de backups, que podem ser executados enquanto o banco de dados está em operação, as ferramentas de recuperação só podem ser usadas enquanto o banco de dados estiver desligado. Escolha uma opção apropriada entre:

  • Restaurar para o estado mais recente, usando qualquer um dos recursos a seguir:
    • Backup completo ou snapshot
    • Backup de registros
    • Entradas de redo log que ainda estão disponíveis
  • Restaurar para um ponto no passado.
  • Restaurar para um backup completo específico.

Monitoramento

Para monitorar e oferecer suporte a cargas de trabalho SAP em execução em instâncias de VM do Compute Engine e servidores da Solução Bare Metal, o Google Cloud fornece o Agente para SAP.

Conforme exigido pela SAP, para receber suporte da SAP e permitir que a SAP atenda aos contratos de nível de serviço (SLAs), instale o agente do Google Cloud para SAP em todas as instâncias de VM do Compute Engine e servidores da Solução Bare Metal que executam qualquer sistema SAP. Para mais informações sobre os pré-requisitos de suporte, consulte a Nota SAP 2456406: SAP no Google Cloud Platform: pré-requisitos de suporte.

Além da coleta obrigatória de métricas do agente SAP Host no Linux, o agente do Google Cloud para SAP inclui recursos opcionais, como coleta de métricas de monitoramento de processos e métricas de avaliação do Gerenciador de cargas de trabalho. Esses recursos ativam produtos e serviços como o gerenciamento de cargas de trabalho para as cargas de trabalho SAP.

Otimização de desempenho

Nesta seção, apresentamos informações sobre como otimizar o desempenho das cargas de trabalho SAP S/4HANA por meio de dimensionamento e configuração de rede.

Dimensionamento

Há várias opções de dimensionamento disponíveis baseadas no tipo de implementação. Para implementações totalmente novas, recomendamos usar a ferramenta SAP Quick Sizer. Para informações detalhadas, consulte a página Dimensionamento da SAP. A SAP também fornece guias de soluções e ferramentas específicas para migração de soluções no local atuais para o Google Cloud. Por exemplo, consulte o Diretório de hardware certificado e compatível do SAP HANA e a nota SAP Nota SAP 2456432 - Aplicativos SAP no Google Cloud: produtos compatíveis e tipos de máquina do Google Cloud. . O SAP e o Google Cloud usam unidades diferentes para medir IOPS (operações de entrada/saída por segundo). Consulte seu parceiro de integração de sistemas (SI, na sigla em inglês) para converter os requisitos de dimensionamento do SAP em uma infraestrutura do Google Cloud de tamanho apropriado.

Antes de migrar sistemas do SAP ECC para o S/4HANA, a SAP recomenda que você execute o relatório /SDF/HDB_SIZING, conforme descrito na nota SAP 1872170 - ABAP no relatório de dimensionamento do HANA (S/4HANA, Suite em HANA etc.). Esse relatório de dimensionamento analisa as necessidades atuais de memória e processamento do sistema de origem e fornece informações sobre os requisitos para migrar para o S/4HANA.

Configuração de rede

Os recursos de rede da VM do Compute Engine são determinados pela respectiva família de máquina, e não pela interface de rede (NIC, na sigla em inglês) ou endereço IP.

Com base no tipo de máquina, a instância de VM pode ter capacidade de rede de 2 a 32 Gbps. Alguns tipos de máquina também oferecem suporte a capacidades de processamento de até 100 Gbps, o que requer o uso do tipo de interface NIC virtual do Google (gVNIC) com uma configuração de rede de nível 1. A capacidade de atingir essas taxas de capacidade depende ainda da direção do tráfego e do tipo de endereço IP de destino.

As interfaces de rede da VM do Compute Engine são apoiadas por uma infraestrutura de rede redundante e resiliente usando componentes de rede físicos e definidos por software. Essas interfaces herdam a redundância e a resiliência da plataforma subjacente. É possível usar várias NICs virtuais para separar o tráfego, mas isso não oferece mais resiliência ou benefícios de desempenho.

Uma única NIC fornece o desempenho necessário para implantações do SAP HANA no Compute Engine. Seu caso de uso específico, requisitos de segurança ou preferências também podem exigir outras interfaces para separar tráfego, como tráfego da Internet, tráfego interno de replicação do sistema SAP HANA ou outros fluxos que podem se beneficiar de regras específicas da política de rede. Recomendamos o uso de criptografia de tráfego oferecida pelo aplicativo e segurança do acesso à rede seguindo uma política de firewall de privilégio mínimo para restringir o acesso.

Considere a necessidade de separar o tráfego antecipadamente como parte do design de rede e aloque outras NICs ao implantar VMs. É necessário anexar cada interface de rede a uma rede VPC diferente. A escolha para o número de interfaces de rede depende do nível de isolamento necessário, com até oito interfaces permitidas para VMs com oito vCPUs ou mais.

Por exemplo, é possível definir uma rede VPC para seus clientes de aplicativos SQL do SAP HANA, como servidores de aplicativos SAP NetWeaver e aplicativos personalizados, e uma rede VPC separada para tráfego entre servidores, como SAP Replicação do sistema HANA. O excesso de segmentos pode complicar o gerenciamento e a solução de problemas de rede. Se você mudar de ideia depois, poderá usar imagens de máquina do Compute Engine para recriar a instância de VM, mantendo todas as configurações, metadados e dados associados.

Confira mais informações:

Implantação

Esta seção fornece informações relacionadas à implantação do SAP S/4HANA no Google Cloud.

Notas SAP importantes antes da implantação

Antes de começar a implantar um sistema SAP S/4HANA no Google Cloud, leia as seguintes notas SAP. Além disso, antes de iniciar qualquer implementação do SAP, verifique o SAP Marketplace para ver os guias e as notas de instalação do produto atualizados.

Automação de implantação

Para instalar o SAP S/4HANA no Google Cloud, use as seguintes opções de implantação:

  • Para automatizar a implantação de um sistema distribuído ou distribuído com alta disponibilidade (HA, na sigla em inglês), use a ferramenta de automação de implantação guiada no Gerenciador de cargas de trabalho. Essa ferramenta permite configurar e implantar cargas de trabalho SAP compatíveis diretamente do console do Google Cloud ou gerar e fazer o download dos códigos equivalentes do Terraform e do Ansible. Para mais informações, consulte Sobre a automação de implantação guiada.
  • Para automatizar a implantação de um sistema SAP HANA centralizado ou distribuído, use as configurações do Terraform fornecidas pelo Google Cloud. Para mais informações, consulte o guia de implantação do seu cenário do SAP HANA.

A seguir