Uzņēmumi izvēlas Java 2, Enterprise Edition (J2EE), lai savas misijai kritiskās lietojumprogrammas piegādātu tīmeklī. J2EE ietvaros kopas nodrošina ar misiju saistītus pakalpojumus, lai nodrošinātu minimālu dīkstāvi un maksimālu mērogojamību. Klasteris ir lietojumprogrammu serveru grupa, kas pārredzami palaiž jūsu J2EE lietojumprogrammu tā, it kā tā būtu viena entītija. Lai mērogotu, klasterī jāiekļauj papildu mašīnas. Lai samazinātu dīkstāvi, pārliecinieties, ka visi klastera komponenti ir lieki.
Šajā rakstā mēs iegūsim pamatinformāciju par kopu veidošanu, kopu veidošanas metodēm un svarīgiem kopu pakalpojumiem. Tā kā klasterizācijas pieejas nozarē ir atšķirīgas, mēs pārbaudīsim katras pieejas priekšrocības un trūkumus. Tālāk mēs apspriedīsim svarīgās ar klasteru saistītās funkcijas, kas jāmeklē lietojumprogrammu serverī.
Lai pielietotu jauniegūtās kopu zināšanas reālajā pasaulē, mēs redzēsim, kā katrs HP Bluestone Total-e-Server 7.2.1, Sybase Enterprise Application Server 3.6, SilverStream Application Server 3.7 un BEA WebLogic Server 6.0 ievieš klasterus.
Šīs sērijas 2. daļā mēs aplūkosim kopu programmēšanas un kļūmjpārlēces stratēģijas, kā arī pārbaudīsim četrus lietojumprogrammu serveru produktus, lai uzzinātu, kā tie mērogojas un kļūmjpārlēces.
Definētas kopas
J2EE lietojumprogrammu serveru piegādātāji nosaka kopu kā mašīnu grupu, kas strādā kopā, lai pārredzami sniegtu uzņēmuma pakalpojumus (atbalsts JNDI, EJB, JSP, HttpSession un komponentu kļūmjpārlēcei utt.). Viņi atstāj definīciju tīri neskaidru, jo katrs pārdevējs klasteru izveidi īsteno atšķirīgi. Spektra vienā galā atrodas pārdevēji, kuri dispečeru novieto neatkarīgu mašīnu grupas priekšā, no kuriem nevienam nav zināšanu par citām klastera mašīnām. Šajā shēmā dispečers saņem sākotnēju pieprasījumu no lietotāja un atbild ar HTTP novirzīšanas galveni, lai piesaistītu klientu konkrētam klastera dalībnieka serverim. Spektra otrajā galā dzīvo pārdevēji, kas ievieš cieši integrētu mašīnu federāciju, katrai mašīnai pilnībā apzinoties citas ap to esošās mašīnas, kā arī šo mašīnu objektus.
Papildus mašīnām kopas var ietvert arī liekus un pēc iespējas pārejas gadījumus:
- Slodzes līdzsvarotāji: Atsevišķi ieejas punkti klasterī un satiksmes vadītāji uz atsevišķiem tīmekļa vai lietojumprogrammu serveriem
- Tīmekļa serveri
- Vārtejas maršrutētāji: Izejas punkti no iekšējā tīkla
- Daudzslāņu slēdži: Pakešu un rāmju filtri, lai nodrošinātu, ka katra klastera mašīna saņem tikai ar šo mašīnu saistītu informāciju
- Ugunsmūri: Klasteru aizsargi no hakeriem, filtrējot porta līmeņa piekļuvi klasterim un iekšējam tīklam
- SAN (Storage Area Networking) slēdži: Savienojiet lietojumprogrammu serverus, tīmekļa serverus un datu bāzes ar aizmugures datu nesēju; pārvaldīt, kurā fiziskajā diskā rakstīt datus; un atteice
- Datu bāzes
Neatkarīgi no tā, kā tie tiek ieviesti, visām kopām ir divi galvenie ieguvumi: mērogojamība un augsta pieejamība (HA).
Mērogojamība
Mērogojamība attiecas uz lietojumprogrammas spēju atbalstīt arvien lielāku lietotāju skaitu. Klasteri ļauj nodrošināt papildu ietilpību, pievienojot papildu serverus, tādējādi nodrošinot mērogojamību.
Augsta pieejamība
HA var apkopot ar vienu vārdu: atlaišana. Klasteris pieprasījumu apkalpošanai izmanto daudzas mašīnas. Tādēļ, ja kāda klastera mašīna neizdodas, cita mašīna var pārredzami pārņemt.
Klasteris nodrošina HA tikai lietojumprogrammu servera līmenī. Lai tīmekļa sistēma demonstrētu patiesu HA, tai jābūt līdzīgai Noasa šķirstam, kurā ir vismaz divi no visa, ieskaitot tīmekļa serverus, vārtejas maršrutētājus, komutācijas infrastruktūras utt. (Lai uzzinātu vairāk par HA, skatiet HA kontrolsarakstu.)
Kopu veidi
J2EE kopām parasti ir divas garšas: neko nedalīja un koplietojamais disks. Koplietojamā nekā kopā katram lietojumprogrammu serverim ir savas failu sistēmas ar savu lietojumprogrammu kopiju, kas darbojas klasterī. Lietojumprogrammu atjauninājumiem un uzlabojumiem ir nepieciešami atjauninājumi katrā klastera mezglā. Ar šo iestatīšanu lieli kopas kļūst par apkopes murgiem, kad tiek nospiedts kods un tiek izlaisti atjauninājumi.
Turpretī koplietojamā diska klasteris izmanto vienu atmiņas ierīci, kuru visi lietojumprogrammu serveri izmanto, lai iegūtu klasterī darbojošās lietojumprogrammas. Atjauninājumi un uzlabojumi notiek vienā failu sistēmā, un visas klastera mašīnas var piekļūt izmaiņām. Vēl nesen šīs pieejas negatīvie punkti bija tās vienīgais neveiksmes punkts. Tomēr SAN liekā datu nesējā nodrošina vienu loģisku saskarni, lai nodrošinātu kļūmjpārlēces, atteices un mērogojamības iespējas. (Lai uzzinātu vairāk par SAN, skatiet krātuves infrastruktūras sānjoslu.)
Salīdzinot J2EE lietojumprogrammu serveru kopu ieviešanu, ir svarīgi apsvērt:
- Klastera ieviešana
- Klasteru un komponentu kļūmjpārlēces pakalpojumi
- HttpSession kļūme
- Atsevišķi neveiksmes punkti klastera topoloģijā
- Elastīgs topoloģijas izkārtojums
- Apkope
Vēlāk mēs apskatīsim, kā četros populāros lietojumprogrammu serveros tiek salīdzinātas dažādās jomās. Bet vispirms apskatīsim katru priekšmetu sīkāk.
Klastera ieviešana
J2EE lietojumprogrammu serveri īsteno kopu ap JNDI (Java Naming and Directory Interface) ieviešanu. Lai gan JNDI ir galvenais pakalpojums, uz kuru paļaujas J2EE lietojumprogrammas, to ir grūti ieviest klasterī, jo tas nevar saistīt vairākus objektus ar vienu vārdu. Attiecībā uz katra lietojumprogrammas servera JNDI ieviešanu pastāv trīs vispārīgas klasterizācijas metodes:
- Neatkarīgs
- Centralizēts
- Kopīgi globāli
Neatkarīgais JNDI koks
HP Bluestone Total-e-Server un SilverStream lietojumprogrammu serveris katram lietojumprogrammu serverim izmanto neatkarīgu JNDI koku. Biedru serveri neatkarīgā JNDI koku klasterī nezina vai rūpējas par citu klastera serveru esamību. Tādēļ kļūmjpārlēce netiek atbalstīta vai nodrošināta, izmantojot starpniecības pakalpojumus, kas novirza HTTP vai EJB pieprasījumus. Šie starpniecības pakalpojumi ir konfigurēti tā, lai zinātu, kur atrodas katrs klastera komponents, un kā atteices gadījumā nokļūt pie alternatīvā komponenta.
Viena neatkarīgās JNDI koku kopas priekšrocība: īsāka kopu konverģence un mērogošanas vieglums. Klastera konverģence mēra laiku, kas nepieciešams, lai klasteris pilnībā apzinātos visas klastera mašīnas un ar tām saistītos objektus. Tomēr konverģence nav jautājums neatkarīgā JNDI koku klasterī, jo kopa sasniedz konverģenci, tiklīdz tiek palaistas divas mašīnas. Vēl viena neatkarīgās JNDI koku kopas priekšrocība: mērogošanai ir nepieciešams pievienot tikai papildu serverus.
Tomēr pastāv vairākas vājās vietas. Pirmkārt, kļūmes pārsūtīšana parasti ir izstrādātāja atbildība. Tas ir, tā kā katra lietojumprogrammas servera JNDI koks ir neatkarīgs, ar JNDI izgūtos attālinātos starpniekserverus piesprauž serverim, kurā notika uzmeklēšana. Saskaņā ar šo scenāriju, ja metodes izsaukšana uz EJB neizdodas, izstrādātājam ir jāuzraksta papildu kods, lai izveidotu savienojumu ar dispečeru, jāiegūst cita aktīvā servera adrese, jāveic vēl viena JNDI uzmeklēšana un vēlreiz jāizsauc neveiksmīgā metode. Bluestone ievieš sarežģītāku neatkarīgā JNDI koka formu, liekot katram pieprasījumam iet caur EJB starpniekserveri vai starpniekserveri LBB (Load Balance Broker). EJB starpniekserveris nodrošina, ka katrs EJB pieprasījums nonāk aktīvā UBS instancē. Šī shēma katram pieprasījumam pievieno papildu latentumu, bet ļauj automātiski veikt pārsūtīšanu starp metodes izsaukumiem.
Centralizēts JNDI koks
Sybase Enterprise Application Server ievieš centralizētu JNDI koku kopu. Šajā iestatījumā centralizētās JNDI koku kopas izmanto CORBA CosNaming pakalpojumu JNDI. Vārdu serveri izvieto klastera centralizēto JNDI koku un seko līdzi, kuri serveri darbojas. Pēc startēšanas katrs klastera serveris saista objektus savā JNDI kokā, kā arī visos vārdu serveros.
Atsauces iegūšana uz EJB centralizētā JNDI koku kopā ir divpakāpju process. Pirmkārt, klients uzmeklē mājas objektu no vārdu servera, kas atgriež sadarbspējīga objekta atsauci (IOR). IOR norāda uz vairākām klastera aktīvām mašīnām, kurām ir mājas objekts. Otrkārt, klients izvēlas pirmo servera atrašanās vietu IOR un iegūst mājas un tālvadības pulti. Ja starp EJB metodes izsaukšanu notiek kļūme, CORBA stūris ievieš loģiku, lai izgūtu citu māju vai tālvadības pulti no alternatīvā servera, kas uzskaitīts IOR, kas atgriezts no vārdu servera.
Vārdu serveri paši parāda centralizētās JNDI koku kopas vājumu. Ja jums ir 50 mašīnu kopa, no kurām piecas ir vārdu serveri, kopa kļūst nederīga, ja visi pieci vārdu serveri nedarbojas. Patiešām, pārējās 45 mašīnas varētu darboties un darboties, bet kopa neapkalpos nevienu EJB klientu, kamēr nedarbojas nosaukumu serveri.
Vēl viena problēma rodas no papildu vārdu servera pieslēgšanas tiešsaistē kopas sākotnējo vārdu serveru pilnīgas kļūmes gadījumā. Šajā gadījumā jaunam centralizētam vārdu serverim ir nepieciešams, lai katra klastera aktīvā mašīna saistītu savus objektus jaunā vārdu servera JNDI kokā. Lai gan ir iespējams sākt saņemt pieprasījumus, kamēr notiek saistīšanas process, tas nav ieteicams, jo saistīšanas process pagarina kopas atkopšanas laiku. Turklāt katrs JNDI uzmeklējums no lietojumprogrammas vai sīklietotnes patiešām pārstāv divus tīkla zvanus. Pirmais zvans izgūst objekta IOR no vārdu servera, bet otrais izgūst objektu, kuru klients vēlas, no IOR norādītā servera.
Visbeidzot, centralizētās JNDI koku kopas cieš no ilgāka laika līdz konverģencei, kad kopa palielinās. Tas nozīmē, ka, mērogojot klasteri, jāpievieno vairāk vārdu serveru. Paturiet prātā, ka vispāratzītā vārdu serveru mašīnu un kopu kopu mašīnu attiecība ir 1:10 ar minimālo divu serveru skaitu. Tāpēc, ja jums ir 10 mašīnu kopa ar diviem vārdu serveriem, kopējais saišu skaits starp serveri un vārdu serveri ir 20. 40 mašīnu klasterī ar četriem vārdu serveriem būs 160 sasaistes. Katra saistīšana apzīmē procesu, kurā dalībnieka serveris visus savus objektus iesaista vārdu servera JNDI kokā. Paturot to prātā, centralizētajai JNDI koku kopai ir vissliktākais konverģences laiks starp visām JNDI kopu ieviešanām.
Kopīgs globālais JNDI koks
Visbeidzot, BEA WebLogic ievieš kopīgu globālu JNDI koku. Izmantojot šo pieeju, palaižot klastera serveri, tas paziņo par savu eksistenci un JNDI koku citiem klastera serveriem, izmantojot IP (Internet Protocol) multicast. Katra grupēta mašīna iesaista savus objektus kopīgajā globālajā JNDI kokā, kā arī savā lokālajā JNDI kokā.
Globāla un lokāla JNDI koka izvietošana katrā dalībnieka serverī ļauj izveidotajiem mājas un attālinātajiem posmiem kļūmes un nodrošina ātru JNDI meklēšanu procesā. Kopīgais globālais JNDI koks tiek koplietots starp visām klastera mašīnām, ļaujot jebkurai dalībnieku mašīnai uzzināt precīzu visu klastera objektu atrašanās vietu. Ja objekts ir pieejams vairākos vienā klastera serveros, koplietojamā globālā JNDI kokā tiek piesaistīts īpašs mājas objekts. Šī īpašā māja zina visu to EJB objektu atrašanās vietu, ar kuriem tā ir saistīta, un ģenerē attālinātus objektus, kas zina arī visu EJB objektu atrašanās vietu, ar kuriem tā ir saistīta.
Dalītās globālās pieejas galvenie trūkumi: liela sākotnējā tīkla trafika, kas rodas, palaižot serverus, un klastera ilgais konverģences laiks. Turpretī neatkarīgā JNDI koku kopā konverģence izrādās problēma, jo nenotiek JNDI informācijas koplietošana. Tomēr kopīgai globālai vai centralizētai kopai ir nepieciešams laiks, lai visas kopas mašīnas izveidotu kopīgu globālu vai centralizētu JNDI koku. Patiešām, tā kā kopīgās globālās kopas JNDI informācijas pārsūtīšanai izmanto multiraides, koplietojamā globālā JNDI koka izveidošanai nepieciešamais laiks ir lineārs attiecībā pret nākamo pievienoto serveru skaitu.
Galvenās kopīgās globālās priekšrocības salīdzinājumā ar centralizētajām JNDI koku kopām ir vērstas uz mērogošanas vieglumu un augstāku pieejamību. Izmantojot koplietojamo globālo, jums nav jāturpina ar centrālajiem procesoriem un RAM īpašā vārdu serverī vai jānoregulē nosaukumu serveru skaits klasterī. Drīzāk, lai paplašinātu lietojumprogrammu, vienkārši pievienojiet vairāk mašīnu. Turklāt, ja kāda klastera mašīna iet uz leju, klasteris turpinās darboties pareizi. Visbeidzot, katram attālajam meklējumam ir nepieciešams viens tīkla zvans, salīdzinot ar diviem tīkla zvaniem, kas nepieciešami centralizētajā JNDI koku kopā.
Tas viss ir jāuzņem ar sāls graudu, jo JSP, servleti, EJB un JavaBeans, kas darbojas lietojumprogrammu serverī, var izmantot to, ka viņi atrodas līdzās EJB serverī. Viņi vienmēr izmantos procesā esošo JNDI uzmeklēšanu. Paturiet prātā, ka, palaižot tikai servera puses lietojumprogrammas, ir maz atšķirību starp neatkarīgo, centralizēto vai koplietojamo globālo kopu ieviešanu. Patiešām, katrs HTTP pieprasījums nonāks lietojumprogrammu serverī, kas procesa laikā veiks JNDI meklēšanu, lai atgrieztu jebkuru objektu, kas izmantots jūsu servera puses lietojumprogrammā.
Tālāk mēs pievēršam uzmanību otrajam svarīgajam J2EE lietojumprogrammu servera apsvērumam: kopu un kļūmjpārlēces pakalpojumiem.
