Lukáš Kubásek

Po nedávno publikovaném článku Představení frameworku JBoss Seam zveřejňuji ještě jeden materiál „ze šuplíku“.

Před krátkým časem jsem se na základě vynikajícího Dagiho článku JBoss cluster krok za krokem rozhodl vyzkoušet jednoduchý cluster nad aplikačním serverem JBoss. Poznámky z mého bádání jsem shrnul ve formě článku a publikoval na našem firemním intranetu. Protože se jedná o téma navýsost zajímavé, uveřejňuji tento článek i zde na svém blogu. Třeba někoho také inspiruji k postavení malého testovacího domácího clusteru.

Základní znalosti o paralelních systémech

Věda o paralelních systémech a paralelních výpočtech je propracovaná a dosti komplexní disciplína, jejíž výsledky nám umožňují používat dříve nevídané, avšak dnes naprosto běžné vysoce spolehlivé distribuované systémy bank, finančních a vládních institucí i soukromých průmyslových společností.

Zajímavý zdroj:

http://www.top500­.org – pravidelná aktualizace seznamu pěti set nejvýkonnějších počítačů světa.

Cluster (česky též svazek) je obecně definován a vnímán jako skupina výpočetních prostředků pracujících společně za určitým cílem (obvykle řešení velkých a náročných problémů). Výrobci J2EE aplikačních serverů definují naproti tomu obvykle cluster jako skupinu počítačů transparentně a paralelně poskytujících enterprise služby (JNDI, EJB, HttpSession, atd.).

Každý J2EE aplikační server implementuje pojem „cluster“ trochu odlišně, jedno mají však společné. Poskytují aplikacím dva hlavní benefity:

• škálovatelnost (scalability) – možnost přidat ke stávajícímu clusteru postupně jeden nebo více systémů, pokud celkové zatížení clusteru přesáhne jeho možnosti
• vysokou dostupnost (high availability) – dostupnost služby i při výpadku některého uzlu clusteru.

Prostředkem pro vyvažování zátěže mezi uzly je mechanizmus rozkládání zátěže zvaný load balancing.

Fyzická infrastruktura clusterů je problematikou značně obsáhlou. Existuje mnoho řešení od různých výrobců lišících se principem i filozofií a jejich popis je vysoce nad rámec tohoto článku. Mnoho zajímavých informací ze světa paralelních systémů a výpočtů, modelů a architektur paralelních systémů, vyhodnocování složitosti paralelních výpočtů, typů propojovacích sítí a dalších tématech v českém jazyce viz. literatura [8] v seznamu na konci článku.

Clustering J2EE aplikací a aplikační server JBoss

JBoss AS poskytuje služby clusteringu na poměrně vyspělé úrovni a disponuje širokou škálou poskytovaných služeb. JBoss cluster (zvaný též partition) je skupina fyzických nebo logických instancí JBoss serverů. Každý cluster je konfigurován pomocí ClusterPartition MBean komponenty, jejíz konfigurační soubor je deploy/cluster-service.xml.

Všechny uzly, které mají stejně nakonfigurovanou ClusterPartition, tvoří automaticky jeden cluster. Nejjednodušší cesta, jak vytvořit jednoduchý cluster je spustit předpřipravenou instanci „all“ JBoss serveru pomocí příkazu „run.bat -c all“ na více počítačích v lokální síti. JBoss si sám najde ostatní uzly pomocí autodetekčního mechanizmu (auto-discover) a funkční cluster je hotov.

Architektura clusteru z hlediska klientské aplikace

Z hlediska klienta nabízí JBoss dvě různé architektury, client-side interceptors (nebo také proxy či stub) a load balancery.

Na architektuře client-side interceptor jsou postaveny služby jako JNDI, EJB či RMI. Podstatou je objekt (stub, proxy), který musí klientská aplikace získat. Proxy objekt implementuje business rozhraní dané služby.

Architektura load balancer je na druhé straně typická pro HTTP a webové služby. Klient nemusí stahovat žádné objekty, jen posílá požadavky na uzel load balancer, který jediný musí znát.

Typy load balancingu v JBossu

JBoss podporuje tři různé politiky load balancingu.

• Round Robin (org.jboss.ha­.framework.in­terfaces.RoundRo­bin) – každé volání je posíláno na jiný uzel, první je vybrán náhodně.
• First Available (org.jboss.ha­.framework.in­terfaces.FirstA­vailable) – jeden z právě dostupných uzlů je náhodně vybrán jako hlavní a ten je využíván pro všechna volání. Pokud se hlavní uzel stane nedostupným, vybere se stejným způsobem uzel jiný (každý client-interceptor či proxy si vybere nezávisle svůj hlavní cílový uzel).
• First Available Identical All Proxies
  (org.jboss.ha­.framework.in­terfaces.FirstA­vailableIdenti­calAllProxies) – chová se stejně jako předchozí strategie, ale vybraný hlavní uzel je sdílen všemi proxy ze stejné rodiny (tzv. Proxy Family).

Farming deployment

Nejjednodušší cesta, jak provést deploy aplikace na všechny uzly clusteru, je využití tzv. farming deploymentu. Stačí provést deploy aplikace (EAR, WAR nebo SAR archiv) do adresáře $JBOSS/server/a­ll/farm na jakémkoliv uzlu clusteru a aplikace je automaticky distribuována do všech uzlů. Stejně je zajištěn i její undeploy.

Tato služba FarmMemberService MBean se konfiguruje v souboru farm-service.xml v deploy adresáři serverové konfigurace. Zde lze specifikovat např. interval, kdy bude server kontrolovat farm adresář.

Služba replikace distribuovaného stavu

V clusteru se jedná o jednu z nejzásadnějších služeb, které musí server podporovat. Jedná se např. o replikaci stavů stateful EJB, cache entity beanů atd.

V dřívějších verzích JBossu zastávala tuto úlohu HASessionState MBean komponenta, kterou později nahradil obecný framework JBoss Cache. Ten se stará o replikaci HTTP sessions, EJB 3.0 session a entity beanů (Hibernate perzistentních entit) a komponent dalších J2EE služeb .

Služba JNDI v clusteru

Clustrovaná služba JNDI je postavena na architektuře client-side interceptor (viz. výše). Klient musí získat JNDI stub (přes InitialContext) a pak vyvolávat služby JNDI lookup na vzdáleném serveru přes stub.

Distribuovaná služba JNDI, tzv. JBoss HA-JNDI (High Availability JNDI), funguje na principu kontextového stromu společného pro celý cluster. Každý JNDI uzel v clusteru si současně drží svůj vlastní lokální strom.

Clusterování EJB

Konfigurace EJB ve verzi 2.x je mnohem složitejší, než je tomu díky anotacím u EJB 3.0 (bližší informace o nastavení EJB 2.x viz. příslušné pasáže dokumentace [1]).

Vše, co je třeba udělat, je označit stateless bean anotací @Clustered. V anotaci lze též specifikovat politiku load balancingu (defaultně org.jboss.ha.fra­mework.interfa­ces.RandomRobin) a název cluster partition (defaultně DefaultPartiti­on).

Stejně jako u stateless beanů je potřeba označit implementační třídu anotací @Clustered. Framework JBoss Cache poskytuje replikaci stavů pro EJB 3.0 stateful session beany. Související MBean komponenta zajišťující tuto funkcionalitu se konfiguruje v souboru ejb3-clustered-sfsbcache-service.xml v deploy adresáři. V tomto souboru je možné nakonfigurovat např. název clusteru, mód cachování, izolaci transakcí, strategii pro uvolňování objektů z cache a mnoho jiných parametrů.

Služba clusterování entit je zajištěna opět frameworkem JBoss Cache. Ten může být nakonfigurován jak samostatně jako standardní L2 cache entit, ale též může být nakonfigurován pro použití v distribuovaném prostředí.

JBoss Cache Service pro EJB 3.0 entity je konfigurována v TreeCache MBean komponentě v deploy/ejb3-entity-cache-service.xml konfiguračním souboru. Celý název komponenty je
jboss.cache:ser­vice=EJB3Enti­tyTreeCache.

Do persistence.xml deskriptoru je třeba doplnit následující řádky:

<!-- Clustered cache with TreeCache -->
<property name="cache.provider_class">
      org.jboss.ejb3.entity.TreeCacheProviderHook
