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. Veja 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
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
Para abrir o editor de código, clique no ícone de lápis (edit) no canto superior direito da janela do terminal do Cloud Shell.
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
.Para abrir o
template_ha.yaml
no editor de código, clique duas vezes nele.Defina as VMs e os discos permanentes no arquivo
template_ha.yaml
. O arquivotemplate_ha.yaml
contém duas seções:sap_db2_primary
esap_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
eotherHost
, 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çãotype
que está ativa por padrão especifica a versão do modelo comolatest
. A especificaçãotype
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
oufamily/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
oususe-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
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
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
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
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
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
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
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
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
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
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://
ougs://
. 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 VMn1-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 como0
.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
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
No console do Google Cloud, abra o Cloud Logging para monitorar o progresso da instalação e verificar se há erros.
Filtre os registros:
Explorador de registros
Na página Explorador de registros, acesse o painel Consulta.
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"
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.
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:
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.
Na página Implantações do Deployment Manager, exclua a implantação para limpar as VMs e discos permanentes da instalação com falha.
Execute a implantação novamente.
- Se
Verificar a configuração da VM
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.Mude para o usuário raiz.
sudo su -
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:
- Corrija o erro.
- Na página Implantações, exclua a implantação para limpar as VMs e os discos permanentes da instalação que falhou.
- 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:
Abra um terminal em uma VM do host ou o Cloud Shell.
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.
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:
Abra um terminal em uma VM do host ou o Cloud Shell.
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:
Abra um terminal em uma VM do host ou o Cloud Shell.
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:
Solução de alta disponibilidade IBM Db2: IBM Tivoli System Automation for Multiplatforms (em inglês)
1984787 – SUSE LINUX Enterprise Server 12: notas de instalação
2002167 – Red Hat Enterprise Linux 7.x: instalação e upgrade
Como instalar o servidor do banco de dados e criar o cluster HA IBM Db2
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.
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
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).
Na VM primária do host, use o SAP Software Provisioning Manager (SWPM) para instalar o servidor do banco de dados do IBM Db2.
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.
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).
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.
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.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.
Saia da ferramenta de configuração de cluster da SAP e do Korn Shell.
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
Mude para o usuário da instância do banco de dados.
sudo su - db2sid
Inicie o utilitário do db2haicu.
db2haicusid
Na interface do db2haicu, selecione a opção 5 e siga as orientações.
Saia do utilitário do db2haicu.
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.
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.wget https://storage.googleapis.com/sapdeploy/gceTSAMP/gcp_floating_ip.sh
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.
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"}
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
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
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:
No host primário, como usuário raiz, anote em qual VM do host os recursos on-line estão no momento.
lssam
No host primário, mude para o usuário da instância Db2.
sudo su - db2sid
Inicie o utilitário do db2haicu.
db2haicu
Na interface do utilitário do db2haicu, selecione a opção 5 e siga as orientações para acionar um failover.
Após o término do processamento do db2haicu, saia do utilitário.
Mude para o usuário raiz.
sudo su -
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:
Estabeleça uma conexão SSH com a instância da VM do host.
Execute este comando:
systemctl status google-cloud-sap-agent
Se o agente estiver funcionando corretamente, a saída conterá
active (running)
. 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:
- No sistema SAP, insira a transação
ST06
. 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
- Provedor de nuvem:
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:
Validar o cluster do banco de dados
Fazer o backup da política principal do TSAMP
Atualizar os pacotes de correção do banco de dados
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 nesta seção do guia de implantação do IBM Db2 para SAP.