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. Os aplicativos executados em diferentes redes virtuais, assinaturas, locatários do Azure ou regiões podem se 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.
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 adicionais com diferentes caminhos de comunicação locais para o SAP RISE, em vez disso, usando hub(s) de rede do Azure existentes.
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 esse cenário SAP distribuído globalmente, recomendamos usar a arquitetura de rede de várias regiões em seu próprio ambiente do Azure, com o SAP RISE emparelhando localmente em cada geografia para seus hubs de rede.
Este diagrama mostra as redes virtuais de hub e spoke típicas de um cliente SAP. O emparelhamento de rede virtual entre locatários conecta o SAP RISE e as redes virtuais de hub do cliente.
Tanto o SAP quanto a(s) rede(s) virtual(is) do cliente são protegidos com grupos de segurança de rede (NSG), permitindo a comunicação no SAP e portas de banco de dados através 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 usuário do locatário oposto do Microsoft Entra como usuário convidado, aceite o convite de usuário convidado e siga o processo documentado em Criar um emparelhamento de rede virtual - assinaturas diferentes. Entre em contato com seu representante SAP para obter as etapas exatas necessárias. Envolva a(s) respetiva(s) equipe(s) 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.
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.
Este diagrama mostra as redes virtuais de hub e spoke típicas de um cliente SAP. O gateway VPN localizado na rede virtual SAP RISE se conecta através da conexão vnet-to-vnet ao gateway contido na rede virtual do hub do cliente.
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 na rede virtual do cliente e da SAP, de forma idêntica à arquitetura de emparelhamento que permite a comunicação com as 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 é usar gateways ER/VPN existentes nos clientes para este fim, com a rede virtual SAP RISE conectada vista como uma rede spoke conectada ao hub de rede virtual do cliente.
Este diagrama mostra as redes virtuais de hub e spoke típicas de um cliente SAP. Conecta-se ao local com uma conexão. O emparelhamento de rede virtual entre locatários conecta a rede virtual SAP RISE à rede de hub do cliente. O emparelhamento de rede virtual tem o trânsito de gateway remoto habilitado, permitindo que a rede virtual SAP RISE seja acessada localmente.
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.
Nota
Uma rede virtual pode ter apenas um gateway, local ou remoto. Com o emparelhamento de rede virtual estabelecido entre o SAP RISE usando o trânsito de gateway remoto, nenhum gateway pode ser adicionado na rede virtual SAP RISE/ECS. Não é possível uma combinação de emparelhamento de rede virtual com trânsito de gateway remoto juntamente com outro gateway de rede virtual na rede virtual SAP RISE/ECS.
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.
Nota
Tanto o DNS fornecido pelo Azure quanto as zonas privadas do Azure não oferecem suporte à capacidade de transferência de zona DNS, portanto, não podem ser usadas para aceitar replicação DNS de servidores DNS SAP RISE/PCE/ECS. Além disso, o SAP normalmente não oferece suporte a provedores de serviços DNS externos para a zona delegada.
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 a(s) vnet(s) do próprio cliente.
Os aplicativos dentro da própria rede virtual de um cliente se conectam à Internet diretamente da respetiva rede virtual ou por meio dos serviços gerenciados centralmente do cliente, como o Firewall do Azure, o Gateway de Aplicativo do Azure, o Gateway NAT 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, o SAP BTP ou qualquer comunicação de endpoint público está em um caminho de rede gerenciado pelos próprios clientes se a carga de trabalho do SAP RISE não estiver envolvida.
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. 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.
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, lidando com DNS e certificados na seguinte série de blogs da SAP Getting Started with BTP Private Link Service for Azure.
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.
Diagrama de portas abertas em um sistema SAP RISE/ECS. Conexões RFC para BAPI e IDoc, https para OData e Rest/SOAP. ODBC/JDBC para conexões diretas de banco de dados com o SAP HANA. Todas as conexões através do emparelhamento de rede virtual privada. Application Gateway com IP público para https como opção potencial, gerenciado através do SAP.
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:
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários