Connettività con SAP RISE
Con il panorama sap gestito all'interno di RISE ed eseguito in una rete virtuale separata, in questo articolo vengono fornite opzioni di connettività disponibili.
Esplorare il peering di reti virtuali di Azure con SAP RISE/ECS
Un peering di rete virtuale (vnet) è il modo più efficiente per connettersi in modo sicuro tra due reti virtuali, tutto in uno spazio di indirizzi di rete privato. Le reti con peering vengono visualizzate come una per scopi di connettività, consentendo alle applicazioni di comunicare tra loro. Le applicazioni in esecuzione in reti virtuali diverse, sottoscrizioni, tenant o aree di Azure possono comunicare direttamente. Come il traffico di rete in una singola rete virtuale, il traffico con peering rimane in uno spazio indirizzi privati e non attraversa Internet. Si applicano addebiti per il peering di rete virtuale.
Per le distribuzioni SAP RISE/ECS, il peering virtuale è il modo migliore per stabilire la connettività con l'ambiente Azure esistente del cliente. I vantaggi principali sono:
- Latenza di rete ridotta e velocità effettiva massima tra il panorama sap RISE e le applicazioni e i servizi in esecuzione in Azure.
- Nessuna complessità e costi aggiuntivi con un percorso di comunicazione locale dedicato per il carico di lavoro SAP RISE. Usare invece il percorso di comunicazione locale degli hub di rete di Azure esistenti.
Il peering di reti virtuali può essere configurato all'interno della stessa area dell'ambiente gestito da SAP, ma anche tramite il peering di reti virtuali globale tra due aree di Azure. Con SAP RISE/ECS disponibile in molte aree di Azure, l'area deve corrispondere al carico di lavoro in esecuzione nelle reti virtuali dei clienti a causa della latenza e delle considerazioni sui costi di peering. Tuttavia, alcuni degli scenari (ad esempio, la distribuzione centrale di S/4HANA per una società presente a livello globale) richiedono anche di eseguire il peering delle reti a livello globale. Per un panorama SAP distribuito a livello globale, è consigliabile usare l'architettura di rete in più aree all'interno del proprio ambiente Azure, con il peering SAP RISE in locale in ogni area geografica agli hub di rete.
Questo diagramma mostra una tipica rete virtuale hub e spoke del cliente SAP. Il peering di reti virtuali tra tenant connette SAP RISE e le reti virtuali hub del cliente.
Sia le reti virtuali SAP che le reti virtuali dei clienti sono protette con gruppi di sicurezza di rete (NSG), consentendo la comunicazione sulle porte SAP e di database tramite il peering. La comunicazione tra le reti virtuali con peering viene protetta tramite questi NSG, limitando la comunicazione da/verso l'ambiente SAP del cliente.
Poiché SAP RISE/ECS viene eseguito in sottoscrizioni e nel tenant e di Azure di SAP, configurare il peering di reti virtuali tra tenant diversi. A tale scopo, configurare il peering con l'ID risorsa di Azure della rete fornita da SAP e approvare il peering da SAP. Aggiungere un utente dal tenant Microsoft Entra opposto come utente guest, accettare l'invito dell'utente guest e seguire il processo documentato in Creare un peering di rete virtuale - sottoscrizioni diverse. Contattare il rappresentante SAP per i passaggi esatti necessari. Coinvolgere i rispettivi team all'interno dell'organizzazione che gestiscono la rete, l'amministrazione degli utenti e l'architettura per consentire il completamento rapido di questo processo.
Vpn da rete virtuale a rete virtuale
In alternativa al peering di rete virtuale, è possibile stabilire una connessione di rete privata virtuale (VPN) tra i gateway VPN, distribuiti sia nella sottoscrizione SAP RISE/ECS che nei clienti. È possibile stabilire una connessione da rete virtuale a rete virtuale tra questi due gateway VPN, abilitando la comunicazione rapida tra le due reti virtuali separate. Le reti e i gateway rispettivi possono risiedere in aree di Azure diverse.
Questo diagramma mostra una tipica rete virtuale hub e spoke del cliente SAP. Il gateway VPN situato nella rete virtuale SAP RISE si connette tramite una connessione da rete virtuale a rete virtuale nel gateway contenuto nella rete virtuale hub del cliente.
Anche se il peering di rete virtuale è il modello di distribuzione consigliato e più tipico, una rete virtuale VPN da rete virtuale a rete virtuale può potenzialmente semplificare un peering virtuale complesso tra le reti virtuali SAP RISE/ECS. Il Gateway VPN funge solo da punto di ingresso nella rete del cliente ed è gestito e protetto da un team centrale. La velocità effettiva della rete è limitata dallo SKU del gateway scelto su entrambi i lati. Per soddisfare i requisiti di resilienza, assicurarsi che i gateway di rete virtuale con ridondanza della zona vengano usati per tale connessione.
I gruppi di sicurezza di rete sono in vigore sia sulla rete virtuale sap che sul cliente, in modo identico all'architettura di peering, consentendo la comunicazione con le porte SAP NetWeaver e HANA in base alle esigenze. Per informazioni dettagliate su come configurare la connessione VPN e le impostazioni da usare, contattare il rappresentante SAP.
Connettività all'ambiente locale
Con una distribuzione di Azure del cliente esistente, la rete locale è già connessa tramite ExpressRoute (ER) o VPN. Lo stesso percorso di rete locale viene usato generalmente per i carichi di lavoro gestiti da SAP RISE/ECS. L'architettura preferita consiste nell'usare ER/Gateway VPN esistenti nel cliente a questo scopo, con la rete virtuale SAP RISE connessa come rete spoke connessa all'hub di rete virtuale del cliente.
Questo diagramma mostra una tipica rete virtuale hub e spoke del cliente SAP. Si connette in locale con una connessione. Il peering reti virtuali tra tenant connette la rete virtuale SAP RISE alla rete hub del cliente. Il peering di rete virtuale ha il transito del gateway remoto abilitato, consentendo l'accesso alla rete virtuale SAP RISE dall'ambiente locale.
Con questa architettura, le regole di sicurezza e i criteri centrali che gestiscono la connettività di rete ai carichi di lavoro del cliente si applicano anche ai carichi di lavoro gestiti da SAP RISE/ECS. Lo stesso percorso di rete locale viene usato sia per la rete virtuale SAP RISE/ECS del cliente.
Se attualmente non è presente la connettività da Azure a locale, contattare il rappresentante SAP per informazioni dettagliate sui modelli di connessioni possibili per il carico di lavoro RISE. Se SAP RISE/ECS stabilisce direttamente l'ambiente locale all'interno di RISE, tale connessione locale è disponibile solo per raggiungere la rete virtuale gestita SAP. Tale connessione ExpressRoute o VPN dedicata all'interno di SAP RISE non può essere usata per accedere alle reti virtuali di Azure del cliente.
Nota
Una rete virtuale può avere un solo gateway, locale o remoto. Con il peering di reti virtuali stabilito tra SAP RISE usando il transito del gateway remoto, non è possibile aggiungere gateway nella rete virtuale SAP RISE/ECS. Non è possibile combinare il peering di rete virtuale con il transito del gateway remoto con un altro gateway di rete virtuale nella rete virtuale SAP RISE/ECS.
rete WAN virtuale con carichi di lavoro gestiti da SAP RISE
Analogamente all'uso di un'architettura di rete hub-spoke con connettività sia alla rete virtuale SAP RISE/ECS che all'hub locale, è possibile usare l'hub vWAN (Virtual Wan) di Azure per lo stesso scopo. Il carico di lavoro RISE è una rete spoke connessa all'hub di rete vWAN. Entrambe le opzioni di connessione a SAP RISE descritte in precedenza, ovvero il peering reti virtuali e la rete virtuale VPN da rete virtuale a rete virtuale, sono disponibili con vWAN.
L'hub di rete vWAN viene distribuito e gestito dal cliente nella propria sottoscrizione. Il cliente gestisce anche interamente la connessione e il routing locali tramite l'hub di rete vWAN, con accesso alla rete virtuale spoke con peering SAP RISE.
Connettività durante la migrazione a SAP RISE
La migrazione del panorama SAP a SAP RISE viene eseguita in diverse fasi in diversi mesi o più. Alcuni ambienti SAP vengono già migrati e in uso in modo produttivo, mentre si preparano altri sistemi SAP per la migrazione. Nella maggior parte dei progetti dei clienti, i sistemi più grandi e più critici vengono migrati al centro o alla fine del progetto. È necessario prendere in considerazione un'ampia larghezza di banda per la migrazione dei dati o la replica del database e non influire sul percorso di rete degli utenti negli ambienti RISE già produttivi. I sistemi SAP già migrati potrebbero anche dover comunicare con il panorama SAP ancora in locale o nel provider di servizi esistente.
Durante la pianificazione della migrazione a SAP RISE, pianificare come in ogni fase i sistemi SAP siano raggiungibili per la base utente e come viene instradato il trasferimento dei dati alla rete virtuale RISE/ECS. Spesso sono coinvolti più posizioni e parti, ad esempio provider di servizi e data center esistenti con una connessione alla rete aziendale. Assicurarsi che non vengano create soluzioni temporanee con connessioni VPN senza considerare come nelle fasi successive viene eseguita la migrazione dei dati SAP per i sistemi più critici per l'azienda.
Integrazione DNS con carichi di lavoro gestiti sap RISE/ECS
L'integrazione delle reti di proprietà dei clienti con l'infrastruttura basata sul cloud e la fornitura di un concetto di risoluzione dei nomi trasparente è una parte essenziale di un'implementazione di progetto riuscita. Questo diagramma descrive uno degli scenari di integrazione comuni delle sottoscrizioni di proprietà di SAP, delle reti virtuali e dell'infrastruttura DNS con i servizi DNS e della rete locale del cliente. In questa configurazione, l'hub di Azure o i server DNS locali contengono tutte le voci DNS. L'infrastruttura DNS è in grado di risolvere le richieste DNS provenienti da tutte le origini (client locali, servizi di Azure del cliente e ambienti gestiti SAP).
Descrizione e specifiche della progettazione:
Configurazione DNS personalizzata per le reti virtuali di proprietà di SAP
Due macchine virtuali all'interno dei server DNS della rete virtuale RISE/PCE di Azure
I clienti devono fornire e delegare a SAP un sottodominio/zona (ad esempio ecs.contoso.com) per assegnare nomi e creare voci DNS in avanti e inversa per le macchine virtuali che eseguono l'ambiente gestito SAP. I server DNS SAP mantengono un ruolo DNS master per la zona delegata
Il trasferimento della zona DNS dal server DNS SAP ai server DNS del cliente è il metodo primario per replicare le voci DNS dall'ambiente RISE/PCE.
Le reti virtuali di Azure del cliente usano anche la configurazione DNS personalizzata che fa riferimento ai server DNS dei clienti che si trovano nella rete virtuale dell'hub di Azure.
Facoltativamente, i clienti possono configurare un server d'inoltro DNS privato all'interno delle reti virtuali di Azure. Tale server d'inoltro esegue quindi il push delle richieste DNS provenienti dai servizi di Azure ai server DNS SAP destinati alla zona delegata (ad esempio ecs.contoso.com).
Il trasferimento di zona DNS è applicabile alle progettazioni quando i clienti gestiscono soluzioni DNS personalizzate (ad esempio, server AD DS o BIND) all'interno della rete virtuale hub.
Nota
Sia le zone DNS fornite da Azure che le zone private di Azure non supportano la funzionalità di trasferimento della zona DNS, quindi non possono essere usate per accettare la replica DNS dai server DNS SAP RISE/PCE/ECS. INOLTRE, SAP in genere non supporta provider di servizi DNS esterni per la zona delegata.
SAP ha pubblicato un post di blog sull'implementazione DNS con SAP RISE in Azure. Per informazioni dettagliate, vedere qui.
Per altre informazioni sull'utilizzo di DNS di Azure per SAP, all'esterno dell'utilizzo con SAP RISE/ECS, vedere i dettagli nel post di blog seguente.
Connessioni Internet in uscita e in ingresso con SAP RISE/ECS
I carichi di lavoro SAP che comunicano con applicazioni e interfacce esterne potrebbero richiedere un percorso di uscita di rete a Internet. Analogamente, la base utente dell'azienda (ad esempio, SAP Fiori) richiede un ingresso Internet o connessioni in ingresso al panorama SAP. Per i carichi di lavoro gestiti sap RISE, collaborare con il rappresentante SAP per esplorare le esigenze per questi percorsi di comunicazione https/RFC/altri. La comunicazione di rete verso/da Internet è per impostazione predefinita non abilitata per i clienti SAP RISE/ECS e la rete predefinita usa solo intervalli IP privati. La connettività Internet richiede la pianificazione con SAP per proteggere in modo ottimale il panorama SAP del cliente.
Se si abilita il traffico associato a Internet o in ingresso con SAP RISE, la comunicazione di rete è protetta tramite varie tecnologie di Azure, ad esempio gruppi di sicurezza di rete, asg, gateway applicazione con Web Application Firewall (WAF), server proxy e altri a seconda dell'uso e dei protocolli di rete. Questi servizi sono completamente gestiti tramite SAP all'interno della sottoscrizione e della rete virtuale SAP RISE/ECS. Il percorso di rete da e verso Internet rimane in genere solo all'interno della rete virtuale SAP RISE/ECS e non transita nelle reti virtuali del cliente.
Le applicazioni all'interno della rete virtuale di un cliente si connettono a Internet direttamente dalla rispettiva rete virtuale o tramite i servizi gestiti centralmente del cliente, ad esempio Firewall di Azure, gateway app Azure lication, gateway NAT e altri. La connettività a SAP BTP da applicazioni non SAP RISE/ECS accetta lo stesso percorso associato a Internet di rete sul lato. Se è necessario un SAP Cloud Connecter per tale integrazione, eseguirlo nelle macchine virtuali del cliente. In altre parole, SAP BTP o qualsiasi comunicazione di endpoint pubblico si trova in un percorso di rete gestito dai clienti stessi se il carico di lavoro SAP RISE non è coinvolto.
Connettività BTP SAP
SAP Business Technology Platform (BTP) offre un'ampia gamma di applicazioni a cui si accede in genere tramite IP/nome host pubblico tramite Internet. I servizi del cliente in esecuzione nelle sottoscrizioni di Azure accedono a BTP tramite il metodo di accesso in uscita configurato, ad esempio il firewall centrale o gli indirizzi IP pubblici in uscita. Alcuni servizi SAP BTP, ad esempio SAP Data Intelligence, sono tuttavia accessibili tramite un peering di rete virtuale separato anziché un endpoint pubblico.
SAP offre collegamento privato servizio per i clienti che usano SAP BTP in Azure per le richieste uni direzionali provenienti da BTP. Il servizio collegamento privato SAP connette i servizi SAP BTP tramite un intervallo IP privato nella rete di Azure del cliente e quindi accessibile privatamente tramite il servizio di collegamento privato anziché tramite Internet. Contattare SAP per la disponibilità di questo servizio per i carichi di lavoro SAP RISE/ECS. Altre informazioni sul supporto di SAP collegamento privato per RISE sono disponibili qui.
Vedere la documentazione di SAP e una serie di post di blog sull'architettura del servizio di collegamento privato SAP BTP e dei metodi di connettività privata, che trattano di DNS e certificati nella seguente serie di blog SAP Introduzione al servizio collegamento privato BTP per Azure.
Porte di comunicazione di rete con SAP RISE
Qualsiasi servizio di Azure con accesso alla rete virtuale del cliente può comunicare con il panorama SAP in esecuzione all'interno della sottoscrizione di SAP RISE/ECS tramite le porte disponibili.
Diagramma delle porte aperte in un sistema SAP RISE/ECS. Connessioni RFC per BAPI e IDoc, https per OData e Rest/SOAP. ODBC/JDBC per le connessioni dirette al database a SAP HANA. Tutte le connessioni tramite il peering di rete virtuale privata. gateway applicazione con ip pubblico per https come opzione potenziale, gestita tramite SAP.
È possibile accedere al sistema SAP in SAP RISE tramite le porte di rete aperte, come configurato e aperto da SAP per l'uso. I protocolli HTTPS, RFC e JDBC/ODBC possono essere usati tramite intervalli di indirizzi della rete privata. Inoltre, le applicazioni possono accedere tramite HTTPS in un indirizzo IP disponibile pubblicamente, esposte dal gateway applicazione di Azure gestito da SAP RISE. Per informazioni dettagliate e le impostazioni per il gateway applicazione e le porte aperte NSG, contattare SAP.
Per altre informazioni , vedere Integrazione dei servizi di Azure con SAP RISE in che modo la connettività disponibile consente di estendere il panorama sap con i servizi di Azure.
Passaggi successivi
Vedere la documentazione: