Guia de implantação do cluster de alta disponibilidade Db2 da IBM para SAP

Neste guia, você entenderá como configurar os recursos do Google Cloud para um cluster de alta disponibilidade (HA, na sigla em inglês) Db2 IBM para SAP no sistema operacional Linux.

Estas instruções complementam as orientações da SAP e IBM fornecidas em Solução de alta disponibilidade IBM Db2: IBM Tivoli System Automation for Multiplatforms (em inglês). Sempre consulte a documentação mais recente fornecida pela SAP e IBM ao instalar e configurar um cluster de alta disponibilidade IBM Db2 no Google Cloud.

Estas instruções são para um cluster HA IBM Db2 que usa o IBM Tivoli System Automation for Multiplatforms (TSAMP) para monitorar o sistema e iniciar a ação apropriada, se o sistema não responder. O cluster utiliza a função de recuperação de desastres de alta disponibilidade (HADR, na sigla em inglês) IBM Db2 para replicar as mudanças nos dados registrados no banco de dados em espera.

O cluster utiliza um endereço IP flutuante que é implementado pelo Google Cloud com uma rota estática ou um endereço IP de alias. Nesse contexto, "endereço IP flutuante" é mesmo que "endereço IP virtual", que é usado na documentação da SAP.

Nestas instruções, você vê como configurar um cluster HA IBM Db2 formado por um servidor IBM Db2 primário e outro secundário ou em espera. Cada um deles é implantado em uma máquina virtual (VM, na sigla em inglês) separada do Compute Engine.

Este guia é destinado a usuários da SAP e do IBM Db2 que sejam experientes e estejam familiarizados com clusters de alta disponibilidade.

Para mais informações sobre o planejamento de um cluster HA Db2, consulte Clusters de alta disponibilidade IBM Db2 no guia de planejamento correspondente da SAP.

Documentação necessária da SAP

As instruções para instalar e configurar os componentes da SAP e IBM são fornecidas em Solução de alta disponibilidade IBM Db2: IBM Tivoli System Automation for Multiplatforms (em inglês).

Leia as documentações da SAP e do Google Cloud antes de iniciar os procedimentos destas instruções. Em várias etapas da implantação, talvez você precise consultar essas documentações.

Pré-requisitos

Antes de criar o cluster de alta disponibilidade IBM Db2, atenda aos requisitos a seguir:

  • Você ou sua organização precisam ter uma conta do Google Cloud. Além disso, é necessário criar um projeto para a implantação do cluster IBM Db2 HA. Para informações sobre como criar projetos do Google Cloud, consulte os pré-requisitos no guia de implantação do IBM Db2 para SAP.
  • 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, crie a pasta do Assured Workloads necessária. Para mais informações, consulte Controles soberanos e de conformidade para a SAP no Google Cloud.

  • Você precisa ter uma rede de nuvem privada virtual no Google Cloud. Para instruções sobre como configurar uma rede VPC e regras de firewall, além de definir um gateway NAT ou Bastion Host para IBM Db2 para SAP, consulte o guia de implantação.

  • Se o login do SO estiver ativado nos metadados do projeto, você precisará desativar o login do SO temporariamente até que a implantação seja concluída. Para fins de implantação, este procedimento configura chaves SSH em metadados de instâncias. Quando o login do SO está ativado, as configurações de chave SSH baseadas em metadados são desativadas. Após a conclusão da implantação, ative o login do SO novamente.

    Veja mais informações em:

Como implantar um cluster de alta disponibilidade Db2 da IBM no Google Cloud

Nestas instruções, você entenderá como implantar duas VMs, definir um endereço IP flutuante e configurar o endereço IP de alias ou as rotas do Google Cloud compatíveis com o endereço IP flutuante. Quando for necessário instalar os componentes da IBM, consulte a documentação da SAP.

Os principais serviços do Google Cloud que você precisa configurar em um cluster de alta disponibilidade IBM Db2 são os seguintes:

  • Uma rede e sub-rede VPC
  • Regras de firewall (se você não usa outro tipo de controle de acesso à rede)
  • Armazenamento em disco permanente e VMs do Compute Engine

Além disso, faça o download e use um script auxiliar do Google Cloud ao definir o recurso personalizado usado pelo TSAMP para gerenciar a alternância do endereço IP flutuante entre os hosts. Com o script, o TSAMP pode interagir com as APIs do Google Cloud.

Sobre o Deployment Manager

Nestas instruções, você definirá as opções de recursos para a instalação em um modelo de arquivo de configuração do Deployment Manager.

O Deployment Manager trata todos os recursos criados para o sistema SAP como uma única entidade chamada de implantação. Consulte e trabalhe com todas as implantações do seu projeto na página Implantações no console do Google Cloud.

Ao usar o Deployment Manager, esteja ciente dos seguintes comportamentos:

  • A exclusão de uma implantação exclui todos os recursos associados a ela, incluindo as VMs, os discos permanentes e quaisquer sistemas SAP instalados nas VMs.

  • Por padrão, o Deployment Manager usa a política de criação de recursos do ACQUIRE. Ao especificar um nome de VM que já esteja em uso por outra VM no projeto, o Deployment Manager não criará uma nova, mas adicionará a atual à nova implantação. Se a VM original foi criada por uma execução anterior do Deployment Manager, ela será associada a duas implantações.

    Se você excluir a nova implantação, a VM adquirida será excluída da implantação que a criou. Para evitar que isto aconteça, defina a política de recursos do Deployment Manager como CREATE ou certifique-se de usar nomes de recursos exclusivos na nova implantação.

    Para informações sobre as políticas que podem ser usadas ao criar recursos com o Deployment Manager e como especificá-las, consulte a documentação do Deployment Manager.

Como implantar as VMs para um cluster Db2 HA da IBM com o Deployment Manager

  1. No Cloud Shell, faça o download do modelo do arquivo de configuração template_ha.yaml no diretório de trabalho:

    wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/template_ha.yaml

  2. Para abrir o editor de código, clique no ícone de lápis () no canto superior direito da janela do terminal do Cloud Shell.

  3. Você tem a opção de renomear o arquivo template_ha.yaml para identificar a configuração que ele define. Por exemplo, db2_ha_s123_dh1.yaml.

  4. Para abrir o template_ha.yaml no editor de código, clique duas vezes nele.

  5. Defina as VMs e os discos permanentes no arquivo template_ha.yaml. O arquivo template_ha.yaml contém duas seções: sap_db2_primary e sap_db2_secondary. Cada seção tem um conjunto de pares de propriedade-valor seguidos de comentários que incluem as propriedades usadas com menos frequência.

    Quando você preenche cada seção, com exceção das propriedades instanceName, zone e otherHost, as definições de cada VM precisam ser iguais.

    Na tabela a seguir, você vê descrições das propriedades incluídas em cada seção. Para usar uma propriedade, substitua os colchetes e o texto do marcador pelos valores da sua instalação.

    Propriedade Tipo de dados Descrição
    Tipo String

    Especifica o local, o tipo e a versão do modelo do Deployment Manager a ser usado durante a implantação.

    O arquivo YAML inclui duas especificações type, uma delas comentada. A especificação type que está ativa por padrão especifica a versão do modelo como latest. A especificação type comentada especifica uma versão de modelo específica com carimbo de data/hora.

    Se você precisar que todas as suas implantações usem a mesma versão de modelo, use a especificação type que inclui o carimbo de data/hora.

    instanceName String O nome da instância de VM em que você instala o IBM Db2. Ele precisa ter até 13 caracteres ou menos, escrito em letras minúsculas, números ou hífens.
    instanceType String O tipo de máquina virtual do Compute Engine em que você instala o IBM Db2. Especifique um tipo de máquina com duas ou mais vCPUs. Por exemplo, n1-standard-4.
    zone String A zona em que a instância do IBM Db2 está sendo implantada. Ele precisa estar na mesma região selecionada para a sub-rede.
    subnetwork String O nome da sub-rede criada em um passo anterior. Se estiver fazendo a implantação em uma VPC compartilhada, especifique o valor como shared-vpc-project/SUBNETWORK. Por exemplo, myproject/network1.
    linuxImage String O nome da família de imagens ou da imagem do sistema operacional Linux que está sendo usado com o IBM Db2. Para especificar uma família de imagens, adicione o prefixo family/ ao nome da família. Por exemplo, family/rhel-7-sap-apps ou family/sles-12-sp3-sap. Para especificar uma imagem, insira apenas o nome dela. Para ver a lista de famílias de imagens disponíveis, consulte a página Imagens no Console do Google Cloud.
    linuxImageProject String Projeto do Google Cloud que contém a imagem a ser utilizada. Ele pode ser seu próprio projeto ou um projeto de imagem do Google Cloud, como rhel-sap-cloud ou suse-sap-cloud. Para ver uma lista dos projetos de imagem do Google Cloud, consulte a página Imagens na documentação do Compute Engine.
    db2SID String O ID da instância do banco de dados.
    db2sidSize Número inteiro O tamanho em GB de /db2/DBSID, que é o diretório raiz da instância do banco de dados. Os valores mínimo e padrão de db2sidSize são 8 GB.
    db2homeSize Número inteiro O tamanho em GB de /db2/db2db2sid, que é o diretório inicial da instância do banco de dados. Os valores mínimo e padrão de db2homeSize são 8 GB.
    db2dumpSize Número inteiro O tamanho em GB de /db2/DBSIDdb2dump, que armazena os arquivos dump do DB2 usados para diagnosticar problemas. Os valores mínimo e padrão de db2dumpSize são 8 GB.
    db2saptmpSize Número inteiro O tamanho em GB de /db2/DBSID/saptmp, que armazena o espaço de tabela temporário do banco de dados. Os valores mínimo e padrão de db2saptmpSize são 8 GB.
    db2sapdataSize Número inteiro O tamanho de /sapdb/DBSID/sapdata, que armazena os arquivos de dados do banco de dados. Os valores mínimo e padrão de db2sapdataSize são 30 GB.
    db2logSize Número inteiro O tamanho de /db2/DBSID/logdir, que armazena os registros de transação do banco de dados. Os valores mínimo e padrão de db2logSize são 8 GB.
    db2backupSize Número inteiro O tamanho do volume /db2backup. Esta propriedade é opcional. Se ela for definida como 0 ou omitida, nenhum disco será criado.
    db2sapdataSSD boolean Especifica se a unidade de dados usa um disco permanente SSD (Yes) ou HDD (No). Yes é o padrão.
    db2logSSD boolean Especifica se a unidade de registros usa um disco permanente SSD (Yes) ou HDD (No). Yes é o padrão. É recomendado o uso de SSD.
    usrsapSize Número inteiro Necessário apenas se você estiver instalando o IBM Db2 para ser executado com o SAP NetWeaver na mesma instância de VM.
    sapmntSize Número inteiro Necessário apenas se você estiver instalando o IBM Db2 para ser executado com o SAP NetWeaver na mesma instância de VM.
    swapSize Número inteiro Necessário apenas se você estiver instalando o IBM Db2 para ser executado com o SAP NetWeaver na mesma instância de VM.
    otherHost String O nome da outra instância de VM no cluster de HA do IBM Db2. A instância de VM precisa ser definida no outro conjunto de propriedades no mesmo arquivo template_ha.yaml.
    networkTag String Opcional. Uma tag de rede que representa a instância de VM para fins de firewall ou roteamento. Se você especificar publicIP: No e não usar uma tag de rede, forneça outro meio de acesso à Internet.
    publicIP boolean Opcional. Determina se um endereço IP público é adicionado à instância da VM. O padrão é Yes.
    serviceAccount String Opcional. Se você criar sua própria conta de serviço com permissões bloqueadas, insira o nome dela aqui. Por padrão, as VMs são implantadas usando a conta de serviço padrão do projeto. Uma conta de serviço definida incorretamente impede a realização da implantação. Veja a seguir um exemplo de conta de serviço personalizada: myserviceuser@myproject.iam.gserviceaccount.com
    sap_deployment_debug boolean Opcional. Se esse valor estiver definido como Yes, a implantação irá gerar registros detalhados de implantação. Não ative essa configuração a menos que um engenheiro do Suporte do Google peça para habilitar a depuração.
    post_deployment_script String Opcional. Especifica o local de um script a ser executado após a conclusão da implantação. O script precisa estar hospedado em um servidor da Web ou em um bucket do Cloud Storage. O URL precisa começar com http://, https:// ou gs://. Esse script é executado em todas as VMs criadas pelo modelo. Para executá-lo apenas na instância principal, adicione uma verificação na parte superior do script.

    O seguinte exemplo de definições de VM de um arquivo de configuração template_ha.yaml cria duas VMs para um cluster IBM Db2 HA. Para cada VM, o arquivo de configuração direciona o Deployment Manager a implantar uma VM n1-standard-4 que está executando um sistema operacional da família de imagens SLES 12 SP3. A VM inclui todos os diretórios necessários para executar um cluster HA IBM Db2. O Deployment Manager não cria os diretórios do SAP NetWeaver porque os tamanhos deles estão definidos como 0.

    resources:
- name: sap_db2_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/sap_db2.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202103310846/dm-templates/sap_db2/sap_db2.py
  #
  properties:
    instanceName: db2-ha-s1
    instanceType: n1-standard-4
    zone: us-central1-c
    subnetwork: example-sap-subnetwork
    linuxImage: family/sles-12-sp3-sap
    linuxImageProject: suse-sap-cloud
    db2SID: DH1
    db2sidSize: 16
    db2dumpSize: 16
    db2saptmpSize: 16
    db2sapdataSize: 50
    db2logSize: 16
    db2backupSize: 50
    db2sapdataSSD: Yes
    db2logSSD: Yes
    usrsapSize: 0
    sapmntSize: 0
    swapSize: 0
    otherHost: db2-ha-s2
#
# (Comment section omitted from example)
#
- name: sap_db2_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/sap_db2.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202103310846/dm-templates/sap_db2/sap_db2.py
  #
  properties:
    instanceName: db2-ha-s2
    instanceType: n1-standard-4
    zone: us-central1-f
    subnetwork: example-sap-subnetwork
    linuxImage: family/sles-12-sp3-sap
    linuxImageProject: suse-sap-cloud
    db2SID: DH1
    db2sidSize: 16
    db2dumpSize: 16
    db2saptmpSize: 16
    db2sapdataSize: 50
    db2logSize: 16
    db2backupSize: 50
    db2sapdataSSD: Yes
    db2logSSD: Yes
    usrsapSize: 0
    sapmntSize: 0
    swapSize: 0
    otherHost: db2-ha-s1

  6. Implante a instância de VM com o Deployment Manager.

    gcloud deployment-manager deployments create DEPLOYMENT-NAME --config TEMPLATE-NAME.yaml

    Em que:

    • DEPLOYMENT-NAME representa o nome de sua escolha para a implantação atual. Esse nome é usado para identificar essa implantação na página Implantações do console do Google Cloud.
    • TEMPLATE-NAME representa o nome escolhido para o arquivo de configuração ou, se você não tiver alterado o nome do arquivo padrão, template_ha.yaml.

    O Deployment Manager lê as especificações no arquivo template_ha.yaml e configura a VM e os discos permanentes de acordo com elas. Isso pode levar alguns minutos. Para verificar o andamento da implantação, siga as etapas da próxima seção.

Como verificar a implantação

Para verificar a implantação, verifique os registros de implantação no Cloud Logging e verifique a configuração da VM.

Verificar os registros

  1. No console do Google Cloud, abra o Cloud Logging para monitorar o progresso da instalação e verificar se há erros.

    Acesse o Cloud Logging

  2. Filtre os registros:

    Explorador de registros

    1. Na página Explorador de registros, acesse o painel Consulta.

    2. No menu suspenso Recurso, selecione Global e clique em Adicionar.

      Se a opção Global não for exibida, insira a seguinte consulta no editor de consultas:

      resource.type="global"
"Deployment"

    3. Clique em Run query.

    Visualizador de registros legado

    • Na página Visualizador de registros legado, no menu de seleção básico, selecione Global como o recurso de registros.

  3. Analise os registros filtrados:

    • Se "--- Finished" for exibido, o processamento do Deployment Manager estará concluído e será possível prosseguir para a próxima etapa.

    • Se você vir um erro de cota:

      1. Na página Cotas do IAM e Admin, aumente as cotas que não atendem aos requisitos do IBM DB2 listados no Guia de planejamento IBM DB2 do SAP.

      2. Na página Implantações do Deployment Manager, exclua a implantação para limpar as VMs e discos permanentes da instalação com falha.

      3. Execute a implantação novamente.

Verificar a configuração da VM

  1. Após a conclusão da implantação da VM, use ssh para se conectar a cada VM. Na página de instâncias de VM do Compute Engine, clique no botão SSH referente a cada instância de VM ou use o método SSH que preferir.

    Botão SSH na página "Instâncias de VM" do Compute Engine.

  2. Mude para o usuário raiz.

    sudo su -

  3. No prompt de comando, insira df -h. Você precisa ver uma saída semelhante a esta:

    db2-ha-s1:~ # df -h
Filesystem                     Size  Used Avail Use% Mounted on
devtmpfs                       7.4G     0  7.4G   0% /dev
tmpfs                           12G     0   12G   0% /dev/shm
tmpfs                          7.4G   18M  7.4G   1% /run
tmpfs                          7.4G     0  7.4G   0% /sys/fs/cgroup
/dev/sda1                       30G  2.2G   26G   8% /
/dev/mapper/vg_db2sid-vol       16G   33M   16G   1% /db2/DH1
/dev/mapper/vg_db2dump-vol      16G   33M   16G   1% /db2/DH1/db2dump
/dev/mapper/vg_db2sapdata-vol   50G   33M   50G   1% /db2/DH1/sapdata
/dev/mapper/vg_db2saptmp-vol    16G   33M   16G   1% /db2/DH1/saptmp
/dev/mapper/vg_db2log-vol       16G   33M   16G   1% /db2/DH1/log_dir
/dev/mapper/vg_db2home-vol      16G   33M   16G   1% /db2/db2dh1
/dev/mapper/vg_db2backup-vol    50G   33M   50G   1% /db2backup
tmpfs                          1.5G     0  1.5G   0% /run/user/1001

Se qualquer uma das etapas de validação mostrar que a instalação falhou, faça o seguinte:

  1. Corrija o erro.
  2. Na página Implantações, exclua a implantação para limpar as VMs e os discos permanentes da instalação com falha.
  3. Execute a implantação novamente.

Como reservar um endereço IP flutuante

Selecione um endereço IP para usar como endereço IP flutuante. Ele será necessário mais tarde quando você definir os metadados da instância de VM do host e instalar e configurar o IBM Db2 e o cluster de alta disponibilidade.

