Tecnologias IBM : Redes IBM

Processador da interface do canal e White Paper da migração do Channel Port Adapter

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Os adaptadores de porta do processador da interface do canal e do canal são amplamente utilizados para o acessório da rede às unidades centrais IBM (e tomada compatível) e para proporcionar serviços tais como a conversão e o TCP/IP Offload do TN3270. Desde que Cisco anunciou o fim da venda deste Produtos, os usuários deste equipamento podem querer começar a planejar soluções alternativa, e este papel fornece a orientação em fazê-lo.

/image/gif/paws/70636/cip_cpa_migration1.gif

Para começar, é importante notar que não há nenhuma necessidade de mudar imediatamente. Há um tempo adequado considerar as opções disponíveis para substituir as funções do CIP e do CPA e para executar um melhor da estratégia de migração serido a sua situação. Estes são o Produtos maduro que foi campo testado nos milhares de instalações de cliente, abrangendo dez dos milhares de variações, e suportando atualmente milhões de utilizadores finais nas redes de produção. O apoio para este equipamento permanecerá disponível no ano 2011.We espera isso para a maioria de clientes, as mudanças a sua rede do centro de dados da unidade central devem e serão conduzidas por fatores diferentes do fim eventual do serviço do Produtos do canal de mainframe de Cisco.

Ao longo da última década houve umas mudanças enormes no sentido do projeto de trabalhos em rede da unidade central. Os vendedores do computador central IBM compatível de tomada deixaram o mercado, permitindo uma única aproximação unificada ao acessório da rede física das unidades centrais. A ênfase na tecnologia tradicional da subzona SNA foi substituída por HPR SNA, para aproveitar-se especialmente de HPR/IP e de capacidade do nó de rede de filial. Ao mesmo tempo o IBM deslocou dramaticamente sua aproximação aos trabalhos em rede na unidade central, abraçando um modelo de sistemas abertos que mantivesse o mesmo nível incomparável da Disponibilidade exigido pelo papel crítico da unidade central na empresa. Os adaptadores dos sistemas abertos dos Ethernet (OSA) com QDIO, e aperfeiçoado para o pacote IP que segura, fornecem muito trajeto dos mais eficiente do que os canais ESCON para mover dados da rede à unidade central. Esta fundação é combinada então com os endereços IP de Um ou Mais Servidores Cisco ICM NT virtuais (VIPA), os protocolos de roteamento dinâmico, e as capacidades de Qualidade de Serviço, de fornecer uma fundação completa para trabalhos em rede IP de Alta disponibilidade e de alto desempenho.

Na maioria dos casos um projeto novo que se mova do CIP e o CPA para o OSA inclui um switch de camada 3 inteligente tal como o catalizador 6000 com apoio forte do protocolo de roteamento e da redistribução e a capacidade de apoiar os módulos de um alcance de serviço.

Roteamento do IP datagram – usando a GARRA ou o CMPC+

Esta seção fornece a informação sobre os recursos de roteamento do IP datagram do Produtos CIP e CPA.

Descrição do recurso

Distribuir pacotes IP às unidades centrais era a primeira função a ser executada por Cisco CIP, e os protocolos do canal da GARRA de Cisco e CMPC+ representam ambos primeiro e último os protocolos do canal executados no CIP e no CPA. Igualmente representam a funcionalidade substituída o mais facilmente, porque a função de Roteamento IP é apoiada em todos os roteadores Cisco e switch de camada 3, e o IP por sua natureza é independente de considerações dos meios físicos.

/image/gif/paws/70636/cip_cpa_migration2.gif

Alternativas sugeridas

Enquanto os diagramas acima mostram, o projeto do centro de dados pode ser simplificado ao usar as relações OSA anexadas diretamente à camada da agregação em um centro de dados. Em uma ou outra encenação, para fornecer a disponibilidade máxima, um protocolo de roteamento dinâmico deve ser executado no interruptor ou no roteador anexado diretamente à unidade central. As diferenças significativas são que a agregação da rota IP é a função principal do Switches da camada da agregação, e são projetados executar o switching da camada 3 da taxa do fio, e servem como o ponto de controle para a redistribução da rota IP.

Este projeto novo remove o equipamento que pode incorrer custos para a manutenção e a operação, representa pontos da falha potencial, e introduz a latência adicional.

Supondo que as relações OSA são da variedade dos Ethernet 100Mb, e configurado para operar-se no modo QDIO, devem fornecer a taxa de transferência similar, ou levemente melhor para datagramas IP do que (CMPC+ ou GARRA EMBALADO) CIP ou CPA otimamente configurados, em uma porta pela base de porta. Obviamente, para os Ethernet 1000Gb, há o potencial para ganhos de desempenho significativos com o projeto OSA.

SNA - Construção de uma ponte sobre LLC – usando o CSNA

Esta seção fornece a informação sobre a característica de Cisco SNA do Produtos CIP e CPA.

Descrição do recurso

A característica CSNA fornece a construção de uma ponte sobre do tráfego LLC SNA através de um canal de mainframe. Devido à variedade de maneiras que o tráfego SNA está entregado ao CSNA, as soluções totais são geralmente mais complexas do que aquelas associadas com Roteamento IP. Pode haver toda a mistura de máquinas anexadas LAN local SNA, DLSw+ que entregam o tráfego SNA das posições remotas, e SNA Switching Services (SNASw) que distribui o tráfego SNA usando o APPN. Os CIP e os CPA que executam o CSNA são igualmente prováveis ser um de poucos lugares restantes em uma rede onde a tecnologia do Token Ring é distribuída, e uma migração do CSNA deve igualmente incluir mover-se do Token Ring para Ethernet

Uma instalação CIP ou CPA para o SNA pode incluir alguns dos seguintes elementos.

/image/gif/paws/70636/cip_cpa_migration3.gif

Alternativas sugeridas

Conversão ótima, SNASw usado no Roteadores secundários

De solução a mais simples e a maioria completa é converter o tráfego existente da camada 2 SNA para usar o IP na camada 3 para o transporte, conectando o a um roteador SNASw. Se isto é feito junto às máquinas da camada 2 SNA, limita o domínio da camada 2 SNA aos segmentos pequenos do LAN, e remove toda a necessidade de construir uma ponte sobre este tráfego através de WAN com DLSw, ou entre LAN.

/image/gif/paws/70636/cip_cpa_migration4.gif

Conversão ao SNASw usando o DLSw+ no Roteadores secundários

Uma solução alternativa, onde não seja possível instalar o SNASw nos roteadores remotos, é usar o DLSw+ para trazer o tráfego SNA no centro de dados, e para passá-lo então fora ao SNASw para a conversão no EE. Quando isto ainda apresentar o tráfego da camada 2 SNA no centro de dados, se as características do DLSw+ e SNASw são amba a corrida no mesmo roteador, a camada 2 SNA estará somente em uma conexão dentro daquele Roteadores. O tráfego que chega de WAN e que vai à unidade central será IP.

/image/gif/paws/70636/cip_cpa_migration5.gif

LLC SNA construído uma ponte sobre através da camada de acesso ao OSA no modo LC

Há determinados casos que exigem a Conectividade direta da camada 2 entre os dispositivos SNA e a unidade central, e onde OSA-E baseado IP não é útil. Um tal caso pode ser onde há somente máquinas locais SNA e estes exigem relativamente altas conexões de largura de banda à unidade central. Um segundo caso é host da subzona para hospedar o tráfego que não pode ser passado com o SNASw e ser transformado no EE o tráfego. Claramente este é o argumento especialmente para o SNI ou o outro tráfego que é enviado com um OSA ao controlador de comunicação para Linux (CCL) NCP baseado. Você deve consultar a documentação IBM apropriada em relação a configurar e a controlar as relações OSA configuradas para segurar LLC/SNA, ou CDLC para o CCL. Para o desempenho máximo e controle-o deve tentar colocar todas estas máquinas SNA em uma, ou um pequeno número, mergulhe 2 conjuntos dentro da camada de acesso da rede do centro de dados. Os desafios originais atuais dos dispositivos anexo do Token Ring, como não toda a infraestrutura do centro de dados apoiam o acessório do Token Ring, e adicionar o Switches para o Token Ring é muito pouco suscetível de ser justificável neste tempo. Nós sugerimos que os dispositivos do Token Ring estejam anexados diretamente a um roteador de filial, e o Translational Bridging seja executado nesse roteador. Um formulário da Disponibilidade redundante pode ser fornecido no ambiente de Ethernet por qualquer um de dois métodos. No ponto que o dispositivo SNA anexa à rede, o endereço MAC de Ethernet duplicado pode ser usado em um único LAN, com o um do endereço que está sendo suprimido até o HSRP de utilização necessário. Alternativamente, os endereços MAC de Ethernet duplicados podem ser usados na extremidade do host da conexão, assegurando-se de que estes endereços existam em LAN separados, e que algum formulário da medida - a árvore impede que ambos apareçam em um LAN comum.

/image/gif/paws/70636/cip_cpa_migration6.gif

