Transformările mainframe

TCP/IP sau HPR? Ambele sunt viabile, însă administratorii de retele trebuie să cunoască diferentele.
Daniel Moldovan

Atunci când e vorba de alegerea unui server Unix sau Windows NT caracteristicile care contează cel mai mult sunt disponibilitatea si scalabilitatea. În ceea ce-i priveste pe producători, acestia se mândresc cu sisteme care ating capacităti de nivel industrial cum ar fi un timp de functionare cu un randament de 99,9% si un suport pentru cel putin 1000 de utilizatori.

În prezent există însă multi administratori de retele ale căror servere îndeplinesc cele două cerinte. Aceste servere nu sunt altele decât vechile sisteme mainframe IBM. Desigur, numai când le auzi denumirea si deja te si gândesti la Jurassic Park. Însă nu vă grăbiti! Ceea ce-ati uitat este că aceste sisteme mainframe oferă un timp de functionare mai bun si pot administra mii de utilizatori. A apărut astfel o nouă posibilitate de administrare a aplicatiilor Internet, în special a celor dedicate procesării tranzactiilor si a comertului electronic. Pentru a spori si mai mult valoarea sistemelor mainframe, IBM a lansat pe piată produse mai scalabile, care folosesc Parallel Sysplex - versiunea mainframe a lucrului în clustere (clustering).

Iar acum, iată mărul discordiei: aplicatiile Internet rulează folosind TCP/IP, în timp ce sistemele mainframe folosesc SNA (Systems Network Arhitecture). Cu toate acestea, administratorii de retele au propriile optiuni. Aceia care doresc să folosească un singur protocol în toată reteaua pot folosi o stivă TCP/IP instalată pe mainframe. Problema în acest caz este că nu toate componentele solutiei TCP/IP vor fi disponibile. O altă variantă ar fi HPR (High Performance Routing) de la IBM, un protocol care a fost dezvoltat la câtva timp după SNA si care oferă o tolerantă la defecte si o performantă mai bună decât TCP/IP.

Întrebarea este care protocol trebuie ales? Din moment ce în centrul de date atât HPR cât si TCP/IP sunt viabile, nu există un singur răspuns corect. Alegerea celei mai bune variante presupune întelegerea fundamentelor centrului de date – în special a modelului Parallel Sysplex.

Sisteme mainframe în clustere

Parallel Sysplex conectează sisteme mainframe individuale (care pot avea procesoare multiple), transformând întreaga configuratie astfel încât aceasta să arate ca un singur sistem. La fel ca în orice cluster, când o componentă cade, celelalte îi vor prelua sarcina. Acest mod de lucru previne de asemenea aparitia situatiilor în care una din masini preia toate sarcinile în timp ce altele sunt utilizate sub capacitate.

Un canal Escon (Enterprise Systems Connections) este în realitate un bus de 17 Mbps, care conectează elemente ale retelei în centrul de date. Deoarece în lumea mainframe, suportul cel mai des utilizat pentru comunicare este canalul Escon, conectarea la acest canal este foarte importantă. Pe lângă sisteme mainframe, arii de discuri si procesoare front-end, mai există de asemenea un timer Sysplex, care este de fapt un ceas sistem comun care permite o păstrare a sincronizării dispozitivelor.

Recent, IBM a adăugat modelului Parallel Sysplex un dispozitiv numit Facilitate de Conectare (Coupling Facility). În esentă, el reprezintă un mainframe separat care administrează jurnalizarea (logging) si unele functii de întretinere, atasându-se direct la sistemele mainframe prin propriile canale de 100 Mbyte/s.

Parallel Sysplex furnizează două mari avantaje: o imagine sistem unică si o sesiune persistentă. Imaginea sistem unică presupune că fiecare locatie a aplicatiei este transparentă pentru utilizator. Acest lucru este important deoarece din motive de întretinere sau capacitate, pot exista imagini multiple ale fiecărei aplicatii. Să presupunem că există mai multe copii CICS (Customer Information Control System) pe unul sau mai multe sisteme mainframe. Parallel Sysplex prezintă utilizatorilor toate copiile aplicatiei sub acelasi nume (de exemplu CICS) indiferent de versiunea care rulează. De unde stie însă FEP care imagine a aplicatiei s-o trimită utilizatorului? Parallel Sysplex prezintă o componentă numită Workload Manager care păstrează o evidentă a încărcării fiecărei aplicatii. Toate sistemele mainframe si Facilitatea de Conectare rulează o copie a acesteia.

Când un FEP receptionează o cerere de sesiune, el o directionează către dispozitivul care procesează conectarea. Versiunea VTAM (Virtual Telecommunications Access Method) care rulează pe această masină interoghează Facilitatea de Conectare pentru a obtine ultimele informatii legate de disponibilitatea aplicatiei. Cu această informatie, VTAM decide unde să transmită sesiunea. Decizia se poate baza simplu pe numărul sesiunilor curente care rulează pe o masină anume, sau pe definitii complexe ale politicii de nivel serviciu.

Facilitătile de conectare intră în scenă atunci când sunt implicate sesiunile persistente. Sesiunile persistente sunt acelea care rămân active în ciuda căderii sistemului. Spre exemplu, dacă o instantă a CICS esuează, VTAM mută toate sesiunile asociate într-o altă imagine a aplicatiei. Aceasta nu este o rezolvare simplă, deoarece aplicatia de la receptie trebuie să cunoască în momentul căderii starea exactă a tuturor tranzactiilor. Dacă spre exemplu, o aplicatie esuează după ce un utilizator actualizează o înregistrare a bazei de date, însă înainte ca baza de date să deblocheze înregistrarea, masina de receptie va fi nevoită să repornească tranzactia din acelasi punct.

Dacă o aplicatie esuează, Parallel Sysplex foloseste informatia din Facilitatea de Conectare pentru a porni din nou sesiunea cu o altă imagine a aplicatiei. Însă o păstrare a urmei aplicatiei, presupune o analiză suplimentară. IBM estimează că Facilitatea de Conectare utilizează aproximativ 17% din resursele disponibile, plus 0,5% pentru fiecare imagine MVS (Multiple Virtual Storage) sau OS/390 suplimentară. (Sistemele mainframe deseori rulează copii multiple ale sistemului de operare pentru a crea partitii logice de date.) Datorită unei analize suplimentare pe care o presupune, administratorii de retea trebuie să se gândească bine dacă o aplicatie necesită această protectie înainte de-a o pune în functiune.

În plus, doar Facilitatea de Conectare nu poate rezolva o problemă de fond. În prezent VTAM administrează căderile prin repornirea aplicatiilor de pe aceeasi masină. El nu poate muta sesiunile pe o altă masină în Sysplex. Cu alte cuvinte, în timp ce este permisă o mutare a aplicatiilor între sistemele mainframe, o mutare a sesiunilor nu este posibilă.

IBM a rezolvat însă această deficientă printr-o caracteristică numită multinod. În esentă, multinodul permite sesiunilor să fie mutate pe orice masină mainframe din Parallel Sysplex, asigurând astfel o disponibilitate totală de 7x24 ore. Pentru a face aceasta, multinodul necesită o folosire intensivă a HPR.

Introducere în HPR

În esentă, HPR reprezintă o versiune mult mai robustă si mai eficientă a APPN (Advanced Peer-to-Peer Networking), realizată de IBM după venerabila suită SNA. SNA era dezavantajată în comparatie cu TCP/IP deoarece ea nu putea redirectiona sesiunile esuate, în timp ce TCP/IP putea. Astfel, HPR adaugă o redirectionare dinamică si un control superior al fluxului, si în plus, merge dincolo de limitele atinse de TCP/IP, datorită capacitătii sale de-a migra sesiunile esuate de la un sistem mainframe la altul. TCP/IP poate face asta deoarece VTAM este punctul de capăt al fiecărei masini; dacă VTAM esuează, la fel vor face si restul sesiunilor de pe acea masină. Aceasta reprezintă de altfel o problemă a versiunii curente a Parallel Sysplex: Dacă VTAM cade, la fel vor face si sesiunile asociate.

