Programovanie

Klastrovanie J2EE, časť 1

Podniky si vyberajú Java 2, Enterprise Edition (J2EE) na doručovanie svojich kriticky dôležitých aplikácií cez web. V rámci J2EE poskytujú klastre dôležité služby na zabezpečenie minimálnych prestojov a maximálnej škálovateľnosti. Klaster je skupina aplikačných serverov, ktoré transparentne spúšťajú vašu aplikáciu J2EE, akoby išlo o jednu entitu. Ak chcete zväčšiť, mali by ste do klastra zahrnúť ďalšie stroje. Aby ste minimalizovali prestoje, uistite sa, že sú všetky komponenty klastra nadbytočné.

V tomto článku získame základné pochopenie klastrovania, klastrovacích metód a dôležitých klastrových služieb. Pretože klastrové prístupy sa v jednotlivých odvetviach líšia, preskúmame výhody a nevýhody jednotlivých prístupov. Ďalej si rozoberieme dôležité funkcie súvisiace s klastrami, ktoré treba hľadať na aplikačnom serveri.

Aby sme naše novo získané vedomosti o klastrovaní mohli aplikovať na skutočný svet, uvidíme, ako HP Bluestone Total-e-Server 7.2.1, Sybase Enterprise Application Server 3.6, SilverStream Application Server 3.7 a BEA WebLogic Server 6.0 implementujú klastre.

V časti 2 tejto série sa budeme venovať programovaniu a stratégiám prepnutia po zlyhaní pre klastre a tiež otestujeme naše štyri produkty aplikačného servera, aby sme zistili, ako sa škálovajú a prekonávajú zlyhania.

Klastre definované

Predajcovia aplikačných serverov J2EE definujú klaster ako skupinu strojov spolupracujúcich na transparentnom poskytovaní podnikových služieb (podpora JNDI, EJB, JSP, HttpSession a převzatia služieb pri zlyhaní atď.). Definíciu nechávajú zámerne vágnu, pretože každý predajca implementuje zoskupovanie inak. Na jednom konci spektra dodávatelia odpočinku, ktorí postavili dispečera pred skupinu nezávislých strojov, z ktorých žiadny nemá vedomosti o ostatných strojoch v klastri. V tejto schéme dispečer prijme počiatočnú požiadavku od používateľa a odpovie hlavičkou presmerovania HTTP, aby pripnul klienta na konkrétny členský server klastra. Na druhom konci spektra sídlia predajcovia, ktorí implementujú federáciu úzko integrovaných strojov, pričom každý stroj má úplné vedomosti o ostatných strojoch okolo seba a o objektoch na týchto strojoch.

Klastre môžu okrem strojov obsahovať aj nadbytočné a podporované služby pri zlyhaní:

  • Vyrovnávače zaťaženia: Jednotlivé vstupné body do klastra a riaditelia prenosu na jednotlivé webové alebo aplikačné servery
  • Webové servery
  • Gateway routery: Výstupné body z internej siete
  • Viacvrstvové prepínače: Filtre paketov a rámcov zaisťujú, že každý stroj v klastri prijíma iba informácie týkajúce sa tohto stroja
  • Brány firewall: Chrániče klastrov pred hackermi filtrovaním prístupu na úrovni portov do klastra a internej siete
  • Prepínače SAN (Storage Area Networking): Prepojte aplikačné servery, webové servery a databázy s back-endovým úložným médiom; spravovať, na ktorý fyzický disk sa majú zapisovať údaje; a zlyhanie
  • Databázy

Bez ohľadu na to, ako sú implementované, všetky klastre poskytujú dve hlavné výhody: škálovateľnosť a vysoká dostupnosť (HA).

Škálovateľnosť

Škálovateľnosť predstavuje schopnosť aplikácie podporovať rastúci počet používateľov. Klastre vám umožňujú poskytnúť ďalšiu kapacitu pridaním ďalších serverov, čím sa zabezpečí škálovateľnosť.

Vysoká dostupnosť

HA možno zhrnúť do jedného slova: nadbytočnosť. Klaster používa na vybavenie požiadaviek veľa počítačov. Preto ak zlyhá akýkoľvek stroj v klastri, môže ho transparentne prevziať iný stroj.

Klaster poskytuje HA iba na úrovni aplikačného servera. Aby webový systém mohol vykazovať skutočnú HA, musí to byť ako Noemova archa, ktorá obsahuje najmenej dva prvky vrátane webových serverov, smerovačov brán, prepínania infraštruktúr atď. (Viac informácií o HA nájdete v kontrolnom zozname HA.)

Typy klastrov

Klastre J2EE majú zvyčajne dve príchute: nezdieľalo nič a zdieľaný disk. V klastri shared-nothing má každý aplikačný server svoje vlastné súborové systémy s vlastnou kópiou aplikácií spustených v klastri. Aktualizácie a vylepšenia aplikácií si vyžadujú aktualizácie v každom uzle klastra. S týmto nastavením sa veľké klastre stávajú nočnými morami údržby, keď budú vydané kódy a aktualizácie.

Klaster zdieľaného disku naopak zamestnáva jedno úložné zariadenie, ktoré všetky aplikačné servery používajú na získanie aplikácií spustených v klastri. Aktualizácie a vylepšenia sa vyskytujú v jednom súborovom systéme a všetky stroje v klastri majú prístup k zmenám. Až donedávna bolo nevýhodou tohto prístupu jeho jediný bod zlyhania. SAN však poskytuje jediné logické rozhranie do redundantného úložného média, aby poskytlo zlyhanie, zlyhanie a škálovateľnosť. (Viac informácií o SAN nájdete na bočnom paneli Pamäťová infraštruktúra.)

Pri porovnaní implementácií klastrov aplikačných serverov J2EE je dôležité vziať do úvahy:

  • Klastrová implementácia
  • Služby záložných služieb klastrov a komponentov
  • Zlyhanie služby HttpSession
  • Jednotlivé body zlyhania v topológii klastra
  • Flexibilné rozloženie topológie
  • Údržba

Neskôr sa pozrieme na to, ako sú porovnávané štyri populárne aplikačné servery v rôznych oblastiach. Najprv však preskúmajme každú položku podrobnejšie.

Klastrová implementácia

Aplikačné servery J2EE implementujú klastrovanie okolo svojej implementácie JNDI (Java Naming and Directory Interface). Aj keď JNDI je základná služba, na ktorú sa aplikácie J2EE spoliehajú, je ťažké ju implementovať v klastri, pretože nemôže viazať viac objektov na jeden názov. Vo vzťahu k implementácii JNDI každého aplikačného servera existujú tri všeobecné spôsoby klastrovania:

  • Nezávislý
  • Centralizované
  • Zdieľané globálne

Nezávislý strom JNDI

HP Bluestone Total-e-Server a SilverStream aplikačný server využívajú pre každý aplikačný server nezávislý strom JNDI. Členské servery v nezávislom stromovom klastri JNDI nevedia o existencii ďalších serverov v klastri alebo sa o nich nestarajú. Zlyhanie po zlyhaní preto nie je podporované alebo poskytované prostredníctvom sprostredkovateľských služieb, ktoré presmerovávajú požiadavky HTTP alebo EJB. Tieto sprostredkovateľské služby sú nakonfigurované tak, aby vedeli, kde sa nachádza každý komponent v klastri, a ako sa dostať k alternatívnemu komponentu v prípade zlyhania.

Jednou výhodou nezávislého klastra stromov JNDI: kratšia konvergencia klastra a jednoduché škálovanie. Konvergencia klastra meria čas potrebný na to, aby si klaster plne uvedomil všetky stroje v klastri a s nimi spojené objekty. Konvergencia však nie je problémom nezávislého klastra stromov JNDI, pretože klaster dosiahne konvergenciu hneď po spustení dvoch strojov. Ďalšia výhoda nezávislého klastra stromov JNDI: zmena mierky vyžaduje iba pridanie ďalších serverov.

