Architettura orizzontale di SAP

Macchine virtuali di Azure
Rete virtuale di Azure
File di Azure
Azure Load Balancer

Questo articolo illustra le procedure consigliate per progettare un intero panorama SAP in Azure. Il panorama SAP include più sistemi SAP in ambienti hub, produzione, non di produzione e ripristino di emergenza. Vengono fornite raccomandazioni incentrate sulla progettazione di rete e non su sistemi SAP specifici. L'obiettivo è fornire le raccomandazioni per progettare un panorama SAP sicuro, ad alte prestazioni e resiliente.

Architettura

Diagramma che mostra un panorama generale di SAP in Azure.

Scaricare un file di Visio dell'architettura.

Workflow

  1. Rete locale: connessione ExpressRoute dalla rete locale alle aree di Azure connesse.
  2. Hub regionali della sottoscrizione di Azure: sottoscrizione di Azure contenente servizi centrali per l'intera azienda, non solo SAP. La sottoscrizione hub fornisce la connettività tramite peering a reti virtuali spoke contenenti carichi di lavoro SAP.
  3. Rete virtuale hub: uno spoke di rete virtuale per l'hub centrale nell'area primaria o nell'area A.
  4. Rete virtuale di ripristino di emergenza dell'hub: uno spoke di rete virtuale per l'hub centrale nell'area di ripristino di emergenza. Rispecchia la progettazione della subnet della rete virtuale di produzione nell'area primaria.
  5. Sottoscrizione di Azure SAP non di produzione: una sottoscrizione di Azure per tutti i carichi di lavoro SAP non di produzione. Include ambienti pre-produzione, controllo qualità, sviluppo e sandbox.
  6. Reti virtuali sap non di produzione: reti virtuali separate per carichi di lavoro sap non di produzione nell'area primaria. Ogni ambiente SAP ha una propria rete virtuale e subnet.
  7. Produzione SAP della sottoscrizione di Azure: una sottoscrizione di Azure per tutti i carichi di lavoro SAP di produzione.
  8. Rete virtuale spoke di produzione SAP: una rete virtuale per l'ambiente di produzione SAP con più subnet. Questa rete virtuale si trova nell'area primaria.
  9. Rete virtuale spoke per il ripristino di emergenza di produzione SAP: una rete virtuale per la produzione SAP nell'area secondaria di ripristino di emergenza. Rispecchia la progettazione della subnet della rete virtuale di produzione nell'area primaria.
  10. Servizi di Azure: campionamento dei servizi di Azure che è possibile connettere al panorama sap.
  11. SAP Business Technology Platform (BTP): l'ambiente SAP accede a SAP Business Technology Platform tramite collegamento privato di Azure.

Sottoscrizioni di Azure

È consigliabile usare una progettazione di rete hub-spoke. Con una progettazione hub-spoke, sono necessarie almeno tre sottoscrizioni per dividere gli ambienti SAP. È necessario avere una sottoscrizione per le reti virtuali dell'hub regionale (1), (2) reti virtuali non di produzione e (3) reti virtuali di produzione. Le sottoscrizioni forniscono limiti di fatturazione, criteri e sicurezza. Non esiste un numero corretto di sottoscrizioni. Il numero di sottoscrizioni usate dipende dalle esigenze di fatturazione, criteri e sicurezza. In generale, si vuole evitare di usare troppe sottoscrizioni. Troppe sottoscrizioni possono aggiungere sovraccarico di gestione non necessario e complessità di rete. Ad esempio, non è necessaria una sottoscrizione per ogni sistema SAP. L'architettura usa tre sottoscrizioni:

  • Hub regionali: una sottoscrizione dell'hub virtuale di Azure in cui è presente la rete virtuale hub per le aree primarie e secondarie. Questa sottoscrizione è destinata a tutti i servizi centrali e non solo a SAP.

  • SAP non di produzione: una sottoscrizione non di produzione di Azure SAP in cui risiedono sistemi non di produzione, tra cui sandbox, sviluppo, controllo di qualità o sistemi di pre-produzione.

  • Produzione SAP: una sottoscrizione di produzione SAP di Azure in cui sono stati configurati i sistemi di produzione e ripristino di emergenza.

