Prefazione: unità di misura per i dati/informazioni

Spesso il throughput di Network Storage è indicato in Mbps o Gbps.

È importante notare che Mb (Megabit) è un prefisso decimale e MiB (Mebibyte) è un prefisso binario, quindi si tratta di scale diverse. La confusione aumenta perché MiB (Mebibyte) era comunemente conosciuto in Microsoft Windows come Megabyte.

Per riferimento futuro, in tutta la documentazione di rete si utilizzano i termini Mb (Megabit) e MiB (Mebibyte) in base al sistema di unità di misura (SI) definito da IEC e adottato da IEEE, ISO e NIST.

Ad esempio:

• 100 Mbps (Megabit al secondo), sarebbe 12 MiB/s (Mebibyte al secondo)
• 1000 Mbps (Megabit al secondo), noti anche come 1 Gbps (Gigabit al secondo), corrispondono a 120 MiB/s (Mebibyte al secondo)
• 10 Gbps (Gigabit al secondo), sarebbero 1200 MiB/s (Mebibyte al secondo)

Considerazioni sulla connettività di rete

Per una panoramica delle opzioni di connettività disponibili, vedere Determinazione dell'accesso al paesaggio del sistema SAP.

SAP I sistemi sono spesso il punto focale delle operazioni aziendali, con un gran numero di applicazioni integrate (comprese quelle legacy).

Nella maggior parte dei casi per i carichi di lavoro di SAP, è necessaria una connessione alla rete interna esistente e si consiglia di usare IBM Cloud® Direct Link 2.0 per utilizzare la connessione sicura, a bassa latenza e ad alta velocità (disponibile fino a 10 Gbps) come connessione OSI Layer-2/3 instradata.

Queste opzioni di connettività dipendono dai requisiti aziendali, ad esempio se l'azienda vuole utilizzare il cloud e ridurre il rischio di sicurezza isolando i flussi di rete attraverso la struttura di rete e la sicurezza esistenti. In questi progetti di connettività "disconnessa" o "solo privata", è meglio richiedere a IBM Cloud® ulteriori informazioni e discutere i casi d'uso.

Inoltre, SAP sconsiglia vivamente di suddividere il tiering del sistema SAP tra sedi On-Premises e sedi Cloud e spetta all'azienda valutarlo; ad esempio, SAP sconsiglia di mantenere SAP AnyDB eseguito da un'infrastruttura in una sede On-Premises e di collegarsi a SAP NetWeaver eseguito da un'infrastruttura in una sede Cloud. Per IBM Power Virtual Server s questa suddivisione del sistema SAP non è supportata.

Considerazioni sulla topologia di rete

A seconda del numero e della configurazione dei sistemi SAP combinati con la disposizione dei flussi di rete tra questi sistemi per motivi di sicurezza o di prestazioni, la topologia di rete sarà significativamente diversa. La progettazione di questa topologia riflette i requisiti aziendali di sicurezza, prestazioni, costi, flessibilità e connettività.

Utilizzando l'applicazione aziendale Enterprise Resource Planning (ERP), ad esempio, un sistema SAP che ospita l'istanza di produzione che utilizza l'approccio di tiering del sistema SAP utilizzando l'alta disponibilità di SAP NetWeaver e SAP HANA:

• SAP NetWeaver, ci sono almeno quattro host invece di uno:

  • Servizi centrali (ASCS)
  • Server applicativo primario (PAS), noto anche come Istanza centrale (CI)
  • Istanza del server di replica Enqueue (ERS)
  • Server applicativo aggiuntivo (AAS)

• SAP HANA, ci sono almeno 2 host (forse 3) anziché 1:

  • SAP HANA nodo primario (utilizzando SAP HANA System Replication)
  • SAP HANA nodo di failover secondario (utilizzando SAP HANA System Replication)
  • SAP HANA nodo terziario di failover per il disaster recovery (utilizzando SAP HANA System Replication)

• Questo descrive 1 sistema SAP all'interno del paesaggio SAP. Un paesaggio SAP potrebbe utilizzare:

  • Una traccia, 5 sistemi SAP (Sandbox > Sviluppo > Test > Staging > Produzione)
  • Doppio binario, 5 SAP Sistemi (Sandbox > Sviluppo di nuove funzionalità + Sviluppo di manutenzione > Test di nuove funzionalità + Test di manutenzione > Staging > Produzione)

Pertanto, per un paesaggio SAP potrebbero essere necessarie da 30 a 50 istanze di SAP, distribuite su 10-50 server host (fisici o virtualizzati). Questo prima che vengano aggiunte altre applicazioni aziendali per specifiche operazioni commerciali, settori o funzioni geografiche.

Le dimensioni dei paesaggi di SAP hanno un impatto diretto sulla topologia della rete.

In genere, anche se questo varia da caso a caso, sono necessarie le seguenti reti per soddisfare gli scenari e le prestazioni richieste dall'azienda che utilizza SAP Business Applications:

• Rete interna per la comunicazione tra più istanze in un SAP Landscape con diversi approcci di tiering del sistema SAP
• Rete per la gestione e i trasferimenti di memoria dei sistemi di database
• Rete utilizzata nella produzione

Tuttavia, nello scenario più semplice potrebbe esserci una rete privata per tutti gli scopi. Dipende dai requisiti aziendali.

Considerazioni sul consumo di rete

La comunicazione di rete tradizionale del carico di lavoro di SAP è relativamente piccola, con un traffico di rete inferiore a 100 MiB al giorno, ad esempio:

• Transazioni utente da SAPGUI; per Windows, per Java (usato con macOS o Linux )
• Transazioni degli utenti da SAP WebGUI
• Transazioni utente con le applicazioni web Dynpro di SAP da SAP NetWeaver Business Client (NWBC)
• SAP Chiamata di funzione remota ( SAP RFC) tra sistemi SAP e non SAP
• SAP iDOC Inbound/Outbound tra i sistemi SAP e non SAP con terze parti (ad esempio, banche, fornitori)

Tuttavia, anche le comunicazioni di rete con carico di lavoro SAP sono molto più grandi e consumano molto più traffico di rete, ad esempio:

• SAPUI5 preinstallare le librerie e i temi per il Launchpad di SAP Fiori e per le applicazioni
  • 10 MiB- 25 MiB (stima) per ogni nuova sessione caricata dall'assistente web SAP (noto anche come. XRay), queste librerie preinstallate vengono memorizzate nella cache dal browser. Una volta memorizzate nella cache, le librerie sono disponibili per l'uso in qualsiasi nuova scheda del browser, anche dopo il riavvio del browser o il logout da SAP Fiori; finché la cache del browser non viene cancellata
  • 20 KiB- 500 KiB (stima) per ogni nuova applicazione Fiori caricata all'interno della sessione
• SAP HANA System Replication (HSR) Sync o Async, streaming di Gigabyte di dati al mese da nodi primari a secondari (o terziari)

Con l'aumento del traffico del nuovo software di progettazione SAP, è possibile superare pesantemente la quantità di traffico di rete riscontrata in passato nell'utilizzo di SAP.

È importante progettare le applicazioni di SAP in modo che utilizzino la dorsale privata di IBM Cloud per questi trasferimenti di dati, in quanto non ci sono costi di ingresso/uscita, mentre l'uso su Internet pubblica comporta costi di uscita.

È necessario stimare la quantità di dati trasferiti. Durante le fasi iniziali di attuazione del progetto, questo può essere difficile. Tuttavia, è necessario effettuare una stima di almeno un ordine di grandezza.

Considerazioni sulle prestazioni del throughput di rete

SAP generalmente raccomanda una velocità di trasmissione di rete di 10 Gbps (ridondante) per il traffico tra i suoi server applicativi e i database di SAP HANA, e per altri client di SAP HANA, come SAP Business Intelligence.

