Conectividade com SAP RISE

Com seu cenário SAP operado dentro do RISE e funcionando em uma rede virtual separada, neste artigo fornecemos opções de conectividade disponíveis.

Emparelhamento de rede virtual com SAP RISE/ECS

Um emparelhamento de rede virtual (vnet) é a maneira mais eficiente de se conectar com segurança entre duas redes virtuais, tudo em um espaço de endereçamento de rede privada. As redes emparelhadas aparecem como uma só para fins de conectividade, permitindo que os aplicativos conversem entre si. Aplicações a executar em diferentes redes virtuais, subscrições, entidades Azure ou regiões podem comunicar diretamente. Como o tráfego de rede em uma única rede virtual, o tráfego de emparelhamento permanece em um espaço de endereçamento privado e não atravessa a Internet. Aplicam-se taxas de emparelhamento de rede virtual.

Para implantações do SAP RISE/ECS, o emparelhamento virtual é a maneira preferida de estabelecer conectividade com o ambiente existente do Azure do cliente. Os principais benefícios são:

• Latência de rede minimizada e taxa de transferência máxima entre o cenário SAP RISE e os próprios aplicativos e serviços em execução no Azure.
• Sem complexidade e custo extras com um caminho de comunicação local dedicado para a carga de trabalho do SAP RISE. Em vez disso, seu hub de rede existente do Azure fornece o caminho de comunicação local.

O emparelhamento de rede virtual pode ser configurado na mesma região do seu ambiente gerenciado SAP, mas também por meio do emparelhamento de rede virtual global entre quaisquer duas regiões do Azure. Com o SAP RISE/ECS disponível em muitas regiões do Azure, a região deve corresponder à carga de trabalho em execução nas redes virtuais do cliente devido a considerações de latência e custo de emparelhamento. No entanto, alguns dos cenários (por exemplo, implantação central do S/4HANA para uma empresa globalmente presente) também exigem redes pares globalmente. Para um panorama SAP distribuído globalmente, recomendamos a utilização de uma arquitetura de rede multi-região dentro do seu próprio ambiente Azure, com o SAP RISE a estabelecer peering localmente em cada geografia com os seus hubs de rede.

Tanto o SAP quanto as redes virtuais do cliente são protegidos com grupos de segurança de rede (NSG), permitindo a comunicação no SAP e nas portas do banco de dados por meio do emparelhamento. A comunicação entre as redes virtuais emparelhadas é protegida por meio desses NSGs, limitando a comunicação de e para o ambiente SAP do cliente.

Como o SAP RISE/ECS é executado no locatário e nas assinaturas do Azure da SAP, configure o emparelhamento de rede virtual entre diferentes locatários. Você realiza essa configuração configurando o emparelhamento com a ID de recurso do Azure da rede fornecida pelo SAP e faz com que o SAP aprove o emparelhamento. Adicione um utilizador do inquilino Microsoft Entra oposto como utilizador convidado, aceite o convite de utilizador convidado e siga o processo documentado em Criar uma rede virtual peering - diferentes subscrições. Entre em contato com seu representante SAP para obter as etapas exatas necessárias. Envolva as respetivas equipes dentro da sua organização que lidam com rede, administração de usuários e arquitetura para permitir que esse processo seja concluído rapidamente.

A SAP não oferece conectividade privada através de endpoints privados para cargas de trabalho SAP RISE para os clientes, em geral. Alguns cenários raros e isolados podem utilizar este endpoint privado para os clientes, mas a SAP não permite esses endpoints privados para o ambiente SAP gerido.

Firewall como serviço e peering de subnetes

Para clientes que necessitam de segurança baseada em rede mais forte do que os NSGs, a RISE oferece um serviço premium opcional chamado "Firewall as a Service (FWaaS)". O firewall é um serviço gerido fornecido pela SAP RISE/ECS e proporciona a macro-segmentação das cargas de trabalho SAP em diferentes níveis. Sistemas dentro do mesmo nível podem contornar o firewall e comunicar diretamente, enquanto a comunicação entre camadas tem de passar pelo firewall e seguir as regras de controlo de tráfego. Pode modificar o conjunto de regras necessário e obter registos de firewall e registos de auditoria através do serviço RISE LogServ.