Existuje však niekoľko slabých stránok. Po prvé, zlyhanie je obvykle zodpovednosťou vývojára. To znamená, že pretože strom JNDI každého aplikačného servera je nezávislý, vzdialené servery proxy načítané cez JNDI sa pripnú na server, na ktorom sa uskutočnilo vyhľadávanie. V tomto scenári, ak zlyhanie volania metódy na EJB zlyhá, musí vývojár napísať ďalší kód na pripojenie k dispečerovi, získanie adresy iného aktívneho servera, ďalšie vyhľadanie JNDI a opätovné volanie neúspešnej metódy. Spoločnosť Bluestone implementuje komplikovanejšiu formu nezávislého stromu JNDI tak, že umožňuje každej požiadavke prejsť cez proxy službu EJB alebo Proxy LBB (Load Balance Broker). Služba proxy EJB zaisťuje, že každá požiadavka EJB ide do aktívnej inštancie UBS. Táto schéma dodáva každej požiadavke ďalšiu latenciu, ale umožňuje automatické prepnutie medzi hovormi metód.

Centralizovaný strom JNDI

Sybase Enterprise Application Server implementuje centralizovaný klaster stromov JNDI. V rámci tohto nastavenia využívajú centralizované stromové klastre JNDI službu CosNaming spoločnosti CORBA pre JNDI. Menné servery obsahujú centralizovaný strom JNDI pre klaster a sledujú, ktoré servery sú hore. Po spustení každý server v klastri viaže svoje objekty na svoj strom JNDI, ako aj na všetky menné servery.

Získanie odkazu na EJB v centralizovanom stromovom klastri JNDI je proces pozostávajúci z dvoch krokov. Najskôr klient vyhľadá domáci objekt z menného servera, ktorý vráti odkaz na interoperabilný objekt (IOR). IOR ukazuje na niekoľko aktívnych strojov v klastri, ktoré majú domáci objekt. Po druhé, klient vyberie prvé umiestnenie servera v IOR a získa domov a vzdialený server. Ak dôjde k zlyhaniu medzi vyvolaním metódy EJB, paket CORBA implementuje logiku na získanie iného domáceho alebo vzdialeného servera z alternatívneho servera uvedeného v IOR vrátenom z menného servera.

Samotné menné servery demonštrujú slabosť centralizovaného klastra stromov JNDI. Konkrétne, ak máte klaster s 50 počítačmi, z ktorých päť sú menné servery, klaster sa stane nepoužiteľným, ak všetkých päť menných serverov zlyhá. Ostatných 45 strojov by skutočne mohlo byť funkčných, ale klaster nebude fungovať ani jednému klientovi EJB, kým nebudú fungovať pomenovacie servery.

Ďalším problémom je uvedenie dodatočného menného servera do režimu online v prípade úplného zlyhania pôvodných menných serverov klastra. V takom prípade nový centralizovaný menný server vyžaduje, aby každý aktívny stroj v klastri naviazal svoje objekty na strom JNDI nového menného servera. Aj keď je možné začať prijímať požiadavky počas procesu viazania, nedoporučuje sa to, pretože proces viazania predlžuje čas obnovy klastra. Okrem toho každé vyhľadávanie JNDI z aplikácie alebo appletu skutočne predstavuje dva sieťové volania. Prvé volanie načítava IOR pre objekt z menného servera, zatiaľ čo druhé volá objekt, ktorý chce klient zo servera uvedeného v IOR.

A nakoniec, centralizované klastre stromov JNDI trpia zvýšeným časom konvergencie, pretože veľkosť klastra rastie. To znamená, že keď rozširujete svoj klaster, musíte pridať viac menných serverov. Majte na pamäti, že všeobecne akceptovaný pomer strojov názvového servera k celkovým strojom klastra je 1:10 s minimálnym počtom dvoch menných serverov. Preto ak máte klaster s 10 strojmi s dvoma mennými servermi, celkový počet väzieb medzi serverom a menným serverom je 20. V klastri so 40 strojmi so štyrmi mennými servermi bude 160 väzieb. Každá väzba predstavuje proces, v ktorom členský server viaže všetky svoje objekty na strom JNDI menného servera. Z tohto dôvodu má centralizovaný klaster stromov JNDI najhorší čas konvergencie zo všetkých implementácií klastra JNDI.

Zdieľaný globálny strom JNDI

Nakoniec BEA WebLogic implementuje zdieľaný globálny strom JNDI. S týmto prístupom pri spustení servera v klastri oznámi svoju existenciu a strom JNDI ostatným serverom v klastri prostredníctvom viacsmerového vysielania IP (internetový protokol). Každý zoskupený stroj spája svoje objekty do zdieľaného globálneho stromu JNDI, ako aj do vlastného lokálneho stromu JNDI.

Globálny a lokálny strom JNDI v rámci každého člena servera umožňuje generovaným domácim a vzdialeným stubom prekonať zlyhanie a poskytuje rýchle vyhľadanie JNDI v procese. Zdieľaný globálny strom JNDI je zdieľaný medzi všetkými strojmi v klastri, čo umožňuje každému členskému stroju poznať presné umiestnenie všetkých objektov v klastri. Ak je objekt k dispozícii na viac ako jednom serveri v klastri, špeciálny domáci objekt je naviazaný na zdieľaný globálny strom JNDI. Tento špeciálny domov pozná umiestnenie všetkých objektov EJB, s ktorými je spojený, a generuje vzdialené objekty, ktoré tiež poznajú umiestnenie všetkých objektov EJB, s ktorými je spojený.

Hlavné nevýhody zdieľaného globálneho prístupu: veľká počiatočná sieťová prevádzka generovaná pri spustení serverov a dlhý čas konvergencie klastra. Naproti tomu v nezávislom klastri stromov JNDI sa ukázalo, že konvergencia nie je problémom, pretože nedochádza k zdieľaniu informácií JNDI. Zdieľaný globálny alebo centralizovaný klaster však vyžaduje čas, aby všetky počítače klastra vytvorili zdieľaný globálny alebo centralizovaný strom JNDI. Pretože zdieľané globálne klastre používajú na prenos informácií JNDI multicast, čas potrebný na vytvorenie zdieľaného globálneho stromu JNDI je lineárny vo vzťahu k počtu ďalších pridaných serverov.

Hlavné výhody zdieľaného globálu v porovnaní s centralizovanými klastrami stromov JNDI sa sústreďujú na jednoduché škálovanie a vyššiu dostupnosť. V prípade zdieľaného globálu nemusíte manipulovať s procesormi a pamäťou RAM na vyhradenom serveri názvov alebo vyladiť počet serverov názvov v klastri. Namiesto toho pre zväčšenie rozsahu aplikácie stačí pridať viac strojov. Navyše, ak ktorýkoľvek stroj v klastri vypadne, klaster bude aj naďalej fungovať správne. Nakoniec každé vzdialené vyhľadávanie vyžaduje jedno sieťové volanie v porovnaní s dvoma sieťovými volaniami požadovanými v centralizovanom stromovom klastri JNDI.

To všetko by sa malo brať s rezervou, pretože servery JSP, servlety, EJB a JavaBeans bežiace na aplikačnom serveri môžu využívať spoločné umiestnenie na serveri EJB. Vždy použijú procesné vyhľadávanie JNDI. Nezabudnite, že ak spúšťate iba aplikácie na strane servera, medzi implementáciami nezávislých, centralizovaných alebo zdieľaných globálnych klastrov existuje malý rozdiel. Každá požiadavka HTTP v skutočnosti skončí na aplikačnom serveri, ktorý vykoná procesné vyhľadávanie JNDI, aby vrátil akýkoľvek objekt použitý vo vašej aplikácii na strane servera.

Ďalej upriamime našu pozornosť na druhý dôležitý aspekt aplikačného servera J2EE: služby klastra a prepnutia po zlyhaní.

Klastrové a záložné služby

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