Arquitetura de referência: SAP Business Suite no SAP ASE ou IBM Db2 no Google Cloud

Esta arquitetura de referência é destinada a pessoas que estão avaliando o Google Cloud como uma plataforma para implantar aplicativos do SAP Business Suite no SAP ASE ou IBM Db2. 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 certificada pela SAP, econômica, confiável, segura e de alto desempenho para executar o SAP Business Suite no SAP ASE ou IBM Db2. Para 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 visão geral de alto nível de três modelos de implantação comuns para o SAP Business Suite: centralizado, distribuído e distribuído com alta disponibilidade.

Implantação centralizada

Em uma implantação centralizada, é possível instalar o SAP Business Suite e o banco de dados SAP ASE ou IBM Db2 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.

As seções a seguir mostram arquiteturas de referência para o SAP Business Suite no SAP ASE e IBM Db2 em implantações centralizadas.

Implantação centralizada do SAP Business Suite com o SAP ASE

O diagrama a seguir mostra uma arquitetura de referência para uma implantação centralizada do SAP Business Suite no SAP ASE. O SAP ASCS, PAS, WD e o banco de dados estão instalados na mesma instância de VM.

Diagrama da arquitetura do SAP Business Suite no SAP ASE no Google Cloud em uma implantação centralizada.

Implantação centralizada do SAP Business Suite com o IBM Db2

O diagrama a seguir mostra uma arquitetura de referência para uma implantação centralizada do SAP Business Suite no IBM Db2. O SAP ASCS, PAS, WD e o banco de dados estão instalados na mesma instância de VM.

Diagrama da arquitetura do SAP Business Suite no IBM Db2 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.

Implantação distribuída do SAP Business Suite com o SAP ASE

O diagrama a seguir mostra uma arquitetura de referência para o SAP Business Suite no SAP ASE em uma implantação distribuída. O SAP ASCS, PAS, WD e ASE estão todos instalados em instâncias diferentes.

Diagrama da arquitetura do SAP Business Suite no SAP ASE no Google Cloud em uma implantação distribuída.

Implantação distribuída do SAP Business Suite com o IBM Db2

O diagrama a seguir mostra uma arquitetura de referência para o SAP Business Suite no IBM Db2 em uma implantação distribuída. SAP ASCS, PAS, WD e IBM Db2 estão todos instalados em instâncias diferentes.

Diagrama de arquitetura do SAP Business Suite no IBM Db2 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 Linux entre zonas usando uma configuração ativa/passiva. Em ambos os 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 SAP ASE ou IBM Db2.

  • Implantação distribuída do SAP ASE com alta disponibilidade: é possível implantar um banco de dados SAP ASE com alta disponibilidade e tolerante a desastres (HADR, na sigla em inglês) no Google Cloud que tenha suporte do SAP. Para mais informações, consulte o Guia de planejamento do SAP ASE.

    O diagrama a seguir ilustra uma arquitetura do SAP Business Suite no SAP ASE que usa um cluster Linux para conseguir alta disponibilidade no aplicativo e no banco de dados:

    Diagrama da arquitetura do SAP Business Suite no SAP ASE no Google Cloud em uma implantação distribuída de alta disponibilidade.

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

    • Três VMs de host, duas com uma instância de banco de dados e uma com o Fault Manager.
    • Replicação síncrona do SAP ASE.
    • O gerenciador de recursos do cluster de alta disponibilidade do Pacemaker
    • Um mecanismo de isolamento que usa o Fault Manager para garantir o isolamento dos recursos com falha ou que estão com falha.
    • Reinicialização automática da instância com falha como nova instância secundária e novo registro automático para replicação do SAP ASE.

  • Implantação distribuída do IBM Db2 com alta disponibilidade: é possível implantar um banco de dados IBM Db2 altamente disponível e tolerante a desastres (HADR) no Google Cloud com suporte da SAP. Para mais informações, consulte o Guia de planejamento do IBM Db2 para SAP.

    É possível configurar um cluster HADR Pacemaker de dois hosts usando a solução de clustering fornecida pela IBM para o Db2. Para mais informações, consulte o PDF da SAP Guia de administração de banco de dados para SAP no IBM Db2 para Linux, Unix e Windows.

    O diagrama a seguir ilustra uma arquitetura do SAP Business Suite no IBM Db2 que usa um cluster Linux para conseguir alta disponibilidade no lado do aplicativo e do banco de dados.

    Diagrama da arquitetura do SAP Business Suite no IBM Db2 no Google Cloud em uma implantação distribuída de alta disponibilidade.

    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 IBM Db2.
    • Replicação síncrona do IBM Db2 HADR.
    • Um gerenciador de recursos de cluster de alta disponibilidade do Linux, como o Pacemaker.
    • Um mecanismo de isolamento que isola o nó com falha.
    • Um balanceador de carga de aplicativo interno para rotear o VIP para o nó ativo.
    • Reinicialização automática da instância com falha como nova instância secundária e novo registro automático para HADR do IBM Db2.

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 Business Suite alta disponibilidade em casos de algo acontecer com qualquer instância do ASCS e do ERS.

Dependendo da versão do SAP NetWeaver usada com o sistema SAP Business Suite, o Enqueue Server e o Enqueue Replication Server / Enqueue Replicator são executados em uma versão diferente:

O diagrama a seguir mostra um sistema SAP Business Suite usando um cluster do Pacemaker para limitar os pontos únicos de falha do Message Server e do Enqueue Server:

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 distribuído do SAP Business Suite no SAP ASE ou IBM Db2, 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 Business Suite no SAP ASE ou IBM Db2 é formado pelos seguintes componentes técnicos:

  • Banco de dados SAP ASE ou IBM Db2
  • Fault Manager, somente no SAP ASE
    • Ele tem seu próprio servidor host e monitora os servidores principal e de espera. O Gerenciador de falhas garante alta disponibilidade do SAP ASE iniciando o failover automático. Ele monitora os seguintes componentes: agente de gerenciamento de replicação, servidor de replicação, aplicativos, bancos de dados e sistema operacional. Ele também permite que você verifique a integridade do banco de dados e reinicie o banco de dados, se necessário.
  • 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 independente ou como parte do sistema SAP Business Suite.
    • 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 independente ou como parte do sistema SAP Business Suite.
    • 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 Business Suite no SAP ASE ou IBM Db2:

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 Business Suite 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 da camada de banco de dados SAP ASE ou IBM Db2 (primário e secundário).

Há várias maneiras de criar sua rede e conectar o sistema do SAP Business Suite à 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 Business Suite em uma ou 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: implantar o SAP Business Suite 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 Business Suite 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 Business Suite no SAP ASE ou IBM Db2 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 ASE ou IBM Db2
  • 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 Business Suite no SAP ASE ou IBM Db2, recomendamos que você estude esses pontos únicos de falha e se 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 do SAP Business Suite no SAP ASE ou IBM Db2, é 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 Business Suite 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 disponíveis para planejar e implantar seu sistema SAP Business Suite no SAP ASE ou IBM Db2 no Google Cloud.

Tipos de máquinas compatíveis com instâncias do SAP Business Suite

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 Business Suite com SAP ASE ou IBM Db2. Para mais informações sobre o dimensionamento no Google Cloud e os tipos de máquina com suporte, consulte os seguintes documentos:

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 o SAP Business Suite

Confira a seguir as opções de armazenamento oferecidas pelo Google Cloud que são certificadas pela SAP para uso com o SAP Business Suite e o SAP ASE ou IBM Db2.

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. 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. 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 Business Suite 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 ASE ou IBM Db2. 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 ASE ou IBM Db2. 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 ASE

As tabelas a seguir descrevem as estruturas de diretório do sistema SAP Business Suite no banco de dados SAP ASE no Google Cloud.

  • Estrutura de diretório Linux recomendada para uma instância genérica do SAP ABAP:

    Diretório do Linux 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.

  • Confira a seguir a estrutura de diretórios do Linux recomendada para o SAP Business Suite no SAP ASE no Google Cloud.

    Todos os arquivos de dados e de registro do banco de dados do SAP ASE precisam estar localizados no diretório /sybase/SAP_SID. Substitua SAP_SID pelo identificador do sistema SAP (SID), que é o número da instância do SAP que você usou durante a instalação do banco de dados.

    Diretório do SAP ASE Opção de armazenamento recomendada no Google Cloud
    /usr/sap Disco permanente equilibrado
    /sybase/SAP_SID/sapdata1 Disco permanente ou hiperdisco baseado em SSD
    /sybase/SAP_SID/log_dir Disco permanente ou hiperdisco baseado em SSD
    /sybase/SAP_SID/saptemp Disco permanente equilibrado
    /sybase/SAP_SID/sapdiag Disco permanente equilibrado

    Para informações da SAP sobre como executar o SAP ASE, consulte Aplicativos SAP no SAP Adaptive Server Enterprise: práticas recomendadas para migração e execução.

  • Confira a seguir a estrutura de diretório do Windows recomendada para o SAP Business Suite no SAP ASE no Google Cloud. A estrutura de diretórios a seguir se aplica à instalação do servidor central.

    Drive Descrição Opção de armazenamento recomendada no Google Cloud
    C:\ Inicialização Disco permanente equilibrado
    D:\ Binários de banco de dados Disco permanente equilibrado
    E:\ Arquivos de dados do banco de dados Disco permanente ou hiperdisco baseado em SSD
    L:\ Arquivos de registro do banco de dados Disco permanente ou hiperdisco baseado em SSD
    P:\ Arquivo de paginação Disco permanente equilibrado
    S:\ os diretórios /usr/sap e /sapmnt Disco permanente equilibrado
    T:\ os diretórios temp e saptemp Disco permanente equilibrado
    X:\ Backup Disco permanente equilibrado

    Para informações da SAP sobre como executar o SAP ASE, consulte Aplicativos SAP no SAP Adaptive Server Enterprise: práticas recomendadas para migração e execução.

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

As tabelas a seguir descrevem as estruturas de diretório do sistema SAP Business Suite no banco de dados IBM Db2 no Google Cloud.

  • Estrutura de diretório Linux recomendada para SAP Business Suite no IBM Db2 no Google Cloud:

    Estrutura de diretório do IBM Db2 Opção de armazenamento recomendada no Google Cloud
    /sapmnt Disco permanente equilibrado
    /usr/sap Disco permanente equilibrado
    /db2/DB_SID Disco permanente equilibrado
    /db2/DB_SID/db2dump Disco permanente equilibrado
    /db2/DB_SID/sapdata1 Disco permanente ou hiperdisco baseado em SSD
    /db2/DB_SID/log_dir Disco permanente ou hiperdisco baseado em SSD
    /db2/DB_SID/saptmp1 Disco permanente equilibrado
    /db2backup Disco permanente equilibrado

    Para informações da SAP sobre como executar sistemas SAP no IBM Db2, consulte SAP no IBM Db2 para Linux, UNIX e Windows.

  • Confira a seguir a estrutura de diretório recomendada do Windows para o SAP Business Suite no IBM Db2 no Google Cloud. Essa estrutura de diretórios se aplica à instalação do servidor central.

    Drive Descrição Opção de armazenamento recomendada no Google Cloud
    C:\ Inicialização Disco permanente equilibrado
    D:\ Binários de banco de dados Disco permanente equilibrado
    E:\ Arquivos de dados do banco de dados Disco permanente ou hiperdisco baseado em SSD
    L:\ Arquivos de registro do banco de dados Disco permanente ou hiperdisco baseado em SSD
    P:\ Arquivo de paginação Disco permanente equilibrado
    S:\ os diretórios /usr/sap e /sapmnt Disco permanente equilibrado
    T:\ os diretórios temp e saptemp Disco permanente equilibrado
    X:\ Backup Disco permanente equilibrado

    Para mais informações sobre as estruturas de diretórios, consulte o Guia de planejamento do SAP NetWeaver. Para informações sobre como calcular o tamanho do arquivo de paginação, consulte a Nota SAP 1518419: arquivo de paginação e memória virtual exigidos pelo sistema SAP (em inglês).

Suporte ao SO para SAP Business Suite

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ê encontra mais informações sobre versões específicas do SO e a compatibilidade com o SAP Business Suite e o SAP ASE ou IBM Db2 nos seguintes guias:

Arquitetura de implantação do SAP ASE

O SAP ASE é um componente essencial de qualquer sistema SAP Business Suite porque funciona como um dos possíveis tipos de banco de dados do sistema.

O diagrama a seguir mostra uma arquitetura de implantação do SAP ASE 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 /sybasebackup. Essa ativação será igual ou maior que a ativação de dados.

Diagrama de arquitetura para a implantação do SAP ASE no Google Cloud.

Arquitetura de implantação do IBM Db2

O IBM Db2 é um componente essencial de qualquer sistema SAP Business Suite porque atua como um dos possíveis tipos de banco de dados do sistema.

O diagrama a seguir mostra uma arquitetura de implantação do IBM Db2 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 /db2backup. Essa ativação será igual ou maior que a ativação de dados.

Diagrama de arquitetura para a implantação do IBM Db2 no Google Cloud.

Arquitetura de implantação do SAP Business Suite

Como mencionado na seção Arquitetura, há várias arquiteturas de implantação que podem ser usadas para implantar o SAP Business Suite no SAP ASE ou IBM Db2 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 Business Suite em execução em uma VM do Compute Engine:

Arquitetura de duas camadas para o SAP Business Suite no SAP ASE ou IBM Db2 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 Business Suite de alta disponibilidade. O diagrama a seguir mostra alguns detalhes de uma arquitetura de três camadas para o SAP Business Suite em execução nas VMs do Compute Engine:

Arquitetura de três camadas para o SAP Business Suite no SAP ASE ou IBM Db2 em uma VM do Compute Engine no Google Cloud.

Nessa arquitetura, o sistema SAP Business Suite 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 Business Suite no SAP ASE ou IBM Db2 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 Business Suite no SAP ASE ou IBM Db2 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:

Alta disponibilidade do SAP ASE

É possível ter alta disponibilidade para seu banco de dados SAP ASE no Google Cloud configurando a replicação síncrona entre os servidores principal e de espera, permitindo que os dois servidores estejam sempre sincronizados e sem perda de dados. A opção sempre ativada do SAP ASE, que é um sistema de alta disponibilidade e recuperação de desastres (HADR, na sigla em inglês), é compatível com o Google Cloud. Para mais informações, consulte o Guia de planejamento do SAP ASE.

As instâncias de VM que hospedam os servidores primário e reserva precisam ter os seguintes componentes:

  • SAP ASE
  • SAP Host Agent, que monitora o uso de CPU, memória e outros recursos do servidor.
  • Agente de gerenciamento de replicação (RMA)
  • SAP ASE Cockpit, que executa atividades de banco de dados
  • Gerenciador de falhas, que tem seu próprio servidor host. Ele monitora os servidores principais e de espera do SAP ASE. O Gerenciador de falhas garante alta disponibilidade do SAP ASE iniciando o failover automático. Ele monitora os seguintes componentes: RMA, servidor de replicação, aplicativos, bancos de dados e sistema operacional. Ele também permite verificar a integridade do banco de dados e reiniciá-lo, se necessário.

Para melhorar a disponibilidade do sistema, um cluster SAP ASE permite que as cargas de trabalho sejam movidas para o nó secundário, monitorando a falha do nó principal. O diagrama a seguir mostra uma arquitetura de referência de alto nível demonstrando como os componentes ASE do SAP descritos podem ser instalados no Google Cloud.

Arquitetura para um sistema de alta disponibilidade do SAP ASE no Google Cloud

Recuperação de desastres do SAP ASE

O sistema HADR do SAP ASE com sistema de nó de recuperação de desastres (DR) consiste em três servidores SAP ASE:

  • Servidor principal: processa todas as transações.
  • Nó de espera: esse servidor funciona como um standby aquecido para o servidor principal e contém cópias de bancos de dados designados do servidor principal.
  • Nó de DR: esse servidor está geograficamente distante e faz backup de bancos de dados designados do servidor principal.

O diagrama a seguir mostra o fluxo da recuperação de desastres do SAP ASE:

Arquitetura para um sistema SAP ASE no Google Cloud com recuperação de desastres

