Informe técnico sobre la migración del adaptador de puerto de canal y del procesador de interfaz de canal

Introducción

El Procesador de interfaz de canal y los Adaptadores de puerto de canal se utilizan ampliamente para la conexión de red a las principales tramas IBM (y compatibles con plug) y para proporcionar servicios como la conversión TN3270 y la descarga TCP/IP. Dado que Cisco ha anunciado el fin de venta de estos productos, es posible que los usuarios de este equipo deseen comenzar a planificar soluciones alternativas, y este documento proporciona orientación para hacerlo.

Para empezar, es importante señalar que no hay necesidad de cambiar inmediatamente. Hay tiempo suficiente para considerar las opciones disponibles para sustituir las funciones del CIP y del CPA y para ejecutar una estrategia de migración que se adapte mejor a su situación. Se trata de productos maduros que se han probado sobre el terreno en miles de instalaciones de clientes, que abarcan decenas de miles de variaciones y que actualmente admiten a millones de usuarios finales en redes de producción. El soporte para este equipo permanecerá disponible hasta el año 2011.Esperamos que para la mayoría de los clientes, los cambios en su red de Data Center central se deban y se deban a factores distintos del final del servicio de los productos de canal de mainframe de Cisco.

En la última década, se han producido grandes cambios en la dirección del diseño de las redes de mainframe. Los proveedores de mainframe de IBM compatibles con Plug han salido del mercado, lo que permite un único enfoque unificado para la conexión de redes físicas de las redes principales. El HPR SNA ha reemplazado el énfasis en la tecnología de subárea de SNA tradicional, especialmente para aprovechar la capacidad de HPR/IP y de nodo de red de sucursal. Al mismo tiempo, IBM ha cambiado drásticamente su enfoque de las redes en el mainframe, adoptando un modelo de sistemas abiertos que mantiene el mismo nivel de disponibilidad sin precedentes que requiere el papel fundamental del mainframe en la empresa. Los adaptadores de sistemas abiertos Ethernet (OSA) con QDIO y optimizados para la gestión de paquetes IP, proporcionan una ruta mucho más eficaz que los canales ESCON para mover datos de la red al mainframe. A continuación, esta base se combina con las direcciones IP virtuales (VIPA), los protocolos de routing dinámico y las funciones de calidad de servicio, para proporcionar una base completa para las redes IP de alta disponibilidad y alto rendimiento.

En la mayoría de los casos, un nuevo diseño que se traslada de CIP y CPA a OSA incluye un switch inteligente de capa 3 como el Catalyst 6000 con soporte de redistribución y protocolo de ruteo sólido y la capacidad de soportar una gama de módulos de servicio.

Routing de datagramas IP: utilización de CLAW o CMPC+

Esta sección proporciona información sobre la función de ruteo de datagramas IP de los productos CIP y CPA.

Descripción de la Función

El ruteo de paquetes IP a las tramas principales fue la primera función que implementaron los CIP de Cisco, y los protocolos de canal CLAW y CMPC+ de Cisco representan los protocolos de canal primero y último implementados en CIP y CPA. También representan la funcionalidad que se reemplaza más fácilmente, ya que la función de IP Routing es compatible con todos los routers de Cisco y switches de capa 3, y la IP por su naturaleza es independiente de las consideraciones de medios físicos.

Alternativas sugeridas

Como se muestra en los diagramas anteriores, el diseño del Data Center puede simplificarse al utilizar interfaces OSA directamente conectadas a la capa de agregación en un Data Center. En cualquier escenario, para proporcionar la máxima disponibilidad, se debe ejecutar un protocolo de ruteo dinámico en el switch o el router directamente conectado al mainframe. Las diferencias significativas son que la agregación de rutas IP es la función principal de los switches de capa de agregación y están diseñados para realizar el switching de capa 3 de velocidad de cable y servir como punto de control para la redistribución de rutas IP.

Este nuevo diseño elimina el equipo que podría incurrir en costes de mantenimiento y funcionamiento, representa posibles puntos de fallo e introduce una latencia adicional.

Suponiendo que las interfaces OSA sean de la variedad Ethernet de 100 Mb y estén configuradas para funcionar en modo QDIO, deben proporcionar un rendimiento similar, o ligeramente mejor, para los datagramas IP que los CIP o CPA configurados de forma óptima (CMPC+ o CLAW PACKED), puerto por puerto. Obviamente, para Ethernet de 1000 Gb, existe el potencial de obtener importantes ganancias de rendimiento con el diseño OSA.