Os requisitos do endereço IP flutuante são diferentes de acordo com o tipo de implementação escolhido: IP do alias ou rota.

Se você usa a implementação de rota estática no endereço IP flutuante, o endereço IP precisa estar fora do intervalo da sub-rede. Além disso, ele não pode ser usado por qualquer outro componente nas redes expandidas da organização. Consulte o administrador de rede para determinar um endereço IP apropriado a ser usado.

Se você usa a implementação de endereço IP do alias no endereço IP flutuante, será necessário reservar um endereço IP do intervalo da sub-rede que os hosts estão utilizando.

Para reservar um endereço IP do alias somente quando escolher esse tipo de implementação, faça o seguinte:

  1. Abra um terminal em uma VM do host ou o Cloud Shell.

    Acessar o Cloud Shell

  2. Reserve um endereço IP.

    gcloud compute addresses create vip-name --region region --subnet subnet-name \
  --addresses ip-addr-optional

    Especificar a propriedade dos endereços é opcional. Se você não inserir um endereço IP, o Compute Engine selecionará um da sua sub-rede.

  3. Exiba e anote o endereço IP reservado a ser usado quando você instalar o servidor de banco de dados e configurar o cluster de alta disponibilidade.

    gcloud compute addresses describe vip-name --region=region

    Por exemplo: 

    db2-ha-s1:~ # gcloud compute addresses describe db2-ha-vip-dh1 --region=us-central1
address: 10.1.0.30
addressType: INTERNAL
creationTimestamp: '2018-11-28T11:34:14.478-08:00'
description: ''
id: '6558342813288977241'
kind: compute#address
name: db2-ha-vip-dh1
region: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1/addresses/db2-ha-vip-dh1
status: RESERVED
subnetwork: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1/subnetworks/example-sap-   subnetwork

Como adicionar o endereço IP flutuante aos metadados de cada instância de VM do host

Especifique as informações sobre seu endereço IP flutuante como metadados personalizados em cada instância de VM no cluster. Elas incluem o tipo de implementação escolhido (IP do alias ou rota). Para mais informações sobre como escolher um tipo de implementação para o endereço IP flutuante, consulte Endereços IP flutuantes para clusters IBM Db2 HA no Google Cloud.

Dependendo do tipo de implementação, os parâmetros de metadados definidos são diferentes. Nas próximas duas seções, siga as instruções daquela que se aplica à implementação de endereço IP flutuante escolhida.

Como configurar metadados em uma implementação de rota do endereço IP flutuante

Se você usa uma implementação de rota no endereço IP flutuante, utilize os parâmetros da tabela a seguir e o procedimento posterior para definir os metadados da instância.

Parâmetro Valor Finalidade
sap_ibm_vip_solution route Indica que esta é uma implantação de várias zonas que usa uma rota estática do Google Cloud para prestar suportar a alternância de endereço IP flutuante entre os hosts.
sap_ibm_db2_vip ip-address Especifica o endereço IP flutuante que você reservou na etapa anterior.
sap_ibm_db2_routename route-name Especifica um nome arbitrário para a rota estática. Por exemplo, db2-dh1-vip-route.
sap_ibm_db2_routenet vpc-network-name Especifica a rede VPC que contém o cluster HA IBM Db2.

Para definir os metadados da instância em uma implementação de rota estática do endereço IP flutuante:

  1. Abra um terminal em uma VM do host ou o Cloud Shell.

    Acessar o Cloud Shell

  2. Para cada instância de VM do host no cluster, especifique os mesmos metadados da implementação de rota do endereço IP flutuante.

    gcloud compute instances add-metadata instance-name \
--metadata sap_ibm_vip_solution=route,sap_ibm_db2_vip=ip-address,\
sap_ibm_db2_routename=route-name,sap_ibm_db2_routenet=vpc-network-name \
--zone instance-zone

Como configurar metadados em uma implementação de endereço IP do alias do endereço IP flutuante

Se você usa uma implementação de endereço IP do alias no endereço IP flutuante, utilize os parâmetros da tabela a seguir e o procedimento posterior para definir os metadados da instância.

Parâmetro Valor Finalidade
sap_ibm_vip_solution alias Indica que esta é uma implantação de uma zona que usa um endereço IP do alias do Google Cloud para suportar a alternância de endereço IP flutuante entre os hosts.
sap_ibm_db2_vip ip-address Especifica o endereço IP flutuante que você reservou na etapa anterior.
sap_ibm_db2_vip_range alias-ip-range-name Opcionalmente, especifica um nome arbitrário para o intervalo de IP do alias. Por exemplo, db2-dh1-vip-alias. O valor padrão é o nome da sub-rede.

