Condividi tramite

Topologia di rete e connettività per una migrazione SAP

  • Articolo

Questo articolo si basa sulle considerazioni e le raccomandazioni definite nell'area di progettazione della zona di destinazione di Azure per la topologia e la connettività di rete. Le indicazioni contenute in questo articolo esaminano le principali considerazioni sulla progettazione e le procedure consigliate per la rete e la connettività da e verso le distribuzioni di Microsoft Azure e SAP. Poiché SAP è una piattaforma cruciale, la progettazione deve seguire anche le linee guida sulle aree di progettazione della zona di destinazione di Azure.

Pianificare l'indirizzamento IP

Un piano per l'indirizzamento IP in Azure è fondamentale per garantire che:

  • Lo spazio indirizzi IP non si sovrappone alle posizioni locali e alle aree di Azure.
  • La rete virtuale contiene lo spazio indirizzi corretto.
  • I piani di configurazione della subnet vengono eseguiti in anticipo.

Il diagramma dell'architettura seguente illustra le considerazioni sulla rete in SAP in un acceleratore di zona di destinazione di Azure:

Diagramma delle considerazioni sulla rete in SAP in un acceleratore di zona di destinazione di Azure.

Considerazioni sulla progettazione per l'implementazione SAP

È possibile dedicare e delegare le subnet a determinati servizi e quindi creare istanze di tali servizi all'interno di tali subnet. Anche se Azure consente di creare più subnet delegate in una rete virtuale, è possibile avere una sola subnet delegata in una rete virtuale per Azure NetApp Files. Se si usano più subnet delegate per Azure NetApp Files, non è possibile creare un nuovo volume.

Caso d'uso

Per implementare Azure NetApp Files sono necessarie subnet delegate. Questo approccio è diffuso per le distribuzioni SAP che condividono file system. È necessaria una subnet delegata solo per un gateway applicazione durante il bilanciamento del carico o per SAP BusinessObjects Business Intelligence, ovvero un server applicazioni Web SAP di bilanciamento del carico.

Configurare il DNS e la risoluzione dei nomi per le risorse in locale e di Azure

Domain Name System (DNS) è una parte fondamentale dell'architettura della zona di destinazione di Azure. Alcune organizzazioni possono ritenere opportuno usare gli investimenti esistenti in DNS, mentre altre possono vedere l'adozione del cloud come un'opportunità per modernizzare l'infrastruttura DNS interna e usare le funzionalità native di Azure.

Consigli di progettazione per l'implementazione SAP

Usare i consigli del caso d'uso seguenti quando il nome DNS o virtuale di una macchina virtuale non cambia durante la migrazione.

Caso d'uso

  • I nomi DNS e virtuali in background connettono molte interfacce di sistema nel panorama SAP e i clienti sono a volte a conoscenza delle interfacce definite dagli sviluppatori nel tempo. Connessione problemi si verificano tra i sistemi quando i nomi DNS o virtuali cambiano dopo le migrazioni. Per semplicità, è consigliabile conservare gli alias DNS.

  • Usare zone DNS diverse per distinguere ogni ambiente, tra cui sandbox, sviluppo, preproduzione e ambienti di produzione, l'uno dall'altro. Un'eccezione riguarda le distribuzioni SAP con una propria rete virtuale. In questo scenario, le zone DNS private potrebbero non essere necessarie.

Definire una topologia di rete di Azure

Le zone di destinazione su scala aziendale supportano due topologie di rete. Una topologia si basa su Azure rete WAN virtuale. L'altra è una topologia di rete tradizionale basata su un'architettura hub-spoke. Questa sezione descrive le configurazioni e le procedure SAP consigliate per entrambi i modelli di distribuzione.

Usare una topologia di rete basata sulla rete WAN virtuale se l'organizzazione prevede di:

  • Distribuire le risorse in diverse aree di Azure e connettere le posizioni globali agli ambienti sia di Azure che locali.
  • Integrare completamente le distribuzioni WAN software-defined con Azure.
  • Distribuire fino a 2.000 carichi di lavoro di macchine virtuali in tutte le reti virtuali connesse a un hub rete WAN virtuale.

Le organizzazioni usano la rete WAN virtuale per soddisfare i requisiti di interconnettività su larga scala. Microsoft gestisce questo servizio, che consente di ridurre la complessità complessiva della rete e modernizzare la rete dell'organizzazione.

Usare una topologia di rete di Azure tradizionale basata su un'architettura hub-spoke se l'organizzazione:

  • Prevede di distribuire le risorse solo in aree di Azure selezionate.
  • Non è necessaria una rete globale e interconnessa.
  • Include poche posizioni remote o di succursali per area e richiede meno di 30 tunnel IPSec (Internet Protocol Security).
  • Richiede controllo completo e granularità per configurare manualmente la rete di Azure.

