Préface : unités de mesure des données/informations

Souvent, le débit du réseau de stockage est indiqué en Mbit/s ou Gbit/s.

Il est important de noter que Mb (mégabits) est un préfixe décimal et Mio (mébioctet) est un préfixe binaire, ils sont donc à des échelles différentes. La confusion est d'autant plus grande que Mio (mébioctet) était communément appelé Megabyte dans Microsoft Windows.

Pour toute référence future dans la documentation sur la mise en réseau, Mb (mégabits) et Mio (mébioctet) sont utilisés en fonction du système d'unités (SI) défini par la CEI et adopté par l'IEEE, l'ISO et le NIST.

Par exemple :

• 100 Mbit/s (mégabits par seconde), soit 12 Mio/s (mébioctet par seconde)
• 1000 Mbit/s (mégabits par seconde), soit 1 Gbit/s (gigabit par seconde), soit 120 Mio/s (mébioctet par seconde)
• 10 Gbit/s (gigabits par seconde), soit 1200 Mio/s (mébioctet par seconde)

Considérations relatives à la connectivité des réseaux

Pour une présentation des options de connectivité disponibles, voir Détermination de l'accès à votre environnement système SAP.

Les systèmes SAP sont souvent le point central des opérations métier, avec un grand nombre d'applications intégrées (y compris les applications existantes).

Dans la plupart des cas pour les charges de travail SAP, une connexion au réseau interne existant est requise, et il est recommandé d'utiliser IBM Cloud® Direct Link 2.0 pour utiliser la connexion sécurisée, à faible temps d'attente et à haut débit (disponible jusqu'à 10 Gbit/s) sous la forme d'une connexion OSI Layer-2/3 Routed.

Ces options de connectivité dépendent des exigences métier, par exemple, si l'entreprise souhaite utiliser le cloud et diminue également le risque de sécurité en isolant les flux de réseau via leur structure de réseau et leur sécurité existantes. Dans ces conceptions de connectivité "déconnectée" ou "privée uniquement", il est préférable de consulter IBM Cloud® pour obtenir des informations supplémentaires et de discuter de vos cas d'utilisation.

En outre, il n'est pas recommandé par SAP de répartir la hiérarchisation du système SAP entre les sites locaux et les sites dans le cloud, et il appartient à l'entreprise de l'évaluer ; par exemple, il n'est pas recommandé par SAP de conserver SAP AnyDB exécuté à partir de l'infrastructure d'un site local et de se connecter à SAP NetWeaver exécuté à partir de l'infrastructure d'un site dans le cloud. Pour IBM Power Virtual Servers, cette répartition de la hiérarchisation du système SAP n'est pas prise en charge.

Considérations relatives à la topologie du réseau

En fonction du nombre et de la configuration des systèmes SAP combinés à l'agencement des flux réseau entre ces systèmes pour des raisons de sécurité ou de performance, la topologie du réseau sera sensiblement différente. La conception de cette topologie reflète les exigences de l'entreprise pour la sécurité, les performances, le coût, la flexibilité et la connectivité.

A l'aide de l'application métier ERP (Enterprise Resource Planning), par exemple, un système SAP hébergeant l'instance de production qui utilise l'approche SAP System Tiering à l'aide de la haute disponibilité de SAP NetWeaver et SAP HANA :

• SAP NetWeaver, il y a au moins quatre hôtes au lieu d'un :

  • Services centraux (ASCS)
  • Serveur d'applications principal (PAS), également appelé Instance centrale (CI)
  • Instance de serveur de réplication de mise en file d'attente (ERS)
  • Serveur d'applications supplémentaire (SAA)

• SAP HANA, il y a au moins 2 hôtes (peut-être 3) au lieu d'un :

  • Nœud principal SAP HANA (à l'aide de la réplication du système SAP HANA)
  • SAP Nœud de reprise secondaire HANA (à l'aide de la réplication du système SAP HANA)
  • Nœud de reprise en ligne de reprise après incident SAP HANA (à l'aide de la réplication du système SAP HANA)

• Voici un système SAP dans le paysage SAP. Un paysage SAP peut utiliser :

  • Une piste, 5 systèmes SAP (Sandbox > Development > Testing > Staging > Production)
  • Deux pistes, 5 systèmes SAP (Sandbox > New Feature Development + Maintenance Development > New feature testing + Maintenance testing > Staging > Production)

Par conséquent, pour un paysage SAP, 30 à 50 instances de SAP, réparties sur 10 à 50 serveurs hôtes (physiques ou virtualisés) peuvent être nécessaires. Cela était le cas avant que d'autres applications métier ne soient ajoutées pour des opérations métier, des secteurs d'activité ou des fonctions géographiques spécifiques.

La taille des paysages SAP a un impact direct sur la topologie du réseau.

Généralement, bien que cela varie d'un cas à l'autre, les réseaux suivants sont requis pour répondre aux scénarios et aux performances requis par l'entreprise qui utilise les applications métier SAP :

• Réseau interne pour la communication entre plusieurs instances dans un paysage SAP avec différentes approches de hiérarchisation du système SAP
• Réseau pour les transferts de gestion et de stockage des systèmes de base de données
• Réseau utilisé en production

Toutefois, dans le scénario le plus simple, un seul réseau privé peut répondre à tous les objectifs. Cela dépend des besoins de l'entreprise.

Considérations relatives à la consommation des réseaux

La communication traditionnelle en réseau des charges de travail de SAP est relativement faible, avec un trafic réseau de moins de 100 Mio par jour possible, comme par exemple :

• Transactions utilisateur de SAPGUI ; pour Windows, pour Java (utilisé avec macOS ou Linux)
• Transactions utilisateur à partir de SAP WebGUI
• Transactions utilisateur avec applications SAP Web Dynpro à partir de SAP NetWeaver Business Client (NWBC)
• Appel de fonction distante SAP (RFC SAP) entre SAP et les systèmes non SAP
• SAP iDOC entrant/sortant entre les systèmes SAP et non SAP avec des tiers (par exemple, banques, fournisseurs)

Cependant, les communications réseau de la charge de travail SAP sont beaucoup plus importantes et consomment beaucoup plus de trafic réseau, notamment :

• Bibliothèques et thèmes de préinstallation SAPUI5 pour SAP Fiori Launchpad et Apps
  • 10 Mio - 25 Mio (estimation) par nouvelle session qui est chargée à partir de SAP Web Assistant (également connu sous le nom XRay), ces bibliothèques de préinstallation sont alors mises en cache par le navigateur. Une fois mises en cache, les bibliothèques peuvent être utilisées dans n'importe quel nouvel onglet du navigateur, même après le redémarrage du navigateur ou la déconnexion de SAP Fiori ; jusqu'à ce que le cache du navigateur soit effacé
  • 20 Kio - 500 Kio (estimation) pour chaque nouvelle application Fiori qui est chargée dans la session
• SAP HANA System Replication (HSR) Sync ou Async, diffusion en streaming de gigaoctets de données par mois du nœud primaire au nœud secondaire (ou tertiaire)

Avec l'augmentation du trafic des logiciels SAP de nouvelle conception, il est possible de dépasser largement le volume de trafic réseau observé lors de l'utilisation antérieure du SAP.

Il est important de concevoir vos applications SAP de manière à utiliser le backbone privé IBM Cloud pour ces transferts de données, car il n'y a pas de frais d'entrée/sortie, alors que l'utilisation sur le réseau Internet public entraîne des frais de sortie.

Vous devez estimer la quantité de données transférées. Au cours des premières étapes de la mise en œuvre du projet, cela peut s'avérer difficile. Toutefois, au moins une estimation de l'ordre de grandeur devrait être effectuée.

Considérations relatives aux performances du débit des réseaux

SAP recommande généralement un débit réseau de 10 Gbit/s (redondant) pour le trafic entre ses serveurs d'applications et les bases de données SAP HANA, ainsi que pour les autres clients SAP HANA, tels que SAP Business Intelligence.

Pour les déploiements de SAP NetWeaver utilisant SAP AnyDB avec stockage local, même pour les configurations à trois niveaux, les réseaux de 1 Gbit/s sont généralement suffisants.

Considérations relatives aux performances de temps d'attente des réseaux

Pour vos opérations métier et les systèmes ne dépendant pas de SAP, vous pouvez exiger que certains indicateurs clés de performance (KPI) de temps d'attente soient respectés. Ces indicateurs doivent tenir compte de l'emplacement de vos hôtes et du test de temps d'attente en utilisant le réseau backbone privé IBM Cloud.

Le test de temps d'attente à l'aide de la mesure RTT (Round Trip Time) est nécessaire lors de la conception de la haute disponibilité (HA) et de la reprise après incident (DR) pour SAP HANA.

Si une reprise en ligne à haute disponibilité (HA) est conçue dans un emplacement à site unique, dans presque tous les cas, il sera possible de répondre aux exigences de réplication du système SAP HANA.

Cependant, si vous concevez une haute disponibilité pour SAP HANA sur plusieurs sites dans une région, ou si vous concevez une reprise après incident sur plusieurs régions, le temps d'attente qui utilise la mesure RTT (Round Trip Time) doit être soigneusement testé et pris en compte.

En effet, IBM Cloud cherche à assurer une haute disponibilité de la plateforme, en utilisant des sites géographiquement dispersés avec une tolérance aux pannes (par exemple, différentes évaluations des risques). Plus d'informations disponibles sur Comment l' IBM Cloud garantit une haute disponibilité et une redondance.

En particulier, pour VPC Infrastructure, les zones de disponibilité sont géographiquement dispersées dans la région. Pour la plupart des charges de travail, cette conception offre plus de redondance dans la région. Toutefois, la réplication du système SAP HANA nécessite un temps d'attente réseau faible. Il peut donc être difficile de respecter la mesure nécessaire du RTT (Round Trip Time) en raison des limites physiques actuelles du transfert de données du câblage du point de vue de la physique (à savoir, la vitesse de la lumière sur un câble à fibre optique).

Considérations relatives à la sécurité des ports des réseaux

Les informations suivantes sont un bref résumé du portail d'aide d' SAP, intitulé « TCP/IP Ports of All SAP Products », qui fournit un exemple des considérations nécessaires à la sécurité de vos systèmes d' SAP s et de l'ensemble de votre infrastructure informatique sur IBM Cloud.

Selon les applications techniques SAP utilisées et les scénarios métier envisagés, différents hôtes nécessitent l'ouverture de ports. Traditionnellement, on utilise des groupes de ports de pare-feu combinés à des règles de pare-feu. Vous pouvez également utiliser des règles de pare-feu individuelles par hôte, bien que cela devienne souvent ingérable.

Le tableau ci-dessous comprend certains des principaux ports à utiliser avec les systèmes SAP qui utilisent SAP NetWeaver et SAP HANA, qui doivent être corrigés, en fonction du numéro d'instance de l'application technique SAP ; les numéros d'instance 00, 01, 02 sont les valeurs par défaut des diverses applications techniques SAP et se présenteront sous des modèles différents (ces modèles sont indiqués avec des code blocks mis en évidence) :

Considérations relatives à la sécurité de la séparation du trafic sur les réseaux

Vous pouvez séparer différents types de trafic réseau dans votre paysage, soit en raison de restrictions de sécurité, soit à cause de considérations de débit.

La séparation des réseaux est utile pour les cas d'utilisation de charge de travail SAP suivants :

• Plusieurs serveurs qui échangent des données
  • Systèmes SAP dans une architecture logique à trois niveaux, où les instances de base de données SAP et d'applications SAP sont sur des hôtes différents.
• Plusieurs systèmes SAP qui échangent de grandes quantités de données
  • Les serveurs de base de données, qui ont besoin d'un faible temps d'attente de réseau et d'un débit réseau élevé pour le stockage par blocs/fichiers en réseau, doivent donc éviter les pare-feu. Toutefois, la base de données doit encore être protégée pour d'autres systèmes et réseaux.

Pour utiliser efficacement la ségrégation des réseaux, l'interconnectivité doit être autorisée dans des conditions spécifiques.