Processamento do Servidor TN3270

Esta seção fornece a informação sobre a característica do Protocolo de servidor TN3270 do Produtos CIP e CPA.

Descrição do recurso

O Servidor TN3270 é um server industrial da força, capaz confiantemente de servir milhares de concurrent 3270 sessões. Sua colocação, como uma parte integral da infraestrutura de rede, fornece a flexibilidade do projeto conseguir a Disponibilidade incomparável.

/image/gif/paws/70636/cip_cpa_migration7.gif

Alternativas sugeridas

Nós sugerimos que a única maneira de conseguir a escalabilidade e a Disponibilidade similares seja colocar a função do Servidor TN3270 diretamente na unidade central. Isto fornece um ambiente altamente confiável, e as interfaces múltiplas e o roteamento dinâmico na unidade central, disponibilidade da rede contínua. Isto igualmente tem a vantagem de colocar mais da complexidade do SNA e da sua conversão ao TN3270 em um único lugar, onde a habilidade o administrar possa ser mais prontamente - disponível. Há duas unidade central diferente ofertas baseadas do programa do Servidor TN3270 disponíveis do IBM. O primeiro é o servidor de comunicação (CS) para z/OS, incluído como parte do software z/OS. O outro é parte do “Communications Server para Linux” que oferece.

TCP/IP Offload

Esta seção fornece a informação sobre a característica do TCP/IP Offload do Produtos CIP e CPA.

Descrição do recurso

O TCP/IP Offload fornece meios alternativos de mover as datagramas dentro levadas dados de payload IP através de um canal de mainframe. O objetivo é segurar alguns dos deveres rotineiros das tarefas domésticas do protocolo TCP/IP no dispositivo do offload, diminuindo desse modo a quantidade de trabalho exigida na unidade central. Quando o TCP/IP Offload era uma vez amplamente utilizado, as melhorias da eficiência na manipulação da unidade central do TCP/IP eliminaram pela maior parte as razões para seu uso.

/image/gif/paws/70636/cip_cpa_migration8.gif

Alternativas sugeridas

Para sistemas MVS usando o programa IBM TCP/IP, a decisão se mover-se do TCP/IP Offload tem sido feita já, como o apoio para offload terminado na versão 2.4 MVS.

Alguns clientes estão usando o produto do Communications Server de Unicenter TCPaccess de CA para aproveitar-se do TCP/IP Offload. Em um ponto mais adiantado a tempo, esta configuração representou o modelo de desempenho ótimo. Este produto pode igualmente ser parte de uma solução que forneça o acesso TCP às redes X.25 através do X.25 sobre TCP (XOT). O caminho de migração o mais simples é provavelmente mudar somente aquelas partes da configuração que usam a função do TCP/IP Offload para usar pelo contrário adaptadores OSA-expressos. Para aqueles que usam outros recursos do Communications Server de Unicenter TCPaccess, isto tem a vantagem de não perturbar aquelas características. Uma aproximação mais agressiva seria considerar mudar o acesso do IP datagram para usar a pilha fornecida IBM, e se há umas características XOT que estão sendo usadas, investigá-lo se aquelas poderiam ser permitidas através da relação NPSI API ao NCP baseado CCL.

O sistema operacional TPF forneceu uma pilha completa TCP, OSA-expresso, e o VIPA desde 2000. Foi permitido originalmente por PJ27333 em 13 POSTOS para a versão 4.1 TPF, e o IBM relata dramaticamente o desempenho aprimorado e a utilização de recurso usando este modelo. Quando o modelo de serviço TPF não impossibilitar clientes da continuação usar o TCP/IP Offload, nós esperamos que as vantagens, e a facilidade de se mover, ao apoio nativo da pilha TCP/IP estão obrigando bastante que os clientes TPF quererão mudar a este modelo antes da extremidade do apoio do TCP/IP Offload.

Resumo

Os CIP e os CPA atualmente instalados permanecerão Conectividade e soluções viáveis do Servidor TN3270 por diversos mais anos. Além do esse, nós esperamos que alguma quantidade de CIP e de CPA continuará a estar disponível do estoque recondicionado. Há umas soluções práticas da substituição para cada um das funções executadas atualmente pelo CIP e pelo CPA. Como uma etapa inicial, você deve inventariar as características e as quantidades de seu uso atual CIP e CPA. Desenvolva então um plano para mover-se, durante os próximos vários anos, para uma infraestrutura inteligente de alta velocidade robusta do interruptor da camada três para fornecer altamente disponível e o acesso de alta velocidade à unidade central.


Informações Relacionadas


Document ID: 70636