Ohjelmointi

J2EE-ryhmittely, osa 1

Yritykset valitsevat Java 2, Enterprise Edition (J2EE) -toiminnon kriittisten sovellustensa toimittamiseksi verkon kautta. J2EE-puitteissa klusterit tarjoavat toimintakriittisiä palveluja varmistaakseen mahdollisimman pienet seisokit ja skaalautuvuuden. Klusteri on ryhmä sovelluspalvelimia, jotka suorittavat J2EE-sovelluksesi avoimesti ikään kuin se olisi yksi kokonaisuus. Mittakaavassa sinun tulisi sisällyttää klusteriin muita koneita. Voit vähentää seisokkeja varmistamalla, että kaikki klusterin osat ovat tarpeettomia.

Tässä artikkelissa saamme perustiedot klusteroinnista, klusterointimenetelmistä ja tärkeistä klusteripalveluista. Koska klustereihin perustuvat lähestymistavat vaihtelevat toimialoittain, tutkitaan kunkin lähestymistavan edut ja haitat. Lisäksi keskustelemme tärkeistä klusteriin liittyvistä ominaisuuksista, joita sovelluspalvelimelta on etsittävä.

Jotta voisimme soveltaa äskettäin hankittua klusterointitietoa todelliseen maailmaan, näemme, kuinka HP Bluestone Total-e-Server 7.2.1, Sybase Enterprise Application Server 3.6, SilverStream Application Server 3.7 ja BEA WebLogic Server 6.0 toteuttavat kukin klusterit.

Tämän sarjan osassa 2 käsitellään klustereiden ohjelmointi- ja vikasietoisuusstrategioita sekä testataan neljää sovelluspalvelintuotettamme nähdäksesi, kuinka ne skaalautuvat ja vikasietotie.

Klusterit määritelty

J2EE-sovelluspalvelimen toimittajat määrittelevät klusterin joukoksi koneita, jotka työskentelevät yhdessä tarjoamaan läpinäkyvästi yrityspalveluja (tuki JNDI: lle, EJB: lle, JSP: lle, HttpSessionille ja komponenttien vianmääritykselle ja niin edelleen). Ne jättävät määritelmän tarkoituksellisesti epämääräiseksi, koska kukin myyjä toteuttaa klusterin eri tavalla. Taajuuksien toisessa päässä lepäävät myyjät, jotka asettavat lähettäjän itsenäisten koneiden ryhmän eteen, joista kenelläkään ei ole tietoa klusterin muista koneista. Tässä järjestelmässä työnvälittäjä vastaanottaa käyttäjän alkuperäisen pyynnön ja vastaa HTTP-uudelleenohjausotsikolla asiakkaan kiinnittämiseksi klusterin tiettyyn jäsenpalvelimeen. Taajuuden toisessa päässä ovat myyjät, jotka toteuttavat tiiviisti integroitujen koneiden federaation, ja jokainen kone on täysin tietoinen muista ympäröivistä koneista yhdessä näiden koneiden esineiden kanssa.

Koneiden lisäksi klusterit voivat sisältää redundantteja ja varakäynnistyskykyisiä:

  • Kuorman tasauslaitteet: Yksittäiset liittymispisteet klusteriin ja liikenteenohjaajat yksittäisille verkko- tai sovelluspalvelimille
  • Web-palvelimet
  • Yhdyskäytävän reitittimet: Poistumispisteet ulos sisäisestä verkosta
  • Monikerroksiset kytkimet: Paketti- ja kehyssuodattimet sen varmistamiseksi, että jokainen klusterin kone vastaanottaa vain kyseiseen koneeseen liittyviä tietoja
  • Palomuurit: Klusterinsuojat hakkereilta suodattamalla porttitason pääsy klusteriin ja sisäiseen verkkoon
  • SAN (Storage Area Networking) -kytkimet: Yhdistä sovelluspalvelimet, Web-palvelimet ja tietokannat taustajärjestelmään; hallita fyysistä levyä, johon tiedot kirjoitetaan; ja vikasietoisuus
  • Tietokannat

Riippumatta siitä, miten ne toteutetaan, kaikilla klustereilla on kaksi pääetua: skaalautuvuus ja korkea saatavuus (HA).

Skaalautuvuus

Skaalautuvuus viittaa sovelluksen kykyyn tukea yhä useampaa käyttäjää. Klustereiden avulla voit tarjota ylimääräistä kapasiteettia lisäämällä ylimääräisiä palvelimia, mikä varmistaa skaalautuvuuden.

