Guia de planejamento do IBM Db2 para SAP

Neste guia, fornecemos informações sobre como planejar a instalação de um sistema IBM Db2 Advanced Enterprise Server (AESE) (IBM Db2) compatível com aplicativos SAP no Google Cloud.

Para implantar o IBM Db2 com produtos SAP no Google Cloud, consulte:

Para acessar links com mais informações da SAP sobre o IBM Db2, consulte SAP no IBM Db2 para Linux, UNIX e Windows (em inglês).

Para mais informações sobre os produtos certificados pela SAP para execução no Google Cloud, incluindo o IBM DB2, consulte a Nota SAP 2456432 - Aplicativos SAP no Google Cloud: produtos compatíveis e tipos de máquinas do Google Cloud .

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 do IBM Db2 com um banco de dados de partição única no Google Cloud é composta pelos componentes a seguir:

  • Uma VM do Compute Engine que executa o banco de dados do IBM Db2

  • Uma ou mais unidades de disco permanente para as opções a seguir:

    • O disco raiz.
    • O volume do ID do banco de dados (/db2/<DBSID>/).
    • O volume da instância (/db2/db2<dbsid>), que inclui o diretório inicial do usuário db2<dbsid> e os dados da instância do IBM Db2 para <DBSID>, bem como o software IBM Db2.
    • O volume de registros (/db2/<DBSID>/log_dir), que inclui pelo menos os arquivos de registro do banco de dados on-line.
    • O volume de despejo/diagnóstico (/db2/<DBSID>/db2dump), que inclui arquivos de registro de diagnóstico do Db2, arquivos de despejo do Db2 e outras informações do engenheiro de serviço.
    • O volume de dados (/db2/<DBSID>/sapdata<n> ou /db2/<DBSID>/sapdata/sapdata<n>). Ele é o local de armazenamento para espaços de tabela com o arquivo gerenciado de banco de dados (DMS) do tipo contêiner ou espaços de tabela com o armazenamento automático do Db2.
    • O volume temporário do espaço de tabela (/db2/<DBSID>/saptmp<n> ou /db2/ <DBSID>/saptmp/saptmp<n>). Ele é o local de armazenamento para espaços de tabela temporários.

Dependendo dos requisitos da instalação, talvez seja necessário incluir também:

  • Um gateway NAT Um gateway NAT permite fornecer conectividade com a Internet para suas VMs embora negue 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.
  • Um volume de backup para armazenar backups intermediários.
  • Um volume de armazenamento para armazenar arquivos de registro.

Casos de uso diferentes podem exigir dispositivos ou bancos de dados extras. Para mais informações, consulte:

Recursos necessários

De muitas maneiras, executar o IBM Db2 com SAP 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 o guia de instalação (em inglês) apropriado para seu sistema SAP com IBM Db2.

Configuração de VM

O IBM Db2 é certificado para execução em todos os tipos de máquina do Compute Engine, inclusive tipos personalizados. Na maioria dos casos, use um tipo de máquina com duas ou mais CPUs virtuais.

Para informações sobre os diferentes tipos de máquina do Compute Engine e os casos de uso, consulte Tipos de máquina na documentação do Compute Engine.

Configuração de CPU

O número de vCPUs necessárias varia de acordo com a carga do aplicativo no IBM Db2 LUW. Aloque no mínimo duas vCPUs para a instalação do IBM Db2. Para que o sistema IBM Db2 aproveite ao máximo os recursos atuais, siga as orientações na documentação SAP no IBM Db2 para Linux, UNIX e Windows (em inglês) e ajuste seus recursos de computação conforme necessário.

Configuração de memória

A VM com IBM Db2 precisa ter pelo menos 4 GB de RAM por vCPU. Desse valor, aproximadamente 80% da RAM precisa ser alocada para o IBM Db2, ficando os 20% restantes para o SO em que o IBM Db2 está sendo executado.

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 orientações sobre como otimizar a configuração de memória, consulte a documentação SAP no IBM Db2 para Linux, UNIX e Windows.

Configuração de armazenamento

Por padrão, cada VM do Compute Engine tem um pequeno disco permanente raiz que contém o sistema operacional. Também é preciso criar, anexar, formatar e montar discos extras para o banco de dados, os registros e os procedimentos armazenados.

