Podniky si vybírají prostředí Java 2, Enterprise Edition (J2EE) pro doručování svých kriticky důležitých aplikací přes web. V rámci J2EE poskytují clustery důležité služby, aby zajistily minimální prostoje a maximální škálovatelnost. Klastr je skupina aplikačních serverů, které transparentně spouštějí vaši aplikaci J2EE, jako by to byla jedna entita. Chcete-li škálovat, měli byste do clusteru zahrnout další stroje. Chcete-li minimalizovat prostoje, ujistěte se, že každá součást klastru je nadbytečná.
V tomto článku získáme základní znalosti o klastrování, klastrovacích metodách a důležitých klastrových službách. Vzhledem k tomu, že se shlukovací přístupy v různých odvětvích liší, prozkoumáme výhody a nevýhody jednotlivých přístupů. Dále probereme důležité funkce související s klastry, které je třeba hledat na aplikačním serveru.
Abychom naše nově získané znalosti o klastrování mohli aplikovat na skutečný svět, uvidíme, jak 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í clustery.
V části 2 této série se budeme zabývat strategiemi programování a převzetí služeb při selhání pro clustery a také otestujeme naše čtyři produkty aplikačního serveru, abychom zjistili, jak se škálovají a převzetí služeb při selhání.
Klastry jsou definovány
Prodejci aplikačních serverů J2EE definují klastr jako skupinu strojů spolupracujících na transparentním poskytování podnikových služeb (podpora JNDI, EJB, JSP, HttpSession a převzetí služeb při selhání komponent atd.). Definici nechávají záměrně vágní, protože každý prodejce implementuje shlukování odlišně. Na jednom konci spektra prodejci odpočinku, kteří postavili dispečera před skupinu nezávislých strojů, z nichž žádný nemá znalosti o ostatních strojích v klastru. V tomto schématu dispečer obdrží počáteční požadavek od uživatele a odpoví záhlaví přesměrování HTTP, aby připnul klienta na konkrétní členský server klastru. Na druhém konci spektra sídlí prodejci, kteří implementují federaci těsně integrovaných strojů, přičemž každý stroj si je plně vědom ostatních strojů kolem něj a objektů na těchto strojích.
Kromě strojů mohou clustery zahrnovat redundantní a převzetí služeb při selhání:
- Vyrovnávače zatížení: Jednotlivé vstupní body do klastru a směrovače provozu na jednotlivé webové nebo aplikační servery
- Webové servery
- Směrovače brány: Výstupní body z interní sítě
- Vícevrstvé přepínače: Filtry paketů a rámců zajišťují, že každý počítač v klastru přijímá pouze informace týkající se tohoto stroje
- Firewally: Chrániče klastrů před hackery filtrováním přístupu na úrovni portů ke klastru a interní síti
- Přepínače SAN (Storage Area Networking): Připojte aplikační servery, webové servery a databáze k back-endovému úložnému médiu; spravovat, na který fyzický disk zapisovat data; a převzetí služeb při selhání
- Databáze
Bez ohledu na to, jak jsou implementovány, poskytují všechny clustery dvě hlavní výhody: škálovatelnost a vysoká dostupnost (HA).
Škálovatelnost
Škálovatelnost označuje schopnost aplikace podporovat rostoucí počet uživatelů. Klastry vám umožňují poskytnout další kapacitu přidáním dalších serverů, čímž se zajistí škálovatelnost.
Vysoká dostupnost
HA lze shrnout do jednoho slova: redundance. Klastr používá k poskytování požadavků mnoho počítačů. Pokud tedy některý stroj v klastru selže, může jej transparentně převzít jiný stroj.
Klastr poskytuje HA pouze na úrovni aplikačního serveru. Aby webový systém vykazoval skutečnou HA, musí to být jako Noemova archa obsahující alespoň dva ze všeho, včetně webových serverů, směrovačů brány, přepínání infrastruktur atd. (Další informace o HA najdete v kontrolním seznamu HA.)
Typy klastrů
Klastry J2EE obvykle přicházejí ve dvou příchutích: nesdílel nic a sdílený disk. V klastru shared-nothing má každý aplikační server vlastní souborové systémy s vlastní kopií aplikací spuštěných v klastru. Aktualizace a vylepšení aplikací vyžadují aktualizace v každém uzlu v clusteru. S tímto nastavením se velké clustery stanou nočními můrami údržby, když budou vydány kódy a aktualizace.
Naproti tomu klastr se sdíleným diskem využívá jedno úložné zařízení, které všechny aplikační servery používají k získání aplikací spuštěných v klastru. K aktualizacím a vylepšením dochází v jednom souborovém systému a ke změnám mají přístup všechny počítače v klastru. Až donedávna byla nevýhodou tohoto přístupu jeho jediný bod selhání. SAN však poskytuje jedno logické rozhraní do redundantního paměťového média, aby poskytlo převzetí služeb při selhání, navrácení služeb po selhání a škálovatelnost. (Další informace o SAN najdete na postranním panelu Storage Infrastructure.)
Při porovnávání implementací clusteru aplikačních serverů J2EE je důležité vzít v úvahu:
- Implementace klastru
- Služby převzetí služeb při selhání clusteru a komponent
- Překonání selhání HttpSession
- Jednotlivé body selhání v topologii clusteru
- Flexibilní rozložení topologie
- Údržba
Později se podíváme na srovnání čtyř populárních aplikačních serverů v různých oblastech. Nejprve se ale podívejme na každou položku podrobněji.
Implementace klastru
Aplikační servery J2EE implementují shlukování kolem své implementace JNDI (Java Naming and Directory Interface). Ačkoli JNDI je základní služba, na kterou se aplikace J2EE spoléhají, je obtížné ji implementovat v klastru, protože nemůže vázat více objektů na jeden název. Ve vztahu k implementaci JNDI každého aplikačního serveru existují tři obecné metody klastrování:
- Nezávislý
- Centralizované
- Sdílené globální
Nezávislý strom JNDI
HP Bluestone Total-e-Server a SilverStream Application Server využívají pro každý aplikační server nezávislý strom JNDI. Členské servery v nezávislém stromovém klastru JNDI nevědí nebo se nestarají o existenci dalších serverů v klastru. Proto převzetí služeb při selhání není podporováno nebo poskytováno prostřednictvím zprostředkovatelských služeb, které přesměrovávají požadavky HTTP nebo EJB. Tyto zprostředkovatelské služby jsou nakonfigurovány tak, aby věděly, kde se každá komponenta v klastru nachází a jak se v případě selhání dostat k alternativní komponentě.
Jedna výhoda nezávislého stromového klastru JNDI: kratší konvergence klastru a snadné škálování. Konvergence klastru měří čas potřebný k tomu, aby si klastr plně uvědomil všechny stroje v klastru a jejich přidružené objekty. Konvergence však není problémem v nezávislém klastru stromů JNDI, protože klastr dosáhne konvergence hned po spuštění dvou strojů. Další výhoda nezávislého klastru stromů JNDI: škálování vyžaduje pouze přidání dalších serverů.
Existuje však několik slabin. Za prvé, převzetí služeb při selhání je obvykle odpovědností vývojáře. To znamená, že protože strom JNDI každého aplikačního serveru je nezávislý, jsou vzdálené servery proxy načtené prostřednictvím rozhraní JNDI připnuty na server, na kterém došlo k vyhledání. V tomto scénáři, pokud volání metody na EJB selže, musí vývojář napsat další kód pro připojení k dispečerovi, získat adresu jiného aktivního serveru, provést další vyhledávání JNDI a znovu zavolat neúspěšnou metodu. Bluestone implementuje komplikovanější formu nezávislého stromu JNDI tak, že každý požadavek projde proxy službou EJB nebo Proxy LBB (Load Balance Broker). Služba proxy EJB zajišťuje, že každý požadavek EJB jde do aktivní instance UBS. Toto schéma přidává další latenci ke každému požadavku, ale umožňuje automatické převzetí služeb při selhání mezi voláními metody.
Centralizovaný strom JNDI
Sybase Enterprise Application Server implementuje centralizovaný stromový klastr JNDI. V rámci tohoto nastavení využívají centralizované stromové klastry JNDI službu CORBA CosNaming pro JNDI. Názvové servery obsahují centralizovaný strom JNDI pro klastr a sledují, které servery jsou aktivní. Po spuštění každý server v klastru váže své objekty do svého stromu JNDI a také na všechny jmenné servery.
Získání odkazu na EJB v centralizovaném klastru stromů JNDI je dvoustupňový proces. Nejprve klient vyhledá domácí objekt z názvového serveru, který vrátí odkaz na interoperabilní objekt (IOR). IOR ukazuje na několik aktivních strojů v klastru, které mají domovský objekt. Zadruhé, klient vybere první umístění serveru v IOR a získá domácí a vzdálené. Pokud dojde k selhání mezi vyvoláním metody EJB, implementuje pahýl CORBA logiku k načtení jiného domovského nebo vzdáleného serveru z alternativního serveru uvedeného v IOR vráceném ze jmenného serveru.
Samotné jmenné servery ukazují slabost centralizovaného klastru stromů JNDI. Konkrétně, pokud máte klastr 50 počítačů, z nichž pět jsou jmenné servery, klastr se stane nepoužitelným, pokud všech pět jmenných serverů poklesne. Ostatních 45 strojů by skutečně mohlo být v provozu, ale cluster nebude obsluhovat jediného klienta EJB, zatímco jsou nepojmenované servery v provozu.
Další problém nastává v případě uvedení dalšího jmenného serveru do režimu online v případě úplného selhání původních jmenných serverů klastru. V tomto případě nový centralizovaný jmenný server vyžaduje, aby každý aktivní stroj v klastru svázal své objekty do stromu JNDI nového jmenného serveru. I když je možné začít přijímat požadavky, zatímco probíhá proces vazby, nedoporučuje se to, protože proces vazby prodlužuje dobu zotavení clusteru. Kromě toho každé vyhledávání JNDI z aplikace nebo appletu skutečně představuje dvě síťová volání. První volání načte IOR pro objekt ze jmenného serveru, zatímco druhé načte objekt, který chce klient ze serveru uvedeného v IOR.
Nakonec centralizované stromové klastry JNDI trpí zvýšenou dobou konvergence, jak se velikost klastru zvětšuje. To znamená, že při škálování clusteru musíte přidat více jmenných serverů. Mějte na paměti, že obecně přijímaný poměr strojů jmenného serveru k celkovým strojům clusteru je 1:10, s minimálním počtem dvou jmenných serverů. Proto pokud máte klastr 10 strojů se dvěma jmennými servery, je celkový počet vazeb mezi serverem a jmenným serverem 20. V klastru 40 strojů se čtyřmi jmennými servery bude 160 vazeb. Každá vazba představuje proces, ve kterém členský server váže všechny své objekty do stromu JNDI jmenného serveru. S ohledem na to má centralizovaný stromový klastr JNDI nejhorší dobu konvergence mezi všemi implementacemi klastru JNDI.
Sdílený globální strom JNDI
Nakonec BEA WebLogic implementuje sdílený globální strom JNDI. S tímto přístupem při spuštění serveru v klastru oznámí svou existenci a strom JNDI ostatním serverům v klastru prostřednictvím vícesměrového vysílání IP (internetový protokol). Každý seskupený stroj váže své objekty do sdíleného globálního stromu JNDI i do vlastního lokálního stromu JNDI.
Globální a místní strom JNDI v každém členském serveru umožňuje generovaným domovským a vzdáleným stubům převzetí služeb při selhání a poskytuje rychlé průběžné vyhledávání JNDI. Sdílený globální strom JNDI je sdílen mezi všemi počítači v klastru, což umožňuje každému členskému počítači znát přesné umístění všech objektů v klastru. Pokud je objekt k dispozici na více než jednom serveru v klastru, je speciální domovský objekt svázán do sdíleného globálního stromu JNDI. Tento speciální domov zná umístění všech objektů EJB, se kterými je spojen, a generuje vzdálené objekty, které také znají umístění všech objektů EJB, se kterými je spojen.
Hlavní nevýhody sdíleného globálního přístupu: velký počáteční síťový provoz generovaný při spuštění serverů a dlouhá doba konvergence klastru. Naproti tomu v nezávislém klastru stromů JNDI se ukázalo, že konvergence není problém, protože nedochází ke sdílení informací JNDI. Sdílený globální nebo centralizovaný klastr však vyžaduje čas, aby všechny stroje clusteru vytvořily sdílený globální nebo centralizovaný strom JNDI. Protože sdílené globální klastry používají vícesměrové vysílání k přenosu informací JNDI, čas potřebný k vytvoření sdíleného globálního stromu JNDI je lineární ve vztahu k počtu přidaných dalších serverů.
Hlavní výhody sdíleného globálu ve srovnání s centralizovanými stromovými klastry JNDI se soustředí na snadné škálování a vyšší dostupnost. Ve sdíleném globálním prostředí nemusíte hrát s CPU a RAM na vyhrazeném jmenném serveru ani ladit počet jmenných serverů v klastru. Spíše pro škálování aplikace stačí přidat další stroje. Navíc pokud některý stroj v klastru spadne, bude klastr nadále správně fungovat. Nakonec každé vzdálené vyhledávání vyžaduje jedno síťové volání ve srovnání se dvěma síťovými voláními požadovanými v centralizovaném stromovém klastru JNDI.
To vše by mělo být bráno s rezervou, protože JSP, servlety, EJB a JavaBeans běžící na aplikačním serveru mohou těžit z toho, že budou umístěny společně na serveru EJB. Vždy použijí vyhledávání JNDI v procesu. Mějte na paměti, že pokud spouštíte pouze aplikace na straně serveru, mezi nezávislými, centralizovanými nebo sdílenými implementacemi globálního klastru existuje malý rozdíl. Ve skutečnosti každý požadavek HTTP skončí na aplikačním serveru, který provede procesní vyhledávání JNDI, aby vrátil jakýkoli objekt použitý ve vaší aplikaci na straně serveru.
Dále zaměříme naši pozornost na druhý důležitý aspekt aplikačního serveru J2EE: služby clusteru a převzetí služeb při selhání.