Korkea saatavuus

HA voidaan tiivistää yhdellä sanalla: redundanssi. Klusteri käyttää monia koneita palvelupyyntöihin. Siksi, jos jokin klusterin kone epäonnistuu, toinen kone voi ottaa sen haltuunsa avoimesti.

Klusteri tarjoaa HA: n vain sovelluspalvelimen tasolla. Jotta verkkojärjestelmällä olisi todellinen HA, sen on oltava kuin Nooan arkki, ja siinä on oltava vähintään kaksi kaikkea, mukaan lukien verkkopalvelimet, yhdyskäytäväreitittimet, kytkininfrastruktuurit ja niin edelleen. (Lisätietoja HA: sta on HA-tarkistuslistassa.)

Klusterityypit

J2EE-klustereita on yleensä kahta makua: ei jakanut mitään ja jaettu levy. Jaetussa ei-klusterissa jokaisella sovelluspalvelimella on omat tiedostojärjestelmänsä, joilla on oma kopio klusterissa käynnissä olevista sovelluksista. Sovellusten päivitykset ja parannukset edellyttävät päivityksiä kaikissa klusterin solmuissa. Tämän asennuksen myötä suurista klustereista tulee ylläpito painajaisia, kun koodia painetaan ja päivitykset julkaistaan.

Sen sijaan jaetun levyn klusteri käyttää yhtä tallennuslaitetta, jota kaikki sovelluspalvelimet käyttävät saamaan klusterissa käynnissä olevia sovelluksia. Päivityksiä ja parannuksia tapahtuu yhdessä tiedostojärjestelmässä, ja kaikki klusterin koneet voivat käyttää muutoksia. Viime aikoihin asti tämän lähestymistavan haittapuoli oli sen ainoa epäonnistumiskohta. SAN antaa kuitenkin yhden loogisen käyttöliittymän redundanttiin tallennusvälineeseen vikasietoisuuden, palautuksen ja skaalautuvuuden tarjoamiseksi. (Lisätietoja SAN-verkosta on Storage Infrastructure -sivupalkissa.)

J2EE-sovelluspalvelinten klusteritoteutuksia verrattaessa on tärkeää ottaa huomioon:

  • Klusterin toteutus
  • Klusterien ja komponenttien vikasietopalvelut
  • HttpSession-vikasietoisuus
  • Yksittäiset epäonnistumispisteet klusteritopologiassa
  • Joustava topologian asettelu
  • Huolto

Myöhemmin tarkastelemme, kuinka neljä suosittua sovelluspalvelinta vertaa eri alueilla. Mutta ensin tutkitaan kutakin kohdetta tarkemmin.

Klusterin toteutus

J2EE-sovelluspalvelimet toteuttavat klustereita JNDI: n (Java Naming and Directory Interface) toteuttamisen ympärillä. Vaikka JNDI on ydinpalvelu, johon J2EE-sovellukset luottavat, sitä on vaikea toteuttaa klusterissa, koska se ei voi sitoa useita objekteja yhteen nimeen. Jokaisen sovelluspalvelimen JNDI-toteutukseen liittyy kolme yleistä klusterointimenetelmää:

  • Itsenäinen
  • Keskitetty
  • Jaettu maailmanlaajuinen

Itsenäinen JNDI-puu

HP Bluestone Total-e-Server ja SilverStream Application Server käyttävät erillistä JNDI-puuta kullekin sovelluspalvelimelle. JNDI-puuryhmän jäsenpalvelimet eivät tiedä tai välitä muiden palvelinten olemassaolosta klusterissa. Siksi vikasietoa joko ei tueta tai se toimitetaan välityspalvelujen kautta, jotka ohjaavat uudelleen HTTP- tai EJB-pyynnöt. Nämä välityspalvelut on määritetty tietämään, missä kukin klusterin komponentti sijaitsee ja miten päästä vaihtoehtoiseen komponenttiin vikatilanteessa.

Yksi itsenäisen JNDI-puuryhmän etu: lyhyempi klustereiden lähentyminen ja skaalauksen helppous. Klusterin konvergenssi mittaa aikaa, jonka klusterille kuluu, jotta se tietäisi kaikki klusterin koneet ja niihin liittyvät objektit. Lähentyminen ei kuitenkaan ole ongelma itsenäisessä JNDI-puuryhmässä, koska klusteri saavuttaa lähentymisen heti, kun kaksi konetta käynnistyy. Toinen itsenäisen JNDI-puuryhmän etu: skaalaus vaatii vain ylimääräisten palvelimien lisäämisen.