SNA - Bridging LLC - usando CSNA

Esta sección proporciona información sobre la función Cisco SNA de los productos CIP y CPA.

Descripción de la Función

La función CSNA proporciona conexión en puente del tráfico SNA LLC a través de un canal de mainframe. Debido a la variedad de formas en que el tráfico SNA se entrega a CSNA, las soluciones totales son generalmente más complejas que las asociadas con el ruteo IP. Puede haber cualquier combinación de máquinas SNA conectadas a LAN locales, DLSw+ que suministran tráfico SNA desde ubicaciones remotas y SNA Switching Services (SNASw) que enrutan tráfico SNA mediante APPN. Los CIP y los CPA que ejecutan CSNA también son probablemente uno de los pocos lugares restantes en una red donde se implementa la tecnología de Token Ring, y una migración de CSNA también debería incluir el paso del Token Ring a Ethernet

Una instalación CIP o CPA para SNA puede incluir cualquiera de los siguientes elementos.

Alternativas sugeridas

Conversión óptima, SNASw utilizada en routers de sucursales

La solución más simple y completa es convertir el tráfico SNA de capa 2 existente para utilizar IP en la capa 3 para el transporte, conectándolo a un router SNASw. Si esto se realiza junto a las máquinas SNA de capa 2, limita el dominio SNA de capa 2 a pequeños segmentos de la LAN y elimina la necesidad de conectar este tráfico a través de una WAN con DLSw o entre las LAN.

Conversión a SNASw con DLSw+ en routers de sucursales

Una solución alternativa, en la que no es posible instalar SNASw en los routers remotos, es utilizar DLSw+ para llevar el tráfico SNA al Data Center y, a continuación, pasarlo a SNASw para convertirlo en EE. Aunque esto todavía presenta tráfico SNA de capa 2 en el Data Center, si las funciones DLSw+ y SNASw se ejecutan en el mismo router, el SNA de capa 2 sólo estará en una conexión dentro de esos routers. El tráfico que llega de la WAN y va al sistema central será IP.

El LLC SNA se puenteó a través de la capa de acceso al OSA en el modo LCS

Hay algunos casos que requieren conectividad directa de capa 2 entre los dispositivos SNA y el mainframe, y donde el OSA-E basado en IP no es útil. Uno de estos casos puede ser el de que sólo hay máquinas SNA locales y éstas requieren conexiones de ancho de banda relativamente altas al mainframe. Un segundo caso es el host de subárea para alojar el tráfico que no puede pasar a través de SNASw y convertirse en tráfico EE. Claramente, este es el caso especialmente para SNI u otro tráfico que se envía a través de un OSA al NCP basado en el controlador de comunicaciones para Linux (CCL). Debe consultar la documentación de IBM apropiada con respecto a la configuración y administración de interfaces OSA configuradas para manejar LLC/SNA, o CDLC para CCL. Para obtener el máximo rendimiento y control, debe intentar colocar todas estas máquinas SNA en uno o un pequeño número de clústeres de capa 2 dentro de la capa de acceso de la red del Data Center. Los dispositivos conectados a Token Ring presentan desafíos únicos, ya que no toda la infraestructura del Data Center admite el archivo adjunto de Token Ring, y es muy poco probable que la adición de switches para Token Ring se justifique en este momento. Sugerimos que los dispositivos Token Ring se conecten directamente a un router de la sucursal y que se realice el bridging de traducción en ese router. En el entorno Ethernet se puede proporcionar una forma de disponibilidad redundante mediante uno de dos métodos. En el punto en que el dispositivo SNA se conecta a la red, se puede utilizar una dirección MAC Ethernet duplicada en una sola LAN, con una de las direcciones suprimidas hasta que sea necesario mediante HSRP. De manera alternativa, se pueden utilizar direcciones MAC Ethernet duplicadas en el extremo host de la conexión, asegurándose de que estas direcciones existan en LANs separadas y que algún tipo de árbol de expansión impida que ambas aparezcan en una LAN común.

Procesamiento del servidor TN3270

Esta sección proporciona información sobre la función TN3270 Server Protocol de los productos CIP y CPA.

Descripción de la Función

El servidor TN3270 es un servidor de seguridad industrial capaz de prestar un servicio fiable a miles de sesiones simultáneas de 3270. Su ubicación, como parte integral de la infraestructura de red, proporciona flexibilidad de diseño para lograr una disponibilidad sin precedentes.

Alternativas sugeridas

Sugerimos que la única manera de lograr una escalabilidad y disponibilidad similares es colocar la función TN3270 Server directamente en el mainframe. Esto proporciona un entorno altamente fiable, y con múltiples interfaces y routing dinámico en el mainframe, disponibilidad continua de la red. Esto también tiene la ventaja de colocar una mayor complejidad del SNA y su conversión a TN3270 en un único lugar, donde la habilidad para administrarlo puede estar más fácilmente disponible. IBM ofrece dos ofertas de programas TN3270 Server basadas en mainframe. El primero es Communication Server (CS) para z/OS, incluido como parte del software z/OS. El otro es parte de la oferta "Communications Server for Linux".

Descarga TCP/IP

Esta sección proporciona información sobre la función TCP/IP Offload de los productos CIP y CPA.

Descripción de la Función

La descarga TCP/IP proporciona un medio alternativo para mover los datos de carga útil transportados en datagramas IP a través de un canal de mainframe. El objetivo es manejar algunas de las tareas de mantenimiento rutinarias del protocolo TCP/IP en el dispositivo de descarga, reduciendo así la cantidad de trabajo requerido en el mainframe. Si bien la descarga TCP/IP se utilizó en el pasado de forma generalizada, las mejoras en la eficiencia en el manejo de mainframe de TCP/IP han eliminado en gran medida las razones para su uso.

Alternativas sugeridas

Para los sistemas MVS que utilizan el programa TCP/IP de IBM, ya se ha tomado la decisión de trasladarse de TCP/IP Offload, ya que el soporte para descarga terminó en la versión 2.4 de MVS.

Algunos clientes utilizan el producto Unicenter TCPaccess Communications Server de CA para aprovechar la descarga TCP/IP. En un momento anterior, esta configuración representaba el modelo de rendimiento óptimo. Este producto también puede formar parte de una solución que proporciona acceso TCP a redes X.25 a través de X.25 sobre TCP (XOT). La ruta de migración más simple es probablemente cambiar solamente las partes de la configuración que utilizan la función TCP/IP Offload para utilizar en su lugar los adaptadores OSA-Express. Para aquellos que utilizan otras funciones de Unicenter TCPaccess Communications Server, esto tiene la ventaja de no perturbar esas funciones. Un enfoque más agresivo sería considerar cambiar el acceso a los datagramas IP para utilizar la pila suministrada por IBM y, si se están utilizando funciones XOT, investigar si se podrían habilitar a través de la interfaz de API NPSI al NCP basado en CCL.

El sistema operativo TPF ha proporcionado una pila TCP completa, OSA-Express y VIPA desde 2000. Originalmente, PJ27333 lo habilitó en PUT 13 para TPF versión 4.1, e IBM informa de una mejora drástica del rendimiento y la utilización de los recursos con este modelo. Aunque el modelo de servicio TPF no impide que los clientes continúen utilizando la descarga TCP/IP, esperamos que las ventajas y la facilidad de migración a la compatibilidad con la pila nativa TCP/IP sean lo suficientemente convincentes como para que los clientes de TPF deseen cambiar a este modelo antes de que finalice el soporte de descarga TCP/IP.

Summary

Los CIP y CPA instalados actualmente seguirán siendo soluciones viables de conectividad y TN3270 Server durante varios años más. Además, esperamos que una cierta cantidad de CIP y CPA siga estando disponible a partir de existencias renovadas. Existen soluciones prácticas de reemplazo para cada una de las funciones que actualmente realizan el CIP y el CPA. Como paso inicial, debe realizar un inventario de las características y cantidades del uso actual de CIP y CPA. A continuación, desarrolle un plan para pasar, en los próximos años, a una sólida infraestructura de switch inteligente de capa 3 de alta velocidad para proporcionar un acceso de alta disponibilidad y alta velocidad al mainframe.

Información Relacionada

• Procesadores de interfaz de canal de Cisco
• Cisco Port Adapters