Essa lista de verificação foi projetada para os clientes que movem os aplicativos SAP para a infraestrutura como serviço do Azure. Os aplicativos SAP deste documento representam os produtos SAP que executam o kernel SAP, incluindo o SAP NetWeaver, o S/4HANA, o BW, o BW/4 e outros. Durante todo o projeto, um cliente e/ou parceiro SAP deve examinar a lista de verificação. É importante ter em mente que muitas das verificações são concluídas no início do projeto e durante a fase de planejamento. Quando a implantação estiver concluída, alterações simples na infraestrutura do Azure implantada ou em versões de software SAP poderão se tornar complexas.
Analise a lista de verificação ao chegar a marcos principais do projeto. Ao fazer isso, você pode detectar pequenos problemas antes que eles se tornem grandes. Você também terá tempo suficiente para remodelar e testar todas as alterações necessárias. Não considere essa lista de verificação concluída. Dependendo da situação, talvez seja necessário executar verificações adicionais.
A lista de verificação não inclui tarefas que sejam independentes do Azure. Por exemplo, as interfaces dos aplicativos SAP são alteradas durante a migração para a plataforma do Azure ou para um provedor de hospedagem. A documentação e as notas de suporte do SAP também conterão outras tarefas, que não são específicas do Azure, mas que precisam fazer parte da lista de verificação de planejamento geral.
Essa lista de verificação também pode ser usada para sistemas que já estejam implantados. Os novos recursos ou as recomendações alteradas podem se aplicar ao seu ambiente. É importante analisar a lista de verificação periodicamente para estar ciente dos novos recursos da plataforma Azure.
O conteúdo principal deste documento é organizado em guias, na ordem cronológica de um projeto típico. Veja o conteúdo de cada guia e considere cada próxima guia para se basear nas ações realizadas e nos aprendizados obtidos na fase anterior. Para a migração de produção, o conteúdo de todas as guias deve ser considerado e não apenas a guia de produção. Para ajudar você a mapear as fases típicas do projeto com a definição de fase usada neste artigo, consulte a tabela abaixo.
| Fases da lista de verificação da implantação |
Exemplos de fases ou marcos de projeto |
| Fase de preparação e planejamento |
Início do projeto/fase de design e definição |
| Fase piloto |
Validação antecipada/prova de conceito/piloto |
| Fase não de produção |
Conclusão do design detalhado/builds do ambiente de não produção/fase de teste |
| Fase de preparação da produção |
Ensaio final/teste de aceitação do usuário/simulação de substituição/verificações de ativação |
| Fase de ativação |
Substituição e ativação em produção |
| Fase de pós-produção |
Implementação/transição para os negócios como de costume |
Fase de planejamento e preparação do projeto
Durante essa fase, a migração da carga de trabalho do SAP é planejada para a plataforma Azure. Documentos como guia de planejamento para SAP do Azure e Cloud Adoption Framework para SAP abordam muitos tópicos e ajudam como informações na sua preparação. Durante essa fase, você precisa criar, no mínimo, os seguintes documentos, além de definir e discutir os seguintes elementos da migração:
Documento de design de alto nível
Este documento deve conter:
- O inventário atual de aplicativos e componentes SAP e inventário de um aplicativo de destino para o Azure.
- Uma RACI (matriz de atribuição de responsabilidade) que define as responsabilidades e atribuições das partes envolvidas. Inicie em um nível alto e trabalhe para níveis mais granulares no planejamento e nas primeiras implantações.
- Uma arquitetura de solução de alto nível. As melhores práticas e os exemplos de arquiteturas do Centro de Arquitetura do Azure devem ser consultados.
- Uma decisão sobre em quais regiões do Azure implantar. Confira a lista de regiões do Azure e a lista de regiões com suporte à zona de disponibilidade. Para saber quais serviços estão disponíveis em cada região, confira Produtos disponíveis por região.
- Arquitetura de rede para conectar-se do local ao Azure. Comece a se familiarizar com o conceito de zona de destino de escala empresarial do Azure.
- Princípios de segurança para executar dados empresariais de alto impacto no Azure. Para saber mais sobre a segurança de dados, comece com a documentação de segurança do Azure.
- Estratégia de armazenamento para abranger os dispositivos de bloco (disco gerenciado) e os sistemas de arquivos compartilhados (como os Arquivos do Azure ou o Azure NetApp Files) que devem ser refinados ainda mais para tamanhos e layouts do sistema de arquivos no documento de design técnico.
Documento de design técnico
Este documento deve conter:
- Um diagrama de bloco para a solução que mostra os aplicativos e os serviços SAP e não SAP
- Um projeto do SAP Quicksizer baseado em volumes de documentos corporativos. A saída do Quicksizer é mapeada para componentes de computação, armazenamento e rede no Azure. Como alternativa ao SAP Quicksizer, o dimensionamento diligente com base na carga de trabalho atual dos sistemas SAP de origem. Levando em conta as informações disponíveis, como relatórios de carga de trabalho do DBMS, Relatórios do SAP EarlyWatch e indicadores de desempenho de computação e armazenamento.
- Arquitetura de recuperação de desastre e continuidade dos negócios.
- Informações detalhadas sobre as versões do sistema operacional, DB, kernel e do pacote de suporte do SAP. Nem todas as versões do sistema operacional com suporte do SAP NetWeaver ou S/4HANA têm necessariamente suporte em VMs do Azure. Isso também ocorre nas versões do DBMS. Verifique as seguintes fontes para alinhar e, se necessário, atualizar as versões do SAP, as versões do DBMS e as versões do sistema operacional para garantir o suporte do SAP e do Azure. Você precisa ter combinações de versão com suporte do SAP e do Azure para obter suporte total do SAP e da Microsoft. Se necessário, planeje a atualização de alguns componentes de software. Mais detalhes sobre o software SAP, sistema operacional e DBMS com suporte estão documentados aqui:
Outros itens a serem incluídos nos mesmos documentos técnicos:
- Decisões de alto nível da Arquitetura de Armazenamento com base nos tipos de armazenamento do Azure para carga de trabalho SAP
- Managed Disks anexado a cada VM
- Layouts e dimensionamento do sistema de arquivos
- Layout e tamanhos de volume SMB e/ou NFS e pontos de montagem, quando aplicável
- Arquitetura de alta disponibilidade, backup e recuperação de desastre
- Com base em RTO e RPO, defina como a arquitetura de alta disponibilidade e recuperação de desastre deve ser.
- Entenda o uso de diferentes tipos de implantação para a proteção ideal.
- Considerações sobre a implantação do DBMS das Máquinas Virtuais do Azure para cargas de trabalho SAP e documentos relacionados. No Azure, não há suporte para o uso de uma configuração de disco compartilhado na camada do DBMS, por exemplo, conforme descrito para o SQL Server. Em vez disso, use soluções como:
- Para a recuperação de desastre em regiões do Azure, examine as soluções oferecidas por diferentes fornecedores de DBMS. A maioria dá suporte para replicação assíncrona ou envio de logs.
- Para a camada de aplicativo SAP, determine se você executará seus sistemas de teste de regressão empresarial, que idealmente são réplicas de suas implantações de produção, na mesma região do Azure ou na sua região de recuperação de desastre. No segundo caso, você pode direcionar esse sistema de regressão empresarial como destino de recuperação de desastre para suas implantações de produção.
- Avalie o Azure Site Recovery como um método para replicar a camada de aplicativo SAP para a região de DR do Azure. Para obter mais informações, confira Configurar a recuperação de desastre para uma implantação de aplicativo SAP NetWeaver de várias camadas.
- Para os projetos que precisam permanecer em uma só região por motivos de conformidade, considere o uso de uma configuração de HADR combinada usando as Zonas de Disponibilidade do Azure.
- Um inventário de todas as interfaces SAP e os sistemas conectados (SAP e não SAP).
- Design de serviços de base. Esse design deve incluir os seguintes itens, muitos dos quais são abordados pelo acelerador de zona de destino para SAP:
- Topologia de rede no Azure e atribuição de um ambiente SAP diferente
- Design de DNS e Active Directory.
- Solução de gerenciamento de identidades para usuários finais e administração
- Estrutura do RBAC (Controle de acesso baseado em função) do Azure para equipes que gerenciam infraestruturas e aplicativos SAP no Azure.
- Estratégia de nomeação de recursos do Azure
- Operações de segurança para cargas de trabalho e recursos internos do Azure
- Conceito de segurança para proteger sua carga de trabalho do SAP. Isso deve incluir todos os aspectos: monitoramento de rede e perímetro, segurança de aplicativos e bancos de dados, proteção de sistemas operacionais e todas as medidas de infraestrutura necessárias, como criptografia. Identifique os requisitos com suas equipes de conformidade e segurança.
- A Microsoft recomenda o contrato Professional Direct, Premier ou Suporte Unificado. Identifique os caminhos de escalonamento e os contatos de suporte com a Microsoft. Para ver os requisitos de suporte do SAP, confira Nota SAP 2015553.
- O número de assinaturas do Azure e a cota central para as assinaturas.
Abra solicitações de suporte para aumentar as cotas de assinaturas do Azure conforme necessário.
- Plano de migração de dados e redução de dados para migrar dados do SAP para o Azure. Para sistemas SAP NetWeaver, o SAP tem diretrizes sobre como limitar o volume de uma grande quantidade de dados. Consulte este guia do SAP sobre o gerenciamento de dados em sistemas de ERP do SAP. Parte do conteúdo também se aplica aos sistemas NetWeaver e S/4HANA em geral.
- Uma abordagem de implantação automatizada. Muitos clientes começam com scripts, usando uma combinação do PowerShell, da CLI, do Ansible e do Terraform.
As soluções desenvolvidas pela Microsoft para a automação da implantação SAP são:
Observação
Definir uma cadência regular de análise de design e implantação entre você como cliente, o integrador de sistema, a Microsoft e outras partes envolvidas.
Fase piloto (fortemente recomendada)
Você pode executar um piloto antes ou durante o planejamento e a preparação do projeto. Também pode usar a fase piloto para testar abordagens e designs feitos durante a fase de planejamento e preparação. E você pode expandir a fase piloto para torná-la uma prova de conceito real.
Recomendamos configurar e validar uma solução HADR completa e um design de segurança durante uma implantação piloto. Alguns clientes executam testes de escalabilidade durante essa fase. Outros clientes usam implantações de sistemas de área restrita do SAP como fase piloto. Supomos que você já tenha identificado um sistema que deseja migrar para o Azure para o piloto.
- Otimize a transferência de dados para o Azure. A opção ideal depende muito do cenário específico. Se a conectividade privada for necessária para a replicação de banco de dados, o Azure ExpressRoute será mais rápido se o circuito do ExpressRoute tiver largura de banda suficiente. Em qualquer outro cenário, a transferência pela Internet é mais rápida. Opcionalmente, use uma VPN de migração dedicada para conectividade privada com o Azure. Qualquer caminho de rede de migração durante o piloto deve espelhar o uso para sistemas de produção futuros, eliminando qualquer impacto nas cargas de trabalho (SAP ou não SAP) que já estão em execução no Azure.
- Para uma migração SAP heterogênea que envolve uma exportação e uma importação de dados, teste e otimize as fases de exportação e importação. Para a migração de ambientes SAP grandes, siga as melhores práticas disponíveis. Use a ferramenta apropriada para o cenário de migração, dependendo das versões SAP de origem e de destino, do DBMS e do fato de você combinar a migração com outras tarefas, como atualização de versão ou até a conversão Unicode ou S/4HANA. O SAP fornece o Monitor de Migração/SWPM, o SAP DMO ou o DMO com a movimentação do sistema, além de outras abordagens para minimizar o tempo de inatividade disponível como um serviço separado do SAP. Nas últimas versões do SAP DMO com a movimentação do sistema, também há suporte para o uso do Azcopy para a transferência de dados pela Internet, permitindo o caminho de rede mais rápido nativamente.
Migrar VLDB (bancos de dados muito grandes) para o Azure para SAP
Validação técnica
Tipos de computação/VM
- Examine os recursos nas notas de suporte do SAP, no diretório de hardware SAP HANA e no PAM do SAP novamente. Faça a correspondência das VMs compatíveis para o Azure, das versões do sistema operacional compatíveis para esses tipos de VMs e das versões compatíveis do SAP e do DBMS.
- Valide novamente o dimensionamento do seu aplicativo e a infraestrutura que você implanta no Azure. Se você pretende migrar os aplicativos existentes, geralmente pode obter os SAPS necessários da infraestrutura usada e da página da Web de parâmetros de comparação SAP e compará-los com os números SAPS listados na Nota SAP 1928533. Além disso, tenha este artigo sobre as classificações de SAPS em mente.
- Avalie e teste o dimensionamento das suas VMs do Azure em relação à taxa de transferência máxima de armazenamento e de rede dos tipos de VM que você escolheu durante a fase de planejamento. Os detalhes dos limites de desempenho da VM estão disponíveis. Para o armazenamento, é importante considerar o limite da taxa de transferência máxima de disco não armazenado em cache para dimensionamento. Considere cuidadosamente o dimensionamento e os efeitos temporários da intermitência no disco e na VM.
- Teste e determine se deseja criar suas imagens do sistema operacional para as VMs no Azure ou usar uma imagem da Galeria de Computação do Azure (antiga Galeria de Imagens Compartilhadas). Se você estiver usando uma imagem da Galeria de Computação do Azure, lembre-se de usar uma imagem que reflita o contrato de suporte com o fornecedor do sistema operacional. Para alguns fornecedores de sistema operacional, a Galeria de Computação do Azure permite que você traga suas próprias imagens de licença. Para outras imagens do sistema operacional, o suporte está incluído no preço cotado pelo Azure.
- O uso de imagens de sistema operacional próprias permite que você armazene as dependências corporativas necessárias, como agentes de segurança, proteção e personalizações diretamente na imagem. Dessa forma, elas são implantadas imediatamente com todas as VMs. Se você decidir criar suas próprias imagens de sistema operacional, poderá encontrar documentação nestes artigos:
- Se você usar imagens do Linux da Galeria de Computação do Azure e adicionar a proteção como parte do pipeline de implantação, precisará usar as imagens adequadas para o SAP fornecidas pelos fornecedores do Linux.
- A escolha de uma imagem do sistema operacional determina o tipo de geração da VM do Azure. O Azure dá suporte a VMs de geração 1 e 2 do Hyper-V. Algumas famílias de VMs estão disponíveis apenas como geração 2 e outras estão certificadas para uso do SAP apenas como geração 2 (Nota SAP 1928533), mesmo que o Azure permita as duas gerações.
Recomendamos usar a VM de geração 2 para todas as VMs do cenário do SAP.
Storage
- Leia o documento Tipos de armazenamento do Azure para carga de trabalho SAP
- Use o armazenamento premium do Azure, o armazenamento premium v2 para todos os ambientes SAP de nível de produção e ao garantir um SLA alto. Para alguns DBMSs, o Azure NetApp Files pode ser usado para uma grande parte dos requisitos gerais de armazenamento.
- No mínimo, use o armazenamento de SSD Standard do Azure para as VMs que representem as camadas do aplicativo SAP e para a implantação de DBMSs que não sejam sensíveis ao desempenho. Tenha em mente que diferentes tipos de armazenamento do Azure influenciam o SLA de disponibilidade de VM individual.
- Em geral, não recomendamos o uso de discos HD Standard do Azure para o SAP.
- Para os diferentes tipos de DBMS, confira a documentação genérica do DBMS relacionada ao SAP e a documentação específica do DBMS indicada pelo primeiro documento. Use a distribuição de disco em vários discos com o armazenamento premium (v1 ou v2) para os dados de banco de dados e a área de log. Verifique se a distribuição de disco LVM está ativa e com o tamanho correto de faixa com o comando 'lvs -a -o+lv_layout,lv_role,stripes,stripe_size,devices' no Linux. Confira as propriedades de espaços de armazenamento no Windows.
- Para obter a configuração de armazenamento ideal com o SAP HANA, confira Configurações de armazenamento de máquina virtual do Azure do SAP HANA.
- Use a LVM para todos os discos em VMs do Linux, pois ela permite um gerenciamento e uma expansão online mais fáceis. Isso inclui volumes em discos individuais, por exemplo /usr/sap.
Rede
- Teste e avalie sua infraestrutura de rede virtual e a distribuição de seus aplicativos SAP entre ou dentro das diferentes redes virtuais do Azure.
- Avalie a abordagem da arquitetura de rede virtual hub-spoke ou WAN virtual com spokes discretos de rede virtual para a carga de trabalho SAP. Para uma escala menor, a abordagem de microssegmentação em uma rede virtual individual do Azure. Baseie esta avaliação em:
- Custos da troca de dados entre as redes virtuais emparelhadas do Azure
- Vantagens de uma rápida desconexão do emparelhamento entre redes virtuais do Azure em vez de alterar o grupo de segurança de rede para isolar uma sub-rede em uma rede virtual. Essa avaliação é para casos em que os aplicativos ou as VMs hospedadas em uma sub-rede da rede virtual se tornaram um risco à segurança.
- Registro em log central e auditoria de tráfego de rede entre locais, o mundo exterior e o datacenter virtual criado no Azure.
- Avalie e teste o caminho de dados entre a camada de aplicativo SAP e a camada do SAP DBMS.
- Verifique se a rede acelerada está habilitada em todas as VMs usadas para o SAP.
- Teste e avalie a latência de rede entre as VMs da camada de aplicativo SAP e as VMs do DBMS, de acordo com as notas SAP 500235 e 1100926. Além do niping do SAP, você pode usar ferramentas como o sockperf ou o ethr para a medição da latência TCP. Avalie os resultados em relação às diretrizes de latência de rede na nota SAP 1100926. A latência de rede deve estar no intervalo entre moderada e boa.
- Otimize a taxa de transferência de rede nas VMs de vCPU alta, normalmente usadas para servidores de banco de dados. Particularmente importante para a expansão do HANA e qualquer sistema SAP grande. Siga as recomendações descritas neste artigo para otimização.
- Para obter a latência de rede ideal, considere seguir as diretrizes no artigo de cenários de posicionamento por proximidade. Sem uso de grupos de posicionamento por proximidade para padrões de implantação de zona ou entre zonas.
- Verifique a disponibilidade correta, o roteamento e o acesso seguro do cenário do SAP a qualquer ponto de extremidade da Internet necessário, como repositórios de patch do sistema operacional, ferramentas de implantação ou ponto de extremidade de serviço. Da mesma forma, se o ambiente SAP fornecer um serviço publicamente acessível, como o SAP Fiori ou o SAProuter, verifique se ele pode ser acessado e está protegido.
Implantações de alta disponibilidade e recuperação de desastre
- Sempre use o balanceador de carga padrão para ambientes clusterizados. O balanceador de carga básico será desativado.
- Selecione as opções de implantação adequadas, dependendo das suas configurações preferenciais do sistema em uma região do Azure – se elas envolvem a abrangência entre zonas, residir em uma única zona ou operar em uma região sem zona.
- Na implantação regional, para proteger os serviços centrais do SAP e as camadas DBMS para alta disponibilidade usando a replicação passiva, coloque os dois nós dos Serviços Centrais do SAP em um conjunto de disponibilidade separado e os dois nós DBMS em outro conjunto de disponibilidade. Não combine as funções VM do aplicativo em um conjunto de disponibilidade.
- Para implantação entre zonas, configure o sistema usando o conjunto de dimensionamento flexível com FD=1 e implante os nós de serviços centrais ativos e passivos e a camada DBMS em duas zonas de disponibilidade diferentes. Use duas zonas de disponibilidade com a menor latência entre elas.
- Para implantação entre zonas, é recomendável usar o conjunto de dimensionamento flexível com FD=1 em vez de uma implantação de zona de disponibilidade padrão.
- Caso esteja usando o Azure Load Balancer em conjunto com os sistemas operacionais convidados do Linux, verifique se o parâmetro de rede do Linux net.ipv4.tcp_timestamps está definido como 0. Essa recomendação entra em conflito com as recomendações descritas em versões mais antigas da Nota SAP 2382421. A nota SAP agora é atualizada para declarar que esse parâmetro precisa ser definido como 0 para funcionar com os balanceadores de carga do Azure.
Configurações de tempo limite
- Examine os rastreamentos de desenvolvedor do SAP NetWeaver de instâncias da SAP para garantir que não haja nenhuma interrupção de conexão entre o servidor de enfileiramento e os processos de trabalho do SAP. É possível evitar essas interrupções de conexão definindo estes dois parâmetros de registro:
- HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Para obter mais informações, consulte KeepAliveTime.
- HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Para obter mais informações, consulte KeepAliveInterval.
- Para evitar tempos limites de GUI entre GUIs de SAP locais e camadas de aplicativo SAP implantadas no Azure, verifique se os parâmetros foram definidos no default.pfl ou no perfil da instância:
- rdisp/keepalive_timeout = 3600
- rdisp/keepalive = 20
- Para evitar a interrupção de conexões estabelecidas entre o processo de enfileiramento do SAP e os processos de trabalho do SAP, defina o parâmetro enque/encni/set_so_keepalive como
TRUE. Confira também Nota SAP 2743751.
- Se você usar uma configuração de cluster de failover do Windows, verifique se o tempo para reagir em nós não responsivos está definido corretamente para o Azure. O artigo Ajustando limites de rede de cluster de failover lista parâmetros e como eles afetam as sensibilidades de failover. Supondo que os nós de cluster estejam na mesma sub-rede, altere esses parâmetros:
- SameSubNetDelay = 2000 (número de milissegundos entre as “pulsações”)
- SameSubNetThreshold = 15 (número máximo de pulsações perdidas consecutivas)
- RoutingHistorylength = 30 (segundos, 2000 ms * 15 pulsações = 30s)
Configurações ou patches do sistema operacional
- Para executar o HANA no SAP, leia estas notas e a documentação, além da documentação não específica não do Azure do SAP e outras notas de suporte:
Verificações adicionais para a fase piloto
Testar os procedimentos de alta disponibilidade e recuperação de desastre
- Simule as situações de failover usando uma ferramenta como o NotMyFault (Windows) ou colocando os sistemas operacionais no modo de pânico ou desabilitando o adaptador de rede com o ifdown (Linux). Esta etapa ajudará você a descobrir se suas configurações de failover funcionam conforme projetado.
- Meça quanto tempo leva para executar um failover. Se os tempos forem muito longos, cogite:
- Para o SUSE Linux, usar dispositivos SBD em vez do agente de isolamento do Azure para acelerar o failover.
- Para o SAP HANA, se o recarregamento de dados levar muito tempo, considere provisionar mais largura de banda de armazenamento.
- Teste a sequência de backup/restauração e o tempo e faça correções, se necessário. Verifique se os tempos de backup são suficientes. Você também precisa testar a restauração e as atividades de restauração de tempo. Verifique se os tempos de restauração estão dentro de seus SLAs de RTO em que o RTO se baseia em um banco de dados ou processo de restauração de VM.
- Testar a funcionalidade e a arquitetura de DR entre regiões e verificar se o RPO e o RTO correspondem às suas expectativas
Verificações de segurança
- Teste a validade da arquitetura do Azure RBAC (controle de acesso baseado em função). A diferenciação de direitos exige a separação e a limitação do acesso e das permissões de diferentes equipes. Por exemplo, os membros da equipe do SAP Basis devem ter a capacidade de implantar VMs e atribuir discos por meio do Armazenamento do Microsoft Azure em determinada rede virtual do Azure. Mas a equipe SAP de Base não deve poder criar as próprias redes virtuais ou alterar as configurações de redes virtuais existentes. Os membros da equipe de rede não devem poder implantar VMs em redes virtuais nas quais VMs do DBMS e do aplicativo SAP estejam em execução. Os membros desta equipe também não devem poder alterar os atributos de VMs nem mesmo excluir VMs ou discos.
- Verifique se o grupo de segurança de rede e as regras de ASC funcionam conforme o esperado e proteja os recursos protegidos.
- Verifique se todos os recursos que precisam ser criptografados foram criptografados. Defina e implemente processos para fazer backup de certificados, armazenar e acessar esses certificados e restaurar as entidades criptografadas.
- Para a criptografia de armazenamento, a criptografia do lado do servidor com a SSE-PMK (chave gerenciada por plataforma) é habilitada para todos os serviços de armazenamento usados para SAP no Azure por padrão, incluindo discos gerenciados, Arquivos do Azure e Azure NetApp Files.
O gerenciamento de chaves com chaves gerenciadas pelo cliente pode ser considerado, se necessário, para a rotação de chave de propriedade do cliente.
-
A criptografia do lado do servidor baseada em host não deve ser habilitada por motivos de desempenho em VMs Linux na família da série M.
- Não use o Azure Disk Encryption com o SAP, pois não há suporte para imagens do sistema operacional ‘para SAP’.
- A criptografia nativa do banco de dados é implantada pela maioria dos clientes do SAP no Azure para proteger dados e backups do DBMS. A TDE (Transparent Data Encryption) normalmente não tem uma sobrecarga de desempenho perceptível, aumenta muito a segurança e deve ser considerada. O gerenciamento e o local da chave de criptografia devem ser protegidos. A criptografia de banco de dados ocorre dentro da VM e é independente de qualquer criptografia de armazenamento, como a SSE.
Teste de desempenho No SAP, com base no rastreamento e nas medições do SAP, faça estas comparações:
- Inventário e linha de base do sistema local atual.
- Relatórios SAR / perfmon.
- Dez principais relatórios online do rastreamento STAT.
- Colete o histórico de trabalho em lotes.
- Teste de foco para verificar o desempenho dos processos de negócios. Não compare os KPIs de hardware inicialmente e em um vácuo, somente ao solucionar problemas de diferenças de desempenho.
- Quando aplicável, compare os 10 principais relatórios online para sua implementação atual.
- Quando aplicável, compare os 10 principais trabalhos de lote com sua implementação atual.
- Compare transferências de dados por meio de interfaces no sistema SAP. Concentre-se nas interfaces em que você sabe que a transferência ocorre entre diferentes locais, como do local para o Azure.
Fase não de produção
Nesta fase, vamos supor que, após um piloto ou POC (prova de conceito) bem-sucedida, você esteja começando a implantar sistemas SAP que não sejam de produção no Azure. Incorpore tudo o que aprendeu e experimentou durante a POC para essa implantação. Todos os critérios e etapas listados para POCs também se aplicam a essa implantação.
Durante esta fase, você geralmente implanta sistemas de desenvolvimento, sistemas de testes de unidade e sistemas de testes de regressão empresarial para o Azure. É recomendável que pelo menos um sistema não de produção em uma linha de aplicativo SAP tenha a configuração de alta disponibilidade completa que o sistema de produção futuro terá. Estas são algumas tarefas que você precisará concluir durante esta fase:
- Antes de mover sistemas da plataforma antigos para o Azure, colete dados de consumo de recursos, como o uso da CPU, taxa de transferência de armazenamento e dados IOPS. Colete esses dados especialmente das unidades de camada DBMS, mas também das unidades da camada de aplicativo. Também meça a latência de rede e de armazenamento. Adapte o dimensionamento e o design com os dados capturados. Ferramentas como o syststat, o KSAR, o nmon e o nmon analyzer for Excel devem ser usadas para capturar e apresentar a utilização de recursos em períodos de pico.
- Registre os padrões de tempo de uso de disponibilidade dos seus sistemas. A meta é descobrir se os sistemas que não são de produção precisam estar disponíveis ininterruptamente, ou se há sistemas que não são de produção que podem ser desligados durante determinadas fases de uma semana ou mês.
- Reavalie sua escolha de imagem do sistema operacional, geração da VM (Geração 2 em todo o cenário do SAP) e a estratégia de patch do sistema operacional.
- Certifique-se de atender aos requisitos de suporte do SAP para contratos de suporte da Microsoft. Confira Nota SAP 2015553.
- Confira as notas SAP relacionadas ao Azure, como a nota 1928533, para novas SKUs de VM e versões do DBMS ou do sistema operacional com suporte recente. Compare o preço dos novos tipos de VM com tipos de VM mais antigos, para implantar VMs com a melhor relação entre preço e desempenho.
- Verifique novamente as notas de suporte do SAP, o diretório de hardware do SAP HANA e o PAM do SAP. Verifique se não houve nenhuma alteração nas VMs compatíveis para o Azure, nas versões de sistema operacional compatíveis naquelas VMs e as versões compatíveis de SAP e DBMS.
- Acesse o site do SAP para conhecer as novas SKUs com certificação do HANA no Azure. Compare os preços de novas SKUs com as que você planejou usar. Por fim, faça as alterações necessárias para usar aquelas com a melhor relação entre preço e desempenho.
- Adapte a automação de implantação para usar os novos tipos de VMs e incorporar novos recursos do Azure que deseja usar.
- Após a implantação da infraestrutura, teste e avalie a latência de rede entre as VMs da camada de aplicativo SAP e as VMs do DBMS, de acordo com as notas SAP 500235. Avalie os resultados em relação às diretrizes de latência de rede na nota SAP 1100926. A latência de rede deve estar no intervalo entre moderada e boa. Além de usar ferramentas como o niping, o sockperf ou o ethr, use a ferramenta HCMT do SAP para as medições de rede entre as VMs do HANA para expansão ou replicação do sistema.
- Verifique se nenhuma das restrições mencionadas em Considerações para implantação do DBMS de Máquinas Virtuais do Azure para cargas de trabalho SAP e Configurações e operações de infraestrutura SAP HANA no Azure se aplicam à sua implantação.
- Se você estiver vendo uma latência maior do que a esperada entre VMs, considere seguir as diretrizes no artigo de cenários de posicionamento por proximidade.
- Execute todas as outras verificações listadas para a fase de prova de conceito antes de aplicar a carga de trabalho.
- Ao aplicar a carga de trabalho, registre o consumo de recursos dos sistemas no Azure. Compare esse consumo com registros de sua plataforma antiga. Ajuste o dimensionamento da VM de implantações futuras se você detectar que há diferenças grandes. Tenha em mente que, ao diminuir o tamanho, o armazenamento e a largura de banda de rede das VMs também serão reduzidos.
- Teste processos e funcionalidade de cópia do sistema. A meta é tornar mais fácil para você copiar um sistema de desenvolvimento ou um sistema de teste para que as equipes de projeto possam obter novos sistemas rapidamente.
- Otimize e aprimore o acesso, as permissões e os processos baseados em função do Azure da sua equipe para verificar se você tem separação de tarefas. Ao mesmo tempo, verifique se todas as equipes podem executar suas tarefas na infraestrutura do Azure.
- Exercite, teste e documente procedimentos de alta disponibilidade e recuperação de desastres para permitir que a sua equipe executar essas tarefas. Identifique deficiências e adapte nova funcionalidade do Azure que você esteja integrando em suas implantações.
Fase de preparação da produção
Nesta fase, colete o que você experimentou e aprendeu durante suas implantações que não sejam de produção e aplique-as às implantações futuras de produção.
- Faça as atualizações da versão SAP necessárias dos sistemas de produção antes de migrar para o Azure.
- Concorde com os proprietários de negócios sobre os testes funcionais e empresariais que precisam ser feitos após a migração do sistema de produção.
- Verifique se esses testes são concluídos com os sistemas de origem na localização de hospedagem atual. Evite realizar testes pela primeira vez depois que o sistema migrar para o Azure.
- Teste o processo de migração de sistemas de produção para o Azure. Se você não mover todos os sistemas de produção para o Azure durante o mesmo período, crie grupos de sistemas de produção que precisam estar na mesma localização de hospedagem. Teste a migração de dados, incluindo as interfaces e os aplicativos não SAP conectados.
Aqui estão alguns métodos comuns:
- Use métodos do DBMS como backup/restauração em combinação com o SQL Server Always On, a Replicação de Sistema HANA ou o envio de log para propagar e sincronizar o conteúdo do banco de dados no Azure.
- Usar backup/restauração para bancos de dados menores.
- Use o processo SAP DMO para cenários com suporte para migrar ou se você precisar combinar a migração com uma atualização de versão do SAP e/ou migrar para o HANA. Saiba que nem todas as combinações de DBMS de origem e de destino têm suporte. Mais informações podem ser encontradas nas notas de suporte SAP específicas para as diferentes versões do DMO. Por exemplo, DMO (Opção de Migração de Banco de Dados) de SUM 2.0 SP15.
- Teste se a taxa da transferência de dados é melhor pela Internet ou pelo ExpressRoute, caso precise mover backups ou arquivos de exportação SAP. Se você mover dados pela Internet, talvez seja necessário alterar algumas de suas regras de grupo de segurança de aplicativo/grupo de segurança de rede que você precisará ter em vigor para futuros sistemas de produção.
- Antes de mover os sistemas de sua plataforma antiga para o Azure, colete os dados de consumo dos recursos. Entre os dados úteis temos uso de CPU, taxa de transferência de armazenamento e dados de IOPS. Colete esses dados especialmente das unidades de camada DBMS, mas também das unidades da camada de aplicativo. Também meça a latência de rede e de armazenamento.
- Verifique novamente as notas SAP e as configurações necessárias do sistema operacional, o diretório de hardware do SAP HANA e o PAM do SAP. Verifique se não houve nenhuma alteração nas VMs compatíveis para o Azure, nas versões de sistema operacional compatíveis naquelas VMs e as versões compatíveis de SAP e DBMS.
- Atualize a automação de implantação para considerar as decisões mais recentes tomadas sobre os tipos de VMs e as funcionalidades do Azure.
- Crie um guia estratégico para responder aos eventos de manutenção planejada do Azure. Determine a ordem na qual os sistemas e as VMs devem ser reinicializados para manutenção planejada.
- Exercite, teste e documente os procedimentos de alta disponibilidade e recuperação de desastre para permitir que sua equipe execute essas tarefas durante a migração e imediatamente após a decisão de ativação.
Fase de ativação
Durante a fase de ativação, não se esqueça de seguir os guias estratégicos desenvolvidos durante as fases anteriores. Execute as etapas que você testou e treinou. Não aceite as alterações de última hora a configurações e processos. Conclua também estas etapas:
- Verifique se o monitoramento do portal do Azure e outras ferramentas de monitoramento estão funcionando. Use ferramentas do Azure, como o Azure Monitor, para o monitoramento da infraestrutura.
Azure Monitor para SAP, para uma combinação de KPIs de sistema operacional e de aplicativo, permitindo que você integre tudo em um só painel para visibilidade durante e após a ativação.
Para os indicadores chave de desempenho do sistema operacional:
- Após a migração dos dados, execute todos os testes de validação acordado com os proprietários do negócio. Só aceite os resultados de teste de validação quando tiver resultados para os sistemas de fonte originais.
- Verificar se as interfaces estão funcionando e se outros aplicativos podem se comunicar com os sistemas de produção implantados recentemente.
- Verificar o sistema de transporte e de correção por meio do STMS da transação SAP.
- Executar backups de Banco de Dados depois que o sistema for liberado para produção.
- Executar backups de VM para as VMs da camada de aplicativo SAP depois que o sistema for liberado para produção.
- Para sistemas SAP que não fazem parte da atual fase de ativação, mas se comunicam com sistemas SAP que você moveu para o Azure durante esta fase de ativação, você precisará redefinir o buffer do nome de host em SM51. Isso removerá os antigos endereços IP em cache associados aos nomes das instâncias do aplicativo que você moveu para o Azure.
Após a produção
Esta fase trata do monitoramento, da operação e da administração do sistema. Do ponto de vista do SAP, as tarefas normais que você precisava concluir em sua antiga localização de hospedagem se aplicam. Concluir também estas tarefas específicas do Azure:
- Analisar faturas do Azure para sistemas de cobrança alta. Instale uma cultura de finOps e crie uma funcionalidade de otimização de custos do Azure na sua organização.
- Otimizar a eficiência de preço/desempenho no lado da VM e do armazenamento.
- Depois que o SAP no Azure estiver estabilizado, seu foco precisará mudar para uma cultura de dimensionamento contínuo e revisões de capacidade. Ao contrário do local, em que fazemos o dimensionamento por um longo período, o dimensionamento correto é um benefício essencial da execução da carga de trabalho do SAP no Azure e o planejamento diligente da capacidade será fundamental.
- Otimizar os horários em que você pode desligar os sistemas.
- Depois que a solução estiver estabilizada no Azure, considere a possibilidade de se afastar de um modelo comercial pago conforme o uso e aproveitar as instâncias reservadas do Azure.
- Planeje e execute simulações regulares de recuperação de desastre.
- Defina e implemente sua estratégia em relação à ‘renovação automática’, para alinhar seu roteiro com o roteiro do SAP no Azure da Microsoft a fim de se beneficiar do avanço da tecnologia.
Lista de verificação de infraestrutura do SAP no Azure
Depois de implantar a infraestrutura e os aplicativos e antes de cada migração ser iniciada, valide se:
- Os tipos de VMs corretos foram implantados com os atributos e a configuração de armazenamento corretos.
- As VMs estão em um sistema operacional, um DBMS e uma versão e um patch do kernel SAP atualizados e se o sistema operacional, o BD e o kernel SAP são uniformes em todo o cenário
- As VMs estão protegidas conforme necessário e de maneira uniforme em todo o respectivo ambiente.
- As VMs foram implantadas em um conjunto de dimensionamento flexível com FD=1 entre zonas de disponibilidade ou em um conjunto de disponibilidade.
- As VMs de geração 2 foram implantadas. As VMs de geração 1 não devem ser usadas para novas implantações.
- O Armazenamento Premium do Azure ou o Armazenamento Premium v2 é usado para discos sensíveis à latência ou quando o SLA de VM individual de 99,9% é necessário.
- Verifique se, nas VMs, os espaços de armazenamento ou os conjuntos de distribuição foram criados corretamente em sistemas de arquivos que exigem mais do que o disco, como os dados do DBMS e as áreas de log.
- O tamanho correto da distribuição e do bloqueio do sistema de arquivos são usados, se indicado nos respectivos guias do DBMS
- O armazenamento e o cache da VM do Azure são usados adequadamente
- Verifique se apenas os discos que contêm os logs online do DBMS são armazenados em cache com o Acelerador de Gravação None+.
- Outros discos com o armazenamento premium estão usando as configurações de cache none ou ReadOnly, dependendo do uso
- Verifique a configuração do LVM em VMs do Linux no Azure.
- Os discos gerenciados do Azure ou os volumes NFS do Azure NetApp Files são usados exclusivamente para as VMs do DBMS.
- Para o Azure NetApp Files, as opções de montagem corretas são usadas e os volumes são dimensionados adequadamente na camada de armazenamento correta.
- Uso dos serviços do Azure (Arquivos do Azure ou Azure NetApp Files) para volumes ou compartilhamentos SMB ou NFS. Os volumes NFS ou os compartilhamentos SMB podem ser acessados pelo respectivo ambiente SAP ou por sistemas SAP individuais. O roteamento de rede para o servidor NFS/SMB passa pelo espaço de endereço de rede privada, usando o ponto de extremidade privado, se necessário.
- A rede acelerada do Azure está habilitada em todos os adaptadores de rede para todas as VMs do SAP.
- Não há nenhum dispositivo de rede virtual na rota de comunicação entre o aplicativo SAP e a camada do DBMS dos sistemas SAP baseados no SAP NetWeaver ou no ABAP Platform.
- Todos os balanceadores de carga para componentes de alta disponibilidade do SAP usam o balanceador de carga padrão com as portas de IP flutuante e HA habilitadas.
- O aplicativo SAP e as VMs do DBMS foram colocados em sub-redes iguais ou diferentes de uma rede virtual ou em redes virtuais emparelhadas diretamente.
- As regras de grupo de segurança de rede e de aplicativo permitem a comunicação conforme desejado e planejado, bloqueando a comunicação quando necessário.
- As configurações de tempo limite são definidas corretamente, conforme descritas anteriormente.
- Se estiver usando grupos de posicionamento por proximidade, verifique se os conjuntos de disponibilidade e as respectivas VMs estão implantados no PPG correto.
- A latência de rede entre as VMs da camada de aplicativo SAP e as VMs do DBMS é testada e validada, conforme descrito nas notas SAP 500235 e 1100926. Avalie os resultados em relação às diretrizes de latência de rede na nota SAP 1100926. A latência de rede deve estar no intervalo entre moderada e boa.
- A criptografia foi implementada quando necessário e com o método de criptografia apropriado.
- Chaves de criptografia próprias são protegidas contra perda, destruição ou uso mal-intencionado.
- Interfaces e outros aplicativos podem se conectar à infraestrutura recém-implantada.
Verificações e insights automatizados no cenário do SAP
Várias das verificações acima são feitas de maneira automatizada com a Ferramenta de Verificação de Qualidade do SAP no Azure. Essas verificações podem ser executadas de maneira automatizada com o projeto de código aberto fornecido. Embora nenhuma correção automática de problemas encontrados seja executada, a ferramenta alertará sobre a configuração em relação às recomendações da Microsoft.
Outras ferramentas para permitir verificações de implantação mais fáceis e descobertas de documentos, planejar as próximas etapas de correção e, geralmente, otimizar o cenário do SAP no Azure são:
-
Revisão do Azure Well-Architected Framework Uma avaliação da carga de trabalho com foco nos cinco principais pilares de confiabilidade, segurança, otimização de custos, excelência em operação e eficiência de desempenho. Dá suporte a cargas de trabalho SAP, e recomendamos executar uma revisão no início e após cada fase do projeto.
-
Verificações de Inventário do Azure para SAP Uma pasta de trabalho do Azure Monitor de código aberto, que mostra o inventário do Azure com inteligência para realçar o descompasso da configuração e aprimorar a qualidade.
Próximas etapas
Consulte estes artigos: