O processador de interface de canal e os adaptadores de porta de canal são amplamente usados para conexão de rede com mainframes IBM (e compatíveis com plug) e para fornecer serviços como conversão TN3270 e descarregamento TCP/IP. Como a Cisco anunciou o fim das vendas desses produtos, os usuários desse equipamento podem querer começar a planejar soluções alternativas, e este documento fornece orientação para isso.
Para começar, é importante notar que não é necessário alterar imediatamente. Há tempo adequado para considerar as opções disponíveis para substituir as funções do CIP e do CPA e executar uma estratégia de migração mais adequada à sua situação. São produtos maduros que foram testados em campo em milhares de instalações de clientes, englobando dezenas de milhares de variações e atualmente oferecendo suporte a milhões de usuários finais em redes de produção. O suporte para esse equipamento permanecerá disponível no ano de 2011.Esperamos que, para a maioria dos clientes, as alterações na rede de data center de mainframe sejam e sejam conduzidas por fatores diferentes do fim do serviço dos produtos de canal de mainframe da Cisco.
Durante a última década, houve grandes mudanças na direção do projeto da rede de mainframe. Os fornecedores de mainframe IBM compatíveis com plug-in deixaram o mercado, permitindo uma única abordagem unificada para a conexão de rede física de mainframes. A ênfase na tecnologia de sub-área SNA tradicional foi substituída pela SNA HPR, especialmente para aproveitar os recursos HPR/IP e Nó de rede de filial. Ao mesmo tempo, a IBM mudou drasticamente sua abordagem de rede no mainframe, adotando um modelo de sistemas abertos que mantém o mesmo nível inigualável de disponibilidade exigido pela função crítica do mainframe na empresa. Os Adaptadores de Sistemas Abertos Ethernet (OSA - Ethernet Open Systems Adapters) com QDIO, e otimizados para o tratamento de pacotes IP, fornecem um caminho muito mais eficiente do que os canais ESCON para mover dados da rede para o mainframe. Essa base é então combinada com endereços IP virtuais (VIPA), protocolos de roteamento dinâmico e recursos de qualidade de serviço, para fornecer uma base completa para redes IP de alta disponibilidade e alto desempenho.
Na maioria dos casos, um novo projeto que se move do CIP e do CPA para o OSA inclui um switch de camada 3 inteligente, como o Catalyst 6000 com protocolo de roteamento forte e suporte de redistribuição, além da capacidade de suportar uma variedade de módulos de serviço.
Esta seção fornece informações sobre o recurso de roteamento de datagrama IP dos produtos CIP e CPA.
O roteamento de pacotes IP para mainframes foi a primeira função a ser implementada pelos CIPs da Cisco, e os protocolos de canal CLAW e CMPC+ da Cisco representam o primeiro e o último protocolos de canal implementados no CIP e no CPA. Eles também representam a funcionalidade mais facilmente substituída, porque a função de roteamento IP é suportada em todos os roteadores Cisco e switches de camada 3, e o IP por sua natureza é independente das considerações de mídia física.
Como mostram os diagramas acima, o projeto do data center pode ser simplificado ao usar interfaces OSA diretamente conectadas à camada de agregação em um data center. Em qualquer um dos cenários, para fornecer disponibilidade máxima, um protocolo de roteamento dinâmico deve ser executado no switch ou roteador diretamente conectado ao mainframe. As diferenças significativas são que a agregação de rotas IP é a função principal dos switches da camada de agregação, e eles são projetados para executar a comutação da camada 3 de taxa de cabo e servem como ponto de controle para a redistribuição de rotas IP.
Esse novo design remove equipamentos que podem incorrer em custos de manutenção e operação, representa pontos de falha em potencial e introduz latência adicional.
Supondo que as interfaces OSA sejam da variedade Ethernet de 100 Mb e estejam configuradas para operar no modo QDIO, elas devem fornecer um throughput semelhante, ou ligeiramente melhor, para datagramas IP do que CIPs ou CPAs configurados de forma otimizada (CMPC+ ou CLAW PACKED), porta por porta. Obviamente, para Ethernet 1000Gb, há o potencial para ganhos significativos de desempenho com o projeto da OSA.
Esta seção fornece informações sobre o recurso Cisco SNA dos produtos CIP e CPA.
O recurso CSNA fornece bridging do tráfego SNA LLC através de um canal de mainframe. Devido à variedade de maneiras em que o tráfego SNA é entregue à CSNA, o total de soluções é geralmente mais complexo do que as associadas ao roteamento IP. Pode haver qualquer combinação de máquinas SNA conectadas à LAN local, DLSw+ fornecendo tráfego SNA de locais remotos e SNA Switching Services (SNASw) roteando tráfego SNA usando APPN. CIPs e CPAs que executam CSNA também são provavelmente um dos poucos lugares restantes em uma rede onde a tecnologia token ring é implantada, e uma migração de CSNA também deve incluir a mudança de token ring para Ethernet
Uma instalação CIP ou CPA para SNA pode incluir qualquer um dos seguintes elementos.
Conversão ideal, SNASw usado em roteadores de filial
A solução mais simples e completa é converter o tráfego SNA de camada 2 existente para usar IP na camada 3 para transporte, conectando-o a um roteador SNASw. Se isso for feito junto às máquinas SNA da camada 2, ele limitará o domínio SNA da camada 2 a pequenos segmentos da LAN e removerá qualquer necessidade de ligar esse tráfego através de uma WAN com DLSw ou entre LANs.
Conversão para SNASw usando DLSw+ em roteadores de filial
Uma solução alternativa, na qual não é possível instalar o SNASw nos roteadores remotos, é usar o DLSw+ para trazer o tráfego SNA para o data center e, em seguida, transferi-lo para o SNASw para conversão em EE. Embora isso ainda apresente o tráfego SNA da camada 2 no data center, se os recursos DLSw+ e SNASw forem executados no mesmo roteador, o SNA da camada 2 estará somente em uma conexão dentro desses roteadores. O tráfego que chega da WAN e vai para o mainframe será IP.
LLC SNA ligado através da camada de acesso à OSA no modo LCS
Há alguns casos que exigem conectividade direta da camada 2 entre os dispositivos SNA e o mainframe, e nos quais o OSA-E baseado em IP não é útil. Um desses casos pode ser quando há apenas máquinas SNA locais e elas exigem conexões de largura de banda relativamente altas para o mainframe. Um segundo caso é o host da sub-área para o tráfego do host que não pode ser passado por SNASw e transformado em tráfego EE. Claramente, esse é o caso especialmente para SNI ou outro tráfego que é enviado através de um OSA para o NCP baseado no Communication Controller for Linux (CCL). Você deve consultar a documentação apropriada da IBM sobre a configuração e o gerenciamento de interfaces OSA configuradas para manipular LLC/SNA ou CDLC para CCL. Para obter o máximo de desempenho e controle, você deve tentar colocar todas essas máquinas SNA em um ou um pequeno número de clusters da camada 2 dentro da camada de acesso da rede do data center. Os dispositivos conectados à Token Ring apresentam desafios únicos, pois nem toda a infraestrutura de data center suporta a conexão Token Ring, e é muito improvável que a adição de switches para Token Ring seja justificável no momento. Sugerimos que os dispositivos Token Ring sejam conectados diretamente a um roteador de filial e que o bridging de tradução seja executado nesse roteador. Uma forma de disponibilidade redundante pode ser fornecida no ambiente Ethernet por um dos dois métodos. No ponto em que o dispositivo SNA se conecta à rede, o endereço MAC Ethernet duplicado pode ser usado em uma única LAN, com um dos endereços sendo suprimido até que seja necessário usar o HSRP. Como alternativa, os endereços MAC Ethernet duplicados podem ser usados na extremidade do host da conexão, garantindo que esses endereços existam em LANs separadas e que alguma forma de spanning tree impeça que ambos apareçam em uma LAN comum.
Esta seção fornece informações sobre o recurso de Protocolo de Servidor TN3270 dos produtos CIP e CPA.
O TN3270 Server é um servidor de força industrial, capaz de atender com segurança milhares de sessões simultâneas 3270. Sua colocação, como parte integrante da infraestrutura de rede, oferece flexibilidade de projeto para alcançar uma disponibilidade inigualável.
Sugerimos que a única maneira de alcançar escalabilidade e disponibilidade semelhantes é colocar a função do Servidor TN3270 diretamente no mainframe. Isso fornece um ambiente altamente confiável, com várias interfaces e roteamento dinâmico no mainframe, disponibilidade contínua da rede. Isso também tem a vantagem de colocar mais da complexidade do SNA e sua conversão para TN3270 em um único local, onde a habilidade de administrá-lo pode estar mais prontamente disponível. Há duas ofertas de programas TN3270 Server baseadas em mainframe disponíveis na IBM. O primeiro é o Communication Server (CS) para z/OS, incluído como parte do software z/OS. O outro faz parte da oferta "Communications Server for Linux".
Esta seção fornece informações sobre o recurso TCP/IP Offload dos produtos CIP e CPA.
O TCP/IP Offload fornece um meio alternativo de mover os dados de payload transportados em datagramas IP através de um canal de mainframe. O objetivo é lidar com algumas das tarefas de manutenção de rotina do protocolo TCP/IP no dispositivo de descarga, reduzindo assim a quantidade de trabalho necessário no mainframe. Embora o TCP/IP Offload tenha sido amplamente usado, as melhorias na eficiência no manuseio de mainframe do TCP/IP eliminaram em grande parte os motivos para seu uso.
Para sistemas MVS que usam o programa IBM TCP/IP, a decisão de mover do TCP/IP Offload já foi tomada, já que o suporte para descarga terminou na versão MVS 2.4.
Alguns clientes estão usando o produto Unicenter TCPaccess Communications Server da CA para aproveitar o TCP/IP Offload. Em um momento anterior, essa configuração representava o modelo de desempenho ideal. Este produto também pode fazer parte de uma solução que fornece acesso TCP a redes X.25 via X.25 sobre TCP (XOT). O caminho de migração mais simples provavelmente é alterar apenas as partes da configuração que usam a função TCP/IP Offload para usar adaptadores OSA-Express. Para aqueles que usam outros recursos do Unicenter TCPaccess Communications Server, isso tem a vantagem de não perturbar esses recursos. Uma abordagem mais agressiva seria considerar alterar o acesso do datagrama IP para usar a pilha fornecida pela IBM e, se houver recursos XOT sendo usados, investigando se eles poderiam ser habilitados através da interface API NPSI para o NCP baseado em CCL.
O sistema operacional TPF fornece uma pilha de TCP completa, OSA-Express e VIPA desde 2000. Ele foi ativado originalmente pelo PJ2733 na PUT 13 para TPF versão 4.1, e a IBM relata uma melhora drástica no desempenho e na utilização de recursos usando esse modelo. Embora o modelo de serviço TPF não impeça que os clientes continuem a usar o TCP/IP Offload, esperamos que as vantagens e a facilidade de mudança para o TCP/IP nativo de suporte de pilha sejam suficientemente atraentes para que os clientes TPF queiram mudar para este modelo antes do fim do suporte de TCP/IP Offload.
Os CIPs e CPAs instalados atualmente continuarão a ser conectividade viável e as soluções de servidor TN3270 por vários anos. Além disso, esperamos que alguma quantidade de CIP e CPA continue disponível em estoque recondicionado. Existem soluções práticas de substituição para cada uma das funções atualmente executadas pelo CIP e pela CPA. Como etapa inicial, você deve fazer um inventário dos recursos e das quantidades de seu uso atual de CIP e CPA. Em seguida, desenvolva um plano para migrar, nos próximos anos, para uma robusta infraestrutura de switch de camada três inteligente de alta velocidade para fornecer acesso altamente disponível e de alta velocidade ao mainframe.