Cargas de trabalho SAP no Azure: lista de verificação de planeamento e implementação
Artigo
Esta lista de verificação foi projetada para clientes que movem aplicativos SAP para a infraestrutura do Azure como um serviço. Os aplicativos SAP neste documento representam produtos SAP que executam o kernel SAP, incluindo SAP NetWeaver, S/4HANA, BW e BW/4 e outros. Durante toda a duração do projeto, um cliente e/ou parceiro SAP deve rever a lista de verificação. É importante notar que muitas das verificações são concluídas no início do projeto e durante a fase de planejamento. Depois que a implantação for concluída, alterações diretas na infraestrutura do Azure implantada ou nas versões de software SAP podem se tornar complexas.
Analise a lista de verificação nos principais marcos durante o projeto. Isso permitirá que você detete pequenos problemas antes que eles se tornem grandes problemas. Você também terá tempo suficiente para reformular e testar as alterações necessárias. Não considere esta lista de verificação completa. Dependendo da sua situação, poderá ter de realizar mais verificações adicionais.
A lista de verificação não inclui tarefas independentes do Azure. Por exemplo, as interfaces de aplicativos SAP mudam durante uma mudança para a plataforma Azure ou para um provedor de hospedagem. As notas de documentação e suporte do SAP também conterão outras tarefas, que não são específicas do Azure, mas precisam fazer parte da sua lista de verificação geral de planejamento.
Essa lista de verificação também pode ser usada para sistemas que já estão implantados. Novos recursos ou recomendações alteradas podem se aplicar ao seu ambiente. É útil revisar a lista de verificação periodicamente para garantir que você esteja ciente dos novos recursos na plataforma Azure.
O conteúdo principal deste documento está organizado em separadores, por ordem cronológica típica do projeto. Veja o conteúdo de cada guia e considere cada próxima guia para construir em cima das ações realizadas e 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 ajudá-lo 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 de implantação
Exemplo de fases ou marcos do projeto
Fase de preparação e planeamento
Fase de arranque/conceção e definição do projeto
Fase-piloto
Validação antecipada / prova de conceito / piloto
Fase de não produção
Conclusão do projeto detalhado / construção do ambiente de não-produção / fase de teste
Fase de preparação da produção
Ensaio geral / teste de aceitação do usuário / corte simulado / verificações go-live
Durante essa fase, você planeja a migração de sua carga de trabalho SAP para a plataforma Azure. Documentos como o guia de planejamento para SAP no Azure e o Cloud Adoption Framework for SAP abrangem muitos tópicos e ajudam como informações em sua preparação. No mínimo, durante essa fase, você precisa criar os seguintes documentos, 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 componentes e aplicativos SAP e um inventário de aplicativos de destino para o Azure.
Uma matriz de atribuição de responsabilidades (RACI) que define as responsabilidades e atribuições das partes envolvidas. Comece em um alto nível e trabalhe para níveis mais granulares durante o planejamento e as primeiras implantações.
Uma arquitetura de solução de alto nível. As práticas recomendadas e as arquiteturas de exemplo do Centro de Arquitetura do Azure devem ser consultadas.
Princípios de segurança para executar dados corporativos de alto impacto no Azure. Para saber mais sobre segurança de dados, comece com a documentação de segurança do Azure.
Estratégia de armazenamento para abranger dispositivos de bloco (Managed Disk) e sistemas de arquivos compartilhados (como Arquivos do Azure ou Arquivos NetApp do Azure) que devem ser ainda mais refinados para tamanhos e layouts de sistema de arquivos no documento de design técnico.
Documento de projeto técnico
Este documento deve conter:
Um diagrama de blocos para a solução mostrando os aplicativos e serviços SAP e não SAP
Um projeto SAP Quicksizer baseado em volumes de documentos de negócios. A saída do Quicksizer é então mapeada para componentes de computação, armazenamento e rede no Azure. Como alternativa ao SAP Quicksizer, dimensionamento diligente com base na carga de trabalho atual dos sistemas SAP de origem. Levando em consideração as informações disponíveis, como relatórios de carga de trabalho DBMS, relatórios SAP EarlyWatch e indicadores de desempenho de computação e armazenamento.
Continuidade de negócios e arquitetura de recuperação de desastres.
Informações detalhadas sobre as versões do pacote de suporte OS, DB, kernel e SAP. Não é necessariamente verdade que todas as versões do sistema operacional suportadas pelo SAP NetWeaver ou S/4HANA são suportadas em VMs do Azure. O mesmo vale para as versões DBMS. Verifique as seguintes fontes para alinhar e, se necessário, atualizar as versões SAP, DBMS e SO para garantir o suporte SAP e Azure. Você precisa ter combinações de versão suportadas pelo SAP e Azure para obter suporte total da SAP e da Microsoft. Se necessário, você precisa planejar a atualização de alguns componentes de software. Mais detalhes sobre os softwares SAP, OS e DBMS suportados estão documentados aqui:
Nota SAP 2039619. Esta nota define a matriz de suporte Oracle para o Azure. A Oracle suporta apenas Windows e Oracle Linux como sistemas operativos convidados no Azure para cargas de trabalho SAP. Esta declaração de suporte também se aplica à camada de aplicativos SAP que executa instâncias SAP, desde que elas contenham o Oracle Client.
As VMs do Azure suportadas pelo SAP HANA estão listadas no site da SAP. Os detalhes de cada entrada contêm especificidades e requisitos, incluindo a versão suportada do SO. Isso pode não corresponder à versão mais recente do sistema operacional, de acordo com a nota 2235581 da SAP.
Layout e tamanhos de volume SMB e/ou NFS, pontos de montagem, quando aplicável
Arquitetura de alta disponibilidade, backup e recuperação de desastres
Com base em RTO e RPO, defina como deve ser a arquitetura de alta disponibilidade e recuperação de desastres.
Compreenda o uso de diferentes tipos de implantação para uma proteção ideal.
Considerações para a implantação de DBMS de 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 para a camada DBMS como, por exemplo, descrita para o SQL Server. Em vez disso, use soluções como:
Para recuperação de desastres em regiões do Azure, analise as soluções oferecidas por diferentes fornecedores de DBMS. A maioria deles oferece suporte à replicação assíncrona ou ao envio de logs.
Para a camada de aplicativos SAP, determine se você executará seus sistemas de teste de regressão de negócios, que idealmente são réplicas de suas implantações de produção, na mesma região do Azure ou em sua região de DR. No segundo caso, você pode direcionar esse sistema de regressão de negócios como o destino de DR para suas implantações de produção.
Analise o Azure Site Recovery como um método para replicar a camada de aplicativo SAP na região de DR do Azure. Para obter mais informações, consulte uma recuperação de desastres de configuração para uma implantação de aplicativo SAP NetWeaver de várias camadas.
Para projetos que precisam permanecer em uma única região por motivos de conformidade, considere uma configuração HADR combinada usando as Zonas de Disponibilidade do Azure.
Um inventário de todas as interfaces SAP e dos sistemas conectados (SAP e não-SAP).
Conceção de serviços de fundação. Este projeto deve incluir os seguintes itens, muitos dos quais são cobertos pelo acelerador de zona de pouso para SAP:
Topologia de rede no Azure e atribuição de ambiente SAP diferente
Design de Ative Directory e DNS.
Solução de gerenciamento de identidades para usuários finais e administração
Operações de segurança para recursos e cargas de trabalho do Azure em
Conceito de segurança para proteger sua carga de trabalho SAP. Isso deve incluir todos os aspetos – monitoramento de rede e perímetro, segurança de aplicativos e bancos de dados, proteção de sistemas operacionais e quaisquer medidas de infraestrutura necessárias, como criptografia. Identifique os requisitos com suas equipes de conformidade e segurança.
A Microsoft recomenda um contrato de Suporte Direto Profissional, Premier ou Unificado. Identifique seus caminhos de escalonamento e contatos para suporte com a Microsoft. Para obter os requisitos de suporte SAP, consulte a nota 2015553 SAP.
Plano de redução e migração de dados para migrar dados SAP para o Azure. Para sistemas SAP NetWeaver, a SAP tem diretrizes sobre como limitar o volume de grandes quantidades de dados. Consulte este guia SAP sobre gestão de dados em sistemas SAP ERP. 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 de PowerShell, CLI, Ansible e Terraform.
As soluções desenvolvidas pela Microsoft para automação de implantação SAP são:
Defina uma cadência regular de revisão de projeto e implantação entre você como cliente, integrador de sistemas, Microsoft e outras partes envolvidas.
Fase-piloto (vivamente recomendada)
Você pode executar um piloto antes ou durante o planejamento e a preparação do projeto. Você também pode usar a fase piloto para testar abordagens e projetos feitos durante a fase de planejamento e preparação. E você pode expandir a fase piloto para torná-la uma verdadeira prova de conceito.
Recomendamos que você configure e valide uma solução HADR completa e um design de segurança durante uma implantação piloto. Alguns clientes realizam testes de escalabilidade durante essa fase. Outros clientes usam implantações de sistemas de sandbox SAP como uma fase piloto. Supomos que você já identificou um sistema que deseja migrar para o Azure para o piloto.
Otimize a transferência de dados para o Azure. A escolha ideal depende muito do cenário específico. Se a conectividade privada for necessária para a replicação de banco de dados, a Rota Expressa do Azure será mais rápida se o circuito da Rota Expressa tiver largura de banda suficiente. Em qualquer outro cenário, a transferência através da 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 – já em execução no Azure.
Para uma migração SAP heterogênea que envolva exportação e importação de dados, teste e otimize as fases de exportação e importação. Para migração de grandes ambientes SAP, passe pelas melhores práticas disponíveis. Use a ferramenta apropriada para o cenário de migração, dependendo de suas versões SAP de origem e destino, DBMS e se combinar a migração com outras tarefas, como atualização de versão ou até mesmo conversão Unicode ou S/4HANA. A SAP fornece Migration Monitor/SWPM, SAP DMO ou DMO com movimentação do sistema, além de outras abordagens para minimizar o tempo de inatividade disponível como serviço separado do SAP. Nas últimas versões do SAP DMO com mudança de sistema, o uso de azcopy para transferência de dados pela internet também é suportado, permitindo o caminho de rede mais rápido nativamente.
Migrar bancos de dados muito grandes (VLDB) para o Azure for SAP
Validação técnica
Tipos de computação / VM
Analise os recursos nas notas de suporte do SAP, no diretório de hardware do SAP HANA e no SAP PAM novamente. Certifique-se de corresponder às VMs suportadas para o Azure, às versões de SO suportadas para esses tipos de VM e às versões SAP e DBMS suportadas.
Valide novamente o dimensionamento do seu aplicativo e a infraestrutura que você implanta no Azure. Se você estiver movendo aplicativos existentes, muitas vezes poderá derivar o SAPS necessário da infraestrutura usada e da página da Web de benchmark do SAP e compará-lo com os números do SAPS listados na nota 1928533 do SAP. Tenha também em mente este artigo sobre classificações SAPS.
Avalie e teste o dimensionamento de suas VMs do Azure para obter o máximo de armazenamento e taxa de transferência de rede dos tipos de VM escolhidos durante a fase de planejamento. Os detalhes dos limites de desempenho da VM estão disponíveis, para armazenamento é importante considerar o limite de taxa de transferência máxima de disco não armazenado em cache para dimensionamento. Considere cuidadosamente o dimensionamento e os efeitos temporários do bursting de disco e nível de VM.
Teste e determine se você deseja criar suas próprias imagens do sistema operacional para suas VMs no Azure ou se deseja usar uma imagem da galeria de computação do Azure (anteriormente conhecida como galeria de imagens compartilhadas). Se estiver a utilizar uma imagem da galeria de computação do Azure, certifique-se de que utiliza uma imagem que reflita o contrato de suporte com o fornecedor do SO. Para alguns fornecedores de SO, a Galeria de Computação do Azure permite-lhe trazer as 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 próprias do sistema operacional permite armazenar as dependências corporativas necessárias, como agentes de segurança, proteção e personalizações diretamente na imagem. Dessa forma, eles são implantados imediatamente com cada VM. Se decidir criar as suas próprias imagens do SO, pode encontrar documentação nestes artigos:
Se você usar imagens do Linux da galeria de computação do Azure e adicionar proteção como parte do pipeline de implantação, precisará usar as imagens adequadas para 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 Hyper-V de geração 1 e 2. Algumas famílias de VM estão disponíveis apenas como geração 2, algumas famílias de VM são certificadas para uso SAP apenas como geração 2 (nota SAP 1928533), mesmo que o Azure permita ambas as gerações. Recomenda-se usar a VM de geração 2 para cada VM do cenário SAP.
No mínimo, use o armazenamento SSD padrão do Azure para VMs que representam camadas de aplicativos SAP e para implantação de DBMSs que não são sensíveis ao desempenho. Lembre-se de que diferentes tipos de armazenamento do Azure influenciam o SLA de disponibilidade de VM única.
Em geral, não recomendamos o uso de discos HDD padrão do Azure para SAP.
Para os diferentes tipos de DBMS, verifique a documentação genérica de SGBD relacionada ao SAP e a documentação específica de SGBD para a qual o primeiro documento aponta. Use o striping de disco em vários discos com armazenamento premium (v1 ou v2) para dados de banco de dados e área de log. Verifique se o striping de disco lvm está ativo e com o tamanho de distribuição correto com o comando 'lvs -a -o+lv_layout,lv_role,stripes,stripe_size,devices' no Linux, consulte as propriedades dos espaços de armazenamento no Windows.
Para obter a configuração de armazenamento ideal com o SAP HANA, consulte Configurações de armazenamento da máquina virtual do SAP HANA Azure.
Use LVM para todos os discos em VMs Linux, pois permite gerenciamento mais fácil e expansão on-line. Isso inclui volumes em discos únicos, 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 de arquitetura de rede virtual hub-and-spoke ou WAN virtual com raios de rede virtual discretos para a carga de trabalho SAP. Para uma abordagem de microssegmentação em menor escala dentro de uma única rede virtual do Azure. Basear esta avaliação em:
Vantagens de uma desconexão rápida do emparelhamento entre redes virtuais do Azure em oposição à alteração do grupo de segurança de rede para isolar uma sub-rede dentro de uma rede virtual. Essa avaliação é para casos em que aplicativos ou VMs hospedados em uma sub-rede da rede virtual se tornaram um risco de segurança.
Registo central e auditoria do tráfego de rede entre o local, o mundo exterior e o centro de dados virtual criado no Azure.
Avalie e teste o caminho de dados entre a camada de aplicativo SAP e a camada DBMS SAP.
Não há suporte para o posicionamento de dispositivos virtuais de rede do Azure no caminho de comunicação entre o aplicativo SAP e a camada DBMS dos sistemas SAP que executam o kernel SAP.
Não há suporte para o posicionamento da camada de aplicativos SAP e do SAP DBMS em diferentes redes virtuais do Azure que não são emparelhadas.
Você pode usar regras de grupo de segurança de aplicativo e de grupo de segurança de rede para proteger caminhos de comunicação de e para a camada de aplicativos SAP e a camada de DBMS SAP.
Certifique-se de que a rede acelerada esteja habilitada em todas as VMs usadas para SAP.
Teste e avalie a latência da rede entre as VMs da camada de aplicativos SAP e as VMs DBMS de acordo com as notas 500235 e 1100926 SAP. Além do niping do SAP, você pode usar ferramentas como sockperf ou ethr para medição de latência tcp. Avalie os resultados em relação às diretrizes de latência de rede na nota 1100926 SAP. A latência da rede deve estar na faixa moderada ou boa.
Otimize a taxa de transferência de rede em VMs de alta vCPU, normalmente usadas para servidores de banco de dados. Particularmente importante para o scale-out HANA e qualquer sistema SAP grande. Siga as recomendações neste artigo para otimização.
Para uma latência de rede ideal, considere seguir as orientações no artigo Cenários de posicionamento de proximidade. Não há uso de grupos de posicionamento de proximidade para padrões de implantação zonais ou interzonais.
Verifique a disponibilidade correta, o roteamento e o acesso seguro do cenário SAP a qualquer endpoint de Internet necessário, como repositórios de patches do sistema operacional, ferramentas de implantação ou ponto de extremidade de serviço. Da mesma forma, se o seu ambiente SAP fornece um serviço acessível ao público, como SAP Fiori ou SAProuter, verifique se ele está acessível e seguro.
Implantações de alta disponibilidade e recuperação de desastres
Sempre use o balanceador de carga padrão para ambientes clusterizados. O balanceador de carga básico será aposentado.
Selecione as opções de implantação adequadas, dependendo da sua configuração de sistema preferida em uma região do Azure, quer envolva abrangência entre zonas, residência em uma única zona ou operação em uma região sem zona.
Na implantação regional, para proteger os serviços centrais SAP e as camadas DBMS para alta disponibilidade usando replicação passiva, coloque os dois nós para SAP Central Services em um conjunto de disponibilidade separado e os dois nós DBMS em outro conjunto de disponibilidade. Não misture funções de VM de aplicativo dentro de um conjunto de disponibilidade.
Para implantação interzonal, configure o sistema usando o conjunto de escala 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 que tenham a menor latência entre elas.
Para implantação interzonal, é aconselhável usar o conjunto de escala flexível com FD=1 sobre a implantação da zona de disponibilidade padrão.
Se estiver a utilizar o Azure Load Balancer juntamente com sistemas operativos convidados Linux, verifique se o parâmetro de rede Linux net.ipv4.tcp_timestamps está definido como 0. Essa recomendação está em conflito com as recomendações em versões mais antigas do SAP note 2382421. A nota SAP agora é atualizada para informar que esse parâmetro precisa ser definido como 0 para trabalhar com balanceadores de carga do Azure.
Configurações de tempo limite
Verifique os rastreamentos do desenvolvedor SAP NetWeaver das instâncias SAP para garantir que não haja quebras de conexão entre o servidor enqueue e os processos de trabalho SAP. Você pode evitar essas quebras de conexão definindo estes dois parâmetros do 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 limite de GUI entre interfaces SAP GUI locais e camadas de aplicativos SAP implantadas no Azure, verifique se esses parâmetros estão definidos no perfil default.pfl ou na instância:
RDISP/keepalive_timeout = 3600
rdisp/keepalive = 20
Para evitar a interrupção das conexões estabelecidas entre o processo de enqueue SAP e os processos de trabalho SAP, você precisa definir o parâmetro enque/encni/set_so_keepalive como true. Consulte também a nota 2743751 da SAP.
Se você usar uma configuração de cluster de failover do Windows, verifique se o tempo para reagir em nós que não respondem está definido corretamente para o Azure. O artigo Tuning Failover Cluster Network Thresholds lista parâmetros e como eles afetam a sensibilidade ao failover. Supondo que os nós do cluster estejam na mesma sub-rede, você deve alterar estes parâmetros:
SameSubNetDelay = 2000 (número de milissegundos entre "batimentos cardíacos")
SameSubNetThreshold = 15 (número máximo de batimentos cardíacos perdidos consecutivos)
Para executar o HANA no SAP, leia estas notas e documentações, além da documentação específica não específica do SAP e outras notas de suporte:
Notas SAP específicas do Azure vinculadas aos componentes de suporte SAP BC-OP-NT-AZR ou BC-OP-LNX-AZR. Examine as notas em detalhes, pois elas contêm soluções atualizadas
Teste seus procedimentos de alta disponibilidade e recuperação de desastres
Simule situações de failover usando uma ferramenta como NotMyFault (Windows) ou colocando sistemas operacionais em modo de pânico ou desativando a interface de rede com 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, considere:
Para SUSE Linux, use dispositivos SBD em vez do agente Azure Fence para acelerar o failover.
Para o SAP HANA, se a recarga de dados demorar muito, considere provisionar mais largura de banda de armazenamento.
Teste a sequência e o tempo de backup/restauração e faça correções se necessário. Certifique-se de que os tempos de backup são suficientes. Você também precisa testar as atividades de restauração e tempo de restauração. Certifique-se de que os tempos de restauração estejam dentro de seus SLAs de RTO sempre que o RTO depender de um banco de dados ou processo de restauração de VM.
Teste a funcionalidade e a arquitetura de DR entre regiões, verifique se o RPO e o RTO correspondem às suas expectativas
Controlos de segurança
Teste a validade da sua arquitetura de controle de acesso baseado em função do Azure (Azure RBAC). A segregação de funções requer separar e limitar o acesso e as permissões de diferentes equipas. Por exemplo, os membros da equipe do SAP Basis devem ser capazes de implantar VMs e atribuir discos do Armazenamento do Azure em uma determinada máquina virtual do Azure. Mas a equipe do SAP Basis não deve ser capaz de criar suas próprias redes virtuais ou alterar as configurações das redes virtuais existentes. Os membros da equipe de rede não devem ser capazes de implantar VMs em redes virtuais nas quais o aplicativo SAP e as VMs DBMS estão em execução. Os membros dessa equipe também não devem ser capazes de alterar atributos de VMs ou até mesmo excluir VMs ou discos.
Certifique-se de que todos os recursos que precisam ser criptografados estão criptografados. Defina e implemente processos para fazer backup de certificados, armazenar e acessar esses certificados e restaurar as entidades criptografadas.
A criptografia nativa do banco de dados é implantada pela maioria dos clientes SAP no Azure para proteger os dados e backups do DBMS. A Criptografia de Dados Transparente (TDE) normalmente não tem sobrecarga de desempenho percetível, aumenta muito a segurança e deve ser considerada. O gerenciamento e a localização 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 SSE.
Testes de desempenho No SAP, com base no rastreamento e nas medições do SAP, faça estas comparações:
Inventarie e baseie o sistema local atual.
Relatórios SAR / perfmon.
STAT trace top 10 relatórios online.
Colete o histórico de trabalhos em lote.
Concentre os testes para verificar o desempenho dos processos de negócios. Não compare KPIs de hardware inicialmente e no vácuo, apenas ao solucionar quaisquer diferenças de desempenho.
Quando aplicável, compare os 10 principais relatórios online com a sua implementação atual.
Quando aplicável, compare os 10 principais trabalhos em lote com sua implementação atual.
Compare as transferências de dados através de interfaces para o sistema SAP. Concentre-se em interfaces nas quais você sabe que a transferência está acontecendo entre diferentes locais, como do local para o Azure.
Fase de não produção
Nesta fase, assumimos que, após um piloto bem-sucedido ou prova de conceito (POC), você está começando a implantar sistemas SAP que não são de produção no Azure. Incorpore tudo o que você aprendeu e experimentou durante o POC a esta implantação. Todos os critérios e etapas listados para POCs também se aplicam a essa implantação.
Durante essa fase, você geralmente implanta sistemas de desenvolvimento, sistemas de teste de unidade e sistemas de teste de regressão de negócios no Azure. Recomendamos que pelo menos um sistema que não seja de produção em uma linha de aplicativos SAP tenha a configuração de alta disponibilidade completa que o futuro sistema de produção terá. Aqui estão algumas tarefas que você precisa concluir durante esta fase:
Antes de mover sistemas da plataforma antiga para o Azure, colete dados de consumo de recursos, como uso da CPU, taxa de transferência de armazenamento e dados IOPS. Especialmente colete esses dados das unidades de camada DBMS, mas também colete-os das unidades da camada de aplicativo. Meça também a latência da rede e do armazenamento. Adapte seu dimensionamento e design com os dados capturados. Ferramentas como syststat, KSAR, nmon e 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 de seus sistemas. O objetivo é descobrir se os sistemas não produtivos precisam estar disponíveis o dia todo, todos os dias ou se há sistemas que não são de produção que podem ser desligados durante certas fases de uma semana ou mês.
Reavalie sua escolha de imagem do sistema operacional, geração de VM (Geração 2 em todo o cenário SAP) e estratégia de patch do sistema operacional.
Certifique-se de cumprir os requisitos de suporte SAP para contratos de suporte da Microsoft. Consulte a nota 2015553 da SAP.
Verifique as notas SAP relacionadas ao Azure, como a nota 1928533, para obter novas SKUs de VM e versões de SO e DBMS recém-suportadas. Compare o preço dos novos tipos de VM com os dos tipos de VM mais antigos, para que você possa implantar VMs com a melhor relação preço/desempenho.
Verifique novamente as notas de suporte do SAP, o diretório de hardware do SAP HANA e o SAP PAM. Certifique-se de que não houve alterações nas VMs suportadas para o Azure, nas versões do SO suportadas nessas VMs e nas versões SAP e DBMS suportadas.
Consulte o site da SAP para obter novas SKUs certificadas pelo HANA no Azure. Compare os preços dos novos SKUs com os que você planejava usar. Eventualmente, faça as alterações necessárias para usar aqueles que têm a melhor relação preço/desempenho.
Adapte sua automação de implantação para usar novos tipos de VM e incorporar novos recursos do Azure que você deseja usar.
Após a implantação da infraestrutura, teste e avalie a latência da rede entre as VMs da camada de aplicativos SAP e as VMs DBMS, de acordo com as notas da SAP 500235. Avalie os resultados em relação às diretrizes de latência de rede na nota 1100926 SAP. A latência da rede deve estar na faixa moderada ou boa. Além de usar ferramentas como niping, sockperf ou ethr, use a ferramenta HCMT da SAP para medições de rede entre VMs HANA para expansão ou replicação do sistema.
Se você estiver vendo latência maior do que o esperado entre VMs, considere seguir as orientações no artigo Cenários de posicionamento de proximidade.
Execute todas as outras verificações listadas para a fase de prova de conceito antes de aplicar a carga de trabalho.
À medida que a carga de trabalho se aplica, registre o consumo de recursos dos sistemas no Azure. Compare este consumo com os registos da sua plataforma antiga. Ajuste o dimensionamento da VM de implantações futuras se você perceber que tem grandes diferenças. Lembre-se de que, ao reduzir o tamanho, o armazenamento e a largura de banda de rede das VMs também serão reduzidos.
Experimente a funcionalidade e os processos de cópia do sistema. O objetivo é 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 garantir que você tenha separação de tarefas. Ao mesmo tempo, certifique-se de que todas as equipes possam executar suas tarefas na infraestrutura do Azure.
Exercite, teste e documente procedimentos de alta disponibilidade e recuperação de desastres para permitir que sua equipe execute essas tarefas. Identifique deficiências e adapte a nova funcionalidade do Azure que você está 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 são de produção e aplique-o a implantações de produção futuras.
Conclua todas as atualizações de versão SAP necessárias de seus sistemas de produção antes de mudar para o Azure.
Concordar com os empresários sobre testes funcionais e de negócios que precisam ser realizados após a migração do sistema de produção.
Certifique-se de que esses testes sejam concluídos com os sistemas de origem no local de hospedagem atual. Evite realizar testes pela primeira vez depois que o sistema for movido para o Azure.
Teste o processo de migração de sistemas de produção para o Azure. Se você não estiver movendo todos os sistemas de produção para o Azure durante o mesmo período, crie grupos de sistemas de produção que precisam estar no mesmo local de hospedagem. Teste a migração de dados, incluindo aplicativos e interfaces não SAP conectados.
Aqui estão alguns métodos comuns:
Use métodos DBMS como backup/restauração em combinação com o SQL Server Always On, a Replicação do Sistema HANA ou o envio de logs para semear e sincronizar o conteúdo do banco de dados no Azure.
Use backup/restauração para bancos de dados menores.
Use o processo SAP DMO para cenários suportados para mover ou se você precisar combinar sua migração com um upgrade de versão SAP e/ou mover para HANA. Lembre-se de que nem todas as combinações de DBMS de origem e DBMS de destino são suportadas. Você pode encontrar mais informações nas notas de suporte SAP específicas para as diferentes versões do DMO. Por exemplo, DMO (Database Migration Option) do SUM 2.0 SP15.
Teste se a taxa de transferência de dados é melhor através da Internet ou através da Rota Expressa, caso precise mover backups ou arquivos de exportação SAP. Se estiver a mover dados através da Internet, poderá ter de alterar algumas das regras do grupo de segurança de rede/grupo de segurança de aplicações que terá de ter em vigor para futuros sistemas de produção.
Antes de mover sistemas da sua plataforma antiga para o Azure, colete dados de consumo de recursos. Os dados úteis incluem o uso da CPU, a taxa de transferência de armazenamento e os dados IOPS. Especialmente colete esses dados das unidades de camada DBMS, mas também colete-os das unidades da camada de aplicativo. Meça também a latência da rede e do armazenamento.
Verifique novamente as notas do SAP e as configurações necessárias do sistema operacional, o diretório de hardware do SAP HANA e o SAP PAM. Certifique-se de que não houve alterações nas VMs suportadas para o Azure, nas versões de SO suportadas nessas VMs e nas versões SAP e DBMS suportadas.
Atualize sua automação de implantação para considerar as decisões mais recentes que você tomou sobre tipos de VM e funcionalidade do Azure.
Crie um manual para reagir a eventos de manutenção planeados do Azure. Determine a ordem na qual os sistemas e VMs devem ser reinicializados para manutenção planejada.
Exercite, teste e documente procedimentos de alta disponibilidade e recuperação de desastres para permitir que sua equipe execute essas tarefas durante a migração e imediatamente após a decisão de entrada em funcionamento.
Fase de entrada em funcionamento
Durante a fase de go-live, certifique-se de seguir os playbooks que você desenvolveu durante as fases anteriores. Execute as etapas testadas e praticadas. Não aceite alterações de última hora em 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 monitoramento de infraestrutura. Azure Monitor for SAP para uma combinação de KPIs de SO e aplicações, permitindo-lhe integrar tudo num dashboard para visibilidade durante e após a entrada em funcionamento.
Para indicadores-chave de desempenho do sistema operacional:
No Linux, certifique-se de que a ferramenta sysstat esteja instalada e capture detalhes em intervalos regulares
Após a migração de dados, execute todos os testes de validação acordados com os proprietários do negócio. Aceite os resultados do teste de validação somente quando tiver resultados para os sistemas de origem originais.
Verifique se as interfaces estão funcionando e se outros aplicativos podem se comunicar com os sistemas de produção recém-implantados.
Verifique o sistema de transporte e correção através da transação SAP STMS.
Execute backups de banco de dados depois que o sistema for liberado para produção.
Execute backups de VM para as VMs da camada de aplicativos SAP depois que o sistema for liberado para produção.
Para sistemas SAP que não faziam parte da fase de ativação atual, mas que se comunicam com os sistemas SAP que você moveu para o Azure durante essa fase de ativação, você precisa redefinir o buffer de nome do host no SM51. Isso removerá os antigos endereços IP armazenados em cache associados aos nomes das instâncias de aplicativo que você moveu para o Azure.
Pós-produção
Esta fase trata de monitorar, operar e administrar o sistema. Do ponto de vista do SAP, aplicam-se as tarefas habituais que você deveria concluir em seu antigo local de hospedagem. Conclua também estas tarefas específicas do Azure:
Analise as faturas do Azure para sistemas de alta cobrança. Instale uma cultura de finOps e crie um recurso de otimização de custos do Azure em sua organização.
Otimize a eficiência de preço/desempenho no lado da VM e no lado do armazenamento.
Depois que seu SAP no Azure estiver estabilizado, seu foco precisa mudar para uma cultura de dimensionamento contínuo e revisões de capacidade. Ao contrário do local, onde dimensionamos por um longo período, o dimensionamento correto é um benefício fundamental da execução do SAP na carga de trabalho do Azure, e o planejamento de capacidade diligente será fundamental.
Otimize os momentos em que você pode desligar os sistemas.
Depois que sua solução estiver estabilizada no Azure, considere abandonar um modelo comercial Pay-As-You-Go e aproveitar as Instâncias Reservadas do Azure.
Planeje e execute exercícios regulares de recuperação de desastres.
Defina e implemente sua estratégia em torno do "ever-greeneing", para alinhar seu próprio roteiro com o SAP da Microsoft no roteiro do Azure para se beneficiar do avanço da tecnologia.
Lista de verificação do SAP na infraestrutura do Azure
Depois de implantar a infraestrutura e os aplicativos e antes do início de cada migração, valide que:
Os tipos de VM corretos foram implantados, com os atributos e a configuração de armazenamento corretos.
As VMs estão em uma versão e patch atualizados do sistema operacional, DBMS e SAP Kernel e o uniforme OS, DB e SAP Kernel em todo o cenário
As VMs são protegidas e reforçadas conforme necessário e de forma uniforme em todo o respetivo ambiente.
As VMs foram implantadas em um conjunto de escala flexível com FD=1 em zonas de disponibilidade ou em um conjunto de disponibilidade.
As VMs de 2ª geração foram implantadas. As VMs de Geração 1 não devem ser usadas para novas implantações.
O Armazenamento Premium do Azure ou Armazenamento Premium v2 é usado para discos sensíveis à latência ou onde o SLA de VM única de 99,9% é necessário.
Usando os serviços do Azure – Arquivos do Azure ou Arquivos NetApp do Azure – para quaisquer volumes ou compartilhamentos SMB ou NFS. Os volumes NFS ou compartilhamentos SMB podem ser acessados pelo respetivo ambiente SAP ou sistema(s) SAP(s) individual(is). O roteamento de rede para o servidor NFS/SMB passa pelo espaço de endereçamento da rede privada, usando o ponto de extremidade privado, se necessário.
A rede acelerada do Azure está habilitada em todas as interfaces de rede para todas as VMs SAP.
Nenhum dispositivo virtual de rede está no caminho de comunicação entre o aplicativo SAP e a camada DBMS dos sistemas SAP baseados no SAP NetWeaver ou ABAP Platform.
Todos os load balancers para componentes de alta disponibilidade SAP usam balanceador de carga padrão com portas IP e HA flutuantes habilitadas.
O aplicativo SAP e a(s) VM(s) DBMS são colocados em sub-redes iguais ou diferentes de uma rede virtual ou em redes virtuais diretamente emparelhadas.
As regras do grupo de segurança de aplicativos e redes permitem a comunicação conforme desejado e planejado e bloqueiam a comunicação quando necessário.
As configurações de tempo limite são definidas corretamente, conforme descrito anteriormente.
Se estiver usando grupos de posicionamento de proximidade, verifique se os conjuntos de disponibilidade e suas VMs são implantados no PPG correto.
A latência de rede entre VMs da camada de aplicativo SAP e VMs DBMS é testada e validada conforme descrito nas notas 500235 e 1100926 do SAP. Avalie os resultados em relação às diretrizes de latência de rede na nota 1100926 SAP. A latência da rede deve estar na faixa moderada ou boa.
A encriptação foi implementada sempre que necessário e com o método de encriptação adequado.
As próprias chaves de encriptação estão protegidas contra perda, destruição ou uso malicioso.
Interfaces e outros aplicativos podem se conectar à infraestrutura recém-implantada.
Verificações e insights automatizados no cenário SAP
Várias das verificações acima são verificadas de forma automatizada com o SAP na Ferramenta de Verificação de Qualidade do Azure. Essas verificações podem ser executadas de forma automatizada com o projeto de código aberto fornecido. Embora nenhuma correção automática dos problemas encontrados seja executada, a ferramenta avisará sobre a configuração em relação às recomendações da Microsoft.
Gorjeta
As mesmas verificações de qualidade e informações adicionais são executadas regularmente quando os sistemas SAP também são implantados ou registrados na solução Azure Center for SAP e fazem parte do serviço.
Outras ferramentas para permitir verificações de implantação mais fáceis e documentar descobertas, planejar as próximas etapas de correção e otimizar geralmente seu SAP no cenário do Azure são:
Revisão do Azure Well-Architected Framework Uma avaliação da sua carga de trabalho com foco nos cinco pilares principais de confiabilidade, segurança, otimização de custos, excelência operacional e eficiência de desempenho. Suporta cargas de trabalho SAP e recomenda a execução de uma revisão no início e após cada fase do projeto.
Azure Inventory Checks for SAP Uma pasta de trabalho de código aberto do Azure Monitor, que mostra seu inventário do Azure com inteligência para destacar desvios de configuração e melhorar a qualidade.