Consigli di progettazione per l'implementazione SAP

  • Usare rete WAN virtuale per le distribuzioni di Azure in reti nuove, di grandi dimensioni o globali in cui è necessaria la connettività di transito globale tra aree di Azure e località locali. Adottando questo approccio, non è necessario configurare manualmente il routing transitivo per la rete di Azure ed è possibile seguire uno standard per le distribuzioni SAP in Azure.

  • Valutare la possibilità di distribuire appliance virtuali di rete tra aree solo se si usano appliance virtuali di rete partner. Le appliance virtuali di rete tra aree o reti virtuali non sono necessarie se sono presenti appliance virtuali di rete native. Quando si distribuiscono tecnologie di rete e appliance virtuali di rete dei partner, seguire le indicazioni del fornitore per identificare le configurazioni in conflitto con la rete di Azure.

  • rete WAN virtuale gestisce la connettività tra reti virtuali spoke per le topologie basate su rete WAN virtuale, quindi non è necessario configurare route definite dall'utente o appliance virtuali di rete. La velocità effettiva massima della rete per il traffico da rete a rete nello stesso hub virtuale è di 50 Gbps. Per superare questa limitazione della larghezza di banda, le zone di destinazione SAP possono usare il peering di rete virtuale per connettersi ad altre zone di destinazione.

  • Nessuna topologia supporta distribuzioni di appliance virtuali di rete tra un'applicazione SAP e un server di database.

  • Il peering di reti virtuali locali e globali offre connettività e sono gli approcci preferiti per garantire la connettività tra le zone di destinazione per le distribuzioni SAP in più aree di Azure.

Pianificare la connettività Internet in ingresso e in uscita

Questa sezione descrive i modelli di connettività consigliati per la connettività in ingresso e in uscita da e verso la rete Internet pubblica. I servizi di sicurezza di rete nativi di Azure come Firewall di Azure, Web application firewall di Azure nel gateway di app Azure lication e Frontdoor di Azure sono servizi completamente gestiti, quindi non si comportano costi operativi e di gestione associati alle distribuzioni dell'infrastruttura.

Consigli di progettazione per l'implementazione SAP

  • Per i clienti con footprint globale, Frontdoor di Azure facilita le distribuzioni SAP usando i criteri di Web Application Firewall per distribuire e proteggere le applicazioni HTTP e HTTPS globali tra aree di Azure.

  • Sfruttare i vantaggi dei criteri di Web Application Firewall in Frontdoor di Azure quando si usa Frontdoor di Azure e gateway applicazione per proteggere le applicazioni HTTP e HTTPS. Bloccare il traffico verso gateway applicazione in modo che riceva il traffico solo da Frontdoor di Azure.

  • gateway applicazione e Web Application Firewall presentano limitazioni quando gateway applicazione funge da proxy inverso per le app Web SAP. Poiché SAP Web Dispatcher e NetScaler sono più intelligenti di gateway applicazione, è necessario eseguire test estesi se li si sostituisce con gateway applicazione. Verificare lo stato più recente ed elencare tutti gli scenari supportati, non supportati, testati e non testati, se possibile.

  • Usare un web application firewall per analizzare il traffico quando viene esposto a Internet. Un'altra opzione consiste nell'usarla con il servizio di bilanciamento del carico o con risorse, ad esempio gateway applicazione o soluzioni di terze parti, con funzionalità firewall predefinite.

  • Per evitare perdite di dati, usare collegamento privato di Azure per accedere in modo sicuro alle risorse PaaS (Platform as a Service), ad esempio Archiviazione BLOB di Azure, File di Azure, Azure Data Lake Archiviazione Gen2 e Azure Data Factory. Gli endpoint privati consentono anche di proteggere il traffico tra reti virtuali e servizi, ad esempio Archiviazione di Azure e Backup di Azure. Il traffico tra la rete virtuale e il servizio abilitato per l'endpoint privato passa attraverso la rete globale Microsoft, che ne impedisce l'esposizione alla rete Internet pubblica.

Implementare Azure ExpressRoute con disponibilità elevata

Azure ExpressRoute è progettato per garantire la disponibilità elevata per fornire connettività di rete privata di livello carrier alle risorse Microsoft. Non esiste un singolo punto di errore nel percorso ExpressRoute all'interno della rete Microsoft. Per ottimizzare la disponibilità, anche il cliente e il segmento del provider di servizi del circuito ExpressRoute devono essere creati per la disponibilità elevata.

Suggerimenti per la progettazione per le implementazioni SAP:

Definire i requisiti di crittografia di rete

Questa sezione illustra le raccomandazioni principali per crittografare le reti tra ambienti locali e di Azure e tra aree di Azure.

Considerazioni sulla progettazione per le implementazioni SAP:

  • Il traffico non viene crittografato per impostazione predefinita quando si usa ExpressRoute per configurare il peering privato.

  • Non è necessario crittografare il traffico tramite ExpressRoute per le distribuzioni SAP. Il traffico SAP usa in genere una grande quantità di larghezza di banda ed è sensibile alle prestazioni. I tunnel IPSec crittografano il traffico Internet per impostazione predefinita e la crittografia o la decrittografia potrebbe influire negativamente sulle prestazioni del traffico.

  • Il cliente determina se il traffico SAP deve essere crittografato. Per altre informazioni sulle opzioni di crittografia di rete nelle zone di destinazione su scala aziendale, vedere Topologia di rete e connettività.

Separare i sistemi