Para permitir o serviço FWaaS, é estabelecido um emparelhamento de sub-rede entre uma sub-rede do VNet RISE e uma sub-rede do lado do cliente. Ao contrário do peering VNet completo, o peering por sub-redes só permite a comunicação entre as sub-redes selecionadas envolvidas no peering. Quando subscreve a oferta FWaaS da RISE, estabelece-se peering de sub-rede entre uma sub-rede da RISE que hospeda um firewall e uma sub-rede do cliente que hospeda um NVA ou outro dispositivo de encaminhamento. Cada NVA é configurado como o principal destino de rota para toda a comunicação RISE. Como resultado, todo o tráfego entre cargas de trabalho SAP RISE e a sua rede passará por ambos os appliances.

O firewall operado pela RISE não substitui os firewalls operados pelo cliente dentro da sua própria subscrição, o serviço FWaaS complementa a sua configuração atual.

VPN vnet-para-vnet

Como alternativa ao emparelhamento de rede virtual, a conexão de rede virtual privada (VPN) pode ser estabelecida entre gateways VPN, implantados tanto na assinatura SAP RISE/ECS quanto na própria dos clientes. Você pode estabelecer uma conexão vnet-to-vnet entre esses dois gateways VPN, permitindo uma comunicação rápida entre as duas redes virtuais separadas. As respetivas redes e gateways podem residir em diferentes regiões do Azure.

Embora o emparelhamento de rede virtual seja o modelo de implantação recomendado e mais típico, uma VPN vnet-to-vnet pode potencialmente simplificar um emparelhamento virtual complexo entre o cliente e as redes virtuais SAP RISE/ECS. O Gateway VPN atua como único ponto de entrada na rede do cliente e é gerenciado e protegido por uma equipe central. A taxa de transferência da rede é limitada pelo SKU do gateway escolhido em ambos os lados. Para atender aos requisitos de resiliência, certifique-se de que gateways de rede virtual com redundância de zona sejam usados para essa conexão.

Os Grupos de Segurança de Rede estão em vigor tanto na rede virtual do cliente como na da SAP, de forma idêntica à arquitetura de peering, permitindo a comunicação para portas SAP NetWeaver e HANA conforme necessário. Para obter detalhes sobre como configurar a conexão VPN e quais configurações devem ser usadas, entre em contato com seu representante SAP.

Conectividade de volta ao local

Com uma implantação existente do Azure do cliente, a rede local já está conectada por meio da Rota Expressa (ER) ou VPN. O mesmo caminho de rede local é normalmente usado para cargas de trabalho gerenciadas pelo SAP RISE/ECS. A arquitetura preferida é utilizar gateways ER/VPN existentes na subscrição do cliente para este fim. A rede virtual SAP RISE conectada atua como uma rede secundária integrada ao hub da rede virtual do cliente.

Com essa arquitetura, as políticas centrais e as regras de segurança que regem a conectividade de rede para cargas de trabalho de clientes também se aplicam às cargas de trabalho gerenciadas pelo SAP RISE/ECS. O mesmo caminho de rede local é usado para a rede virtual do cliente e do SAP RISE/ECS.

Se atualmente não houver conectividade do Azure para local, entre em contato com seu representante SAP para obter detalhes sobre quais modelos de conexões são possíveis para a carga de trabalho RISE. Se o SAP RISE/ECS estabelecer diretamente no local no RISE, essa conexão local estará disponível apenas para alcançar a rede virtual gerenciada pelo SAP. Essa conexão ExpressRoute ou VPN dedicada no SAP RISE não pode ser usada para acessar as próprias redes virtuais do Azure do cliente. Certifique-se de que sua Rota Expressa tenha sido projetada para resiliência em mente, recomendando-se resiliência alta ou máxima.

WAN virtual com cargas de trabalho gerenciadas pelo SAP RISE

Da mesma forma que usa uma arquitetura de rede hub and spoke com conectividade à rede virtual SAP RISE/ECS e local, o hub Azure Virtual Wan (vWAN) pode ser usado para a mesma finalidade. A carga de trabalho RISE é uma rede spoke conectada ao hub de rede vWAN. Ambas as opções de conexão com o SAP RISE descritas anteriormente – emparelhamento de rede virtual, bem como VPN vnet-to-vnet – estão disponíveis com vWAN.

O hub de rede vWAN é implantado e gerenciado pelo cliente em assinatura própria. O cliente também gerencia inteiramente a conexão local e o roteamento por meio do hub de rede vWAN, com acesso à rede virtual peered spoke SAP RISE.