</property>
<property name="treecache.mbean.object_name">
      jboss.cache:service=EJB3EntityTreeCache
</property>

Konfigurace entit dle JPA lze provést opět pomocí anotací, např.:

@Entity
@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
public class Person implements Serializable {
      // ...
}

Typicky se provádí cachování entit, které se málo často mění, ale velice často jsou používány. Atributy definující např. velikost cache, politiku uvolňování cache a jiné je možné nakonfigurovat ve výše zmíněném ejb3-entity-cache-service.xml konfiguračním souboru.

Služby HTTP

Replikace HTTP session se používá pro rozkopírování stavu session s webovými klienty nebo jinými uzly clusteru. V případě, že jeden uzel clusteru vypadne, je klientům jejich HTTP session transparentně přístupná z jiného serveru. V předpřipravené konfiguraci „all“ je replikace session již implicitně zapnuta.

Replikace relací je přímo obhospodařována JBossem. Naproti tomu load-balancing musí být v případě HTTP zajištěn jiným softwarem. Typickým a doporučeným řešením je použití webového serveru Apache a mod_jk. Jako load balancery se často využívají také specializované hardwarové switche nebo routery (např. Cisco LoadDirector) nebo jiný dedikovaný software.

Kromě mechanizmu distribuce session je také používají tzv. sticky sessions. Tento proncip znamená, že požadavky klienta jsou vždy směřovány na jeden fyzický server a k replikaci jeho session nedochází. Pokud není kriticky nutné session replikovat (při výpadku klient session ztratí, ale může hned pokračovat v práci na jiném serveru clusteru), je toto řešení výhodné. Nedochází totiž ke zbytečné režii a komunikaci serverů vyměňujících si informace o HTTP relacích.

Přesný postup, jak nainstalovat load balancer pomocí Apache serveru a mod_jk je uveden v dokumentaci [1] sekce 1.5 Http Services nebo v překladu česky též na již zmiňovaném Dagiho webu [2].

Konfigurace sticky sessions je dle výše uvedeného návodu triviální. Pokud chceme jít dále, replikace HTTP sessions lze nastavit pomocí TomcatClusterin­gCache MBean komponentě. Tato komponenta je nakonfigurována v deploy/tc5-cluster.sar/META-INF/jboss-service.xml souboru. Zde je možné nastavit konkrétní parametry replikace, jako např. mód cachování, izolace transakcí, název clusteru atd.

Pro zprovoznění clusteringu na straně klientské webové aplikace stačí definice elementu <distributable/> ve web.xml deskriptoru. Specifickou konfiguraci lze provést ve specifickém JBoss deskriptoru jboss-web.xml v elementu replication-config. Nejzajímavější nastavení jsou např.:

• nastavení typu politiky pro označení session jako dirty (možnosti SET, SET_AND_GET, SET_AND_NON_PRI­MITIVE_GET, ACCESS)
• nastavení granularity replikace (možnosti SESSION, ATTRIBUTE, FIELD).

Bližší informace o významech specifických nastavení viz. [1] a sekce 1.5.6 Enabling session replication in your application. Těmito nastaveními lze poměrně dobře ladit výkon clusteru a tím i vlastních aplikací.

Monitorovat replikace HTTP sessions je možné z JBoss konzole. Na MBean komponentě TomcatClusterin­gCache lze vyvolat metodu printDetails a z výpisů lze vyčíst počet sessions a jiné zajímavé informace.

Clustering služeb JMS

V předpřipravené konfigurace „all“ je dále k dizspozici plně nakonfigurovaná instance HA-JMS služby (High Available JMS), která je implementována jako tzv. Clustered Singleton Fail-over Service.

Co to znamená. Princip High availability Singleton Fail-over a potažmo JBoss HA-JMS služba (tj. front zpráv message queues a témat topics) beží pouze na jednom vybraném uzlu clusteru (tzv. master node). Pokud tento uzel selže, cluster jednoduše vybere jiný uzel a na něm spustí službu znovu.

I když není možné tedy z výše uvedeného důvodu provádět load balancing HA-JMS zpráv (existuje jen jeden master node obsahující fronty zprávy), je možné load balancovat Message Driven Beany, které zpracovávají zprávyz těchto front.

Pro využití Singleton Fail-over HA-JMS služby je třeba nakonfigurovat totožně na všech uzlech clusteru JMS. Tzn. všechny JMS služby a všechny JMS aplikace. Implicitně je JMS nastaven tak, že ukládá svá data do embedded databáze HSQLDB (DefaultDS datový zdroj), což je ovšem nevyhovující a je třeba nastavit nějakou „opravdovou“ databázi pro ukládání zpráv a zajištění konzistence dat pro případ výpadku uzlu.

Pro popis nastavení HA-JMS klienta a load balancing HA-JMS Message Driven Beanů viz. [1] sekce 1.6.1. High Availability Singleton Fail-over.

JBossCache a JGroups Services

Bystrého čtenáře jistě během čtení napadla nejednou otázka „jak to ale všechno takhle pěkně samo funguje“? Servery si musejí v distribuovaném prostředí clusteru vyměňovat spoustu informací týkajících se replikace dat, auto-discovery, cachování atd.

Za vším stojí framework JBossCache, který byl již několikrát v článku zmíněn a hlavně pak sada služeb JGroups, která zajišťuje vlastní fundamentální komunikaci mezi uzly clusteru. Každá z těchto dvou technologií nabízí sadu MBean komponent pro konfiguraci různých typů služeb (SFS EJBs, entity EJBs, atd.).

JBoss AS je dodáván a v předpřipravených konfiguracích nastaven s implicitní sadou těchto komponent, které jsou již rozumně nastaveny tak, že kromě speciálních případů a ladění výkonnosti není třeba tyto podpůrné technologie příliš speciálně konfigurovat. Vše šlape jaksi „samo“.

Speciální možnosti konfigurace JGroups, používaných síťových protokolů UDP a TCP, discovery protokolů, protokolů pro detekci selhání uzlů, a speciálních systémových nastavení cache lze vyčíst z dokumentace [1] v sekci 2.1. JGroups Configuration a 2.2. JBossCache Configuration.

Závěr

Práce na tomto článku mě motivovala jednak ke konfiguraci jednoduchého domácího clusteru a jednak k nastudování obecných možností clusteringu J2EE aplikace nad aplikačním serverem JBoss AS. Bezproblémová funkčnost celého řešení mě velmi mile překvapila. O problematice však na Internetu neexistuje bohužel dostatek volně přístupných materiálů, což je škoda. Každopádně však nezbývá než doufat, že bude možné někdy nabyté znalosti využít v praxi. Máte někdo komerční zkušenosti s využitím JBoss clusteru, jsou nějaké problémy s nasazením v produkci?

Použité zdroje a doporučená literatura

[1] JBoss – JBoss 4 Clustering Guide, 2006
http://labs.jbos­s.com/jbossas/doc­s/index.html

[2] Roman Pichlik – JBoss cluster krok za krokem, 2006
http://www.sweb­.cz/pichlik/ar­chive/2006_11_2­6_archive.html#116493­175089741929

[3] JavaWorld.com – J2EE clustering, Part 1
http://www.ja­vaworld.com/jw-02–2001/jw-0223-extremescale.html

[4] JavaWorld.com – J2EE clustering, Part 2
http://www.ja­vaworld.com/ja­vaworld/jw-08–2001/jw-0803-extremescale2.html

[5] OnJava.com – Clustering with JBoss 3.0
http://www.on­java.com/pub/a/on­java/2002/07/1­0/jboss.html

[6] OnJava.com – J2EE Clustering with JBoss
http://www.on­java.com/pub/a/on­java/2003/08/2­0/jboss_cluste­ring.html

[7] Přednášky předmětu 36PAR Paralelní systémy a algoritmy na FEL ČVUT
http://star.fel­k.cvut.cz/36par/pr­ednasky/index­.html

[8] Pavel Tvrdík: Paralelní systémy a algoritmy, Vydavatelství ČVUT, 2. vydání, 2006.

[9] Jakša Vučkovic, Universita di Bologna, Clustering Implementation in JBoss
http://adapt.ls­.fi.upm.es/adap­t/bologna-2003-feb/unibo3.ppt