On kuitenkin olemassa useita heikkouksia. Ensinnäkin vika on yleensä kehittäjän vastuulla. Eli koska jokaisen sovelluspalvelimen JNDI-puu on riippumaton, JNDI: n kautta haetut etävaltuutukset kiinnitetään palvelimeen, jolla haku tapahtui. Tässä skenaariossa, jos menetelmän kutsu EJB: lle epäonnistuu, kehittäjän on kirjoitettava ylimääräinen koodi yhteyden muodostamiseksi välittäjään, hankittava toisen aktiivisen palvelimen osoite, tehtävä toinen JNDI-haku ja soitettava epäonnistunut menetelmä uudelleen. Bluestone toteuttaa itsenäisen JNDI-puun monimutkaisemman muodon tekemällä jokaisen pyynnön EJB-välityspalvelun tai välityspalvelimen (Proxy LBB) (Load Balance Broker) kautta. EJB-välityspalvelu varmistaa, että jokainen EJB-pyyntö menee aktiiviseen UBS-ilmentymään. Tämä malli lisää ylimääräisen viiveen kuhunkin pyyntöön, mutta sallii automaattisen vianmäärityksen menetelmän puheluiden välillä.

Keskitetty JNDI-puu

Sybase Enterprise Application Server toteuttaa keskitetyn JNDI-puuryhmän. Tässä asennuksessa keskitetyt JNDI-puuryhmät käyttävät CORBA: n CosNaming-palvelua JNDI: lle. Nimipalvelimet sisältävät keskitetyn JNDI-puun klusterille ja seuraavat, mitkä palvelimet ovat käytössä. Käynnistyksen yhteydessä jokainen klusterin palvelin sitoo objektinsa JNDI-puuhun sekä kaikkiin nimipalvelimiin.

Viitteen saaminen EJB: lle keskitetyssä JNDI-puuryhmässä on kaksivaiheinen prosessi. Ensin asiakas etsii kotiobjektin nimipalvelimelta, joka palauttaa yhteentoimivan objektiviitteen (IOR). IOR osoittaa useita klusterin aktiivisia koneita, joilla on kotiobjekti. Toiseksi asiakas valitsee ensimmäisen palvelimen sijainnin IOR: ssä ja hankkii kodin ja etäyhteyden. Jos EJB-menetelmäkutsujen välillä esiintyy vika, CORBA-tynkä toteuttaa logiikkaa hakemaan toisen kodin tai kaukosäätimen nimipalvelimelta palautetusta IOR: sta luetellulta vaihtoehtoiselta palvelimelta.

Nimipalvelimet itse osoittavat keskitetyn JNDI-puuryhmän heikkouden. Jos sinulla on 50 koneen klusteri, joista viisi on nimipalvelimia, klusteri muuttuu hyödyttömäksi, jos kaikki viisi nimipalvelinta menevät alas. Itse asiassa muut 45 konetta voisivat olla käynnissä, mutta klusteri ei palvele yhtä EJB-asiakasta nimipalvelinten ollessa poissa käytöstä.

Toinen ongelma syntyy lisäämällä ylimääräinen nimipalvelin verkkoon, jos klusterin alkuperäiset nimipalvelimet epäonnistuvat kokonaan. Tässä tapauksessa uusi keskitetty nimipalvelin vaatii jokaisen klusterin aktiivisen koneen sitomaan objektinsa uuden nimipalvelimen JNDI-puuhun. Vaikka on mahdollista aloittaa pyyntöjen vastaanottaminen sidontaprosessin aikana, tätä ei suositella, koska sidontaprosessi pidentää klusterin palautumisaikaa. Lisäksi jokainen JNDI-haku sovelluksesta tai sovelmasta edustaa todella kahta verkkopuhelua. Ensimmäinen puhelu hakee objektin IOR: n nimipalvelimelta, kun taas toinen hakee asiakkaan haluaman objektin IOR: ssa määritetyltä palvelimelta.

Lopuksi, keskitetyt JNDI-puuryhmät kärsivät pitemmästä lähentymisaikasta, kun klusteri kasvaa. Eli kun lisäät ryhmääsi, sinun on lisättävä lisää nimipalvelimia. Muista, että nimipalvelinkoneiden ja klusterikoneiden yleisesti hyväksytty suhde on 1:10, ja vähintään kaksi nimipalvelinta. Siksi, jos sinulla on 10 koneen klusteri, jossa on kaksi nimipalvelinta, palvelimen ja nimipalvelimen välisten sidosten kokonaismäärä on 20. 40 koneen klusterissa, jossa on neljä nimipalvelinta, on 160 sidontaa. Jokainen sidonta edustaa prosessia, jossa jäsenpalvelin sitoo kaikki objektinsa nimipalvelimen JNDI-puuhun. Tässä mielessä keskitetyllä JNDI-puuryhmällä on huonoin lähentymisaika kaikkien JNDI-klusterien toteutusten joukossa.

Jaettu globaali JNDI-puu

Lopuksi BEA WebLogic toteuttaa jaetun globaalin JNDI-puun. Tällä lähestymistavalla, kun klusterin palvelin käynnistyy, se ilmoittaa olemassaolonsa ja JNDI-puun klusterin muille palvelimille IP (Internet Protocol) -lähetyksen kautta. Jokainen klusteroitu kone sitoo objektinsa jaettuun globaaliin JNDI-puuhun sekä omaan paikalliseen JNDI-puuhun.

Globaalin ja paikallisen JNDI-puun käyttäminen jokaisessa jäsenpalvelimessa antaa luotujen koti- ja etätukien vianetsinnän ja tarjoaa nopeat JNDI-haun prosessin aikana. Jaettu globaali JNDI-puu on jaettu kaikkien klusterin koneiden kesken, jolloin kukin jäsenkone voi tietää kaikkien klusterin kohteiden tarkan sijainnin. Jos objekti on käytettävissä useammassa kuin yhdessä klusterin palvelimessa, erityinen kotiobjekti on sidottu jaettuun globaaliin JNDI-puuhun. Tämä erityinen koti tietää kaikkien EJB-objektien sijainnin, joihin se liittyy, ja luo etäobjekteja, jotka tietävät myös kaikkien EJB-objektien sijainnin, joihin se on liitetty.

Jaetun globaalin lähestymistavan tärkeimmät haittapuolet: palvelinten käynnistyessä syntyvä suuri alkuperäinen verkkoliikenne ja klusterin pitkä lähentymisaika. Sen sijaan riippumattomassa JNDI-puuryhmässä lähentyminen ei ole ongelma, koska JNDI-tietojen jakamista ei tapahdu. Jaettu globaali tai keskitetty klusteri vaatii kuitenkin aikaa kaikille klusterin koneille jaetun globaalin tai keskitetyn JNDI-puun rakentamiseen. Koska jaetut globaalit klusterit käyttävät monilähetystä JNDI-tietojen siirtämiseen, jaetun globaalin JNDI-puun rakentamiseen tarvittava aika on lineaarinen suhteessa seuraavien lisättyjen palvelimien määrään.

Jaetun globaalin pääedut keskitettyihin JNDI-puuryhmiin verrattuna keskittyvät helposti skaalaukseen ja parempaan käytettävyyteen. Jaetussa globaalissa tilassa sinun ei tarvitse hioa erillisen nimipalvelimen suorittimia ja RAM-muistia tai virittää klusterin nimipalvelimien määrää. Pikemminkin sovelluksen laajentamiseksi lisää vain lisää koneita. Lisäksi jos jokin kone klusterissa putoaa, klusteri jatkaa toimintaansa oikein. Lopuksi kukin etähaku vaatii yhden verkkopuhelun verrattuna kahteen verkkopuheluun, joita tarvitaan keskitetyssä JNDI-puuryhmässä.

Kaikki tämä tulisi ottaa jyvän suolalla, koska sovelluspalvelimessa käynnissä olevat JSP: t, servletit, EJB: t ja JavaBeans voivat hyödyntää sijaintiaan yhdessä EJB-palvelimessa. He käyttävät aina prosessin sisäistä JNDI-hakua. Muista, että jos suoritat vain palvelinpuolen sovelluksia, riippumattomien, keskitettyjen tai jaettujen globaalien klusteritoteutusten välillä on vähän eroja. Jokainen HTTP-pyyntö päätyy sovelluspalvelimeen, joka suorittaa prosessin sisäisen JNDI-haun palauttaakseen kaikki palvelinpuolen sovelluksessa käytetyt objektit.

Seuraavaksi kiinnitämme huomiomme toiseen tärkeään J2EE-sovelluspalvelimen näkökohtaan: klusteri- ja vikasietopalvelut.

Ryhmä- ja vikasietopalvelut

$config[zx-auto] not found$config[zx-overlay] not found