Neste guia, você verá como implantar e configurar um cluster de alta disponibilidade (HA, na sigla em inglês) do SUSE Linux Enterprise Server (SLES) para um sistema SAP HANA de escalonamento horizontal no Google Cloud.
Este guia inclui as etapas de:
- Como configurar um balanceador de carga de rede de passagem interno para redirecionar o tráfego em caso de falha
- Como configurar um cluster do Pacemaker no SLES para gerenciar os sistemas SAP e outros recursos durante um failover
Este guia também inclui etapas para configurar a replicação do sistema SAP HANA, mas consulte a documentação da SAP para ver as instruções definitivas.
Para implantar um sistema SAP HANA sem um cluster de alta disponibilidade do Linux ou um host de nó em espera, use o guia de implantação do SAP HANA.
Este guia é destinado a usuários avançados do SAP HANA familiarizados com as configurações de alta disponibilidade do Linux para SAP HANA.
O sistema que este guia implanta
Seguindo este guia, você implantará um sistema de alta disponibilidade do SAP HANA de vários nós configurado para redundância total da zona com uma instância adicional que atua como fabricante majoritário, também conhecido como nó desempatador. Isso garante que o quórum do cluster seja mantido em caso de perda de uma zona.
A implantação final é composta pelos seguintes recursos:
- Um localprimário e secundário onde cada instância tem uma contraparte zonal.
- Dois locais configurados para replicação síncrona.
- Uma única instância de computação que atua como fabricante majoritário.
- Um gerenciador de recursos de cluster de alta disponibilidade do Pacemaker com um mecanismo de isolamento.
- Discos permanentes para dados e volumes de registro do SAP HANA anexados a cada instância do SAP HANA.
Neste guia, você usa os modelos do Terraform fornecidos pelo Google Cloud para implantar as máquinas virtuais (VMs) do Compute Engine e as instâncias do SAP HANA, garantindo que as VMs e os sistemas SAP HANA de base atendam aos requisitos de compatibilidade da SAP e as práticas recomendadas atuais.
O SAP HANA Studio é usado neste guia para testar a replicação do sistema SAP HANA. Se preferir, use o SAP HANA Cockpit. Para informações sobre como instalar o SAP HANA Studio, consulte:
- Como instalar o SAP HANA Studio em uma VM do Windows do Compute Engine
- Guia de instalação e atualização do SAP HANA Studio
Pré-requisitos
Antes de criar o cluster de alta disponibilidade do SAP HANA, verifique se os pré-requisitos a seguir são atendidos:
- Você leu o Guia de planejamento do SAP HANA e o Guia de planejamento de alta disponibilidade do SAP HANA.
- Você ou sua organização tem uma conta do Google Cloud e criou um projeto para a implantação do SAP HANA. Para informações sobre como criar contas e projetos do Google Cloud, consulte Como configurar sua Conta do Google no Guia de implantação do SAP HANA.
- 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.
A mídia de instalação do SAP HANA está armazenada em um bucket do Cloud Storage disponível no projeto e na região de implantação. Para mais informações sobre como fazer upload da mídia de instalação do SAP HANA em um bucket do Cloud Storage, consulte Como fazer o download do SAP HANA no Guia de implantação do SAP HANA.
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 é ativado, as configurações de chave SSH baseadas em metadados são desativadas e a implantação falha. Após a conclusão da implantação, ative o login do SO novamente.
Veja mais informações em:
Se você estiver usando o DNS interno da VPC, o valor da variável
vmDnsSetting
nos metadados do projeto precisará serGlobalOnly
ouZonalPreferred
para ativar a resolução dos nomes de nó nas zonas. A configuração padrão devmDnsSetting
éZonalOnly
. Para mais informações, consulte estes tópicos:Você tem uma solução de NFS, como a Filestore gerenciada, para compartilhar os volumes
/hana/shared
e/hanabackup
do SAP HANA entre os hosts no sistema de escalonamento horizontal SAP HANA. Para implantar servidores NFS do Filestore, veja Como criar instâncias.- Os sites principal e secundário precisam ter acesso aos próprios caminhos NFS dedicados para evitar a substituição de dados. Para usar uma única instância do Filestore, configure a implantação para usar subdiretórios distintos como caminho de montagem.
Como criar uma rede
Por motivos de segurança, crie uma nova rede. Para controlar quem tem acesso a ela, adicione regras de firewall ou use outro método de controle de acesso.
Caso o projeto tenha uma rede VPC padrão, não a use. Em vez disso, crie sua própria rede VPC para que as únicas regras de firewall aplicadas sejam aquelas criadas explicitamente por você.
Durante a implantação, as instâncias de VM normalmente exigem acesso à Internet para fazer o download do agente do Google Cloud para SAP. Se você estiver usando uma das imagens Linux certificadas pelo SAP disponíveis no Google Cloud, a instância da VM também exigirá acesso à Internet para registrar a licença e acessar repositórios de fornecedor do sistema operacional. Uma configuração com um gateway NAT e tags de rede da VM é compatível com esse acesso, mesmo se as VMs de destino não tiverem IPs externos.
Para configurar a rede:
Console
- No Console do Google Cloud, acesse a página Redes VPC.
- Clique em Criar rede VPC.
- Digite um Nome para a rede.
O nome precisa seguir a convenção de nomenclatura. As redes VPC usam a convenção de nomenclatura do Compute Engine.
- Em Modo de criação da sub-rede, escolha Custom.
- Na seção Nova sub-rede, especifique os parâmetros de configuração a seguir para uma sub-rede:
- Insira um Nome para a sub-rede.
- Em Região, selecione a região do Compute Engine em que você quer criar a sub-rede.
- Em Tipo de pilha de IP, selecione IPv4 (pilha única) e insira um intervalo
de endereços IP no
formato CIDR. ,
como
10.1.0.0/24
.Esse é o intervalo principal de IPv4 da sub-rede. Se você planeja adicionar mais de uma sub-rede, atribua intervalos IP CIDR não sobrepostos para cada sub-rede na rede. Observe que cada sub-rede e os respectivos intervalos IP internos são mapeados para uma única região.
- Clique em Concluído.
- Para adicionar mais sub-redes, clique em Adicionar sub-rede e repita as etapas anteriores. É possível adicionar mais sub-redes à rede depois de criá-la.
- Clique em Criar.
gcloud
- Acesse o Cloud Shell.
- Para criar uma nova rede no modo de sub-redes personalizadas, execute:
gcloud compute networks create NETWORK_NAME --subnet-mode custom
Substitua
NETWORK_NAME
pelo nome da nova rede. O nome precisa seguir a convenção de nomenclatura. As redes VPC usam a convenção de nomenclatura do Compute Engine.Especifique
--subnet-mode custom
para evitar o uso do modo automático padrão, que cria automaticamente uma sub-rede em cada região do Compute Engine. Para mais informações, consulte Modo de criação da sub-rede. - Crie uma sub-rede e especifique a região e o intervalo de IP:
gcloud compute networks subnets create SUBNETWORK_NAME \ --network NETWORK_NAME --region REGION --range RANGE
Substitua:
SUBNETWORK_NAME
: o nome da nova sub-rede.NETWORK_NAME
: o nome da rede que você criou na etapa anterior;REGION
: a região em que você quer a sub-rede;RANGE
: o intervalo de endereços IP, especificado no formato CIDR. Por exemplo,10.1.0.0/24
Se você planeja adicionar mais de uma sub-rede, atribua intervalos IP CIDR não sobrepostos para cada sub-rede na rede. Observe que cada sub-rede e os respectivos intervalos IP internos são mapeados para uma única região.
- Se quiser, repita o passo anterior e adicione mais sub-redes.
Como configurar um gateway NAT
Se você precisar criar uma ou mais VMs sem endereços IP públicos, será necessário usar a conversão de endereços de rede (NAT) para permitir que as VMs acessem a Internet. Use o Cloud NAT, um serviço gerenciado distribuído e definido pelo software do Google Cloud que permite que as VMs enviem pacotes de saída para a Internet e recebam todos os pacotes de resposta de entrada estabelecidos. Se preferir, é possível configurar uma VM separada como um gateway NAT.
Para criar uma instância do Cloud NAT para seu projeto, consulte Como usar o Cloud NAT.
Depois de configurar o Cloud NAT para seu projeto, as instâncias de VM poderão acessar a Internet com segurança sem um endereço IP público.
Como adicionar regras de firewall
Por padrão, uma regra de firewall implícita bloqueia conexões de entrada de fora da rede de nuvem privada virtual (VPC). Para permitir conexões de entrada, configure uma regra de firewall para sua VM. Depois que uma conexão de entrada for estabelecida com uma VM, será permitido o tráfego nas duas direções nessa conexão.
Também é possível criar uma regra de firewall para permitir o acesso externo a portas especificadas
ou para restringir o acesso entre as VMs na mesma rede. Se o tipo de rede VPC default
for usado, algumas regras padrão complementares também serão aplicadas, como a regra default-allow-internal
, que permite a conectividade entre VMs na mesma rede em todas as portas.
Dependendo da política de TI que for aplicada ao ambiente, pode ser necessário isolar ou então restringir a conectividade com o host do banco de dados, o que pode ser feito criando regras de firewall.
Dependendo do seu cenário, é possível criar regras de firewall para permitir o acesso para estes itens:
- Portas padrão do SAP listadas no TCP/IP de Todos os Produtos SAP.
- Conexões do seu computador ou do ambiente de rede corporativa para a instância de VM do Compute Engine. Se você não tiver certeza do endereço IP a ser usado, fale com o administrador de redes da sua empresa.
Para criar uma regra de firewall:
Console
No console do Google Cloud, acesse a página Firewall do Compute Engine.
Na parte superior da página, clique em Criar regra de firewall.
- No campo Rede, selecione a rede em que a VM está localizada.
- No campo Destinos, especifique os recursos no Google Cloud a que esta regra se aplica. Por exemplo, especifique Todas as instâncias na rede. Ou, para limitar a regra a instâncias específicas no Google Cloud, insira tags em Tags de destino especificado.
- No campo Filtro de origem, selecione uma das opções a seguir:
- Intervalos de IP para permitir tráfego de entrada de endereços IP específicos. Especifique o intervalo de endereços IP no campo Intervalos de IPs de origem.
- Sub-redes para permitir tráfego de entrada de uma determinada sub-rede. Especifique o nome da sub-rede no campo Sub-redes a seguir. É possível usar esta opção para permitir acesso entre as VMs na configuração em três níveis ou de escalonamento horizontal.
- Na seção Protocolos e portas, selecione Portas e protocolos especificados e insira
tcp:PORT_NUMBER
.
Clique em Criar para criar a regra de firewall.
gcloud
Crie uma regra de firewall usando o seguinte comando:
$
gcloud compute firewall-rules create firewall-name
--direction=INGRESS --priority=1000 \
--network=network-name --action=ALLOW --rules=protocol:port \
--source-ranges ip-range --target-tags=network-tags
Como implantar as VMs e o SAP HANA
Para implantar um sistema de alta disponibilidade do SAP HANA com vários nós configurado para redundância total de zona, use o modelo do Cloud Deployment Manager para SAP HANA como base para a configuração, bem como um modelo adicional para implantar uma instância do fabricante majoritário.
A implantação consiste no seguinte:
- Dois sistemas SAP HANA correspondentes, cada um com dois ou mais nós de trabalho.
- Uma única instância do fabricante majoritário, também conhecida como nó desempatador, garante que o quórum de clusters seja mantido em caso de perda de uma zona.
Adicione a definição de todos os sistemas ao mesmo arquivo YAML para que o Deployment Manager implante todos os recursos em uma única implantação. Depois que os sistemas SAP HANA e a instância do fabricante majoritário forem implantados, defina e configure o cluster de alta disponibilidade.
As instruções a seguir são para o Cloud Shell, mas, no geral, se aplicam à Google Cloud CLI.
Confirme se as cotas atuais para recursos, como discos permanentes e CPUs, são suficientes para os sistemas SAP HANA que você está prestes a instalar. Se as cotas não forem suficientes, a implantação falhará. Para saber os requisitos de cotas do SAP HANA, consulte Considerações sobre preços e cotas para SAP HANA.
Abra o Cloud Shell ou, se tiver instalado a CLI gcloud na estação de trabalho local, abra um terminal.
Faça o download do modelo do arquivo de configuração
template.yaml
do cluster de alta disponibilidade do SAP HANA para o diretório de trabalho usando o seguinte comando no Cloud Shell ou no CLI gcloud:wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/template.yaml
Você tem a opção de renomear o arquivo
template.yaml
para identificar a configuração que ele define.Abra o arquivo
template.yaml
no editor de código do Cloud Shell ou, se estiver usando o gcloud, o editor de texto de sua escolha.Para abrir o editor de código, clique no ícone de lápis, no canto superior direito da janela do terminal do Cloud Shell.
No arquivo
template.yaml
, conclua a definição do sistema SAP HANA principal. Especifique os valores da propriedade substituindo os colchetes e o conteúdo pelos valores da instalação. As propriedades estão descritas na tabela a seguir.Para criar as instâncias de VM sem instalar o SAP HANA, exclua ou comente todas as linhas que começam com
sap_hana_
.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 que está sendo definida no momento. Especifique nomes diferentes nas definições de VM principal e secundária. Os nomes precisam ser especificados em letras minúsculas, números ou hífens. instanceType
String O tipo de máquina virtual do Compute Engine em que é necessário executar o SAP HANA. Se você precisar de um tipo de VM personalizado, especifique um tipo de VM predefinido com um número de vCPUs o mais próximo possível do necessário, mesmo que maior. Após a conclusão da implantação, modificar o número de vCPUs e a quantidade de memória O instanceType
mínimo recomendado para o fabricante majoritário én1-standard-2
ou o equivalente a pelo menos dois núcleos de CPU e 2 GB de memória.zone
String A zona do Google Cloud em que a instância da VM que você está definindo será implantada. Especifique zonas diferentes na mesma região para as definições de instância principal do HANA, secundária do HANA e do fabricante majoritário. As zonas precisam estar na mesma região selecionada para a sub-rede. subnetwork
String Nome da sub-rede criado em uma etapa anterior. Se estiver implantando em uma VPC compartilhada, especifique esse valor como [SHAREDVPC_PROJECT]/[SUBNETWORK]
. Por exemplo,myproject/network1
.linuxImage
String Nome da imagem do sistema operacional Linux ou da família de imagens que você está usando com o SAP HANA. Para especificar uma família de imagens, adicione o prefixo family/
ao nome da família. Por exemplo,family/sles-15-sp1-sap
. Para definir uma imagem específica, determine somente o nome da imagem. Para ver a lista de imagens e famílias disponíveis, consulte a página Imagens no Console do Google Cloud.linuxImageProject
String O projeto do Google Cloud que contém a imagem que você usará. Ele pode ser o próprio projeto ou um projeto de imagem do Google Cloud, como suse-sap-cloud
. Para mais informações sobre projetos de imagem do Google Cloud, consulte a página Imagens na documentação do Compute Engine.sap_hana_deployment_bucket
String Nome do bucket de armazenamento do Google Cloud no projeto que contém os arquivos de instalação e revisão do SAP HANA enviados em uma etapa anterior. Todos os arquivos de revisão de upgrade no bucket são aplicados ao SAP HANA durante o processo de implantação. sap_hana_sid
String O ID do sistema (SID, na sigla em inglês) do SAP HANA. O ID precisa ter três caracteres alfanuméricos e começar com uma letra. Todas as letras precisam ser maiúsculas. sap_hana_instance_number
Inteiro Número da instância, 0 a 99, do sistema SAP HANA. O padrão é 0. sap_hana_sidadm_password
String A senha do administrador do sistema operacional (SO). As senhas precisam ter no mínimo oito caracteres e incluir pelo menos uma letra maiúscula, uma letra minúscula e um número. sap_hana_system_password
String A senha do superusuário do banco de dados. As senhas precisam ter pelo menos oito caracteres e incluir pelo menos uma letra maiúscula, uma letra minúscula e um número. sap_hana_sidadm_uid
Inteiro O valor padrão do ID do usuário SID_LCadm
é900
para evitar que grupos criados por usuários entrem em conflito com o SAP HANA. É possível alterar para um valor diferente, se necessário.sap_hana_sapsys_gid
Inteiro O ID de grupo padrão do sapsys é 79
. Ao especificar um valor acima, é possível substituir esse valor pelos seus requisitos.sap_hana_scaleout_nodes
Inteiro Especifique 1
ou maior.sap_hana_shared_nfs
String Ponto de montagem do NFS para o volume /hana/shared
. Por exemplo,10.151.91.122:/hana_shared_nfs
.sap_hana_backup_nfs
String Ponto de montagem do NFS para o volume /hanabackup
. Por exemplo,10.216.41.122:/hana_backup_nfs
.networkTag
String 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 inserir uma tag de rede, forneça outro meio de acesso à Internet.nic_type
String Opcional, mas recomendado se disponível para a máquina de destino e a versão do SO. Especifica a interface de rede a ser usada com a instância de VM. É possível especificar o valor GVNIC
ouVIRTIO_NET
. Para usar uma NIC virtual do Google (gVNIC), especifique uma imagem do SO compatível com gVNIC como o valor da propriedadelinuxImage
. Confira a lista de imagens do SO em Detalhes do sistema operacional.Se você não especificar um valor para essa propriedade, a interface de rede será selecionada automaticamente com base no tipo de máquina especificado para a propriedade
Esse argumento está disponível nas versõesinstanceType
.202302060649
ou posteriores do modelo do Deployment Manager.publicIP
Booleano Opcional. Determina se um endereço IP público é adicionado à instância da VM. O padrão é Yes
.serviceAccount
String Opcional. Especifica uma conta de serviço a ser usada pelas VMs de host e pelos programas executados nas VMs de host. Especifique o endereço de e-mail da conta de serviço. Por exemplo, svc-acct-name@project-id.iam.gserviceaccount.com. Por padrão, a conta de serviço padrão do Compute Engine é usada. Para mais informações, consulte Gerenciamento de identidade e acesso para programas SAP no Google Cloud. Crie a definição do sistema SAP HANA secundário, copiando a definição do sistema SAP HANA principal e colando a cópia após a definição do sistema SAP HANA principal. Veja o exemplo seguindo estas etapas.
Na definição do sistema SAP HANA secundário, especifique valores para as propriedades a seguir diferentes daqueles definidos na definição do sistema SAP HANA principal:
name
instanceName
zone
Faça o download do arquivo de configuração
sap_majoritymaker.yaml
do fabricante majoritário:wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/template.yaml -O sap_majoritymaker.yaml
Copie e cole a especificação YAML do arquivo
sap_majoritymaker.yaml
, começando na linha no 6 e abaixo, na parte de baixo do arquivotemplate.yaml
do SAP HANA.Complete a definição da instância do fabricante majoritário:
- Especifique um
zone
diferente dos dois sistemas SAP HANA. - O mínimo recomendado de
instanceType
én1-standard-2
ou o equivalente a pelo menos 2 núcleos de CPU e 2 GB de memória.
Agora você tem três recursos listados no arquivo YAML, dois clusters do SAP HANA e uma instância do fabricante majoritário, além das propriedades configuráveis.
- Especifique um
Crie as instâncias:
gcloud deployment-manager deployments create DEPLOYMENT_NAME --config TEMPLATE_NAME.yaml
O comando acima invoca o Deployment Manager, que implanta as VMs, faz o download do software do SAP HANA do bucket de armazenamento e instala o SAP HANA de acordo com as especificações do arquivo
template.yaml
.O processamento da implantação consiste em dois estágios. Na primeira etapa, o Deployment Manager grava o status no console. Na segunda etapa, os scripts de implantação gravam o status no Cloud Logging.
Exemplo de um arquivo de configuração template.yaml
completo
O exemplo a seguir mostra um arquivo de configuração template.yaml
completo,
que implanta dois clusters de escalonamento horizontal com um sistema SAP HANA instalado
e uma única instância de VM que funciona como o fabricante majoritário.
O arquivo contém as definições de dois recursos a serem implantados:
sap_hana_primary
e sap_hana_secondary
. Cada definição de recurso
contém as definições de uma VM e uma instância do SAP HANA.
A definição do recurso sap_hana_secondary
foi criada copiando e colando
a primeira definição e, em seguida, modificando os valores das propriedades name
,
instanceName
e zone
. Todos os outros valores de propriedade nas
duas definições de recursos são iguais.
As propriedades networkTag
, serviceAccount
, sap_hana_sidadm_uid
e
sap_hana_sapsys_gid
são da seção Opções avançadas do
modelo de arquivo de configuração. As propriedades sap_hana_sidadm_uid
e
sap_hana_sapsys_gid
são incluídas para mostrar os valores padrão, que são usados
porque as propriedades são comentadas.
resources: - name: sap_hana_primary type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.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/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py # properties: instanceName: hana-ha-vm-1 instanceType: n2-highmem-32 zone: us-central1-a subnetwork: example-subnet-us-central1 linuxImage: family/sles-15-sp1-sap linuxImageProject: suse-sap-cloud sap_hana_deployment_bucket: hana2-sp4-rev46 sap_hana_sid: HA1 sap_hana_instance_number: 22 sap_hana_sidadm_password: Tempa55word sap_hana_system_password: Tempa55word sap_hana_scaleout_nodes: 2 sap_hana_shared_nfs: 10.151.91.123:/hana_shared_nfs sap_hana_backup_nfs: 10.216.41.123:/hana_backup_nfs networkTag: cluster-ntwk-tag serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com # sap_hana_sidadm_uid: 900 # sap_hana_sapsys_gid: 79 - name: sap_hana_secondary type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.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/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py # properties: instanceName: hana-ha-vm-2 instanceType: n2-highmem-32 zone: us-central1-c subnetwork: example-subnet-us-central1 linuxImage: family/sles-15-sp1-sap linuxImageProject: suse-sap-cloud sap_hana_deployment_bucket: hana2-sp4-rev46 sap_hana_sid: HA1 sap_hana_instance_number: 22 sap_hana_sidadm_password: Google123 sap_hana_system_password: Google123 sap_hana_scaleout_nodes: 2 sap_hana_shared_nfs: 10.141.91.124:/hana_shared_nfs sap_hana_backup_nfs: 10.106.41.124:/hana_backup_nfs networkTag: cluster-ntwk-tag serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com # sap_hana_sidadm_uid: 900 # sap_hana_sapsys_gid: 79 - name: sap_majoritymaker type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/sap_majoritymaker.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/202208181245/dm-templates/sap_majoritymaker/sap_majoritymaker.py properties: instanceName: sap-majoritymaker instanceType: n1-standard-2 zone: us-central1-b subnetwork: example-subnet-us-central1 linuxImage: family/sles-15-sp1-sap linuxImageProject: suse-sap-cloud publicIP: No
Criar regras de firewall que permitam acesso às VMs do host
Se ainda não tiver feito isso, crie regras de firewall que permitam acesso a cada VM do host das seguintes origens:
- Para fins de configuração, sua estação de trabalho local, um Bastion Host ou um servidor do Jump
- Para acesso entre os nós do cluster, as outras VMs de host no cluster de alta disponibilidade
Ao criar regras de firewall da VPC, especifique as tags de
rede definidas no arquivo de configuração template.yaml
para designar
as VMs do host como destino da regra.
Para verificar a implantação, defina uma regra para permitir conexões SSH na porta 22 de um Bastion Host ou da estação de trabalho local.
Para acesso entre os nós do cluster, adicione uma regra de firewall que permita todos os tipos de conexão em qualquer porta de outras VMs na mesma sub-rede.
Certifique-se de que as regras de firewall para verificar a implantação e a comunicação dentro do cluster sejam criadas antes de prosseguir para a próxima seção. Para instruções, consulte Como adicionar regras de firewall.
Como verificar a implantação das VMs e do SAP HANA
Para verificar a implantação, verifique os registros de implantação no Cloud Logging e verifique os discos e serviços nas VMs dos hosts principal e secundário.
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 SAP HANA listados no Guia de planejamento do SAP HANA.
Na página Implantaçõesdo 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 o status de implantação do fabricante majoritário
Use o comando a seguir para verificar o status de implantação do fabricante majoritário.
gcloud compute instances describe MAJORITY_MAKER_HOSTNAME --zone MAJORITY_MAKER_ZONE --format="table[box,title='Deployment Status'](name:label=Instance_Name,metadata.items.status:label=Status)"
Se o status Complete
for exibido, o processamento da implantação
será bem-sucedido para a instância do fabricante majoritário.
Para uma implantação em andamento, o status de <blank>
é exibido.
Verificar a configuração das VMs e do SAP HANA
Depois de implantar o sistema SAP HANA sem erros, conecte-se a cada VM usando SSH. Na página Instâncias de VM do Compute Engine, clique no botão "SSH" para cada instância de VM ou use seu método de SSH preferido.
Mude para o usuário raiz.
$
sudo su -No prompt de comando, insira
df -h
. Em cada VM, verifique se você vê os diretórios/hana
, como/hana/data
.Filesystem Size Used Avail Use% Mounted on /dev/sda2 30G 4.0G 26G 14% / devtmpfs 126G 0 126G 0% /dev tmpfs 126G 0 126G 0% /dev/shm tmpfs 126G 17M 126G 1% /run tmpfs 126G 0 126G 0% /sys/fs/cgroup /dev/sda1 200M 9.7M 191M 5% /boot/efi /dev/mapper/vg_hana-shared 251G 49G 203G 20% /hana/shared /dev/mapper/vg_hana-sap 32G 240M 32G 1% /usr/sap /dev/mapper/vg_hana-data 426G 7.0G 419G 2% /hana/data /dev/mapper/vg_hana-log 125G 4.2G 121G 4% /hana/log /dev/mapper/vg_hanabackup-backup 512G 33M 512G 1% /hanabackup tmpfs 26G 0 26G 0% /run/user/900 tmpfs 26G 0 26G 0% /run/user/899 tmpfs 26G 0 26G 0% /run/user/1000
Altere para o usuário administrador do SAP substituindo
SID_LC
no comando a seguir pelo ID do sistema especificado no modelo do arquivo de configuração. Use letras minúsculas para letras.#
su - SID_LCadmPara verificar se os serviços do SAP HANA, como
hdbnameserver
,hdbindexserver
e outros, estão sendo executados na instância, digite o seguinte comando:>
HDB infoSe você estiver usando o RHEL for SAP 9.0 ou posterior, verifique se os pacotes
chkconfig
ecompat-openssl11
estão instalados na instância de VM.Para mais informações da SAP, consulte a Nota SAP 3108316 – Red Hat Enterprise Linux 9.x: instalação e configuração .
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:
Configurar o monitoramento para o SAP HANA
Como opção, monitore as instâncias do SAP HANA usando o agente do Google Cloud para SAP. A partir da versão 2.0, é possível configurar o agente para coletar as métricas de monitoramento do SAP HANA e enviá-las para o Cloud Monitoring. O Cloud Monitoring permite criar painéis para visualizar essas métricas, configurar alertas com base em limites de métrica e muito mais.
Para mais informações sobre a coleta de métricas de monitoramento do SAP HANA usando o agente do Google Cloud para SAP, consulte Coleta de métricas de monitoramento do SAP HANA.
(Opcional) Criar uma lista de instâncias para automação de scripts
Para automatizar parcialmente algumas das tarefas repetitivas durante a configuração do cluster do sistema SAP HANA e do Pacemaker, use scripts bash. Ao longo deste guia, esses scripts bash são usados para acelerar a configuração do sistema SAP HANA e do cluster do Pacemaker. Esses scripts exigem uma lista de todas as instâncias de VM implantadas e as zonas correspondentes como entrada.
Para ativar essa automação, crie um arquivo chamado nodes.txt
e inclua os detalhes de todas as instâncias de VM implantadas no seguinte formato: nome da zona, espaço em branco e o nome da instância da VM. O arquivo de amostra a seguir é usado
ao longo deste guia:
# cat nodes.txt us-west1-a hana-ha-vm-1 us-west1-a hana-ha-vm-1w1 us-west1-a hana-ha-vm-1w2 us-west1-b hana-majoritymaker us-west1-c hana-ha-vm-2 us-west1-c hana-ha-vm-2w1 us-west1-c hana-ha-vm-2w2
Configurar o acesso SSH sem senha
Para configurar o cluster do Pacemaker e sincronizar as chaves de armazenamento seguro do SAP HANA (SSFS, na sigla em inglês), o acesso SSH sem senha é necessário entre todos os nós, incluindo a instância do fabricante majoritário. Para acesso SSH sem senha, é necessário adicionar as chaves públicas SSH aos metadados de todas as instâncias implantadas.
O formato dos metadados é USERNAME: PUBLIC-KEY-VALUE
.
Para mais informações sobre como adicionar chaves SSH a VMs, consulte Adicionar chaves SSH a VMs que usam chaves SSH baseadas em metadados.
Etapas manuais
Para cada instância nos sistemas principal e secundário, bem como para a instância do fabricante majoritário, colete a chave pública para o usuário
root
.gcloud compute ssh --quiet --zone ZONE_ID INSTANCE_NAME -- sudo cat /root/.ssh/id_rsa.pub
Inclua a string
root:
no início da chave e a escreva como uma nova linha no arquivopublic-ssh-keys.txt
. Por exemplo:root:ssh-rsa AAAAB3NzaC1JfuYnOI1vutCs= root@INSTANCE_NAME
Depois de coletar todas as chaves públicas SSH, faça upload das chaves como metadados para todas as instâncias:
gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone ZONE_ID INSTANCE_NAME
Etapas automatizadas
Como alternativa, para automatizar o processo de configuração do acesso SSH sem senha para
todas as instâncias listadas em nodes.txt
,
execute as seguintes etapas no console do Google Cloud:
Crie uma lista de chaves públicas de todas as instâncias implantadas:
while read -u10 ZONE HOST ; do echo "Collecting public-key from $HOST"; { echo 'root:'; gcloud compute ssh --quiet --zone $ZONE $HOST --tunnel-through-iap -- sudo cat /root/.ssh/id_rsa.pub; } | tr -ds '\n' " " >> public-ssh-keys.txt; done 10< nodes.txt
Atribua as chaves públicas SSH como entradas de metadados a todas as instâncias:
while read -u10 ZONE HOST ; do echo "Adding public keys to $HOST"; gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone $ZONE $HOST; done 10< nodes.txt
Desativar o início automático do SAP HANA
Etapas manuais
Para cada instância do SAP HANA no cluster, verifique se o início automático do SAP HANA está desativado. Para failovers, o Pacemaker gerencia o início e a interrupção das instâncias do SAP HANA em um cluster.
Em cada host como SID_LCadm, pare o SAP HANA:
>
HDB stopEm cada host, abra o perfil do SAP HANA usando um editor, como o vi:
vi /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_HOST_NAME
Defina a propriedade
Autostart
como0
:Autostart=0
Salve o perfil.
Em cada host como SID_LCadm, inicie o SAP HANA:
>
HDB start
Etapas automatizadas
Como alternativa, para desativar o início automático do SAP HANA em todas as instâncias listadas em
nodes.txt
,
execute o seguinte script no console do Google Cloud:
while read -u10 ZONE HOST ; do gcloud compute ssh --verbosity=none --zone $ZONE $HOST -- "echo Setting Autostart=0 on \$HOSTNAME; sudo sed -i 's/Autostart=1/Autostart=0/g' /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_\$HOSTNAME"; done 10< nodes.txt
Ativar a reinicialização rápida do SAP HANA
O Google Cloud recomenda fortemente ativar a reinicialização rápida do SAP HANA para cada instância do SAP HANA, especialmente para instâncias maiores. A reinicialização rápida do SAP HANA reduz os tempos de reinicialização caso o SAP HANA seja encerrado, mas o sistema operacional continua em execução.
Conforme definido pelos scripts de automação que o Google Cloud fornece,
as configurações do sistema operacional e do kernel já aceitam o Inicialização rápida do SAP HANA.
Você precisa definir o sistema de arquivos tmpfs
e configurar o SAP HANA.
Para definir o sistema de arquivos tmpfs
e configurar o SAP HANA, siga
as etapas manuais ou use o script de automação fornecido
pelo Google Cloud para ativar a reinicialização rápida do SAP HANA. Para mais informações, veja:
- Etapas manuais: ativar a reinicialização rápida do SAP HANA
- Etapas automatizadas: ativar a reinicialização rápida do SAP HANA
Para receber instruções completas sobre a reinicialização rápida do SAP HANA, consulte a documentação da opção de reinicialização rápida do SAP HANA.
Etapas manuais
Configurar o sistema de arquivos tmpfs
Depois que as VMs do host e os sistemas SAP HANA de base forem implantados, você precisará criar e ativar diretórios para os nós NUMA no sistema de arquivos tmpfs
.
Exibir a topologia de NUMA da sua VM
Antes de mapear o sistema de arquivos tmpfs
necessário, você precisa saber quantos
nós NUMA sua VM tem. Para exibir os nós NUMA disponíveis em uma
VM do Compute Engine, digite o seguinte comando:
lscpu | grep NUMA
Por exemplo, um tipo de VM m2-ultramem-208
tem quatro nós NUMA,
numerados de 0 a 3, conforme mostrado no exemplo a seguir:
NUMA node(s): 4 NUMA node0 CPU(s): 0-25,104-129 NUMA node1 CPU(s): 26-51,130-155 NUMA node2 CPU(s): 52-77,156-181 NUMA node3 CPU(s): 78-103,182-207
Criar os diretórios de nós NUMA
Crie um diretório para cada nó NUMA na sua VM e defina as permissões.
Por exemplo, para quatro nós NUMA numerados de 0 a 3:
mkdir -pv /hana/tmpfs{0..3}/SID chown -R SID_LCadm:sapsys /hana/tmpfs*/SID chmod 777 -R /hana/tmpfs*/SID
Montar os diretórios de nó NUMA em tmpfs
Monte os diretórios do sistema de arquivos tmpfs
e especifique uma preferência de nó NUMA para cada um com mpol=prefer
:
SID especifica o SID com letras maiúsculas.
mount tmpfsSID0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID mount tmpfsSID1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID mount tmpfsSID2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID mount tmpfsSID3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID
Atualizar /etc/fstab
Para garantir que os pontos de montagem estejam disponíveis após uma reinicialização do sistema operacional, adicione entradas à tabela do sistema de arquivos, /etc/fstab
:
tmpfsSID0 /hana/tmpfs0/SID tmpfs rw,relatime,mpol=prefer:0 tmpfsSID1 /hana/tmpfs1/SID tmpfs rw,relatime,mpol=prefer:1 tmpfsSID1 /hana/tmpfs2/SID tmpfs rw,relatime,mpol=prefer:2 tmpfsSID1 /hana/tmpfs3/SID tmpfs rw,relatime,mpol=prefer:3
Opcional: defina limites de uso de memória
O sistema de arquivos tmpfs
pode aumentar e diminuir dinamicamente.
Para limitar a memória usada pelo sistema de arquivos tmpfs
, defina um limite de tamanho para um volume de nó NUMA com a opção size
.
Exemplo:
mount tmpfsSID0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID
Também é possível limitar o uso geral da memória tmpfs
para todos os nós NUMA de
uma determinada instância do SAP HANA e de um determinado nó do servidor definindo o
parâmetro persistent_memory_global_allocation_limit
na seção [memorymanager]
do arquivo global.ini
.
Configuração do SAP HANA para reinicialização rápida
Para configurar o SAP HANA para reinicialização rápida, atualize o arquivo global.ini
e especifique as tabelas a serem armazenadas na memória permanente.
Atualize a seção [persistence]
no arquivo global.ini
Configure a seção [persistence]
no arquivo global.ini
do SAP HANA para fazer referência aos locais tmpfs
. Separe cada local tmpfs
com
um ponto e vírgula:
[persistence] basepath_datavolumes = /hana/data basepath_logvolumes = /hana/log basepath_persistent_memory_volumes = /hana/tmpfs0/SID;/hana/tmpfs1/SID;/hana/tmpfs2/SID;/hana/tmpfs3/SID
O exemplo anterior especifica quatro volumes de memória para quatro nós NUMA,
que correspondem a m2-ultramem-208
. Se você estivesse executando no m2-ultramem-416
, seria necessário configurar oito volumes de memória (0..7).
Reinicie o SAP HANA depois de modificar o arquivo global.ini
.
O SAP HANA agora pode usar o local tmpfs
como espaço de memória permanente.
Especificar as tabelas a serem armazenadas na memória permanente
Especifique tabelas ou partições específicas de coluna para armazenar na memória permanente.
Por exemplo, para ativar a memória permanente de uma tabela atual, execute a consulta SQL:
ALTER TABLE exampletable persistent memory ON immediate CASCADE
Para alterar o padrão de novas tabelas, adicione o parâmetro table_default
no arquivo indexserver.ini
. Exemplo:
[persistent_memory] table_default = ON
Para mais informações sobre como controlar colunas, tabelas e quais visualizações de monitoramento fornecem informações detalhadas, consulte Memória permanente do SAP HANA.
Etapas automatizadas
O script de automação que o Google Cloud fornece para ativar
a Inicialização rápida do SAP HANA
faz mudanças nos diretórios /hana/tmpfs*
, /etc/fstab
e
na configuração do SAP HANA. Ao executar o script, talvez seja necessário executar
etapas adicionais, dependendo se essa é a implantação inicial do seu
sistema SAP HANA ou se você está redimensionando sua máquina para um tamanho de NUMA diferente.
Para a implantação inicial do seu sistema SAP HANA ou redimensionar a máquina para aumentar o número de nós NUMA, verifique se o SAP HANA está em execução durante a execução do script de automação que o Google Cloud fornece para permitir a reinicialização rápida do SAP HANA.
Ao redimensionar a máquina para diminuir o número de nós NUMA, verifique se o SAP HANA é interrompido durante a execução do script de automação fornecido pelo Google Cloud para ativar a reinicialização rápida do SAP HANA. Depois que o script for executado, você precisará atualizar manualmente a configuração do SAP HANA para concluir a configuração de reinício rápido do SAP HANA. Para mais informações, consulte Configuração do SAP HANA para reinício rápido.
Para ativar o reinício rápido do SAP HANA, siga estas etapas:
Estabeleça uma conexão SSH com sua VM do host.
Mudar para raiz:
sudo su -
Faça o download do script
sap_lib_hdbfr.sh
:wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh
Torne o arquivo executável:
chmod +x sap_lib_hdbfr.sh
Verifique se o script não tem erros:
vi sap_lib_hdbfr.sh ./sap_lib_hdbfr.sh -help
Se o comando retornar um erro, entre em contato com o Cloud Customer Care. Para mais informações sobre como entrar em contato com o Customer Care, consulte Como receber suporte para a SAP no Google Cloud.
Execute o script depois de substituir o ID do sistema (SID) do SAP HANA e a senha do usuário SYSTEM do banco de dados do SAP HANA. Para fornecer a senha com segurança, recomendamos que você use uma chave secreta no Gerenciador de secrets.
Execute o script usando o nome de um secret no Secret Manager. Esse secret precisa existir no projeto do Google Cloud que contém a instância de VM do host.
sudo ./sap_lib_hdbfr.sh -h 'SID' -s SECRET_NAME
Substitua:
SID
: especifique o SID com letras maiúsculas. Por exemplo,AHA
.SECRET_NAME
: especifique o nome do secret que corresponde à senha do usuário do SYSTEM do banco de dados do SAP HANA. Esse secret precisa existir no projeto do Google Cloud que contém a instância de VM do host.
Outra opção é executar o script com uma senha de texto simples. Depois que a reinicialização rápida do SAP HANA estiver ativada, altere sua senha. Não é recomendável usar uma senha de texto simples, porque ela seria registrada no histórico de linha de comando da VM.
sudo ./sap_lib_hdbfr.sh -h 'SID' -p 'PASSWORD'
Substitua:
SID
: especifique o SID com letras maiúsculas. Por exemplo,AHA
.PASSWORD
: especifique a senha do usuário do SYSTEM do banco de dados SAP HANA.
Para uma execução inicial bem-sucedida, você verá uma saída semelhante a esta:
INFO - Script is running in standalone mode ls: cannot access '/hana/tmpfs*': No such file or directory INFO - Setting up HANA Fast Restart for system 'TST/00'. INFO - Number of NUMA nodes is 2 INFO - Number of directories /hana/tmpfs* is 0 INFO - HANA version 2.57 INFO - No directories /hana/tmpfs* exist. Assuming initial setup. INFO - Creating 2 directories /hana/tmpfs* and mounting them INFO - Adding /hana/tmpfs* entries to /etc/fstab. Copy is in /etc/fstab.20220625_030839 INFO - Updating the HANA configuration. INFO - Running command: select * from dummy DUMMY "X" 1 row selected (overall time 4124 usec; server time 130 usec) INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistence', 'basepath_persistent_memory_volumes') = '/hana/tmpfs0/TST;/hana/tmpfs1/TST;' 0 rows affected (overall time 3570 usec; server time 2239 usec) INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistent_memory', 'table_unload_action') = 'retain'; 0 rows affected (overall time 4308 usec; server time 2441 usec) INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('persistent_memory', 'table_default') = 'ON'; 0 rows affected (overall time 3422 usec; server time 2152 usec)
Fazer o download de pacotes SUSE
Desinstale os agentes de recursos usados para implantações de escalonamento vertical e substitua-os pelos agentes de recursos usados para o escalonamento horizontal.
Etapas manuais
Siga estas etapas em todos os hosts, incluindo a instância do fabricante majoritário:
Desinstale os agentes de recursos de escalonamento vertical do HANA:
zypper remove SAPHanaSR SAPHanaSR-doc
Instale os agentes de recursos de escalonamento horizontal do HANA:
zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc
Instale
socat
:zypper install socat
Instale os patches mais recentes do sistema operacional:
zypper patch
Etapas automatizadas
Como alternativa, para automatizar esse processo para todas as instâncias listadas em nodes.txt
, execute o script a seguir no Console do Google Cloud:
while read -u10 HOST ; do gcloud compute ssh --zone $HOST -- "sudo zypper remove -y SAPHanaSR SAPHanaSR-doc; sudo zypper in -y SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc socat; sudo zypper patch -y"; done 10< nodes.txt
Fazer backup dos bancos de dados
Crie backups dos seus bancos de dados para iniciar a geração de registros do banco de dados para a replicação do sistema SAP HANA e criar um ponto de recuperação.
Se você tiver bancos de dados multilocatário em uma configuração de MDC, faça backup de cada banco de dados de locatário.
O modelo do Deployment Manager usa /hanabackup/data/SID como o diretório de backup padrão.
Para criar backups de novos bancos de dados SAP HANA:
No host principal, mude para
SID_LCadm
. Dependendo da imagem do SO, o comando pode ser diferente.sudo -i -u SID_LCadm
Crie backups de banco de dados:
Para um sistema de contêiner de banco de dados único do SAP HANA:
>
hdbsql -t -u system -p SYSTEM_PASSWORD -i INST_NUM \ "backup data using file ('full')"O exemplo a seguir mostra uma resposta bem-sucedida de um novo sistema SAP HANA:
0 rows affected (overall time 18.416058 sec; server time 18.414209 sec)
Para um sistema de contêiner de vários bancos de dados (MDC, na sigla em inglês) do SAP HANA, crie um backup do banco de dados do sistema e de quaisquer bancos de dados de locatário:
>
hdbsql -t -d SYSTEMDB -u system -p SYSTEM_PASSWORD -i INST_NUM \ "backup data using file ('full')">
hdbsql -t -d SID -u system -p SYSTEM_PASSWORD -i INST_NUM \ "backup data using file ('full')"
O exemplo a seguir mostra uma resposta bem-sucedida de um novo sistema SAP HANA:
0 rows affected (overall time 16.590498 sec; server time 16.588806 sec)
Confirme se o modo de geração de registros está definido como normal:
>
hdbsql -u system -p SYSTEM_PASSWORD -i INST_NUM \ "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"Você verá:
VALUE "normal"
Ativar a replicação do sistema SAP HANA
Como parte da ativação da replicação do sistema SAP HANA, você precisa copiar os dados e os arquivos de chave para os armazenamentos seguros do SAP HANA no sistema de arquivos (SSFS) do host principal para o host secundário. O método usado para copiar os arquivos é apenas um método possível.
No host principal como
SID_LCadm
, ative a replicação do sistema:>
hdbnsutil -sr_enable --name=PRIMARY_HOST_NAMENo host secundário:
Como
SID_LCadm
, interrompa o SAP HANA:>
sapcontrol -nr INST_NUM -function StopSystemComo raiz, arquive os dados e arquivos de chave SSFS atuais:
#
cd /usr/sap/SID/SYS/global/security/rsecssfs/#
mv data/SSFS_SID.DAT data/SSFS_SID.DAT-ARC#
mv key/SSFS_SID.KEY key/SSFS_SID.KEY-ARCCopie o arquivo de dados do host principal:
#
scp -o StrictHostKeyChecking=no \ PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT \ /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DATCopie o arquivo de chave do host principal:
#
scp -o StrictHostKeyChecking=no \ PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY \ /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEYAtualize a propriedade dos arquivos:
#
chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT#
chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEYAtualize as permissões dos arquivos:
#
chmod 644 /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT#
chmod 640 /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEYComo SID_LCadm, registre o sistema SAP HANA secundário com a replicação do sistema SAP HANA:
>
hdbnsutil -sr_register --remoteHost=PRIMARY_HOST_NAME --remoteInstance=INST_NUM \ --replicationMode=syncmem --operationMode=logreplay --name=SECONDARY_HOST_NAMEComo SID_LCadm, inicie o SAP HANA:
>
sapcontrol -nr INST_NUM -function StartSystem
Como validar a replicação do sistema
No host principal como SID_LCadm
, confirme se a
replicação do sistema SAP HANA está ativa executando o seguinte script Python:
$
python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py
Se a replicação estiver configurada corretamente, entre outros indicadores, os seguintes valores
serão exibidos para os serviços xsengine
, nameserver
e indexserver
:
- O
Secondary Active Status
éYES
- O
Replication Status
éACTIVE
Além disso, o overall system replication status
mostra ACTIVE
.
Ativar os ganchos de provedor HA/DR do SAP HANA
O SUSE recomenda que você ative os ganchos de provedor HA/DR do SAP HANA, que permitem que o SAP HANA envie notificações para determinados eventos e melhoram a detecção de falhas. Os ganchos de provedor HA/DR do SAP HANA exigem o SAP HANA 2.0 SPS 03 ou uma versão posterior.
Tanto no site principal quanto no secundário, siga estas etapas:
Como
SID_LCadm
, interrompa o SAP HANA:>
sapcontrol -nr 00 -function StopSystem
Como raiz ou
SID_LCadm
, abra o arquivoglobal.ini
para edição:>
vi /hana/shared/SID/global/hdb/custom/config/global.iniAdicione as seguintes definições ao arquivo
global.ini
:[ha_dr_provider_saphanasrmultitarget] provider = SAPHanaSrMultiTarget path = /usr/share/SAPHanaSR-ScaleOut/ execution_order = 1 [ha_dr_provider_sustkover] provider = susTkOver path = /usr/share/SAPHanaSR-ScaleOut/ execution_order = 2 sustkover_timeout = 30 [ha_dr_provider_suschksrv] provider = susChkSrv path = /usr/share/SAPHanaSR-ScaleOut/ execution_order = 3 action_on_lost = stop [trace] ha_dr_saphanasrmultitarget = info ha_dr_sustkover = info
Como raiz, crie um arquivo de configuração personalizado no diretório
/etc/sudoers.d
executando o comando a seguir. Esse novo arquivo de configuração permite que o usuárioSID_LCadm
acesse os atributos do nó do cluster quando o método hooksrConnectionChanged()
for chamado.>
sudo visudo -f /etc/sudoers.d/SAPHanaSRNo arquivo
/etc/sudoers.d/SAPHanaSR
, adicione o seguinte texto:Substitua
SID_LC
pelo SID em letras minúsculas.SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_* SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_SID_LC_gsh * SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=SID_LC *
No arquivo
/etc/sudoers
, verifique se o texto a seguir está incluído.Para SLES para SAP 15 SP3 e mais recentes:
@includedir /etc/sudoers.d
Para versões até o SLES para SAP 15 SP2:
#includedir /etc/sudoers.d
Observe que
#
nesse texto faz parte da sintaxe e não significa que a linha seja um comentário.
Como
SID_LCadm
, inicie o SAP HANA:>
sapcontrol -nr 00 -function StartSystemDepois de concluir a configuração do cluster para o SAP HANA, verifique se o gancho funciona corretamente durante um teste de failover, conforme descrito em Como solucionar problemas do gancho do Python do SAPHanaSR e Preenchimento total do cluster de alta disponibilidade demora muito em uma falha no servidor de índice do HANA
Configurar o suporte a failover do Cloud Load Balancing
O serviço de balanceador de carga de rede de passagem interno com suporte a failover direciona o tráfego para o host ativo em um cluster do SAP HANA com base em um serviço de verificação de integridade.
Reservar um endereço IP para o IP virtual
O endereço IP virtual (VIP, na sigla em inglês), às vezes chamado de endereço IP flutuante, segue o sistema SAP HANA ativo. O balanceador de carga encaminha o tráfego enviado ao VIP para a VM que está hospedando o sistema ativo do SAP HANA.
Abra o Cloud Shell:
Reserve um endereço IP para o IP virtual. Esse é o endereço IP que os aplicativos usam para acessar o SAP HANA. Se você omitir a sinalização
--addresses
, um endereço IP será escolhido para você na sub-rede especificada:$
gcloud compute addresses create VIP_NAME \ --region CLUSTER_REGION --subnet CLUSTER_SUBNET \ --addresses VIP_ADDRESSPara mais informações sobre como reservar um IP estático, consulte Como reservar um endereço IP interno estático.
Confirmar reserva de endereço IP:
$
gcloud compute addresses describe VIP_NAME \ --region CLUSTER_REGIONO resultado será semelhante a:
address: 10.0.0.19 addressType: INTERNAL creationTimestamp: '2020-05-20T14:19:03.109-07:00' description: '' id: '8961491304398200872' kind: compute#address name: vip-for-hana-ha networkTier: PREMIUM purpose: GCE_ENDPOINT region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1 selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-hana-ha status: RESERVED subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1
Criar grupos de instâncias para suas VMs de host
No Cloud Shell, crie dois grupos de instâncias não gerenciadas e atribua a VM do host mestre principal a um e a VM do host mestre secundário à outra:
$
gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE$
gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE \ --instances=PRIMARY_HOST_NAME$
gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE$
gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE \ --instances=SECONDARY_HOST_NAMEConfirme a criação dos grupos de instâncias:
$
gcloud compute instance-groups unmanaged listO resultado será semelhante a:
NAME ZONE NETWORK NETWORK_PROJECT MANAGED INSTANCES hana-ha-ig-1 us-central1-a example-network example-project-123456 No 1 hana-ha-ig-2 us-central1-c example-network example-project-123456 No 1
Criar uma verificação de integridade do Compute Engine
No Cloud Shell, crie a verificação de integridade. Para a porta usada pela verificação de integridade, escolha uma porta que esteja no intervalo privado 49152-65535 para evitar conflitos com outros serviços. Os valores de intervalo de verificação e tempo limite são um pouco mais longos do que os padrões para aumentar a tolerância de failover durante os eventos de migração em tempo real do Compute Engine. É possível ajustar os valores, se necessário:
$
gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \ --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \ --healthy-threshold=2Confirme a criação da verificação de integridade:
$
gcloud compute health-checks describe HEALTH_CHECK_NAMEO resultado será semelhante a:
checkIntervalSec: 10 creationTimestamp: '2020-05-20T21:03:06.924-07:00' healthyThreshold: 2 id: '4963070308818371477' kind: compute#healthCheck name: hana-health-check selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check tcpHealthCheck: port: 60000 portSpecification: USE_FIXED_PORT proxyHeader: NONE timeoutSec: 10 type: TCP unhealthyThreshold: 2
Criar uma regra de firewall para as verificações de integridade
Defina uma regra de firewall para uma porta no intervalo particular que permita o acesso
às VMs do host a partir dos intervalos de IP usados pelas verificações de integridade do
Compute Engine, 35.191.0.0/16
e 130.211.0.0/22
. Para mais informações,
consulte Como criar regras de firewall para verificações de integridade.
Se você ainda não tiver uma tag de rede, adicione uma às suas VMs de host. Essa tag de rede é usada pela regra de firewall para verificações de integridade.
$
gcloud compute instances add-tags PRIMARY_HOST_NAME \ --tags NETWORK_TAGS \ --zone PRIMARY_ZONE$
gcloud compute instances add-tags SECONDARY_HOST_NAME \ --tags NETWORK_TAGS \ --zone SECONDARY_ZONESe você ainda não tiver uma, crie uma regra de firewall para permitir as verificações de integridade:
$
gcloud compute firewall-rules create RULE_NAME \ --network NETWORK_NAME \ --action ALLOW \ --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tags NETWORK_TAGS \ --rules tcp:HLTH_CHK_PORT_NUMExemplo:
gcloud compute firewall-rules create fw-allow-health-checks \ --network example-network \ --action ALLOW \ --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tags cluster-ntwk-tag \ --rules tcp:60000
Configurar o balanceador de carga e o grupo de failover
Crie o serviço de back-end do balanceador de carga:
$
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --load-balancing-scheme internal \ --health-checks HEALTH_CHECK_NAME \ --no-connection-drain-on-failover \ --drop-traffic-if-unhealthy \ --failover-ratio 1.0 \ --region CLUSTER_REGION \ --global-health-checksAdicione o grupo de instâncias principal ao serviço de back-end:
$
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --instance-group PRIMARY_IG_NAME \ --instance-group-zone PRIMARY_ZONE \ --region CLUSTER_REGIONAdicione o grupo de instâncias de failover secundário ao serviço de back-end:
$
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --instance-group SECONDARY_IG_NAME \ --instance-group-zone SECONDARY_ZONE \ --failover \ --region CLUSTER_REGIONCrie uma regra de encaminhamento. No caso do endereço IP, especifique aquele que você reservou para o VIP. Se você precisar acessar o sistema SAP HANA de fora da região especificada abaixo, inclua a sinalização
--allow-global-access
na definição:$
gcloud compute forwarding-rules create RULE_NAME \ --load-balancing-scheme internal \ --address VIP_ADDRESS \ --subnet CLUSTER_SUBNET \ --region CLUSTER_REGION \ --backend-service BACKEND_SERVICE_NAME \ --ports ALLPara mais informações sobre o acesso entre regiões ao sistema de alta disponibilidade do SAP HANA, consulte Balanceamento de carga TCP/UDP interno.
Testar a configuração do balanceador de carga
Mesmo que os grupos de instâncias de back-end não sejam registrados como íntegros até mais tarde, teste a configuração do balanceador de carga configurando um listener para responder às verificações de integridade. Depois de configurar um listener, se o balanceador de carga estiver configurado corretamente, o status dos grupos de instâncias de back-end será alterado para íntegro.
As seções a seguir apresentam métodos diferentes que podem ser usados para testar a configuração.
Como testar o balanceador de carga com o utilitário socat
É possível usar o utilitário socat
para detectar temporariamente a porta de verificação de
integridade. Você precisa instalar o utilitário socat
mesmo assim, porque
ele será usado mais tarde quando você configurar os recursos do cluster.
Nas VMs do host mestre principal e secundário como raiz, instale o utilitário
socat
:#
zypper install -y socatInicie um processo
socat
para detectar por 60 segundos na porta de verificação de integridade:#
timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,forkNo Cloud Shell, depois de esperar alguns segundos pela verificação de integridade para detectar o listener, verifique a integridade dos grupos de instâncias de back-end:
$
gcloud compute backend-services get-health BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONA resposta será semelhante a esta:
--- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1 ipAddress: 10.0.0.35 port: 80 kind: compute#backendServiceGroupHealth --- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2 ipAddress: 10.0.0.34 port: 80 kind: compute#backendServiceGroupHealth
Como testar o balanceador de carga usando a porta 22
Se a porta 22 estiver aberta para conexões SSH nas VMs do host, será possível editar temporariamente o verificador de integridade para usar a porta 22, que tem um listener que pode responder ao verificador de integridade.
Para usar temporariamente a porta 22, siga estas etapas:
Clique na verificação de integridade no console:
Clique em Editar.
No campo Porta, altere o número da porta para 22.
Clique em Salvar e aguarde um ou dois minutos.
No Cloud Shell, verifique a integridade dos grupos de instâncias de back-end:
$
gcloud compute backend-services get-health BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONA resposta será semelhante a esta:
--- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1 ipAddress: 10.0.0.35 port: 80 kind: compute#backendServiceGroupHealth --- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2 ipAddress: 10.0.0.34 port: 80 kind: compute#backendServiceGroupHealth
Quando terminar, altere o número da porta de verificação de integridade para o número de porta original.
Configurar o Pacemaker
O procedimento a seguir configura a implementação do SUSE de um cluster do Pacemaker nas VMs do Compute Engine para SAP HANA.
Para mais informações sobre a configuração de clusters de alta disponibilidade no SLES, consulte a documentação Extensão de alta disponibilidade do SUSE Linux Enterprise (em inglês) para sua versão do SLES.
Fazer o download dos scripts do agente de recursos
Etapas manuais
Como raiz em todos os hosts principais e secundários, bem como no fabricante majoritário, faça o download dos scripts do agente de recursos necessários:
#
mkdir -p /usr/lib64/stonith/plugins/external#
curl https://storage.googleapis.com/sapdeploy/pacemaker-gcp/gcpstonith -o /usr/lib64/stonith/plugins/external/gcpstonith#
chmod +x /usr/lib64/stonith/plugins/external/gcpstonith
Etapas automatizadas
Como alternativa, para fazer o download dos scripts do agente de recursos necessários para todas as instâncias listadas em nodes.txt
, execute o script a seguir no console do Google Cloud:
while read -u10 HOST ; do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- "echo 'CLOUDSDK_PYTHON=/usr/bin/python' | sudo tee -a /etc/sysconfig/pacemaker; sudo curl --silent https://storage.googleapis.com/sapdeploy/pacemaker-gcp/gcpstonith -o /usr/lib64/stonith/plugins/external/gcpstonith; sudo chmod +x /usr/lib64/stonith/plugins/external/gcpstonith"; done 10< nodes.txt
Inicializar o cluster
No host principal como raiz, inicialize o cluster:
SLES 15
crm cluster init -y
SLES 12
ha-cluster-init -y
Ignore os avisos relacionados ao SBD e à senha padrão. O SBD e a senha padrão não são usados nesta implantação.
Configurar o cluster
Execute as etapas a seguir no host principal como raiz.
Ativar o modo de manutenção
Coloque o cluster do Pacemaker no modo de manutenção:
crm configure property maintenance-mode="true"
Configurar as propriedades gerais do cluster
Configure as seguintes propriedades gerais do cluster:
crm configure property stonith-timeout="300s" crm configure property stonith-action="reboot" crm configure property stonith-enabled="true" crm configure property cluster-infrastructure="corosync" crm configure property cluster-name="hacluster" crm configure property placement-strategy="balanced" crm configure property no-quorum-policy="freeze" crm configure property concurrent-fencing="true" crm configure rsc_defaults migration-threshold="50" crm configure rsc_defaults resource-stickiness="1000" crm configure op_defaults timeout="600"
Editar as configurações padrão corosync.conf
Abra o arquivo
/etc/corosync/corosync.conf
usando um editor.Remova o parâmetro
consensus
.Modifique os parâmetros restantes de acordo com as recomendações do Google Cloud.
A tabela a seguir mostra os parâmetrostotem
para os quais o Google Cloud recomenda valores, além do impacto da alteração dos valores. Para os valores padrão desses parâmetros, que podem diferir entre as distribuições do Linux, consulte a documentação da distribuição do Linux.Parâmetro Valor recomendado Impacto da alteração do valor secauth
off
Desativa a autenticação e a criptografia de todas as mensagens totem
.join
60 (ms) Aumenta o tempo que o nó aguarda as mensagens join
no protocolo de associação.max_messages
20 Aumenta o número máximo de mensagens que podem ser enviadas pelo nó após o recebimento do token. token
20000 (ms) Aumenta o tempo de espera do nó para um token de protocolo
totem
antes que o nó declare uma perda de token, adote uma falha do nó e comece a agir.Aumentar o valor do parâmetro
token
torna o cluster mais tolerante a eventos de infraestrutura momentâneos, como uma migração em tempo real. No entanto, isso também pode fazer com que o cluster demore mais para detectar e se recuperar de uma falha de nó.O valor do parâmetro
token
também determina o valor padrão do parâmetroconsensus
, que controla quanto tempo um nó aguarda por um consenso antes de tentar restabelecer a associação da configuração.consensus
N/A Especifica, em milissegundos, quanto tempo esperar pelo consenso antes de iniciar uma nova rodada de configuração de assinatura.
Recomendamos que você omita esse parâmetro. Quando o parâmetro
No entanto, se você especificar explicitamente um valor paraconsensus
não é especificado, o Corosync define o valor como 1,2 vez o valor do parâmetrotoken
. Se você usar o valor recomendado de20000
do parâmetrotoken
, o parâmetroconsesus
será definido com o valor24000
.consensus
, verifique se ele é24000
ou1.2*token
, o que for maior.token_retransmits_before_loss_const
10 Aumenta o número de retransmissões de token que o nó tenta antes de concluir que o nó do destinatário falhou e entrar em ação. transport
- Para SLES:
udpu
- Para o RHEL 8 ou mais recente:
knet
- Para o RHEL 7:
udpu
Especifica o mecanismo de transporte usado pelo corosync. - Para SLES:
Mesclar todos os hosts com o cluster do Pacemaker
Mescle todos os outros hosts, incluindo o do fabricante majoritário, ao cluster do Pacemaker no host principal:
Etapas manuais
SLES 15
crm cluster join -y -c PRIMARY_HOST_NAME
SLES 12
ha-cluster-join -y -c PRIMARY_HOST_NAME
Etapas automatizadas
Como alternativa, para automatizar esse processo para todas as instâncias listadas em nodes.txt
, execute o script a seguir no Console do Google Cloud:
while read -u10 HOST ; do echo "Joining $HOST to Pacemaker cluster"; gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- sudo ha-cluster-join -y -c PRIMARY_HOST_NAME; done 10< nodes.txt
Ignore a mensagem de erro ERROR: cluster.join: Abort: Cluster is currently active
que é acionada ao mesclar no nó principal nele mesmo.
Em qualquer host como raiz, confirme se o cluster mostra todos os nós:
#
crm_mon -s
A resposta será semelhante a esta:
CLUSTER OK: 5 nodes online, 0 resources configured
Configurar o isolamento
Para configurar o isolamento, defina um recurso de cluster com um agente de isolamento para cada VM do host.
Para garantir a sequência correta de eventos após uma ação de isolamento, configure também o sistema operacional para atrasar a reinicialização do Corosync depois que uma VM for isolada. Ajuste também o tempo limite do Pacemaker para reinicializações para considerar o atraso.
Criar os recursos do dispositivo de isolamento
Etapas manuais
No host principal, como raiz, crie os recursos de isolamento para todos os nós nos clusters principal e secundário:
Execute o seguinte comando depois de substituir
PRIMARY_HOST_NAME
pelo nome do host de um nó no cluster principal:#
crm configure primitive STONITH-"PRIMARY_HOST_NAME" stonith:external/gcpstonith \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params instance_name="PRIMARY_HOST_NAME" gcloud_path="/usr/bin/gcloud" logging="yes" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30Repita a etapa anterior para todos os outros nós no cluster principal.
Execute o seguinte comando depois de substituir
SECONDARY_HOST_NAME
pelo nome do host de um nó no cluster secundário.#
crm configure primitive STONITH-"SECONDARY_HOST_NAME" stonith:external/gcpstonith \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params instance_name="SECONDARY_HOST_NAME" gcloud_path="/usr/bin/gcloud" logging="yes" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4Repita a etapa anterior para todos os outros nós no cluster secundário.
Execute o seguinte comando depois de substituir
MAJORITY_MAKER_HOSTNAME
pelo nome do host da instância de máquina principal:#
crm configure primitive STONITH-"MAJORITY_MAKER_HOSTNAME" stonith:external/gcpstonith \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params instance_name="MAJORITY_MAKER_HOSTNAME" gcloud_path="/usr/bin/gcloud" logging="yes" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4Defina a localização do dispositivo de isolamento:
#
crm configure location LOC_STONITH_"PRIMARY_HOST_NAME" \ STONITH-"PRIMARY_HOST_NAME" -inf: "PRIMARY_HOST_NAME"Repita a etapa anterior para todos os outros hosts nos clusters principal e secundário, incluindo o host do fabricante majoritário.
Etapas automatizadas
Como alternativa, para configurar o isolamento de todas as instâncias listadas em nodes.txt
, execute o script a seguir no console do Google Cloud:
while read -u10 HOST; do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- "sudo crm configure primitive STONITH-\$HOSTNAME stonith:external/gcpstonith op monitor interval=\"300s\" timeout=\"60s\" on-fail=\"restart\" op start interval=\"0\" timeout=\"60s\" onfail=\"restart\" params instance_name=\$HOSTNAME gcloud_path=\"/usr/bin/gcloud\" logging=\"yes\" pcmk_reboot_timeout=300 pcmk_monitor_retries=4; sudo crm configure location LOC_STONITH_\$HOSTNAME STONITH-\$HOSTNAME -inf: \$HOSTNAME"; done 10< nodes.txt
Definir um atraso para a reinicialização do Corosync
Etapas manuais
Em todos os hosts como raiz, crie um arquivo drop-in
systemd
que atrase a inicialização do Corosync para garantir a sequência adequada de eventos após a reinicialização de uma VM isolada:systemctl edit corosync.service
Adicione as seguintes linhas ao arquivo:
[Service] ExecStartPre=/bin/sleep 60
Salve o arquivo e saia do editor.
Atualize a configuração do gerenciador systemd.
systemctl daemon-reload
Confirme se o arquivo drop-in foi criado:
service corosync status
Você verá uma linha para o arquivo drop-in, conforme mostrado no exemplo abaixo:
● corosync.service - Corosync Cluster Engine Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled) Drop-In: /etc/systemd/system/corosync.service.d └─override.conf Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago
Etapas automatizadas
Como alternativa, para automatizar esse processo para todas as instâncias listadas em nodes.txt
, execute o script a seguir no Console do Google Cloud:
while read -u10 HOST; do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- "sudo mkdir -p /etc/systemd/system/corosync.service.d/; sudo echo -e '[Service]\nExecStartPre=/bin/sleep 60' | sudo tee -a /etc/systemd/system/corosync.service.d/override.conf; sudo systemctl daemon-reload"; done 10< nodes.txt
Criar um recurso de IP de cluster local para o endereço VIP
Para configurar o endereço VIP no sistema operacional, crie um recurso de IP do cluster local para o endereço VIP reservado anteriormente:
#
crm configure primitive rsc_vip_int-primary IPaddr2 \
params ip=VIP_ADDRESS cidr_netmask=32 nic="eth0" op monitor interval=3600s timeout=60s
Configurar o serviço auxiliar de verificação de integridade
O balanceador de carga usa um listener na porta de verificação de integridade de cada host para determinar onde a instância principal do cluster do SAP HANA está sendo executada.
Para gerenciar os listeners no cluster, crie um recurso para o listener.
Estas instruções usam o utilitário socat
como listener.
Nos dois hosts como raiz, instale o
socat utility
:#
zypper in -y socatNo host principal, crie um recurso para o serviço de verificação de integridade auxiliar:
crm configure primitive rsc_healthcheck-primary anything \ params binfile="/usr/bin/socat" \ cmdline_options="-U TCP-LISTEN:HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \ op monitor timeout=20s interval=10s \ op_params depth=0
Agrupe os recursos de serviço de verificação de integridade VIP e auxiliar:
#
crm configure group g-primary rsc_vip_int-primary rsc_healthcheck-primary meta resource-stickiness="0"
Criar o recurso primitivo do SAPHanaTopology
Você define o recurso primitivo SAPHanaTopology em um arquivo de configuração temporário que você envia para o Corosync.
No host principal como raiz:
Crie um arquivo de configuração temporário para os parâmetros de configuração do SAPHanaTopology:
#
vi /tmp/cluster.tmpCopie e cole as definições de recurso do SAPHanaTopology no arquivo
/tmp/cluster.tmp
:primitive rsc_SAPHanaTopology_SID_HDBINST_NUM ocf:suse:SAPHanaTopology \ operations \$id="rsc_sap2_SID_HDBINST_NUM-operations" \ op monitor interval="10" timeout="600" \ op start interval="0" timeout="600" \ op stop interval="0" timeout="300" \ params SID="SID" InstanceNumber="INST_NUM" clone cln_SAPHanaTopology_SID_HDBINST_NUM rsc_SAPHanaTopology_SID_HDBINST_NUM \ meta clone-node-max="1" target-role="Started" interleave="true" location SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_SID_HDBINST_NUM -inf: MAJORITY_MAKER_HOSTNAME
Edite o arquivo
/tmp/cluster.tmp
para substituir o texto da variável pelo SID e pelo número da instância do sistema SAP HANA.No principal como raiz, carregue o conteúdo do arquivo
/tmp/cluster.tmp
no Corosync:crm configure load update /tmp/cluster.tmp
Criar o recurso primitivo do SAPHana
Defina o recurso primitivo do SAPHana usando o mesmo método utilizado para o recurso SAPHanaTopology: em um arquivo de configuração temporário, que será enviado ao Corosync.
Substitua o arquivo de configuração temporário:
#
rm /tmp/cluster.tmp#
vi /tmp/cluster.tmpCopie e cole as definições de recurso do SAPHana no arquivo
/tmp/cluster.tmp
:primitive rsc_SAPHana_SID_HDBINST_NUM ocf:suse:SAPHanaController \ operations \$id="rsc_sap_SID_HDBINST_NUM-operations" \ op start interval="0" timeout="3600" \ op stop interval="0" timeout="3600" \ op promote interval="0" timeout="3600" \ op demote interval="0" timeout="3600" \ op monitor interval="60" role="Master" timeout="700" \ op monitor interval="61" role="Slave" timeout="700" \ params SID="SID" InstanceNumber="INST_NUM" PREFER_SITE_TAKEOVER="true" \ DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="true" ms msl_SAPHana_SID_HDBINST_NUM rsc_SAPHana_SID_HDBINST_NUM \ meta master-node-max="1" master-max="1" clone-node-max="1" \ target-role="Started" interleave="true" colocation col_saphana_ip_SID_HDBINST_NUM 4000: g-primary:Started \ msl_SAPHana_SID_HDBINST_NUM:Master order ord_SAPHana_SID_HDBINST_NUM Optional: cln_SAPHanaTopology_SID_HDBINST_NUM \ msl_SAPHana_SID_HDBINST_NUM location SAPHanaCon_not_on_majority_maker msl_SAPHana_SID_HDBINST_NUM -inf: MAJORITY_MAKER_HOSTNAME
Para um cluster multinível de HA do SAP HANA, se você estiver usando uma versão anterior ao SAP HANA 2.0 SP03, defina
AUTOMATED_REGISTER
comofalse
. Isso impede que uma instância recuperada tente fazer o registro automático para replicação em um sistema HANA que já tem um destino de replicação configurado. Para o SAP HANA 2.0 SP03 ou posterior, é possível definirAUTOMATED_REGISTER
comotrue
para configurações do SAP HANA que usam replicação do sistema de várias camadas. Para mais informações, consulte:No principal como raiz, carregue o conteúdo do arquivo
/tmp/cluster.tmp
no Corosync:crm configure load update /tmp/cluster.tmp
Confirmar se a replicação do sistema SAP HANA está ativa
No host principal como SID_LCadm, verifique o status da replicação:
#
python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py
Ativar o cluster
No host principal como raiz, remova o cluster do modo de manutenção:
#
crm configure property maintenance-mode="false"Se você receber uma solicitação pedindo a remoção de "manutenção", digite
y
.Aguarde 15 segundos e, em seguida, no host principal como raiz, verifique o status do cluster:
#
crm statusOs exemplos a seguir mostram o status de um cluster ativo e configurado corretamente:
7 nodes configured 21 resources configured Online: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 sap-majoritymaker ] Full list of resources: STONITH-hana-ha-vm-1 (stonith:external/gcpstonith): Started hana-ha-vm-1w2 STONITH-hana-ha-vm-1w1 (stonith:external/gcpstonith): Started hana-ha-vm-1 STONITH-hana-ha-vm-1w2 (stonith:external/gcpstonith): Started hana-ha-vm-2 STONITH-sap-majoritymaker (stonith:external/gcpstonith): Started hana-ha-vm-1w2 STONITH-hana-ha-vm-2 (stonith:external/gcpstonith): Started hana-ha-vm-2w1 STONITH-hana-ha-vm-2w1 (stonith:external/gcpstonith): Started hana-ha-vm-2w2 STONITH-hana-ha-vm-2w2 (stonith:external/gcpstonith): Started sap-majoritymaker Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22] Started: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 ] Stopped: [ sap-majoritymaker ] Resource Group: g-primary rsc_vip_int-primary (ocf::heartbeat:IPaddr2): Started hana-ha-vm-1 rsc_healthcheck-primary (ocf::heartbeat:anything): Started hana-ha-vm-1 Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable) Masters: [ hana-ha-vm-1 ] Slaves: [ hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 ] Stopped: [ sap-majoritymaker ]
Testar o failover
Para testar seu cluster, simule uma falha no host principal. Use um sistema de teste ou execute o teste no sistema de produção antes de liberar o sistema para uso.
Faça backup do sistema antes do teste.
É possível simular uma falha de várias maneiras, incluindo:
HDB stop
HDB kill
reboot
(no nó ativo)ip link set eth0 down
para instâncias com uma única interface de redeiptables ... DROP
para instâncias com várias interfaces de redeecho c > /proc/sysrq-trigger
Nestas instruções, ip link set eth0 down
ou iptables
são usados para simular uma
interrupção de rede entre os dois hosts no cluster. Use o comando ip link
em uma instância com uma única interface de rede e iptables
em instâncias com uma ou mais interfaces de rede. O teste valida
o failover e o isolamento. Quando as instâncias têm várias interfaces de rede definidas, use o comando iptables
no host secundário para descartar o tráfego de entrada e de saída com base no IP usado pelo host principal para o cluster de comunicação, simulando uma perda de conexão de
rede com a instância principal.
No host ativo, como raiz, coloque a interface de rede off-line:
#
ip link set eth0 downOu, se várias interfaces de rede estiverem ativas, usando
iptables
no host secundário:#
iptables -A INPUT -s PRIMARY_CLUSTER_IP -j DROP; iptables -A OUTPUT -d PRIMARY_CLUSTER_IP -j DROPReconecte-se ao host usando o SSH e mude para o usuário raiz
Digite
crm status
para confirmar que o host principal está ativo na VM que costumava conter o host secundário. A reinicialização automática está habilitada no cluster. Portanto, o host parado será reiniciado e passará à função de host secundário, conforme mostrado no exemplo a seguir.Stack: corosync Current DC: hana-ha-vm-2 (version 2.0.1+20190417.13d370ca9-3.9.1-2.0.1+20190417.13d370ca9) - partition with quorum Last updated: Fri Jun 12 16:46:07 2020 Last change: Fri Jun 12 16:46:07 2020 by root via crm_attribute on hana-ha-vm-2 2 nodes configured 8 resources configured Online: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1] Full list of resources: STONITH-hana-ha-vm-1 (stonith:external/gcpstonith): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:external/gcpstonith): Started hana-ha-vm-1 STONITH-hana-ha-vm-1w1 (stonith:external/gcpstonith): Started hana-ha-vm-2w1 STONITH-hana-ha-vm-1w1 (stonith:external/gcpstonith): Started hana-ha-vm-mm STONITH-hana-ha-vm-mm (stonith:external/gcpstonith): Started hana-ha-vm-1w1 Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22] Started: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1 Stopped: [ hana-ha-vm-mm ]] Resource Group: g-primary rsc_vip_int-primary (ocf::heartbeat:IPaddr2): Started hana-ha-vm-2 rsc_healthcheck-primary (ocf::heartbeat:anything): Started hana-ha-vm-2 Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable) Masters: [ hana-ha-vm-2 ] Slaves: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-2w1 Stopped: [ hana-ha-vm-mm ]]
Avaliar sua carga de trabalho do SAP HANA
Para automatizar verificações de validação contínua para suas cargas de trabalho de alta disponibilidade do SAP HANA em execução no Google Cloud, use o Gerenciador de carga de trabalho.
O Gerenciador de carga de trabalho permite verificar e avaliar automaticamente suas cargas de trabalho de alta disponibilidade do SAP HANA em relação às práticas recomendadas de fornecedores da SAP, do Google Cloud e do SO. Isso ajuda a melhorar a qualidade, o desempenho e a confiabilidade das cargas de trabalho.
Para informações sobre as práticas recomendadas compatíveis com o Gerenciador de cargas de trabalho para avaliar cargas de trabalho de alta disponibilidade do SAP HANA em execução no Google Cloud, consulte Práticas recomendadas do Gerenciador de cargas de trabalho para SAP. Para informações sobre como criar e executar uma avaliação usando o Gerenciador de cargas de trabalho, consulte Criar e executar uma avaliação.
Solução de problemas
Para resolver problemas com configurações de alta disponibilidade do SAP HANA no SLES, consulte Como solucionar problemas de configurações de alta disponibilidade para SAP.
Como receber suporte para o SAP HANA no SLES
Se você precisar de ajuda para resolver um problema com clusters de alta disponibilidade do SAP HANA no SLES, colete as informações de diagnóstico necessárias e entre em contato com o Cloud Customer Care Para mais informações, consulte Clusters de alta disponibilidade em informações de diagnóstico do SLES.
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:
- Como receber suporte para o SAP no Google Cloud
- Nota SAP 2456406 - SAP no Google Cloud Platform: pré-requisitos de suporte (é necessário ter uma conta de usuário SAP)
Como se conectar ao SAP HANA
Se as VMs do host não tiverem um endereço IP externo para SAP HANA, você só conseguirá se conectar às instâncias do SAP HANA por meio da instância Bastion usando SSH ou por meio do servidor Windows via SAP HANA Studio.
Para se conectar ao SAP HANA por meio da instância Bastion, conecte-se ao Bastion Host e depois às instâncias do SAP HANA usando o cliente SSH de sua escolha.
Para se conectar ao banco de dados SAP HANA por meio do SAP HANA Studio, use um cliente de área de trabalho remota para se conectar à instância do Windows Server. Após a conexão, instale o SAP HANA Studio (em inglês) manualmente e acesse o banco de dados SAP HANA.
Tarefas pós-implantação
Depois de concluir a implantação, siga estas etapas:
Altere as senhas temporárias do superusuário do sistema SAP HANA e do superusuário do banco de dados. Exemplo:
sudo passwd SID_LCadm
Para informações da SAP sobre alteração de senha, consulte Redefinir a senha do usuário do SISTEMA do banco de dados do sistema.
Antes de usar a instância do SAP HANA, configure e faça o backup do novo banco de dados do SAP HANA.
Se o sistema SAP HANA for implantado em uma interface de rede VirtIO, recomendamos que você garanta que o valor do parâmetro TCP
/proc/sys/net/ipv4/tcp_limit_output_bytes
esteja definido como1048576
. Essa modificação ajuda a melhorar a capacidade geral da rede na interface de rede VirtIO sem afetar a latência da rede.
Veja mais informações em:
A seguir
Para mais informações, consulte os recursos a seguir: