Este artigo fornece práticas recomendadas para arquitetar um cenário SAP inteiro no Azure. O cenário SAP inclui vários sistemas SAP em ambientes de hub, produção, não produção e recuperação de desastres. Fornecemos recomendações que se concentram no projeto de rede e não em sistemas SAP específicos. O objetivo é fornecer nossas recomendações para arquitetar um cenário SAP seguro, de alto desempenho e resiliente.
Arquitetura
Baixe um arquivo Visio da arquitetura.
Fluxo de Trabalho
- Rede local: conexão ExpressRoute da rede local para regiões conectadas do Azure.
- Hubs regionais de assinatura do Azure: assinatura do Azure que contém serviços centrais para toda a empresa, não apenas para o SAP. A assinatura do hub fornece conectividade por emparelhamento a redes virtuais spoke contendo cargas de trabalho SAP.
- Rede virtual de hub: uma rede virtual falou para o hub central na região primária ou região A.
- Rede virtual de recuperação de desastres (DR) do hub: uma rede virtual falou em nome do hub central na região de recuperação de desastres. Ele espelha o design da sub-rede da rede virtual de produção na região primária.
- Assinatura do Azure SAP não produção: uma assinatura do Azure para todas as cargas de trabalho SAP que não são de produção. Inclui ambientes de pré-produção, garantia de qualidade, desenvolvimento e sandbox.
- Redes virtuais SAP não relacionadas à produção: Separe as redes virtuais para cargas de trabalho SAP que não são de produção na região primária. Cada ambiente SAP tem sua própria rede virtual e sub-redes.
- Produção SAP de assinatura do Azure: uma assinatura do Azure para todas as cargas de trabalho SAP de produção.
- SAP production spoke virtual network: Uma rede virtual para o ambiente de produção SAP com várias sub-redes. Esta rede virtual está na região principal.
- Rede virtual de recuperação de desastres (DR) de produção SAP: uma rede virtual para produção SAP na região secundária de recuperação de desastres. Ele espelha o design da sub-rede da rede virtual de produção na região primária.
- Serviços do Azure: uma amostra dos serviços do Azure que você pode conectar ao cenário SAP.
- SAP Business Technology Platform (BTP): O ambiente SAP acede à SAP Business Technology Platform através do Azure Private Link.
Subscrições do Azure
Recomendamos o uso de um design de rede hub-spoke. Com um design hub-spoke, você precisa de pelo menos três assinaturas para dividir seus ambientes SAP. Você deve ter uma assinatura para (1) redes virtuais de hub regional, (2) redes virtuais de não produção e (3) redes virtuais de produção. As subscrições fornecem limites de faturação, política e segurança. Não existe um número correto de subscrições. O número de subscrições que utiliza depende das suas necessidades de faturação, política e segurança. Em geral, você deseja evitar o uso de muitas assinaturas. Muitas assinaturas podem adicionar sobrecarga de gerenciamento desnecessária e complexidade de rede. Por exemplo, você não precisa de uma assinatura para cada sistema SAP. Nossa arquitetura usa três assinaturas:
Hubs regionais: uma assinatura de hub virtual do Azure em que a rede virtual de hub existe para as regiões primária e secundária. Esta subscrição destina-se a todos os serviços centrais e não apenas à SAP.
SAP não produção: uma assinatura SAP de não produção do Azure onde residem sistemas que não são de produção, incluindo sandbox, desenvolvimento, garantia de qualidade ou sistemas de pré-produção.
Produção SAP: uma assinatura de produção SAP do Azure onde configuramos os sistemas de produção e recuperação de desastres.
Para obter mais informações, consulte:
Design de rede
Uma topologia hub-spoke é o design de rede recomendado para um cenário SAP. Nessa topologia, a rede virtual do hub de produção atua como um ponto central de conectividade. Ele se conecta à rede local e às várias redes virtuais spoke e permite que usuários e aplicativos acessem a carga de trabalho do SAP. Dentro dessa topologia hub-spoke, aqui estão nossas recomendações para o projeto de rede SAP.
Use a Rota Expressa para conexão local. Para cargas de trabalho SAP, recomendamos o uso da Rota Expressa para conectar a rede local à rede virtual Hub e à rede virtual Hub DR. Você pode usar a topologia WAN virtual do Azure se tiver locais globais. Considere configurar uma VPN site a site (S2S) como um backup para o Azure ExpressRoute ou quaisquer requisitos de rota de terceiros.
Para obter mais informações, consulte:
- Topologia de rede e conectividade para uma migração SAP
- Arquitetura Hub e spoke
- Azure virtual WAN
- VPN S2S como backup para emparelhamento privado da Rota Expressa
Use uma rede virtual por ambiente. Recomendamos o uso de uma rede virtual por ambiente (camada de implantação SAP). A arquitetura usa uma rede virtual diferente para produção, desenvolvimento, garantia de qualidade e sandbox. Este design de rede é ideal para grandes arquiteturas empresariais.
Use um firewall central. Todo o tráfego de rede para as redes virtuais faladas, incluindo conexões de chamada de função remota (RFC), deve passar por um firewall central na rede virtual do Hub. A comunicação de rede entre as redes virtuais spoke (comunicação spoke-to-spoke) passa pelo firewall da rede virtual do hub na sub-rede do Firewall do Azure da rede virtual do Hub. Da mesma forma, a comunicação de rede entre as redes virtuais spoke e a rede local também passa pelo firewall da rede virtual do hub. Usamos o emparelhamento de rede virtual para conectar as várias redes virtuais spoke à rede virtual do hub. Toda a comunicação entre as redes virtuais spoke passa pelo firewall da rede virtual Hub. Você também pode usar um dispositivo virtual de rede em vez de um firewall. Para obter mais informações, consulte Dispositivo virtual de rede.
O tráfego de rede que permanece em uma rede virtual não deve passar por um firewall. Por exemplo, não coloque um firewall entre a sub-rede do aplicativo SAP e a sub-rede do banco de dados SAP. Não é possível colocar um firewall ou dispositivos virtuais de rede (NVAs) entre o aplicativo SAP e a camada do sistema de gerenciamento de banco de dados (DBMS) dos sistemas SAP que executam o kernel SAP.
Evite emparelhar redes virtuais faladas. O emparelhamento de redes virtuais entre as redes virtuais faladas deve ser evitado, se possível. O emparelhamento de rede virtual spoke-to-spoke permite que a comunicação spoke-to-spoke contorne o firewall da rede virtual Hub. Você só deve configurar o emparelhamento de rede virtual spoke-to-spoke quando tiver requisitos de alta largura de banda, por exemplo, com replicação de banco de dados entre ambientes SAP. Todo o outro tráfego de rede deve ser executado através da rede virtual do Hub e do firewall. Para obter mais informações, consulte Conexões de entrada e saída da Internet para SAP no Azure.
Sub-redes
É uma prática recomendada dividir cada ambiente SAP (produção, pré-produção, desenvolvimento, sandbox) em sub-redes e usar sub-redes para agrupar serviços relacionados. Aqui estão nossas recomendações para sub-rede em um cenário SAP.
Número de sub-redes
A rede virtual de produção na arquitetura tem cinco sub-redes. Este design é ideal para soluções empresariais de grande dimensão. O número de sub-redes pode ser menor ou maior. O número de recursos na rede virtual deve determinar o número de sub-redes na rede virtual.
Dimensionamento da sub-rede
Verifique se as sub-redes têm espaço de endereço de rede suficiente. Se você usa nomes de host virtual SAP, precisará de mais espaço de endereço em suas sub-redes SAP. Muitas vezes, cada instância SAP requer 2-3 endereços IP e inclui um endereço IP para o nome de host da máquina virtual. Outros serviços do Azure podem exigir sua própria sub-rede dedicada quando implantados nas redes virtuais de carga de trabalho SAP.
Sub-rede do aplicativo
A sub-rede do aplicativo contém máquinas virtuais que executam servidores de aplicativos SAP, SAP Central Services (ASCS), SAP Enqueue Replication Services (ERS) e instâncias SAP Web Dispatcher. A sub-rede também contém um ponto de extremidade privado para Arquivos do Azure. No diagrama, agrupamos as máquinas virtuais por função. Recomendamos o uso de conjuntos de dimensionamento de máquina virtual com orquestração flexível, zonas de disponibilidade ou conjuntos de disponibilidade para implantação resiliente. Para obter mais informações, consulte as próximas etapas.
Sub-rede da base de dados
A sub-rede de banco de dados contém máquinas virtuais que executam bancos de dados. No diagrama, um par de máquinas virtuais com replicação síncrona representa todas as máquinas virtuais de banco de dados de um ambiente SAP.
Sub-redes de perímetro
As sub-redes de perímetro são voltadas para a Internet e incluem uma sub-rede de perímetro SAP e uma sub-rede do Application Gateway. Aqui estão nossas recomendações para projetar essas duas sub-redes.
Sub-rede de perímetro SAP: A sub-rede de perímetro SAP é uma rede de perímetro que contém aplicativos voltados para a Internet, como SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent e Application Gateway. Esses serviços têm dependências em sistemas SAP que uma equipe SAP deve implantar, gerenciar e configurar. Uma equipe central de TI não deve gerenciar os serviços na sub-rede de perímetro SAP. Por esse motivo, você deve colocar esses serviços na rede virtual SAP spoke e não na rede virtual Hub. O diagrama de arquitetura mostra apenas uma rede de perímetro SAP de produção. Ele não tem uma sub-rede de perímetro SAP nas redes virtuais que não são de produção. As cargas de trabalho na assinatura SAP de não produção usam os serviços na sub-rede de perímetro SAP.
Você pode criar uma sub-rede de perímetro SAP definida separada na assinatura que não é de produção. Recomendamos essa abordagem apenas para cargas de trabalho críticas ou cargas de trabalho que mudam com frequência. Um perímetro SAP dedicado que não seja de produção é útil para testes e implantação de novos recursos. Aplicativos menos críticos ou aplicativos que terão apenas algumas modificações ao longo do tempo não precisam de uma sub-rede de perímetro SAP separada que não seja de produção.
Sub-rede do Gateway de Aplicativo: o Gateway de Aplicativo do Azure requer sua própria sub-rede. Use-o para permitir o tráfego da Internet que os serviços SAP, como o SAP Fiori, podem usar. A arquitetura recomendada coloca o Gateway de Aplicativo do Azure junto com seu endereço IP público frontend na rede virtual do Hub. Um Gateway de Aplicativo do Azure requer pelo menos uma sub-rede de tamanho /29. Recomendamos o tamanho /27 ou maior. Não é possível usar as duas versões do Application Gateway (v1 e v2) na mesma sub-rede. Para obter mais informações, consulte sub-rede para o Gateway de Aplicativo do Azure.
Coloque sub-redes de perímetro em uma rede virtual separada para aumentar a segurança: para aumentar a segurança, você pode colocar a sub-rede de perímetro SAP e a sub-rede do Application Gateway em uma rede virtual separada dentro da assinatura de produção SAP. A rede virtual SAP perimeter spoke é emparelhada com a rede virtual Hub e todo o tráfego de rede para redes públicas flui através da rede virtual de perímetro. Essa abordagem alternativa mostra o Gateway de Aplicativo do Azure com seu endereço IP público para conexões de entrada colocadas em uma rede virtual spoke para uso exclusivo do SAP.
Baixe um arquivo do Visio incluindo esta arquitetura alternativa.
Esse design de rede oferece melhores recursos de resposta a incidentes e controle de acesso à rede refinado. No entanto, também aumenta a complexidade do gerenciamento, a latência da rede e o custo da implantação. Vamos discutir cada ponto.
Melhor resposta a incidentes: A rede virtual de raios de perímetro SAP permite o isolamento rápido de serviços comprometidos se você detetar uma violação. Você pode remover o emparelhamento de rede virtual da rede virtual de fala de perímetro SAP para o hub e isolar imediatamente as cargas de trabalho de perímetro SAP e os aplicativos de rede virtual de aplicativos SAP da Internet. Você não quer confiar nas alterações de regras do NSG (grupo de segurança de rede) para responder a incidentes. Alterar ou remover uma regra NSG afeta apenas novas conexões e não corta conexões maliciosas existentes.
Controle de acesso à rede refinado: A rede virtual de perímetro SAP fornece um controle de acesso à rede mais rigoroso de e para a rede virtual de produção SAP spoke.
Maior complexidade, latência e custo: a arquitetura aumenta a complexidade, o custo e a latência do gerenciamento. A comunicação ligada à Internet da rede virtual de produção SAP é emparelhada duas vezes, uma para a rede virtual do Hub e outra para a rede virtual de perímetro SAP para a Internet. O firewall na rede virtual do Hub tem o maior efeito sobre a latência. Recomendamos medir a latência para ver se o seu caso de uso pode suportá-la.
Para obter mais informações, consulte Práticas recomendadas de rede de perímetro.
Sub-rede Azure NetApp Files
Se você estiver usando Arquivos NetApp, deverá ter uma sub-rede delegada para fornecer compartilhamentos de arquivos NFS (sistema de arquivos de rede) ou SMB (bloco de mensagens do servidor) para diferentes cenários SAP no Azure. Uma sub-rede /24 é o tamanho padrão para uma sub-rede NetApp Files, mas você pode alterar o tamanho para atender às suas necessidades. Use seus próprios requisitos para determinar o dimensionamento adequado. Para obter mais informações, consulte sub-rede delegada.
Segurança de sub-rede
O uso de sub-redes para agrupar recursos SAP que têm os mesmos requisitos de regra de segurança facilita o gerenciamento da segurança.
Grupos de segurança de rede (NSG): as sub-redes permitem implementar grupos de segurança de rede no nível da sub-rede. O agrupamento de recursos na mesma sub-rede que exigem regras de segurança diferentes requer grupos de segurança de rede no nível da sub-rede e da interface de rede. Com esta configuração de dois níveis, as regras de segurança entram facilmente em conflito e podem causar problemas de comunicação inesperados que são difíceis de resolver. As regras NSG também afetam o tráfego dentro da sub-rede. Para obter mais informações sobre NSGs, consulte grupos de segurança de rede.
Grupos de segurança de aplicativos (ASG): recomendamos o uso de grupos de segurança de aplicativos para agrupar interfaces de rede de máquinas virtuais e fazer referência aos grupos de segurança de aplicativos nas regras de grupo de segurança de rede. Essa configuração permite a criação e o gerenciamento de regras mais fáceis para implantações SAP. Cada interface de rede pode pertencer a vários grupos de segurança de aplicativos com diferentes regras de grupo de segurança de rede. Para obter mais informações, consulte Grupos de segurança de aplicativos.
Azure Private Link
Recomendamos usar o Azure Private Link para melhorar a segurança das comunicações de rede. O Azure Private Link usa pontos de extremidade privados com endereços IP privados para se comunicar com os serviços do Azure. Os Links Privados do Azure evitam o envio de comunicação de rede pela Internet para pontos de extremidade públicos. Para obter mais informações, consulte pontos de extremidade privados nos serviços do Azure.
Usar pontos de extremidade privados na sub-rede do aplicativo: recomendamos usar pontos de extremidade privados para conectar a sub-rede do aplicativo aos serviços suportados do Azure. Na arquitetura, há um ponto de extremidade privado para Arquivos do Azure na sub-rede Aplicativo de cada rede virtual. Você pode estender esse conceito para qualquer serviço do Azure com suporte.
Use o Azure Private Link for SAP Business Technology Platform (BTP): o Azure Private Link for SAP Business Technology Platform (BTP) agora está disponível para o público em geral. O SAP Private Link Service suporta conexões do SAP BTP, o tempo de execução do Cloud Foundry e outros serviços. Exemplos de cenários incluem SAP S/4HANA ou SAP ERP em execução na máquina virtual. Eles podem se conectar aos serviços nativos do Azure, como o Banco de Dados do Azure para MariaDB e o Banco de Dados do Azure para MySQL.
A arquitetura representa uma conexão SAP Private Link Service de ambientes SAP BTP. O SAP Private Link Service estabelece uma conexão privada entre serviços específicos do SAP BTP e serviços específicos em cada rede como contas de provedor de serviços. O link privado permite que os serviços BTP acessem seu ambiente SAP por meio de conexões de rede privada. Melhora a segurança ao não utilizar a Internet pública para comunicar.
Para obter mais informações, consulte:
- Recursos do Azure Private Link
- Azure Database for MariaDB
- Base de Dados do Azure para MySQL
- Conexão com a Internet para SAP no Azure
Compartilhamentos de arquivos NFS (Network File System) e SMB (Server Message Block)
Os sistemas SAP geralmente dependem de volumes de sistemas de arquivos de rede ou compartilhamentos de blocos de mensagens do servidor. Esses compartilhamentos de arquivos movem arquivos entre máquinas virtuais ou funcionam como uma interface de arquivo com outros aplicativos. Recomendamos o uso de serviços nativos do Azure, como Arquivos Premium do Azure e Arquivos NetApp do Azure, como seus compartilhamentos de arquivos NFS (sistema de arquivos de rede) e SMB (bloco de mensagens do servidor). Os serviços do Azure têm melhor disponibilidade combinada, resiliência e contratos de nível de serviço (SLAs) do que ferramentas baseadas no sistema operacional.
Para obter mais informações, consulte:
Ao arquitetar sua solução SAP, você precisa dimensionar corretamente os volumes individuais de compartilhamento de arquivos e saber a qual compartilhamento de arquivos do sistema SAP se conecta. Tenha em mente as metas de escalabilidade e desempenho do serviço do Azure durante o planejamento. A tabela a seguir descreve os compartilhamentos de arquivos SAP comuns e fornece uma breve descrição e o uso recomendado em todo um ambiente SAP.
| Nome da partilha de ficheiros | Utilização | Recomendação |
|---|---|---|
sapmnt |
Sistema SAP distribuído, perfil e diretórios globais | Compartilhamento dedicado para cada sistema SAP, sem reutilização |
cluster |
Compartilhamentos de alta disponibilidade para ASCS, ERS e banco de dados de acordo com o respetivo design | Compartilhamento dedicado para cada sistema SAP, sem reutilização |
saptrans |
Diretório de transporte SAP | Uma ação para um ou poucos cenários SAP (ERP, Business Warehouse) |
interface |
Troca de arquivos com aplicativos não-SAP | Requisitos específicos do cliente, compartilhamentos de arquivos separados por ambiente (produção, não produção) |
Você só pode compartilhar saptrans entre diferentes ambientes SAP e, como tal, deve considerar cuidadosamente seu posicionamento. Evite consolidar muitos sistemas SAP em um saptrans único compartilhamento por motivos de escalabilidade e desempenho.
As políticas de segurança corporativa orientarão a arquitetura e a separação de volumes entre ambientes. Um diretório de transporte com separação por ambiente ou camada precisa de comunicação RFC entre ambientes SAP para permitir grupos de transporte SAP ou links de domínio de transporte. Para obter mais informações, consulte:
Serviços de dados
A arquitetura contém serviços de dados do Azure que ajudam você a estender e melhorar sua plataforma de dados SAP. Para ajudar a desbloquear informações comerciais, recomendamos que utilize serviços como o Azure Synapse Analytics, o Azure Data Factory e o Azure Data Lake Storage. Esses serviços de dados ajudam a analisar e visualizar dados SAP e dados não SAP.
Para muitos cenários de integração de dados, é necessário um tempo de execução de integração. O tempo de execução de integração do Azure é a infraestrutura de computação que os pipelines do Azure Data Factory e do Azure Synapse Analytics usam para fornecer recursos de integração de dados. Recomendamos a implantação de máquinas virtuais de tempo de execução para esses serviços para cada ambiente separadamente. Para obter mais informações, consulte:
- Tempo de execução da integração do Azure
- Configurar um tempo de execução de integração auto-hospedado para usar na solução SAP CDC
- Copiar dados do SAP HANA
- Copie dados do SAP Business Warehouse via Open Hub
Serviços partilhados
As soluções SAP dependem de serviços partilhados. O balanceador de carga e os gateways de aplicativos são exemplos de serviços que vários sistemas SAP usam. A arquitetura, mas suas necessidades organizacionais devem determinar como você arquiteta seus serviços compartilhados. Aqui estão as orientações gerais que você deve seguir.
Balanceadores de carga: Recomendamos um balanceador de carga por sistema SAP. Essa configuração ajuda a minimizar a complexidade. Você deseja evitar muitos pools e regras em um único balanceador de carga. Essa configuração também garante que a nomenclatura e o posicionamento estejam alinhados com o sistema SAP e o grupo de recursos. Cada sistema SAP com uma arquitetura de alta disponibilidade (HA) clusterizada deve ter pelo menos um balanceador de carga. A arquitetura usa um balanceador de carga para as máquinas virtuais ASCS e um segundo balanceador de carga para as máquinas virtuais de banco de dados. Alguns bancos de dados podem não exigir balanceadores de carga para criar uma implantação de alta disponibilidade. SAP HANA faz. Verifique a documentação específica do banco de dados para obter mais detalhes.
Application Gateway: recomendamos pelo menos um gateway de aplicativo por ambiente SAP (produção, não produção e sandbox), a menos que a complexidade e o número de sistemas conectados sejam muito altos. Você pode usar um gateway de aplicativo para vários sistemas SAP para reduzir a complexidade, já que nem todos os sistemas SAP no ambiente exigem acesso público. Um único gateway de aplicativo pode servir várias portas de despachante da Web para um único sistema SAP S/4HANA ou ser usado por diferentes sistemas SAP.
Máquinas virtuais SAP Web Dispatcher: a arquitetura mostra um pool de duas ou mais VMs do SAP Web Dispatcher. Recomendamos que você não reutilize máquinas virtuais SAP Web Dispatcher entre diferentes sistemas SAP. Mantê-los separados permite dimensionar as máquinas virtuais do Web Dispatcher para atender às necessidades de cada sistema SAP. Para soluções SAP menores, recomendamos incorporar os serviços do Web Dispatcher na instância ASCS.
Serviços SAP: serviços SAP como SAProuter, Cloud Connector e Analytics Cloud Agent, são implantados com base nos requisitos do aplicativo, centralmente ou divididos. Nenhuma recomendação de reutilização entre sistemas SAP devido aos diversos requisitos do cliente. A principal decisão a tomar é mencionada na seção de rede, se e quando a sub-rede de perímetro SAP para não produção deve ser usada. Caso contrário, com apenas a sub-rede de perímetro de produção para SAP, os serviços de perímetro SAP são consumidos por todo o cenário SAP.
Recuperação após desastre
A recuperação de desastres (DR) aborda o requisito de continuidade de negócios caso a região principal do Azure não esteja disponível ou comprometida. De uma perspetiva geral do cenário SAP e mostrada no diagrama, aqui estão nossas recomendações para o projeto de recuperação de desastres.
Usar diferentes intervalos de endereços IP As redes virtuais abrangem apenas uma única região do Azure. Qualquer solução de recuperação de desastres deve usar uma região diferente. Você precisa criar uma rede virtual diferente na região secundária. A rede virtual no ambiente DR precisa de um intervalo de endereços IP diferente para permitir a sincronização do banco de dados por meio da tecnologia nativa do banco de dados.
Serviços centrais e conectividade com o local: a conectividade com serviços centrais locais e de chave (DNS ou firewalls) deve estar disponível na região de recuperação de desastres. A disponibilidade e a configuração de alteração dos serviços centrais de TI precisam fazer parte do seu plano de recuperação de desastres. Os serviços centrais de TI são componentes fundamentais para um ambiente SAP funcional.
Usar o Azure Site Recovery O Azure Site Recovery replica e protege as configurações de discos gerenciados e máquinas virtuais para servidores de aplicativos para a região de DR.
Garantir a disponibilidade do compartilhamento de arquivos: o SAP depende da disponibilidade de compartilhamentos de arquivos importantes. A replicação de backup ou compartilhamento contínuo de arquivos é necessária para fornecer dados sobre esses compartilhamentos de arquivos com perda mínima de dados no cenário de DR.
Replicação de banco de dados O Azure Site Recovery não pode proteger os servidores de banco de dados SAP devido à alta taxa de alteração e à falta de suporte ao banco de dados pelo serviço. Você precisa configurar a replicação contínua e assíncrona do banco de dados para a região de recuperação de desastres.
Para obter mais informações, consulte Visão geral da recuperação de desastres e diretrizes de infraestrutura para carga de trabalho SAP.
Arquitetura SAP menor
Para soluções SAP menores, pode ser benéfico simplificar o projeto de rede. A rede virtual de cada ambiente SAP seria, então, sub-redes dentro dessa rede virtual combinada. Qualquer simplificação das necessidades de design de rede e assinatura pode afetar a segurança. Você deve reavaliar o roteamento de rede, o acesso de e para redes públicas, o acesso a serviços compartilhados (compartilhamentos de arquivos) e o acesso a outros serviços do Azure. Aqui estão algumas opções para reduzir a arquitetura para melhor atender às necessidades organizacionais.
Combine as sub-redes do aplicativo SAP e do banco de dados em uma só. Você pode combinar as sub-redes do aplicativo e do banco de dados para criar uma grande rede SAP. Esse design de rede espelha muitas redes SAP locais. A combinação dessas duas sub-redes requer maior atenção à segurança da sub-rede e às regras do grupo de segurança de rede. Os grupos de segurança de aplicativos são importantes ao usar uma única sub-rede para sub-redes de aplicativos e bancos de dados SAP.
Combine a sub-rede de perímetro SAP e a sub-rede do aplicativo. Você pode combinar a sub-rede de perímetro e a sub-rede do aplicativo SAP. Deve ser dada uma atenção acrescida às regras do grupo de segurança da rede e à utilização do grupo de segurança da aplicação. Recomendamos apenas esta abordagem de simplificação para pequenas propriedades SAP.
Combine redes virtuais SAP spoke entre diferentes ambientes SAP A arquitetura usa diferentes redes virtuais para cada ambiente SAP (hub, produção, não produção e recuperação de desastres). Dependendo do tamanho do seu cenário SAP, você pode combinar as redes virtuais SAP spoke em menos ou até mesmo apenas um SAP falado. Você ainda precisa dividir entre ambientes de produção e não produção. Cada ambiente de produção SAP torna-se uma sub-rede em uma rede virtual de produção SAP. Cada ambiente de não produção SAP torna-se uma sub-rede em uma rede virtual de não produção SAP.
Contribuidores
A Microsoft mantém este artigo. Foi originalmente escrito pelos seguintes contribuidores.
Principais autores:
- Robert Biro - Brasil | Arquiteto Sénior
- Pankaj Meshram - Brasil | Gerente de Programa Principal
Próximos passos
- SAP S/4HANA no Linux no Azure
- Executar o SAP NetWeaver no Windows no Azure
- Executar o SAP HANA em uma arquitetura de expansão no Azure
- Cloud Adoption Framework - Cenário SAP
- Conexões de entrada e saída da Internet para SAP no Azure
- Documentação do SAP no Azure.
- Guia de planejamento e implementação do Azure para cargas de trabalho SAP
- Cargas de trabalho SAP no Azure: lista de verificação de planeamento e implementação