Dodatek za povezljivost

Nastavitev strežnika aplikacij

Podpora za strežnik aplikacij v DB2 za MVS/ESA omogoča, da DB2 za MVS/ESA deluje kot strežnik za zahtevnike aplikacij DRDA. Odjemalec aplikacij, povezan s strežnikom aplikacij DB2 za MVS/ESA, je lahko:

Za katerikoli zahtevnik aplikacij, povezan s strežnikom aplikacij DB2 za MVS/ESA, strežnik aplikacij DB2 za MVS/ESA podpira dostop do baze podatkov takole:

Posredovanje omrežnih informacij

Če želite, da bo strežnik aplikacij DB2 za MVS/ESA pravilno obdelal zahteve porazdeljene baze podatkov, morate narediti naslednje:

  1. Definirajte strežnik aplikacij za lokalni Upravljalnik komunikacij.
  2. Definirajte vse možne cilje sekundarnega strežnika, da bo lahko strežnik aplikacij DB2 za MVS/ESA preusmeril zahteve SQL na njihov končni cilj.
  3. Podajte potrebno zaščito.
  4. Omogočite predstavitev podatkov.

Definiranje strežnika aplikacij

Če želite, da bo strežnik aplikacij sprejemal zahteve porazdeljene baze podatkov, mora biti definiran za lokalni Upravljalnik komunikacij in imeti enkraten RDB_NAME. Za pravilno definiranje strežnika aplikacij morate narediti naslednje:

  1. Izberite ime LU in RDB_NAME, ki ju bo uporabljal strežnik aplikacij DB2 za MVS/ESA. Postopek zapisa teh imen v DB2 za MVS/ESA in VTAM je enak postopku, ki je opisan v temi Definiranje lokalnega sistema. RDB_NAME, ki ga izberete za DB2 za MVS/ESA, morate posredovati vsem končnim uporabnikom in zahtevnikom aplikacij, ki zahtevajo povezljivost s strežnikom aplikacij.
  2. Vrednost NETID.LUNAME registrirajte za vsak strežnik aplikacij DB2 za MVS/ESA z vsakim zahtevnikom aplikacij, ki zahteva dostop, da bo zahtevnik aplikacij lahko usmerjal zahteve SNA na strežnik DB2 za MVS/ESA. To velja tudi, če zahtevnik aplikacij lahko izvaja dinamično usmerjanje v omrežju, ker mora zahtevnik aplikacij pred uporabo dinamičnega usmerjanja v omrežju poznati NETID.LUNAME.
  3. Za vsak zahtevnik aplikacij podajte privzetek TPN DRDA (X'07F6C4C2'), ker DB2 za MVS/ESA to vrednost uporabi samodejno.
  4. Za vsako ime načina, ki ga potrebuje zahtevnik aplikacij, izdelajte postavko v tabeli načinov VTAM. Te postavke opisujejo velikosti RU, velikost okna za krmiljenje takta in razred storitve za vsako ime načina.
  5. Definirajte omejitve seje za zahtevnike aplikacij, ki bodo vzpostavili povezavo s strežnikom aplikacij DB2 za MVS/ESA. Stavek APPL VTAM definira privzete omejitve seje za vse partnerske sisteme. Če želite nastaviti enkratne privzetke za določenega partnerja, lahko uporabite tabelo SYSIBM.SYSLUMODES komunikacijske baze podatkov (CDB).

    Za informacije o tem, kako se pregleda omrežje VTAM, preberite Nastavitev velikosti RU in krmiljenja takta.

  6. Izdelajte postavke v DB2 za MVS/ESA CDB, da boste določili, kateri zahtevniki aplikacij lahko vzpostavijo povezavo s strežnikom aplikacij DB2 za MVS/ESA. Postavke komunikacijske baze podatkov za zahtevnike aplikacij v omrežju lahko definirate na dva načina:
    1. V SYSIBM.SYSLUNAMES lahko vstavite vrstico, ki podaja uporabo privzetih vrednosti za vse LU-je, ki niso specifično opisani v CDB (privzeta vrstica je v stolpcu LUNAME prazna). Ta način omogoča, da definirate specifične lastnosti za nekatere LU-je v omrežju, za vse druge LU-je pa uporabite privzetke.

      Tako lahko na primer sistemu DALLAS (drugi sistem DB2 za MVS/ESA) omogočite pošiljanje že preverjenih zahtev porazdeljene baze podatkov (LU 6.2 SECURITY=SAME), in od sistemov upravljalnik baz podatkov zahtevate, da pošiljajo gesla. V CDB lahko za vsak sistem Upravljalnika baz podatkov vpišete postavko, še posebej, če je teh sistemov več. Slika 10 kaže, kako lahko CDB uporabite za podajanje SECURITY=SAME za sistem DALLAS, za vse druge zahtevnike pa uveljavite SECURITY=PGM.

      Slika 10. Vzpostavljanje privzetkov za povezave zahtevnika aplikacij

      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
      VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
      VALUES (' ', ' ', 'C', 'N', 'N', ' ');
      

    2. CDB lahko uporabite, če želite vsakemu zahtevniku aplikacij v omrežju ločeno dodeliti pooblastilo; to naredite tako, da CDB nastavite na enega izmed naslednjih načinov:
      • V SYSIBM.SYSLUNAMES ne vpišite privzete vrstice. Če privzete vrstice (vrstica, ki vsebuje prazno ime LU) ni, DB2 za MVS/ESA zahteva vrstico v SYSIBM.SYSLUNAMES, ki vsebuje ime LU za vsak zahtevnik aplikacij, ki poskusi vzpostaviti povezavo. Če zahtevnik aplikacij v CDB ne najde ustrezne vrstice, bo dostop zavrnjen.
      • V SYSIBM.SYSLUNAMES vpišite privzeto vrstico, ki podaja, da je preverjanje izvora zahtevano (stolpec USERNAMES je nastavljen na 'I' ali 'B'). To povzroči, da DB2 za MVS/ESA omeji dostop samo na zahtevnike aplikacij in končne uporabnike, ki so določeni v tabeli SYSIBM.SYSUSERNAMES, kot je opisano v temi Preverjanje izvora. Ta pristop lahko uporabite, če pravila za prevajanje imena zahtevajo, da je v SYSIBM.SYSLUNAMES vrstica s praznim imenom LU, vendar ne želite, da DB2 za MVS/ESA to vrstico uporabi za omogočanje neomejenega dostopa do strežnika aplikacij DB2 za MVS/ESA.

      V Slika 11 nobena vrstica v stolpcu LUNAME ne vsebuje praznega polja, zato DB2 za MVS/ESA zavrne dostop za vse LU-je, razen za LUDALLAS ali LUNYC.

      Slika 11. Določanje posameznih povezav zahtevnika aplikacij

      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
      VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
      VALUES ('LUNYC', ' ', 'A', 'N', 'N', ' ');
      

Definiranje sekundarnih strežnikov

DB2 za MVS/ESA strežnika baz podatkov ne izvaja, kot je definirano v DRDA. Namesto tega ima DB2 za MVS/ESA na voljo sekundarne strežnike, ki omogočajo dostop do več sistemov DB2 za MVS/ESA v eni enoti dela, za kar uporabijo dostop, ki ga usmerja sistem.

Razlike v SQL

SQL, ki ga podpira dostop, ki ga usmerja sistem, se v veliki meri razlikuje od oddaljene enote dela DRDA:

Imena objektov SQL

Ko strežnik aplikacij DB2 za MVS/ESA prejme zahtevo SQL, pregleda ime objekta SQL, da določi, kje v omrežju se nahaja objekt. DB2 za MVS/ESA sprejme eno-, dvo- ali tridelna imena objektov SQL, pri čemer ima ime eno izmed naslednjih oblik:

Objectname podaja ime tabele, pogleda, sopomenke ali vzdevka DB2 za MVS/ESA.

authid.objectname podaja lastnika objekta in ime objekta.

location.authid.objectname podaja lastniški sistem, lastniškega uporabnika in ime objekta.

Če se ime položaja (prvi del tridelnega imena objekta) ujema z RDB_NAME lokalnega sistema DB2 za MVS/ESA, zahteva določa lokalni objekt DB2 za MVS/ESA.

Če se ime položaja ne ujema z RDB_NAME lokalnega sistema DB2 za MVS/ESA, strežnik aplikacij DB2 za MVS/ESA preusmeri zahtevo v sistem, ki ga določa ime položaja, za kar uporabi dostop, ki ga usmerja sistem. Ciljni sistem mora biti drug sistem DB2 za MVS/ESA, ker je dostop, ki ga usmerja sistem, podprt samo med sistemi DB2 za MVS/ESA. Dostop, ki ga usmerja sistem, ne podpira nobenih funkcij za oddaljeno povezovanje, zato ni potrebno, da je aplikacija pred izvajanjem povezana na strežniku. Slika 12 povzema postopek, ki ga DB2 za MVS/ESA uporablja za razrešitev imen objektov SQL.

Slika 12. Razrešitev imena objekta DB2 za MVS/ESA SQL

                                                                                  
                                                                                 
 

REQTEXT

Definicija strežnika

Če želite, da bo strežnik aplikacij DB2 za MVS/ESA preusmeril zahteve SQL, morate vsak sekundarni strežnik definirati v CDB in VTAM. Večina postopka definiranja je podobna postopku, ki ga opisuje tema Definiranje oddaljenih sistemov. Če želite povezati sekundarne strežnike, naredite naslednje:

  1. Zapišite vrednosti za RDB_NAME in ime LU za vsak strežnik v CDB in VTAM. Vrednost TPN, ki jo uporablja dostop, ki ga usmerja sistem, se razlikuje od privzete vrednosti DRDA. Vendar ta razlika ni pomembna, saj DB2 za MVS/ESA samodejno izbere pravilno vrednost.
  2. V SYSIBM.SYSLUNAMES definirajte zaščitne zahteve za vsak sekundarni strežnik. Ta postopek je opisan v temi Omogočanje zaščite.
  3. Definirajte ime načina (ali imena), ki se uporablja med strežnikom aplikacij DB2 za MVS/ESA in sekundarnimi strežniki, nato pa ta imena načinov postavite v tabelo načinov VTAM. Privzeto ime načina je IBMDB2LM.
  4. Definirajte omejitve seje za vse sekundarne strežnike. Postopek, ki se uporablja za določitev omejitev seje, je enak kot postopek, ki je opisan v temi Definiranje lokalnega sistema. Vendar lahko dostop, ki ga usmerja sistem, za vsako aplikacijo vzpostavi več pogovorov. Za povezave z dostopom, ki ga usmerja sistem, bo morda potrebno nastaviti višje omejitve seje kot za povezave DRDA. Podrobnejše informacije o tem, kako se izračuna število sej LU 6.2, ki jih zahtevajo aplikacije z dostopom, ki ga usmerja sistem, preberite poglavje "Connecting Distributed Database Systems" priročnika DB2 Administration Guide.

Kot lastnik sredstev baze podatkov sekundarni strežnik krmili zaščito baze podatkov za objekte SQL, ki se nahajajo na strežniku. Vendar to odgovornost deli s strežnikom aplikacij DB2 za MVS/ESA, ki izvajajo zahtevo. Strežnik dostop do objektov SQL krmili tako:

Omogočanje zaščite

Pri tem, ko zahtevnik aplikacij usmerja zahtevo porazdeljene baze podatkov na strežnik aplikacij DB2 za MVS/ESA, morate upoštevati naslednjo problematiko v zaščiti:

Preverjanje izvora

Ko strežnik aplikacij DB2 za MVS/ESA od zahtevnika aplikacij prejme ime končnega uporabnika, lahko strežnik aplikacij omeji imena končnih uporabnikov, ki jih prejme od določenega zahtevnika aplikacij. To doseže z uporabo preverjanja izvora. Preverjanje izvora strežniku aplikacij omogoča, da poda, da lahko določen ID uporabnika uporabljajo samo določeni partnerji. Tako lahko na primer strežnik aplikacij uporabnika JONES omeji na "izvor" DALLAS. Če drug zahtevnik aplikacij (ki ni DALLAS) poskusi strežniku aplikacij poslati ime JONES, lahko strežnik aplikacij zavrne zahtevo, ker ime ne prihaja iz pravilnega omrežnega mesta.

DB2 za MVS/ESA izvaja preverjanje izvora kot del prevoda vhodnega imena uporabnika, ki je opisano v naslednjem razdelku.

Izbira imen končnih uporabnikov

ID uporabnika, ki ga pošlje zahtevnik aplikacij, morda ni enkraten v celotnem omrežju SNA. Strežnik aplikacij DB2 za MVS/ESA bo za izdelavo enkratnih imen končnih uporabnikov v omrežju SNA morda moral izvesti prevod vhodnega imena. Podobno bo morda moral strežnik aplikacij DB2 za MVS/ESA za posredovanje enkratnih imen končnih uporabnikov sekundarnim strežnikom, ki so vključeni v aplikacijo, prevesti tudi izhodno ime (preberite temo Omogočanje zaščite, kjer boste našli informacije o prevodu izhodnih imen končnih uporabnikov).

Prevod vhodnega imena omogočite tako, da stolpec USERNAMES tabele SYSIBM.SYSLUNAMES nastavite na 'I' (vhodni prevod) ali 'B' (vhodni in izhodni prevod). Če uveljavite prevod vhodnega imena, DB2 za MVS/ESA prevede ID uporabnika, ki ga pošlje zahtevnik aplikacij, in ime lastnika načrta DB2 za MVS/ESA (če je zahtevnik aplikacij drug sistem DB2 za MVS/ESA).

Če zahtevnik aplikacij za besedo APPC ALLOCATE pošlje ID uporabnika in geslo, bosta oba preverjena pred prevodom ID-ja uporabnika. Stolpec PASSWORD tabele SYSIBM.SYSUSERNAMES se ne uporablja za preverjanje gesla. Namesto tega sta ID uporabnika in geslo v preverjanje poslana zunanjemu sistemu za zaščito (RACF ali njemu enakovreden izdelek).

Ko je vhodni ID uporabnika za besedo ALLOCATE preverjen, ima DB2 za MVS/ESA izhode za pooblastila, ki jih lahko uporabite za posredovanje seznama sekundarnih AUTHID-jev in izvajanje dodatnega preverjanja zaščite. Podrobnejše informacije lahko najdete v priročniku DB2 Administration Guide.

Postopek prevajanja vhodnega imena v tabeli SYSIBM.SYSUSERNAMES poišče vrstico, ki se mora ujemati z enim izmed vzorcev, prikazanem na naslednjem seznamu prednosti (TYPE.AUTHID.LUNAME):

  1. I.AUTHID.LUNAME--Določen končni uporabnik z določenega zahtevnika aplikacij.
  2. I.AUTHID.blank--Določen končni uporabnik s kateregakoli zahtevnika aplikacij
  3. I.blank.LUNAME--Katerikoli končni uporabnik z določenega zahtevnika aplikacij.

Če vrstica ni najdena, je oddaljeni dostop zavrnjen. Če je vrstica najdena, bo oddaljeni dostop omogočen, ime končnega uporabnika pa bo spremenjeno v vrednost, ki jo podaja stolpec NEWAUTHID, pri čemer bo vrednost NEWAUTHID prazna, kar pomeni, da ime ni spremenjeno. Vsa preverjanja pooblastil sredstev DB2 za MVS/ESA (na primer pooblastila tabele SQL), ki jih opravi DB2 za MVS/ESA, se opravijo na prevedenih imenih končnih uporabnikov in ne na izvirnih imenih.

Ko strežnik aplikacij DB2 za MVS/ESA od zahtevnika aplikacij prejme ime končnega uporabnika, lahko z zmožnostjo za prevod vhodnega imena DB2 za MVS/ESA dosežete več stvari:

Omogočanje zaščite omrežja

LU 6.2 nudi tri glavne funkcije za zaščito omrežja:

Tema Zaščita omrežja razlaga, kako se poda zaščita na ravni seje in šifriranje z DB2 za MVS/ESA. Strežnik aplikacij DB2 za MVS/ESA uporablja zaščito na ravni seje in šifriranje popolnoma enako kot zahtevnik aplikacij DB2 za MVS/ESA.

Edina problematika, ki je še preostala v zvezi z zaščito omrežja, je zaščita na ravni pogovora SNA. Nekateri vidiki zaščite na ravni pogovora so značilni za strežnik aplikacij DB2 za MVS/ESA. Strežnik aplikacij DB2 za MVS/ESA ima v zaščiti omrežja dve različni vlogi:

Če je odkrita kršitev zaščite, LU 6.2 od strežnika aplikacij DB2 za MVS/ESA zahteva, da zahtevniku aplikacij vrne kodo zaznavanja napake v zaščiti SNA ('080F6051'X). Ker ta koda zaznavanja ne opisuje vzroka napake, DB2 za MVS/ESA nudi dva načina za beleženje vzroka kršitev porazdeljene zaščite:

Zaščita Upravljalnika baz podatkov

Kot lastnik sredstev baze podatkov strežnik aplikacij DB2 za MVS/ESA krmili funkcije za zaščito baze podatkov za objekte SQL, ki se nahajajo na strežniku aplikacij DB2 za MVS/ESA. Dostop do objektov, ki jih upravlja DB2 za MVS/ESA, krmilijo pooblastila, ki jih uporabnikom dodelijo skrbnik DB2 za MVS/ESA ali lastniki posameznih objektov. Dva osnovna razreda objektov, ki jih krmili strežnik aplikacij DB2 za MVS/ESA, sta:

Ko izdelate paket, možnost DISABLE/ENABLE omogoča, da nadzorujete, kateri tipi povezav DB2 za MVS/ESA lahko izvajajo paket. Če želite končnim uporabnikom selektivno omogočiti uporabo DDF, lahko uporabite RACF in izhodne podprograme za zaščito DB2 za MVS/ESA. RLF lahko uporabite za podajanje omejitev za čas procesorja za oddaljene povezave in izvajanja dinamičnega SQL.

Za primer vzemimo paket DB2 za MVS/ESA z imenom MYPKG, katerega lastnik je JOE. JOE lahko SAL omogoči izvajanje paketa z izdajo stavka DB2 za MVS/ESA GRANT USE. Če SAL izvede paket, se zgodi naslednje:

Zaščitni podsistem

Način, na katerega strežnik aplikacij DB2 za MVS/ESA uporablja podsistem za zaščito (RACF ali enakovreden izdelek), je odvisen od tega, kako v tabeli SYSIBM.SYSLUNAMES definirate funkcijo za prevod vhodnega imena:

Predstavitev podatkov

Zagotoviti morate, da vaš podsistem DB2 za MVS/ESA lahko pretvori CCSID posameznih zahtevnikov aplikacij v namestitveni CCSID podsistema DB2 za MVS/ESA. Za podrobnejše informacije preglejte temo Predstavitev podatkov.


[ Vrh Strani | Predhodna Strani | Naslednja Strani | Obsah | Seznam ]