Para definir os metadados da instância em uma implementação de IP do alias do endereço IP flutuante:

  1. Abra um terminal em uma VM do host ou o Cloud Shell.

    Acessar o Cloud Shell

  2. Para cada instância de VM do host no cluster, especifique os mesmos metadados da implementação de endereço IP do alias do endereço IP flutuante.

    gcloud compute instances add-metadata instance-name \
--metadata sap_ibm_vip_solution=alias,sap_ibm_db2_vip=ip-address,\
sap_ibm_db2_vip_range=alias-ip-range-name --zone instance-zone

Como analisar ou alterar os metadados da instância

Para analisar os metadados da instância que você definiu, use o seguinte:

gcloud compute instances describe instance-name --zone instance-zone

Se você precisa alterar os metadados personalizados, use o seguinte:

gcloud compute instances add-metadata instance-name --metadata  parm-name=parm-value

Como adicionar nomes de host e endereços IP a /etc/hosts

Durante a configuração do cluster SAP, a ferramenta correspondente valida os nomes de host e os endereços IP internos de cada VM do host e do endereço IP flutuante. Para garantir que a validação seja bem-sucedida, adicione o endereço IP, o nome do host e o nome de DNS interno da VPC de cada VM do host e o endereço IP flutuante ao arquivo /etc/hosts de todas as VMs do host usando o editor que preferir.

Por exemplo, como raiz, siga este exemplo para atualizar /etc/hosts:

echo "#Db2 HA floating IP additions" >> /etc/hosts
echo 10.2.0.24 db2-ha-vip-dh1 db2-ha-vip-dh1.c.solutions-writers.internal >> /etc/hosts
echo 10.1.0.3 db2-ha-s1 db2-ha-s1.us-central1-c.c.db2-ha-project.internal >> /etc/hosts
echo 10.1.0.2 db2-ha-s2 db2-ha-s2.us-central1-f.c.db2-ha-project.internal >> /etc/hosts

No exemplo anterior, a string entre o nome do host e >> em cada linha é o nome de DNS interno da VPC usado por esse serviço.

As VMs do host usam um nome DNS interno zonal, que inclui um campo para a zona. Já o endereço IP flutuante utiliza um nome de DNS interno global, que não inclui um campo de zona.

Para um host de VM, é possível recuperar o nome DNS interno. Basta inserir o comando a seguir em um terminal na VM do host:

curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \
-H "Metadata-Flavor: Google"

Para um endereço IP flutuante, é possível inseri-lo usando o formato a seguir.

vip-host-name.c.project-name.internal

Depois de atualizar o arquivo /etc/hosts, as informações relevantes em /etc/hosts precisam ser iguais ao exemplo a seguir:

#Db2 HA floating IP additions
10.2.0.24 db2-ha-vip-dh1 db2-ha-vip-dh1.c.solutions-writers.internal
10.1.0.3 db2-ha-s1 db2-ha-s1.us-central1-c.c.db2-ha-project.internal
10.1.0.2 db2-ha-s2 db2-ha-s2.us-central1-f.c.db2-ha-project.internal

Como preparar o sistema operacional

Depois de criar a VM, prepare o sistema operacional para o cluster HA IBM Db2.

Os requisitos são definidos pela SAP e IBM. A documentação da SAP exige a instalação de softwares como o Perl e o Korn Shell. Eles podem não estar pré-instalados nas VMs do host do Compute Engine.

Consulte os requisitos mais recentes nos documentos a seguir:

Como instalar o servidor do banco de dados e criar o cluster Db2 HA da IBM

Antes de começar a seguir as instruções em Solução de alta disponibilidade IBM Db2: IBM Tivoli System Automation for Multiplatforms (em inglês) para instalar e configurar o IBM Db2 e o cluster HA, confira a visão geral do procedimento a seguir, prestando atenção especial às observações.

Para instalar o SAP NetWeaver e o servidor primário de aplicativos, consulte a documentação da SAP NetWeaver do Google Cloud e os guias de instalação aplicáveis da SAP disponíveis no portal de ajuda da SAP (em inglês).