Esistono ambienti diversi, tra cui sviluppo, test, qualità, preproduzione e ambienti di produzione, in uno scenario SAP e i clienti tendono a classificare questi sistemi in costrutti logici o fisici per rispettare gli standard di sicurezza e conformità. L'idea è quella di gestire tutti i sistemi che hanno lo stesso ciclo di vita in un gruppo di risorse comune. È possibile definire questi gruppi a vari livelli, ad esempio a livello di sottoscrizione o di gruppo di risorse.

L'organizzazione deve anche considerare la struttura di sicurezza e criteri durante il raggruppamento delle risorse in un panorama SAP. Tuttavia, per il flusso dei trasporti SAP tra ambienti di sviluppo, test, qualità e produzione, l'organizzazione potrebbe avere bisogno di:

  • Peering di reti virtuali.
  • Apertura delle porte del firewall tra reti virtuali.
  • Regole del gruppo di sicurezza di rete e UDR.

Non è consigliabile ospitare il sistema di gestione del database (DBMS) e i livelli applicativi di sistemi SAP in reti virtuali diverse e connetterli usando il peering di rete virtuale. Un traffico di rete eccessivo tra i livelli può accumulare costi sostanziali.

Consigli aggiuntivi per le implementazioni SAP

  • Nessuna topologia supporta l'inserimento del livello dell'applicazione SAP e di SAP DBMS in reti virtuali di Azure diverse che non sono sottoposte a peering.

  • È possibile usare le regole dei gruppi di sicurezza delle applicazioni e dei gruppi di sicurezza di rete per definire gli elenchi di controllo di accesso per la sicurezza di rete tra il livello applicazione SAP e il livello DBMS. È possibile aggiungere macchine virtuali ai gruppi di sicurezza di Azure per facilitare la gestione della sicurezza.

  • Abilitare la rete accelerata di Azure nelle macchine virtuali usate nei livelli dell'applicazione SAP e del sistema DBMS. I livelli del sistema operativo seguenti supportano la rete accelerata in Azure:

    • Windows Server 2012 R2 o versione successiva
    • SU edizione Standard Linux Enterprise Desktop 12 SP3 o versione successiva
    • Red Hat Enterprise Linux 7.4 o versione successiva
    • Oracle Linux 7.5
      • Il kernel compatibile con Red Hat Enterprise Linux richiede la versione 3.10.0-862.13.1.el7.
      • Il kernel Oracle Unbreakable Enterprise richiede la versione 5.

  • Assicurarsi di configurare le distribuzioni interne per Azure Load Balancer per usare la funzionalità direct server return. Questa funzionalità riduce la latenza quando si usano configurazioni di bilanciamento del carico interno per configurazioni a disponibilità elevata nel livello DBMS.

  • Se si usa Load Balancer con sistemi operativi guest Linux, assicurarsi che il parametro net.ipv4.tcp_timestamps di rete Linux sia impostato su 0.

  • Per una latenza di rete ottimale con applicazioni SAP, valutare l'uso di gruppi di posizionamento di prossimità di Azure.

  • Per i progetti di migrazione, prendere in considerazione l'ottimizzazione dei parametri di rete. Ad esempio, è possibile migliorare le prestazioni disabilitando i riconoscimenti durante il periodo di migrazione.

  • Per altre informazioni sull'implementazione SAP, vedere il portale di supporto SAP e Nota SAP 2391465.

Considerazioni sulla progettazione per le implementazioni di istanze riservate edizione Standard

Quando si eseguono distribuzioni di istanze riservate SAP edizione Standard in Azure, l'integrazione dell'ambiente gestito da SAP con il proprio ecosistema di Azure è fondamentale. Per altre informazioni sulle procedure consigliate e sulle linee guida, vedere Integrazione di Azure con l'istanza riservata di SAP edizione Standard carichi di lavoro gestiti.

L'implementazione di SAP RI edizione Standard include in genere due opzioni per la connettività: una VPN da sito a sito o un peering di rete virtuale. Se non si dispone di carichi di lavoro di Azure precedenti, una VPN da sito a sito potrebbe essere l'opzione più semplice. Tuttavia, se si vuole adottare Azure come piattaforma strategica, è possibile configurare una zona di destinazione di Azure appropriata e usare il peering di rete virtuale al tenant di SAP RI edizione Standard. Per questi scenari, una zona di destinazione semplificata come la zona di destinazione di Azure potrebbe essere un'opzione valida. È possibile adattare facilmente questa esperienza di distribuzione pronta ai requisiti, in particolare i parametri della rete virtuale.

Anche la distribuzione del peering di reti virtuali tra tenant nel tenant di istanze riservate SAP edizione Standard richiede più lavoro. È necessario pianificare attentamente l'architettura di rete virtuale per assicurarsi che non siano presenti intervalli di routing interdomini senza classi sovrapposti. È anche necessario eseguire correttamente il peering del DNS al tenant dell'istanza riservata di SAP edizione Standard.

Prendere in considerazione i limiti e le limitazioni se si decide di configurare una soluzione rete WAN virtuale e se sono necessarie connessioni VPN da sito a sito o ExpressRoute.