HPR administrează căderile atât pentru nodurile intermediare cât si pe cele din nodurile de capăt. Când o sesiune esuează, HPR de la nodul intermediar sau de capăt transmite o comandă de localizare căutând copiile aplicatiilor care rulează pe alte sisteme mainframe. Din moment ce pe durata procesului de localizare sistemele mainframe folosesc nume si nu adrese specifice, faptul că o aplicatie este găsită pe o masină nouă, nu reprezintă o problemă. Comanda de localizare returnează noua adresă către utilizatorul final, care nu stie niciodată ce adresă fizică este implicată.

Administratorii de retea care cred însă că aceasta reprezintă o disponibilitate de 100% pentru serverele Web s-ar putea să fie dezamăgiti. Redirectionarea HPR, Workload Manager de la Sysplex si sesiunile persistente SNA lucrează bine în cazul sesiunilor de lungă durată. Paginile Web în schimb, presupun sesiuni de scurtă durată – una pentru fiecare obiect din pagină. A păstra urma tuturor actiunilor asociate cu aceste sesiuni scurte nu-si justifică efortul depus. Si chiar dacă HPR oferă beneficii indubitabile atunci când sunt implicate versiuni de lungă durată, el nu este implementat pe scară largă. În timp ce este relativ usor să implementezi HPR în Parallel Sysplex (de fapt HPR este activat în mod automat în noile versiuni de VTAM), unele dispozitive din afara centrului de date suportă HPR sau APPN versiunea 1. În cele din urmă, sesiunile pe termen lung pentru paginile Web ar putea veni chiar de la HTTP (hypertext transfer protocol); o versiune propusă va suporta si sesiunile persistente.Înseamnă cumva asta că majoritatea utilizatorilor vor fi lăsati în afară? Nu chiar. IBM, Bus-Tech Inc. si Cisco Systems Inc. au dezvoltat aplicatii pentru lucrul în retea mainframe care nu necesită o convertire la HPR a tuturor statiilor din fluxul descendent. Cu solutiile oferite de aceste companii, dispozitivele din fluxul descendent vor comunica peste protocoalele deja în functiune, cum ar fi SNA zonal sau TCP/IP.

Toti acesti producători folosesc aceeasi abordare când e vorba de protocolul SNA zonal: ei realizează o conversie de ultim-hop a traficului la HPR. Softul care realizează această conversie este DLUR/S (Dependent LU Requester/Server).

Iată modul de lucru: Un utilizator final transmite o cerere prin SNA la centrul de date. Dispozitivul de la marginea centrului de date converteste traficul în HPR folosind codul DLUR. DLUR interceptează cererea sesiunii SNA si o transferă perechii sale din Sysplex – DLUR/S, care rulează ca o aplicatie VTAM pe mainframe. DLUR/S actionează ca si o interfată între SNA zonal si TCP/IP în configurarea sesiunii. Odată ce sesiunea este stabilită, DLUR înlocuieste header-ul fiecărui cadru SNA zonal (numit format ID 2 [FID2] în limbajul SNA) cu un nou format HPR (FID5). IBM, Bus-Tech si Cisco implementează fiecare DLUR în propriile dispozitive atasate la canal: IBM în familia sa de procesoare front-end 900 si 3745/3746 si în ruterul Model 2216, Bus-Tech în Netshuttle 230 si Cisco în cartela CIP (Channel Interface Processor) pentru ruterul său Model 7500.

Lucrând cu TCP/IP

Dar dacă dispozitivele din fluxul descendent folosesc TCP/IP? Nu ar exista nici o problemă dacă ele ar lucra cu Tn3270, cel mai utilizat protocol de retea TCP/IP-SNA. Portile SNA pot converti traficul descendent Tn3270 în SNA nativ pentru procesare de către mainframe. Portile provenite de la Apertus Technologies Inc., CNT/Brixton Systems Inc. si Openconnect Systems Inc., toate pot realiza o conversie a traficului TCP/IP către SNA zonal. Aceasta permite reconstituirea pe acelasi mainframe a aplicatiilor esuate, însă nu permite migrarea aplicatiilor sau a sesiunilor pe un nou mainframe. Pentru aceste functii, sunt necesare Facilitatea de Conectare si HPR.

Cu toate acestea, multe companii caută să implementeze TCP/IP în întreaga întreprindere – si în sistemele mainframe din centrul de date. Însă lipsa de suport din partea TCP/IP pentru functii cheie Parallel Sysplex, cum ar fi sesiuni persistente îl fac să se claseze pe o pozitie secundă. Această situatie s-ar putea schimba însă repede. IBM, Bay Networks si Cisco lucrează la includerea IP ca parte integrantă în Parallel Sysplex. Au fost anuntate proiecte menite a rula TCP/IP oriunde, chiar si pe sistemele mainframe cu functii Parallel Sysplex.

Este important de mentionat însă că în prezent este posibilă o compatibilitate IP de la un capăt la altul; IBM si Interlin Computer Sciences Inc. vând de câtiva ani stive TCP/IP pentru MVS si OS/390. Deocamdată, la TCP/IP nu sunt încă disponibile functiile Parallel Sysplex cum ar fi o imagine sistem singulară si sesiuni persistente de-a lungul mai multor sisteme mainframe.

Căi diferite

Desi IBM, Bay si Cisco planifică deservirea unor functii Sysplex prin TCP/IP, ei au în vedere rute diferite pentru obtinerea lor. Să presupunem că un utilizator final doreste o resursă generică numită CICS (care ca si răspuns va accesa una din cele trei instante – CICS1, CICS2 sau CICS3 – pe unul din sistemele mainframe). IBM si BAY au următoarea abordare: În primul rând, aplicatia utilizatorului final cere adresa IP pentru resursa numită CICS de la DNS (Domain Name Server). DNS-ul transferă cererea către alte DNS-uri până află unul care stie ceva în legătură cu resursa dată. Acest DNS special – cel care cunoaste date despre resursă – rulează pe un dispozitiv atasat la canal. Acest dispozitiv poate fi un FEP IBM, Model 2216 de la IBM sau Bay 5000. În continuare, dispozitivul atasat la canal, transferă o cerere VTAM, care comunică cu Workload Manager, întrebându-l ce adresă IP să returneze. În cele din urmă, VTAM si Workload Manager găsesc si returnează adresa IP corespunzătoare imaginii sistemului mainframe care rulează CICS1. DNS-ul la rândul său, directionează adresa IP a CICS1 către PC-ul care porneste sesiunea.

Există însă unele probleme potentiale. În primul rând, DNS-urile stochează în mod normal orice corespondentă nume-adresă pe care au învătat-o, astfel încât viitoarele cereri nu vor mai necesita o căutare. Cât de mult îsi vor putea reaminti celelalte DNS-uri, depinde de valoarea din câmpul TTL (Time-to-live) din header-ul pachetelor IP returnate de DNS-ul special. Însă stocarea rezultatelor de căutare anulează scopul lui Workload Manager – care poate aloca cereri către alte sisteme mainframe (si astfel si alte adrese IP) pe principiul sesiune-cu-sesiune în functie de starea tuturor masinilor din Sysplex. IBM si Bay au rezolvat această problemă impunând ca DNS-ul special să emită un răspuns TTL de valoare zero pentru toate DNS-urile. În acest mod, răspunsul nu va fi depus în cache. În al doilea rând, DNS presupune realizarea cererilor către resurse după nume si nu după adresa IP. Dacă este folosită o adresă IP, conexiunea depăseste DNS-ul si merge direct la aplicatie – anulând din nou scopul Workload Manager.

Cisco la rândul său merge mai departe, ruterele sale actionând ca si proxy pentru aplicatiile ce rulează pe mainframe-uri. Acest lucru este realizat folosind o adresă IP virtuală, o functie disponibilă cu stivele IP mainframe. Când un utilizator cere adresa unei aplicatii ce rulează pe un mainframe, ruterul Cisco returnează o adresă virtuală – însă în acelasi timp renuntă la cererea pentru adresa sursei reale. Cisco maschează adresa IP folosind NAT (Network Address Translation), folosit pe scară largă în ziduri de protectie pentru ecranarea adreselor IP de vizualizarea externă.

Folosind NAT, ruterul Cisco poate lucra cu Workload Manager. Iată modul în care producătorul planifică să trateze căutarea CICS discutată anterior: Înainte de toate, aplicatia utilizatorului final cere de la DNS adresa IP a resursei numite CICS. În continuare, serverul returnează adresa IP virtuală a mainframe-ului. Apoi, aplicatia utilizatorului final transmite o cerere de conectare pe care ruterul Cisco o interceptează folosind fie numele resursei (CICS) fie o adresă IP. Ruterul Cisco întreabă apoi Workload Manager-ul care mainframe rulează aplicatia si care este sarcina pe fiecare. Pe baza acestor informatii decide care aplicatie va fi dirijată către conexiune. Fără abordarea Cisco, VTAM împreună cu Workload Manager trebuiau să decidă unde să trimită cererea. Abordarea Cisco nu are VTAM, asa că ruterul trebuie să decidă. Aceasta presupune ca ruterul Cisco să obtină informatia legată de imaginea care va trebui selectată din Workload Manager – un proces la care producătorii încă mai lucrează. În final, ruterul realizează o translatie între adresele IP virtuale pe care utilizatorul final le cunoaste si adresele IP actuale. Apoi PC-ul lansează sesiunea.

Administrând căderile sistem

Abordările IBM/Bay si Cisco descoperă resursele si echilibrează încărcarea configuratiei Parallel Sysplex. Dar dacă sistemul esuează? Asa cum s-a mentionat, TCP/IP din centrul de date nu oferă sesiuni persistente, asa cum SNA zonal sau APPN/HPR o fac. Există două lucruri care trag IP-ul înapoi. Stivele IP mainframe de la IBM si Interlink nu transferă informatiile către Facilitatea de Conectare. Fără această posibilitate de conectare, nu există nici o modalitate de refacere a sesiunii. Nici un producător n-a realizat încă o încercare serioasă pentru a adăuga această capacitate. În plus, deoarece aplicatiile TCP/IP consideră sesiunile de pe masini diferite, noi conexiuni, dacă o aplicatie esuează si este pornită din nou de pe-o altă masină, toate sesiunile sunt pierdute. IBM nu are încă o solutie. Cisco evită problema din moment ce foloseste o adresă IP virtuală care apare pe fiecare sistem mainframe din Parallel Sysplex.

Probleme de performantă

Chiar si atunci când aceste probleme vor fi rezolvate, performanta TCP/IP tot nu o va egala pe cea a SNA din centrul de date. Mainframe-urile n-au fost niciodată proiectate pentru a administra procesarea TCP/IP. În consecintă, aceasta necesită mai multi cicli decât echivalentul SNA. Numărul exact variază în functie de sarcină, însă cu o bună aproximare se poate spune că lungimea căii IP - numărul de instructiuni necesare pentru o sarcină dată - este aproximativ de două ori mai mare decât lungimea căii VTAM pentru SNA. Acest raport nu se reflectă însă în diferenta dintre tranzactiile SNA respectiv TCP/IP deoarece VTAM si IP contribuie doar cu o mică parte la lungimea căii globale pentru orice tranzactie procesată. Spre exemplu să presupunem că lungimea căii unei aplicatii este de 100 Kbytes. VTAM adaugă 15 Kbytes pentru SNA iar IP adaugă 30. Din moment ce lungimea totală este de 115 Kbytes pentru SNA si 130 pentru IP, diferenta este de doar 13%. Desigur, cu cât lungimea căii aplicatiei este mai mare, cu atât mai mică este diferenta dintre lungimea căilor protocoalelor de comunicatii.

Vestea bună pentru fanii IP este că diferenta se micsorează, iar costul IP scade. Cât de mare este problema diferentei dintre IP si SNA? Comparatiile sunt valabile doar dacă IP este folosit în toată aplicatia. Când folositi Tn3270 si porti SNA nu există nici o diferentă. Desi multe retele urmează o cale de mijloc, rulând SNA/HPR în centrul de date si IP în rest, administratorii de retea consideră că un scenariu complet IP trebuie să facă fată următoarei provocări: Beneficiile rulării unui singur protocol în întreprindere depăseste limitările IP din centrul de date?

Daniel Moldovan este redactor la BYTE România. Poate fi contactat la dmoldovan@agora.ro.

(C) Copyright Computer Press Agora