White paper sulla migrazione di Channel Interface Processor e Channel Port Adapter
Sommario
Introduzione
Gli adattatori Channel Interface Processor e Channel Port sono ampiamente utilizzati per il collegamento di rete ai mainframe IBM (e compatibili con plug) e per fornire servizi quali la conversione TN3270 e l'offload TCP/IP. Poiché Cisco ha annunciato la fine della vendita di questi prodotti, gli utenti di queste apparecchiature potrebbero voler iniziare a pianificare soluzioni alternative. In questo documento viene fornita una guida al riguardo.
Per cominciare, è importante notare che non c'è bisogno di cambiare immediatamente. C'è il tempo sufficiente per considerare le opzioni disponibili per sostituire le funzioni del CIP e del CPA e per attuare una strategia di migrazione che sia la più adatta alla tua situazione. Si tratta di prodotti maturi che sono stati testati sul campo in migliaia di installazioni presso i clienti, che comprendono decine di migliaia di variazioni e attualmente supportano milioni di utenti finali nelle reti di produzione. Il supporto per queste apparecchiature rimarrà disponibile nel 2011.Ci aspettiamo che per la maggior parte dei clienti, le modifiche alla rete del centro dati mainframe debbano e siano determinate da fattori diversi dall'eventuale fine del servizio dei prodotti del canale mainframe Cisco.
Negli ultimi dieci anni ci sono stati enormi cambiamenti nella direzione di progettazione delle reti mainframe. I fornitori di sistemi mainframe IBM compatibili con la tecnologia "plug-in" hanno abbandonato il mercato, consentendo un approccio unificato al collegamento fisico di rete dei mainframe. L'enfasi sulla tradizionale tecnologia delle sottoaree SNA è stata superata dalla SNA HPR, specialmente per sfruttare le funzionalità HPR/IP e dei nodi di rete delle filiali. Allo stesso tempo, IBM ha cambiato radicalmente il proprio approccio alla rete sul mainframe, adottando un modello di sistemi aperti che mantiene lo stesso livello senza precedenti di disponibilità richiesto dal ruolo critico del mainframe nell'azienda. Ethernet Open Systems Adapters (OSA) con QDIO e ottimizzato per la gestione dei pacchetti IP, offre un percorso molto più efficiente rispetto ai canali ESCON per spostare i dati dalla rete al mainframe. Questa base viene quindi combinata con gli indirizzi IP virtuali (VIPA, Virtual IP Address), i protocolli di routing dinamico e le funzionalità QoS (Quality of Service), per fornire una base completa per una rete IP ad alta disponibilità e prestazioni elevate.
Nella maggior parte dei casi, un nuovo progetto che prevede il passaggio da CIP e CPA a OSA include uno switch intelligente di layer 3, ad esempio Catalyst 6000, con un protocollo di routing e un supporto di ridistribuzione affidabili e la capacità di supportare una vasta gamma di moduli servizi.
Routing di datagrammi IP - con CLAW o CMPC+
In questa sezione vengono fornite informazioni sulla funzionalità di routing del datagramma IP dei prodotti CIP e CPA.
Descrizione delle funzionalità
Il routing dei pacchetti IP ai mainframe è stata la prima funzione implementata dai Cisco CIP, e i protocolli di canale Cisco CLAW e CMPC+ rappresentano sia il primo che l'ultimo protocollo di canale implementati sul CIP e sul CPA. Rappresentano inoltre la funzionalità più facilmente sostituibile, in quanto la funzione di routing IP è supportata in tutti i router Cisco e gli switch di livello 3 e il protocollo IP per sua natura è indipendente da considerazioni relative ai supporti fisici.
Alternative consigliate
Come illustrato nei diagrammi precedenti, la progettazione del centro dati può essere semplificata quando si utilizzano interfacce OSA direttamente collegate al livello di aggregazione in un centro dati. In entrambi gli scenari, per garantire la massima disponibilità, è necessario eseguire un protocollo di routing dinamico sullo switch o sul router direttamente collegato al mainframe. Le differenze significative sono che l'aggregazione della route IP è la funzione principale degli switch del livello di aggregazione e sono progettati per eseguire la commutazione del livello 3 della wire rate e fungere da punto di controllo per la ridistribuzione della route IP.
Il nuovo design elimina le apparecchiature che potrebbero sostenere costi di manutenzione e funzionamento, rappresenta potenziali punti di errore e introduce una latenza aggiuntiva.
Supponendo che le interfacce OSA siano della serie Ethernet da 100 MB e siano configurate per funzionare in modalità QDIO, dovrebbero fornire un throughput simile, o leggermente migliore, per i datagrammi IP rispetto ai CIP (CMPC+ o CLAW PACKED) configurati in modo ottimale, porta per porta. Ovviamente, per Ethernet a 1000 Gb è possibile ottenere significativi miglioramenti delle prestazioni grazie al design OSA.
SNA - bridging LLC - con CSNA
Questa sezione fornisce informazioni sulla funzionalità SNA Cisco dei prodotti CIP e CPA.
Descrizione delle funzionalità
La funzione CSNA fornisce il bridging del traffico SNA LLC attraverso un canale mainframe. A causa della varietà di modi in cui il traffico SNA viene consegnato alla CSNA, le soluzioni totali sono generalmente più complesse di quelle associate al routing IP. Può esistere una combinazione di macchine SNA locali collegate alla LAN, DLSw+ che distribuisce il traffico SNA da postazioni remote e il traffico SNA Switching Services (SNASw) che instrada il traffico SNA tramite APPN. I CIP e CPA con CSNA probabilmente saranno anche uno dei pochi luoghi rimanenti in una rete in cui è installata la tecnologia token ring. La migrazione da CSNA dovrebbe includere anche il passaggio da token ring a Ethernet
Un'installazione CIP o CPA per SNA può includere uno dei seguenti elementi.
Alternative consigliate
Conversione ottimale, SNASw utilizzato nei router delle filiali
La soluzione più semplice e completa è convertire il traffico SNA di layer 2 esistente in modo da usare l'IP di layer 3 per il trasporto, collegandolo a un router SNASw. Se questa operazione viene eseguita accanto ai computer SNA di layer 2, il dominio SNA di layer 2 viene limitato ai piccoli segmenti della LAN e non è necessario eseguire il bridging di questo traffico su una WAN con DLSw o tra LAN.
Conversione in SNASw utilizzando DLSw+ nei router delle diramazioni
Una soluzione alternativa, in cui non è possibile installare SNASw sui router remoti, consiste nell'utilizzare DLSw+ per portare il traffico SNA nel centro dati e quindi passarlo a SNASw per la conversione in EE. Anche se questo presenta ancora il traffico SNA di layer 2 nel centro dati, se le funzionalità DLSw+ e SNASw vengono entrambe eseguite nello stesso router, la SNA di layer 2 si troverà solo su una connessione all'interno di tali router. Il traffico in arrivo dalla WAN e diretto al mainframe sarà IP.
Collegamento tra SNA LLC tramite il livello di accesso a OSA in modalità LCS
In alcuni casi è necessaria una connettività diretta di layer 2 tra i dispositivi SNA e il mainframe, mentre OSA-E basato su IP non è utile. Uno di questi casi può essere quello in cui esistono solo macchine SNA locali e queste richiedono connessioni con larghezza di banda relativamente elevata al mainframe. Un secondo caso è rappresentato dal traffico tra la sottoarea host e l'host, che non può essere passato attraverso SNASw e trasformato in traffico EE. Chiaramente questo è il caso, in particolare per il traffico SNI o di altro tipo inviato tramite OSA al controller di comunicazione per Linux (CCL) basato su NCP. È necessario consultare la documentazione IBM appropriata relativa alla configurazione e alla gestione delle interfacce OSA configurate per gestire LLC/SNA o CDLC per CCL. Per ottimizzare le prestazioni e il controllo, è consigliabile posizionare tutte queste macchine SNA in uno o un numero ridotto di cluster di livello 2 all'interno del livello di accesso della rete del centro dati. I dispositivi collegati a Token Ring presentano problematiche specifiche, in quanto non tutte le infrastrutture dei centri dati supportano il collegamento Token Ring e l'aggiunta di switch per Token Ring al momento è molto improbabile. Si consiglia di collegare i dispositivi Token Ring direttamente a un router di succursale e di eseguire il bridging di conversione in tale router. Una forma di disponibilità ridondante può essere fornita nell'ambiente Ethernet mediante uno di due metodi. Nel punto in cui il dispositivo SNA si collega alla rete, è possibile usare un indirizzo MAC Ethernet duplicato su una singola LAN, sopprimendo uno degli indirizzi fino a quando necessario usando HSRP. In alternativa, è possibile usare indirizzi MAC Ethernet duplicati sull'estremità host della connessione, assicurandosi che questi indirizzi esistano su LAN separate e che alcune forme di Spanning Tree impediscano ad entrambi di apparire su una LAN comune.
TN3270 Elaborazione server
In questa sezione vengono fornite informazioni sulla funzionalità del protocollo server TN3270 dei prodotti CIP e CPA.
Descrizione delle funzionalità
Il server TN3270 è un server di eccellenza industriale, in grado di servire in modo affidabile migliaia di sessioni simultanee 3270. Il suo posizionamento, come parte integrante dell'infrastruttura di rete, offre flessibilità di progettazione per ottenere una disponibilità senza precedenti.
Alternative consigliate
L'unico modo per ottenere una scalabilità e una disponibilità simili è posizionare la funzione server TN3270 direttamente sul mainframe. Ciò fornisce un ambiente altamente affidabile, con più interfacce e routing dinamico sul mainframe, disponibilità continua della rete. Questo ha anche il vantaggio di porre una maggiore complessità della SNA e la sua conversione a TN3270 in un unico luogo, dove la capacità di amministrarla può essere più facilmente disponibile. IBM offre due diverse offerte di programmi server TN3270 basati su mainframe. Il primo è il server di comunicazione (CS) per z/OS, incluso come parte del software z/OS. L'altro fa parte dell'offerta "Communications Server for Linux".
Offload TCP/IP
In questa sezione vengono fornite informazioni sulla funzionalità di offload TCP/IP dei prodotti CIP e CPA.
Descrizione delle funzionalità
L'offload TCP/IP costituisce un metodo alternativo per spostare i dati del payload trasportati nei datagrammi IP su un canale mainframe. L'obiettivo è gestire alcune delle attività di routine di manutenzione del protocollo TCP/IP sul dispositivo offload, riducendo in tal modo la quantità di lavoro richiesto sul mainframe. Mentre l'offload TCP/IP era un tempo ampiamente utilizzato, i miglioramenti dell'efficienza nella gestione dei mainframe di TCP/IP hanno in gran parte eliminato le ragioni per il suo utilizzo.
Alternative consigliate
Per i sistemi MVS che utilizzano il programma IBM TCP/IP, la decisione se passare da TCP/IP Offload è già stata presa, in quanto il supporto per offload terminava alla versione MVS 2.4.
Alcuni clienti utilizzano il prodotto Unicenter TCPaccess Communications Server da CA per trarre vantaggio da TCP/IP Offload. In un momento precedente, questa configurazione rappresentava il modello di prestazioni ottimale. Questo prodotto può anche fare parte di una soluzione che fornisce accesso TCP alle reti X.25 tramite X.25 su TCP (XOT). Il percorso di migrazione più semplice consiste probabilmente nel modificare solo le parti della configurazione che utilizzano la funzione di offload TCP/IP per utilizzare le schede OSA-Express. Per coloro che utilizzano altre funzionalità di Unicenter TCPaccess Communications Server, questo ha il vantaggio di non disturbare queste funzionalità. Un approccio più aggressivo sarebbe quello di prendere in considerazione la modifica dell'accesso al datagramma IP per utilizzare lo stack fornito da IBM e, se ci sono funzioni XOT in uso, studiare se queste possano essere abilitate tramite l'interfaccia API NPSI al NCP basato su CCL.
Il sistema operativo TPF fornisce uno stack TCP completo, OSA-Express e VIPA dal 2000. È stato originariamente abilitato da PJ27333 in PUT 13 per TPF versione 4.1 e IBM segnala un notevole miglioramento delle prestazioni e dell'utilizzo delle risorse grazie a questo modello. Sebbene il modello del servizio TCP/IP non impedisca ai clienti di continuare a utilizzare l'offload TCP/IP, ci aspettiamo che i vantaggi e la facilità di passaggio al supporto dello stack nativo TCP/IP siano sufficientemente convincenti da spingere i clienti TPF a passare a questo modello prima della fine del supporto dell'offload TCP/IP.
Riepilogo
I CIP e i CPA attualmente installati continueranno a garantire la connettività e le soluzioni server TN3270 per molti altri anni. Oltre a ciò, ci aspettiamo che una certa quantità di PIC e CPA continui ad essere disponibile a partire da scorte ricondizionate. Esistono soluzioni pratiche sostitutive per ciascuna delle funzioni attualmente svolte dal CIP e dalla CPA. Come fase iniziale, è necessario eseguire l'inventario delle caratteristiche e delle quantità dell'uso corrente di CIC e CPA. Sviluppare quindi un piano per passare, nei prossimi anni, a una solida infrastruttura di switch intelligente di livello tre ad alta velocità per fornire accesso ad alta disponibilità e velocità al mainframe.
Feedback