Conectividade durante a migração para o SAP RISE

A migração do seu cenário SAP para o SAP RISE é feita em várias fases ao longo de vários meses ou mais. Alguns de seus ambientes SAP já são migrados e estão em uso de forma produtiva, enquanto você prepara outros sistemas SAP para migração. Na maioria dos projetos de clientes, os sistemas maiores e mais críticos são migrados no meio ou no final do projeto. Você precisa considerar ter ampla largura de banda para migração de dados ou replicação de banco de dados, e não afetar o caminho de rede de seus usuários para os ambientes RISE já produtivos. Os sistemas SAP já migrados também podem precisar se comunicar com o cenário SAP ainda no local ou no provedor de serviços existente.

Durante o planejamento da migração para o SAP RISE, planeje como, em cada fase, os sistemas SAP podem ser acessados para sua base de usuários e como a transferência de dados para a rede virtual RISE/ECS é roteada. Muitas vezes, vários locais e partes estão envolvidos, como provedores de serviços existentes e data centers com conexão própria à sua rede corporativa. Certifique-se de que nenhuma solução temporária com conexões VPN seja criada sem considerar como, em fases posteriores, os dados SAP são migrados para os sistemas mais críticos para os negócios.

Integração de DNS com cargas de trabalho gerenciadas pelo SAP RISE/ECS

A integração de redes de propriedade do cliente com a infraestrutura baseada em nuvem e o fornecimento de um conceito de resolução de nomes contínuo é uma parte vital de uma implementação de projeto bem-sucedida. Este diagrama descreve um dos cenários comuns de integração de assinaturas de propriedade da SAP, redes virtuais e infraestrutura DNS com a rede local do cliente e serviços DNS. Nessa configuração, o hub do Azure ou os servidores DNS locais estão armazenando todas as entradas DNS. A infraestrutura DNS é capaz de resolver solicitações DNS provenientes de todas as fontes (clientes locais, serviços do Azure do cliente e ambientes gerenciados SAP).

Descrição do projeto e especificidades:

• Configuração de DNS personalizada para redes virtuais de propriedade da SAP

• Duas VMs dentro dos servidores DNS de host de rede virtual do Azure RISE/PCE

• Os clientes devem fornecer e delegar ao SAP um subdomínio/zona (por exemplo, exemplo ecs.contoso.com) para atribuir nomes e criar entradas DNS diretas e inversas para as máquinas virtuais que executam o ambiente gerenciado SAP. Os servidores DNS SAP estão mantendo uma função DNS mestre para a zona delegada

• A transferência de zona DNS do servidor DNS SAP para os servidores DNS do cliente é o principal método para replicar entradas DNS do ambiente RISE/PCE.

• As redes virtuais do Azure do cliente também estão usando a configuração DNS personalizada referente aos servidores DNS do cliente localizados na rede virtual do hub do Azure.

• Opcionalmente, os clientes podem configurar um encaminhador DNS privado em suas redes virtuais do Azure. Em seguida, esse encaminhador envia por push solicitações DNS provenientes dos serviços do Azure para servidores DNS SAP direcionados para a zona delegada (exemplo ecs.contoso.com).

A transferência de zona DNS é aplicável aos designs quando os clientes operam soluções DNS personalizadas (por exemplo, servidores AD DS ou BIND) dentro de sua rede virtual de hub.

A SAP publicou uma postagem no blog sobre a implementação de DNS com o SAP RISE no Azure, veja aqui para obter detalhes.

Para ler mais sobre o uso do DNS do Azure para SAP, fora do uso com o SAP RISE/ECS, consulte os detalhes na postagem de blog a seguir.

Conexões de entrada e saída da Internet com o SAP RISE/ECS

As cargas de trabalho SAP que se comunicam com aplicativos e interfaces externos podem exigir um caminho de saída de rede para a Internet. Da mesma forma, a base de usuários da sua empresa (por exemplo, SAP Fiori) precisa de uma entrada na Internet ou conexões de entrada para o cenário SAP. Para cargas de trabalho gerenciadas pelo SAP RISE, trabalhe com seu representante SAP para explorar as necessidades desses caminhos de comunicação https/RFC/outros. A comunicação de rede de/para a Internet não está, por padrão, habilitada para clientes SAP RISE/ECS e a rede padrão usa apenas intervalos de IP privados. A conectividade com a Internet requer planejamento com o SAP, para proteger de forma ideal o cenário SAP do cliente.