O tamanho do disco e os requisitos de desempenho dependem do aplicativo. Dimensione cada dispositivo de acordo com suas necessidades.

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

Para orientação da SAP sobre o dimensionamento de disco, consulte:

Versões do IBM Db2 compatíveis

Utilize os níveis de Pacote de correções (FP, na sigla em inglês) do software IBM Db2 certificado pela SAP. Não é permitido usar outros níveis de software do IBM Db2.

Para mais informações, consulte a Nota SAP 101809 - DB6: Níveis de pacote de correções e versões do Db2 compatíveis.

Recursos compatíveis do IBM Db2

A SAP dá suporte à maioria dos recursos do IBM Db2 no Google Cloud. No entanto, não há suporte para os seguintes recursos:

  • Bancos de dados Db2 com várias partições
  • Recurso pureScale para IBM Db2

Sistemas operacionais compatíveis

A SAP certificou o Google Cloud para executar o IBM Db2 nas imagens a seguir de sistema operacional SUSE Linux Enterprise Server (SLES), Red Hat Enterprise Linux (RHEL) e Windows Server:

  • SLES 12 SP2 e posterior
  • RHEL 7.4
  • Windows Server 2012 R2 e posterior

Para mais informações sobre imagens do Compute Engine, consulte Imagens.

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 IBM Db2. 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 particular. Eles fornecem um ponto único de fortalecimento ou auditoria e é possível iniciá-los e interrompê-los 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 sem endereço IP externo, primeiro conecte-se a um Bastion Host. O aumento da proteção de Bastion Hosts está fora do escopo deste artigo, mas é possível executar algumas etapas iniciais, incluindo o seguinte:

  • Limitar o intervalo CIDR de IPs de origem capazes de 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. Consulte o guia de implantação do IBM Db2 para SAP NetWeaver para instruções sobre como configurar uma VM para atuar como um gateway NAT.

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 usando esse 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 (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 incorre em cobranças de saída padrão. Para mais informações, consulte a Visão geral de VPN e Como escolher uma opção de roteamento de VPN.

Como proteger um bucket do Cloud Storage

Se você usa o Cloud Storage para hospedar backups de dados e registros, proteja os dados em trânsito usando TLS (HTTPS) ao enviá-los das VMs para o Cloud Storage. O Cloud Storage criptografa 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.

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

Backup e recuperação

É preciso ter um plano para restaurar o sistema à condição operacional caso o pior aconteça.

Para mais informações sobre backup e recuperação de sistemas IBM Db2 compatíveis com SAP, consulte:

Para orientações gerais sobre como planejar a recuperação de desastres usando o Google Cloud, consulte:

Automação para implantações do IBM Db2

O Google Cloud fornece um arquivo de configuração do Terraform que pode ser usado para automatizar a implantação de recursos do IBM Db2 com Linux.

A configuração sap_db2.tf fornecida pelo Google Cloud para IBM Db2 provisiona os seguintes recursos:

  • Uma instância de VM do Compute Engine com base no tipo de máquina de sua preferência.
  • Escolha o sistema operacional Red Hat Enterprise Linux (RHEL) ou SUSE Linux Enterprise Server (SLES).
  • Discos permanentes do Compute Engine.
  • Agente de monitoramento do Google Cloud para SAP NetWeaver.

Para instruções de automação de implantação, consulte Implantação automatizada de VMs para o IBM Db2 no Linux usando o Terraform.

Clusters de alta disponibilidade do IBM Db2

É possível configurar um cluster IBM Db2 altamente disponível e tolerante a desastres no Google Cloud que seja compatível com SAP. O cluster é configurado e gerenciado pelo IBM System Automation for Multiplatforms (TSAMP) e usa a função HADR do IBM Db2 para fins de replicação.

Os aplicativos se conectam ao servidor principal do IBM Db2 por meio de um endereço IP flutuante, que, em caso de failover, é reatribuído pelo TSAMP ao servidor em espera.

O papel IBM Db2 HADR comporta até três servidores em espera. No Google Cloud, as VMs de host no cluster precisam estar na mesma região, mas podem estar em zonas diferentes dentro dessa região.

O suporte da SAP para clusters de HA do DB2 no Google Cloud está listado na Nota SAP 2456432 - Aplicativos SAP no Google Cloud: produtos compatíveis e tipos de máquina do Google Cloud .

Para mais informações sobre os recursos do IBM Db2 aceitos pela SAP, consulte a Nota SAP 1555903.

Arquiteturas de implantação

É possível implantar as VMs do host em um cluster HA do IBM Db2 em várias zonas do Compute Engine na mesma região ou, se necessário, implantá-las em uma única região.

Para maior disponibilidade, implante cada VM do host em uma zona diferente.

O diagrama a seguir mostra uma implantação em várias zonas que usa uma implementação de rota estática para o endereço IP flutuante.

Cada host de um cluster Db2 de alta disponibilidade é implantado em uma zona diferente.

O diagrama a seguir mostra uma implantação em uma única zona que usa uma implementação de IP de alias para o endereço IP flutuante.

Os dois hosts de um cluster Db2 de alta disponibilidade são implantados na mesma zona.

Documentação necessária

Para implantar um cluster IBM Db2 de alta disponibilidade para SAP, você precisa seguir a documentação do SAP e do Google Cloud.

Durante a instalação dos componentes da SAP ou da IBM, pode ser necessário consultar a documentação extra de cada uma.

Requisitos específicos de um cluster IBM Db2 de alta disponibilidade no Google Cloud

No Google Cloud, a SAP é compatível com clusters IBM Db2 de alta disponibilidade apenas em sistemas operacionais RHEL ou SLES.

Para ver os requisitos de software do Google Cloud para as instâncias do IBM Db2, consulte Requisitos de recursos.

Para o IBM TSAMP, use a versão mais recente disponível que seja compatível com sua versão do IBM Db2 e seu sistema operacional.

Para ver todos os outros requisitos de hardware e software, consulte Solução de alta disponibilidade do IBM Db2: IBM Tivoli System Automation for Multiplatforms.

Endereços IP flutuantes para clusters IBM Db2 de alta disponibilidade no Google Cloud

Um cluster HA do IBM Db2 para SAP usa um endereço IP flutuante, também conhecido como "endereço IP virtual" ou "endereço IP compartilhado".

Para um cluster IBM Db2 de alta disponibilidade, o Google Cloud pode implementar um endereço IP flutuante usando uma rota estática ou um IP de alias do Google Cloud.

A implementação de rota estática é recomendada para clusters IBM Db2 de alta disponibilidade presentes em várias zonas. As implantações em várias zonas ajudam a garantir que uma falha em uma única zona não deixe o sistema IBM Db2 indisponível.

No entanto, caso sua arquitetura de rede não comporte rotas estáticas ou você precise evitar soluções como sobreposição de IP ou roteamento complexo, use a implementação de endereço IP de alias com um cluster HA do IBM Db2 presente em uma única zona. Não é recomendável usar endereços IP de alias para implantações em várias zonas porque a realocação do alias pode não ser garantida no caso de uma falha zonal.

Os requisitos referentes ao endereço IP usado como flutuante diferem de acordo com a implementação escolhida: rota estática ou IP de alias.

O uso de uma rota estática exige que você selecione como flutuante um endereço IP que:

  • esteja fora dos intervalos de IP das sub-redes de nuvem privada virtual atuais, onde as VMs residem;
  • não entre em conflito com nenhum endereço IP externo na rede expandida.

Consulte o administrador da rede para determinar um endereço IP adequado para uma implementação de rota estática.

O uso de um endereço IP de alias exige que você o reserve a partir do intervalo de IPs da sub-rede para ser usado como endereço IP flutuante.

Para mais informações sobre endereços IP flutuantes no Google Cloud, consulte Práticas recomendadas para endereços IP flutuantes.

A SAP recomenda o uso de endereços IP flutuantes em clusters HA do IBM Db2. Ela também aceita Redirecionamento automático do cliente (ACR, na sigla em inglês), desde que sua conta para todos os requisitos e limitações deste método seja reconhecida. Para mais informações, consulte a Nota SAP 1568539.

Desempatador de rede

Os clusters IBM Db2 de alta disponibilidade geralmente enviam uma solicitação ICMP (ping) para um gateway de rede, que serve como um desempatador de rede para determinar qual nó assumirá quando a comunicação entre os nós em um cluster for perdida.

Como os gateways de rede no Google Cloud não respondem a solicitações ICMP, use qualquer outro endereço IP que possa receber ping e que seja altamente disponível. Por exemplo, é possível usar o endereço IP virtual da instância do Central Services do aplicativo SAP ou o DNS do Google, 8.8.8.8.

Se o desempatador de rede não conseguir responder a solicitações ICMP durante a configuração, ela falhará.

Há outros fatores de desempate de rede definidos pela IBM. Para mais informações, consulte Como configurar o Operator.

Ferramentas de configuração para um cluster Db2 HA

É possível utilizar uma das seguintes ferramentas fornecidas pela a SAP e pela IBM para configurar um cluster do IBM Db2 HADR:

  • A ferramenta de configuração de clusters SAP (sapdb2cluster.sh)
  • O utilitário de configuração de instâncias de alta disponibilidade do IBM DB2 (db2haicu)

Ferramenta de configuração de clusters Db2 da SAP (sapdb2cluster.sh)

A SAP recomenda a ferramenta de configuração de cluster fornecida por ela mesma, sapdb2cluster.sh, para configurar e criar um cluster Db2 de alta disponibilidade. As instruções de implantação do Google Cloud usam a ferramenta de configuração de cluster SAP. Ela simplifica grande parte da instalação do cluster e garante que ele atenda aos requisitos de suporte da SAP.

Antes de você criar o cluster de alta disponibilidade com a ferramenta de configuração de clusters da SAP (sapdb2cluster.sh), uma das etapas nas instruções de implantação do Google Cloud faz uma pequena modificação nessa ferramenta para que ela ignore a criação da classe de recurso IBM.ServiceIP padrão.

Os recursos criados com base na classe de recurso IBM.ServiceIP do IBM TSAMP emitem solicitações ARP gratuitas, que não são aceitas em redes VPC no Google Cloud, conforme explicado em Desafios na migração de IPs flutuantes para o Compute Engine.

Para fazer o download da versão mais recente da ferramenta de configuração de clusters, consulte a Nota da SAP 960843.

Utilitário de configuração de instâncias de alta disponibilidade do IBM Db2 (db2haicu)

Como alternativa ao uso da ferramenta de configuração de clusters da SAP, é possível usar o utilitário db2haicu da IBM, que também fornece uma interface interativa. A ferramenta de configuração de clusters da SAP usa o db2haicu para configurar o cluster.

Ao usar o utilitário db2haicu para configurar o cluster, primeiro configure a relação com HADR antes do db2haicu. Embora o procedimento geral de configuração possa ser mais complexo com o utilitário db2haicu, este confere mais personalização a configurações complexas de rede ou outros requisitos específicos do ambiente.

Sempre siga as orientações da SAP e da IBM ao usar o utilitário db2haicu.

Para mais informações sobre db2haicu, consulte a documentação do IBM Db2.

Script auxiliar do Google Cloud para integração de clusters do IBM TSAMP

Para permitir que o cluster IBM Db2 de alta disponibilidade chame os comandos apropriados das APIs do Google Cloud para iniciar, interromper e monitorar o recurso TSAMP do endereço IP flutuante, faça o download de um script auxiliar do Google Cloud para as VMs do host. Ao criar o recurso de endereço IP flutuante no IBM TSAMP, você faz referência ao script auxiliar do Google Cloud.

Licenças

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

Licenças do IBM Db2

Ao executar o IBM Db2 no Google Cloud, é preciso trazer sua própria licença (BYOL, na sigla em inglês). As licenças do Db2 são oferecidas pela SAP e pela IBM. Para mais informações sobre licenciamento e suporte, consulte as seguintes Notas SAP:

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. Os custos por hora serão mais altos, mas você terá flexibilidade total para aumentá-los e diminuí-los conforme necessário. Esse é 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 sua própria licença, 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:

Para mais informações sobre o suporte da SAP para Db2, consulte a nota SAP 1168456 - DB6: processo de suporte e datas de fim de suporte ao IBM DB2 para LUW.

A seguir

Para implantar o IBM Db2 no Google Cloud, consulte:

Para implantar um cluster IBM Db2 de alta disponibilidade no Google Cloud, consulte o Guia de implantação do cluster IBM Db2 de alta disponibilidade para SAP.