Alta disponibilidade do IBM Db2 e recuperação de desastres

É possível alcançar alta disponibilidade e recuperação de desastres (HADR, na sigla em inglês) para o banco de dados IBM Db2 da seguinte maneira:

  • É necessário implantar duas instâncias separadas do banco de dados IBM Db2: uma principal e outra de espera. Você precisa manter a sincronização entre eles. Se a instância principal falhar, a instância de espera vai assumir a carga de trabalho.

    A instância principal processa as conexões e transações do cliente e as registra em registros. Esses registros são enviados pelo TCP/IP para o servidor de espera, que os usa para atualizar o banco de dados, permanecendo sincronizado com a instância principal.

  • Como o HADR não tem detecção e automação de falhas, você também precisa implantar o Pacemaker. O Pacemaker monitora as duas instâncias. Se a instância principal falhar, o Pacemaker aciona a transferência de HADR pela instância de espera, garantindo que o endereço IP flutuante seja atribuído à nova instância principal.

    O Pacemaker lida com o gerenciamento de cluster, e um VIP é usado com o balanceador de carga de aplicativo interno para rotear solicitações de aplicativo para a instância principal.

Arquitetura de um sistema IBM Db2 no Google Cloud com alta disponibilidade e recuperação de desastres

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

Para informações sobre a licença do SAP ASE no Google Cloud, consulte a seção "Licenças do SAP" no Guia de planejamento do SAP ASE.

Para implantar o IBM Db2 para SAP no Google Cloud, você precisa trazer sua própria licença. É possível conseguir uma licença na SAP ou na IBM. Para mais informações sobre licenciamento e suporte, consulte a nota SAP 1168456 - DB6: Processo de suporte e datas de fim de suporte ao IBM Db2 para LUW.

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 do SAP Business Suite. 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 Business Suite no SAP ASE ou IBM Db2 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 ASE ou do IBM Db2 no Google Cloud, incluindo as seguintes:

Fazer backup e recuperar o SAP ASE

É possível usar as seguintes opções para fazer backup e recuperar um banco de dados IBM Db2 no Google Cloud:

  • Backup e recuperação usando discos: é possível usar os mecanismos flexíveis de backup e recuperação do SAP ASE em combinação com os tipos de Persistent Disk e hiperdisco fornecidos pelo Compute Engine. Para armazenar backups por um período mais longo, use o Cloud Storage.

    O diagrama a seguir mostra como os discos e o Cloud Storage são usados para armazenar backups de um banco de dados SAP ASE:

    Diagrama mostrando como fazer backup de dados do SAP ASE em discos e no Cloud Storage

  • Backup e recuperação usando snapshots de disco: outra opção que pode ser adicionada à sua estratégia de backup é fazer snapshots de discos inteiros usando o recurso de snapshot de disco do Compute Engine. Por exemplo, é possível tirar snapshots programados do disco que hospeda o diretório /sybasebackup 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 ASE. Para garantir a consistência do aplicativo, tire instantâneos quando o volume de destino não estiver sendo alterado. Os snapshots ocorrem no nível do bloco.

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

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

Fazer backup de um banco de dados IBM Db2

É possível fazer backup de um banco de dados IBM Db2 usando uma das seguintes opções:

  • Use os modos on-line e off-line fornecidos pela IBM:
    • Modo on-line: nesse modo, os usuários podem continuar trabalhando enquanto o backup do banco de dados está sendo criado.
    • Modo off-line: nesse modo, o banco de dados é totalmente encerrado, ficando indisponível para os usuários enquanto o backup está sendo criado.

  • Fazer backup e recuperar o banco de dados do IBM Db2 usando snapshots de disco: outra opção que pode ser adicionada à sua estratégia de backup é fazer snapshots de discos inteiros usando o recurso de snapshot de disco do Compute Engine. Por exemplo, é possível tirar snapshots programados do disco que hospeda o diretório /db2backup 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 IBM Db2. Para garantir a consistência do aplicativo, tire instantâneos quando o volume de destino não estiver sendo alterado. Os snapshots ocorrem no nível do bloco.

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

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

O processo de criação do backup do banco de dados depende de quantas partições seu banco de dados IBM Db2 tem:

  • Banco de dados de partição única: nesta configuração, é possível criar um backup seguindo estas etapas:

    1. Como usuário db2DB_SID, faça login no servidor de banco de dados.

    2. Execute este comando:

      db2 backup db DB_SID

      Substitua DB_SID pelo identificador do sistema de banco de dados (SID).

  • Banco de dados com várias partições: nesta configuração, é possível criar um backup seguindo estas etapas:

    1. Como usuário db2DB_SID, faça login no servidor de banco de dados.

    2. Execute este comando:

      db2 "backup db DB_SID on ALL DBPARTITIONNUMS..."

      Substitua DB_SID pelo identificador do sistema de banco de dados (SID).

    Também é possível usar a ferramenta DBA Cockpit fornecida pela IBM para criar um backup do banco de dados. Para mais informações sobre como fazer backup de um banco de dados IBM Db2, consulte o documento da SAP Como fazer backup de um banco de dados.

Recuperar um banco de dados IBM Db2

É possível recuperar o banco de dados IBM Db2 de um backup bem-sucedido. A recuperação do banco de dados depende da acessibilidade a um arquivo de histórico atualizado, porque todas as informações sobre imagens de backup e arquivos de registro são acessadas a partir dele.

  • Para recuperar o banco de dados IBM Db2 de um backup, siga estas etapas:

    1. Como usuário db2DB_SID ou SAP_SIDadm, faça login no servidor de banco de dados.

    2. Execute este comando:

      db2 RECOVER DB DB_SID

      Substitua DB_SID pelo identificador do sistema de banco de dados (SID).

  • Para recuperar o banco de dados IBM Db2 para um ponto específico no tempo, siga estas etapas:

    1. Como usuário db2DB_SID ou SAP_SIDadm, faça login no servidor de banco de dados.

    2. Execute este comando:

      db2 RECOVER DB DB_SID to LOCAL_TIME_ON_DB_SERVER

      Substitua:

      • DB_SID: o identificador do sistema de banco de dados (SID)
      • LOCAL_TIME_ON_DB_SERVER: a hora local no servidor do banco de dados

    Para mais informações sobre como recuperar um banco de dados do IBM Db2, consulte o documento SAP Recuperação de banco de dados usando o comando RECOVER.

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 de cargas de trabalho do SAP Business Suite 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 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.

Para dimensionar um banco de dados do SAP ASE, consulte o documento do SAP Dimensionamento do SAP ASE.

Para dimensionar um banco de dados IBM Db2, consulte o comparativo de dimensionamento da SAP.

Para informações sobre os requisitos de hardware para executar o SAP ASE ou o IBM Db2 com diferentes sistemas operacionais e versões do SAP NetWeaver, consulte o documento da SAP Guide Finder para SAP NetWeaver e ABAP Platform.

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 oferece o desempenho necessário para implantações do SAP ASE ou do IBM Db2 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 SAP ASE ou IBM Db2 HADR 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.

Veja mais informações em:

Implantação

Esta seção fornece informações relacionadas à implantação do SAP Business Suite no SAP ASE ou IBM Db2 no Google Cloud.

Notas SAP importantes antes da implantação

Antes de começar a implantar um sistema SAP Business Suite no Google Cloud, leia as seguintes notas da 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.

Para mais informações sobre a instalação do SAP ASE ou IBM Db2, consulte:

Automação de implantação

Automatizar a implantação do SAP ASE

Para automatizar a implantação da infraestrutura necessária para executar o SAP ASE e o SAP NetWeaver no Linux no Google Cloud, use as configurações do Terraform fornecidas pelo Google Cloud. Para mais informações, consulte os guias de implantação para seu cenário.

Para informações sobre como planejar a implantação do SAP ASE, consulte:

Automatizar a implantação do IBM Db2

Para automatizar a implantação da infraestrutura necessária para executar o IBM Db2 e o SAP NetWeaver no Linux no Google Cloud, use as configurações do Terraform fornecidas pelo Google Cloud. Para mais informações, consulte os guias de implantação para seu cenário.

Para informações sobre como planejar a implantação do SAP ASE, consulte:

A seguir