Guia de planejamento do SAP MaxDB

Neste guia, fornecemos uma visão geral de como o SAP MaxDB funciona no Google Cloud e fornecemos detalhes que podem ser usados ao planejar a implementação de um novo sistema SAP MaxDB.

Para detalhes sobre como implantar o SAP MaxDB no Google Cloud, consulte:

Para informações da SAP sobre o SAP MaxDB, consulte a biblioteca do SAP MaxDB, disponível no portal de ajuda da SAP (em inglês).

Princípios básicos do Google Cloud

O Google Cloud consiste em muitos serviços e produtos baseados em nuvem. Ao executar produtos SAP no Google Cloud, você usa principalmente os serviços baseados em IaaS oferecidos pelo Compute Engine e pelo Cloud Storage, bem como alguns recursos de toda a plataforma, como as ferramentas.

Consulte a visão geral do Google Cloud Platform para ver conceitos e termos importantes. Por conveniência e para contextualização, há algumas informações repetidas da visão geral neste guia.

Para uma visão geral das considerações que as organizações de escala empresarial devem considerar ao executar no Google Cloud, consulte o Framework da arquitetura do Google Cloud.

Interação com o Google Cloud

O Google Cloud oferece três maneiras principais de interagir com a plataforma e seus recursos na nuvem:

  • O console do Google Cloud, que é uma interface do usuário na Web.
  • A ferramenta de linha de comando gcloud (que fornece um superconjunto das funcionalidades encontradas no console do Google Cloud)
  • As bibliotecas de cliente, que fornecem APIs para acessar serviços e gerenciamento de recursos, além de serem úteis para você criar suas próprias ferramentas)

Serviços do Google Cloud

As implantações da SAP normalmente utilizam alguns ou todos os seguintes serviços do Google Cloud:

Serviço Descrição
Rede VPC Conecta as instâncias de VM entre si e à Internet. Cada instância é membro de uma rede legada com um intervalo de IPs global ou de uma rede de sub-redes recomendada, em que a instância é membro de uma sub-rede que faz parte de uma rede maior. Não é possível que uma rede se estenda a projetos do Google Cloud, mas é possível que um projeto do Google Cloud tenha várias redes.
Compute Engine Cria e gerencia VMs com sua opção de sistema operacional e pilha de software.
Disco permanente e hiperdisco

É possível usar o disco permanente e o hiperdisco do Compute Engine:

  • Estão disponíveis como unidades de disco rígido (HDD, na sigla em inglês) padrão ou unidades de estado sólido (SSD, na sigla em inglês). Para discos permanentes balanceados e discos permanentes SSD, a PD Async Replication fornece replicação assíncrona de dados SAP entre duas regiões do Google Cloud.
  • Os hiperdiscos oferecem opções máximas de IOPS e de capacidade do que os discos permanentes SSD.
Console do Google Cloud 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 no Cloud Storage os backups de bancos de dados SAP 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 permanentes.

O Monitoring coleta métricas, eventos e metadados do Google Cloud para oferecer insights por meio de 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. Controle quem tem capacidade para realizar operações de plano de controle nas VMs, que incluem criação, modificação e exclusão de VMs e discos persistentes, bem como criação e redes.

Preços e cotas

Use a calculadora de preços para estimar os custos de uso. Para mais informações sobre preços, consulte Preços do Compute Engine, Preços do Cloud Storage e Preços de observabilidade do Google Cloud.

Os recursos do Google Cloud estão sujeitos a cotas. Se você planeja usar máquinas com alto uso da CPU ou da memória, talvez seja necessário solicitar cotas extras. Para mais informações, consulte Cotas de recursos do Compute Engine.

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.

Arquitetura de implantação

Uma instalação básica do SAP MaxDB de nó único no Google Cloud é composta pelos seguintes componentes:

  • Uma VM do Compute Engine que executa o banco de dados do SAP MaxDB.

  • Três ou quatro drives de disco permanentes conectados:

    Conteúdo do drive Linux Windows
    Diretório raiz da instância do banco de dados /sapdb/[DBSID] MaxDB (D:)
    Arquivos de dados do banco de dados /sapdb/[DBSID]/sapdata MaxDB Data (E:)
    Registros de transação do banco de dados /sapdb/[DBSID]/saplog MaxDB Log (L:)
    Backups do banco de dados (opcional) /maxdbbackup Backup (X:)

