Įmonės, norėdamos pristatyti savo misijai svarbias programas internete, renkasi „Java 2, Enterprise Edition“ (J2EE). J2EE sistemoje klasteriai teikia kritines paslaugas, kad būtų užtikrintas minimalus prastovos laikas ir maksimalus mastelis. Klasteris yra programų serverių grupė, skaidriai vykdanti jūsų J2EE programą, tarsi tai būtų vienas objektas. Norėdami pakeisti mastelį, į grupę turėtumėte įtraukti papildomas mašinas. Norėdami sumažinti prastovą, įsitikinkite, kad visi klasterio komponentai yra nereikalingi.
Šiame straipsnyje įgysime pagrindinį supratimą apie grupes, grupavimo metodus ir svarbias grupių paslaugas. Kadangi grupavimo metodai įvairiose pramonės šakose skiriasi, mes išnagrinėsime kiekvieno požiūrio pranašumus ir trūkumus. Toliau aptarsime svarbias su klasteriais susijusias funkcijas, kurių reikia ieškoti programų serveryje.
Norėdami pritaikyti naujai įgytas klasterių žinias realiame pasaulyje, pamatysime, kaip kiekvienas „HP Bluestone Total-e-Server 7.2.1“, „Sybase Enterprise Application Server 3.6“, „SilverStream Application Server 3.7“ ir „BEA WebLogic Server 6.0“ diegia grupes.
Šios serijos 2 dalyje aptarsime klasterių programavimo ir perėmimo strategijas, taip pat išbandysime savo keturis programų serverių produktus, kad sužinotume, kaip jie keičiasi ir veikia.
Apibrėžti klasteriai
„J2EE“ programų serverių tiekėjai apibrėžia klasterį kaip mašinų grupę, veikiančią kartu skaidriai teikiant įmonės paslaugas (palaikymas JNDI, EJB, JSP, „HttpSession“ ir komponentų perjungimas ir kt.). Jie palieka apibrėžimą tiksliai neapibrėžtą, nes kiekvienas pardavėjas klasterius įgyvendina skirtingai. Viename spektro gale ilsisi pardavėjai, kurie dispečerį pastatė priešais nepriklausomų mašinų grupę, iš kurių nė vienas neturi žinių apie kitas grupėje esančias mašinas. Pagal šią schemą dispečeris gauna pradinę vartotojo užklausą ir atsako naudodamas HTTP peradresavimo antraštę, kad klientas būtų prisegtas prie konkretaus grupės nario serverio. Kitame spektro gale gyvena pardavėjai, kurie įgyvendina griežtai integruotų mašinų federaciją, kiekvienai mašinai visiškai žinant kitas aplink esančias mašinas kartu su jose esančiais objektais.
Be mašinų, grupes gali sudaryti nereikalingi ir tinkami perjungti:
- Apkrovos balansatoriai: Vieni įėjimo į klasterį taškai ir eismo vadovai į atskirus žiniatinklio ar programų serverius
- Žiniatinklio serveriai
- Vartų maršrutizatoriai: Išėjimo taškai iš vidinio tinklo
- Daugiasluoksniai jungikliai: Paketiniai ir rėmelių filtrai, užtikrinantys, kad kiekviena klasterio mašina gauna tik su ta mašina susijusią informaciją
- Ugniasienės: Klasterių apsauga nuo įsilaužėlių filtruodama uosto lygio prieigą prie klasterio ir vidinio tinklo
- SAN („Storage Area Networking“) jungikliai: Prijunkite programų serverius, žiniatinklio serverius ir duomenų bazes prie vidinės atminties terpės; valdyti, į kurį fizinį diską įrašyti duomenis; ir failover
- Duomenų bazės
Nepaisant jų įgyvendinimo, visi klasteriai teikia du pagrindinius pranašumus: mastelis ir didelis prieinamumas (HA).
Mastelis
Mastelis reiškia programos galimybę palaikyti didėjantį vartotojų skaičių. Klasteriai leidžia suteikti papildomą talpą pridedant papildomų serverių, taip užtikrinant mastelio mastą.
Didelis prieinamumas
HA galima apibendrinti vienu žodžiu: atleidimas. Klasteris naudoja daugybę mašinų aptarnavimo užklausoms. Todėl, jei kuri nors mašina grupėje sugenda, kita mašina gali skaidriai perimti.
Klasteris teikia HA tik programų serverio pakopoje. Kad žiniatinklio sistema parodytų tikrąją HA, ji turi būti panaši į Nojaus arką, kurioje būtų bent du dalykai, įskaitant žiniatinklio serverius, šliuzo maršrutizatorius, perjungimo infrastruktūras ir kt. (Norėdami sužinoti daugiau apie HA, žr. HA kontrolinį sąrašą.)
Klasterių tipai
J2EE klasteriai paprastai būna dviejų skonių: nieko nedalino ir bendras diskas. „Shared-nothing“ grupėje kiekvienas programų serveris turi savo failų sistemas su savo grupe veikiančių programų kopijomis. Programų naujinimams ir patobulinimams reikalingi atnaujinimai kiekviename klasterio mazge. Pasirinkus šią sąranką, dideli klasteriai tampa priežiūros košmarais, kai spaudžiamas kodas ir išleidžiami atnaujinimai.
Priešingai, bendro disko klasteris naudoja vieną atminties įrenginį, kurį visi programų serveriai naudoja, kad gautų klasteryje veikiančias programas. Naujinimai ir patobulinimai atliekami vienoje failų sistemoje, o visos grupių mašinos gali pasiekti pakeitimus. Dar neseniai šio požiūrio trūkumas buvo vienintelis nesėkmės taškas. Tačiau SAN suteikia vieną loginę sąsają į nereikalingą laikmeną, kad būtų užtikrintas perjungimas, atkūrimas ir mastelis. (Norėdami daugiau sužinoti apie SAN, žiūrėkite „Storage Infrastructure“ šoninę juostą.)
Lyginant J2EE programų serverių sankaupas, svarbu atsižvelgti į:
- Klasterio diegimas
- Klasterių ir komponentų perjungimo paslaugos
- HttpSession failover
- Pavieniai nesėkmės taškai klasterio topologijoje
- Lankstus topologijos išdėstymas
- Priežiūra
Vėliau panagrinėsime, kaip keturi populiarūs programų serveriai skiriasi įvairiose srityse. Bet pirmiausia panagrinėkime kiekvieną elementą išsamiau.
Klasterio diegimas
J2EE programų serveriai įgyvendina JNDI („Java“ pavadinimų ir katalogų sąsajos) diegimą. Nors JNDI yra pagrindinė paslauga, kuria remiasi „J2EE“ programos, grupėje ją sunku įgyvendinti, nes ji negali susieti kelių objektų su vienu vardu. Yra trys bendri grupavimo metodai, susiję su kiekvieno programų serverio JNDI diegimu:
- Nepriklausomas
- Centralizuota
- Bendras pasaulinis
Nepriklausomas JNDI medis
„HP Bluestone Total-e-Server“ ir „SilverStream Application Server“ naudoja nepriklausomą JNDI medį kiekvienam programų serveriui. Narių serveriai nepriklausomame JNDI medžių klasteryje nežino kitų serverių egzistavimo grupėje ir jiems nerūpi. Todėl perėmimas nepalaikomas arba teikiamas per tarpines paslaugas, kurios peradresuoja HTTP arba EJB užklausas. Šios tarpinės paslaugos sukonfigūruotos taip, kad žinotų, kur yra kiekvienas klasterio komponentas ir kaip patekti į alternatyvų komponentą gedimo atveju.
Vienas nepriklausomo JNDI medžių sankaupos privalumas: trumpesnė sankaupų konvergencija ir paprastas mastelio keitimas. Klasterio konvergencija matuoja laiką, kurio reikia, kol klasteris visiškai sužino visas klasterio mašinas ir su jais susijusius objektus. Tačiau konvergencija nėra nepriklausomos JNDI medžių grupės problema, nes klasteris pasiekia konvergenciją, kai tik paleidžiamos dvi mašinos. Kitas nepriklausomo JNDI medžių klasterio pranašumas: mastelio keitimas reikalauja tik papildomų serverių pridėjimo.
Tačiau yra keletas trūkumų. Pirma, „failover“ yra kūrėjo atsakomybė. Tai yra todėl, kad kiekvieno programų serverio JNDI medis yra nepriklausomas, per JNDI gauti nuotoliniai tarpiniai serveriai yra prisegami prie serverio, kuriame įvyko paieška. Pagal šį scenarijų, jei metodo iškvietimas į EJB nepavyksta, kūrėjas turi parašyti papildomą kodą prisijungti prie dispečerio, gauti kito aktyvaus serverio adresą, atlikti kitą JNDI paiešką ir dar kartą iškviesti nepavykusį metodą. „Bluestone“ įgyvendina sudėtingesnę nepriklausomo JNDI medžio formą, leisdama kiekvienai užklausai atlikti EJB tarpinio serverio paslaugą arba „Proxy LBB“ (apkrovos balanso tarpininką). EJB tarpinio serverio paslauga užtikrina, kad kiekviena EJB užklausa atiteks aktyviam UBS egzemplioriui. Ši schema suteikia papildomą vėlavimą kiekvienai užklausai, tačiau leidžia automatiškai perjungti tarp metodo iškvietimų.
Centralizuotas JNDI medis
„Sybase Enterprise Application Server“ įgyvendina centralizuotą JNDI medžių sankaupą. Pagal šią sąranką centralizuoti JNDI medžių klasteriai naudoja CORBA „CosNaming“ paslaugą JNDI. Vardų serveriuose yra centralizuotas JNDI medis klasteriui ir sekama, kurie serveriai veikia. Paleidus, kiekvienas klasterio serveris susieja savo objektus į savo JNDI medį ir visus vardų serverius.
Nuorodos į EJB gavimas centralizuotoje JNDI medžių grupėje yra dviejų etapų procesas. Pirma, klientas ieško namų objekto iš vardų serverio, kuris pateikia sąveikų objektų nuorodą (IOR). IOR nurodo kelias grupėje esančias aktyvias mašinas, turinčias namų objektą. Antra, klientas pasirenka pirmąją serverio vietą IOR ir gauna namų bei nuotolinį. Jei tarp EJB metodo iškvietimo įvyko klaida, CORBA atkaklė įgyvendina logiką, norėdama nuskaityti kitą namą ar nuotolinį kompiuterį iš alternatyvaus serverio, nurodyto IOR, grąžintame iš vardų serverio.
Patys vardų serveriai rodo centralizuoto JNDI medžių sankaupos silpnumą. Tiksliau, jei turite 50 mašinų sankaupą, iš kurių penkios yra vardų serveriai, klasteris tampa nenaudingas, jei sugenda visi penki vardų serveriai. Iš tiesų, kitos 45 mašinos gali veikti ir veikti, tačiau klasteris neaptarnaus nė vieno EJB kliento, kol neveikia vardų serveriai.
Kita problema kyla dėl papildomo vardų serverio prijungimo prie interneto, jei klasterio originalūs vardų serveriai visiškai sugenda. Tokiu atveju naujam centralizuotam vardų serveriui reikia, kad kiekviena grupėje veikianti mašina susietų savo objektus su naujojo vardų serverio JNDI medžiu. Nors galima pradėti gauti užklausas, kol vyksta susiejimo procesas, tai nerekomenduojama, nes susiejimo procesas prailgina klasterio atkūrimo laiką. Be to, kiekviena JNDI peržiūra iš programos ar programėlės iš tikrųjų reiškia du tinklo skambučius. Pirmasis skambutis gauna objekto IOR iš vardų serverio, o antrasis - kliento norimą objektą iš serverio, nurodyto IOR.
Galiausiai, centralizuotoms JNDI medžių grupėms ilgėja konvergencijos laikas, kai klasteris auga. T. y., Keisdami klasterį, turite pridėti daugiau vardų serverių. Atminkite, kad visuotinai priimtas vardų serverių mašinų ir visų grupių mašinų santykis yra 1:10, o mažiausiai dviejų vardų serverių skaičius. Todėl, jei turite 10 mašinų sankaupą su dviem vardų serveriais, bendras susiejimų tarp serverio ir vardų serverio skaičius yra 20. 40 įrenginių klasteryje, kuriame yra keturi vardų serveriai, bus 160 susiejimų. Kiekvienas susiejimas reiškia procesą, kai narys serveris visus savo objektus susieja su vardų serverio JNDI medžiu. Atsižvelgiant į tai, centralizuotam JNDI medžių klasteriui yra blogiausias konvergencijos laikas tarp visų JNDI klasterių diegimų.
Bendras pasaulinis JNDI medis
Galiausiai „BEA WebLogic“ įgyvendina bendrą pasaulinį JNDI medį. Taikant šį metodą, paleidus klasterio serverį, jis praneša apie savo egzistavimą ir JNDI medį kitiems klasterio serveriams per IP (interneto protokolo) multicast. Kiekviena grupuota mašina susieja savo objektus į bendrą JNDI medį ir savo vietinį JNDI medį.
Turėdami visuotinį ir vietinį JNDI medį kiekviename nario serveryje, sugeneruoti namų ir nuotoliniai blokai gali pereiti ir suteikia greitą JNDI paiešką procese. Bendras visuotinis JNDI medis yra bendrinamas tarp visų klasterio mašinų, leidžiantis bet kuriai narei žinoti tikslią visų klasterio objektų vietą. Jei objektas yra prieinamas daugiau nei viename klasterio serveryje, specialus namų objektas yra susietas su bendru pasauliniu JNDI medžiu. Šis specialus namas žino visų EJB objektų, su kuriais jis yra susietas, vietą ir sukuria nuotolinius objektus, kurie taip pat žino visų EJB objektų, su kuriais jis yra susietas, vietą.
Pagrindiniai bendro požiūrio trūkumai: didelis pradinis tinklo srautas, generuojamas paleidus serverius, ir ilgas klasterio konvergencijos laikas. Priešingai, nepriklausomoje JNDI medžių grupėje konvergencija nėra problema, nes nevyksta JNDI informacijos mainai. Tačiau bendram pasauliniam ar centralizuotam klasteriui reikia laiko, kad visos klasterio mašinos sukurtų bendrą visuotinį arba centralizuotą JNDI medį. Iš tiesų, kadangi bendri visuotiniai klasteriai naudoja daugiaadresį perdavimą JNDI informacijai, laikas, reikalingas bendram pasauliniam JNDI medžiui sukurti, yra tiesinis, palyginti su paskesnių pridėtų serverių skaičiumi.
Pagrindiniai bendro pasaulio pranašumai, palyginti su centralizuotais JNDI medžių klasteriais, yra lengvesnis mastelio keitimas ir didesnis prieinamumas. Jei naudojatės bendru pasauliniu, jums nereikia blaškytis su procesoriais ir RAM tam skirtame vardų serveryje ar derinti vardų serverių skaičių grupėje. Atvirkščiai, norėdami išplėsti programą, tiesiog pridėkite daugiau mašinų. Be to, jei kuri nors mašina klasteryje nusileis, klasteris ir toliau veiks tinkamai. Galiausiai kiekvienai nuotolinei paieškai reikia vieno tinklo skambučio, palyginti su dviem tinklo skambučiais, reikalingais centralizuotoje JNDI medžių grupėje.
Visa tai turėtų būti imama su druska, nes JSP, servletai, EJB ir „JavaBeans“, veikiantys programų serveryje, gali pasinaudoti tuo, kad jie yra EJB serveryje. Jie visada naudos procese vykdomą JNDI paiešką. Atminkite, kad jei naudojate tik serverio programas, nepriklausomų, centralizuotų ar bendrų pasaulinių sankaupų diegimai skiriasi nedaug. Iš tiesų, kiekviena HTTP užklausa pateks į programų serverį, kuris atliks JNDI procesą, norėdamas grąžinti bet kurį objektą, naudojamą jūsų serverio programoje.
Toliau atkreipsime dėmesį į antrą svarbų „J2EE“ programų serverio klausimą: grupių ir perjungimo paslaugas.
