Livre blanc sur la migration du processeur d'interface à attachement canal et de l'adaptateur de port canal

Introduction

Le processeur d'interface de canal et les adaptateurs de port de canal sont largement utilisés pour la connexion réseau aux mainframes IBM (et compatibles avec les prises) et pour fournir des services tels que la conversion TN3270 et le déchargement TCP/IP. Puisque Cisco a annoncé la fin de commercialisation de ces produits, les utilisateurs de cet équipement peuvent commencer à planifier des solutions alternatives. Le présent document fournit des conseils pour ce faire.

Pour commencer, il est important de noter qu'il n'est pas nécessaire de changer immédiatement. Il y a suffisamment de temps pour examiner les options disponibles pour remplacer les fonctions du CIP et du CPA et pour mettre en oeuvre une stratégie de migration adaptée à votre situation. Il s'agit de produits matures qui ont été testés sur le terrain dans des milliers d'installations de clients, couvrant des dizaines de milliers de variations, et qui prennent actuellement en charge des millions d'utilisateurs finaux dans les réseaux de production. La prise en charge de cet équipement restera disponible jusqu'en 2011.Pour la plupart des clients, les modifications apportées à leur réseau de centre de données mainframe devraient et seront motivées par des facteurs autres que la fin de service des produits de canal mainframe Cisco.

Au cours de la dernière décennie, d'énormes changements ont été apportés à la conception des réseaux mainframe. Les fournisseurs de mainframe IBM compatibles Plug-and-Play ont quitté le marché, permettant une approche unifiée unique de la connexion réseau physique des mainframes. L'accent mis sur la technologie de sous-zone SNA traditionnelle a été supplanté par le SNA HPR, en particulier pour tirer parti de la fonctionnalité HPR/IP et Branch Network Node. Dans le même temps, IBM a radicalement modifié son approche de la mise en réseau sur le mainframe, en adoptant un modèle de systèmes ouverts qui maintient le même niveau de disponibilité inégalé requis par le rôle critique du mainframe dans l'entreprise. Les adaptateurs OSA (Ethernet Open Systems Adapters) avec QDIO, optimisés pour la gestion des paquets IP, fournissent un chemin beaucoup plus efficace que les canaux ESCON pour déplacer les données du réseau vers le mainframe. Cette fondation est ensuite associée aux adresses IP virtuelles (VIPA), aux protocoles de routage dynamique et aux fonctionnalités de qualité de service, afin de fournir une base complète pour une haute disponibilité et des réseaux IP hautes performances.

Dans la plupart des cas, une nouvelle conception qui passe du CIP et de la CPA à l'OSA inclut un commutateur de couche 3 intelligent, tel que le Catalyst 6000, avec un protocole de routage et une prise en charge de la redistribution, ainsi que la capacité de prendre en charge une gamme de modules de service.

Routage de datagramme IP - avec CLAW ou CMPC+

Cette section fournit des informations sur la fonctionnalité de routage de datagramme IP des produits CIP et CPA.

Description de la fonctionnalité

Le routage des paquets IP vers les mainframes a été la première fonction à être mise en oeuvre par les CIP Cisco, et les protocoles de canaux CLAW et CMPC+ de Cisco représentent à la fois le premier et le dernier protocole de canal mis en oeuvre sur les CIP et CPA. Ils représentent également la fonctionnalité la plus facilement remplaçable, car la fonction de routage IP est prise en charge par tous les routeurs et commutateurs de couche 3 Cisco, et IP par sa nature est indépendante des considérations de support physique.

Solutions suggérées

Comme le montrent les diagrammes ci-dessus, la conception du data center peut être simplifiée lors de l'utilisation d'interfaces OSA directement connectées à la couche d'agrégation dans un data center. Dans les deux cas, pour fournir une disponibilité maximale, un protocole de routage dynamique doit être exécuté sur le commutateur ou le routeur directement connecté au mainframe. Les différences significatives sont que l'agrégation de routes IP est la fonction principale des commutateurs de couche d'agrégation, et qu'ils sont conçus pour exécuter la commutation de couche de débit filaire 3 et servent de point de contrôle pour la redistribution de routes IP.

Cette nouvelle conception supprime les équipements susceptibles d'entraîner des coûts de maintenance et d'exploitation, représente des points de défaillance potentiels et introduit une latence supplémentaire.

En supposant que les interfaces OSA sont de la variété Ethernet 100 Mo et configurées pour fonctionner en mode QDIO, elles doivent fournir un débit similaire, ou légèrement supérieur, pour les datagrammes IP par rapport aux CIP ou CPA configurés de manière optimale (CMPC+ ou CLAW PACKED), port par port. Évidemment, pour la technologie Ethernet 1000 Gb, la conception OSA offre des gains de performances significatifs.

SNA - Pontage LLC - utilisation de CSNA

Cette section fournit des informations sur la fonctionnalité SNA de Cisco des produits CIP et CPA.

Description de la fonctionnalité

La fonctionnalité CSNA assure le pontage du trafic LLC SNA via un canal mainframe. En raison de la diversité des modes de livraison du trafic SNA à CSNA, les solutions globales sont généralement plus complexes que celles associées au routage IP. Il peut y avoir toute combinaison de machines SNA LAN locales, de DLSw+ fournissant le trafic SNA à partir de sites distants et de SNAS (SNA Switching Services) acheminant le trafic SNA à l'aide d'APPN. Les CIP et les CPA exécutant CSNA sont également susceptibles d’être l’un des rares emplacements restants dans un réseau où la technologie Token Ring est déployée, et une migration de CSNA doit également inclure le passage d’un anneau Token Ring à Ethernet

Une installation CIP ou CPA pour SNA peut inclure l'un des éléments suivants.

Solutions suggérées

Conversion optimale, SNASw utilisé dans les routeurs des filiales

La solution la plus simple et la plus complète consiste à convertir le trafic SNA de couche 2 existant pour utiliser IP de couche 3 pour le transport, en le connectant à un routeur SNASw. Si cette opération est effectuée à côté des machines SNA de couche 2, elle limite le domaine SNA de couche 2 à de petits segments du réseau local et supprime tout besoin de relier ce trafic à un réseau étendu avec DLSw ou entre des réseaux locaux.

Conversion en SNASw à l'aide de DLSw+ dans les routeurs des filiales

Une autre solution, où il n'est pas possible d'installer SNASw sur les routeurs distants, consiste à utiliser DLSw+ pour amener le trafic SNA dans le data center, puis à le transmettre au SNASw pour conversion en EE. Bien que ceci présente toujours le trafic SNA de couche 2 dans le data center, si les fonctions DLSw+ et SNASw sont toutes deux exécutées sur le même routeur, le SNA de couche 2 ne sera connecté qu'à l'intérieur de ces routeurs. Le trafic provenant du WAN et se dirigeant vers le mainframe sera IP.

LLC SNA ponté par la couche d'accès à OSA en mode LCS

Dans certains cas, la connectivité directe de couche 2 entre les périphériques SNA et le mainframe est requise et l'OSA-E basée sur IP n'est pas utile. Il peut s’agir, par exemple, de machines SNA locales qui nécessitent des connexions à bande passante relativement élevée vers le mainframe. Un deuxième cas est le trafic hôte de sous-zone vers hôte qui ne peut pas être transmis via SNASw et transformé en trafic EE. Il est clair que c'est le cas en particulier pour le SNI ou tout autre trafic qui est envoyé via un OSA au contrôleur de communication pour Linux (CCL) basé sur NCP. Consultez la documentation IBM appropriée concernant la configuration et la gestion des interfaces OSA configurées pour gérer LLC/SNA ou CDLC pour CCL. Pour optimiser les performances et le contrôle, vous devez essayer de placer toutes ces machines SNA dans un ou plusieurs clusters de couche 2 au sein de la couche d'accès du réseau du data center. Les périphériques Token Ring associés présentent des défis uniques, car toutes les infrastructures de data center ne prennent pas en charge la connexion Token Ring. Par ailleurs, l'ajout de commutateurs pour Token Ring est très peu susceptible d'être justifié pour le moment. Nous suggérons que les périphériques Token Ring soient connectés directement à un routeur de filiale et que le pontage de traduction soit effectué sur ce routeur. Une forme de disponibilité redondante peut être fournie dans l’environnement Ethernet par l’une ou l’autre des deux méthodes. Au point où le périphérique SNA se connecte au réseau, une adresse MAC Ethernet dupliquée peut être utilisée sur un réseau local unique, l’une des adresses étant supprimée jusqu’à ce que cela soit nécessaire à l’aide de HSRP. Vous pouvez également utiliser des adresses MAC Ethernet dupliquées à l’extrémité hôte de la connexion, en vous assurant que ces adresses existent sur des réseaux locaux distincts et qu’une forme quelconque de Spanning Tree les empêche d’apparaître sur un réseau local commun.

Traitement du serveur TN3270

Cette section fournit des informations sur la fonctionnalité de protocole de serveur TN3270 des produits CIP et CPA.

Description de la fonctionnalité

Le serveur TN3270 est un serveur de puissance industrielle capable de gérer de manière fiable des milliers de sessions simultanées de 3270. Son emplacement, en tant que partie intégrante de l'infrastructure réseau, offre une souplesse de conception permettant d'obtenir une disponibilité inégalée.

Solutions suggérées

Nous suggérons que la seule façon d'obtenir une évolutivité et une disponibilité similaires est de placer la fonction de serveur TN3270 directement sur le mainframe. Cela fournit un environnement hautement fiable, avec plusieurs interfaces et un routage dynamique sur le mainframe, une disponibilité continue du réseau. Cela présente également l'avantage de placer une plus grande partie de la complexité du SNA et de sa conversion en TN3270 en un seul endroit, où la compétence pour l'administrer peut être plus facilement disponible. Il existe deux offres de programmes TN3270 Server basés sur mainframe disponibles auprès d'IBM. Le premier est Communication Server (CS) pour z/OS, inclus dans le logiciel z/OS. L'autre fait partie de l'offre « Communications Server for Linux ”.

Déchargement TCP/IP

Cette section fournit des informations sur la fonctionnalité de déchargement TCP/IP des produits CIP et CPA.

Description de la fonctionnalité

Le déchargement TCP/IP offre un autre moyen de déplacer les données de charge utile transportées dans les datagrammes IP sur un canal mainframe. L'objectif est de gérer certaines tâches de maintenance courantes du protocole TCP/IP sur le périphérique de déchargement, réduisant ainsi le volume de travail requis sur le mainframe. Alors que le délestage TCP/IP était autrefois largement utilisé, les améliorations apportées à la gestion du mainframe de TCP/IP ont largement éliminé les raisons de son utilisation.

Solutions suggérées

Pour les systèmes MVS utilisant le programme IBM TCP/IP, la décision de quitter le déchargement TCP/IP a déjà été prise, car la prise en charge du déchargement s'est terminée à la version 2.4 de MVS.

Certains clients utilisent le produit Unicenter TCPaccess Communications Server de CA pour tirer parti du déchargement TCP/IP. Plus tôt, cette configuration représentait le modèle de performance optimal. Ce produit peut également faire partie d'une solution qui fournit un accès TCP aux réseaux X.25 via X.25 sur TCP (XOT). Le chemin de migration le plus simple consiste probablement à modifier uniquement les parties de la configuration qui utilisent la fonction de déchargement TCP/IP pour utiliser les adaptateurs OSA-Express à la place. Pour ceux qui utilisent d'autres fonctionnalités d'Unicenter TCPaccess Communications Server, cela a l'avantage de ne pas perturber ces fonctionnalités. Une approche plus agressive consisterait à envisager de modifier l'accès au datagramme IP pour utiliser la pile fournie par IBM et, s'il y a des fonctionnalités XOT utilisées, à déterminer si celles-ci pourraient être activées via l'interface API NPSI vers le NCP basé sur CCL.

Le système d'exploitation TPF fournit une pile TCP complète, OSA-Express et VIPA depuis 2000. Il a été initialement activé par PJ2733 dans PUT 13 pour TPF version 4.1, et IBM signale une amélioration considérable des performances et de l'utilisation des ressources à l'aide de ce modèle. Bien que le modèle de service TPF n'empêche pas les clients de continuer à utiliser le délestage TCP/IP, nous nous attendons à ce que les avantages de la prise en charge de la pile native TCP/IP et la facilité de déplacement vers cette prise en charge soient suffisamment convaincants pour que les clients TPF souhaitent passer à ce modèle avant la fin de la prise en charge du délestage TCP/IP.

Résumé

Les CIP et les CPA actuellement installés resteront une connectivité viable et les solutions de serveur TN3270 pour plusieurs années supplémentaires. En outre, nous nous attendons à ce qu'une certaine quantité de CIP et d'ACP continuent d'être disponibles à partir de stocks remis à neuf. Il existe des solutions de remplacement pratiques pour chacune des fonctions actuellement exercées par le CIP et le CPA. Dans un premier temps, vous devez répertorier les fonctionnalités et les quantités de votre CIP et de votre CPA actuels. Ensuite, élaborez un plan pour passer, au cours des prochaines années, à une infrastructure de commutation intelligente de couche 3 à haut débit robuste afin de fournir un accès haut débit et hautement disponible au mainframe.

Informations connexes

• Processeurs d'interface de canal Cisco
• Cartes de ports Cisco