Explorar a fase piloto

  • 20 minutos

O piloto pode ser executado paralelamente ao planejamento e à preparação do projeto. Essa fase também pode ser usada para testar as opções identificadas na fase de planejamento e de preparação. Como parte do piloto, é recomendável configurar e validar uma solução completa de HA/DR, além do design de segurança. Em alguns casos, também pode ser possível usar essa fase para executar testes de escalabilidade ou implantar sistemas de área restrita da SAP. Para executar um piloto, os clientes devem começar identificando um sistema não crítico que desejem migrar para o Azure e continuar executando as seguintes tarefas:

1. Otimizar a transferência de dados para o Azure

A abordagem e o resultado dependem muito da conectividade do cliente com o Azure. Dependendo da quantidade de dados, pode ser possível usar os seguintes recursos para essa finalidade: ExpressRoute, VPN site a site ou serviços de transferência de dados offline, como Azure Data Box ou o serviço de Importação/Exportação do Azure.

2. Migração de plataforma heterogênea do SAP

No caso de uma migração de plataformas heterogêneas da SAP, que envolve exportação e importação do banco de dados, teste e otimização das fases de exportação e importação. Para grandes migrações heterogêneas destinadas ao SQL Server, confira Migração de OS/DB do SAP para o SQL Server – Perguntas Frequentes. Você pode usar o Monitor de Migração/SWPM caso não precise combinar a migração com uma atualização de versão ou a DMO (Opção de migração de banco de dados) da SAP. Para obter detalhes, confira DMO (Opção de Migração de Banco de Dados) do SUM – Introdução . Em ambos os casos, siga as seguintes etapas:

  • Calcule o tempo de exportação da fonte, carregue o conteúdo exportado no Azure e execute a importação. Maximize a sobreposição entre exportação e importação.
  • Use a comparação entre os bancos de dados de origem e de destino para dimensionar a infraestrutura de destino adequadamente.
  • Valide e otimize o tempo.

3. Executar a validação técnica

Tipos de VM

  • Confira as notas de suporte da SAP, o diretório de hardware do SAP HANA e o PAM (Matriz de disponibilidade de produto) da SAP para garantir a precisão das informações relacionadas aos SKUs de VM do Azure com suporte, as versões de sistema operacional com suporte para essas SKUs de VM do Azure e as versões de SAP e DBMS com suporte.
  • Valide o dimensionamento da infraestrutura e os componentes do aplicativo implantados no Azure. Ao migrar aplicativos existentes, você deve ser capaz de obter os SAPS necessários com base na telemetria existente. Recupere o parâmetro de comparação da SAP e compare-o com os números SAPS listados na Nota da SAP #1928533. Além disso, confira as informações fornecidas em Classificações de SAPS em VMs do Azure – onde procurar e onde você pode se confundir .
  • Avalie e teste o dimensionamento de suas VMs do Azure em relação à taxa de transferência máxima de armazenamento e à taxa de transferência de rede de diferentes tipos de VM que você escolheu na fase de planejamento. Esses dados podem ser encontrados em Tamanhos de máquinas virtuais no Azure. Quando o sistema operacional convidado da VM do Azure é o Windows, é importante considerar a taxa de transferência máxima do disco não armazenado em cache para o dimensionamento. No caso do Linux, também é importante considerar a taxa de transferência máxima do disco não armazenado em cache para o dimensionamento.

Armazenamento

  • Use o armazenamento de SSD Standard do Azure como mínimo para VMs que representam as camadas de aplicativos SAP e para a implantação de DBMS não sensível ao desempenho e use o Armazenamento Premium do Azure para qualquer VM de DBMS que seja sensível ao desempenho.
  • Evite usar discos HDD Standard do Azure.
  • Usar os discos gerenciados do Azure.
  • Use o Acelerador de Gravação do Azure para unidades de log do DBMS com a série M de VMs do Azure. Fique atento aos limites do Acelerador de Gravação documentados e às restrições de uso.
  • Para obter informações de armazenamento relacionadas a DBMS, confira Considerações sobre implantação de DBMS de Máquinas Virtuais do Azure para carga de trabalho do SAP, bem como documentações específicas do DBMS referenciada nesse documento.
  • Para implantações do SAP HANA, confira o documento da Microsoft chamado Configurações e operações de infraestrutura do SAP HANA no Azure.
  • Nunca monte discos de dados do Azure em uma VM Linux do Azure usando a ID do dispositivo. Em vez disso, use o identificador universal exclusivo (UUID). Tenha cuidado ao usar ferramentas gráficas para montar o disco de dados do Azure. Verifique novamente as entradas em /etc/fstab para ver se os discos são montados usando o UUID. Para obter mais informações, confira Conectar-se à VM do Linux para montar o novo disco.