Se você habilitar o tráfego de entrada ou vinculado à Internet com o SAP RISE, a comunicação de rede será protegida por meio de várias tecnologias do Azure, como NSGs, ASGs, Application Gateway com Web Application Firewall (WAF), servidores proxy e outros, dependendo do uso e dos protocolos de rede. Estes serviços são inteiramente geridos através da SAP dentro da rede virtual e subscrição SAP RISE/ECS. O caminho de rede SAP RISE de e para a Internet permanece normalmente apenas na rede virtual SAP RISE/ECS e não transita de/para as vnets do próprio cliente.

As aplicações dentro da sua própria rede virtual ligam-se à Internet a partir da respetiva rede virtual diretamente ou através dos serviços geridos centralmente do cliente, como Azure Firewall, NAT Gateway e outros. A conectividade com o SAP BTP a partir de aplicativos não-SAP RISE/ECS usa o mesmo caminho de rede ligado à Internet do seu lado. Caso seja necessário um SAP Cloud Connecter para essa integração, execute-o nas VMs do cliente. Em outras palavras, a comunicação de seus próprios aplicativos para o SAP BTP ou qualquer endpoint RISE público está em um caminho de rede gerenciado por você. A comunicação do seu ambiente SAP RISE para o SAP BTP ou outros endpoints SAP públicos está num caminho de rede gerido pelo SAP RISE/ECS.

Conectividade SAP BTP

O SAP Business Technology Platform (BTP) fornece uma infinidade de aplicativos normalmente acessados por meio de IP/nome de host público via Internet. Os serviços do cliente em execução em suas assinaturas do Azure acessam o BTP por meio do método de acesso de saída configurado, como firewall central ou IPs públicos de saída. Alguns serviços SAP BTP, como o SAP Data Intelligence, no entanto, são acessados por design por meio de um emparelhamento de rede virtual separado em vez de um ponto de extremidade público.

A SAP oferece o Private Link Service para clientes que usam o SAP BTP no Azure para solicitações unidirecionais originadas do BTP. O SAP Private Link Service conecta serviços SAP BTP por meio de um intervalo de IP privado à rede Azure do cliente e, portanto, acessível de forma privada por meio do serviço de link privado em vez de pela Internet. Entre em contato com a SAP para obter a disponibilidade deste serviço para cargas de trabalho SAP RISE/ECS. Saiba mais sobre o suporte do SAP Private Link para RISE aqui.

Consulte a documentação da SAP e uma série de postagens no blog sobre a arquitetura do SAP BTP Private Link Service e os métodos de conectividade privada do BTP, lidando com DNS e certificados na seguinte série de blogs da SAP Getting Started with BTP Private Link Service for Azure.

A ligação ao BTP não utiliza Private Link e comunica com uma interface pública. Se o SAP BTP e seu cenário SAP RISE estiverem em execução no Azure, o comportamento de roteamento padrão será manter essa comunicação vinculada à Internet no backbone do Azure. Para mais informações, consulte a documentação sobre o encaminhamento de tráfego do Azure para mais detalhes.

Portas de comunicação de rede com SAP RISE

Qualquer serviço do Azure com acesso à rede virtual do cliente pode se comunicar com o cenário SAP em execução na assinatura SAP RISE/ECS por meio das portas disponíveis.

Seu sistema SAP no SAP RISE pode ser acessado através das portas de rede abertas, conforme configurado e aberto pela SAP para seu uso. Os protocolos https, RFC e JDBC/ODBC podem ser usados através de intervalos de endereços de rede privada. Além disso, os aplicativos podem acessar por meio de https em um IP disponível publicamente, exposto pelo gateway de aplicativos do Azure gerenciado pelo SAP RISE. Para obter detalhes e configurações para o gateway de aplicativo e as portas abertas do NSG, entre em contato com a SAP.

Veja mais documento Integrando serviços do Azure com SAP RISE como a conectividade disponível permite estender seu cenário SAP com serviços do Azure.

Próximos passos

Confira a documentação:

• Integrando o Azure com o SAP RISE
• Integrando os serviços do Azure com o SAP RISE
• Identidade e segurança no Azure com o SAP RISE
• Peering de rede virtual
• Guia da série de integração de DNS com o SAP RISE em ambiente multicloud – Azure | SAP Blogs