j2ee clustering hgolle wwwjavadilicom

8/14/2019 J2EE Clustering HGOLLE WwwJavaDiliCom

http://slidepdf.com/reader/full/j2ee-clustering-hgolle-wwwjavadilicom 1/20

1

Ocak 2006, Hacettepe Üniversitesi Bilgisayar Mühendisliği

HACETTEPE ÜNVERSTES

BLGSAYAR MÜHENDSLĞ BÖLÜMÜ

BL447 - YAZILIM MÜHENDSLĞ LABORATUVARI

ARAŞTIRMA ÖDEV

(J2EE Clustering)

Hasan Gölle20021905

[email protected]



2


Önsöz ……………………………………………………………. 3

Temel terimler ………………………………………………….. 3

J2EE cluster mimarisi …………………………………………. 4

J2EE clustering nedir? ………………………………………… 6

Web tier (dizi) clustering (öbekleme) gerçekleştirimi ………. 8

JBoss ile J2EE Clustering -Singleton Service ………………... 15

Uygulama sunucu dağıtımı ……………………………………. 16

Kaynaklar ……………………………………………………… 20



3


Önsöz

Günümüzde çok fazla sayıda kritik görevli ve geniş çaplı uygulamalar Java 2, EnterpriseEdition (J2EE) da çalıştırılmaktadır. Banka ve faturalandırma gibi kritik görevli uygulamalar üst düzeyde elde edilebilirlik gerektirirken Google ve Yahoo gibi geniş çaplı uygulamalar iseölçeklenebilirlik gerektirirler. Elde edilebilirlik ve ölçeklenebilirliğin önemi şu olayla daispatlanmıştır: Haziran 1999 da eBay’da 22 saatlik hizmet kesintisi 2.3 milyon müzayedekesintisine ve eBay’ın hisse değerinin yüzde 9.2 düşmesine neden olmuştur.

Hata toleransı ile birlikte elde edilebilirlik ve ölçeklenebilirlik sağlama açısından J2EEclustering popüler bir teknolojidir. Fakat J2EE özelliğinin destek vermemesi nedeniyle J2EEsatıcıları clustering’i farklı şekillerde gerçekleştirmişlerdir. Bu da J2EE mimarları vegeliştiricileri için sorunlara neden olmuştur.

Temel Terimler

Clustering altında yatan kavramları anlamak gereklidir. Bu kavramlardan bazıları;

Ölçeklenebilirlik

Bazı geniş ölçekli sistemlerde son kullanıcıların sayısını ve davranışlarını önceden kestirmek zordur. Ölçeklenebilirlik, hızlı sayıda artan kullanıcıya destek verebilme yeteneğidir. Bununsezgisel yolu kaynakları (hafıza, CPU, disk gibi) artırmaktır. Clustering ise alternatif bir yoldur. Bir grup sunucunun ağır işleri paylaşmasını ve tek bir mantıksal sunucu gibi

davranmasını gerektirir.

Yüksek elde edilebilirlik

Ölçeklenebilirliğe tek sunucu çözümü (kaynak artırma) tek hata noktası nedeniyle sağlıklı bir çözüm değildir. Kritik görevli uygulamalar (banka gibi) bir dakikalık bile kesintiye toleransgösteremez. Bu hizmetlerin makul cevap verme süreleri olmalıdır. Clustering, bu tür eldeedilebilirliğe yedek sunucular sağlayarak ve hata durumunda yedeğini çalıştırarak çözümsağlar.

Yük dengelemeClustering’in anahtar teknolojisidir. Gelen istekleri farklı sunuculara dağıtarak daha iyi

performans sağlar. Yük dengeleyici basit bir servlet yada plug-in’den pahalı bir donanımakadar pek çok şey olabilir.

Hata Toleransı

Yüksek elde edilebilir veri çok doğru veri olmayabilir. J2EE cluster’da sunucu hata yaparsakesilmez çünkü diğer istekler yedek sunucular tarafından değerlendirilir. Hata toleranshizmetiyle az sayıda hataya rağmen doğru hizmeti garanti eder.



4


Failover

Hata toleransı sağlamak için gerekli diğer bir anahtar teknolojidir. Cluster’da başka bir düğümseçmekle orijinal düğüm hata yapsa bile işlem devam eder. Başka bir düğüme failover açıkçakodlanabilir yada otomatikman yürütülür.

J2EE Cluster Mimarisi

J2EE cluster şunları içerir:• Bir yada çok J2EE olgusu• Olgu yaratabilen merkezi servisler • Bir yada çok veritabanı

Dağıtıcılar ve sunucular farklı fiziksel sunucular arasında dağıtılabilir. Merkezi hizmetler

(mesaj hizmeti ve kuyruklama hizmeti) gereksinmeleri sağlayabilen bir host’ayüklenebilir.Genel olarak J2EE clustering teknolojisi “yük dengeleme” ve “failover”gerektirir.

Minimum Cluster YüklemeAşağıdaki grafik SAP Web uygulamasının en basit cluster yüklemesini gösterir. Bu şekildeyüklenen sunucu yalnızca J2EE sorgularını işletir.



7


Instance1 hata verirse Class A’nın business() metodu diğer B olgusu üzerine failover yadayük dengelemesi mi yapacak? Hayır. Yük dengelemesi ve failover için çağrılan ve çağıranarasında metot çağrılarını dağıtan ve farklı nesnelere yönlendiren bir yakalayıcı bulunmalıdır.Class A ve B nesneleri aynı JVM de çalışırlar ve sıkıca bağlıdırlar. Metot çağrıları arasınadağıtma mantığı eklemek zordur.

Öyleyse ne tür nesneler öbeklenebilir?- Yalnızca dağıtılmış topolojilere yüklenebilenbileşenler.

Öyleyse J2EE kodda failover ve yük dengeleme nerde olur?- Yalnızca dağıtılmış nesnelerinmetotlarının çağrıldığı yerlerde.



8


Şekil: Dağıtılmış nesneler

Şekildeki gibi dağıtılmış bir ortamda çağıran ve çağrılanlar belli sınırları olan farklı çalışmazamanı kaplarına ayrılırlar. Sınırlar JVM ile işlemler yada makineler arasında olabilir.

Hedef nesne istemci tarafından çağrıldığında hedef nesnenin kabında işlev çalıştırılır. (Bunedenle dağıtılmış denir). stemciler ve hedef nesneler standart ağ protokolü ile haberleşirler.Bu özellikler sayesinde bazı mekanizmalar metot çağırma yoluna girerek yük dengeleme vefailover yürütebilir.

Şekilde görüldüğü gibi tarayıcı uzak JSP nesnesini HTTP protokolü üstünden çağırabilir. JSPWeb sunucu tarafından çalıştırılır, tarayıcı nasıl çalıştırıldığı ile ilgilenmez, yalnızca sonucuister. Böyle bir senaryoda yük dengeleme ve failover işlevleri için tarayıcı ve web sunucuarasında bir şey bulunmalıdır. J2EE de dağıtma teknikleri JSP(Servlet), JDBC, EJB, JNDI,JMS, web servisleri ve diğerlerini içerir. Bu dağıtılmış metotlar çağrıldığında yük dengeleme

ve failover yürütülür. Detaylı teknikleri bir sonraki bölümde anlatacağız.

Web tier (dizi) clustering (öbekleme) gerçekleştirimi

Web dizisinde öbekleme J2EE clustering’de en önemli işlevdir. Web öbekleme teknikleri webyük dengeleme ve HTTP oturum failover içerir.



9


Web Yük Dengeleme

J2EE satıcıları web yük dengelemeyi birçok yöntemle başarırlar. Temelde yük dengeleyicitarayıcılar ile web sunucuları arasına girerler.

Şekil: Web yük dengeleyici

Yük dengeleyici F5 yük dengeleyici gibi donanımsal bir ürün olabilir, ve yük dengeleyici

plug-in’leri ile birlikte bir web sunucu da olabilir. Ip zincirleri ile bir Linux kutusu yük dengelemeyi yapabilir. Hangi tekniği kullanırsa kullansın yük dengeleyici şu özellikleresahiptir;

. Yük dengeleme algoritmalarını gerçekleştirir

