Podjetja izberejo Javo 2, izdaja za podjetja (J2EE), da po spletu dostavijo svoje ključne naloge. V okviru J2EE grozdi zagotavljajo kritične storitve, s katerimi zagotavljajo minimalno čas izpada in največjo razširljivost. Grozd je skupina aplikacijskih strežnikov, ki pregledno zaženejo vašo aplikacijo J2EE, kot da bi bila ena sama entiteta. Za obseg bi morali v gručo vključiti dodatne stroje. Če želite zmanjšati čas izpada, se prepričajte, da je vsaka komponenta gruče odvečna.
V tem članku bomo pridobili temeljno razumevanje združevanja v skupine, metod združevanja v skupine in pomembnih storitev grozdov. Ker se pristopi združevanja v različne panoge razlikujejo, bomo preučili prednosti in pomanjkljivosti vsakega pristopa. Nadalje bomo razpravljali o pomembnih funkcijah, povezanih z grozdi, ki jih je treba iskati na strežniku aplikacij.
Če želimo novo pridobljeno znanje o združevanju uporabiti v resničnem svetu, bomo videli, kako HP Bluestone Total-e-Server 7.2.1, Sybase Enterprise Application Server 3.6, SilverStream Application Server 3.7 in BEA WebLogic Server 6.0 izvajajo grozde.
V 2. delu te serije bomo zajeli strategije programiranja in odpovedi za grozde ter preizkusili naše štiri izdelke aplikacijskega strežnika, da bomo videli, kako se razširijo in preklopijo.
Opredeljeni grozdi
Ponudniki aplikacijskih strežnikov J2EE grozd opredelijo kot skupino strojev, ki sodelujejo za pregledno zagotavljanje storitev v podjetju (podpora za JNDI, EJB, JSP, HttpSession in preusmeritev komponent itd.). Definicijo puščajo namerno nejasno, ker vsak prodajalec različno izvaja združevanje. Na enem koncu spektra počivajo prodajalci, ki postavijo dispečerja pred skupino neodvisnih strojev, od katerih noben ne pozna drugih strojev v gruči. V tej shemi dispečer prejme začetno zahtevo uporabnika in odgovori z glavo preusmeritve HTTP, da odjemalca pripne na določen strežnik člana gruče. Na drugem koncu spektra so prodajalci, ki izvajajo zvezo tesno integriranih strojev, pri čemer se vsak stroj popolnoma zaveda drugih strojev okoli sebe, skupaj s predmeti na teh strojih.
Poleg strojev lahko grozdi vsebujejo odvečne in zmožne preusmeritve:
- Izravnalniki obremenitve: Posamezne vstopne točke v gruči in direktorji prometa do posameznih spletnih ali aplikacijskih strežnikov
- Spletni strežniki
- Usmerjevalniki prehoda: Izhodne točke iz notranjega omrežja
- Večplastna stikala: Paketni in okvirni filtri zagotavljajo, da vsaka naprava v gruči prejme samo informacije, ki se nanašajo nanjo
- Požarni zidovi: Zaščitniki grozdov pred hekerji s filtriranjem dostopa na ravni vrat do grozda in notranjega omrežja
- Stikala SAN (Storage Area Networking): Povežite aplikacijske strežnike, spletne strežnike in zbirke podatkov z zalednim pomnilniškim medijem; upravljati na kateri fizični disk zapisovati podatke; in preusmeritev
- Zbirke podatkov
Ne glede na to, kako se izvajajo, imajo vsi grozdi dve glavni prednosti: razširljivost in visoka dostopnost (HA).
Razširljivost
Razširljivost se nanaša na zmožnost aplikacije, da podpira večje število uporabnikov. Grozdi vam omogočajo, da z dodajanjem dodatnih strežnikov zagotovite dodatno zmogljivost in tako zagotovite razširljivost.
Visoka dostopnost
HA lahko povzamemo z eno besedo: redundanca. Grozd uporablja veliko strojev za servisiranje zahtev. Če torej katera koli naprava v gruči odpove, jo lahko transparentno prevzame druga naprava.
Grozd zagotavlja HA samo na ravni strežnika aplikacij. Da lahko spletni sistem prikazuje resnično HA, mora biti kot Noetova barka, saj vsebuje vsaj dve stvari, vključno s spletnimi strežniki, prehodnimi usmerjevalniki, preklopnimi infrastrukturami itd. (Za več informacij o HA glejte kontrolni seznam HA.)
Vrste grozdov
Skupine J2EE so ponavadi v dveh okusih: ni delil ničesar in skupni disk. V gruči, v kateri ni nič v skupni rabi, ima vsak strežnik aplikacij lastne datotečne sisteme s svojo kopijo aplikacij, ki se izvajajo v gruči. Posodobitve in izboljšave aplikacij zahtevajo posodobitve v vseh vozliščih v gruči. S to nastavitvijo velike grozde postanejo nočna mora za vzdrževanje, ko koda pritiska in se sprostijo posodobitve.
Nasprotno pa gruča diskov v skupni rabi uporablja eno samo pomnilniško napravo, ki jo vsi aplikacijski strežniki uporabljajo za pridobivanje aplikacij, ki se izvajajo v gruči. Posodobitve in izboljšave se pojavijo v enem datotečnem sistemu in vsi stroji v gruči lahko dostopajo do sprememb. Do nedavnega je bila slabost tega pristopa njegova edina točka neuspeha. Vendar SAN daje en sam logični vmesnik v odvečni pomnilniški medij, da zagotovi odpoved, odpoved in razširljivost. (Za več informacij o SAN glejte stransko vrstico Storage Infrastructure.)
Pri primerjavi izvedb gruče strežnikov aplikacijskih strežnikov J2EE je pomembno upoštevati:
- Izvajanje grozdov
- Storitve odpovedi grozdov in komponent
- Preklop HttpSession
- Posamezne točke okvare v topologiji grozda
- Prilagodljiva postavitev topologije
- Vzdrževanje
Kasneje si bomo ogledali primerjavo štirih priljubljenih strežnikov aplikacij na različnih področjih. Najprej pa podrobneje preučimo vsak element.
Izvajanje grozdov
Aplikacijski strežniki J2EE izvajajo združevanje v skupine, ki izvajajo JNDI (Java Naming in Directory Interface). Čeprav je JNDI osnovna storitev, na katero se zanašajo aplikacije J2EE, jo je v gruči težko implementirati, ker ne more povezati več predmetov z enim imenom. V zvezi z izvajanjem JNDI vsakega aplikacijskega strežnika obstajajo tri splošne metode združevanja v gruče:
- Neodvisno
- Centralizirano
- Skupna raba
Neodvisno drevo JNDI
HP Bluestone Total-e-Server in SilverStream Application Server uporabljata neodvisno drevo JNDI za vsak aplikacijski strežnik. Članski strežniki v neodvisni drevesni gruči JNDI ne vedo ali ne skrbijo za obstoj drugih strežnikov v gruči. Zato preusmeritev podatkov ni podprta ali zagotovljena prek posredniških storitev, ki preusmerijo zahteve HTTP ali EJB. Te posredniške storitve so konfigurirane tako, da vedo, kje je vsaka komponenta v gruči, in kako v primeru okvare pridejo do nadomestne komponente.
Ena od prednosti neodvisne drevesne gruče JNDI: krajša konvergenca grozdov in enostavnost skaliranja. Konvergenca grozdov meri čas, ki je potreben, da se grozd popolnoma zaveda vseh strojev v grozdu in z njimi povezanih objektov. Vendar konvergenca ni problem v neodvisni drevesni gruči JNDI, ker grozd doseže konvergenco takoj, ko se zaženeta dva stroja. Druga prednost neodvisne gruče dreves JNDI: skaliranje zahteva le dodajanje dodatnih strežnikov.
Vendar obstaja več slabosti. Prvič, odpoved je običajno odgovornost razvijalca. To pomeni, ker je drevo JNDI vsakega aplikacijskega strežnika neodvisno, oddaljeni strežniki proxy, pridobljeni prek JNDI, so pripeti na strežnik, na katerem je prišlo do iskanja. V tem primeru, če klic metode na EJB ne uspe, mora razvijalec napisati dodatno kodo za povezavo z dispečerjem, pridobiti naslov drugega aktivnega strežnika, opraviti drugo iskanje JNDI in znova poklicati neuspešno metodo. Bluestone izvaja bolj zapleteno obliko neodvisnega drevesa JNDI, tako da vsako zahtevo posreduje prek storitve proxy EJB ali Proxy LBB (Load Balance Broker). Storitev proxy EJB zagotavlja, da gre vsaka zahteva EJB v aktivni primerek UBS. Ta shema doda dodatno zakasnitev vsaki zahtevi, vendar omogoča samodejno preusmeritev med klici metode.
Centralizirano drevo JNDI
Sybase Enterprise Application Server izvaja centralizirano drevesno gručo JNDI. V tej nastavitvi centralizirane drevesne gruče JNDI uporabljajo storitev CORBA CosNaming za JNDI. Imenski strežniki hranijo centralizirano drevo JNDI za gručo in spremljajo, kateri strežniki so nameščeni. Ob zagonu vsak strežnik v gruči poveže svoje predmete v svoje drevo JNDI in vse imenske strežnike.
Pridobivanje reference na EJB v centralizirani drevesni gruči JNDI je postopek v dveh korakih. Najprej odjemalec poišče domači objekt z imenskega strežnika, ki vrne referenco interoperabilnega predmeta (IOR). IOR kaže na več aktivnih strojev v gruči, ki imajo domači objekt. Drugič, odjemalec izbere prvo lokacijo strežnika v IOR-u in dobi dom in daljinski upravljalnik. Če pride do napake med priklicem metode EJB, klin CORBA implementira logiko za pridobivanje drugega doma ali oddaljenega od nadomestnega strežnika, navedenega v IOR, vrnjenem z imenskega strežnika.
Imenski strežniki sami dokazujejo šibkost centralizirane drevesne gruče JNDI. Natančneje, če imate skupino 50 naprav, od katerih je pet imenskih strežnikov, grozd postane neuporaben, če vseh pet imenskih strežnikov propade. Dejansko bi lahko ostalih 45 strojev delovalo, vendar grozd ne bo služil enemu odjemalcu EJB, medtem ko poimenski strežniki ne delujejo.
Druga težava nastane zaradi povezave dodatnega imenskega strežnika v primeru popolne okvare prvotnih imenskih strežnikov grozda. V tem primeru novi centralizirani imenski strežnik zahteva, da vsaka aktivna naprava v gruči veže svoje predmete v drevo JNDI novega imenskega strežnika. Čeprav je mogoče začeti prejemati zahteve, medtem ko poteka postopek vezave, to ni priporočljivo, saj postopek vezave podaljša čas obnovitve grozda. Poleg tega vsako iskanje JNDI iz aplikacije ali programčka v resnici predstavlja dva omrežna klica. Prvi klic pridobi IOR za objekt iz imenskega strežnika, drugi pa objekt, ki ga želi odjemalec, iz strežnika, določenega v IOR.
Nazadnje, centralizirane drevesne gruče JNDI trpijo zaradi povečanega časa do konvergence, ko grozd narašča. To pomeni, da morate med prilagajanjem gruče dodati več imenskih strežnikov. Upoštevajte, da je splošno sprejeto razmerje med strežniki imenskih strežnikov in celotnimi stroji grozdov 1:10 z najmanj dvema imenskima strežnikoma. Če imate torej 10-strojno gručo z dvema imenskima strežnikoma, je skupno število vezav med strežnikom in imenskim strežnikom 20. V 40-strojni gruči s štirimi imenskimi strežniki bo 160 vezav. Vsaka veza predstavlja proces, pri katerem strežnik člana veže vse svoje predmete v drevo JNDI imenskega strežnika. Glede na to ima centralizirana drevesna gruča JNDI najslabši konvergenčni čas med vsemi izvedbami gruče JNDI.
Skupno drevo JNDI v skupni rabi
Končno, BEA WebLogic implementira skupno globalno drevo JNDI. S tem pristopom, ko se strežnik v gruči zažene, prek multicast IP (Internet Protocol) prek drugih strežnikov v gruči sporoči svoj obstoj in drevo JNDI. Vsak gručasti stroj poveže svoje predmete v skupno globalno drevo JNDI in svoje lokalno drevo JNDI.
Vključitev globalnega in lokalnega drevesa JNDI znotraj vsakega strežnika-člana omogoča generirane domače in oddaljene škrbine za odpoved ter omogoča hitro iskanje JNDI v postopku. Skupno drevo JNDI v skupni rabi je v skupni rabi med vsemi stroji znotraj gruče, kar omogoča vsakemu članskemu računalniku, da ve natančno lokacijo vseh objektov v gruči. Če je objekt na voljo na več strežnikih v gruči, je poseben domači objekt vezan na skupno drevo JNDI v skupni rabi. Ta poseben dom pozna lokacijo vseh objektov EJB, s katerimi je povezan, in ustvarja oddaljene predmete, ki poznajo tudi lokacijo vseh objektov EJB, s katerimi je povezan.
Glavne slabosti skupnega globalnega pristopa: velik začetni omrežni promet, ustvarjen ob zagonu strežnikov, in dolg konvergenčni čas grozda. Nasprotno pa se v neodvisni drevesni gruči JNDI izkaže, da konvergenca ni težava, ker ne pride do izmenjave informacij JNDI. Vendar skupna globalna ali centralizirana grozd zahteva čas, da vsi stroji grozda zgradijo skupno globalno ali centralizirano drevo JNDI. Ker skupne globalne grozde za prenos podatkov JNDI uporabljajo večkanalno pošiljanje, je čas, potreben za izdelavo skupnega drevesa JNDI, linearen glede na število dodanih nadaljnjih strežnikov.
Glavne prednosti skupne globalne storitve v primerjavi s centraliziranimi drevesnimi skupinami JNDI so osredotočene na enostavnost skaliranja in večjo razpoložljivost. Pri globalni skupni rabi vam ni treba igrati na CPE-jih in RAM-u na namenskem imenskem strežniku ali nastavljati število imenskih strežnikov v gruči. Za razširitev aplikacije preprosto dodajte več strojev. Poleg tega, če kateri koli stroj v gruči pade, bo grozd še naprej pravilno deloval. Na koncu je za vsako oddaljeno iskanje potreben en omrežni klic v primerjavi z dvema omrežnima klicema, ki sta potrebna v centralizirani drevesni gruči JNDI.
Vse to je treba vzeti z rezervo, ker lahko JSP-ji, servleti, EJB-ji in JavaBeans, ki se izvajajo na strežniku aplikacij, izkoristijo možnost, da se nahajajo na strežniku EJB. Vedno bodo uporabljali medprocesno iskanje JNDI. Upoštevajte, da če zaženete samo aplikacije na strežniški strani, obstaja majhna razlika med neodvisnimi, centraliziranimi ali skupnimi izvedbami globalne gruče. Dejansko se bo vsaka zahteva HTTP končala na aplikacijskem strežniku, ki bo v postopku poiskal JNDI, da bo vrnil kateri koli predmet, uporabljen v aplikaciji na strani strežnika.
Nato se osredotočimo na drugo pomembno obravnavo aplikacijskega strežnika J2EE: storitve grozdov in odpovedi.
