Este artigo fornece melhores práticas para arquitetar uma paisagem sap inteira no Azure. O panorama sap inclui vários sistemas SAP em ambientes hub, produção, não produção e recuperação após desastre. Fornecemos recomendações que se focam na conceção de rede e não em sistemas SAP específicos. O objetivo é fornecer as nossas recomendações para arquitetar uma paisagem SAP segura, de alto desempenho e resiliente.
Arquitetura
Transfira um ficheiro do Visio da arquitetura.
Fluxo de trabalho
- Rede no local: ligação do ExpressRoute da rede no local para regiões ligadas do Azure.
- Hubs regionais de subscrição do Azure: subscrição do Azure que contém serviços centrais para toda a empresa e não apenas SAP. A subscrição do hub fornece conectividade através do peering para redes virtuais spoke que contêm cargas de trabalho SAP.
- Rede virtual do hub: uma rede virtual falou para o hub central na região ou região primária A.
- Rede virtual de recuperação após desastre do hub (DR): uma rede virtual falou para o hub central na região de recuperação após desastre. Espelha o design da sub-rede da rede virtual de produção na região primária.
- Não produção sap da subscrição do Azure: uma subscrição do Azure para todas as cargas de trabalho SAP de não produção. Inclui ambientes de pré-produção, garantia de qualidade, desenvolvimento e sandbox.
- Redes virtuais spoke de não produção sap: redes virtuais separadas para cargas de trabalho de não produção SAP na região primária. Cada ambiente SAP tem a sua própria rede virtual e sub-redes.
- Produção SAP da subscrição do Azure: uma subscrição do Azure para todas as cargas de trabalho SAP de produção.
- Rede virtual spoke de produção sap: uma rede virtual para o ambiente de produção sap com várias sub-redes. Esta rede virtual está na região primária.
- A recuperação após desastre de produção sap (DR) falou de rede virtual: uma rede virtual para a produção sap na região secundária de recuperação após desastre. Espelha o design da sub-rede da rede virtual de produção na região primária.
- Serviços do Azure: uma amostragem dos serviços do Azure que pode ligar ao panorama do SAP.
- SAP Business Technology Platform (BTP): o ambiente SAP acede à Plataforma de Tecnologia de Negócio sap através de Azure Private Link.
Subscrições do Azure
Recomendamos a utilização de uma estrutura de rede hub-spoke. Com uma estrutura hub-spoke, precisa de, pelo menos, três subscrições para dividir os seus ambientes SAP. Deve ter uma subscrição para as (1) redes virtuais do 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, quer evitar a utilização de demasiadas subscrições. Demasiadas subscrições podem adicionar uma sobrecarga de gestão desnecessária e complexidade de rede. Por exemplo, não precisa de uma subscrição para cada sistema SAP. A nossa arquitetura utiliza três subscrições:
Hubs regionais: uma subscrição do hub virtual do Azure onde existe a rede virtual do hub para as regiões primária e secundária. Esta subscrição destina-se a todos os serviços centrais e não apenas ao SAP.
Não produção sap: uma subscrição de não produção sap do Azure onde residem sistemas de não produção, incluindo sandbox, desenvolvimento, garantia de qualidade ou sistemas de pré-produção.
Produção SAP: uma subscrição de produção sap do Azure onde configurámos os sistemas de produção e recuperação após desastre.
Para obter mais informações, consulte:
Estrutura da rede
Uma topologia hub-spoke é o design de rede recomendado para uma paisagem SAP. Nesta topologia, a rede virtual do hub de produção funciona como um ponto central de conectividade. Liga-se à rede no local e às várias redes virtuais spoke e permite aos utilizadores e aplicações aceder à carga de trabalho SAP. Nesta topologia hub-spoke, eis as nossas recomendações para a conceção da rede SAP.
Utilize o ExpressRoute para ligação no local. Para cargas de trabalho SAP, recomendamos que utilize o ExpressRoute para ligar a rede no local à rede virtual hub e à rede virtual dr do Hub. Pode utilizar a topologia da WAN virtual do Azure se tiver localizações globais. Considere configurar uma VPN site a site (S2S) como uma cópia de segurança 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-and-spoke
- Azure virtual WAN
- VPN S2S como cópia de segurança para peering privado do ExpressRoute
Utilize uma rede virtual por ambiente. Recomendamos a utilização de uma rede virtual por ambiente (escalão de implementação SAP). A arquitetura utiliza uma rede virtual diferente para produção, desenvolvimento, garantia de qualidade e sandbox. Este design de rede é ideal para arquiteturas empresariais de grandes dimensões.
Utilize uma firewall central. Todo o tráfego de rede para as redes virtuais spoke, incluindo ligações de chamada de função remota (RFC), deve passar por uma firewall central na rede virtual do Hub. A comunicação de rede entre as redes virtuais spoke (comunicação spoke-to-spoke) passa pela firewall da rede virtual do hub na sub-rede Azure Firewall da rede virtual do Hub. Da mesma forma, a comunicação de rede entre as redes virtuais spoke e a rede no local também passa pela firewall da rede virtual do hub. Utilizámos o peering de rede virtual para ligar as várias redes virtuais spoke à rede virtual do hub. Toda a comunicação entre as redes virtuais spoke passa pela firewall da rede virtual do Hub. Também pode utilizar uma aplicação virtual de rede em vez de uma firewall. Para obter mais informações, veja a aplicação virtual de rede.
O tráfego de rede que permanece numa rede virtual não deve passar por uma firewall. Por exemplo, não coloque uma firewall entre a sub-rede da aplicação SAP e a sub-rede da base de dados SAP. Não pode colocar uma firewall ou aplicações virtuais de rede (NVAs) entre a aplicação SAP e a camada do sistema de gestão de bases de dados (DBMS) dos sistemas SAP que executam o kernel do SAP.
Evite redes virtuais spoke de peering. O peering de rede virtual entre as redes virtuais spoke deve ser evitado, se possível. O peering de rede virtual spoke-to-spoke permite que a comunicação spoke-to-spoke ignore a firewall da rede virtual do Hub. Só deve configurar o peering de rede virtual spoke-to-spoke quando tiver requisitos de largura de banda elevada, por exemplo, com a replicação da base de dados entre ambientes SAP. Todo o tráfego de rede deve ser executado através da rede virtual e firewall do Hub. Para obter mais informações, veja Ligações à Internet de entrada e saída para o SAP no Azure.
Sub-redes
É uma melhor prática dividir cada ambiente SAP (produção, pré-produção, desenvolvimento, sandbox) em sub-redes e utilizar sub-redes para agrupar serviços relacionados. Eis as nossas recomendações para subcontar uma paisagem SAP.
Número de sub-redes
A rede virtual de produção na arquitetura tem cinco sub-redes. Este design é ideal para grandes soluções empresariais. O número de sub-redes pode ser menor ou mais. O número de recursos na rede virtual deve determinar o número de sub-redes na rede virtual.
Dimensionamento da sub-rede
Certifique-se de que as sub-redes têm espaço de endereços de rede suficiente. Se utilizar nomes de anfitriões virtuais SAP, precisa de mais espaço de endereços nas sub-redes SAP. Muitas vezes, cada instância SAP necessita de endereços IP 2 a 3 e inclui um endereço IP para o nome do anfitrião da máquina virtual. Outros serviços do Azure podem exigir a sua própria sub-rede dedicada quando implementados nas redes virtuais de carga de trabalho SAP.
Sub-rede da aplicação
A sub-rede da aplicação contém máquinas virtuais que executam servidores de aplicações SAP, Serviços Sap Central (ASCS), Sap Enqueue Replication Services (ERS) e instâncias do SAP Web Dispatcher. A sub-rede também contém um ponto final privado para Ficheiros do Azure. No diagrama, agrupámos as máquinas virtuais por função. Recomendamos a utilização de conjuntos de dimensionamento de máquinas virtuais com orquestração flexível, zonas de disponibilidade ou conjuntos de disponibilidade para implementação resiliente. Para obter mais informações, veja os passos seguintes.
Sub-rede da base de dados
A sub-rede da base de dados contém máquinas virtuais que executam bases de dados. No diagrama, um par de máquinas virtuais com replicação síncrona representam todas as máquinas virtuais de base de dados de um ambiente SAP.
Sub-redes de perímetro
As sub-redes de perímetro estão voltadas para a Internet e incluem uma sub-rede de perímetro SAP e uma sub-rede Gateway de Aplicação. Eis as nossas recomendações para conceber estas duas sub-redes.
Sub-rede de perímetro SAP: a sub-rede de perímetro sap é uma rede de perímetro que contém aplicações com acesso à Internet, como SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent e Gateway de Aplicação. Estes serviços têm dependências em sistemas SAP que uma equipa sap deve implementar, gerir e configurar. Uma equipa de TI central não deve gerir os serviços na sub-rede de perímetro sap. Por este motivo, deve colocar estes 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. 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 subscrição SAP de não produção utilizam os serviços na sub-rede de perímetro sap.
Pode criar uma sub-rede de perímetro SAP definida separadamente na subscrição de não produção. Recomendamos apenas esta abordagem para cargas de trabalho críticas ou cargas de trabalho que mudam frequentemente. Um perímetro SAP de não produção dedicado é útil para testes e implementação de novas funcionalidades. Aplicações ou aplicações menos críticas que terão apenas poucas modificações ao longo do tempo não precisam de uma sub-rede de perímetro SAP de não produção separada.
Gateway de Aplicação sub-rede: Gateway de Aplicação do Azure requer a sua própria sub-rede. Utilize-o para permitir o tráfego da Internet que os serviços SAP, como o SAP Fiori, podem utilizar. A arquitetura recomendada coloca Gateway de Aplicação do Azure juntamente com o respetivo endereço IP público de front-end na rede virtual do Hub. Uma Gateway de Aplicação do Azure requer, pelo menos, uma sub-rede de tamanho /29. Recomendamos o tamanho /27 ou superior. Não pode utilizar ambas as versões do Gateway de Aplicação (v1 e v2) na mesma sub-rede. Para obter mais informações, veja sub-rede para Gateway de Aplicação do Azure.
Colocar sub-redes de perímetro numa rede virtual separada para maior segurança: para maior segurança, pode colocar a sub-rede de perímetro SAP e Gateway de Aplicação sub-rede numa rede virtual separada na subscrição de produção SAP. A rede virtual spoke de perímetro sap está em modo de peering 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. Esta abordagem alternativa mostra Gateway de Aplicação do Azure com o respetivo endereço IP público para ligações de entrada colocadas numa rede virtual spoke para utilização exclusiva do SAP.
Transfira um ficheiro do Visio , incluindo esta arquitetura alternativa.
Esta estrutura de rede fornece melhores capacidades de resposta a incidentes e controlo de acesso de rede detalhado. No entanto, também aumenta a complexidade da gestão, a latência de rede e o custo da implementação. Vamos discutir cada ponto.
Melhor resposta a incidentes: a rede virtual spoke de perímetro sap permite o isolamento rápido de serviços comprometidos se detetar uma falha de segurança. Pode remover o peering de rede virtual da rede virtual spoke do perímetro sap para o hub e isolar imediatamente as cargas de trabalho de perímetro sap e as aplicações de rede virtual da aplicação SAP da Internet. Não quer confiar nas alterações das regras do grupo de segurança de rede (NSG) para resposta a incidentes. Alterar ou remover uma regra NSG só afeta novas ligações e não corta ligações maliciosas existentes.
Controlo de acesso de rede detalhado: a rede virtual de perímetro SAP fornece um controlo de acesso de rede mais rigoroso de e para a rede virtual spoke de produção sap.
Maior complexidade, latência e custo: a arquitetura aumenta a complexidade, o custo e a latência da gestão. A comunicação com ligação à Internet a partir da rede virtual de produção sap é em modo de peering duas vezes, uma para a rede virtual do Hub e novamente para a rede virtual de perímetro SAP para a Internet. A firewall na rede virtual do Hub tem o maior efeito na latência. Recomendamos medir a latência para ver se o seu caso de utilização o pode suportar.
Para obter mais informações, veja melhores práticas de rede de perímetro.
sub-rede Azure NetApp Files
Se estiver a utilizar o NetApp Files, deverá ter uma sub-rede delegada para fornecer partilhas de ficheiros do sistema de ficheiros de rede (NFS) ou do bloco de mensagens de servidor (SMB) para diferentes cenários SAP no Azure. Uma sub-rede /24 é o tamanho predefinido de uma sub-rede netApp Files, mas pode alterar o tamanho para satisfazer as suas necessidades. Utilize os seus próprios requisitos para determinar o dimensionamento adequado. Para obter mais informações, veja sub-rede delegada.
Segurança da sub-rede
A utilização de sub-redes para agrupar recursos SAP com os mesmos requisitos de regras de segurança facilita a gestão da segurança.
Grupos de segurança de rede (NSG): as sub-redes permitem-lhe implementar grupos de segurança de rede ao nível da sub-rede. Agrupar recursos na mesma sub-rede que requerem regras de segurança diferentes requer grupos de segurança de rede ao nível da sub-rede e ao nível 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 do NSG também afetam o tráfego na sub-rede. Para obter mais informações sobre os NSGs, veja Grupos de segurança de rede.
Grupos de segurança de aplicações (ASG): recomendamos a utilização de grupos de segurança de aplicações para agrupar interfaces de rede de máquinas virtuais e referenciar os grupos de segurança da aplicação nas regras de grupo de segurança de rede. Esta configuração permite uma criação e gestão de regras mais fácil para implementações SAP. Cada interface de rede pode pertencer a vários grupos de segurança de aplicações com diferentes regras de grupo de segurança de rede. Para obter mais informações, veja Grupos de segurança de aplicações.
Azure Private Link
Recomendamos que utilize Azure Private Link para melhorar a segurança das comunicações de rede. Azure Private Link utiliza pontos finais privados com endereços IP privados para comunicar com os serviços do Azure. As Ligações Privadas do Azure evitam o envio de comunicações de rede através da Internet para pontos finais públicos. Para obter mais informações, veja pontos finais privados nos serviços do Azure.
Utilizar pontos finais privados na sub-rede da aplicação: recomendamos que utilize pontos finais privados para ligar a sub-rede da aplicação aos serviços do Azure suportados. Na arquitetura, existe um ponto final privado para Ficheiros do Azure na sub-rede da Aplicação de cada rede virtual. Pode alargar este conceito a qualquer serviço do Azure suportado.
Utilize Azure Private Link para a SAP Business Technology Platform (BTP): Azure Private Link para a SAP Business Technology Platform (BTP) está agora disponível de forma geral. O Serviço sap Private Link suporta ligações do SAP BTP, do runtime do Cloud Foundry e de outros serviços. Os cenários de exemplo incluem SAP S/4HANA ou SAP ERP em execução na máquina virtual. Podem ligar-se a serviços nativos do Azure, como Azure Database for MariaDB e Base de Dados do Azure para MySQL.
A arquitetura ilustra uma ligação sap Private Link Service a partir de ambientes SAP BTP. O Serviço sap Private Link estabelece uma ligação privada entre serviços BTP SAP específicos e serviços específicos em cada rede como contas de fornecedor de serviços. A ligação privada permite que os serviços BTP acedam ao seu ambiente SAP através de ligações de rede privadas. Melhora a segurança ao não utilizar a Internet pública para comunicar.
Para obter mais informações, consulte:
- recursos de Azure Private Link
- Azure Database for MariaDB
- Base de Dados do Azure para MySQL
- Ligação à Internet para SAP no Azure
Partilhas de ficheiros do sistema de ficheiros de rede (NFS) e do bloco de mensagens de servidor (SMB)
Os sistemas SAP dependem frequentemente de volumes do sistema de ficheiros de rede ou partilhas de blocos de mensagens de servidor. Estas partilhas de ficheiros movem ficheiros entre máquinas virtuais ou funcionam como uma interface de ficheiro com outras aplicações. Recomendamos a utilização de serviços nativos do Azure, como Ficheiros Premium do Azure e Azure NetApp Files, como partilhas de ficheiros do sistema de ficheiros de rede (NFS) e do bloco de mensagens de servidor (SMB). Os serviços do Azure têm melhores contratos de disponibilidade, resiliência e nível de serviço (SLAs) combinados do que as ferramentas baseadas no sistema operativo.
Para obter mais informações, consulte:
- Ficheiros Premium do Azure
- Azure NetApp Files
- Nota SAP 2015553 (requisitos para serviços de armazenamento)
Ao arquitetar a sua solução SAP, tem de dimensionar corretamente os volumes de partilha de ficheiros individuais e saber a que partilha de ficheiros do sistema SAP se liga. Tenha em atenção os objetivos de escalabilidade e desempenho do serviço do Azure durante o planeamento. A tabela seguinte descreve partilhas de ficheiros SAP comuns e fornece uma breve descrição e utilização recomendada em todo um ambiente SAP.
| Nome da partilha de ficheiros | Utilização | Recomendação |
|---|---|---|
sapmnt |
Sistema SAP distribuído, perfil e diretórios globais | Partilha dedicada para cada sistema SAP, sem reutilização |
cluster |
Partilhas de elevada disponibilidade para ASCS, ERS e base de dados de acordo com a estrutura | Partilha dedicada para cada sistema SAP, sem reutilização |
saptrans |
Diretório de transporte sap | Uma partilha para uma ou poucas paisagens SAP (ERP, Business Warehouse) |
interface |
Troca de ficheiros com aplicações não SAP | Requisitos específicos do cliente, partilhas de ficheiros separadas por ambiente (produção, não produção) |
Só pode partilhar saptrans entre diferentes ambientes SAP e, como tal, deve considerar cuidadosamente a respetiva colocação. Evite consolidar demasiados sistemas SAP numa só saptrans partilha por motivos de escalabilidade e desempenho.
As políticas de segurança empresarial irão impulsionar a arquitetura e a separação de volumes entre ambientes. Um diretório de transporte com separação por ambiente ou escalão necessita de comunicação RFC entre ambientes SAP para permitir grupos de transporte SAP ou ligações 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 o ajudam a expandir e melhorar a sua plataforma de dados SAP. Para ajudar a desbloquear informações empresariais, recomendamos que utilize serviços como o Azure Synapse Analytics, Azure Data Factory e Azure Data Lake Storage. Estes serviços de dados ajudam-no a analisar e visualizar dados SAP e dados não SAP.
Para muitos cenários de integração de dados, é necessário um runtime de integração. O runtime de integração do Azure é a infraestrutura de computação que Azure Data Factory e Azure Synapse os pipelines do Analytics utilizam para fornecer capacidades de integração de dados. Recomendamos a implementação de máquinas virtuais de runtime para estes serviços para cada ambiente separadamente. Para obter mais informações, consulte:
- Runtime de integração do Azure
- Configurar um runtime de integração autoalojado para utilizar na solução SAP CDC
- Copiar dados do SAP HANA
- Copiar dados do SAP Business Warehouse através do Open Hub
Serviços partilhados
As soluções SAP dependem de serviços partilhados. O balanceador de carga e os gateways de aplicação são exemplos de serviços que vários sistemas SAP utilizam. A arquitetura, mas as suas necessidades organizacionais, devem determinar como arquiteta os seus serviços partilhados. Eis as orientações gerais que deve seguir.
Balanceadores de carga: recomendamos um balanceador de carga por sistema SAP. Esta configuração ajuda a minimizar a complexidade. Quer evitar demasiados conjuntos e regras num único balanceador de carga. Esta configuração também garante que a nomenclatura e a colocação estão alinhadas com o sistema SAP e o grupo de recursos. Cada sistema SAP com uma arquitetura de elevada disponibilidade (HA) em cluster deve ter, pelo menos, um balanceador de carga. A arquitetura utiliza um balanceador de carga para as máquinas virtuais do ASCS e um segundo balanceador de carga para as máquinas virtuais da base de dados. Algumas bases de dados podem não necessitar de balanceadores de carga para criar uma implementação de elevada disponibilidade. O SAP HANA sim. Consulte a documentação específica da base de dados para obter mais detalhes.
Gateway de Aplicação: recomendamos pelo menos um gateway de aplicação por ambiente SAP (produção, não produção e sandbox), a menos que a complexidade e o número de sistemas ligados sejam demasiado elevados. Pode utilizar um gateway de aplicação para vários sistemas SAP para reduzir a complexidade, uma vez que nem todos os sistemas SAP no ambiente necessitam de acesso público. Um único gateway de aplicação pode servir várias portas de despachante Web para um único sistema SAP S/4HANA ou ser utilizado por diferentes sistemas SAP.
Máquinas virtuais sap Web Dispatcher: a arquitetura mostra um conjunto de duas ou mais VMs sap Web Dispatcher. Recomendamos que não reutilize máquinas virtuais sap Web Dispatcher entre diferentes sistemas SAP. Mantê-las separadas permite-lhe dimensionar as máquinas virtuais do Web Dispatcher para satisfazer as necessidades de cada sistema SAP. Para soluções SAP mais pequenas, recomendamos a incorporação dos serviços do Web Dispatcher na instância do ASCS.
Serviços SAP: os serviços SAP, como o SAProuter, o Cloud Connector e o Analytics Cloud Agent, são implementados com base nos requisitos da aplicação, quer centralmente quer divididos. Nenhuma recomendação sobre a reutilização entre sistemas SAP devido a diversos requisitos do cliente. A decisão principal a tomar é mencionada na secção de rede, se e quando deve ser utilizada a sub-rede de perímetro SAP para não produção. 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 toda a paisagem sap.
Recuperação após desastre
A recuperação após desastre (DR) aborda o requisito de continuidade de negócio no caso de a região primária do Azure estar indisponível ou comprometida. A partir de uma perspetiva horizontal geral do SAP e mostradas no diagrama, eis as nossas recomendações para a conceção da recuperação após desastre.
Utilizar intervalos de endereços IP diferentes As redes virtuais abrangem apenas uma única região do Azure. Quaisquer soluções de recuperação após desastre devem utilizar uma região diferente. Tem de criar uma rede virtual diferente na região secundária. A rede virtual no ambiente de DR precisa de um intervalo de endereços IP diferente para ativar a sincronização de bases de dados através da tecnologia nativa da base de dados.
Serviços centrais e conectividade ao local: a conectividade aos serviços centrais no local e principais (DNS ou firewalls) tem de estar disponível na região de recuperação após desastre. A disponibilidade e a alteração da configuração dos serviços de TI centrais têm de fazer parte do seu plano de recuperação após desastre. Os serviços de TI centrais são componentes fundamentais para um ambiente SAP funcional.
Utilizar o Azure Site Recovery Azure Site Recovery replica e protege os discos geridos e as configurações de máquinas virtuais dos servidores de aplicações para a região de DR.
Garantir a disponibilidade da partilha de ficheiros: o SAP depende da disponibilidade das principais partilhas de ficheiros. A cópia de segurança ou a replicação contínua da partilha de ficheiros é necessária para fornecer dados nestas partilhas de ficheiros com perda mínima de dados no cenário de DR.
Replicação da base de dados O Azure Site Recovery não consegue proteger os servidores de bases de dados SAP devido à elevada taxa de alterações e à falta de suporte da base de dados pelo serviço. Tem de configurar a replicação de base de dados contínua e assíncrona para a região de recuperação após desastre.
Para obter mais informações, veja Descrição geral da recuperação após desastre e diretrizes de infraestrutura para a carga de trabalho SAP.
Arquitetura SAP mais pequena
Para soluções SAP mais pequenas, pode ser vantajoso simplificar o design 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 estrutura da rede e da subscrição pode afetar a segurança. Deve reavaliar o encaminhamento de rede, aceder a e a partir de redes públicas, aceder a serviços partilhados (partilhas de ficheiros) e aceder a outros serviços do Azure. Seguem-se algumas opções para reduzir a arquitetura de forma a satisfazer melhor as necessidades organizacionais.
Combine a aplicação SAP e as sub-redes de base de dados numa só. Pode combinar as sub-redes da aplicação e da base de dados para criar uma rede SAP grande. Esta estrutura de rede espelha muitas redes SAP no local. A combinação destas duas sub-redes requer uma maior atenção às regras de segurança da sub-rede e do grupo de segurança de rede. Os grupos de segurança de aplicações são importantes ao utilizar uma única sub-rede para sub-redes de bases de dados e aplicações SAP.
Combinar sub-rede de perímetro SAP e sub-rede da aplicação. Pode combinar a sub-rede de perímetro e a sub-rede da aplicação SAP. Tem de ser colocada uma atenção acrescida nas regras de grupo de segurança de rede e na utilização do grupo de segurança de aplicações. Recomendamos apenas esta abordagem de simplificação para pequenas propriedades SAP.
Combinar redes virtuais sap spoke entre diferentes ambientes SAP A arquitetura utiliza diferentes redes virtuais para cada ambiente SAP (hub, produção, não produção e recuperação após desastre). Consoante o tamanho do seu panorama SAP, pode combinar as redes virtuais sap spoke em menos ou até mesmo um sap spoke. Ainda precisa de dividir entre ambientes de produção e de não produção. Cada ambiente de produção sap torna-se uma sub-rede numa rede virtual de produção SAP. Cada ambiente de não produção SAP torna-se uma sub-rede numa rede virtual de não produção SAP.
Contribuidores
A Microsoft mantém este artigo. Foi originalmente escrito pelos seguintes contribuintes.
Autores principais:
- Robert Biro | Arquiteto Sénior
- Pankaj Meshram | Gestor de Programas Principal
Passos seguintes
- SAP S/4HANA em Linux no Azure
- Executar o SAP NetWeaver no Windows no Azure
- Executar o SAP HANA numa arquitetura de aumento vertical no Azure
- Cloud Adoption Framework – cenário SAP
- Ligações à Internet de Entrada e Saída para SAP no Azure
- Documentação do SAP no Azure.
- Guia de planeamento 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