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 aterragem do Azure para topologia de rede e conectividade. A orientação neste artigo examina 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 a implementação do 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 do Azure NetApp, não poderá criar um novo volume.

Caso de uso:

Você precisa de sub-redes delegadas para implementar os Arquivos do Azure NetApp. Essa abordagem é popular para implantações SAP que compartilham sistemas de arquivos. Você precisa de uma sub-rede delegada apenas para um gateway de aplicativo durante o balanceamento de carga ou para o SAP BusinessObjects Business Intelligence, que é um servidor de aplicativos da 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 no DNS. Outras podem ver a adoção da nuvem como uma oportunidade para modernizar sua infraestrutura de DNS interna e usar recursos nativos do Azure.

Recomendações de design para a implementação do 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:

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

  • Use zonas DNS diferentes 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 oferecem suporte a duas topologias de rede. Uma topologia é baseada na WAN Virtual do Azure. A outra é 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 com base na WAN Virtual se sua organização planeja:

  • Implante recursos em várias regiões do Azure e conecte seus locais globais ao Azure e a ambientes locais.
  • Integrar totalmente implantações 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 de WAN Virtual.

As organizações usam a WAN Virtual para atender aos requisitos de interconectividade em larga 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 com base em uma arquitetura hub-and-spoke se sua organização:

  • Planeja implantar recursos apenas em 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 a implementação do 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 implantações do SAP no Azure.

  • Considere a implantação de 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, para que você não precise configurar rotas definidas pelo usuário (UDRs) ou NVAs. A taxa de transferência de rede máxima 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 do SAP podem usar o emparelhamento de rede virtual para se conectar a outras zonas de aterrissagem.

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

  • Emparelhamento de rede virtual local e global fornecem 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 da 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 a implementação do 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 Gateway de Aplicativo para que ele receba tráfego somente do Azure Front Door.

  • O Application Gateway e o Web Application Firewall têm limitações quando o Application Gateway serve como um proxy reverso para aplicativos Web SAP. Como o SAP Web Dispatcher e o NetScaler são mais inteligentes 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 com suporte, não suportados, testados e não testados, se possível.

  • Use um firewall do aplicativo 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 internos de firewall.

  • Para evitar o vazamento de dados, use o Link Privado do Azure para acessar com segurança recursos de PaaS (plataforma como serviço), como 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 aos 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.

  • Você não precisa criptografar o tráfego no ExpressRoute para implantações SAP. O tráfego do SAP normalmente consome muita largura de banda e é sensível ao desempenho. Os túneis IPSec criptografam o tráfego da Internet por padrão, e a criptografia ou descriptografia 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 de escala empresarial, consulte Topologia e conectividade de rede.

Sistemas de separação

Há 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 grupo de recursos.

Sua organização também deve considerar a estrutura de segurança e política 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 porta de firewall entre redes virtuais.
  • Regras UDR e NSG (grupo de segurança de rede).

Não recomendamos hospedar o sistema de gerenciamento de banco de dados (DBMS) e as camadas de aplicativos dos sistemas SAP em diferentes redes virtuais e conectá-los usando emparelhamento de rede virtual. O tráfego de rede excessivo entre as camadas pode acumular custos substanciais.

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

  • Nenhuma topologia oferece suporte à colocação da camada de aplicativo SAP e do SGBD SAP em diferentes redes virtuais do Azure que não são emparelhadas.

  • Você pode usar as regras ASG (grupo de segurança de aplicativo) e NSG para definir as listas de controle de acesso de segurança de rede entre o aplicativo SAP e as camadas de DBMS. Você pode adicionar máquinas virtuais a 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 versões posteriores
    • 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 internas do balanceador de carga 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 uma latência de rede ideal com aplicativos SAP, considere o uso de grupos de posicionamento por proximidade do Azure.

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

  • Explore o portal de suporte do SAP e a Nota SAP 2391465 para saber mais sobre como implementar o SAP.

Considerações de design para implementações do 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 às cargas de trabalho gerenciadas do 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ê imaginar adotar o Azure como uma plataforma estratégica, talvez esteja interessado em configurar uma zona de aterrissagem adequada do Azure 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 esse blueprint 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 no 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 para o 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.