Descubra como realizar a Migração SAP HANA/S4 HANA para nuvem (AWS/Azure)
Neste artigo demonstraremos as etapas completas do banco de dados BASIS/HANA “Como migrar aplicativos SAP e banco de dados HANA para a nuvem AWS/Azure.
Estão disponíveis ferramentas para migração SAP para nuvem, Cloud Endure (AWS), Azure Site Replication (ASR), metodologias de backup e restauração, exportação e importação e replicação de banco de dados. A ferramenta que usamos é uma ferramenta de código aberto (RSYNC) para migração de aplicativos e replicação de banco de dados (HSR).
Notas principais: Esta é a migração AS-IS. Nenhuma alteração na origem e assumindo que o banco de dados já estava instalado no AWS/Azure. (Consulte o link abaixo como instalar o banco de dados HANA)
Etapas completas para migração:
- depois que as VMs forem construídas, certifique-se de que os respectivos RPMs estejam instalados
- Referência SAP NOTA: 2455582 – Linux: Executando aplicativos SAP compilados com GCC 6.xe 2777782 – Configurações recomendadas do SAP Hana DB para RHEL 8
- Os nomes de host (nome do host usado durante a instalação do banco de dados) devem ser diferentes entre os bancos de dados de origem e de destino
- SID e número de instância para banco de dados e aplicativo devem ser iguais
- sid-adm /Sudo -informações de usuário e senha root para fonte
- Acesso SAP* e DDIC ao sistema de origem
- Para o banco de dados HANA, obtenha senhas dos usuários SYSTEM (System DB e Tenant DB), SCHEMA, DBACOCKPIT e qualquer outro usuário administrador de banco de dados do Tenant DB
- Listar plug-ins instalados em bancos de dados de origem
- Faça as capturas de tela necessárias do sistema de origem, como STMS, SMLG, RZ12 etc.
Preparação do sistema ALVO :
- Prepare a planilha de construção para todos os sistemas de componentes SAP
- Sistemas VM desenvolvidos com 8.x no AWS/Azure
- Manter UID e GID com On Prem e AWS/Azure iguais
- Verifique os pacotes recomendados pela SAP, parâmetros de kernel, FS, memória e CPU em aplicativos e nós de banco de dados
- Verifique se os pacotes de instalação necessários estão disponíveis (Banco de Dados, Aplicativo, DAA, SWPM e Kernel)
- Verificações/prontidão dos servidores de banco de dados (armazenamento, sistema operacional, redes, arquivos hares) no servidor de destino
- Instale o HANA 2.0 SP05 revisão 56 (igual à fonte em nosso caso) com os plug-ins necessários e execute a ferramenta de verificação de hardware, certifique-se de que o SID de destino corresponda ao SID de origem e ao número da instância
- Observe que as replicações HANA suportam de inferior (origem) a superior (destino AWS/Azure)
- Conectividade entre servidor de banco de dados e servidor de aplicativos no AWS/Azure
- Verifique a lista de endereços IP na origem e permita as portas necessárias no firewall AWS/Azure para solicitações de entrada
- A porta 4nn00 – 4nn99 precisa ser permitida para HSR entre os bancos de dados de origem e de destino
- A porta 3298 pode ser verificada com niping
- Execute o comando niping para ouvir solicitações de entrada de SourceFrom Source: ./niping -c -H <IP> -B 2000000 -L 5No destino: ./niping -s -I 0 -T trace_niping &
- Configurar a replicação HSR do nó local para o nó primário da AWS
- Compartilhamento de arquivos .dat e .key do banco de dados de origem e lista de parâmetros que precisam ser definidos no banco de dados AWS/Azure
- Pare o banco de dados no AWS/Azure
- Faça o backup dos arquivos .dat e .key existentes e substitua os arquivos .dat e .key do banco de origem e mantenha os parâmetros mencionados acima
- Manter o IP/nome do host do banco de dados de origem em arquivos /etc/hosts no banco de dados AWS/Azure
- iniciar banco de dados no AWS/Azure
- Habilite a replicação HSR do nó local para o nó primário da AWS
- Monitore a replicação (conclusão completa e delta)
- Leve o banco de dados primário AWS/Azure para o modo normal e faça a verificação de integridade
- Atualizar licença do banco de dados
Sincronização de aplicativos de origem para destino processando Rsync
- Crie todos os usuários de aplicativos no nível do sistema operacional (<sid>adm, daaadm, sapadm) com IDs de grupo adequados (sapsys, sapinst ) iguais aos sistemas de origem nos nós AWS/Azure de destino
Sincronize FS do local com o AWS/Azure Application Server para todos
/usr/sap/
/sapmnt/<SID>
/usr/sap/DAA
/home/<SID>adm
/home/daaadm
/home/sapadm
Pontos de montagem NFS
/usr/sap/trans
/sap/Interface
- Sincronize a permissão do sistema de arquivos igual ao sistema de origem
- Atualize o hdbuserstore em todos os servidores de aplicativos e verifique a conectividade do aplicativo com o banco de dados no host do aplicativo usando R3trans -d
- Abra o servidor de aplicativos e faça a verificação de integridade
- Adapte os parâmetros de perfil para aplicativo e banco de dados, se necessário, e reinicie o aplicativo SAP
- Execute etapas pós-migração para aplicativo e banco de dados <SID>
- Verifique a consistência do sistema usando SICK
- Execute a ação pós-instalação para o Transport Organizer no SE06
- Importar perfis de servidores ativos no RZ10
- Gerar cargas do sistema no SGEN
- Modifique a tela inicial da GUI no SE61, se necessário
- Instale agentes DAA em todos os servidores
- Monitoramento de aplicativos a ser configurado no Solution Manager e confirmado
- Encerre os servidores de aplicativos
Verificações de prontidão do banco de dados:
- Faça uma captura de tela do FS de todos os sistemas de origem
- Verifique se nenhum outro backup foi acionado após o backup on-line completo do banco de dados HANA e do aplicativo (se aplicável) para <SID> e interrompa todos os backups agendados e trabalhos BTC com BTCTRNS1
- Verifique o status de sincronização da replicação
- Interromper trabalhos em lote
- Bloquear usuários e parar servidores de aplicativos
- Aguarde a conclusão da replicação Delta (dados pontuais)
- Assuma o controle do banco de dados AWS/Azure HANA do modo de replicação para o modo normal, execute o comando ‘hdbnsutil -sr_takeover’ no banco de dados do Azure.
- Assim que o controle for concluído, desabilite a replicação no banco de dados do Azure e desabilite a replicação no banco de dados de origem (hdbnsutil -sr_disable)
- Renomeie o nome do host do banco de dados para o mesmo nome do host do alias do banco de dados de origem
- Incluir host de banco de dados/aplicativo no domínio junto com o nome alternativo do sistema de origem
- Pare o nó do banco de dados no Azure
- Reverta todos os parâmetros em global.ini que foram adicionados durante a configuração do HSR
- Reverter ambos os arquivos SSFS do atual para o original (durante a instalação) no banco de dados AWS/Azure
- Iniciar nó de banco de dados no Azure
- Inicie o aplicativo SAP
- Habilite a replicação no banco de dados do Azure entre o nó A e o nó B
- Verifique a licença no banco de dados, aplicativo e execute verificações de integridade
- Configurar e executar backup e conclusão.
Se você acha que há alguns dados a serem sincronizados nos aplicativos, execute novamente o Rsync (Delta Sync)
- Execute uma troca de DNS para que os respectivos nomes de host apontem para IPs AWS/Azure
- Inicie o banco de dados e os aplicativos no Target.
Vamos ver como realizar o HSR entre origem e destino .
Supondo que o banco de dados HANA já esteja instalado no AWS/Azure com a mesma versão do Source.
(A replicação HSR da origem para o destino funciona (da versão inferior para a superior), mas não de outra maneira (a replicação da versão superior para a inferior não funciona)
1) Habilite a replicação do banco de dados de origem
hdbnsutil -sr_enable –name=SourceA
2) Verifique o estado do servidor primário
hdbnsutil -sr_state
3) Secundário (banco de dados em AWS/Azure)
Verifique se o HANA está interrompido
4) Lado secundário: registro (banco de dados em AWS/Azure) Azure)
hdbnsutil -sr_register –name=TargetB –remoteHost=sourceDBHost –remoteInstance=$$ –replicationMode=async –operationMode=logreplay
5) Inicie o Hana no
sapcontrol secundário -nr $$ -function StartSystem HDB
6) Verifique o cluster
hdbnsutil -sr_state
7) verifique o status da replicação via Hana Studio ou script python
8) cancelar o registro da replicação no banco de dados de destino no AWS/Azure
hdbnsutil -sr_unregister
9) Parar o banco de dados e aplicativos no local
10) iniciar o banco de dados HANA no AWS/Azure
sapcontrol -nr $$ -function StartService SID
sapcontrol -nr $$ -function StartSystem
Vamos ver como realizar o RSYNC entre a origem e o destino.
Veja o link abaixo como instalar e configurar o RSYNC caso não esteja presente no SO
https://linuxize.com/post/how-to-use-rsync-for-local-and-remote-data-transfer-and-synchronization/
Sudo para fazer root e execute abaixo.
rsync -avhz –partial /home/<SID>/ <sid>adm@<IP de destino>:/home/<sid>adm/
rsync -avhz –partial /usr/sap/<SID>/ <sid>adm @< IP de destino>:/usr/sap/<SID>/
rsync -avhz –partial /sapmnt/<SID>/ <sid>adm @<IP de destino>:/sapmnt/<SID>/
rsync -avhz –partial /usr/ sap/DAA
/home/daaadm
-a, –archive, modo de arquivamento, equivalente a -rlptgoD. Esta opção diz ao rsync para sincronizar diretórios recursivamente, transferir dispositivos especiais e bloquear, preservar links simbólicos, tempos de modificação, grupos, propriedade e permissões.
-z, –comprimir. Esta opção força o rsync a compactar os dados à medida que são enviados para a máquina de destino. Use esta opção somente se a conexão com a máquina remota for lenta.
-v, –verbose aumenta a verbosidade
–h, –números de saída legíveis por humanos em um formato legível por humanos
–progress mostra o progresso durante a transferência
1. Host ASCS e ERS ==> Requer o seguinte sistema de arquivos
/home/<sid>adm
/usr/sap
/usr/sap/DAA
/usr/sap/<SID>/ASCS60
/usr/sap/<SID>/ERS70
/sapmnt/<SID> ==> montagem comum existe em todos os servidores SAP
2. Valide o FS no servidor de destino e verifique as permissões com <sid>adm:sapsys após a sincronização em /usr/sap.
3. Verifique o arquivo host e mantenha “/etc/hosts” no banco de dados, Ascs, ERS, aplicativo e codifique o nome do host VIP com o IP do host físico.
4. Anexe as entradas ao arquivo /etc/services
5. Altere os arquivos de variáveis de ambiente se <SID> for diferente em todos os servidores APP
Vá para /home/<sid>adm
ls –alt
egrep <SID> .sap* – altere para target <SID> se SID for diferente
Chown –R <sid>adm:sapsys .sap*
Chown –R <sid>adm:sapsys *
Verifique o caminho inicial de <sid>adm,daaadm
Edite /usr/sap/sapservices adequadamente
Certifique-se de que os links abaixo estejam funcionando. Se não existir, crie-os
lrwxrwxrwx 1 sidadm sapsys 19 9 de novembro 18:49 perfil -> /sapmnt/<SID>/profile
lrwxrwxrwx 1 sidadm sapsys 18 9 de novembro 18:49 global -> /sapmnt/<SID>/global
/usr/sap/<SID> /SYS/exe
lrwxrwxrwx 1 sidadm sapsys 18 9 de novembro 18:50 uc -> /sapmnt/<SID>/exe/uc
lrwxrwxrwx 1 sidadm sapsys 19 9 de novembro 18:55 nuc -> /sapmnt/<SID>/exe/nuc
lrwxrwxrwx 1 sidadm sapsys 30 9 de novembro 18:56 dbg -> /sapmnt/<SID>/exe/uc/linuxx86_64
lrwxrwxrwx 1 sidadm sapsys 24 9 de novembro 18:56 executar -> /usr/sap/<SID>/SYS/exe /dbg
rsync – captura de tela de amostra de conclusão de sincronização para /sapmnt/SID
Verifique o armazenamento do usuário HDB e atualize com os detalhes necessários
Iniciar Databse
hdbuserstore SET DEFAULT DBHOSTNAME:35015 <schema> <Password>
sapcontrol -nr 00 -function StartService <SID>
sapcontrol -nr 00 -function Start
R3trans –d deve retornar (0000)
Iniciar servidor/s de aplicativo
sapcontrol -nr $$ -function StartService <SID>
sapcontrol -nr $$ -function StartSystem
Observe que Start iniciará instâncias locais enquanto StartSystem iniciará todas as instâncias
Arbit: Especialista em SAP S4/HANA
Pode não ser parecer fácil gerar valor para seus dados, mas a Arbit, pode ajudá-lo. Há 24 anos atuando com inteligência de dados, a Arbit possui especialistas para implementar as melhores soluções ao seu ambiente de negócios. Fale conosco agora mesmo