Whitepaper: Migration von Channel-Schnittstellenprozessoren und Channel-Port-Adaptern
Inhalt
Einführung
Der Channel-Schnittstellenprozessor und die Channel-Port-Adapter werden häufig für Netzwerkverbindungen mit IBM-Mainframes (und Plug-kompatiblen) und für die Bereitstellung von Services wie TN3270-Konvertierung und TCP/IP-Offload verwendet. Da Cisco das Ende des Vertriebszeitraums für diese Produkte angekündigt hat, möchten Benutzer dieser Geräte möglicherweise mit der Planung alternativer Lösungen beginnen. Dieses Whitepaper bietet Hilfestellung dabei.
Zunächst ist zu beachten, dass es nicht notwendig ist, sich sofort zu ändern. Es ist ausreichend Zeit, die Optionen zu prüfen, die für den Austausch der Funktionen des CIP und des CPA verfügbar sind, und eine Migrationsstrategie durchzuführen, die Ihrer Situation am besten entspricht. Hierbei handelt es sich um ausgereifte Produkte, die in Tausenden von Kundeninstallationen getestet wurden, Zehntausende von Varianten umfassen und derzeit Millionen von Endbenutzern in Produktionsnetzwerken unterstützen. Der Support für diese Geräte wird bis 2011 verfügbar bleiben.Wir gehen davon aus, dass die meisten Kunden Änderungen am Mainframe-Rechenzentrumsnetzwerk vornehmen werden, die sich auf andere Faktoren als das endgültige Ende des Service für die Cisco Mainframe-Channel-Produkte beziehen sollten und werden.
In den letzten zehn Jahren hat sich die Designrichtung von Mainframe-Netzwerken enorm verändert. Steckkompatible IBM-Mainframe-Anbieter haben den Markt verlassen und ermöglichen so einen einheitlichen Ansatz für die physische Anbindung von Mainframes. Der Schwerpunkt auf die herkömmliche SNA-Subzone-Technologie wurde von HPR SNA abgelöst, insbesondere um die HPR/IP- und Zweigstellennetzwerkknoten-Funktionen zu nutzen. Gleichzeitig hat IBM seinen Netzwerkansatz auf Großrechnern drastisch verändert und ein offenes Systemmodell eingeführt, das die gleiche unübertroffene Verfügbarkeit bietet, die auch für Großrechner erforderlich ist. Ethernet Open Systems Adapters (OSA) mit QDIO und Optimierung für die IP-Paketverarbeitung bieten einen wesentlich effizienteren Pfad als ESCON-Kanäle, um Daten vom Netzwerk zum Mainframe zu übertragen. Diese Grundlage wird dann mit Virtual IP Addresses (VIPA), dynamischen Routing-Protokollen und Quality of Service-Funktionen kombiniert, um eine vollständige Grundlage für hohe Verfügbarkeit und IP-Netzwerke mit hoher Leistung bereitzustellen.
In den meisten Fällen umfasst ein neues Design, das von CIP und CPA auf OSA umgestellt wird, einen intelligenten Layer-3-Switch wie den Catalyst 6000 mit starkem Routing-Protokoll, Unterstützung für die Umverteilung und Unterstützung einer Reihe von Servicemodule.
IP-Datagram-Routing - mit CLAW oder CMPC+
Dieser Abschnitt enthält Informationen zur IP-Datagram-Routingfunktion für CIP- und CPA-Produkte.
Funktionsbeschreibung
Das Routing von IP-Paketen zu Mainframes war die erste Funktion, die von Cisco CIPs implementiert wurde. CLAW- und CMPC+-Kanalprotokolle von Cisco stellen sowohl das erste als auch das letzte im CIP und CPA implementierte Channel-Protokoll dar. Sie stellen auch die Funktionen dar, die am einfachsten ersetzt werden können, da die IP-Routing-Funktion von allen Cisco Routern und Layer-3-Switches unterstützt wird und IP von Natur aus unabhängig von Überlegungen zu physischen Medien ist.
Empfohlene Alternativen
Wie die obigen Diagramme zeigen, kann das Rechenzentrumsdesign vereinfacht werden, wenn OSA-Schnittstellen verwendet werden, die direkt mit dem Aggregation Layer in einem Rechenzentrum verbunden sind. In beiden Szenarien sollte ein dynamisches Routing-Protokoll auf dem Switch oder Router ausgeführt werden, der direkt mit dem Mainframe verbunden ist, um maximale Verfügbarkeit zu gewährleisten. Die wesentlichen Unterschiede bestehen darin, dass die IP-Routen-Aggregation die primäre Funktion der Switches auf dem Aggregations-Layer darstellt und für Layer-3-Switching mit Leitungsgeschwindigkeit konzipiert ist. Sie dienen als Kontrollpunkt für die Neuverteilung von IP-Routen.
Durch dieses neue Design fallen Wartungs- und Betriebskosten für Geräte weg, es handelt sich um potenzielle Fehlerpunkte, und es treten zusätzliche Latenzen auf.
Wenn die OSA-Schnittstellen der 100-Mbit-Ethernet-Variante entsprechen und für den Betrieb im QDIO-Modus konfiguriert sind, sollten sie einen ähnlichen oder etwas besseren Durchsatz für IP-Datagramme bereitstellen als optimal konfigurierte (CMPC+ oder CLAW PACKED) CIPs oder CPAs auf Port-Basis. Für 1000-Gbit-Ethernet besteht das Potenzial für erhebliche Leistungssteigerungen durch das OSA-Design.
SNA - LLC Bridging - Verwenden von CSNA
Dieser Abschnitt enthält Informationen zur Cisco SNA-Funktion der CIP- und CPA-Produkte.
Funktionsbeschreibung
Die CSNA-Funktion ermöglicht das Bridging von LLC-SNA-Datenverkehr über einen Mainframe-Kanal. Aufgrund der Vielzahl von Möglichkeiten, wie SNA-Datenverkehr an CSNA übermittelt wird, sind die Gesamtlösungen im Allgemeinen komplexer als die mit IP-Routing verbundenen Lösungen. Es kann eine beliebige Mischung aus lokalen LAN-angeschlossenen SNA-Systemen, DLSw+ zur Bereitstellung von SNA-Datenverkehr von Remote-Standorten und SNA Switching Services (SNASw)-Routing-SNA-Datenverkehr über APPN geben. CIPs und CPAs, auf denen CSNA ausgeführt wird, sind wahrscheinlich auch einer der wenigen verbleibenden Stellen in einem Netzwerk, in dem Token-Ring-Technologie bereitgestellt wird. Eine Migration von CSNA sollte auch den Wechsel von Token-Ring zu Ethernet umfassen.
Eine CIP- oder CPA-Installation für SNA kann eines der folgenden Elemente enthalten:
Empfohlene Alternativen
Optimale Konvertierung, in Zweigstellen-Routern verwendetes SNASw
Die einfachste und umfassendste Lösung besteht darin, den vorhandenen Layer-2-SNA-Datenverkehr durch die Verbindung mit einem SNASw-Router in die Verwendung von IP auf Layer 3 für den Transport umzuwandeln. Wenn dies in der Nähe der Layer-2-SNA-Systeme erfolgt, wird die Layer-2-SNA-Domäne auf kleine Segmente des LAN beschränkt, und es ist nicht erforderlich, diesen Datenverkehr über ein WAN mit DLSw oder zwischen LANs zu überbrücken.
Konvertierung in SNASw mit DLSw+ in Zweigstellen-Routern
Eine alternative Lösung, bei der die Installation von SNASw auf den Remote-Routern nicht möglich ist, ist die Verwendung von DLSw+, um den SNA-Datenverkehr in das Rechenzentrum zu bringen und ihn anschließend zur Umwandlung in EE an SNASw weiterzuleiten. Auch wenn auf diese Weise Layer-2-SNA-Datenverkehr im Rechenzentrum übertragen wird, sind die DLSw+- und SNASw-Funktionen beide auf demselben Router ausgeführt, wird die Layer-2-SNA nur über eine Verbindung innerhalb dieser Router bereitgestellt. Vom WAN ankommender Datenverkehr zum Mainframe ist IP.
LLC SNA im LCS-Modus durch Access Layer zu OSA überbrückt
Es gibt Fälle, in denen eine direkte Layer-2-Verbindung zwischen den SNA-Geräten und dem Mainframe erforderlich ist und in denen IP-basiertes OSA-E nicht sinnvoll ist. Ein solcher Fall kann sein, dass es nur lokale SNA-Systeme gibt, die eine relativ hohe Bandbreite für Verbindungen mit dem Mainframe benötigen. Ein zweiter Fall ist der Subarea-Host für den Datenverkehr, der nicht über SNASw weitergeleitet und in EE-Datenverkehr umgewandelt werden kann. Dies gilt insbesondere für SNI- oder anderen Datenverkehr, der über ein OSA an den Communication Controller for Linux (CCL)-basierten NCP gesendet wird. Informationen zur Konfiguration und Verwaltung von OSA-Schnittstellen, die für die Verarbeitung von LLC/SNA oder CDLC für CCL konfiguriert sind, finden Sie in der entsprechenden IBM-Dokumentation. Um maximale Leistung und Kontrolle zu erzielen, sollten Sie versuchen, alle SNA-Systeme in einem oder einer kleinen Anzahl von Layer-2-Clustern im Access Layer des Rechenzentrumsnetzwerks zu platzieren. Token Ring verbundene Geräte stellen eine besondere Herausforderung dar, da nicht alle Rechenzentrumsinfrastrukturen Token Ring-Verbindungen unterstützen. Das Hinzufügen von Switches für Token Ring ist derzeit sehr unwahrscheinlich. Wir empfehlen, Token-Ring-Geräte direkt an einen Zweigstellen-Router anzuschließen und an diesem Router eine Übersetzungsüberbrückung durchzuführen. Eine Form der redundanten Verfügbarkeit kann in der Ethernet-Umgebung auf zwei Arten bereitgestellt werden. An dem Punkt, an dem das SNA-Gerät mit dem Netzwerk verbunden ist, können in einem LAN doppelte Ethernet-MAC-Adressen verwendet werden, wobei eine der Adressen unterdrückt wird, bis sie mithilfe von HSRP erforderlich ist. Alternativ können duplizierte Ethernet-MAC-Adressen am Host-Ende der Verbindung verwendet werden, indem sichergestellt wird, dass diese Adressen in separaten LANs vorhanden sind und dass eine Form von Spanning Tree verhindert, dass beide Adressen in einem gemeinsamen LAN angezeigt werden.
TN3270 Serververarbeitung
Dieser Abschnitt enthält Informationen zur Funktion des TN3270-Serverprotokolls für CIP- und CPA-Produkte.
Funktionsbeschreibung
Der TN3270-Server ist ein leistungsstarker Industrieserver, der Tausende paralleler 3270 Sitzungen zuverlässig unterstützen kann. Seine Platzierung als integraler Bestandteil der Netzwerkinfrastruktur bietet ein flexibles Design für eine unübertroffene Verfügbarkeit.
Empfohlene Alternativen
Wir schlagen vor, dass eine vergleichbare Skalierbarkeit und Verfügbarkeit nur erreicht werden kann, wenn die TN3270-Serverfunktion direkt auf dem Mainframe platziert wird. Dadurch entsteht eine hochgradig zuverlässige Umgebung mit mehreren Schnittstellen und dynamischem Routing auf dem Mainframe, was eine kontinuierliche Netzwerkverfügbarkeit ermöglicht. Dies hat auch den Vorteil, dass die Komplexität der SNA und ihre Umwandlung in TN3270 in einen einzigen Ort, an dem die Verwaltungsfähigkeiten leichter verfügbar sein können, noch größer ist. IBM bietet zwei verschiedene Mainframe-basierte Serverprogramme an. Der erste ist Communication Server (CS) für z/OS, enthalten als Teil der z/OS Software. Das andere ist Teil des Angebots "Communications Server for Linux".
TCP/IP-Offload
Dieser Abschnitt enthält Informationen zur TCP/IP-Offload-Funktion der CIP- und CPA-Produkte.
Funktionsbeschreibung
TCP/IP-Offload bietet eine alternative Möglichkeit zum Verschieben der in IP-Datagrammen übertragenen Nutzlastdaten über einen Mainframe-Kanal. Das Ziel besteht darin, einige der routinemäßigen Verwaltungsaufgaben des TCP/IP-Protokolls auf dem Offload-Gerät zu übernehmen und so den Arbeitsaufwand auf dem Mainframe zu reduzieren. Während TCP/IP-Offload einst weit verbreitet war, konnten durch Effizienzverbesserungen bei der Verarbeitung von TCP/IP-Mainframes die Gründe für deren Verwendung weitgehend beseitigt werden.
Empfohlene Alternativen
Für MVS-Systeme, die das IBM TCP/IP-Programm verwenden, wurde bereits entschieden, ob die TCP/IP-Offload-Verarbeitung übernommen werden soll, da die Unterstützung für Offload bei MVS Version 2.4 endete.
Einige Kunden verwenden das Unicenter TCPAccess Communications Server-Produkt von CA, um die Vorteile von TCP/IP-Offload zu nutzen. Zu einem früheren Zeitpunkt stellte diese Konfiguration das optimale Leistungsmodell dar. Dieses Produkt kann auch Teil einer Lösung sein, die TCP-Zugriff auf X.25-Netzwerke über X.25 über TCP (XOT) ermöglicht. Der einfachste Migrationspfad besteht wahrscheinlich darin, nur die Teile der Konfiguration zu ändern, die die TCP/IP-Offload-Funktion verwenden, um stattdessen OSA-Express-Adapter zu verwenden. Für Benutzer, die andere Funktionen von Unicenter TCPaccess Communications Server verwenden, hat dies den Vorteil, diese Features nicht zu stören. Ein aggressiverer Ansatz wäre, eine Änderung des IP-Datagrammzugriffs zur Verwendung des von IBM bereitgestellten Stacks in Erwägung zu ziehen. Wenn XOT-Funktionen verwendet werden, sollte untersucht werden, ob diese über die NPSI API-Schnittstelle zum CCL-basierten NCP aktiviert werden können.
Das TPF-Betriebssystem stellt seit dem Jahr 2000 einen vollständigen TCP-Stack, OSA-Express und VIPA bereit. Ursprünglich wurde sie vom PJ2733 in PUT 13 für TPF Version 4.1 aktiviert, und IBM meldet unter Verwendung dieses Modells eine erheblich verbesserte Leistung und Ressourcenauslastung. Obwohl das TPF-Servicemodell Kunden nicht daran hindert, weiterhin TCP/IP-Offload zu verwenden, gehen wir davon aus, dass die Vorteile und die einfache Umstellung auf den nativen TCP/IP-Stack-Support ausreichend überzeugend sind, dass TPF-Kunden vor dem Ende der TCP/IP-Offload-Unterstützung zu diesem Modell wechseln möchten.
Zusammenfassung
Die derzeit installierten CIPs und CPAs werden noch mehrere Jahre lang funktionsfähige Konnektivität und TN3270-Serverlösungen bieten. Darüber hinaus gehen wir davon aus, dass einige VPIs und CPAs auch weiterhin aus generalüberholten Beständen erhältlich sein werden. Für jede der Funktionen, die derzeit vom CIP und CPA ausgeführt werden, gibt es praktische Ersatzlösungen. Zunächst sollten Sie die Funktionen und Mengen Ihrer aktuellen CIP- und CPA-Nutzung erfassen. Entwickeln Sie dann einen Plan für den Übergang zu einer robusten intelligenten Hochgeschwindigkeits-Layer-3-Switch-Infrastruktur, die hochverfügbaren Hochgeschwindigkeits-Zugriff auf das Mainframe bietet.
Feedback