As etapas a seguir são uma visão geral do procedimento de instalação. Consulte a documentação da SAP para mais detalhes.

  1. Estabeleça a conectividade SSH baseada em chaves entre as instâncias primária e secundária e cada instância entre si, conforme descrito na documentação da SAP. O SSH é usado pela ferramenta de configuração de cluster da SAP. Teste todas as conexões em cada host. Por exemplo, teste o seguinte em db2-ha-s1:

    • ssh db2-ha-s1
    • ssh db2-ha-s2

  2. Faça o download ou a cópia do conjunto de mídia completo da SAP para o Db2 na sua VM usando o portal de suporte da SAP (em inglês).

  3. Na VM primária do host, use o SAP Software Provisioning Manager (SWPM) para instalar o servidor do banco de dados do IBM Db2.

  4. Na VM secundária do host, configure o banco de dados em espera. Basta usar um método como a cópia de sistema homogênea da SAP.

  5. Em ambas as VMs do host, instale os arquivos de licença do IBM Db2 e do IBM TSAMP. Para mais informações sobre como instalar licenças da IBM recebidas da SAP, consulte a Nota SAP 816773 – DB6: como instalar uma licença do SAP OEM (em inglês).

  6. Em ambas as VMs do host, instale a versão mais recente do TSAMP compatível com a versão do seu banco de dados e sistema operacional.

  7. Na VM primária do host, use a versão mais recente da ferramenta de configuração de cluster da SAP sapdb2cluster.sh para configurar e criar o cluster IBM Db2 HA.

  8. Depois que o cluster é criado, no host primário, use o utilitário de configuração da instância de alta disponibilidade Db2 (db2haicu) para testar se o cluster pode fazer o failover.

    1. Saia da ferramenta de configuração de cluster da SAP e do Korn Shell.

    2. Na instância principal, confirme se o servidor de banco de dados primário está on-line.

      lssam

      No exemplo a seguir, extraído da saída lssam, a instância de banco de dados primária está on-line:

      Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2

    3. Mude para o usuário da instância do banco de dados.

      sudo su - db2sid

    4. Inicie o utilitário do db2haicu.

      db2haicusid

    5. Na interface do db2haicu, selecione a opção 5 e siga as orientações.

    6. Saia do utilitário do db2haicu.

    7. No host primário, verifique se o secundário está on-line agora.

      lssam

      No trecho de exemplo a seguir extraído da saída lssam, a instância de banco de dados secundária está on-line:

      Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2

Para concluir a configuração do cluster, siga as instruções na próxima seção para criar um recurso TSAMP personalizado no endereço IP flutuante e associá-lo ao TSAMP com o recurso de instância do IBM Db2.

Como criar um recurso personalizado do TSAMP no endereço IP flutuante

Para permitir que o TSAMP gerencie o endereço IP flutuante, você precisa criar um recurso personalizado do TSAMP para ele. Para permitir que o TSAMP interaja com o Google Cloud ao gerenciar o recurso de endereço IP flutuante, é necessário fazer o download e a configuração de um script auxiliar no Google Cloud.

Fazer o download do script auxiliar do Google Cloud

Em cada host no cluster, faça o download do script auxiliar do Google Cloud e defina as permissões dele.

  1. Nos hosts primário e em espera, como o usuário raiz do diretório /root na VM principal, faça o download do script.

    Para instâncias que não usam uma configuração de VPC compartilhada: 

    wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_db2/utility/gcp_floating_ip.sh -O gcp_floating_ip.sh
     Para instâncias que usam uma configuração de VPC compartilhada: 
    wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_db2/utility/gcp_floating_ip_svpc.sh -O gcp_floating_ip.sh

  2. Em ambos os hosts, defina as permissões no script.

    chmod 744 gcp_floating_ip.sh

Criar e configurar um recurso personalizado do TSAMP no endereço IP flutuante

Em qualquer host do cluster, crie e configure recursos personalizados do TSAMP no endereço IP flutuante.

  1. Em qualquer host, use o método que preferir para criar um arquivo de configuração denominado cluster_res.conf. Depois, cole nele o texto visto a seguir após atualizar o parâmetro NodeNameList com os nomes de host.

    PersistentResourceAttributes::
  Name="gcp_floating_ip-rs"
  ResourceType=1
  StartCommand="/root/gcp_floating_ip.sh start"
  StopCommand="/root/gcp_floating_ip.sh stop"
  MonitorCommand="/root/gcp_floating_ip.sh status"
  MonitorCommandPeriod=30
  MonitorCommandTimeout=30
  StartCommandTimeout=600
  StopCommandTimeout=600
  UserName="root"
  RunCommandsSync=1
  ProtectionMode=0
  NodeNameList={"host-1","host-2"}

  2. No host primário, como usuário raiz, crie o recurso personalizado do TSAMP com os comandos a seguir.

    export CT_MANAGEMENT_SCOPE=2
mkrsrc -f cluster_res.conf IBM.Application
mkrg -l None gcp_floating_ip-rg
chrg -o Online gcp_floating_ip-rg
addrgmbr -g gcp_floating_ip-rg -m F IBM.Application:gcp_floating_ip-rs
rgreq -o start gcp_floating_ip-rg

  3. No host primário, como usuário raiz, confirme se o recurso da instância Db2 on-line está no mesmo host que o recurso do IP flutuante on-line.

    lssam

    Na saída, os recursos on-line precisam estar todos nas mesmas VMs do host:

    Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2
Online IBM.ResourceGroup:gcp_floating_ip.sh_rg Nominal=Online
        '- Online IBM.Application:gcp_floating_ip.sh_rs
                |- Online IBM.Application:gcp_floating_ip.sh_rs:db2-ha-s1
                '- Offline IBM.Application:gcp_floating_ip.sh_rs:db2-ha-s2

    Se o recurso de endereço IP flutuante não estiver on-line no mesmo host que a instância do banco de dados, migre esse recurso.

    rgreq -o move -n host-to-move-from gcp_floating_ip-rg

  4. Como usuário raiz no host primário, estabeleça uma relação no TSAMP entre o recurso de instância do banco de dados e o de endereço IP flutuante.

    rgreq -o lock gcp_floating_ip-rg
rgreq -o lock db2_db2sid_db2sid_SID-rg
mkrel -o NoCondition -p Collocated \
  -S IBM.Application:gcp_floating_ip-rs -G IBM.Application:db2_db2sid_db2sid_SID-rs \
  db2hadr_colo_gcp_floating_ip
rgreq -o unlock db2_db2sid_db2sid_SID-rg
rgreq -o unlock gcp_floating_ip-rg

    Depois de estabelecer a relação entre o recurso da instância do banco de dados e o de endereço IP flutuante, teste o failover novamente, conforme descrito na próxima seção.

Como verificar a implantação do cluster HA Db2 para SAP no Google Cloud

Para confirmar que o cluster HA IBM Db2 foi configurado corretamente, acione um failover e verifique se todos os recursos on-line são migrados de uma VM do host para outra.

Para executar um teste de failover:

  1. No host primário, como usuário raiz, anote em qual VM do host os recursos on-line estão no momento.

    lssam

  2. No host primário, mude para o usuário da instância Db2.

    sudo su - db2sid

  3. Inicie o utilitário do db2haicu.

    db2haicu

  4. Na interface do utilitário do db2haicu, selecione a opção 5 e siga as orientações para acionar um failover.

  5. Após o término do processamento do db2haicu, saia do utilitário.

  6. Mude para o usuário raiz.

    sudo su -

  7. Confirme se os recursos on-line foram migrados para a outra VM do host.

Validar a instalação do agente do Google Cloud para SAP

Depois de implantar uma VM e instalar o sistema SAP, confirme se o agente do Google Cloud para SAP está funcionando corretamente.

Verificar se o agente do Google Cloud para SAP está em execução

Para verificar se o agente está em execução, siga estas etapas:

  1. Estabeleça uma conexão SSH com a instância de VM do host.

  2. Execute este comando: 

    systemctl status google-cloud-sap-agent

    Se o agente estiver funcionando corretamente, a saída conterá active (running). Por exemplo: 

    google-cloud-sap-agent.service - Google Cloud Agent for SAP
Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled)
Active:  active (running)  since Fri 2022-12-02 07:21:42 UTC; 4 days ago
Main PID: 1337673 (google-cloud-sa)
Tasks: 9 (limit: 100427)
Memory: 22.4 M (max: 1.0G limit: 1.0G)
CGroup: /system.slice/google-cloud-sap-agent.service
       └─1337673 /usr/bin/google-cloud-sap-agent

Se o agente não estiver em execução, reinicie-o.

Verificar se o SAP Host Agent está recebendo métricas

Para verificar se as métricas de infraestrutura são coletadas pelo agente do Google Cloud para SAP e enviadas corretamente ao agente de host da SAP, siga estas etapas:

  1. No sistema SAP, insira a transação ST06.

  2. No painel de visão geral, verifique a disponibilidade e o conteúdo dos seguintes campos para a configuração completa da infraestrutura de monitoramento da SAP e do Google:

    • Provedor de nuvem: Google Cloud Platform
    • Acesso ao monitoramento avançado: TRUE
    • Detalhes do monitoramento avançado: ACTIVE

Como realizar tarefas de pós-implantação

Antes de usar o sistema de IBM Db2 de alta disponibilidade no Google Cloud, recomendamos que você conclua todas as atividades pós-instalação documentadas em Solução IBM Db2 de alta disponibilidade: IBM Tivoli System Automation for Multiplatforms (em inglês), incluindo:

  1. Validar o cluster do banco de dados

  2. Fazer o backup da política principal do TSAMP

  3. Atualizar os pacotes de correção do banco de dados

  4. Atualizar conexões de cliente do Db2 para usar o nome do host e o endereço IP do tipo flutuante. Por exemplo, atualize o arquivo db2cli.ini nos servidores de aplicativos do SAP ABAP.

Se você estiver usando um gateway NAT com o cluster HA DB2, conclua a configuração do gateway NAT, conforme descrito na sessão Como concluir a instalação do gateway NAT do guia de implantação do IBM Db2 para SAP.