Se quiser, é possível expandir sua instalação para incluir também o seguinte:

  • Diretórios do NetWeaver, incluindo:

    • /usr/sap no Linux ou SAP (S:) no Windows;
    • /sapmnt no Linux ou Pagefile (P:) no Windows

  • Um gateway NAT Um gateway NAT permite que você forneça conectividade com a Internet para suas VMs enquanto nega a conectividade direta com a Internet para essas VMs. Também é possível configurar essa VM como um Bastion Host que permite estabelecer conexões SSH com outras VMs na sub-rede particular. Para mais informações, consulte Gateways NAT e Bastion Hosts.

Casos de uso diferentes podem exigir dispositivos ou bancos de dados extras. Para mais informações, consulte a documentação do MaxDB no portal de ajuda da SAP (em inglês).

Recursos necessários

De muitas maneiras, executar o SAP MaxDB no Google Cloud é semelhante a executá-lo no seu próprio data center. Mas você ainda precisa se preocupar com recursos de computação, armazenamento e rede. Para mais informações, consulte a Nota SAP 2456432 - Aplicativos SAP no Google Cloud: produtos compatíveis e tipos de máquina do Google Cloud .

Configuração de VM

O SAP MaxDB é certificado para execução em todos os tipos de máquina do Compute Engine, inclusive tipos personalizados. No entanto, se você executar o MaxDB na mesma VM que o SAP NetWeaver ou o Application Server Central Services (ASCS), será necessário usar uma VM compatível com o SAP NetWeaver. Para ver uma lista das VMs compatíveis com o SAP NetWeaver, consulte o Guia de planejamento do SAP NetWeaver.

Para informações sobre todos os tipos de máquinas disponíveis no Google Cloud e os respectivos casos de uso, consulte Tipos de máquinas na documentação do Compute Engine.

Configuração de CPU

O número de vCPUs que você seleciona para o MaxDB depende da carga do aplicativo e de seus objetivos de desempenho. É preciso alocar no mínimo duas vCPUs para a instalação do SAP MaxDB. Para conseguir o melhor desempenho, dimensione o número de vCPUs e o tamanho dos discos permanentes até que seus objetivos de desempenho sejam alcançados. Para mais informações da SAP sobre o MaxDB, consulte o portal de ajuda da SAP (em inglês).

Configuração de memória

A memória alocada para o sistema SAP MaxDB depende do seu caso de uso. A quantidade ideal de memória para seu caso de uso depende da complexidade das consultas executadas, do tamanho dos dados, da quantidade de paralelismo usada e do nível de desempenho esperado.

Para mais informações da SAP sobre o MaxDB, consulte o portal de ajuda da SAP (em inglês).

Configuração de armazenamento

Por padrão, cada VM do Compute Engine tem um pequeno disco permanente raiz que contém o sistema operacional. Você provisiona discos extras para os dados do banco de dados, registros e, opcionalmente, backups de banco de dados.

Use um disco permanente de alto desempenho para o volume de registros e, dependendo dos objetivos de desempenho, para o volume de dados.

Para mais informações sobre as opções de discos permanentes do SAP MaxDB, consulte Discos permanentes.

Mais informações da SAP:

Versões e recursos compatíveis com o SAP MaxDB

O SAP MaxDB versão 7.9.09 e mais recentes é certificado pela SAP para uso no Google Cloud.

A SAP também certifica as seguintes versões do SAP liveCache e do SAP Content Server no Google Cloud:

  • Tecnologia SAP liveCache, com no mínimo SAP LC/LCAPPS 10.0 SP 39, incluindo o liveCache 7.9.09.09 e o LCA-Build 39, lançado para EhP 4 para SAP SCM 7.0 e superior
  • O SAP Content Server 6.50 no Windows usando o Internet Information Services 10 (IIS)
  • SAP Content Server 6.50 no Linux usando Apache Web Server 2.4.xx

Para mais informações sobre as versões compatíveis do liveCache, consulte a Nota SAP 2074842 (em inglês).

Para mais informações sobre os produtos SAP compatíveis com o Google Cloud, consulte a Nota SAP 2456432 - Aplicativos SAP no Google Cloud: produtos compatíveis e tipos de máquina do Google Cloud .