Per altre informazioni, vedi:

Progettazione della rete

Una topologia hub-spoke è la progettazione di rete consigliata per un panorama SAP. In questa topologia, la rete virtuale dell'hub di produzione funge da punto centrale di connettività. Si connette alla rete locale e alle varie reti virtuali spoke e consente agli utenti e alle applicazioni di accedere al carico di lavoro SAP. All'interno di questa topologia hub-spoke, ecco le raccomandazioni per la progettazione della rete SAP.

Usare ExpressRoute per la connessione locale. Per i carichi di lavoro SAP, è consigliabile usare ExpressRoute per connettere la rete locale alla rete virtuale hub e alla rete virtuale di ripristino di emergenza dell'hub. È possibile usare la topologia della rete WAN virtuale di Azure se si dispone di posizioni globali. Valutare la possibilità di configurare una VPN da sito a sito (S2S) come backup in Azure ExpressRoute o in qualsiasi requisito di route di terze parti.

Per altre informazioni, vedi:

Usare una rete virtuale per ogni ambiente. È consigliabile usare una rete virtuale per ogni ambiente (livello di distribuzione SAP). L'architettura usa una rete virtuale diversa per la produzione, lo sviluppo, la garanzia di qualità e la sandbox. Questa progettazione di rete è ideale per architetture aziendali di grandi dimensioni.

Usare un firewall centrale. Tutto il traffico di rete verso le reti virtuali spoke, incluse le connessioni RFC (Remote Function Call), deve passare attraverso un firewall centrale nella rete virtuale hub. La comunicazione di rete tra le reti virtuali spoke (comunicazione spoke-spoke) passa attraverso il firewall della rete virtuale hub nella subnet Firewall di Azure della rete virtuale hub. Analogamente, anche le comunicazioni di rete tra le reti virtuali spoke e la rete locale passano attraverso il firewall della rete virtuale hub. È stato usato il peering di rete virtuale per connettere le varie reti virtuali spoke alla rete virtuale hub. Tutte le comunicazioni tra le reti virtuali spoke passano attraverso il firewall della rete virtuale hub. È anche possibile usare un'appliance virtuale di rete anziché un firewall. Per altre informazioni, vedere Appliance virtuale di rete.

Il traffico di rete che rimane in una rete virtuale non deve passare attraverso un firewall. Ad esempio, non inserire un firewall tra la subnet dell'applicazione SAP e la subnet del database SAP. Non è possibile posizionare un firewall o appliance virtuali di rete tra l'applicazione SAP e il livello DBMS (Database Management System) dei sistemi SAP che eseguono il kernel SAP.

Evitare di eseguire il peering di reti virtuali spoke. Se possibile, è consigliabile evitare il peering di rete virtuale tra le reti virtuali spoke. Il peering di rete virtuale spoke-spoke consente la comunicazione spoke-to-spoke per ignorare il firewall della rete virtuale hub. È consigliabile configurare il peering di rete virtuale spoke-to-spoke solo quando si dispone di requisiti di larghezza di banda elevata, ad esempio con la replica di database tra ambienti SAP. Tutti gli altri traffico di rete devono essere eseguiti attraverso la rete virtuale hub e il firewall. Per altre informazioni, vedere Connessioni Internet in ingresso e in uscita per SAP in Azure.

Subnet

È consigliabile dividere ogni ambiente SAP (produzione, pre-produzione, sviluppo, sandbox) in subnet e usare subnet per raggruppare i servizi correlati. Ecco le raccomandazioni per la subnet di un panorama SAP.

Numero di subnet

La rete virtuale di produzione nell'architettura ha cinque subnet. Questa progettazione è ideale per soluzioni aziendali di grandi dimensioni. Il numero di subnet può essere minore o maggiore. Il numero di risorse nella rete virtuale deve determinare il numero di subnet nella rete virtuale.

Ridimensionamento della subnet

Verificare che le subnet dispongano di spazio di indirizzi di rete sufficiente. Se si usano nomi host virtuali SAP, è necessario più spazio indirizzi nelle subnet SAP. Spesso ogni istanza SAP richiede 2-3 indirizzi IP e include un indirizzo IP per il nome host della macchina virtuale. Altri servizi di Azure potrebbero richiedere la propria subnet dedicata quando vengono distribuiti nelle reti virtuali del carico di lavoro SAP.

Subnet applicazione

La subnet dell'applicazione contiene macchine virtuali che eseguono server applicazioni SAP, SAP Central Services (ASCS), SAP Enqueue Replication Services (ERS) e istanze di SAP Web Dispatcher. La subnet contiene anche un endpoint privato da File di Azure. Nel diagramma sono stati raggruppati le macchine virtuali per ruolo. È consigliabile usare set di scalabilità di macchine virtuali con orchestrazione flessibile, zone di disponibilità o set di disponibilità per la distribuzione resiliente. Per altre informazioni, vedere passaggi successivi.

Subnet database

La subnet del database contiene macchine virtuali che eseguono database. Nel diagramma una coppia di macchine virtuali con replica sincrona rappresenta tutte le macchine virtuali di database di un ambiente SAP.

Subnet perimetrali

Le subnet perimetrali sono con connessione Internet e includono una subnet perimetrale SAP e una subnet gateway applicazione. Ecco le raccomandazioni per la progettazione di queste due subnet.

Subnet perimetrale SAP: la subnet perimetrale SAP è una rete perimetrale che contiene applicazioni con connessione Internet, ad esempio SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent e gateway applicazione. Questi servizi hanno dipendenze dai sistemi SAP che un team SAP deve distribuire, gestire e configurare. Un team IT centrale non deve gestire i servizi nella subnet perimetrale SAP. Per questo motivo, è consigliabile inserire questi servizi nella rete virtuale SPOKE SAP e non nella rete virtuale hub. Il diagramma dell'architettura mostra solo una rete perimetrale SAP di produzione. Non ha una subnet perimetrale SAP nelle reti virtuali non di produzione. I carichi di lavoro nella sottoscrizione SAP non di produzione usano i servizi nella subnet perimetrale SAP.

È possibile creare una subnet perimetrale SAP set separata nella sottoscrizione non di produzione. È consigliabile usare questo approccio solo per carichi di lavoro o carichi di lavoro critici che cambiano frequentemente. Un perimetro SAP non di produzione dedicato è utile per il test e la distribuzione di nuove funzionalità. Le applicazioni o le applicazioni meno critiche che avranno solo poche modifiche nel tempo non richiedono una subnet perimetrale SAP non di produzione separata.

gateway applicazione subnet: il gateway di app Azure lication richiede la propria subnet. Usarlo per consentire il traffico proveniente da Internet che i servizi SAP, ad esempio SAP Fiori, possono usare. L'architettura consigliata inserisce app Azure lication Gateway insieme al relativo indirizzo IP pubblico front-end nella rete virtuale hub. Un gateway di app Azure lication richiede almeno una subnet di dimensioni /29. È consigliabile usare dimensioni /27 o superiori. Non è possibile usare entrambe le versioni di gateway applicazione (v1 e v2) nella stessa subnet. Per altre informazioni, vedere subnet per il gateway di app Azure lication.

Posizionare le subnet perimetrali in una rete virtuale separata per una maggiore sicurezza: per una maggiore sicurezza, è possibile inserire la subnet perimetrale SAP e gateway applicazione subnet in una rete virtuale separata all'interno della sottoscrizione di produzione SAP. La rete virtuale SAP perimeter spoke è con peering con la rete virtuale hub e tutto il traffico di rete verso le reti pubbliche passa attraverso la rete virtuale perimetrale. Questo approccio alternativo illustra app Azure lication Gateway con il relativo indirizzo IP pubblico per le connessioni in ingresso inserite in una rete virtuale spoke per l'uso esclusivo di SAP.

Diagramma che mostra il flusso di rete tra gli spoke di rete virtuale attraverso la rete virtuale hub.

Scaricare un file di Visio, inclusa questa architettura alternativa.

Questa progettazione di rete offre migliori funzionalità di risposta agli eventi imprevisti e controllo di accesso alla rete con granularità fine. Tuttavia, aumenta anche la complessità di gestione, la latenza di rete e il costo della distribuzione. Esaminiamo ogni punto.

Migliore risposta agli eventi imprevisti: la rete virtuale spoke perimetrale SAP consente un rapido isolamento dei servizi compromessi se si rileva una violazione. È possibile rimuovere il peering di rete virtuale dalla rete virtuale SAP perimeter spoke all'hub e isolare immediatamente i carichi di lavoro perimetrali SAP e le applicazioni di rete virtuale dell'applicazione SAP da Internet. Non si vuole fare affidamento sulle modifiche alle regole del gruppo di sicurezza di rete (NSG) per la risposta agli eventi imprevisti. La modifica o la rimozione di una regola del gruppo di sicurezza di rete influisce solo sulle nuove connessioni e non taglia le connessioni dannose esistenti.

Controllo di accesso alla rete con granularità fine: la rete virtuale perimetrale SAP offre un controllo di accesso alla rete più rigoroso da e verso la rete virtuale spoke di produzione SAP.

Maggiore complessità, latenza e costo: l'architettura aumenta la complessità di gestione, i costi e la latenza. La comunicazione associata a Internet dalla rete virtuale di produzione SAP viene con peering due volte, una volta alla rete virtuale hub e di nuovo alla rete virtuale perimetrale SAP verso Internet. Il firewall nella rete virtuale hub ha il massimo effetto sulla latenza. È consigliabile misurare la latenza per verificare se il caso d'uso può supportarlo.

Per altre informazioni, vedere Procedure consigliate per la rete perimetrale.

Subnet Azure NetApp Files

Se si usa NetApp Files, è necessario avere una subnet delegata per fornire condivisioni file system di rete (NFS) o SMB (Server Message Block) per diversi scenari SAP in Azure. Una subnet /24 è la dimensione predefinita per una subnet di NetApp Files, ma è possibile modificare le dimensioni in base alle esigenze. Usare i propri requisiti per determinare il dimensionamento corretto. Per altre informazioni, vedere Subnet delegata.

Sicurezza delle subnet

L'uso di subnet per raggruppare le risorse SAP con gli stessi requisiti delle regole di sicurezza semplifica la gestione della sicurezza.

Gruppi di sicurezza di rete :le subnet consentono di implementare gruppi di sicurezza di rete a livello di subnet. Il raggruppamento di risorse nella stessa subnet che richiede regole di sicurezza diverse richiede gruppi di sicurezza di rete a livello di subnet e a livello di interfaccia di rete. Con questa configurazione a due livelli, le regole di sicurezza sono facilmente in conflitto e possono causare problemi di comunicazione imprevisti difficili da risolvere. Le regole del gruppo di sicurezza di rete influiscono anche sul traffico all'interno della subnet. Per altre informazioni sui gruppi di sicurezza di rete, vedere Gruppi di sicurezza di rete.

Gruppi di sicurezza delle applicazioni: è consigliabile usare i gruppi di sicurezza delle applicazioni per raggruppare le interfacce di rete delle macchine virtuali e fare riferimento ai gruppi di sicurezza delle applicazioni nelle regole del gruppo di sicurezza di rete. Questa configurazione consente di semplificare la creazione e la gestione delle regole per le distribuzioni SAP. Ogni interfaccia di rete può appartenere a più gruppi di sicurezza delle applicazioni con regole di gruppo di sicurezza di rete diverse. Per altre informazioni, vedere Gruppi di sicurezza delle applicazioni.

È consigliabile usare collegamento privato di Azure per migliorare la sicurezza delle comunicazioni di rete. collegamento privato di Azure usa endpoint privati con indirizzi IP privati per comunicare con i servizi di Azure. collegamento privato di Azure evita di inviare comunicazioni di rete tramite Internet agli endpoint pubblici. Per altre informazioni, vedere Endpoint privati nei servizi di Azure.

Usare endpoint privati nella subnet dell'applicazione: è consigliabile usare endpoint privati per connettere la subnet dell'applicazione ai servizi di Azure supportati. Nell'architettura è presente un endpoint privato per File di Azure nella subnet Dell'applicazione di ogni rete virtuale. È possibile estendere questo concetto a qualsiasi servizio di Azure supportato.

Usare collegamento privato di Azure per SAP Business Technology Platform (BTP): collegamento privato di Azure for SAP Business Technology Platform (BTP) è ora disponibile a livello generale. SAP collegamento privato Service supporta le connessioni da SAP BTP, dal runtime di Cloud Foundry e da altri servizi. Gli scenari di esempio includono SAP S/4HANA o SAP ERP in esecuzione nella macchina virtuale. Possono connettersi a servizi nativi di Azure, ad esempio Database di Azure per MariaDB e Database di Azure per MySQL.

L'architettura illustra una connessione al servizio SAP collegamento privato da ambienti SAP BTP. SAP collegamento privato Service stabilisce una connessione privata tra specifici servizi SAP BTP e servizi specifici in ogni rete come account del provider di servizi. Il collegamento privato consente ai servizi BTP di accedere all'ambiente SAP tramite connessioni di rete private. Migliora la sicurezza non usando la rete Internet pubblica per comunicare.

Per altre informazioni, vedi:

Condivisioni file system di rete (NFS) e SMB (Server Message Block)

I sistemi SAP spesso dipendono dai volumi del file system di rete o dalle condivisioni di blocchi di messaggi del server. Queste condivisioni file spostano i file tra macchine virtuali o funzionano come interfaccia file con altre applicazioni. È consigliabile usare servizi nativi di Azure, ad esempio File Premium di Azure e Azure NetApp Files, come file system di rete (NFS) e condivisioni file SMB (Server Message Block). I servizi di Azure hanno una migliore disponibilità combinata, resilienza e contratti di servizio rispetto agli strumenti basati sul sistema operativo.

Per altre informazioni, vedi:

Quando si progetta la soluzione SAP, è necessario ridimensionare correttamente i singoli volumi di condivisione file e conoscere la condivisione file di sistema SAP a cui si connette. Tenere presenti obiettivi di scalabilità e prestazioni del servizio di Azure durante la pianificazione. La tabella seguente descrive le condivisioni file SAP comuni e fornisce una breve descrizione e l'uso consigliato in un intero ambiente SAP.

Nome condivisione file Utilizzo Elemento consigliato
sapmnt Sistema SAP distribuito, profilo e directory globali Condivisione dedicata per ogni sistema SAP, senza riutilizzo
cluster Condivisioni a disponibilità elevata per ASCS, ERS e database per ogni rispettiva progettazione Condivisione dedicata per ogni sistema SAP, senza riutilizzo
saptrans Directory di trasporto SAP Una condivisione per uno o pochi scenari SAP (ERP, Business Warehouse)
interface Scambio di file con applicazioni non SAP Requisiti specifici del cliente, condivisioni file separate per ambiente (produzione, non produzione)

È possibile condividere saptrans solo tra ambienti SAP diversi e, di conseguenza, è consigliabile valutarne attentamente la posizione. Evitare di consolidare troppi sistemi SAP in un'unica saptrans condivisione per motivi di scalabilità e prestazioni.

I criteri di sicurezza aziendali guidano l'architettura e la separazione dei volumi tra ambienti. Una directory di trasporto con separazione per ambiente o livello richiede la comunicazione RFC tra ambienti SAP per consentire i gruppi di trasporto SAP o i collegamenti di dominio di trasporto. Per altre informazioni, vedi:

Servizi dati

L'architettura contiene servizi dati di Azure che consentono di estendere e migliorare la piattaforma dati SAP. Per ottenere informazioni dettagliate aziendali, è consigliabile usare servizi come Azure Synapse Analytics, Azure Data Factory e Azure Data Lake Storage. Questi servizi dati consentono di analizzare e visualizzare dati SAP e dati non SAP.

Per molti scenari di integrazione dei dati, è necessario un runtime di integrazione. Il runtime di integrazione di Azure è l'infrastruttura di calcolo usata dalle pipeline di Azure Data Factory e Azure Synapse Analytics per fornire funzionalità di integrazione dei dati. È consigliabile la distribuzione di macchine virtuali di runtime per questi servizi per ogni ambiente separatamente. Per altre informazioni, vedi:

Servizi condivisi

Le soluzioni SAP si basano su servizi condivisi. Il servizio di bilanciamento del carico e i gateway applicazione sono esempi di servizi usati da più sistemi SAP. L'architettura, ma le esigenze dell'organizzazione devono determinare il modo in cui si progettano i servizi condivisi. Ecco le indicazioni generali da seguire.

Servizi di bilanciamento del carico: è consigliabile un servizio di bilanciamento del carico per ogni sistema SAP. Questa configurazione consente di ridurre al minimo la complessità. Si vogliono evitare troppi pool e regole in un singolo servizio di bilanciamento del carico. Questa configurazione garantisce anche che la denominazione e il posizionamento siano allineati al sistema SAP e al gruppo di risorse. Ogni sistema SAP con un'architettura a disponibilità elevata in cluster deve avere almeno un servizio di bilanciamento del carico. L'architettura usa un servizio di bilanciamento del carico per le macchine virtuali ASCS e un secondo servizio di bilanciamento del carico per le macchine virtuali di database. Alcuni database potrebbero non richiedere servizi di bilanciamento del carico per creare una distribuzione a disponibilità elevata. SAP HANA fa. Per altri dettagli, vedere la documentazione specifica del database.

gateway applicazione: è consigliabile almeno un gateway applicazione per ogni ambiente SAP (produzione, non di produzione e sandbox), a meno che la complessità e il numero di sistemi connessi non siano troppo elevati. È possibile usare un gateway applicazione per più sistemi SAP per ridurre la complessità perché non tutti i sistemi SAP nell'ambiente richiedono l'accesso pubblico. Un singolo gateway applicazione può gestire più porte dispatcher Web per un singolo sistema SAP S/4HANA o essere usato da sistemi SAP diversi.

Macchine virtuali SAP Web Dispatcher: l'architettura mostra un pool di due o più macchine virtuali Sap Web Dispatcher. È consigliabile non riutilizzare le macchine virtuali SAP Web Dispatcher tra sistemi SAP diversi. Mantenerli separati consente di ridimensionare le macchine virtuali Web Dispatcher per soddisfare le esigenze di ogni sistema SAP. Per soluzioni SAP più piccole, è consigliabile incorporare i servizi Web Dispatcher nell'istanza di ASCS.

Servizi SAP: i servizi SAP come SAProuter, Cloud Connector e Analytics Cloud Agent vengono distribuiti in base ai requisiti dell'applicazione, in modo centralizzato o suddiviso. Non è consigliabile riutilizzare i sistemi SAP a causa di requisiti diversi per i clienti. La decisione principale da prendere è menzionata nella sezione rete, se e quando deve essere usata la subnet perimetrale SAP per la non produzione. In caso contrario, con una sola subnet perimetrale di produzione per SAP, i servizi perimetrali SAP vengono usati da un intero panorama SAP.

Ripristino di emergenza

Il ripristino di emergenza risolve i requisiti per la continuità aziendale nel caso in cui l'area primaria di Azure non sia disponibile o compromessa. Dal punto di vista generale del panorama SAP e illustrato nel diagramma, ecco le raccomandazioni per la progettazione del ripristino di emergenza.

Usare intervalli di indirizzi IP diversi Le reti virtuali si estendono solo in una singola area di Azure. Tutte le soluzioni di ripristino di emergenza devono usare un'area diversa. È necessario creare una rete virtuale diversa nell'area secondaria. La rete virtuale nell'ambiente di ripristino di emergenza richiede un intervallo di indirizzi IP diverso per abilitare la sincronizzazione del database tramite la tecnologia nativa del database.

Servizi centrali e connettività all'ambiente locale: la connettività ai servizi centrali locali e chiave (DNS o firewall) deve essere disponibile nell'area di ripristino di emergenza. La disponibilità e la modifica della configurazione dei servizi IT centrali devono far parte del piano di ripristino di emergenza. I servizi IT centrali sono componenti chiave per un ambiente SAP funzionante.

Usare Azure Site Recovery azure Site Recovery esegue la replica e protegge i dischi gestiti e le configurazioni di macchine virtuali per i server applicazioni nell'area di ripristino di emergenza.

Verificare la disponibilità della condivisione file: SAP dipende dalla disponibilità delle condivisioni file chiave. La replica di backup o condivisione file continua è necessaria per fornire dati su queste condivisioni file con una perdita minima di dati nello scenario di ripristino di emergenza.

La replica di database di Azure Site Recovery non è in grado di proteggere i server di database SAP a causa della frequenza di modifica elevata e della mancanza di supporto del database da parte del servizio. È necessario configurare la replica continua e asincrona del database nell'area di ripristino di emergenza.

Per altre informazioni, vedere Panoramica del ripristino di emergenza e linee guida sull'infrastruttura per il carico di lavoro SAP.

Architettura SAP più piccola

Per soluzioni SAP più piccole, potrebbe essere utile semplificare la progettazione della rete. Ogni rete virtuale dell'ambiente SAP sarà quindi subnet all'interno di tale rete virtuale combinata. Qualsiasi semplificazione delle esigenze di progettazione della rete e della sottoscrizione può influire sulla sicurezza. È necessario rivalutare il routing di rete, l'accesso da e verso reti pubbliche, l'accesso ai servizi condivisi (condivisioni file) e accedere ad altri servizi di Azure. Ecco alcune opzioni per ridurre l'architettura per soddisfare meglio le esigenze dell'organizzazione.

Combinare le subnet dell'applicazione SAP e del database in una sola. È possibile combinare le subnet dell'applicazione e del database per creare una rete SAP di grandi dimensioni. Questa progettazione di rete rispecchia molte reti SAP locali. La combinazione di queste due subnet richiede maggiore attenzione alla sicurezza della subnet e alle regole del gruppo di sicurezza di rete. I gruppi di sicurezza delle applicazioni sono importanti quando si usa una singola subnet per le subnet di database e applicazioni SAP.

Combinare la subnet perimetrale SAP e la subnet dell'applicazione. È possibile combinare la subnet perimetrale e la subnet dell'applicazione SAP. È necessario prestare maggiore attenzione alle regole del gruppo di sicurezza di rete e all'uso del gruppo di sicurezza delle applicazioni. È consigliabile solo questo approccio di semplificazione per piccole proprietà SAP.

Combinare reti virtuali SPOKE SAP tra ambienti SAP diversi L'architettura usa reti virtuali diverse per ogni ambiente SAP (hub, produzione, non produzione e ripristino di emergenza). A seconda delle dimensioni del panorama applicativo SAP, è possibile combinare le reti virtuali SAP spoke in un numero minore o anche in un solo spoke SAP. È comunque necessario dividere tra ambienti di produzione e non di produzione. Ogni ambiente di produzione SAP diventa una subnet in una rete virtuale di produzione SAP. Ogni ambiente sap non di produzione diventa una subnet in una rete virtuale non di produzione SAP.

Collaboratori

Microsoft gestisce questo articolo. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Passaggi successivi