Carga de trabalho SAP no Azure: lista de verificação de planejamento e implantação
Artigo
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
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.
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 os softwares SAP, OS e DBMS compatíveis estão documentados aqui:
Nota SAP 2039619. Esta nota define a matriz de suporte da Oracle para o Azure. A Oracle dá suporte apenas ao Windows e Oracle Linux como sistemas operacionais convidados no Azure para cargas de trabalho do SAP. Essa declaração de suporte também se aplica à camada do aplicativo SAP que executa as instâncias SAP, desde que contenham o Cliente Oracle.
As VMs do Azure com suporte no SAP HANA são listadas no site do SAP. Os detalhes de cada entrada contêm especificações e requisitos, incluindo a versão do sistema operacional com suporte. Talvez isso não corresponda à última versão do sistema operacional, de acordo com a Nota SAP 2235581.
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 desastres
Com base em RTO e RPO, defina como a arquitetura de alta disponibilidade e recuperação de desastre deve ser.
Compreenda o uso de diferentes tipos de implantação para obter 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.
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 dos sistemas conectados (SAP e não-SAP).
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.
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 automação da implantação do SAP sã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.
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 do sistema operacional, você pode encontrar a 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.
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.
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.
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:
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.
Não há suporte para o posicionamento de soluções de virtualização de rede do Azure na rota de comunicação entre o aplicativo SAP e a camada do DBMS de sistemas SAP que executam o kernel SAP.
Não há suporte para o posicionamento da camada de aplicativo SAP e DBMS de SAP em diferentes redes virtuais do Azure que não estejam emparelhadas.
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 orientações do artigo Cenários de posicionamento de 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 da configuração do sistema preferida em uma região do Azure, se envolve a extensão entre zonas, a residência em uma única zona ou a operação em uma região sem zona.
Na implantação regional, para proteger os serviços centrais SAP e as camadas de DBMS para alta disponibilidade usando replicação passiva, coloque os dois nós do SAP Central Services em um conjunto de disponibilidade separado e os dois nós do DBMS em outro conjunto de disponibilidade. Não combine as funções VM do aplicativo em um conjunto de disponibilidade.
Para implantação zonal cruzada, 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 de DBMS em duas zonas de disponibilidade diferentes. Use duas zonas de disponibilidade com a menor latência entre elas.
Para implantação entre zonais, é aconselhável usar um conjunto de escala flexível com FD=1 sobre a 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. 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 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, você deve alterar estes parâmetros:
SameSubNetDelay = 2000 (número de milissegundos entre as “pulsações”)
SameSubNetThreshold = 15 (número máximo de pulsações perdidas consecutivas)
Para executar o HANA no SAP, leia estas notas e documentações, além da documentação específica do SAP que não é do Azure e outras notas de suporte:
Notas específicas do SAP do Azure vinculadas aos componentes de suporte do SAP BC-OP-NT-AZR ou BC-OP-LNX-AZR. Analise as notas detalhadamente, pois elas contêm soluções atualizadas
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 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 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:
Inventariar e estabelecer a linha de base do sistema local atual.
Relatórios SAR / perfmon.
STAT rastrear os 10 principais relatórios on-line.
Coletar histórico de trabalhos em lote.
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.
Se você estiver vendo uma latência maior do que a esperada 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.
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 indicadores-chave de desempenho do sistema operacional:
No Linux, verifique se a ferramenta sysstat está instalada e se ela captura os detalhes em intervalos regulares
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 escala flexível com FD=1 em zonas de disponibilidade ou em um conjunto de disponibilidade.
As VMs de geração 2 foram implantadas. As VMs de 1ª geração 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.
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.