Sistemas operacionais compatíveis

É possível executar o SAP MaxDB nos seguintes sistemas operacionais no Google Cloud:

  • Red Hat Entrprise Linux (RHEL)
  • SUSE Linux Enterprise Server (SLES)
  • Windows Server

A SAP lista as versões do sistema operacional que você pode usar com o MaxDB na Matriz de disponibilidade de produtos SAP (em inglês).

O Compute Engine fornece sistemas operacionais Linux e Windows como imagens públicas que incluem melhorias para o Google Cloud. Para mais informações sobre imagens do Compute Engine, clique aqui.

Considerações sobre implantação

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 local do data center. Cada região tem uma ou mais zonas.

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. É possível acessar os recursos zonais, como VMs e discos, apenas por recursos localizados na mesma zona.

Regiões e zonas do Google Cloud

Ao escolher regiões e zonas para as VMs, tenha em mente:

  • 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;
  • a localização dos outros recursos SAP. O aplicativo SAP e o banco de dados precisam estar na mesma zona.

Discos permanentes

Os discos permanentes são dispositivos de armazenamento em blocos duráveis que funcionam de maneira semelhante aos discos físicos em um computador ou servidor.

O Compute Engine oferece diferentes tipos de discos permanentes. Cada tipo tem diferentes características de desempenho. O Google Cloud gerencia o hardware subjacente de discos permanentes para garantir a redundância de dados e otimizar o desempenho.

É possível usar qualquer um dos seguintes tipos de disco permanente do Compute Engine:

  • 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).
  • SSD (pd-ssd): fornece armazenamento em blocos confiável e de alto desempenho com suporte de unidades de estado sólido (SSD).
  • Equilibrado (pd-balanced): fornece armazenamento em blocos baseado em SSD e econômico e confiável.
  • Extremo (pd-extreme): oferece opções de IOPS e capacidade máximas maiores que pd-ssd para tipos de máquinas maiores do Compute Engine. Para mais informações, consulte Discos permanentes extremos.

O desempenho de discos permanentes SSD e equilibrados é dimensionado automaticamente com o tamanho. Assim, você pode ajustar o desempenho redimensionando os discos permanentes existentes ou adicionando mais discos permanentes a uma VM.

O tipo de VM que você está usando e o número de vCPUs que ele contém também afeta o desempenho do disco permanente.

A localização dos discos permanentes independe das VMs, portanto, é possível retirar ou mover os discos para manter os dados, mesmo depois de excluir as VMs.

Para mais informações sobre os diferentes tipos de discos permanentes do Compute Engine, as características de desempenho deles e como trabalhar com eles, consulte a documentação do Compute Engine:

SSD local (não permanente)

O Google Cloud também oferece unidades de disco SSD locais. Os SSDs locais oferecem algumas vantagens em relação aos discos permanentes, mas não os utilize como parte de um sistema SAP MaxDB. Instâncias de VM com SSDs locais conectados não podem ser interrompidas e reiniciadas em seguida.

Gateways NAT e Bastion Hosts

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 o 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 tiverem endereços IP externos, será possível acessá-las apenas por outras VMs na rede ou por meio de um gateway de VPN gerenciado. É possível provisionar VMs na rede para atuarem 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.

Como usar Bastion Hosts para conexões de entrada

Os Bastion Hosts disponibilizam um ponto de entrada externo em uma rede que contém VMs de rede privada. Eles podem fornecer um ponto único de fortalecimento ou auditoria e podem ser iniciados e interrompidos para ativar ou desativar a comunicação SSH de entrada pela Internet.

Bastion Host mostrado no cenário SSH

Para ter acesso SSH a VMs que não contam com endereço IP externo, primeiro conecte-se a um Bastion Host. O aumento da proteção de Bastion Hosts está fora do escopo deste guia, mas é possível executar algumas etapas iniciais, como:

  • 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, em vez de armazenar a chave privada da VM de destino no Bastion Host, é necessário usar o encaminhamento de agente SSH para acessar a VM de destino. Faça isso mesmo que esteja usando o mesmo par de chaves para VMs de destino e Bastion, porque o Bastion tem acesso direto apenas à metade pública do par de chaves.

Como usar gateways NAT para saída de tráfego

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. É necessário ter um gateway NAT por rede. Um gateway NAT de VM única não pode ser considerado altamente disponível e não é compatível com alta capacidade de tráfego para várias VMs. Para instruções sobre como configurar uma VM para atuar como gateway NAT, consulte o Guia de implantação do SAP MaxDB para Linux ou o Guia de implantação do SAP MaxDB para Windows.

Imagens personalizadas

Com o sistema em pleno funcionamento, é possível criar imagens personalizadas. Crie essas imagens quando você modificar o estado do disco permanente raiz e quiser ter a opção de restaurar o novo estado facilmente. Você precisa de um plano para gerenciar as imagens personalizadas criadas. Para mais informações, consulte Práticas recomendadas de gerenciamento de imagens.

Identificação do usuário e acesso a recursos

Ao planejar a segurança de uma implantação do SAP no Google Cloud, é preciso identificar o seguinte:

  • As contas de usuário e os aplicativos que precisam de acesso aos recursos do Google Cloud no seu projeto do Google Cloud.
  • Os recursos específicos do Google Cloud em seu projeto que cada usuário precisará acessar.

É necessário adicionar cada usuário ao projeto incluindo o ID da conta do Google ao projeto como principal. Para programas aplicativos que usam os recursos do Google Cloud, crie uma conta de serviço, que fornece uma identificação ao usuário para o programa dentro do projeto.

As VMs do Compute Engine dispõem de suas próprias contas de serviço. Qualquer programa que seja executado na VM pode usar uma conta de serviço da VM, contanto que essa conta tenha as permissões de recursos necessárias para o programa.

Depois de identificar os recursos do Google Cloud que cada usuário precisa, conceda permissões para que eles usem esses recursos atribuindo papéis específicos do recurso ao usuário. Revise os papéis predefinidos que o IAM oferece para cada recurso e atribua, a cada usuário, papéis que forneçam apenas as permissões suficientes para que eles concluam suas tarefas ou funções.

Se você precisar de um controle mais granular ou restritivo do que os papéis predefinidos do IAM, poderá criar papéis personalizados.

Para mais informações sobre os papéis do IAM necessários aos programas SAP no Google Cloud, consulte Gerenciamento de identidade e acesso para programas SAP no Google Cloud.

Para uma visão geral do gerenciamento de identidade e acesso do SAP no Google Cloud, consulte este artigo.

Rede e segurança da rede

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

Modelo de privilégio mínimo

Uma das primeiras linhas de defesa é restringir quem pode acessar a rede e as VMs, usando firewalls. 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, restrinja todo o tráfego em um determinado conjunto de portas a endereços IP de origem específicos. Siga o modelo de privilégio mínimo para restringir o acesso a portas, protocolos e endereços IP específicos que precisam de acesso. Por exemplo, sempre configure um Bastion Host e autorize o SSH no sistema SAP NetWeaver somente a partir desse host.

Gerenciamento de acesso

Entender como o gerenciamento de acesso funciona no Google Cloud é fundamental para planejar sua implementação. É preciso tomar decisões sobre:

  • como organizar seus recursos no Google Cloud;
  • quais membros da equipe podem acessar e trabalhar com recursos;
  • quais permissões cada membro da equipe pode ter;
  • quais serviços e aplicativos precisam usar quais contas de serviço e que nível de permissões será concedido em cada caso.

Comece entendendo a hierarquia de recursos do Cloud Platform. É importante que você compreenda quais são os diversos contêineres de recursos, como eles se relacionam entre si e onde são criados os limites de acesso.

O gerenciamento de identidade e acesso (IAM) oferece controle unificado sobre permissões para recursos do Google Cloud. É possível gerenciar o controle de acesso definindo quem tem qual acesso aos recursos. Por exemplo, controle quem pode realizar operações de plano de controle nas instâncias SAP, como criação e modificação de VMs, discos permanentes e rede.

Para mais detalhes sobre o IAM, consulte a Visão geral do IAM.

Para uma visão geral do IAM no Compute Engine, consulte Opções de controle de acesso.

Os papéis do IAM são fundamentais para conceder permissões aos usuários. Para conhecê-los e saber quais permissões eles oferecem, consulte Papéis do Identity and Access Management.

As contas de serviço do Google Cloud fornecem uma maneira de conceder permissões a aplicativos e serviços. É importante entender como funcionam as contas de serviço no Compute Engine. Veja mais detalhes em Contas de serviço.

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 (em inglês). Cada projeto do Google Cloud tem uma rede padrão com configurações predefinidas e regras de firewall, mas é preciso 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.

Dependendo dos requisitos, pode ser conveniente adicionar mais sub-redes para isolar partes da rede. Consulte Sub-redes para mais informações.

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. Ou configure os firewalls para serem aplicados a VMs de destino específicas usando o mecanismo de inclusão de tag.

Alguns produtos SAP, como o SAP NetWeaver, exigem acesso a determinadas portas. Lembre-se de adicionar as regras de firewall para permitir o acesso às portas descritas pela 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 máquina virtual como um gateway NAT. Essa configuração exige que você adicione o gateway NAT como uma rota para a instância SAP. Para mais informações, consulte Gateways NAT e Bastion Hosts.

Cloud VPN

É possível conectar sua rede atual ao Google Cloud com segurança por meio de uma conexão VPN usando IPsec com o Cloud VPN. O tráfego entre as duas redes é criptografado por um gateway de VPN e depois decodificado pelo outro gateway de VPN. 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 de acordo com uma taxa mensal estática mais as cobranças de saída padrão. Observe que conectar duas redes no mesmo projeto ainda gera cobranças de saída padrão. Para mais informações, consulte Visão geral do Cloud VPN e Como criar uma VPN.

Como proteger um bucket do Cloud Storage

Se você utiliza o Cloud Storage para hospedar backups de dados e registros, proteja os dados em trânsito usando TLS (HTTPS) ao enviar dados para o Cloud Storage a partir das VMs. O Cloud Storage criptografa automaticamente os dados em repouso. É possível especificar suas próprias chaves de criptografia se tiver seu próprio sistema de gerenciamento de chaves.

Consulte os seguintes recursos de segurança extra para seu ambiente SAP no Google Cloud:

Backup e recuperação

É necessário ter um plano para restaurar o sistema à condição operacional caso o pior aconteça. Para orientações gerais sobre como planejar a recuperação de desastres usando o Google Cloud, consulte:

Licenças

Nesta seção, você encontra informações sobre requisitos de licenciamento.

Licenças SAP

A execução do SAP MaxDB no Google Cloud exige que você traga sua própria licença (BYOL, na sigla em inglês). Veja mais informações em:

Para mais informações sobre licenciamento da SAP, entre em contato com ela.

Licenças do sistema operacional

No Compute Engine, existem duas maneiras de licenciar o SLES, o RHEL e o Windows Server:

  • No pagamento por utilização, o custo por hora de uso da VM do Compute Engine inclui o licenciamento. O Google gerencia a logística de licenciamento. Seus custos por hora são mais altos, mas você tem total flexibilidade para aumentar e diminuir seus custos, conforme necessário. Este é o modelo de licenciamento usado para imagens públicas do Google Cloud que incluem SLES, RHEL e Windows Server.

  • No BYOL, os custos da VM do Compute Engine são menores porque o licenciamento não está incluído. Você precisa migrar uma licença atual ou comprar uma licença própria, o que significa pagar antecipadamente e ter menos flexibilidade.

Suporte

Em caso de problemas com a infraestrutura ou os serviços do Google Cloud, entre em contato com o Customer Care. É possível ver os dados de contato na página Visão geral do suporte no Console do Google Cloud. Se o Customer Care determinar que há um problema nos seus sistemas SAP, você será encaminhado ao Suporte da SAP.

Para problemas relacionados a produtos SAP, registre sua solicitação de suporte no site da SAP. A SAP avalia o tíquete de suporte e, se for um problema de infraestrutura do Google Cloud, transfere o tíquete para o componente BC-OP-LNX-GOOGLE ou BC-OP-NT-GOOGLE do Google Cloud.

Requisitos de suporte

Antes de receber suporte para sistemas SAP e a infraestrutura e os serviços do Google Cloud que eles usam, você precisa atender aos requisitos mínimos do plano de suporte.

Saiba mais sobre os requisitos mínimos de suporte para SAP no Google Cloud em:

Também é possível procurar informações sobre o SAP MaxDB no portal de ajuda da SAP.

A seguir