De Kanaalinterfaceprocessor en de Kanaalpoortadapters worden uitgebreid gebruikt voor netwerkbijlage aan IBM (en stekker-compatibele) hoofdframes en om services te leveren zoals TN3270-conversie en TCP/IP-offload. Aangezien Cisco het End-of-sale van deze producten heeft aangekondigd, willen gebruikers van deze apparatuur misschien beginnen met het plannen van alternatieve oplossingen, en dit document biedt u een advies bij het doen van dit probleem.
Om te beginnen is het belangrijk op te merken dat er geen noodzaak is om onmiddellijk te veranderen. Er is voldoende tijd om na te gaan welke opties beschikbaar zijn ter vervanging van de functies van het CIP en de CPA en om een migratiestrategie uit te voeren die het best op uw situatie is afgestemd. Dit zijn volgroeide producten die in duizenden installaties van klanten zijn getest, die tienduizenden variaties omvatten en op dit moment miljoenen eindgebruikers in productienetwerken ondersteunen. Ondersteuning voor deze apparatuur zal beschikbaar blijven in 2011. We verwachten dat voor de meeste klanten veranderingen in hun mainframe-datacenternetwerk veroorzaakt zullen worden door andere factoren dan het uiteindelijke einde van de service van de Cisco mainframe-kanaalproducten.
De laatste tien jaar zijn er enorme veranderingen geweest in de ontwerprichting van mainframenetwerken. Plug-compatibele IBM mainframe vendors hebben de markt verlaten en voorzien in één enkele benadering voor fysieke netwerkbijlage van mainframes. De nadruk op traditionele SNA-subgebiedtechnologie is door HPR SNA overtrokken, vooral om voordeel te halen uit de mogelijkheden van HPR/IP en Branch Network Node. Tegelijkertijd heeft IBM hun aanpak van netwerkvorming op de mainframe drastisch veranderd, door een open-systeemmodel te omarmen dat hetzelfde ongekende niveau van beschikbaarheid handhaaft dat vereist is door de cruciale rol van de mainframe in de onderneming. Ethernet Open Systems Adapters (OSA) met QDIO en geoptimaliseerd voor IP-pakketverwerking, bieden een veel efficiënter pad dan ESCON-kanalen om gegevens van het netwerk naar het mainframe te verplaatsen. Deze stichting wordt dan gecombineerd met Virtuele IP-adressen (VIPA), dynamische routingprotocollen en Quality-of-Service functies om een volledige basis te bieden voor hoge beschikbaarheid en hoogwaardige IP-netwerken.
In de meeste gevallen omvat een nieuw ontwerp dat van CIP en CPA naar OSA beweegt een intelligente Layer 3 switch zoals Catalyst 6000 met een sterk routingprotocol en herverdelingsondersteuning en de mogelijkheid om een reeks servicemodules te ondersteunen.
Deze sectie verschaft informatie over de IP datagram-routefunctie van de CIP- en CPA-producten.
Het routeren van IP-pakketten naar mainframes was de eerste functie die door Cisco CIP’s moest worden geïmplementeerd en de CLAW- en CMPC+-kanaalprotocollen van Cisco vertegenwoordigen zowel de eerste als de laatste kanaalprotocollen die op CIP en CPA zijn geïmplementeerd. Ze vertegenwoordigen ook de functionaliteit die het makkelijkst vervangen wordt, omdat de IP-routingfunctie in alle routers en Layer 3-switches van Cisco wordt ondersteund, en IP door de aard ervan is onafhankelijk van fysieke media-overwegingen.
Zoals de bovenstaande diagrammen aangeven, kan het ontwerp van het datacenter worden vereenvoudigd wanneer OSA-interfaces worden gebruikt die rechtstreeks op de aggregatielaag in een datacenter zijn aangesloten. In beide scenario's, om maximale beschikbaarheid te bieden, moet een dynamisch routingprotocol worden uitgevoerd op de switch of router die direct op de mainframe is aangesloten. De significante verschillen zijn dat IP-routeaggregatie de primaire functie van de switches van de aggregatielaag is, en zij worden ontworpen om de omschakeling van de draadsnelheidslaag 3 uit te voeren, en dienen als controlepunt voor IP-routeherverdeling.
Dit nieuwe ontwerp verwijdert apparatuur die kosten voor onderhoud en gebruik kan veroorzaken, vertegenwoordigt potentiële defecten en introduceert extra latentie.
Aangenomen dat de OSA interfaces van de variëteit 100Mb Ethernet zijn en geconfigureerd om in QDIO-modus te werken, moeten ze vergelijkbare, of iets betere doorvoersnelheid voor IP-datagrammen bieden dan optimaal geconfigureerd (CMPC+ of CLAW PACKED) CIP’s of CPA’s, op poortbasis. Uiteraard is er voor 100 Gbps Ethernet het potentieel voor een aanzienlijke prestatiewinst met het OSA-ontwerp.
Deze sectie verschaft informatie over de Cisco SNA optie van CIP en CPA producten.
De eigenschappen van CSNA verstrekken het overbruggen van het verkeer van LLC SNA door een mainframe kanaal. Vanwege de verscheidenheid aan manieren waarop SNA verkeer aan CSNA wordt geleverd, zijn de totale oplossingen over het algemeen complexer dan die verbonden met IP routing. Er kan een mix zijn van lokale LAN-aangesloten SNA-machines, DLSw+ die SNA-verkeer vanaf externe locaties leveren en SNA Switching Services (SNASw) die SNA-verkeer verzenden met APPN. CIP's en CPA's die CSNA uitvoeren zijn waarschijnlijk ook een van de weinige resterende plekken in een netwerk waar token-ringtechnologie wordt geïmplementeerd en een migratie van CSNA zou ook moeten omvatten, van token-ring naar Ethernet
Een CIP- of CPA-installatie voor SNA kan een van de volgende elementen omvatten:
Optimale conversie, SNASw gebruikt in filiaalrouters
De eenvoudigste en meest complete oplossing is om het bestaande Layer 2 SNA-verkeer om IP op Layer 3 te gebruiken voor transport, door het aan te sluiten op een SNASw-router. Als dit naast de Layer 2 SNA-machines gebeurt, beperkt het het Layer 2 SNA-domein tot kleine segmenten van het LAN en verwijdert u de noodzaak om dit verkeer via een WAN met DLSw of tussen LAN’s te overbruggen.
Conversie naar SNASw met DLSw+ in filiaalrouters
Een alternatieve oplossing, waarbij het niet mogelijk is om SNASw op de externe routers te installeren, is DLSw+ te gebruiken om het SNA-verkeer naar het datacenter te brengen en het dan door te geven aan SNASw voor conversie naar EE. Terwijl dit nog laag 2 SNA verkeer in het datacenter voorstelt, als de eigenschappen DLSw+ en SNASw allebei in de zelfde router lopen, zal laag 2 SNA slechts op een verbinding binnen die routers zijn. Het verkeer dat van WAN komt en naar de mainframe gaat is IP.
LLC SNA overbrugd door toegangslaag naar OSA in LCS-modus
Er zijn bepaalde gevallen die directe Layer 2 connectiviteit tussen de SNA apparaten en het mainframe vereisen en waar IP gebaseerd OSA-E niet nuttig is. Eén zo'n geval kan zijn waar alleen lokale SNA-machines zijn en deze vereisen een relatief hoge bandbreedte-verbindingen naar de mainframe. Een tweede geval is subgebied host om verkeer te organiseren dat niet via SNASw kan worden doorgegeven en in EE-verkeer kan worden omgezet. Dit is duidelijk het geval, vooral voor SNI of ander verkeer dat door een OSA naar de Communication Controller voor Linux (CCL) gebaseerde NCP wordt verzonden. U dient de juiste IBM-documentatie te raadplegen betreffende het configureren en beheren van OSA-interfaces die zijn geconfigureerd om LLC/SNA of CDLC voor CCL te verwerken. Voor maximale prestaties en controle zou u moeten proberen om al deze SNA machines in één, of een klein aantal, laag 2 clusters binnen de toegangslaag van het netwerk van het datacenter te plaatsen. Token Ring-apparaten bieden unieke uitdagingen, omdat niet alle datacenterinfrastructuur Token Ring-bijlage ondersteunt en het toevoegen van switches voor Token Ring op dit moment zeer waarschijnlijk niet te rechtvaardigen is. We stellen voor om Token Ring-apparaten rechtstreeks aan een brancheruter te bevestigen en om vertaalde overbrugging op die router uit te voeren. Een vorm van redundante beschikbaarheid kan in de Ethernet-omgeving door een van beide methoden worden geboden. Op het punt dat het SNA apparaat aan het netwerk bevestigd is, kan het dubbele adres van MAC van Ethernet op één enkele LAN worden gebruikt, met één van het adres dat tot nodig wordt onderdrukt het gebruik van HSRP. In plaats hiervan kunnen twee dubbele Ethernet MAC-adressen worden gebruikt aan het host-uiteinde van de verbinding, door ervoor te zorgen dat deze adressen op afzonderlijke LAN’s bestaan en dat een bepaalde vorm van het overspannen van bomen voorkomt dat ze beide op een gemeenschappelijk LAN verschijnen.
Deze sectie verschaft informatie over de TN3270-serverprotocol van de CIP- en CPA-producten.
De TN3270-server is een server met industriële sterkte die duizenden gelijktijdige 3270 sessies op betrouwbare wijze kan bedienen. De plaatsing ervan, als integraal onderdeel van de netwerkinfrastructuur, biedt ontwerpflexibiliteit om ongekende beschikbaarheid te bereiken.
We stellen voor dat de enige manier om een vergelijkbare schaalbaarheid en beschikbaarheid te bereiken is de TN3270-serverfunctie direct op de mainframe te plaatsen. Dit biedt een zeer betrouwbaar milieu, en met meerdere interfaces en dynamische routing op het mainframe, continue netwerkbeschikbaarheid. Dit heeft ook het voordeel om meer van de complexiteit van SNA en zijn omzetting in TN3270 in één enkele plaats te plaatsen, waar de vaardigheid om het te beheren makkelijker beschikbaar kan zijn. Er zijn twee verschillende mainframe-gebaseerde TN3270-serverprogramma's beschikbaar bij IBM. Het eerste is Communication Server (CS) voor z/OS, onderdeel van de z/OS-software. Het andere deel maakt deel uit van het aanbod "Communications Server voor Linux".
Deze sectie verschaft informatie over de TCP/IP offload optie van CIP en CPA producten.
TCP/IP-offload biedt een alternatief middel om de payload-gegevens die in IP-datagrammen zijn opgeslagen, over een mainframekanaal te verplaatsen. Het doel is een aantal van de routinematige huishoudelijke taken van het TCP/IP-protocol op het offload-apparaat af te handelen, waardoor de hoeveelheid werk op de mainframe wordt verminderd. Terwijl TCP/IP Offload ooit breed werd gebruikt, hebben de efficiëntieverbeteringen in de mainframabehandeling van TCP/IP de redenen voor het gebruik ervan grotendeels geëlimineerd.
Voor MVS-systemen die het IBM TCP/IP-programma gebruiken, is de beslissing of u van TCP/IP-offload moet overgaan al genomen, als ondersteuning voor offload beëindigd op MVS versie 2.4.
Sommige klanten gebruiken het product Unicenter TCP/Access Communications Server van CA om voordeel te halen uit TCP/IP offload. Op een vroeger tijdstip representeerde deze configuratie het optimale prestatiemodel. Dit product kan ook deel uitmaken van een oplossing die TCP-toegang tot X.25-netwerken via X.25 over TCP (XOT) biedt. Het eenvoudigste migratiepad is waarschijnlijk alleen de delen van de configuratie te wijzigen die de TCP/IP-offload-functie gebruiken om OSA-Express-adapters te gebruiken. Voor degenen die andere functies van de Unicenter TCP-toegangsserver gebruiken, heeft dit het voordeel die functies niet te verstoren. Een agressievere benadering zou zijn om te overwegen de IP-datagramtoegang te wijzigen om de IBM meegeleverde stack te gebruiken, en als er XOT-functies worden gebruikt, om te onderzoeken of deze via de NPSI API-interface naar de op CCL gebaseerde NCP kunnen worden ingeschakeld.
Het TPF-besturingssysteem heeft sinds 2000 een volledige TCP-stack, OSA-Express en VIPA geleverd. Het werd oorspronkelijk door PJ27333 in PUT 13 voor TPF versie 4.1 ingeschakeld en IBM rapporteert met dit model een drastische verbetering van de prestaties en de benutting van hulpbronnen. Terwijl het TPF-servicemodel klanten niet belet om TCP/IP-offload te blijven gebruiken, verwachten we dat de voordelen van en het gemak bij het verplaatsen naar de TCP/IP-ondersteuning dwingend genoeg is dat de klanten van TPF aan dit model willen veranderen voorafgaand aan het eind van TCP/IP-offload-ondersteuning.
Op dit moment geïnstalleerde CIP's en CPA's zullen levensvatbare connectiviteit en TN3270-serveroplossingen voor nog enkele jaren blijven. Afgezien daarvan verwachten we dat er nog een deel van de CIP's en CPA's beschikbaar zal blijven uit gerenoveerde voorraden. Er zijn praktische vervangingsoplossingen voor elk van de functies die momenteel door het CIP en de CPA worden uitgevoerd. In eerste instantie moet u de kenmerken en hoeveelheden van uw huidige CIP- en CPA-gebruik inventariseren. Daarna een plan ontwikkelen om in de komende paar jaar over te stappen op een robuuste hoge-snelheids intelligente switch infrastructuur om zeer beschikbare en snelle toegang tot het mainframe te bieden.