Rede

Teste e avalie sua infraestrutura de rede virtual e a distribuição de seus aplicativos SAP entre ou dentro das redes virtuais do Azure.

  1. Avaliar a abordagem da arquitetura de rede virtual de hub e spoke ou microssegmentação em uma única rede virtual do Azure com base nestes critérios:

    • Custos devidos à troca de dados entre VNets do Azure com emparelhamento (para obter detalhes, confira Preços da rede virtual do Azure.
    • Comparação entre a capacidade de encerrar o emparelhamento entre redes virtuais do Azure e o uso de NSGs para isolar sub-redes em uma rede virtual nos casos em que os aplicativos ou as VMs hospedadas em uma sub-rede da rede virtual se tornem um risco à segurança.
    • Registro em log central e auditoria de tráfego de rede entre o local, a Internet e o datacenter virtual do Azure.

  2. Avalie e teste o caminho de dados entre a camada de aplicativo SAP e a camada do SAP DBMS. Como parte de sua avaliação, cogite o seguinte:

    • Não há suporte para a colocação de Dispositivos de rede virtual no caminho de comunicação entre o aplicativo SAP e a camada DBMS de um SAP NetWeaver, Hybris ou sistemas SAP baseados no S/4HANA.
    • Não há suporte para a colocação da camada de aplicativo SAP e o SAP DBMS em diferentes redes virtuais do Azure que não estejam emparelhadas.
    • Há suporte para o uso de ASGs (Grupos de Segurança de Aplicativo do Azure) e NSGs (Grupos de segurança de rede) do Azure para controlar o fluxo de tráfego entre a camada de aplicativo SAP e a camada de DBMS da SAP.

  3. Verifique se a Rede acelerada do Azure está habilitada nas VMs usadas na camada do aplicativo SAP e na camada do DBMS da SAP. Lembre-se dos requisitos do sistema operacional para o suporte à Rede acelerada no Azure:

    • Windows Server 2012 R2 ou versões mais recentes
    • SUSE Linux 12 SP3 ou versões mais recentes
    • RHEL 7.4 ou versões mais recentes
    • Oracle Linux 7.5. O kernel RHCKL requer a versão 3.10.0-862.13.1.el7. O kernel do Oracle UEK requer a versão 5.

  4. Teste e avalie a latência de rede entre a VM da camada de aplicativo SAP e a VM do DBMS de acordo com a Nota da SAP #500235 e a Nota da SAP #1100926. Avalie os resultados em relação às diretrizes de latência de rede da Nota da SAP #1100926. A latência de rede deve estar dentro do intervalo de moderado a bom.

  5. Verifique se as implantações de ILB (balanceador de carga interno) são configuradas para usar o Retorno de servidor direto. Essa configuração reduzirá a latência nos casos em que ILBs são usados para configurações de alta disponibilidade na camada de DBMS.

  6. Caso esteja usando o Azure Load Balancer em conjunto com os sistemas operacionais Linux convidados, verifique se o parâmetro de rede do Linux net.ipv4.tcp_timestamps está definido como 0. Observe que isso contradiz as recomendações gerais da Nota da SAP #2382421. A anotação de SAP foi atualizada para refletir o fato de que o parâmetro precisa ser definido como 0 para funcionar em conjunto com os balanceadores de carga do Azure.

Implantações de alta disponibilidade e recuperação de desastre

  • Se implantar a camada de aplicativo SAP sem direcionar Zonas de Disponibilidade do Azure específicas, verifique se todas as VMs que estejam executando instâncias de caixa de diálogo da SAP ou instâncias middleware do mesmo sistema SAP estão implantadas no mesmo conjunto de disponibilidade.

    • Caso não precise de alta disponibilidade para o SAP Central Services e o DBMS, essas VMs poderão ser implantadas no mesmo Conjunto de disponibilidade da camada de aplicativo SAP.

  • Caso precise proteger os SAP Central Services e a camada de DBMS para alta disponibilidade com réplicas passivas, implante os dois nós para SAP Central Services em um Conjunto de disponibilidade e os dois nós de DBMS em outro Conjunto de disponibilidade.

  • Se você implantar em Zonas de Disponibilidade do Azure, não poderá aproveitar os Conjuntos de disponibilidade. Em vez disso, você deve garantir a implantação dos nós dos Serviços Centrais ativos e passivos em duas Zonas de Disponibilidade diferentes, o que fornece a menor latência entre as zonas.

  • Lembre-se de que você precisa usar o Azure Standard Load Balancer ao criar Clusters de Failover baseados em Pacemaker ou Windows Server para a camada de Serviços Centrais de SAP e do DBMS entre Zonas de Disponibilidade. O Load Balancer Básico não é compatível com implantações em zonas.

Configurações de tempo limite

  • Examine os rastreamentos de desenvolvedor do SAP NetWeaver de instâncias da SAP e garanta que não haja nenhuma interrupção de conexão entre o servidor de enfileiramento e os processos de trabalho do SAP. Essas interrupções de conexão podem ser evitadas definindo estes dois parâmetros de registro.

    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Para obter detalhes, confira KeepAliveTime.
    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Para obter detalhes, confira KeepAliveInterval.

  • Para evitar tempos limites de GUI entre interfaces da SAP GUI locais e camadas de aplicativo SAP implantadas no Azure, defina os parâmetros no default.pfl ou no perfil da instância:

    • rdisp/keepalive_timeout = 3600
    • rdisp/keepalive = 20

  • Se você usar um Clustering de failover do Windows, verifique se estão definidos corretamente os parâmetros que determinam o failover acionado por nós não responsivos. O artigo da Microsoft TechCommunity Como ajustar Limites de Rede de Cluster de Failover lista os parâmetros e seu impacto no comportamento do failover. Por exemplo, supondo que os nós de cluster estejam na mesma sub-rede, configure os parâmetros de failover da seguinte maneira:

    • SameSubNetDelay = 2000

    • SameSubNetThreshold = 15

    • RoutingHistorylength = 30

    • Testar os procedimentos de alta disponibilidade e recuperação de desastre:

      • Simule o failover encerrando as VMs do Azure (SO convidado do Windows) ou colocando os sistemas operacionais em modo de pânico (SO convidado do Linux).

      • Meça o tempo necessário para concluir os failovers. Se os tempos forem muito longos, cogite:

        • Para o SUSE Linux, use 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 melhorar o desempenho de armazenamento.

      • Testar a sequência de backup/restauração e ajustar se necessário. Assegure que não apenas os tempos de backup sejam suficientes. Além disso, teste a restauração e o tempo nas atividades de restauração. Verifique se os tempos de restauração estão dentro de seus SLAs RTO, em que o RTO depende de um processo de restauração de banco de dados ou VM.

      • Teste a funcionalidade e a arquitetura de DR.

4. Realize verificações de segurança

  • Teste a validade da abordagem RBAC (acesso baseado em função) do Azure implementada. A meta é separar e limitar o acesso e as permissões delegadas a diferentes equipes. Por exemplo, os membros da equipe SAP Basis devem ser capazes de implantar VMs do Azure em uma determinada rede virtual do Azure e atribuir discos a essas VMs do Azure. No entanto, a equipe SAP Basis não deve poder criar novas redes virtuais ou alterar as configurações de redes virtuais existentes. Por outro lado, os membros da equipe de rede não devem poder implantar VMs do Azure em redes virtuais nas quais VMs do DBMS e do aplicativo SAP estejam em execução. Nem os membros da equipe de rede devem ser capazes de alterar os atributos das VMs ou excluir as VMs e seus discos.
  • Verifique se as regras do NSG estão funcionando conforme o esperado e defenda os recursos protegidos.
  • Verifique a criptografia em repouso e em trânsito. Defina e implemente processos para fazer backup, armazenar e acessar certificados, bem como validar o processo de restauração de entidades criptografadas.
  • Use o Azure Disk Encryption para discos do sistema operacional.
  • Cogite usar uma abordagem pragmática ao decidir se deve implementar um mecanismo de criptografia. Por exemplo, avalie se é necessário aplicar tanto a Criptografia de disco do Azure quanto o Transparent Data Encryption do DBMS.

5. Testar o desempenho

Em cenários de migração, aproveite o rastreamento e as medições do SAP para comparar o piloto com a implementação atual com base no seguinte:

  • 10 principais relatórios online
  • 10 principais trabalhos em lotes
  • Transferências de dados por meio de interfaces no sistema SAP, concentrando-se no tráfego entre locais