stemciden istek geldiğinde yük dengeleyici bu istekleri en son sunucu olgularına nasıldağıtacağına karar verir. Popüler algoritmalar round-robin, random ve ağırlık tabanlıolanlardır. Yük dengeleyici her sunucu olgusuna eşit iş yükünü sağlamaya çalışır, fakatyukarıdaki algoritmalardan hiçbiri mükemmel eşitliği sağlayamaz çünkü hepsi bir sunucuolgusuna dağıtılan istekleri temel alırlar.

. Sağlık kontrolü

Bazı sunucu olguları hata verirse yük dengeleyici bu hatayı bulmalı ve o sunucuya bir daha istek göndermemelidir. Yük dengeleyici ayrıca bu sunucu geri döndüğünde izlemelive istek göndermeye devam etmelidir.



10


. Oturum

Hemen hemen her web uygulaması oturum durumlarına sahiptir, bunlar log-in durumuyada alışveriş listesini hatırlamak kadar basit olabilir. Http protokolü durumsuzolduğundan oturum durumu bir yere kaydedilmeli ve aynı uygulamadan tekrar

istendiğinde geri çağrılabilmelidir. Yük dengeleyici için bazı tarayıcı oturumlarınınisteklerini en son dağıtılan sunucu olgusuna dağıtmak en iyi çözümdür.

Oturum durumu web sunucu olgusunun hafızasına yüklendiğinden yük dengeleme içinoturum özellikleri önemlidir. Eğer bir sunucu olgusu güç kesilmesi gibi bir nedenle hataverirse bu sunucudaki oturum durumu kaybedilir. Yük dengeleyici bu hatayı bulmalı ve osunucuya bir daha istek göndermemelidir. Fakat oturum durumu hata veren sunucuda kayıtlıolan istekler bütün oturum bilgilerini yitirirler ve bu da hataya neden olur. Bu durumdaoturum failover ortaya çıkar.

HTTPOturum (HTTPSession) Failover

Şekil: HTTPOturum Failover

Bütün popüler J2EE satıcıları bütün istemci isteklerinin oturum durumu yitirilmedenişletildiğinden emin olmak için kendi cluster ürünlerinde HTTPOturum failover

gerçekleştirirler. Üstteki şekilde görüldüğü gibi tarayıcı, durumlu bir web uygulamasınıziyaret ettiğinde (1,2. adımlar) bu uygulama daha sonra kullanmak için hafızada oturumnesnesi oluşturabilir. Aynı zamanda tarayıcıya bu oturum nesnesini belirleyecek HTTPOturum kimliği gönderir(3. adım). Tarayıcı bu kimliği “cookie” (çerez) olarak kaydeder ve aynı web sunucudan sayfa istediğinde yeniden gönderir. Oturum failover desteklemek içinweb sunucudaki oturum nesnesi kendini yedeklemelidir(adım 4), böylece sunucu hatalarındaoturum kaybı önlenir. Yük dengeleyici hatayı fark ettiğinde (5, 6. adım) sıradaki istemleriaynı uygulama içindeki diğer sunucu olgusuna gönderir. Oturum durumu bir yerde yedekliolduğundan bu yeni web sunucu olgusu oturumu geri getirir(adım 8) ve istemleri yürütür.



11


HTTPOturum failover gerçekleştiriminde şu kavramlar dikkate alınmalıdır.

. Global HTTPOturum Kimliği(ID)

Yukarda belirtildiği gibi HTTPSession kimliği hafıza içi oturum nesnesini belirlemede

kullanılır. J2EE de HTTPOturum kimliği JVM olgusuna bağlıdır. Her JVM olgusu birden çok web uygulamasını tutabilir, her bir uygulama farklı kullanıcılar için birçok HTTPOturumtutabilir. HTTPOturum kimliği o anki JVM olgusunda ilgili oturum nesnesine erişmek içinanahtar rolündedir. Farklı JVM olguları iki tane aynı HTTPOturum kimliği üretmemelidir,çünkü failover olduğunda bir JVM deki oturumlar yedeklenebilir ve diğerinden çağrılabilir.Sonuç olarak global HTTPOturum kimliği mekanizması gerçekleştirilmelidir.

. Oturum durumları nasıl yedeklenir

Oturum durumlarının nasıl yedeklendiği konusu J2EE sunucuyu özel yapmak ve diğerlerindenüstün kılmak için anahtar rolündedir. Farklı satıcılar farklı şekilde gerçekleştirmektedir.

. Yedekleme sıklığı

HTTPOturum durum yedeklemenin performans maliyetleri vardır(CPU devri, ağ bantgenişliği, veritabanına yada diske yazma IO maliyeti gibi). Yedekleme sıklığı cluster

performansını önemli ölçüde etkiler.

Veritabanı devamlılığı yaklaşımı

Bütün popüler J2EE cluster ürünleri oturum durumunuzu yedeklemeniz için size JDBCarayüzü üstünden ilişkisel veritabanı seçme olanağı sunar.Alttaki şekilde görüldüğü gibi buyaklaşım basitçe sunucu olgusunun oturum içeriğini serileştirmesi ve veritabanına yazmasıdır.Failover olduğunda diğer bir sunucu olgusu hatalı sunucunun sorumluluğunu alır veveritabanından bütün oturum durumlarını geri alır. Nesnelerin serileştirilmesi önemlidir çünkü

bu sayede hafıza içi verinin kalıcı ve taşınabilir olması sağlanır. Java nesne serileştirimi içinhttp://java.sun.com/j2se/1.5.0/docs/guide/serialization/index.html” adresine bakınız.

Oturum durumunu veritabanına yedekleme

Veritabanı sorguları maliyetli olduğundan bu yaklaşımın temel dezavantajı oturumlar içindeçok sayıda nesne saklandığında sınırlı ölçeklenebilir olmasıdır. Veritabanı oturumu kullanançoğu uygulama sunucuları nesneleri saklamak için minimum HTTPOturumu kullanmayısavunur, fakat bu web uygulamasının mimarisini ve tasarımını kısıtlar.

Buna rağmen veritabanı yaklaşımının bazı avantajları da vardır.

• Gerçekleştirimi kolaydır.• Veritabanı paylaşımlı olduğundan oturum başka bir host’a failover edebilir.• Oturum bilgisi tüm öbek çökene kadar durur.



12


Hafıza kopyalama yaklaşımı

Performans nedenlerinden ötürü bazı J2EE sunucu’ları (Tomcat, JBoss, Weblogic, and

Websphere) alternatif bir yaklaşım getirmiştir: Hafıza kopyalama

Şekil: Oturum durumu için hafıza kopyalama

Hafıza tabanlı oturum, oturum bilgilerini veritabanı yerine bir yada birkaç yedek sunucudatutar. Bu yaklaşım yüksek performansı nedeniyle çok popülerdir. Veritabanı yaklaşımınakıyasla orijinal sunucu ile yedek sunucular arası ağ haberleşmesi çok önemsiz kalır. Ayrıcaveritabanı yaklaşımındaki geri okuma aşamasına gerek kalmaz çünkü zaten oturum bilgisiyedek sunucuda bulunmaktadır.

“JavaGroups” JBoss ile Tomcat öbekleme arasındaki haberleşme katmanıdır. “Grup üyeliği protokolleri” ve “mesaj yayını” gibi öbekleme için temel özellikleri sağlar. Daha fazla bilgiiçin “http://www.jgroups.org/javagroupsnew/docs/index.html”. adresine bakınız.

Tomcat’in yaklaşımı: Çoklu-sunucu kopyalamaHafıza kopyalamanın birçok değişik yöntemi vardır. lki oturum bilgisini cluster’daki bütün

düğümlerde kopyalamaktır. Tomcat 5 bunu şu şekilde yapar.



13


Şekil: Çoklu-sunucu kopyalama

Şekilde görüldüğü gibi bir sunucu olgusunda oturum değişirse o sunucu verilerini bütün diğer sunuculara yedekler. Bir sunucu olgusu hata verirse yük dengeleyici yedek olarak diğer sunucuyu seçebilir. Fakat bu yaklaşımın ölçeklenebilirlik açısından kısıtları vardır. Eğer öbekte çok sayıda olgu varsa ağ haberleşmesi maliyeti gözardı edilemez.

Weblogic, Jboss ve WebSphere yaklaşımı- eşli sunucu kopyalama

Performance ve ölçeklenebilirlik açısından Weblogic, JBoss ve Websphere başka bir hafızakopyalama geliştirmiştir: Her sunucu olgusu oturum bilgisini tutmak için keyfi bir yedek olguseçer.



14


. Bu yolla her sunucu olgusu kendi eş yedek sunucusuna sahiptir Bu yaklaşımölçeklenebilirlik problemine çözüm getirir, fakat şu kısıtları vardır:

. Yük dengeleyiciye karmaşıklık getirir. Bir sunucu olgusu hata verirse yük dengeleyicininhata veren sunucunun eşini bilmesi gerekir. Bu da yük dengeleyicinin alanını kısıtlar.

. Normal istem gerçekleştirme haricinde sunucular kopyalama sorumluluğunu da almalıdır.

. Normal işlem esnasında yedek oturumları tutmak için kullanılan hafıza, failover olmazsayedek sunucularda boşa harcanır.

IBM’in yaklaşımı- merkezi durum sunucu

Websphere’de hafıza kopyalamaya alternatif bir çözüm vardır: Merkezi durum sunucuyayedek durum bilgisi.

Şekil: Merkezi sunucu kopyalama

Veri tabanı çözümüne çok benzerdir. Veritabanı sunucu yerine “oturum yedek sunucu”kullanılmıştır. Bu yaklaşım şu avantajları getirir:

. Yürütülen işlemleri yedek oturum işlemlerinden ayırmak cluster’ı daha sağlam yapar.

. Bütün oturum bilgileri ilgili sunucuda yedeklenmiştir. Hafıza tüketen sunucu olgularınagerek yoktur.

. Uygulama sunucu ile oturum yedek sunucu arasındaki soket haberleşmesi veritabanı bağlantılarına göre basit olduğundan daha iyi performans verir.

Buna rağmen “geri okuma” aşaması nedeniyle performansı hafızanın eşler arasında direk kopyalandığı çözüm gibi olamaz. Ayrıca fazladan oturum yedek sunucuları karmaşa getirir.



15


Sun’ın yaklaşımı- Özel veritabanı

Sun JES uygulama sunucusu oturum failover’a farklı bir yaklaşım getirir. Veritabanıyaklaşımına benzese de aslında JES’in kullandığı veritabanı (HADB) oturum erişimi içinoptimize edilmiştir ve bütün veriyi hafızada tutar. Dolayısıyla merkezi durum sunucuyaklaşımına daha yakındır.

JBoss ile J2EE Clustering -Singleton Service

Singleton hizmet veren cluster içindeki düğüme efendi düğüm denir. Efendi düğüm hataverirse diğerleri arasından bir efendi seçilir ve servis tekrar başlar.



16


Uygulama sunucu dağıtımı

Cluster’ınıza uygulama sunucu olgularını dağıtırken cluster’da tek düğümde birden çok uygulama sunucu olgusu istediğinize karar vermelisiniz, ve cluster’daki toplam düğümsayısını belirlemelisiniz.

Bir düğümdeki uygulama sunucu sayısı CPU sayısına, kullanımına ve hafızaya bağlıdır.Cluster’daki optimum düğüm sayısını belirlemek tekrarlı bir iştir. Öncelikle uygulamanın

profili çıkarılır ve optimize edilir. Sonra maksimum kullanım için yük testi yapılır. Son olarak hata olduğunda yükü kaldıracak fazladan düğümler eklenir.



17


Oturum depolama anahatları

Kırılmayı minimize etmek için uygulama sunucu’ları anahatları takip edilmelidir:

Bütün nesneler ve HttpOturumda özyineli olanlar serileştirilebilir olmalıdır vejava.io.Serializable gerçekleştirmelidir.

HttpOturumda nesnenin durumu değiştiğinde nesnenin değiştiğini belirtmek ve değişikliğiyedek sunucuya kaydetmek için session.setAttribute(...)çağrılır.

AccountModel am =

(AccountModel)session.getAttribute("account");

am.setCreditCard(cc);

//You need this so the AccountModel object on the backupreceives the

//Credit card

session.setAttribute("account",am);

ServletContext serializable değildir bu nedenle olgu değişkeni olarak kullanılamaz.

EJB uzak nesneleri serileştirilemezler. Serileştirilemeyen durumlarda mekanizma aşağıdakiile değiştirilir (Bu sınıf java.io.Serializable gerçekleştirilmez çünkü superclass’ıAccountModel bunu yapar).

...

public class AccountWebImpl extends AccountModel

implements ModelUpdateListener, HttpSessionBindingListener {

transient private Account acctEjb;

...

private void writeObject(ObjectOutputStream s) {

try {

s.defaultWriteObject();

Handle acctHandle = acctEjb.getHandle();

s.writeObject(acctHandle);

} catch (IOException ioe) {

Debug.print(ioe);

throw new GeneralFailureException(ioe);

} catch (RemoteException re) {

throw new GeneralFailureException(re);

}

}



18


private void readObject(ObjectInputStream s) {

try {

s.defaultReadObject();

Handle acctHandle = (Handle)s.readObject()

Object ref = acctHandle.getEJBObject();

acctEjb = (Account)

PortableRemoteObject.narrow(ref,Account.class);

} catch (ClassNotFoundException cnfe) {

throw new

GeneralFailureException(cnfe);

} catch (RemoteException re) {

throw new

GeneralFailureException(re);

} catch (IOException ioe) {

Debug.print(ioe);

throw new GeneralFailureException(ioe);

}}

Oturum diskten geri yazıldığında ve HttpSession's setAttribute(...) methodu her çağrıldığında HttpSessionBindingListener ' ınvalueBound(HttpSessionBindingEvent event) methodu çağrılır. Buna rağmenfailover esnasında valueBound(HttpSessionBindingEvent event) çağrılmaz.

Hafıza içi oturum durum kopyalaması Hafıza içi oturum durum kopyalaması veritabanı yaklaşımından daha zordur çünkü

HttpOturum’daki her bir nesne değiştikçe yedek sunucuda serileştirilebilir. Veritabanıyaklaşımı durumundaysa oturumdaki nesnelerin biri değişse hepsi birden serileştirilir. Hatadurumunda uygulama çalışır fakat bazı özellikler çalışmayabilir- alışveriş kartı daha fazla

parçayı reddedebilir örneğin. Problem, uygulamanızın aynı alışveriş kart nesnesine referansgösteren farklı parçalarından (alışveriş kartını güncelleyen ve gösteren) kaynaklanır. Tek sunucu durumunda bu durum görülmez çünkü her parça aynı nesneye referans gösterir.

Aşağıda dolaylı kopyalayan nesnelerin örneği görülmektedir.

import java.io.*;

public class Aaa implements Serializable {

String name;

pubic void setName (String name) {

this.name = name;

}

public String getName( ) {

return name;

}

}



19


import java.io.*;

public class Bbb implements Serializable {

Aaa a;

public Bbb (Aaa a) {

this.a = a;

}

pubic void setName (String name) {

a.setName(name);

}

public String getName( ) {

return a.getName();

}

}

In first.jsp on sunucu1:

<%

Aaa a = new Aaa();

a.setName("Abe");

Bbb b = new Bbb(a);

// a is copied to backup machine under key "a"

session.setAttribute("a",a);

// b is copied to backup machine under key "b"

session.setAttribute("b",b);

%>

In second.jsp on sunucu1:

<%

Bbb b = (Bbb)session.getAttribute("b");

b.setName("Bob");

// b is copied to backup machine under key "b"

// but object Aaa under key "a" has the name "Abe"

// and "b"'s Aaa has the name "Bob"

session.setAttribute("b",b);

---> Failure trying to get to sunucu1's third.jsp

----->Failover to sunucu2's (backup machine) third.jsp

In third.jsp on sunucu2:

The name associated with Object Aaa is:

<%=((Aaa)session.getAttribute("a")).getName()%>

The name associated with Object Aaa through Object Bbb is:



20


<%=((Bbb)session.getAttribute("b")).getName()%>

...

//End of third.jsp lk ifade etiketi “Abe” çıktısı verirken, ikincisi “Bob” üretir. Tek sunucu durumunda her ikisi

de “Bob” üretir.

Kaynaklar:http://www.theserverside.com/articles/article.tss?l=J2EEClustering http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-extremescale2.html http://help.sap.com/saphelp_webas630/helpdata/en/2e/611724f410254ca12a3f396ec5ae85/content.htm http://www.onjava.com/pub/a/onjava/2003/08/20/jboss_clustering.html

j2ee clustering hgolle wwwjavadilicom

Documents