D’un îlot réseau à un composant de l’infrastructure d’entreprise
IBM Z n’est plus présenté comme un îlot réseau spécialisé. La stratégie actuelle d’IBM consiste à intégrer le mainframe à l’infrastructure hybride globale, en s’appuyant sur Ethernet et IP tout en développant des communications à haut débit et à faible latence.
« La stratégie consiste à faire d’IBM Z un élément profondément intégré à l’infrastructure hybride globale du client », explique Andrew Crimmins d’IBM à Network World.
Cette intégration élargit le périmètre opérationnel des équipes réseau. Une charge de travail mainframe peut dépendre de connexions Ethernet et IP, mais aussi de protocoles de stockage, de systèmes distribués, d’environnements cloud et d’infrastructures d’IA. Le fabric doit donc être documenté et validé comme un service de bout en bout, et non comme une simple collection de ports isolés.
Une architecture DPU sur puce qui transforme le modèle d’E/S
IBM a intégré une architecture DPU, ou Data Processing Unit, à l’architecture de processeur Telum II qui équipe les systèmes IBM Z actuels. Selon IBM, cette DPU comprend :
Quatre clusters de traitement
Huit microcontrôleurs programmables par cluster
Un accélérateur d’E/S coordonnant les clusters et les sous-systèmes d’entrées-sorties
Un gestionnaire de requêtes dédié aux charges d’E/S importantes
IBM déportait déjà certaines fonctions d’E/S au moyen d’ASIC personnalisés installés sur les cartes d’entrées-sorties. Le transfert de ces fonctions vers la puce du processeur vise à préserver les cycles des cœurs du mainframe tout en améliorant les performances, la latence et le débit.
Cette conception supprime également de nombreux ASIC externes et réduit la consommation électrique. Pour des protocoles tels que Fibre Channel et FICON, une densité de ports plus élevée peut diminuer le nombre de cartes et de tiroirs d’E/S, voire, dans certaines configurations, le nombre de baies ou de châssis IBM Z.
Sur le plan opérationnel, un renouvellement matériel ne modifie donc pas uniquement la puissance de calcul. Il peut également transformer la densité des ports, le câblage physique, l’emplacement des E/S, la consommation électrique et les chemins que les outils de supervision et de gestion de configuration doivent suivre.
Une connectivité 100 GbE à deux ports
IBM a également ajouté un adaptateur 100 GbE pour IBM Z et IBM LinuxONE. Celui-ci comporte deux ports 100 GbE dotés d’optiques QSFP SR, directement raccordés au tiroir du Central Processor Complex. Cette architecture évite le recours à des tiroirs d’E/S externes pour cette connectivité réseau à haut débit.
IBM présente LinuxONE comme une plateforme permettant de consolider des centaines, voire des milliers de machines virtuelles Linux. Cette consolidation peut réduire l’empreinte d’un parc de serveurs distribués, mais elle concentre aussi la connectivité et les dépendances des charges de travail autour d’un nombre plus restreint de systèmes.
La présence d’un adaptateur 100 GbE définit la capacité de l’interface ; elle ne démontre pas, à elle seule, les performances applicatives de bout en bout.
Les commutateurs en amont, les optiques, l’adressage, la configuration, les profils de trafic et chaque segment intermédiaire continuent de contribuer au résultat final.
Conseils pratiques pour suivre le fabric
1. Inventorier le chemin complet
L’inventaire ne doit pas s’arrêter à l’adaptateur du mainframe. Pour chaque service critique, il convient de documenter :
L’interface IBM Z ou LinuxONE et son débit configuré
Le type de port et d’optique, notamment QSFP SR le cas échéant
Les équipements et interfaces réseau adjacents
L’adressage IP et les segments réseau concernés
Les connexions Fibre Channel ou FICON orientées stockage
Les dépendances envers les systèmes distribués, le cloud et les infrastructures d’IA
L’inventaire matériel devient ainsi une cartographie du fabric orientée services.
2. Documenter RDMA selon l’implémentation utilisée
La stratégie d’IBM prévoit d’élargir les options réseau reposant sur RDMA. Les équipes ne doivent toutefois pas considérer « RDMA » comme une configuration universelle. Il faut consigner les emplacements où RDMA est activé, les terminaux concernés et les paramètres exigés par l’implémentation retenue.
Les preuves de configuration doivent être rattachées au chemin réellement utilisé. Cette approche évite de supposer qu’une fonction RDMA est active ou homogène sur l’ensemble des segments simplement parce que la plateforme la prend en charge.
3. Établir une référence avant et après chaque changement
Les performances doivent être mesurées avant toute modification des adaptateurs, de la disposition des ports ou de l’architecture d’E/S, puis avec les mêmes tests après le changement. Un plan de validation utile doit examiner :
Le débit sous une charge représentative
La latence et ses variations
Les erreurs et rejets sur les interfaces
L’utilisation des liens et les indicateurs de congestion
Le comportement lors d’un basculement ou d’un changement de chemin
Les résultats applicatifs pour les charges critiques
Les tests doivent être reproductibles et leurs conditions d’exécution conservées. Sans cette rigueur, un lien plus rapide pourrait se voir attribuer à tort des améliorations dues à une variation de charge, de routage ou de configuration.
4. Corréler les configurations et les performances
Un écart de performance devient plus facile à diagnostiquer lorsque l’équipe peut répondre à trois questions :
Qu’est-ce qui a changé ?
Quels équipements et chemins ont été affectés ?
Le comportement mesuré a-t-il changé au même moment ?
Des configurations versionnées et une topologie exacte fournissent le contexte nécessaire pour distinguer une limite de capacité d’une modification de configuration involontaire.
5. Revalider après chaque phase de consolidation
Lorsque de nombreuses machines virtuelles Linux ou plusieurs services critiques sont consolidés sur un nombre réduit de systèmes, les dépendances se concentrent. Après chaque phase, il faut vérifier à nouveau l’adressage, la capacité des liaisons montantes, les chemins redondants, la cohérence des configurations et le comportement en cas de panne, sans attendre la fin de la migration.
La place de ConnectMyAssets
ConnectMyAssets fournit une couche de gestion sur site et indépendante des constructeurs pour le réseau multivendeur qui entoure les environnements IBM Z et LinuxONE.
Dynamic CMDB consigne les actifs réseau et leurs relations afin de maintenir un inventaire de référence lorsque l’organisation des E/S ou la densité des ports évolue.
Topology présente les chemins reliant les interfaces orientées mainframe à la commutation, au stockage et aux autres composants d’infrastructure.
IPAM conserve le contexte d’adressage nécessaire aux connexions Ethernet et IP.
Backup & History versionne les configurations des équipements, facilite les comparaisons avant-après et permet une restauration en un clic lorsqu’elle est prise en charge.
Compliance Engine contrôle les configurations selon les règles internes et des référentiels tels que NIS2, ISO 27001, PCI, CISA et NIST.
Automation permet de standardiser les opérations répétitives de configuration et de validation sur les actifs réseau pris en charge.
End-of-Life tracking aide à repérer les composants vieillissants autour d’un fabric mainframe modernisé.
Cette approche ne remplace pas les tests de performance. Elle fournit l’inventaire, la topologie, l’historique des configurations et les preuves de conformité nécessaires pour interpréter les mesures et les rendre utiles aux opérations.
Ce qu’il faut retenir
L’évolution du réseau IBM Z associe l’intégration standard Ethernet/IP, des options fondées sur RDMA, l’accélération des E/S sur puce, une densité de connexion accrue et des adaptateurs 100 GbE à deux ports. La réponse opérationnelle ne peut pas se limiter à consigner l’installation d’une interface plus rapide.
Les équipes réseau doivent cartographier chaque chemin de bout en bout, conserver l’historique des configurations, établir des références reproductibles et revalider les performances après toute évolution du matériel, de la topologie ou de la consolidation. Cette discipline permet de convertir une capacité réseau supplémentaire en amélioration mesurable du service.
Source : Network World
