Explore a fase-piloto

  • 20 minutos

O projeto-piloto pode decorrer em paralelo com o planeamento e a preparação do projeto. Esta fase também pode ser utilizada para testar as opções identificadas na fase de planeamento e preparação. Como parte do piloto, recomenda-se configurar e validar uma solução HA/DR completa, bem como um 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 sandbox SAP. Para executar um piloto, os clientes devem começar identificando um sistema não crítico que desejam 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 de um cliente com o Azure. Dependendo da quantidade de dados, pode ser possível usar para essa finalidade a Rota Expressa, VPN Site a Site ou serviços de transferência de dados offline, como o Azure Data Box ou o Serviço de Importação/Exportação do Azure.

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

No caso de uma migração de plataforma heterogênea SAP que envolva uma exportação e importação dos dados do banco de dados, teste e otimize as fases de exportação e importação. Para grandes migrações heterogêneas direcionadas ao SQL Server, consulte Migração do SAP OS/DB para o SQL Server–FAQ. 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 com a opção de migração de banco de dados SAP (DMO) caso contrário. Para obter detalhes, consulte Database Migration Option (DMO) de SUM – Introduction. Em ambos os casos, use as seguintes etapas:

  • Meça o tempo de exportação da origem, carregue o conteúdo exportado para o 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 corretamente a infraestrutura de destino.
  • Valide e otimize o tempo.

3. Realizar a validação técnica

Tipos de VM

  • Consulte as notas de suporte do SAP, o diretório de hardware do SAP HANA e a Matriz de disponibilidade do produto SAP (PAM) para garantir a precisão das informações sobre SKUs de VM do Azure suportadas, versões de SO suportadas para essas SKUs de VM do Azure e versões SAP e DBMS suportadas.
  • Valide o dimensionamento da infraestrutura e dos componentes de aplicativo que você implanta no Azure. Ao migrar aplicativos existentes, você deve ser capaz de obter o SAPS necessário com base na telemetria existente. Recupere o benchmark SAP e compare-o com os números SAPS listados na SAP Note #1928533. Além disso, consulte as informações fornecidas nas classificações do SAPS em VMs do Azure – onde procurar e onde você pode ficar confuso.
  • 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 dos diferentes tipos de VM escolhidos na fase de planejamento. Esses dados podem ser encontrados em Tamanhos para 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 de disco não armazenado em cache para dimensionamento. No caso do Linux, também é importante considerar a taxa de transferência máxima de disco sem cache para dimensionamento.

Armazenamento

  • Use o armazenamento SSD padrão do Azure como o mínimo para VMs que representam camadas de aplicativos SAP e para implantação de DBMS não sensíveis ao desempenho e use o Armazenamento Premium do Azure para VMs DBMS que sejam sensíveis ao desempenho.
  • Evite usar discos HDD padrão do Azure.
  • Use discos gerenciados do Azure.
  • Habilite o Azure Write Accelerator para unidades de log DBMS com VMs do Azure M-Series. Esteja ciente dos limites documentados do Acelerador de Gravação e das restrições de uso.
  • Para obter informações de armazenamento relacionadas ao DBMS, consulte Considerações sobre a implantação do DBMS das Máquinas Virtuais do Azure para carga de trabalho SAP, bem como a documentação específica do DBMS mencionada nesse documento.
  • Para implantações do SAP HANA, consulte 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 universalmente exclusivo (UUID). Tenha cuidado ao usar ferramentas gráficas para montar um disco de dados do Azure. Verifique novamente as entradas em /etc/fstab para se certificar de que os discos estão montados usando o UUID. Para obter mais informações, consulte Conectar-se à VM Linux para montar o novo disco.

Rede

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

  1. Avalie a abordagem da arquitetura de rede virtual hub e spoke ou microsegmentação dentro de uma única rede virtual do Azure com base nos seguintes critérios:

    • Custos devido à troca de dados entre VNets do Azure emparelhadas (para obter detalhes, consulte os 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 dentro de uma rede virtual nos casos em que aplicativos ou VMs hospedados em uma sub-rede da rede virtual se tornam um risco de segurança.
    • Registo central e auditoria do tráfego de rede entre o local, a Internet e o centro de dados virtual do Azure.

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

    • Não há suporte para a colocação de dispositivos virtuais de rede no caminho de comunicação entre o aplicativo SAP e a camada DBMS de um sistema SAP baseado em SAP NetWeaver, Hybris ou S/4HANA.
    • Não há suporte para colocar a camada de aplicativo SAP e o DBMS SAP em diferentes redes virtuais do Azure que não são emparelhadas.
    • Há suporte para usar ASGs (Grupos de Segurança de Aplicativos) e NSGs (Grupos de Segurança de Rede) do Azure para controlar o fluxo de tráfego entre a camada de aplicativos SAP e a camada de DBMS SAP.

  3. Verifique se o Azure Accelerated Networking está habilitado nas VMs usadas na camada de aplicativos SAP e na camada SAP DBMS. Lembre-se dos requisitos do SO para suporte de 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 aplicação SAP e a VM DBMS de acordo com a Nota SAP #500235 e a Nota SAP #1100926. Avalie os resultados em relação à orientação de latência de rede do SAP Note #1100926. A latência da rede deve estar dentro do intervalo moderado a bom.

  5. Certifique-se de que as implantações do ILB (balanceador de carga interno) do Azure estejam configuradas para usar o Retorno Direto do Servidor. Essa configuração reduzirá a latência nos casos em que os ILBs são usados para configurações de alta disponibilidade na camada DBMS.

  6. Se você estiver usando o balanceador de carga do Azure em conjunto com sistemas operacionais convidados do Linux, verifique se o parâmetro de rede Linux net.ipv4.tcp_timestamps está definido como 0. Observe que isso contradiz as recomendações gerais da SAP Note #2382421. A Nota SAP foi atualizada para refletir o fato de que o parâmetro precisa ser definido como 0 para trabalhar em conjunto com os balanceadores de carga do Azure.

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

  • Se você implantar a camada de aplicativo SAP sem direcionar zonas de disponibilidade específicas do Azure, certifique-se de que todas as VMs que executam a instância de diálogo SAP ou instâncias de middleware do mesmo sistema SAP sejam implantadas no mesmo conjunto de disponibilidade.

    • Caso você não precise de alta disponibilidade para os SAP Central Services e DBMS, essas VMs podem ser implantadas no mesmo conjunto de disponibilidade que a camada de aplicativos SAP.

  • Se você precisar proteger os SAP Central Services e a camada 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 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, certifique-se de implantar os nós de Serviços Centrais ativos e passivos em duas Zonas de Disponibilidade diferentes, que fornecem a menor latência entre zonas.

  • Lembre-se de que você precisa usar o balanceador de carga padrão do Azure ao criar clusters de failover baseados no Windows Server ou Pacemaker para a camada DBMS e SAP Central Services em zonas de disponibilidade. O balanceador de carga básico não oferece suporte a implantações zonais.

Configurações de tempo limite

  • Verifique os rastreamentos de instâncias SAP do desenvolvedor SAP NetWeaver e verifique se não há quebras de conexão entre o servidor enqueue e os processos de trabalho SAP. Essas quebras de conexão podem ser evitadas definindo esses dois parâmetros do Registro.

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

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

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

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

    • SameSubNetDelay = 2000

    • SameSubNetThreshold = 15

    • RoutingHistorylength = 30

    • Teste procedimentos de alta disponibilidade e recuperação de desastres:

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

      • Meça os tempos necessários para concluir failovers. Se os tempos forem muito longos, considere:

        • Para o SUSE Linux, use dispositivos SBD em vez do Agente de Esgrima do Azure para acelerar o failover.
        • Para o SAP HANA, se a recarga de dados demorar muito, considere melhorar o desempenho do armazenamento.

      • Teste a sequência e o tempo de backup/restauração e ajuste se necessário. Certifique-se de que não apenas os tempos de backup são suficientes. Além disso, teste a restauração e tome o tempo nas atividades de restauração. certifique-se de que os tempos de restauração estejam dentro de seus SLAs de 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. Realizar verificações de segurança

  • Teste a validade da abordagem RBAC (acesso baseado em função) do Azure que você implementou. O objetivo é separar e limitar o acesso e as permissões delegadas a diferentes equipes. Como exemplo, os membros da equipe do 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 do SAP Basis não deve ser capaz de 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 ser capazes de implantar VMs do Azure em redes virtuais onde o aplicativo SAP e as VMs DBMS estão em execução. Os membros da equipe de rede também não devem ser capazes de alterar atributos de VMs ou excluir VMs e seus discos.
  • Verifique se as regras do NSG estão funcionando conforme o esperado e proteja 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.
  • Considere uma abordagem pragmática ao decidir se deve implementar um mecanismo de criptografia. Por exemplo, avalie se é necessário aplicar a criptografia de Disco do Azure e a Criptografia de Banco de Dados Transparente DBMS.

5. Desempenho dos ensaios

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 em:

  • Top 10 relatórios online
  • Top 10 trabalhos em lote
  • Transferências de dados através de interfaces para o sistema SAP, com foco no tráfego entre locais