Per le implementazioni di SAP NetWeaver che utilizzano SAP AnyDB con storage locale, anche per le configurazioni a tre livelli, le reti a 1 Gbps sono generalmente sufficienti.

Considerazioni sulle prestazioni della latenza di rete

Per le operazioni aziendali e i sistemi non dipendenti da SAP, è possibile che sia necessario soddisfare determinati indicatori chiave di prestazione (KPI) di latenza. Si dovrebbe considerare la posizione degli host e testare la latenza utilizzando la rete dorsale privata IBM Cloud.

La verifica della latenza utilizzando la metrica Round Trip Time (RTT) è necessaria quando si progetta l'High Availability (HA) e il Disaster Recovery (DR) per SAP HANA.

Se si progetta un failover HA all'interno di un'unica sede, in quasi tutti i casi ciò sarà possibile per i requisiti di SAP HANA System Replication.

Tuttavia, se si progetta l'Alta disponibilità per SAP HANA su più siti all'interno di una regione, o se si progetta il Disaster Recovery su più regioni, la latenza che utilizza la metrica Round Trip Time (RTT) deve essere attentamente testata e considerata.

Questo perché IBM Cloud cerca di garantire un'elevata disponibilità della piattaforma, utilizzando sedi geograficamente disperse con tolleranza ai guasti (ad esempio, diverse valutazioni del rischio). Ulteriori informazioni disponibili su Come l' IBM Cloud e garantisce alta disponibilità e ridondanza.

In particolare, per l'infrastruttura VPC le zone di disponibilità sono posizioni geograficamente disperse all'interno della regione. Per la maggior parte dei carichi di lavoro, questo design offre una maggiore ridondanza nella regione. Tuttavia, la replica del sistema SAP HANA richiede una bassa latenza di rete, che può diventare difficile da soddisfare a causa dei limiti fisici del cablaggio per il trasferimento dei dati (cioè la velocità della luce su cavi in fibra ottica).

Considerazioni sulla sicurezza delle porte di rete

Le seguenti informazioni sono un breve riassunto di SAP Help Portal - TCP/IP Ports of All SAP Products, che fornisce un esempio delle considerazioni necessarie per la sicurezza dei sistemi SAP e dell'intero panorama dell'infrastruttura IT su IBM Cloud.

A seconda delle applicazioni tecniche SAP utilizzate e degli scenari aziendali affrontati, sarà necessario aprire porte diverse per gli host. In genere, per soddisfare questo requisito, i gruppi di porte del firewall vengono combinati con le regole del firewall. È anche possibile utilizzare singole regole firewall per host, anche se spesso diventa ingestibile.

La tabella seguente include alcune delle Porte chiave da utilizzare con i sistemi SAP che utilizzano SAP NetWeaver e SAP HANA, che devono essere corrette, a seconda del numero di istanza dell'Applicazione tecnica SAP ; i numeri di istanza 00, 01, 02 sono quelli predefiniti nelle varie Applicazioni tecniche SAP e saranno in schemi diversi (questi schemi sono indicati con l'evidenziazione code blocks ):

Considerazioni sulla sicurezza della segregazione del traffico di rete

È possibile separare diversi tipi di traffico di rete nel paesaggio, sia per restrizioni di sicurezza che per considerazioni di throughput.

La segregazione delle reti è utile per i seguenti casi d'uso del carico di lavoro SAP:

• Server multipli che scambiano dati
  • SAP Sistemi in un'architettura logica a tre livelli, in cui il database SAP e le istanze dell'applicazione SAP si trovano su host diversi.
• SAP e multipla Sistemi che scambiano grandi quantità di dati
  • I server di database, che devono avere una bassa latenza di rete e un elevato throughput di rete per l'archiviazione di blocchi/file, devono evitare i firewall. Tuttavia, il database deve essere protetto dall'accesso di altri sistemi e reti.

Per utilizzare efficacemente la segregazione delle reti, l'interconnettività deve essere consentita a condizioni specifiche.