Topologia de rede e conectividade para uma migração SAP

  • Artigo

Este artigo baseia-se nas considerações e recomendações definidas na área de design da zona de aterrissagem do Azure para topologia de rede e conectividade. As diretrizes neste artigo examinam as principais considerações de design e práticas recomendadas para rede e conectividade para, de e dentro de implantações do Microsoft Azure e SAP. Como o SAP é uma plataforma de missão crítica, seu design também deve seguir as orientações sobre as áreas de design da zona de aterrissagem do Azure.

Planejar o endereçamento IP

Um plano de endereçamento IP no Azure é vital para garantir que:

  • O espaço de endereço IP não se sobrepõe a locais e regiões do Azure.
  • A rede virtual contém o espaço de endereço correto.
  • Os planos de configuração de sub-rede ocorrem com antecedência.

O diagrama de arquitetura a seguir mostra considerações de rede no SAP em um acelerador de zona de aterrissagem do Azure:

A diagram of networking considerations in SAP on an Azure landing zone accelerator.

Considerações de design para implementação SAP:

Você pode dedicar e delegar sub-redes a determinados serviços e, em seguida, criar instâncias desses serviços dentro dessas sub-redes. Embora o Azure ajude você a criar várias sub-redes delegadas em uma rede virtual, você só pode ter uma sub-rede delegada em uma rede virtual para Arquivos NetApp do Azure. Se você usar mais de uma sub-rede delegada para Arquivos NetApp do Azure, não poderá criar um novo volume.

Caso de uso:

Você precisa de sub-redes delegadas para implementar os Arquivos NetApp do Azure. Essa abordagem é popular para implantações SAP que compartilham sistemas de arquivos. Você precisa de uma sub-rede delegada somente para um gateway de aplicativo durante o balanceamento de carga ou para o SAP BusinessObjects Business Intelligence, que é um servidor de aplicativos Web SAP de balanceamento de carga.

Configurar DNS e resolução de nomes para recursos locais e do Azure

O DNS (Sistema de Nomes de Domínio) é uma parte crítica da arquitetura da zona de aterrissagem do Azure. Algumas organizações podem querer usar seus investimentos existentes em DNS. Outros podem ver a adoção da nuvem como uma oportunidade para modernizar sua infraestrutura DNS interna e usar recursos nativos do Azure.

Recomendações de design para implementação SAP:

Use as seguintes recomendações de caso de uso quando o DNS ou o nome virtual de uma máquina virtual não for alterado durante a migração.

Caso de uso:

  • DNS em segundo plano e nomes virtuais conectam muitas interfaces de sistema no cenário SAP, e os clientes só às vezes estão cientes das interfaces que os desenvolvedores definem ao longo do tempo. Os desafios de conexão surgem entre sistemas quando nomes virtuais ou DNS mudam após migrações. Para simplificar, recomendamos que mantenha os aliases DNS.

  • Use diferentes zonas DNS para distinguir cada ambiente, incluindo ambientes de área restrita, desenvolvimento, pré-produção e produção, uns dos outros. Uma exceção é para implantações SAP que têm sua própria rede virtual. Nesse cenário, zonas DNS privadas podem não ser necessárias.

Definir uma topologia de rede do Azure

As zonas de aterrissagem em escala empresarial suportam duas topologias de rede. Uma topologia é baseada na WAN Virtual do Azure. O outro é uma topologia de rede tradicional baseada em uma arquitetura hub-and-spoke. Esta seção descreve as configurações e práticas recomendadas do SAP para ambos os modelos de implantação.

Use uma topologia de rede baseada na WAN Virtual se sua organização planejar:

  • Implante recursos em várias regiões do Azure e conecte seus locais globais a ambientes do Azure e locais.
  • Integre totalmente implantações de WAN definidas por software com o Azure.
  • Implante até 2.000 cargas de trabalho de máquina virtual em todas as redes virtuais conectadas a um hub WAN virtual.

As organizações usam a WAN Virtual para atender aos requisitos de interconectividade em grande escala. A Microsoft gerencia esse serviço, o que ajuda a reduzir a complexidade geral da rede e modernizar a rede da sua organização.

Use uma topologia de rede tradicional do Azure baseada em uma arquitetura hub-and-spoke se sua organização:

  • Planeja implantar recursos em apenas regiões selecionadas do Azure.
  • Não precisa de uma rede global e interconectada.
  • Tem poucos locais remotos ou filiais por região e precisa de menos de 30 túneis IPSec (Internet Protocol Security).
  • Requer controle total e granularidade para configurar manualmente sua rede do Azure.

Recomendações de design para implementação SAP:

  • Use a WAN Virtual para implantações do Azure em redes novas, grandes ou globais nas quais você precisa de conectividade de trânsito global entre regiões do Azure e locais locais. Ao adotar essa abordagem, você não precisa configurar manualmente o roteamento transitivo para a rede do Azure e pode seguir um padrão para SAP em implantações do Azure.

  • Considere implantar dispositivos virtuais de rede (NVAs) entre regiões somente se você usar NVAs de parceiros. NVAs entre regiões ou redes virtuais não são necessários se NVAs nativos estiverem presentes. Ao implantar tecnologias de rede de parceiros e NVAs, siga as orientações do fornecedor para identificar configurações conflitantes com a rede do Azure.

  • A WAN virtual gerencia a conectividade entre redes virtuais spoke para topologias baseadas em WAN virtual, portanto, você não precisa configurar rotas definidas pelo usuário (UDRs) ou NVAs. A taxa de transferência máxima da rede para o tráfego de rede para rede no mesmo hub virtual é de 50 Gbps. Para superar essa limitação de largura de banda, as zonas de aterrissagem SAP podem usar o emparelhamento de rede virtual para se conectar a outras zonas de aterrissagem.

  • Nenhuma topologia suporta implantações NVA entre um aplicativo SAP e um servidor de banco de dados.

  • O emparelhamento de rede virtual local e global fornece conectividade e são as abordagens preferidas para garantir a conectividade entre zonas de aterrissagem para implantações SAP em várias regiões do Azure.

Planejar a conectividade de entrada e saída com a Internet

Esta seção descreve os modelos de conectividade recomendados para conectividade de entrada e saída de e para a Internet pública. Os serviços de segurança de rede nativos do Azure, como o Firewall do Azure, o Firewall de Aplicativo Web do Azure no Gateway de Aplicativo do Azure e o Azure Front Door, são serviços totalmente gerenciados, portanto, você não incorre nos custos operacionais e de gerenciamento associados às implantações de infraestrutura.

Recomendações de design para implementação SAP:

  • Para clientes que têm uma presença global, o Azure Front Door facilita as implantações SAP usando políticas do Web Application Firewall para fornecer e proteger aplicativos HTTP e HTTPS globais em regiões do Azure.

  • Aproveite as políticas do Web Application Firewall no Azure Front Door quando estiver usando o Azure Front Door e o Application Gateway para proteger aplicativos HTTP e HTTPS. Bloqueie o tráfego para o Application Gateway para que ele receba tráfego somente da Porta da Frente do Azure.

  • O Application Gateway e o Web Application Firewall têm limitações quando o Application Gateway serve como proxy reverso para aplicativos Web SAP. Como o SAP Web Dispatcher e o NetScaler são mais inteligentes do que o Application Gateway, você precisará fazer testes extensivos se substituí-los pelo Application Gateway. Verifique o status mais atual e liste todos os cenários suportados, não suportados, testados e não testados, se possível.

  • Use um firewall de aplicativo da Web para verificar seu tráfego quando ele estiver exposto à Internet. Outra opção é usá-lo com seu balanceador de carga ou com recursos, como o Application Gateway ou soluções de terceiros, que tenham recursos de firewall integrados.

  • Para evitar vazamento de dados, use o Azure Private Link para acessar com segurança recursos de plataforma como serviço (PaaS), como o Armazenamento de Blobs do Azure, Arquivos do Azure, Azure Data Lake Storage Gen2 e Azure Data Factory. Os pontos de extremidade privados também podem ajudar a proteger o tráfego entre redes virtuais e serviços, como o Armazenamento do Azure e o Backup do Azure. O tráfego entre sua rede virtual e o serviço habilitado para ponto de extremidade privado viaja pela rede global da Microsoft, o que impede sua exposição à Internet pública.

Implementar o Azure ExpressRoute com alta disponibilidade

O Azure ExpressRoute foi projetado para alta disponibilidade para fornecer conectividade de rede privada de nível de operadora para recursos da Microsoft. Não há um único ponto de falha no caminho da Rota Expressa na rede da Microsoft. Para maximizar a disponibilidade, o segmento de cliente e provedor de serviços do seu circuito de Rota Expressa também deve ser criado para alta disponibilidade.

Recomendações de design para implementações SAP:

Definir requisitos de criptografia de rede

Esta seção explora as principais recomendações para criptografar redes entre ambientes locais e do Azure e entre regiões do Azure.

Considerações de design para implementações SAP:

  • O tráfego não é criptografado por padrão quando você usa a Rota Expressa para configurar o emparelhamento privado.

  • Não é necessário criptografar o tráfego nas implantações do ExpressRoute for SAP. O tráfego SAP normalmente consome muita largura de banda e é sensível ao desempenho. Os túneis IPSec encriptam o tráfego da Internet por predefinição, e a encriptação ou desencriptação pode afetar negativamente o desempenho do tráfego.

  • O cliente determina se o tráfego SAP deve ser criptografado. Para saber mais sobre as opções de criptografia de rede em zonas de aterrissagem em escala empresarial, consulte Topologia e conectividade de rede.

Sistemas de segregação

Existem diferentes ambientes, incluindo ambientes de desenvolvimento, teste, qualidade, pré-produção e produção, em um cenário SAP, e os clientes tendem a categorizar esses sistemas em construções lógicas ou físicas para manter os padrões de segurança e conformidade. A ideia é gerenciar todos os sistemas que têm o mesmo ciclo de vida em um grupo de recursos comum. Você pode definir esses grupos em vários níveis, como no nível de assinatura ou de grupo de recursos.

Sua organização também deve considerar a estrutura de segurança e políticas ao agrupar recursos em um cenário SAP. No entanto, para que os transportes SAP fluam entre ambientes de desenvolvimento, teste, qualidade e produção, sua organização pode precisar:

  • Emparelhamento de rede virtual.
  • Aberturas de portas de firewall entre redes virtuais.
  • UDR e regras de grupo de segurança de rede (NSG).

Não recomendamos que você hospede o sistema de gerenciamento de banco de dados (DBMS) e as camadas de aplicativos dos sistemas SAP em diferentes redes virtuais e conecte-as usando o emparelhamento de rede virtual. O tráfego de rede excessivo entre as camadas pode acarretar custos substanciais.

Recomendações adicionais para implementações SAP:

  • Nenhuma topologia suporta a colocação da camada de aplicativos SAP e do SAP DBMS em diferentes redes virtuais do Azure que não estão emparelhadas.

  • Você pode usar o grupo de segurança do aplicativo (ASG) e as regras NSG para definir listas de controle de acesso de segurança de rede entre o aplicativo SAP e as camadas DBMS. Você pode adicionar máquinas virtuais aos ASGs para ajudar a gerenciar sua segurança.

  • Habilite a rede acelerada do Azure nas máquinas virtuais que você usa nas camadas de aplicativo SAP e DBMS. Os seguintes níveis de sistema operacional oferecem suporte à rede acelerada no Azure:

    • Windows Server 2012 R2 ou posterior
    • SUSE Linux Enterprise Desktop 12 SP3 ou posterior
    • Red Hat Enterprise Linux 7.4 ou posterior
    • Oracle Linux 7.5
      • O kernel compatível com o Red Hat Enterprise Linux requer a versão 3.10.0-862.13.1.el7.
      • O Oracle Unbreakable Enterprise Kernel requer a versão 5.

  • Certifique-se de configurar implantações internas para o Balanceador de Carga do Azure para usar o recurso de retorno direto do servidor. Esse recurso reduz a latência quando você usa configurações de balanceador de carga interno para configurações de alta disponibilidade na camada DBMS.

  • Se você estiver usando o Load Balancer com sistemas operacionais convidados Linux, verifique se o parâmetro net.ipv4.tcp_timestamps de rede Linux está definido como 0.

  • Para obter uma latência de rede ideal com aplicativos SAP, considere o uso de grupos de posicionamento de proximidade do Azure.

  • Para projetos de migração, considere ajustar os parâmetros de rede. Por exemplo, você pode melhorar o desempenho desativando as confirmações durante o período de migração.

  • Explore o portal de suporte SAP e o SAP Note 2391465 para saber mais sobre a implementação do SAP.

Considerações de design para implementações RISE

Quando você executa implantações do SAP RISE no Azure, a integração do ambiente gerenciado pelo SAP com seu próprio ecossistema do Azure é fundamental. Para saber mais sobre as práticas recomendadas e as orientações, consulte Integrando o Azure com cargas de trabalho gerenciadas pelo SAP RISE.

A implementação do SAP RISE geralmente tem duas opções, VPN site a site ou emparelhamento de rede virtual, para conectividade. Se você não tiver nenhuma carga de trabalho anterior do Azure, a VPN site a site pode ser a opção mais fácil. No entanto, se você pretende adotar o Azure como uma plataforma estratégica, pode estar interessado em configurar uma zona de aterrissagem do Azure adequada e usar o emparelhamento de rede virtual para o locatário do SAP RISE. Para esses cenários, uma zona de aterrissagem simplificada, como a zona de aterrissagem de migração do Cloud Adoption Framework, pode ser uma boa opção. Você pode facilmente adaptar este plano aos requisitos do cliente, com um foco específico nos parâmetros da rede virtual.

A implantação do emparelhamento de rede virtual entre locatários para o locatário do SAP RISE também requer mais trabalho. Você precisa planejar cuidadosamente a arquitetura de rede virtual para garantir que não haja intervalos de roteamento entre domínios sem classe sobrepostos. Você também deve emparelhar corretamente o DNS ao locatário do SAP RISE.

Finalmente, se você decidir configurar uma solução de WAN Virtual e também precisar de conexões VPN site a site ou ExpressRoute, considere os limites e limitações.