Ez a kiadás a következő termékhez készült:
továbbá minden későbbi kiadáshoz és módosításhoz, amennyiben az újabb kiadások ettől eltérően nem jelzik.
A kiadványokat az IBM képviselőjétől vagy az IBM helyi irodájától rendelheti meg.
A könyv (WebSphere Application Server - fogalmak, tervezés és az Edge összetevők telepítése) bevezetést nyújt a WebSphere Application Server Edge összetevők használatához. Magas szintű áttekintést ad a termékekről, részletesen tárgyalja a kulcsösszetevők működését, valamint a hálózat peremét is magába foglaló példákat, telepítési és a konfigurálás elkezdéséhez szükséges információkat, illetve példahálózatokat foglal magába.
A WebSphere Application Server - fogalmak, tervezés és az Edge összetevők telepítése tapasztalt hálózat- és rendszergazdáknak készült, akik megfelelő ismeretekkel rendelkeznek az operációs rendszerekről és az internetes szolgáltatások üzemeltetéséről. A WebSphere Application Server vagy a WebSphere Application Server Edge összetevők előzetes ismeretére nincs szükség.
A kisegítő lehetőségek a fizikai fogyatékkal élőket, például a mozgásukban vagy látásukban korlátozottakat segítik a szoftvertermékek eredményes használatában. A WebSphere Application Server, 6.1 Változat fontosabb kisegítő lehetőségei a következők:
A jelen dokumentáció az alábbi szedési és jelölési konvenciókat alkalmazza.
Jelölés | Jelentés |
---|---|
Félkövér | A grafikus felhasználói felületek elemeire való hivatkozáskor a félkövér szöveg menüt, menüelemet, címkét, gombot, ikont vagy mappát jelöl. Egyes esetekben olyan parancsnév kiemelésére szolgál, amelyet egyébként könnyen össze lehetne keverni a körülötte található szöveggel. |
Monospace betűtípus | A parancssorba beírandó szöveget ad meg. A képernyőn megjelenő szövegek, a kódminták és a fájlkivonatok szintén Monospace szedésűek. |
Dőlt | Változóértéket jelöl, amelyet Önnek kell megadnia (például Önnek kell meghatároznia a fájlnév fájl nevét). A dőlt betűket kiemelésre és könyvek címének megadására is alkalmazzuk. |
Ctrl-x | Ahol az x egy billentyű neve, a kombináció pedig egy Ctrl+karakter gomnyomássorozatot jelöl. A Ctrl-c például azt jelenti, hogy lenyomva kell tartania a Ctrl gombot, miközben a c gombot is lenyomja. |
Return | A Return vagy Enter szóval vagy balra mutató nyíllal jelölt billentyűre hivatkozik. |
% | A Linux és UNIX parancssori héjat jelöli olyan parancsnál, amelynek futtatásához nincs szükség root jogokra. |
# | A Linux és a UNIX parancssori héjat jelöli olyan parancsnál, amelynek futtatásához root jogosultságokra van szükség. |
C:\ | A Windows parancssorát jelöli. |
Parancsok beírása | Ha parancs "beírására" vagy "kiadására" kap utasítást, akkor gépelje be a parancsot, majd nyomja meg a Return gombot. Az "Adja ki az ls parancsot" például azt jelenti, hogy gépelje be az ls karaktersorozatot a parancssorba, majd nyomja meg a Return gombot. |
[ ] | Elhagyható elemeket határol a szintaxisok leírásában. |
{ } | A szintaxisok leírásában listákat határol, amelyek elemei közül ki kel választania egyet. |
| | A szintaxisok leírásában a lehetséges választások { }(kapcsos zárójelek) közé foglalt listájának elemeit választja el egymástól. |
... | A szintaxisok leírásában a három pont azt jelzi, hogy a megelőző elemet egy vagy több alkalommal meg lehet ismételni. A példákban a három pont arra utal, hogy a tömörség megőrzése miatt a példából bizonyos információk kimaradtak. |
Ez a rész a WebSphere Application Server Edge összetevők Caching Proxy és Load Balancer összetevőit, valamint ezek az Application Server összetevővel való integrációját mutatja be. Emellett ismerteti a Caching Proxy és a Load Balancer összetevőit. Mindezen túl a fejezet bemutatja a WebSphere családhoz kapcsolódó egyéb termékeket.
Ez a rész a következő fejezeteket tartalmazza:
A WebSphere egy internetes infrastruktúra szoftver, amelynek segítségével a vállalatok következő generációs e-business alkalmazásokat fejleszthetnek, vezethetnek be és integrálhatnak, például a vállalatok közötti értékesítés az e-kereskedelem megvalósítása céljából. A WebSphere köztes szoftvere az üzleti alkalmazásokat az egyszerű webes közzétételtől egészen a vállalati szintű tranzakciófeldolgozásig képes támogatni.
A WebSphere platform alapjaként a WebSphere Application Server átfogó köztesszoftver-szolgáltatásokat biztosít, amelyek segítségével a felhasználók elvégezhetik az üzleti alkalmazások tervezését, megvalósítását, telepítését és kezelését. Ezek az alkalmazások az egyszerű, webes "kirakattól" kezdve egészen egy-egy szervezet számítástechnikai infrastruktúrájának teljeskörű átformálásáig terjedhetnek.
A processzorokat erősen igénybe vevő szolgáltatások, mint például a személyre szabás, minden e-business vállalat számára versenyelőnyt biztosítanak. Ugyanakkor ezeknek a szolgáltatásoknak a megszokott, központi szerverekre való áthelyezése megakadályozhatja az értékes funkciók internetes léptékekre való méretezését. Az újabb és újabb webes alkalmazások hozzáadásával tehát a vállalatok internetes infrastruktúrájának hatókörét és befolyását tekintve egyaránt bővülnie kell. A megbízhatóság és a biztonság az e-business vállalatok számára kiemelt fontosságú. Esetükben akár egyetlen szolgáltatás minimális kiesése is üzleti veszteséget eredményezhet.
Az Edge összetevők (korábban Edge Server) most a WebSphere Application Server részeként állnak rendelkezésre. Az Edge összetevőket a WebSphere Application Serverrel összekapcsoltan lehet használni az ügyfelek a webszerverekhez való hozzáférésének szabályozására, illetve segítségével a vállalatok magasabb szintű szolgáltatásokat nyújthatnak a webes tartalmat az Interneten vagy a vállalati intraneten keresztül elérő ügyfelek számára. Az Edge összetevők használatával enyhíthetők a webszervereken fellépő torlódások, növelhető a tartalom rendelkezésre állása, valamint javítható a webszerverek teljesítménye. Ahogy a név mutatja, az Edge összetevők olyan számítógépeken futnak, amelyek (hálózati konfigurációs értelemben véve) közel vannak a vállalati intranet és az Internet határához.
A WebSphere Application Server magába foglalja a Caching Proxy és a Load Balancer Edge összetevőket.
FONTOS: A Caching Proxy az Edge összetevők minden telepítésekor elérhető, kivéve a következőket:
A Caching Proxy segítségével, több háttér-tartalomszerver részére egyetlen jelenléti pontot biztosítva csökkenthető a sávszélesség-használat és növelhető a webhely sebessége és megbízhatósága. A Caching Proxy gyorsítótárazza és átadja az ügyfeleknek a statikus és a WebSphere Application Server által dinamikusan előállított tartalmat.
A Caching Proxy fordított proxykiszolgáló (alapértelmezett konfiguráció) vagy továbbító proxykiszolgáló szerepben konfigurálható, amivel alkalmas arra, hogy jelenléti pontként szolgáljon egy hálózat vagy egy belső hálózati kiszolgáló számára, javítva a kérés- és válaszidőket. További információkért a fordított és a továbbító konfigurációkról tekintse meg a következőt: Alapszintű gyorsítótárazó proxy konfigurációk.
A proxyszerver elfogja az ügyféltől érkező adatkéréseket, lekéri a kért információkat a tartalmat tároló számítógépekről, majd kézbesíti a tartalmat az ügyfélnek. A kérések leggyakrabban webszerver gépeken (ezeket származási szervereknek vagy tartalomhosztoknak is nevezzük) tárolt dokumentumokra vonatkoznak, és kézbesítésük a Hypertext Transfer Protocol (HTTP) használatával történik. A proxyszerver más protokollok kezelésére is konfigurálható, mint például a Fájlátviteli protokoll (FTP) és a Gopher.
A proxyszerver a helyi gyorsítótárban is tárolja a gyorsítótárazható tartalmat, mielőtt kézbesítené a kérelmezőnek. Gyorsítótárazható tartalmak például a statikus weboldalak és a JavaServer Pages fájlok, amelyeknek dinamikusan előállított, de ritkán változó információkat tartalmaznak. A gyorsítótárazás lehetővé teszi a proxyszerver számára, hogy közvetlenül a gyorsítótárból elégítse ki az azonos tartalmakra vonatkozó későbbi kéréseket, ami sokkal gyorsabb megoldás, mintha újra lekérné őket a tartalomhosztról.
Caching Proxy bedolgozók és a proxyszerver funkcióinak bővítése
A Caching Proxy funkcióit egyéni bedolgozó modulok az alkalmazás programozási felület (API) segítségével végzett készítésével tovább lehet bővíteni. Az API rugalmas, könnyen használható és platformfüggetlen. A proxy minden egyes ügyfélkéréshez meghatározott lépések sorozatát hajtja végre. A bedolgozó alkalmazás a kérésfeldolgozás munkafolyamatának egyes lépéseit módosíthatja, illetve teljesen át is veheti egy-egy lépés, például az ügyfélhitelesítés vagy a kérésszűrés végrehajtását. A sokoldalú Transmogrify felület például hozzáférést biztosít a HTTP adatokhoz, és lehetővé teszi az URL címek és a webes tartalom lecserélését vagy átalakításást. A bedolgozók képesek az egyes feldolgozási lépések módosítására vagy szerepének átvételére, illetve egy-egy lépéshez több bedolgozót is meg lehet hívni.
A Load Balancer segítségével olyan a hálózat peremén elhelyezkedő rendszerek hozhatók létre, amelyek szabályozzák a hálózati forgalom áramlását, mérséklik a torlódásokat, valamint kiegyenlítik a különféle szolgáltatások és rendszerek terhelését. A Load Balancer képes a helyválasztásra, a munkaterhelés felügyeletére, a munkamenetek affinitásának követésére és az átlátszó átállás megvalósítására.
A Load Balancert az Internet és a vállalat háttérszerverei közé kell telepíteni, utóbbiak tartalomhosztok vagy Caching Proxy gépek lehetnek. A Load Balancer a vállalat egyetlen internetes jelenléti pontjaként viselkedik, még akkor is, ha a vállalat a nagy forgalom vagy a tartalom nagy mennyisége miatt több háttérszervert tart fenn. A feladatokat az elsődleges ideiglenes meghibásodása esetén átvevő tartalék Load Balancer telepítésével a magas szintű rendelkezésre állás is garantálható.
A Load Balancer elfogja az ügyfelektől érkező adatkéréseket, és minden kérést ahhoz a szerverhez továbbít, amely a legjobban képes kielégíteni a kérést. Másként fogalmazva, a bejövő kérések miatt jelentkező terhelést azonos típusú kéréseket kiszolgáló szerverek meghatározott csoportjának tagjai között osztja el. A Load Balancer a kéréseket számos különböző típusú szerver között képes elosztani, ideértve a WebSphere Application Servereket és a Caching Proxy gépeket is. A terheléskiegyenlítés egyéni tanácsadók segítségével adott alkalmazás vagy platform igényei szerint is egyénre szabható. A WebSphere Application Serverek terheléskiegyenlítésével kapcsolatos információk beszerzéséhez különleges tanácsadók állnak rendelkezésre.
Ha a Content Based Routing összetevő a Caching Proxyval együtt van telepítve, akkor a HTTP- és HTTPS-kéréseket akár URL címek, akár egyéb, a rendszergazda által megadott szempont alapján is el lehet osztani, így nem muszáj az összes háttérszerveren azonos tartalmat tárolni. A Dispatcher összetevő hasonló funkciókat biztosít a HTTP-kérések kezeléséhez.
A terheléskiegyenlítéssel növelhető a webhelyek rendelkezésre állása és méretezhetősége, ugyanis a tartalomszerverek fürtözése átlátszó módon történik, ideértve a HTTP-szervereket, az alkalmazáskiszolgálókat és a helyettesítő tartalomszerver szerepet játszó proxyszervereket egyaránt. A rendelkezésre állás növelése párhuzamosítással, terheléskiegyenlítéssel és az átállás támogatásával valósul meg. Így egy-egy szerver leállása nem okozza az üzleti folyamatok megszakadását. Az infrastruktúra méretezhetősége nagyban javul, ugyanis a háttérfeldolgozási kapacitást átlátszó módon lehet bővíteni.
Az IPv6 támogatása: Az IPv6 kiterjesztett IP címzési sémájának támogatása a "Load Balancer for IPv4 and IPv6" révén érhető el. A Load Balancer for IPv4 and IPv6 egy különálló telepítőkészlet, amely kizárólag a Dispatcher összetevőt tartalmazza. Az ilyen típusú telepítések a Dispatcher MAC továbbítási módszerével a hálózat szerverei számára az IPv4 és az IPv6 forgalom terheléskiegyenlítését egyaránt képesek biztosítani. Fontos megjegyezni, hogy a Load Balancer for IPv4 and IPv6 telepítése előtt a Load Balancer minden korábbi példányát el kell távolítani. Ugyanazon a gépen nem lehet két Load Balancer telepítve. (A Dispatcher összetevő rövid áttekintését a következő rész tartalmazza: Dispatcher.)
A Load Balancer a következő összetevőket foglalja magába:
Az internetes szolgáltatások esetében, mint a HTTP, az FTP, a HTTPS és a Telnet, a Dispatcher adott helyi hálózat (LAN) vagy nagy kiterjedésű (WAN) hálózat szervereihez végez terheléskiegyenlítést. A HTTP alapú szolgáltatásokhoz a Dispatcher a szerverek terheléskiegyenlítését az ügyfélkérések URL címe alapján is el tudja végezni.
A Dispatcher összetevő segítségével a nagyméretű, méretezhető szerverhálózatok felügyelete is üzembiztos és hatékony módon végezhető el. A Dispatcherrel számos önálló szervert kapcsolhat össze egyetlen virtuális szerverként megjelenő egységgé. A webhely így egyetlen IP címmel érhető el a külvilág számára.
Ha Load Balancer for IPv4 and IPv6 telepítést használ, tanulmányozza a WebSphere Application Server Load Balancer adminisztrációs útmutató Dispatcher Load Balancer for IPv4 and IPv6 rendszerre való telepítését tárgyaló fejezetet, amely a korlátokat és a konfigurálási különbségeket is áttekinti.
A HTTP és a HTTPS szolgáltatások esetében az ügyfélkérések tartalma alapján a Content Based Routing összetevő végzi a szerverek közötti terheléskiegyenlítést. A Content Based Routing összetevő az Application Server Caching Proxy összetevőjével összekapcsolva dolgozik.
FONTOS: A Content Based Routing (CBR) összetevője minden támogatott operációs rendszeren elérhető, a következő kivételekkel:
Az ilyen jellegű telepítéseknél a Load Balancer' Dispatcher összetevőjének cbr továbbítási módszerét alkalmazhatja a HTTP és HTTPS kérések a Caching Proxy használata nélkül történő, tartalom alapú útválasztására. További információkat a WebSphere Application Server Load Balancer adminisztrációs útmutatójában talál.
Load Balancer for IPv4 and IPv6 csak a Dispatcher ' összetevő mac továbbítási módszerét támogatja. A nat és a cbr továbbítási módszer nem támogatott.
A Site Selector összetevő azzal bővíti a terheléskiegyenlítő rendszert, hogy lehetővé teszi, hogy a hálózat egyetlen megjelenési pontjaként viselkedjen, illetve a bejövő kérések terheléskiegyenlítését a DNS nevek IP címekre való leképezésével biztosítja. A Metric Server összetevővel összekapcsoltan a Site Selector képes figyelni a szerverek terhelési szintjét, és felismeri, ha valamelyik szerver túlterhelt vagy meghibásodott.
Ez az összetevő az Edge összetevők minden telepítésénél támogatott, a következő kivétellel:
A Cisco CSS vezérlő összetevő szerversúlyozó mértékeket állít elő, melyeket a szerver kiválasztásának, a terhelés optimalizálásának és a hibatűrés megvalósításának elősegítése céljából továbbít a Cisco CSS kapcsolónak.
Ez az összetevő az Edge összetevők minden telepítésénél támogatott, a következő kivétellel:
A Nortel Alteon vezérlő összetevő szerversúlyozó mértékeket állít elő, amelyeket a szerver kiválasztásának, a terhelés optimalizálásának és a hibatűrés megvalósításának céljából továbbít a Nortel Alteon kapcsolónak.
Ez az összetevő az Edge összetevők minden telepítésénél támogatott, a következő kivétellel:
A Metric Server összetevő a kiegyenlített terhelésű szerveren démonként fut, és információkat nyújt a rendszer terheléséről a Load Balancer számára.
Az IBM WebSphere családot arra tervezték, hogy segítse a felhasználókat az e-business révén kínálkozó lehetőségek felismerésében. Olyan szoftvertermékek gyűjteménye, amelyek segítséget nyújtanak a felhasználóknak a nagyteljesítményű webhelyek fejlesztéséhez és kezeléséhez, valamint a webhelyek új vagy nem webes üzleti információs rendszerekkel való integrálásához.
A WebSphere család az Edge összetevőket is tartalmazó WebSphere Application Serverből és más WebSphere családbeli szoftverekből áll, amelyek szorosan integrálva vannak a WebSphere Application Serverrel, fokozva annak teljesítményét. A WebSphere Application Server és összetevőinek bemutatását lásd: A WebSphere Application Server Edge összetevők bemutatása.
A Tivoli Access Manager (korábban Tivoli Policy Director) külön érhető el. A meglévő webes alkalmazásokhoz hozzáférés-kezelést és központosított biztonsági szolgáltatásokat nyújt, valamint több webes információforrás elérését egyszer hitelesítéssel is képes biztosítani. Az egyik Caching Proxy bedolgozó az Access Manager biztonsági keretrendszere által nyújtott szolgáltatásokat kihasználva lehetővé teszi a proxyszerver számára az Access Manager integrált jogosultságkezelési és hitelesítési szolgáltatásainak igénybe vételét.
A WebSphere Portal Server (külön érhető el) egy keretrendszert biztosít a portálokkal kapcsolatos megjelenítési, biztonsági, méretezhetőségi és rendelkezésre állási kérdések megoldásához. A Portal Server használatával a vállalatok felépíthetik a saját egyéni portál webhelyüket, amely az alkalmazottak, az üzleti partnerek és az ügyfelek kiszolgálására egyaránt felhasználható. Miután a felhasználók bejelentkeztek a portálra, az képes személyre szabott weboldalakat átadni nekik, így mindig biztosítja a számukra szükséges információk, személyek és alkalmazások elérhetőségét. A személyre szabott, minden szükséges információforráshoz egyetlen elérési pontot adó szolgáltatások csökkentik az információs túlterheltséget, javítják a hatékonyságot, valamint növelik a webhely használatát.
A WebSphere Portal Server a méretezhetőség és a megbízhatóság miatt egy WebSphere Application Server fürtön fut. A terheléskiegyenlítés és a magas szintű rendelkezésre állás megvalósítására a Application Server Load Balancer összetevő is használható.
A WebSphere Site Analyzer (külön érhető el) segítségével a vállalatok korán fel tudják ismerni a teljesítménnyel és a kapacitással kapcsolatos problémákat. A Site Analyzerrel a Caching Proxy és a Load Balancer naplói és egyéb kezelési segédeszközök használhatók - a webhely használatának figyelésével, elemzésével és jelentésével - a további erőforrások iránti igények időben való felismerésére. Továbbá a Site Analyzer kezelési összetevői segítik az Edge összetevőket telepítő és frissítő felhasználókat, kezelik és tárolják a konfigurációkat, távolról működtetik az Edge összetevőket, valamint megjelenítik és jelentik az eseményeket.
A WebSphere Transcoding Publisher (külön érhető el) mobil eszközökön, például internetkezelésre képes telefonon való megjelenítéshez alakítja át a weboldalakat, lefordítja a webtartalmat a felhasználó által preferált nemzeti nyelvre (a WebSphere Translation Server közreműködésével), valamint átalakítja a leírónyelveket. A Transcoding Publisher kibővíti a Caching Proxy képességeit, lehetővé téve, hogy különböző eszközök és felhasználók részére szolgáltasson tartalmat. A Caching Proxy Transmogrify felületét be lehet úgy állítani, hogy a webszerver tartalmához való hozzáférés után hívja meg a Transcoding Publishert, alakítsa át az adatokat, majd címkézze fel azokat a variánsok gyorsítótárazásához és az esetleges újrafelhasználáshoz. A Caching Proxy utóhitelesítő felületén a Transcoding Publisher ezt követően ellenőrzi, hogy a proxyszerver rendelkezik-e a felhasználó és az eszköz igényeinek megfelelő tartalommal, és ha talál ilyet, akkor a tartalmat a proxyszerver gyorsítótárából adja át.
A következő, a WebSphere Application Server Edge összetevőkhöz tartozó dokumentáció az Edge összetevők információs központból érhető el.
További WebSphere Application Server dokumentáció a WebSphere Application Server könyvtár oldaláról áll rendelkezésére.
Az Edge összetevőkhöz műszaki terméktámogatási információkat a WebSphere Application Server terméktámogatás oldalon talál.
Az Edge összetevőkről információkat, illetve kapcsolódó információkat a következő webhelyeken talál:
Ez a rész részletes leírásokat tartalmaz, amelyek mélyebben is ismertetnek néhány az Edge összetevőkkel megvalósítható funkciót. Az Application Server Caching Proxy összetevőjének bemutatását a következő rész tartalmazza: A WebSphere Application Server Edge összetevők bemutatása.
Ez a rész a következő fejezeteket tartalmazza:
A Caching Proxy gyorsítótárazási funkciójának segítségével minimalizálni lehet a hálózati sávszélesség igénybe vételét, valamint gyorsabb és megbízhatóbb szolgáltatást lehet biztosítani a végfelhasználók számára. Mindez úgy válik lehetővé, hogy a proxyszerver által végzett gyorsítótárazás tehermentesíti a háttérszervereket és a partnergépek közötti összeköttetéseket. A Caching Proxy a statikus tartalmat és a WebSphere Application Server által dinamikusan előállított tartalmat egyaránt képes gyorsítótárazni. A magas szintű gyorsítótárazás biztosításához a Caching Proxy az Application Server Load Balancer összetevőjével együttműködve látja el feladatait. A rendszerek bemutatását lásd: A WebSphere Application Server Edge összetevők bemutatása.
FONTOS: A Caching Proxy az Edge összetevők minden telepítésekor elérhető, kivéve a következőket:
A Caching Proxy fordított gyorsítótárazó proxykiszolgálóként (alapértelmezett konfiguráció) vagy továbbító gyorsítótárazó proxykiszolgálóként konfigurálható. Ha tartalomhosztok veszik igénybe, akkor a Caching Proxy fordított gyorsítótárazó proxykiszolgáló szerepet játszik, amely az internet és a vállalati tartalomhosztok között helyezkedik el. Ha internetszolgáltató használja, akkor a Caching Proxy mint továbbító gyorsítótárazó proxykiszolgáló viselkedik, amely az ügyfél és az internet között található.
Fordított proxy konfiguráció használatakor a Caching Proxyt futtató számítógép az internet és a vállalat tartalomhosztjai között helyezkedik el. Helyettesítő szerepet játszva a proxyszerver elfogja az Internetről érkező ügyfélkéréseket, továbbítja őket a megfelelő tartalomhoszthoz, gyorsítótárazza a visszakapott adatokat, majd az Interneten keresztül kézbesíti az adatokat a felhasználóknak. A gyorsítótárazás lehetővé teszi a Caching Proxy számára, hogy közvetlenül a gyorsítótárból elégítse ki az azonos tartalomra vonatkozó későbbi kéréseket, ami sokkal gyorsabb megoldás, mintha újra lekérné őket a tartalomhosztról. Az információk attól függően gyorsítótárazhatóak, hogy mikor évülnek el, milyen nagy a gyorsítótár, illetve mikor kell az információkat frissíteni. A gyorsítótár-találatok gyorsabb letöltése az ügyfelek számára jobb minőségű szolgáltatást jelent. A Caching Proxy alapszintű működését lásd: 1. ábra
Jelmagyarázat: 1--Ügyfél 2--Internet 3--Útválasztó/átjáró 4--Caching Proxy 5--Gyorsítótár 6--TartalomhosztA konfigurációban a proxyszerver (4) elfogja azokat a kéréseket, amelyek URL címe tartalmazza a tartalomhoszt hosztnevét (6). Amikor az (1) ügyfél kéri az X fájlt, a kérés keresztülhalad az Interneten (2), majd az internetátjárón keresztül belép a vállalat belső hálózatába (3). A proxyszerver elfogja a kérést, új kérést állít elő, amelynek forráscíme a saját IP címe, majd az új kérést elküldi a tartalomhosztnak (6).
A tartalomhoszt az X fájlt a proxyszerver részére küldi el, és nem közvetlenül a végfelhasználónak. Ha a fájl gyorsítótárazható, a Caching Proxy elment egy másolatot a gyorsítótárba (5), mielőtt továbbítaná a végfelhasználónak. A gyorsítótárazható tartalomra a legjobb példát a statikus weboldalak adják; bár a Caching Proxy a WebSphere Application Server által dinamikusan előállított tartalom gyorsítótárazását és továbbszolgáltatását is támogatja.
Ha a végfelhasználók közvetlen Internet-hozzáférést kapnak, az sok esetben rendkívül rossz hatékonyságú megoldás. Minden felhasználó, aki lehív egy adott fájlt egy webkiszolgálóról, a fájlt elsőként lekérő felhasználóval azonos mennyiségű forgalmat generál a hálózaton és az internetátjárón, még akkor is, ha a fájl idő közben nem módosul. A megoldás egy továbbító Caching Proxy telepítése az átjáró közelébe.
Továbbító proxy konfiguráció használatakor a Caching Proxyt futtató számítógép az ügyfél és az Internet között helyezkedik el. A Caching Proxy továbbítja az ügyfelek kéréseit az Interneten található tartalomhosztok felé, gyorsítótárazza a lekért adatokat, majd továbbítja őket az ügyfélnek.
2. ábra - Továbbító Caching Proxy konfigurációja. Az ügyfelek böngészőprogramjai (az 1-es számú számítógépeken) úgy vannak beállítva, hogy a kéréseket a továbbító Caching Proxynak adják át (2), amely a kérések elfogására van konfigurálva. Amikor egy ügyfél kéri a tartalomhoszton (6) tárolt X fájlt, a továbbító Caching Proxy elfogja a kérést, származási IP címként a saját IP címét használva előállít egy új kérést, majd a vállalat útválasztóján (4) keresztül elküldi az Internetre (5).
Ennél a megoldásnál a származási kiszolgáló a továbbító Caching Proxynak adja át az X fájlt, és nem a végfelhasználónak. Ha a továbbító Caching Proxy gyorsítótárazási szolgáltatása engedélyezve van, akkor a Caching Proxy megvizsgálja, hogy az X fájl a fejlécében található adatok (ilyen például az elévülési dátum, illetve az, hogy a fájl dinamikusan került-e előállításra) gyorsítótárazható-e. Ha a fájl gyorsítótárazható, akkor a Caching Proxy elhelyez belőle egy másolatot a saját gyorsítótárában (3), mielőtt átadná a végfelhasználónak. Alapértelmezésben a gyorsítótárazás engedélyezve van, és a továbbító Caching Proxy memóriabeli gyorsítótárat használ; ugyanakkor más típusú gyorsítótárazás is konfigurálható.
Az X fájlra vonatkozó első kérésnél a továbbító Caching Proxy még nem javítja az Internet elérésének hatékonyságát. Éppen ellenkezőleg, az X fájlt elsőként elérő felhasználó várhatóan nagyobb válaszidőt fog tapasztalni, mintha a továbbító Caching Proxy nem lenne jelen. Ennek oka az, hogy a továbbító Caching Proxynak némi időre van szüksége az eredeti kéréscsomag feldolgozásához, valamint a kapott X fájl fejlécében található, a gyorsítótárazhatóságot szabályozó adatok vizsgálatához. A továbbító Caching Proxy előnye akkor jelentkezik, ha később más felhasználók is kérik az X fájlt. A továbbító Caching Proxy ellenőrzi, hogy az X fájl általa gyorsítótárazott példánya még érvényes-e (nem évült-e el), és ha igen, akkor közvetlenül a gyorsítótárából adja át, nem továbbítja a kérést az Interneten keresztül a tartalomhosztnak.
Még ha a továbbító Caching Proxy úgy is találja, hogy a kért fájl elévült akkor sincs feltétlenül szükség a fájl ismételt lekérésére a tartalomhoszttól. Ehelyett csak egy különleges állapotellenőrző üzenetet küld a tartalomhosztnak. Ha a tartalomhoszt azt jelzi, hogy a fájl nem változott, akkor a továbbító Caching Proxy átadhatja a felhasználónak a gyorsítótárazott példányt.
A továbbító Caching Proxy ilyen jellegű konfigurációját továbbító proxynak nevezzük, mert a Caching Proxy a böngészőprogramok nevében cselekszik, továbbítva az Interneten keresztül a kéréseiket a tartalomhosztoknak. A gyorsítótárazást végző továbbító proxy használata két szempontból is előnyös:
A Caching Proxy számos hálózati átviteli protokoll proxyzására képes, ideértve a HTTP (Hypertext Transfer Protocol, Hiperszöveg átviteli protokoll), az FTP (File Transfer Protocol, Fájlátviteli protokoll) és a Gopher protokollt egyaránt.
A továbbító Caching Proxy egyik változata az átlátszó Caching Proxy. Ebben a szerepben a Caching Proxy ugyanazt a funkciót látja el, mint az alapszintű továbbító Caching Proxy, de mindeközben az ügyfelek nem szereznek tudomást a jelenlétéről. Az átlátszó Caching Proxy konfiguráció csak Linux rendszereken támogatott.
A Továbbító Caching Proxy részben ismertetett konfigurációban minden ügyfél böngészőjét külön be kell állítani úgy, hogy a kéréseit egy meghatározott továbbító Caching Proxynak adja át. Az ilyen rendszerek fenntartása azonban számos problémát okozhat, különösen, ha nagyszámú ügyfélgépet foglalnak magukba. A Caching Proxy számos az adminisztráció egyszerűsítését szolgáló alternatívát támogat. Az egyik lehetőség a Caching Proxy átlátszó proxyként való konfigurálása; lásd: 3. ábra. Ahogy a normál továbbító Caching Proxy, úgy az átlátszó Caching Proxy is egy az átjáróhoz közeli számítógépen fut, de az ügyfelek böngészőprogramjai nincsenek arra konfigurálva, hogy a kéréseiket a továbbító Caching Proxynak adják át. Az ügyfelek nem tudnak arról, hogy proxy található a rendszerben. Ehelyett egy útválasztó van úgy konfigurálva, hogy elfogja az ügyfelek kéréseit, majd továbbítsa őket az átlátszó Caching Proxynak. Amikor a számítógépek valamelyikén dolgozó ügyfél (1-es számmal van jelölve) kéri a tartalomhoszton (6) tárolt X fájlt, akkor az útválasztó (2) átadja a kérést a Caching Proxynak. A Caching Proxy származási IP címként a saját címét használva előállít egy új kérést, majd az útválasztó (2) közreműködésével továbbítja az új kérést az Interneten (5) keresztül. Amikor az X fájl megérkezik, a Caching Proxy gyorsítótárazza (amennyiben ez lehetséges; a gyorsítótárhatóság a Továbbító Caching Proxy részben ismertetett feltételektől függ), majd átadja a fájlt a kérést indító ügyfélnek.
A HTTP kérések esetében egy további lehetőség a proxykonfigurációval kapcsolatos adatok az összes böngészőben történő tárolása helyett az automatikus proxykonfiguráló szolgáltatás alkalmazása. A szolgáltatást számos böngésző támogatja, ideértve a Netscape Navigator 2.0-s és újabb, valamint a Microsoft Internet Explorer 4.0-s és újabb változatait. Ebben az esetben létre kell hozni legalább egy központi automatikus proxykonfiguráló (proxy automatic configuration, PAC) fájlt, majd a böngészőket úgy kell beállítani, hogy a helyi proxykonfiguráció helyett ezek egyikére hivatkozzanak. A böngészők automatikusan észlelik a PAC változásait, és ennek megfelelően módosítják saját proxyhasználatukat. Ezzel nemcsak a böngészőkben megadott különálló konfigurációs adatok fenntartása válik feleslegessé, de a kérések átirányítása is könnyen megoldható, ha valamelyik proxykiszolgáló elérhetetlenné válna.
A harmadik alternatíva a Web Proxy Auto Discovery (WPAD) mechanizmus használata, ezt szintén több böngésző támogatja, köztük az Internet Explorer 5.0-s és újabb változatai. Ha engedélyezi ezt a szolgáltatást a böngészőben, akkor az automatikusan megkeresi a hálózat egyik WPAD-megfelelő proxykiszolgálóját, és hozzá irányítja a webes kéréseit. Ebben az esetben központi proxykonfigurációs fájl fenntartására nincs szükség. A Caching Proxy WPAD-megfelelő.
Ha fejlett gyorsítótárazási funkcionalitást szeretne biztosítani, akkor alkalmazza a Caching Proxyt fordított proxyként, a Load Balancer összetevővel együtt. A gyorsítótárazási és a terheléskiegyenlítési képesség integrálásával hatékony, magas szinten kezelhető webes infrastruktúrát hozhat létre.
4. ábra - A Caching Proxy és a Load Balancer összetevő együttes használata a webes tartalom még erős terhelés mellett is hatékony átadására. Ebben a konfigurációban a proxyszerver (4) elfogja azokat a kéréseket, amelyek URL címe megegyezik a tartalomhosztokból álló fürt hosztnevével; (7) utóbbiak terheléskiegyenlítését a Load Balancer végzi (6).
Jelmagyarázat: 1--Ügyfél 2--Internet 3--Útválasztó/Átjáró 4--Caching Proxy 5--Gyorsítótár 6--Load Balancer 7--TartalomhosztAmikor az (1) ügyfél kéri az X fájlt, a kérés keresztülhalad az Interneten (2), majd az internetátjárón keresztül belép a vállalat belső hálózatába (3). A proxyszerver elfogja a kérést, előállít egy új kérést, amelynek forráscíme a saját IP címe lesz, majd az új kérést elküldi a fürtcímen elérhető Load Balancernek. A Load Balancer a saját terheléskiegyenlítési algoritmusát használja annak meghatározására, hogy pillanatnyilag melyik tartalomhoszt képes kielégíteni az X fájlra vonatkozó kérést. A tartalomhoszt az X fájlt a proxyszervernek adja át, és nem a Load Balancernek. A proxyszerver eldönti, hogy gyorsítótárazza-e a fájlt, majd az előzőekben bemutatott módon továbbítja a végfelhasználónak.
A Caching Proxy Dynamic Caching bedolgozója szintén továbbfejlesztett gyorsítótárazási funkciókat biztosít. A WebSphere Application Serverrel összekapcsolva a Caching Proxy képes gyorsítótárazni, továbbszolgáltatni és érvényteleníteni a Java Server Pages (JSP) formátumú vagy a WebSphere Application Server szerver kisalkalmazások válaszaként kapott dinamikus tartalmat.
Általában a meghatározatlan elévülési idejű dinamikus tartalmat "ne gyorsítótárazza" jelöléssel kell ellátni, mert a gyorsítótár normál, idő alapú elévülési eljárásával a megfelelő idő eltelte utáni eltávolítás nincs biztosítva. A Dynamic Caching bedolgozó eseményvezérelt elévültetési eljárásával a proxyszerver meghatározatlan elévülési idejű tartalmak gyorsítótárazására is képes. Az ilyen tartalmak a hálózat peremén végzett gyorsítótárazásával megelőzhető, hogy a tartalomhosztok a kérések kiszolgálásához újra és újra a megfelelő Application Serverhez forduljanak. Mindez a következő előnyöket nyújtja:
A szerver kisalkalmazások válaszának gyorsítótárazása ideális megoldás a dinamikusan előállított weboldalak esetében, amelyeknek elévülése az alkalmazási logikán vagy valamilyen eseményen alapul, mint például egy adatbázisból érkező üzenet. Bár az ilyen oldalak élettartama korlátozott, az élettartam értékét nem lehet a létrehozáskor megadni, mert előre nem tudható az elévültetés aktiválásának időpontja. Ha az ilyen oldalak élettartama nullára van beállítva, a tartalomhosztok a dinamikus tartalom szolgáltatásakor magas büntetést kapnak.
A Caching Proxy és az Application Server dinamikus gyorsítótárazási szolgáltatásának összehangolásáért a két rendszer közösen felel. Ha például adott egy nyilvános weboldal, amelyet egy az aktuális időjárás-előrejelzést szolgáltató alkalmazás dinamikusan állít elő, akkor azt exportálni lehet az Application Server segítségével, illetve gyorsítótárazni lehet a Caching Proxyval. Ekkor a Caching Proxy az alkalmazás futtatásának eredményeit számos különböző felhasználónak át tudja adni, egészen addig, amíg értesítést nem kap az oldal érvénytelenné válásáról. A Caching Proxy a szerver kisalkalmazások válaszának gyorsítótárazására szolgáló tárának tartalma addig érvényes, amíg a proxyszerver a gyorsítótár telítődése miatt el nem távolít egy bejegyzést, a Caching Proxy konfigurációs fájljában az ExternalCacheManager utasítással megadott alapértelmezett időkorlát le nem jár, vagy a Caching Proxy egy érvénytelenítő üzenetet nem kap, amely a tartalom a gyorsítótárából való eltávolítására szólítja fel. Érvénytelenítő üzenetet az a WebSphere Application Server küldhet, amely a tartalom felett rendelkezik, és ezek az üzenetek minden egyes konfigurált Caching Proxyhoz eljutnak.
A Caching Proxy további fontos és különleges gyorsítótárazási szolgáltatásokat biztosít:
A Caching Proxy bevezetése hatással van a hálózat teljesítményére. A Caching Proxyt önállóan vagy a Load Balancerrel összekapcsolva is alkalmazhatja a hálózat teljesítményének javítására. Az említett rendszerek bemutatását a következő részben találja: A WebSphere Application Server Edge összetevők bemutatása
A Caching Proxy teljesítménye erősen függ attól, hogy milyen hardveren fut, valamint milyen annak a rendszernek a teljes architektúrája, amelybe bevezetik. A hálózati teljesítmény optimalizálásához a hardvert és a teljes hálózati architektúrát a proxyszerver igényeinek megfelelően kell kialakítani.
A Caching Proxy szoftver alapszintű konfigurációja és adminisztrációja, valamint az operációs rendszer szintű hangolása szintén nagyban befolyásolja a Caching Proxy teljesítményét. A teljesítménynövekedést számos szoftverkonfigurációs változtatással el lehet érni; ideértve többek között, de nem kizárólagosan a naplózási utasítások módosítását, a leképezési szabályokat, a bedolgozókat, az időkorlátok értékeit, a gyorsítótár konfigurációs értékeit és az aktív szál értékeket. A Caching Proxy konfigurálásáról részleteket a Caching Proxy Adminisztrációs kézikönyvben talál.
Az operációs rendszerek is számos olyan konfigurációs értékkel rendelkeznek, amelyek megváltoztatásával teljesítménynövekedést lehet elérni; ideértve többek között, de nem kizárólagosan a TCP és az ARP működésének hangolását, a fájlleírókra vonatkozó korlátok növelését, a rendszerórák összehangolását, a hálózati csatolókártyák hangolását, valamint az alábbiakban megadott, a rendszeradminisztrációs feladatok elvégzésére vonatkozó általános és bevált eljárásokat.
FONTOS: A Caching Proxy az Edge összetevők minden telepítésekor elérhető, kivéve a következőket:
Ebben a részben azokat a hálózati hardverekkel kapcsolatos problémákat tárgyaljuk, amelyeket a Caching Proxy bevezetésekor figyelembe kell venni.
A proxyszerver számára nagymennyiségű memóriát kell biztosítani. A Caching Proxy akár 2 GB virtuális címteret is képes felhasználni, ha nagyméretű, csak a memóriát használó gyorsítótár fenntartására van konfigurálva. A kernel, a megosztott könyvtárak és a hálózati pufferek szintén igényelnek memóriát. Ebből fakadóan előfordulhat, hogy a proxyszerver fizikaimemória-igénye akár a 3 vagy 4 GB-ot is eléri. Megjegyezzük, hogy a csak a memóriát használó gyorsítótár számottevően gyorsabb, mint a nyers lemezes, és kizárólag a konfiguráció megváltoztatásával komoly teljesítménynövekedést lehet elérni.
Fontos, hogy a Caching Proxyt futtató számítógépen nagymennyiségű lemezterület álljon rendelkezésre. Ez különösen lemezes gyorsítótárazás használatakor igaz. A számítógép számára a merevlemez olvasása és írása meglehetősen leterhelő folyamat. Bár a Caching Proxy I/O eljárásai hatékonyak, a merevlemezek mechanikai korlátai behatárolhatják a teljesítményt, ha a Caching Proxy lemezes gyorsítótár használatára van konfigurálva. A lemez I/O miatti szűk keresztmetszet kedvezőtlen hatásai csökkenthető olyan megoldásokkal, mint a több merevlemez használata a nyers gyorsítótáreszközökhöz és a naplófájlok tárolásához, valamint rövid elérési idejű, magas fordulatszámú és nagy átviteli sebességgel rendelkező lemezmeghajtók használata.
A hálózati követelmények, mint a sebesség, a típus és a hálózati csatolók száma, valamint a hálózati csatlakozások sebessége a proxyszerverhez, szintén befolyásolják a Caching Proxy teljesítményét. A teljesítmény szempontjából általában a legnagyobb előnyt a proxyszerver számítógép két hálózati csatolóval való ellátása jelenti: egy csatoló a bejövő forgalomnak és egy a kimenőnek. Egyetlen hálózati csatoló használatakor előfordulhat, hogy a HTTP-kérések és -válaszok miatti forgalom önmagában is kihasználja a csatoló kapacitását. Továbbá a hálózati csatolóknak legalább 100 Mb/s sebességűeknek kell lenniük, és mindig teljes duplex működésre kell konfigurálni őket. Erre azért van szükség, mert az útválasztók és a kapcsolók közötti automatikus egyeztetés hibákat és romló teljesítményt okozhat. Végül, rendkívül fontos a hálózati csatlakozások sebessége. Nem várhatja el nagymennyiségű kérés kiszolgálását és az optimális átviteli teljesítmény elérését, ha a Caching Proxy számítógép kapcsolata egy egyébként is telített T1 vonal.
A Caching Proxy számítógép központi feldolgozási egysége (processzora) könnyedén korlátozó tényezővé válhat. A CPU teljesítménye befolyásolja a kérések feldolgozási idejének hosszát, valamint a hálózatban lévő CPU-k száma befolyásolja a méretezhetőséget. Fontos a proxyszerver CPU-igényét összeegyeztetni a környezettel, melynek során különös figyelmet kell szentelni a proxyszerver által csúcsidőszakban kiszolgált kérések miatti terhelés modellezésének.
Ha átfogóan jó teljesítményt szeretne elérni, akkor rendszerint előnyösebb az architektúra méretezése, mint a hardvereszközök egyenkénti hozzáadása. Nem számít, mennyi hardvert ad hozzá egy számítógéphez, mindenképpen lesz egy maximális teljesítményszintje.
Ebben a fejezetben a Caching Proxy bevezetésekor figyelembe veendő, a hálózati architektúrával kapcsolatos problémákat tárgyaljuk.
Ha a vállalat webhelye népszerű, akkor a tartalma iránti igény nagyobb lehet annál, hogy egyetlen proxyszerver hatékonyan ki tudja szolgálni, ami nagy válaszidőt eredményezhet. A hálózati teljesítmény optimalizálásához fontolja meg fürtözött, kiegyenlített terhelésű Caching Proxy számítógépek használatát, illetve a teljes hálózati architektúrán használjon megosztott gyorsítótárazást és távoli gyorsítótár-hozzáférést (RCA).
Az architektúra méretezésének egyik módja a proxyszerverek fürtözése, valamint a Load Balancer használata a terhelés közöttük való kiegyenlítésére. A proxyszerverek fürtözése nem csak a teljesítmény és a méretezhetőség szempontjából előnyös, de a redundancia és a megbízhatóság javítása miatt is. Ha csak egy proxyszervert használ, akkor az egyetlen meghibásodási pontot jelent; ha meghibásodik vagy hálózati hiba miatt elérhetetlenné válik, akkor a felhasználók nem tudják elérni a webhelyet.
Az osztott gyorsítótárazó architektúra és az RCA használatát szintén érdemes megfontolni. Az osztott gyorsítótárazó architektúra több Caching Proxy szerver között osztja szét a virtuális gyorsítótárat, amelyhez valamilyen gyorsítótárak közötti protokollt, például Internet Cache Protocolt (ICP) vagy Cache Array Routing protokollt (CARP) használnak. Az RCA-t a fürtözött gyorsítótár találati arányának nagyméretű virtuális gyorsítótár fenntartásával való maximalizálására tervezték.
A proxyszerverek RCA tömbje jóval nagyobb teljesítményre képes, mint egy különálló Caching Proxy, illetve egy önálló Caching Proxy számítógépekből álló fürt. A legtöbb esetben a teljesítmény növekedése a virtuális gyorsítótár méretének növekedéséből fakad, amivel maximalizálható a gyorsítótár találati aránya, illetve minimalizálható a gyorsítótár inkonzisztenciája és várakozási ideje. Az RCA használatakor az egyes dokumentumoknak csak egy-egy másolata található meg a gyorsítótárban. A proxyszerverfürttel a gyorsítótár összesített mérete ugyan növekedik, de a több proxyszerver nagy valószínűséggel ugyanazokat az információkat hívja le és gyorsítótárazza. Éppen ezért a teljes gyorsítótár találati aránya nem növekedik.
Az RCA-t általában nagyvállalati tartalomhosztoló környezetekben használják. Ugyanakkor az RCA nem csak nagyméretű vállalati környezetben bizonyulhat hatékonynak. Ha a hálózat terhelése olyan magas, hogy gyorsítótárazó szerverfürtre van szükség, és a kérések többsége gyorsítótár-találat, akkor fontolja meg az RCA használatát. A hálózat jellemzőitől függően az RCA nem minden esetben javítja a teljesítményt ugyanis az RCA használatakor az egyes ügyfelek által igénybe vett TCP-kapcsolatok száma növekedik. Ennek oka az, hogy egy RCA tag nem csak azoknak az URL címeknek a kiszolgálásáért felelős, amelyekhez a legmagasabb a pontszáma, de a kéréseket más tagokhoz vagy fürtökhöz is továbbítania kell, ha olyan URL címre vonatkozó kérést kap, amelyekhez nem neki a legmagasabb a pontszáma. Ez azt jelenti, hogy egy RCA tömb minden egyes tagjának több nyitott TCP-kapcsolatot kell fenntartania, mintha önálló szerverként üzemelne.
A teljesítmény javításához a legnagyobb mértékben a Caching Proxy gyorsítótárazási képességei járulnak hozzá. A proxyszerver gyorsítótárja ugyanakkor könnyen szűk keresztmetszetté válhat, ha hibásan van konfigurálva. A legjobb gyorsítótár-konfiguráció meghatározásához jelentős erőfeszítést kell tenni a forgalom jellemzőinek elemzésére. A tartalom típusa, mérete, mennyisége és jellemzői egyaránt befolyásolják a proxyszerver teljesítményét, legalábbis ami a dokumentumoknak a származási szerverről való lekérési idejét és a szerver terhelését illeti. Ha megismerte annak a forgalomnak a típusát, amelyet a Caching Proxy proxyzni fog, illetve a gyorsítótárából tovább fog szolgáltatni, akkor a proxyszerver konfigurálásakor kellő figyelmet fordíthat a megfelelő jellemzőkre. Ha például tudja, hogy a gyorsítótárazandó objektumok 80 százaléka képfájl (*.gif vagy *.jpg), és a képek mérete körülbelül 200 KB, akkor könnyebben el tudja végezni a gyorsítótárazási paraméterek hangolását és a gyorsítótár méretének meghatározását. Továbbá annak felismerése, hogy például a tartalom túlnyomó része testreszabott, dinamikus oldal, amelyek jellemzően nem gyorsítótárazhatók, szintén fontos tényező a Caching Proxy hangolásában.
A forgalom jellemzőinek elemzése lehetővé teszi annak meghatározását, hogy memóriabeli vagy lemezes gyorsítótár használatával lehet optimális teljesítményt elérni. A hálózati forgalom jellemzőinek ismerete annak eldöntéséhez is elengedhetetlen, hogy a Caching Proxy dinamikus gyorsítótárazó szolgáltatásának használata a teljesítmény javulásához vezetne-e.
A lemez alapú gyorsítótárazás olyan webhelyek esetében jelent megfelelő választást, amelyeknél nagymennyiségű információt kell gyorsítótárazni. Ha például a webhely nagymennyiségű tartalmat tárol (5 GB-nál többet) és 80 és 90% közötti a gyorsítótár-találati arány, akkor lemez alapú gyorsítótárat érdemes használni. Igaz, a memória (RAM) alapú gyorsítótár gyorsabb, és vannak olyan helyzetek, amikor nagyméretű webelyeknél is megvalósítható a csak memória alapú gyorsítótárazás. Ha például a Caching Proxy gyorsítótár-találati aránya kevésbé fontos, vagy osztott gyorsítótár-konfigurációt használjanak, akkor a memória alapú gyorsítótár jelenti a jobb választást.
A Caching Proxy a WebSphere Application Server dinamikus gyorsítótára által előállított dinamikus tartalom (JSP és szerver kisalkalmazás tartalom) gyorsítótárazására és érvénytelenítésére is képes, virtuálisan kiterjesztve a Application Server gyorsítótárát a hálózat alapú gyorsítótárra. A dinamikusan előállított tartalom gyorsítótárazásának lehetővé tétele kedvezően befolyásolja a hálózat teljesítményét, ha az adott környezetben számos kérés irányul dinamikusan előállított nyilvános weboldalakra, és ezek elévülése az alkalmazási logikán vagy valamilyen eseményen, például egy adatbázisból érkező üzeneten alapul. Az oldal élettartama véges, de a lejárati határidőt nem lehet a létrehozáskor beállítani; emiatt a dinamikus gyorsítótárazásra és az érvénytelenítésre képtelen hosztoknak az ilyen oldalakat nulla élettartamúként kell megjelölniük.
Ha egy ilyen dinamikusan előállított oldalt az élettartama során legalább egy felhasználó egynél többször lekér, akkor a dinamikus gyorsítótárazás fontos kiterhelési lehetőséget jelent, valamint a hálózat tartalomhosztjainak terhelését is mérsékli. A dinamikus gyorsítótárazás használata a hálózati késleltetések csökkentésével és az internetes bejárási utak számának csökkentésével a felhasználók által érzékelt válaszidők javulásához vezet, ezzel is hozzájárulva a hálózat teljesítményének fokozásához.
A tartalomhosztokkal például a WebSphere Application Serverrel vagy az Application Server Caching Proxy összetevővel összekapcsoltan működtetve az Application Server Load Balancer összetevője lehetővé teszi a hálózat rendelkezésre állásának és méretezhetőségének növelését. (Az említett Edge összetevőknek az ismertetését lásd: A WebSphere Application Server Edge összetevők bemutatása.) A Load Balancer összetevőt elsősorban vállalati hálózatokban használják, és az Internet és a vállalat háttérszerverei között helyezkedik el. A Load Balancer összetevő az Internet felé a vállalat egyetlen megjelenési pontjaként viselkedik, még akkor is, ha a vállalat a magas terhelés és a nagymennyiségű tartalom miatt több háttérszervert használ.
A rendelkezésre állás növelése terheléskiegyenlítéssel és a feladatátvétel támogatásával érhető el.
FONTOS: A Caching Proxy az Edge összetevők minden telepítésekor elérhető, kivéve a következőket:
A terheléskiegyenlítés a proxyszerverek és az alkalmazásszerverek átlátszó módon végzett fürtözésével javítja a webhelyek rendelkezésre állását és méretezhetőségét. Segítségével az IT infrastruktúrák méretezhetősége nagymértékben javítható, mivel lehetővé teszi a háttérfeldolgozási teljesítmény átlátszó módon való növelését.
A nagy számú látogató kiszolgálásának egyik módja a tartalom több hosztra való többszörözése, ám ekkor valamilyen módon ki kell egyenlíteni közöttük a terhelést. A tartománynév-szolgáltatás (DNS) ugyan képes az alapszintű, körbeforgó jellegű terheléskiegyenlítés biztosítására, de ez számos környezetben csak meglehetősen rossz megoldást ad.
A tartalom megtöbbszörözött példányait tároló hosztok közötti terheléskiegyenlítésre egy kifinomultabb megoldást jelent a Load Balancer Dispatcher összetevőjének használata. Lásd: 5. ábra Ebben a konfigurációban az összes tartalomhoszt (az 5 számmal jelzett számítógépek) ugyanazt a tartalmat tárolja. Általuk egy kiegyenlített terhelésű fürt jön létre, és a 4 jelzésű Load Balancer számítógép egyik hálózati felületéhez a fürt hosztneve és IP címe van hozzárendelve. Amikor az 1 jelzésű számítógépen dolgozó végfelhasználó az X fájlt kéri, a kérés keresztülhalad az Interneten (2), majd az internetátjárón (3) keresztül belép a vállalat belső hálózatába. A Dispatcher összetevő elfogja a kérést, mivel az URL címe a Dispatcher összetevő hosztnevére és IP címére van leképezve. A Dispatcher eldönti, hogy a fürtből pillanatnyilag melyik tartalomhoszt a legalkalmasabb a kérés kiszolgálására, majd továbbítja a kérést a hoszthoz. Ha a MAC továbbító módszer konfigurálva van, akkor a hoszt az X fájlt közvetlenül az ügyfélnek adja át (vagyis az X fájl nem halad keresztül a Load Balancer összetevőn).
Jelmagyarázat: 1--Ügyfél 2--Internet 3--Útválasztó/Átjáró 4--Dispatcher 5-- TartalomhosztAlapértelmezésben a Dispatcher a DNS rendszerhez hasonlóan körbeforgó terheléskiegyenlítést használ, ám a DNS számos hiányosságát kiküszöböli. A DNS rendszerrel ellentétben nyomon követi, ha a tartalomhoszt nem áll rendelkezésre vagy nem elérhető, és nem folytatja az ügyfelek kéréseinek az elérhetetlen tartalomhoszthoz való irányítását. Továbbá figyelembe veszi a tartalomhosztok pillanatnyi leterheltségét, nyomon követve az új, az aktív és a befejezett kapcsolatokat. A terheléskiegyenlítést a Load Balancer külön megrendelhető tanácsadó és kezelő összetevőjének aktiválásával tovább optimalizálhatja. Az összetevők még pontosabban nyomon követik a tartalomhosztok állapotát, és a kiegészítő információkat felhasználják a terheléskiegyenlítési folyamat finomításához. A kezelő lehetővé teszi, hogy a döntési folyamatban használt különböző tényezőkhöz különböző súlyokat rendeljen hozzá, így az adott helyhez személyre szabott terheléskiegyenlítést valósíthat meg.
A Load Balancer Dispatcher összetevő Caching Proxy számítógépek között is képes terheléskiegyenlítést végezni. Ha egy vállalat webhelye népszerű, akkor a tartalma iránti igény olyan nagy lehet, hogy egyetlen proxyszerver nem tudja hatékonyan kielégíteni, ami végül a proxyszerver teljesítményének leromlásához vezethet.
Arra is van lehetőség, hogy több Caching Proxy rendszer egyetlen tartalomhoszt számára nyújtson proxyszolgáltatásokat (a következő ábrán látható konfigurációhoz hasonlóan: 1. ábra), de ha a hely elég népszerű ahhoz, hogy proxyszervereket igényeljen, akkor valószínűleg tartalomhosztból is többre van szükség, amelyek között a terheléskiengyelítést a Load Balancer biztosítja. 6. ábra - Példakonfiguráció. A 4 jelzésű Dispatcher egy két proxyszerverekből álló fürt (5) tagjainak biztosít terheléskiegyenlítést, a 7 jelzésű Dispatcher összetevő pedig a három tartalomhosztból álló fürt (8) terheléskiegyenlítését biztosítja.
Jelmagyarázat: 1--Ügyfél 2--Internet 3--Útválasztó/Átjáró 4--Dispatcher 5--proxyszerver 6--Gyorsítótár 7--Dispatcher 8-- TartalomhosztA 4 jelzésű Dispatcher összetevő fürtjének hosztneve az a hosztnév, amely a vállalat webes tartalmának URL címeiben is megjelenik (amely a webhely neve, ahogyan az Interneten látható). A 7 jelzésű Dispatcher fürt hosztneve nem látható az Interneten, és így bármilyen értéket felvehet. Például az ABC vállalat esetében a 4 jelzésű Dispatcher hosztneve www.abc.com, míg a 7 jelzésű Dispatcher neve http-balancer.abc.com.
Tegyük fel, hogy az egyik 1 jelzésű ügyfélszámítógép böngészőjének el kell érnie az X fájlt, amely a 8 jelzésű tartalomszervereken található. A HTTP-kérés keresztülhalad az Interneten (2), majd az átjárón keresztül (3) belép a vállalat belső hálózatába. Az útválasztó a kérést a 4 jelzésű Dispatcher összetevőhöz irányítja, az pedig továbbadja annak a proxyszervernek (5), amely a terheléskiegyenlítési algoritmus szerint a legalkalmasabb a kérés kezelésére. Ha a proxyszerver tartalmazza az X fájlt a gyorsítótárában (6), akkor azt közvetlenül átadja a böngészőnek, kihagyva a 4 jelzésű Dispatcher összetevőt.
Ha a proxyszerver nem rendelkezik másolattal az X fájlról a gyorsítótárában, akkor létrehoz egy új kérést, amelynél a fejléc származás mezőjébe a saját hosztnevét írja, majd elküldi a kérést a 7 jelzésű Dispatcher összetevőnek. A Load Balancer eldönti, hogy pillanatnyilag melyik tartalomhoszt (8) képes a legjobban kielégíteni a kérést, és ahhoz irányítja a kérést. A tartalomhoszt lekéri az X fájlt az adattároló egységtől, és közvetlenül a proxyszervernek küldi vissza, kihagyva a 7 jelzésű Dispatcher összetevőt. A proxyszerver szükség szerint gyorsítótárazza az X fájlt, majd továbbítja a böngészőnek, kihagyva a 4 jelzésű Dispatcher összetevőt.
Ha nagyszámú ügyfélnek biztosít Internet-hozzáférést, akkor ezek nagyobb internethasználati terhelést okozhatnak, mint amit egyetlen proxyval hatékonyan ki lehet szolgálni. Ahogy a Caching Proxyt túlterhelik a kérések, előfordulhat, hogy az ügyfelek rosszabb válaszidőket tapasztalnak, mintha közvetlenül kapcsolódnának az Internethez. Ha a Caching Proxy meghibásodik vagy hálózati hiba miatt elérhetetlenné válik, akkor az Internet-hozzáférés is lehetetlenné válik. A megoldás több Caching Proxyt futtató számítógép telepítése, és a Load Balancer Dispatcher összetevőjének használata a terhelés ezek között a számítógépek között történő elosztására.
A Dispatcher nélkül csak úgy lehet több Caching Proxyt futtató számítógéppel valóban átlátszó proxyszolgáltatást nyújtani, ha az útválasztók képesek arra, hogy azonos típusú forgalmat egynél több Caching Proxyhoz továbbítsanak, ezt azonban nem minden útválasztó támogatja. Dispatcher nélkül is lehet normál továbbító proxyszolgáltatást nyújtani több Caching Proxyt futtató számítógépen, ám ehhez az ügyfelek böngészőjét explicit módon be kell állítani arra, hogy elsődleges proxyként a Caching Proxyt futtató számítógépek valamelyikét vegyék igénybe. Ha ez a Caching Proxy meghibásodik, túlterheltté vagy elérhetetlenné válik, akkor előfordulhat, hogy a végfelhasználók nem tudják elérni az Internetet. Az ilyen helyzetek elkerülésére automatikus proxykonfiguráló (PAC) fájlt lehet létrehozni (leírását lásd: Átlátszó továbbító Caching Proxy (csak Linux rendszeren)), amely átirányítja a böngészőt a másodlagos Caching Proxyk valamelyikére. PAC fájllal ugyanakkor nem oldható meg a terhelés a Caching Proxyt futtató számítógépek közötti elosztása; ha az egyik Caching Proxy jóval nagyobb terhelést kap, mint a másik, akkor a teljesítménye nagy valószínűséggel leromlik, és az ügyfelei rossz válaszidőket fognak tapasztalni. Ahhoz, hogy minden ügyfél hasonló teljesítményt érezzen, nagyjából azonos számú böngészőt kell konfigurálni az egyes Caching Proxyk használatára, majd az elosztást saját kezűleg kell követni, vagyis a böngészők telepítése és eltávolítása során ügyelni kell a terheléselosztás egyenletességére.
7. ábra - Az ábrán olyan hálózati konfiguráció látható, amelyben a Dispatcher terheléskiegyenlítést végez egy Caching Proxyt futtató számítógépekből álló fürtben. A Dispatchert futtató számítógép hálózati csatolóinak egyike a fürt dedikált hosztnevével és IP címével van konfigurálva. Az ügyfelek böngészői úgy vannak beállítva, hogy az internetes kéréseiket a fürt hosztnevére továbbítsák. Ha egy az 1-es számmal jelölt ügyfélgépek valamelyikén futó böngésző hozzá szeretne férni a tartalomhoszton (7) található X fájlhoz, akkor a fürt hosztnevére vagy címére küldi el a kérését. Itt a Dispatcher (2) elfogja a kérést, majd továbbítja a megfelelő Caching Proxynak (3). A Caching Proxy létrehoz egy új kérést, majd a vállalati átjárón (5) és az Interneten (6) keresztül elküldi, illetve - amennyiben ez lehetséges - tárolja a kapott fájlt a saját gyorsítótárában (4); a folyamat részletesebb leírását lásd: Továbbító Caching Proxy
A Dispatcher felismeri, ha a Caching Proxyt futtató számítógépek valamelyike elérhetetlenné válik, és automatikusan másik gépre irányítja a kéréseket. Ennek a megoldásnak köszönhetően lehetővé válik a Caching Proxyt futtató számítógépek az Internet-hozzáférés szüneteltetése nélkül történő (például karbantartási célokat szolgáló) leállítása. A Dispatcher számos konfigurációs lehetőséget támogat, amelyekkel pontosan szabályozhatók a terheléskiegyenlítési döntések során figyelembe vett tényezők. A Caching Proxyt futtató számítógépekre külső Dispatcher programok is telepíthetők, amelyekkel megfigyelhető az állapotuk, illetve az állapotinformációk átadhatók a Dispatchernek. A részleteket lásd a WebSphere Application Server Load Balancer adminisztrátori kézikönyvében. Több Caching Proxy használatakor megjelenik a hatékonyság romlásának veszélye, ugyanis, ha több ügyfél különböző Caching Proxykon keresztül kéri ugyanazt a fájlt, akkor több Caching Proxy is gyorsítótárazhatja azt. A redundancia kiküszöbölésére alkalmazható a távoli gyorsítótár-elérés (RCA), amely lehetővé teszi a megadott csoportba tartozó proxyk számára, hogy megosszák egymással saját gyorsítótáruknak a tartalmát. A RCA csoportba tartozó proxyk mindegyike ugyanazt az algoritmust alkalmazza annak meghatározására, hogy melyik Caching Proxy felelős az egyes URL címek kezeléséért. Amikor egy Caching Proxy olyan URL címet fog el, amelynek kezeléséért nem ő a felelős, akkor továbbítja a kérést a megfelelő Caching Proxynak. A felelős Caching Proxy elvégzi a kérés kielégítéséhez szükséges műveleteket, ami jelentheti a gyorsítótárból való beolvasást vagy a kérés továbbítását a megfelelő tartalomhoszt felé, illetve a kapott fájl gyorsítótárazását, amennyiben szükség és lehetőség van erre. A felelős Caching Proxy ezt követően átadja a fájlt az eredeti Caching Proxynak, amely eljuttatja a kérést indító végfelhasználóhoz.
Ha az RCA csoport az adott URL cím kezeléséért felelős Caching Proxyja meghibásodik, akkor az eredeti, az ügyfél kérését fogadó Caching Proxy közvetlenül kapcsolódik a tartalomhoszthoz (vagy egy tartalék Caching Proxy kiszolgálóhoz, amennyiben van ilyen megadva). A felhasználók tehát egészen addig el tudják érni a fájlokat, amíg az RCA csoport legalább egy Caching Proxyja megfelelően működik.
Ez a konfiguráció kiváló teljesítményű Internet-hozzáférést képes biztosítani; a Dispatcher kiegyenlíti a kérésekből fakadó terhelést a Caching Proxyt futtató számítógépek között. Az egyik lehetséges probléma az, hogy a Dispatcher egyszeres meghibásodási pontot jelent. Ha meghibásodik vagy hálózati hiba miatt elérhetetlenné válik, akkor az ügyfelek böngészői nem tudják elérni a Caching Proxykat és az Internetet. A megoldás egy másik Dispatcher konfigurálása az elsődleges Dispatcher tartalékaként; lásd: 8. ábra.
Ebben az esetben az 1-es számmal jelölt számítógépeken futó böngészők az X fájlra vonatkozó kéréseiket normál esetben az elsődleges Dispatchernek (2) küldik el, amely továbbítja azokat a terheléskiegyenlítési feltételek alapján kiválasztott Caching Proxynak (4). A Caching Proxy létrehoz egy új kérést, a vállalati átjárón (6) és az Interneten (7) keresztül továbbítja a tartalomhosztnak (8), majd amennyiben ez lehetséges, tárolja a kapott X fájlt a saját gyorsítótárában (5) (a folyamat ezen részének részletesebb leírását lásd: Továbbító Caching Proxy).
Ebben a konfigurációban a tartalék Dispatcher (3) egészen addig nem végez terheléskiegyenlítést, amíg az elsődleges működőképes. Az elsődleges és a tartalék Dispatcher az életjelnek nevezett üzenetek küldése-fogadása révén folyamatosan követik egymás állapotát. Ha a tartalék Dispatcher észleli, hogy az elsődleges meghibásodott, akkor az elsődleges Dispatcher hosztnevére és IP címére küldött kérések fogadásával automatikusan átveszi a terheléskiegyenlítés feladatát. Arra is van lehetőség, hogy két Dispatchert kölcsönös magas szintű rendelkezésre állásra konfiguráljunk. Ebben az esetben két különálló Caching Proxy fürt számára mindkét gép aktív terheléskiegyenlítést végez, miközben tartalékként szolgál a másik számára. További részleteket a WebSphere Application Server Load Balancer adminisztrátori kézikönyvében talál.
A Dispatcher általában nem igényel komolyabb feldolgozási vagy memória-erőforrást, tehát a Dispatchert futtató számítógépen más alkalmazások is üzemeltethetők. Ha fontos a készülékekre fordított anyagi forrásokkal való takarékoskodás, akkor a tartalék Dispatcher akár a Caching Proxyval azonos számítógépen is futtatható. 9. ábra - Az ábrán olyan konfiguráció látható, amelyben a tartalék Dispatcher a Caching Proxyval azonos számítógépen (3) fut.
A Load Balancer egyetlen jelenléti pontként viselkedik a vállalat tartalomhosztjai számára. Ez azért előnyös, mert így a fürt hosztnevét és címét kell csak közzétenni DNS rendszerben, az egyes tartalomhosztok címét és hosztnevét nem, amely egy további védelmi szintet biztosít az alkalmi támadások ellen, illetve biztosítja a vállalat webhelyének egységes arculatát. A webhely rendelkezésre állásának további javításához konfiguráljon egy másik Load Balancer összetevőt az elsődleges Load Balancer összetevő tartalékaként; lásd: az 10. ábra Ha az egyik Load Balancer meghibásodik vagy hálózati hiba miatt elérhetetlenné válik, a végfelhasználók továbbra is zavartalanul érhetik el a tartalomhosztot.
Jelmagyarázat: 1--Ügyfél 2--Internet 3--Útválasztó/Átjáró 4--Elsődleges Dispatcher 5--Tartalék Dispatcher 6-- TartalomhosztNormál esetben az 1 jelzésű számítógépek egyikén futó böngésző az X fájlra vonatkozó kérést az elsődleges Load Balancer összetevőre leképezett fürthosztnévre küldi (4). A Dispatcher továbbítja a kérést annak a tartalomhosztnak (6) amelyet a Dispatcher a terheléskiegyenlítési feltételek alapján kiválasztott. A tartalomhoszt az X fájlt közvetlenül a böngészőnek küldi, a vállalat átjáróján keresztül (3), az Interneten keresztül (2), kihagyva a Load Balancer összetevőt.
A tartalék Dispatcher (5) nem végez terheléskiegyenlítést, amíg az elsődleges működik. Az elsődleges és a tartalék Dispatcher összetevők az életjeleknek nevezett, egymásnak rendszeres időközönként elküldött üzenetekkel nyomon követik egymás állapotát. Ha a tartalék Dispatcher azt észleli, hogy az elsődleges meghibásodott, akkor automatikusan átveszi a terheléskiegyenlítés felelősségét, és megkezdi az elsődleges fürt hosztnevére és IP címére irányított kérések elfogását.
Két Dispatcher összetevőt kölcsönös magas szintű rendelkezésre állás biztosítására is lehet konfigurálni. Ebben az esetben mindkét készülék aktív terheléskiegyenlítést végez a tartalomhosztok egy-egy különálló fürtjéhez, miközben társa tartalékaként viselkedik. (A Load Balancer for IPv4 and IPv6 telepítéseknél az egyszerű magas szintű rendelkezésre állás támogatott, de a kölcsönös magas szintű rendelkezésre állás nem.)
A Dispatcher általában nem igényel sok adatfeldolgozást vagy memória-erőforrást, így a Load Balancer számítógépen más alkalmazások is futhatnak. Ha muszáj minimalizálni a berendezések költségeit, akkor a tartalék Dispatcher összetevőt a terheléskiegyenlített fürt egyik számítógépén is lehet futtatni. 11. ábra - Egy olyan konfigurációt ismertet, amelyben a tartalék Dispatcher a fürt tartalomhosztjainak (5) egyikén fut.
Jelmagyarázat: 1--Ügyfél 2--Internet 3--Útválasztó/Átjáró 4--Elsődleges Dispatcher 5--Tartalék Dispatcher és tartalomhoszt 6--TartalomhosztFONTOS: A Content Based Routing (CBR) összetevője minden támogatott operációs rendszeren elérhető, a következő kivételekkel:
Az ilyen jellegű telepítéseknél a Load Balancer' Dispatcher összetevőjének cbr továbbítási módszerét alkalmazhatja a HTTP és HTTPS kérések a Caching Proxy használata nélkül történő, tartalom alapú útválasztására. További információkat a WebSphere Application Server Load Balancer adminisztrációs útmutatójában talál.
Load Balancer for IPv4 and IPv6 csak a Dispatcher ' összetevő mac továbbítási módszerét támogatja. A nat és a cbr továbbítási módszer nem támogatott.
Az Application Server Caching Proxy összetevőjével összekapcsoltan működtetve az Application Server Load Balancer összetevője lehetővé teszi a kérések a különböző tartalmakat tároló háttérszerverek közötti szétosztását. (Az említett Edge összetevőknek az ismertetését lásd: A WebSphere Application Server Edge összetevők bemutatása.)
Ha a Load Balancer Content Based Routing (tartalom alapú útválasztás, CBR) összetevője a Caching Proxy összetevővel együtt kerül telepítésre, akkor a HTTP-kérések az URL címek vagy más, a rendszergazda által meghatározott jellemzők alapján szétoszthatóak, így nincs szükség arra, hogy az összes háttérszerver ugyanazt a tartalmat tárolja.
A CBR használata különösen akkor előnyös, ha a webszervereknek számos különböző funkciót kell ellátniuk, vagy több, különböző típusú szolgáltatást nyújtanak. Például egy online kiskereskedő webhelyének a nagyrészt statikus katalógus megjelenítéséről és a rendelések fogadásáról egyaránt gondoskodnia kell, utóbbi azonban a cikkszámok és az ügyfélinformációk fogadásához interaktív alkalmazás, például CGI parancsfájl futtatását teszi szükségessé. A különböző feladatok elvégzéséhez gyakran hatékonyabb két különböző számítógépet használni, és a CBR összetevőre bízni az eltérő típusú forgalmak a különböző számítógépekre való továbbítását. Hasonlóan a nagyvállalatok is használhatják a CBR összetevőt arra, hogy például a fizető ügyfelek részére a fizetett kérések nagyobb teljesítményű webszerverekre való továbbításával magasabb szintű szolgáltatást nyújtsanak, mint a webhelyre csak alkalmanként látogatóknak.
A CBR az Ön által megadott szabályok alapján továbbítja a kéréseket. A legáltalánosabb típus a tartalom szabály, amely a kéréseket az URL címben szereplő útvonal alapján irányítja. Például az ABC vállalat megadhat olyan szabályokat, amelyek a http://www.abc.com/catalog_index.html URL címre vonatkozó kéréseket az egyik szerverfürtre, a http://www.abc.com/orders.html címre vonatkozó kéréseket pedig egy másik fürtre irányítják. Vannak olyan szabályok is, amelyek a kéréseket a küldő ügyfél IP címe, illetve egyéb jellemzők alapján irányítják. Ezek részletes ismertetését lásd a WebSphere Application Server Load Balancer adminisztrációs útmutató a CBR konfigurálásáról, illetve a Load Balancer és a CBR további szolgáltatásairól szóló részeiben. A szabályok szintaxisának ismertetését a WebSphere Application Server Load Balancer adminisztrációs útmutató a CBR szabálytípusokról szóló függelékében találja.
12. ábra - Egy egyszerű konfigurációt mutat be, amelyben a Load Balancer CBR összevője és a Caching Proxy együtt van telepítve a 4 jelzésű számítógépre, és a kéréseket három eltérő tartalmakat tároló tartalomhoszthoz (a 6, a 7, és a 8 jelzésűekhez) továbbítja. Amikor az 1 jelzésű számítógépen dolgozó végfelhasználó az X fájlt kéri, a kérés keresztülhalad az Interneten (2), majd az internetátjárón (3) keresztül belép a vállalat belső hálózatába. A proxyszerver elfogja a kérést, átadja az ugyanazon a gépen futó CBR összetevőnek, ami elemzi a kérésben szereplő URL címet, majd megállapítja, hogy a 6 jelzésű tartalomhoszt tartalmazza az X fájlt. A proxyszerver létrehoz egy új, az X fájlra vonatkozó kérést, és ha a gyorsítótárazó szolgáltatása engedélyezve van, akkor eldönti, hogy a 6 jelű hoszttól kapott fájl alkalmas-e a gyorsítótárazásra. Ha a fájl gyorsítótárazható, a proxyszerver elmenti egy másolatát a gyorsítótárába (5), majd átadja a fájlt a végfelhasználónak. A továbbítás más fájlok esetében is ugyanezzel a módszerrel történik: az Y fájlra vonatkozó kérés a 7 jelű tartalomhoszthoz továbbítódik, a Z fájlra vonatkozó pedig a 8 jelűhöz.
Jelmagyarázat: 1--Ügyfél 2--Internet 3--Útválasztó/Átjáró 4--Caching Proxy és Load Balancer CBR összetevő 5--Gyorsítótár 6, 7, 8--Tartalomhoszt13. ábra - Összetettebb konfiguráció, amely például egy online kiskereskedő rendszerét jellemezheti. A Load Balancer CBR összetevője és a proxyszerver együtt vannak feltelepítve a 4 jelű számítógépre, és két Load Balancer számítógéphez továbbítják a kéréseket. A 6 jelzéssel ellátott Load Balancer számítógép egy tartalomhosztfürthöz (8) végez terheléskiegyenlítést, a tartalomhosztok a kiskereskedő jellemzően statikus katalógusát tárolják. A 7 jelzéssel ellátott Load Balancer a rendeléseket kezelő webszerverfürt (9) számára végzi a terheléskiegyenlítést.
Amikor az egyik 1 jelzésű számítógépen dolgozó végfelhasználó eléri a kiskereskedő katalógusának URL címét, a kérés keresztülhalad az Interneten (2), és az internetátjárón (3) keresztül belép a vállalat belső hálózatába. A proxyszerver elfogja a kérést, továbbítja az ugyanazon a számítógépen futó CBR összetevőnek, amely értelmezi az URL címet, majd megállapítja, hogy az adott URL címet a 6 jelzésű Load Balancer számítógép kezeli. A proxyszerver összeállít egy új elérési kérést, elküldi a Load Balancer összetevőnek, amely meghatározza, hogy a 8 jelzésű tartalomhosztok közül jelenleg melyik képes a legjobban kiszolgálni a kérést (az Ön által megadott feltételek alapján). A kiválasztott tartalomhoszt a katalógus tartalmát közvetlenül a proxyszervernek adja át, a Load Balancert kihagyva. Ahogy az előző példában is, a proxyszerver meghatározza, hogy a tartalom gyorsítótárazható-e, és ha igen, akkor tárolja az 5 jelzésű gyorsítótárban.
A végfelhasználó a kiskereskedő rendelési URL címét elérve lead egy rendelést, például egy a katalógusban szereplő hiperhivatkozáson keresztül. A kérés ugyanazon az útvonalon továbbítódik, mint a katalóguselérés kérése, kivéve azt, hogy a 4 jelzésű számítógépen futó CBR összetevő a 7 jelzésű Load Balancer számítógépre irányítja. A Load Balancer továbbítja a 9 jelzésű webszerverek közül a legmegfelelőbbnek, amely a választ közvetlenül a proxyszerver összetevőnek küldi el. Mivel a a rendelési információk általában dinamikusan előállított információk, a proxyszerver valószínűleg nem gyorsítótárazza őket.
Jelmagyarázat: 1--Ügyfél 2--Internet 3--Útválasztó/Átjáró 4--Caching Proxy és Load Balancer CBR összetevő 5--Gyorsítótár 6, 7--Load Balancer 8--Tartalomhoszt 9--WebszerverA Load Balancer CBR funkciója támogatja a cookie affinitást. Ez azt jelenti, hogy a rendszer egy speciális, a válaszba beillesztett adatcsomagban (cookie) rögzíti annak a szervernek az azonosítóját, amely a végfelhasználó első kérését kiszolgálta. Ha a végfelhasználó az Ön által megadott időtartamon belül újra hozzáfér ugyanahhoz az URL címhez, és a kérés tartalmazza a cookie-t, akkor a CBR a kérést az eredeti szerverhez továbbítja, és nem alkalmazza újra az általános szabályokat. Ezzel általában javul a válaszidő, ha a szerver tárol valamilyen információt a végfelhasználóról (például a hitelkártyája számát), és azt nem kell újra lekérdeznie.
Ez a rész olyan üzleti példahelyzeteket mutat be, amelyekben IBM WebSphere Application Server Edge összetevőket használnak. Ezek olyan mérnöki szempontból megalapozott és letesztelt megoldások, amelyek kitűnő teljesítményt, elérhetőséget, méretezhetőséget és megbízhatóságot nyújtanak.
Ez a rész a következő fejezeteket tartalmazza:
Vállalattól fogyasztóhoz hálózat
Vállalkozás-ügyfél banki megoldás
Az alapszintű elektronikus kereskedelmi webhely egy a vállalattól a fogyasztóhoz vezető hálózat. Az Internet növekedésének első fázisában a vállalkozások jellemzően csak arra összpontosítottak, hogy egyszerűen jelen legyenek a weben. A vállalati információkat és a termékkatalógusokat digitális formátumra alakítva elérhetővé tették a webhelyükön. A vásárlás lehetőségét e-mail címek, telefon- és faxszámok, továbbá automatizált űrlapok megadásával biztosították. Valódi online vásárlásra ugyanakkor nem volt lehetőség. Minden tranzakciónak volt egy velejáró várakozási ideje, ugyanis embereknek kellett feldolgozniuk a rendelést.
A második fázisban a vállalkozások a közvetlen online vásárlásokhoz létrehozott, biztonságos bevásárlókosarak alkalmazásával kiküszöbölték ezt a várakozási időt, és leegyszerűsítették az értékesítési folyamatot. Az áruházak adatbázisainak összehangolása és a banki rendszerekkel való integráció döntő fontosságú ezeknek az értékesítési tranzakciónak a végrehajtásában. Az a termék, amely nem érhető el, az nem is adható el, és az ilyen termékért nem lehet a vásárló pénzére számítani. Hasonlóképpen, addig nem lehet elhozni a terméket a raktárból, illetve kiszállítani a vásárlónak, amíg meg nem történik az megfelelő és érvényes fizetési tranzakció.
A harmadik fázisban a vállalat webhelye dinamikusan megjelenített hellyé fejlődik, ahol a vásárló egyre inkább ügyféllé válik, és személyre szabott tartalmat kap.
A következő példa Load Balancer és Caching Proxy összetevőt is tartalmaz.
FONTOS: A Caching Proxy az Edge összetevők minden telepítésekor elérhető, kivéve a következőket:
14. ábra Egy kisméretű kereskedelmi webhelyet szemléltet, amelyet hatékony katalógusbeli böngészésre terveztek. Az összes ügyfélkérés áthalad a tűzfalon, majd eljut a Dispatcher összetevőhöz, amely továbbítja a kéréseket az aktív gyorsítótárazást végző, a webszerverek számára helyettes szerepet játszó proxyszerverek fürthöz. A mértékszerverek a proxyszerverekkel kolokáltak, így képesek terheléskiegyenlítési adatokat biztosítani a Dispatcher összetevőnek. Ez az elrendezés csökkenti a hálózati terhelést a webszervereken, és elkülöníti őket az Internettel való közvetlen kapcsolattól.
15. ábra A fejlődés második fázisát jeleníti meg, egy olyan kereskedelmi webhelyet szemlélteti, amelyet hatékony katalógusböngészésre és a potenciális vásárlók számára gyors, biztonságos bevásárlókosarak fenntartására terveztek. A Dispatcher összetevő az internetes protokoll alapján elkülöníti a kéréseket, és összes ügyfélkérést a hálózat megfelelő ágára továbbítja. A HTTP-kérések a statikus webhelyhez futnak be, HTTPS-kérések pedig a vásárlási hálózathoz. Az elsődleges, statikus webhelyet továbbra is egy a webszerverek számára helyettesítőként viselkedő proxyszerverek fürt szolgálja ki aktív gyorsítótárazással. A hálózatnak ez a része megegyezik az első fázis hálózatával.
A webhely elektronikus kereskedelmi részét szintén egy proxyszerverek fürt szolgálja ki. Itt azonban Caching Proxy csomópontok szolgáltatásainak bővítését számos bedolgozó segíti. Az SSL kézfogások kezelése egy kriptográfiai kártyára van kiterhelve, a hitelesítés pedig az Access Manager (korábban Policy Director) bedolgozó közreműködésével folyik. A dinamikus gyorsítótárazó bedolgozó a közös adatok tárolásával csökkenti a WebSphere Application Server terhelését. A dinamikus gyorsítótár objektumainak érvénytelenítését szükség esetén az alkalmazásszerver egyik bedolgozója végzi el.
Az összes bevásárlókosár alkalmazás kapcsolatban áll a felhasználók hitelesítésére is használt ügyfél-adatbázissal. Ezzel megakadályozható, hogy a felhasználónak kétszer kelljen megadnia a személyes adatait a rendszernek: egyszer a hitelesítéshez és egyszer a vásárláshoz.
A hálózat ügyfélhasználat szerint osztja fel a forgalmat, eltávolítva az elsődleges webhelyről a processzort erősen terhelő, SSL alapú hitelesítést és az elektronikus kereskedelem bevásárlókosarait. A kettős útvonalú webhely révén a hálózati rendszergazda a különböző szerverek hangolását szerepük szerint tudja elvégezni, így azok kiváló teljesítményt tudnak elérni.
16. ábra A vállalattól a fogyasztóig terjedő hálózat fejlődésének harmadik fázisát jeleníti meg, amelyben a statikus web dinamikus megjelenítési módszereket vesz át. A proxyszerverfürt kibővült a dinamikus webtartalom gyorsítótárazásának és az Edge Side Includes (ESI) protokollnak megfelelő módon megírt oldaltöredékek összeállításának támogatásával. Ahelyett, hogy szerveroldali beillesztő megoldásokat használna a weboldalak a tartalomszervereken történő összeállításához, majd végigküldené ezeket az ügyfélspecifikus, gyorsítótárazásra alkalmatlan oldalakat a teljes hálózaton, az ESI mechanizmus lehetővé teszi az oldalak a hálózat peremén gyorsítótárazott töredékekből végzett összeállítását, amivel a sávszélesség-használat és a válaszidő egyaránt csökken.
Az ESI mechanizmus kiemelt szerepet játszik a harmadik példában, ahol a webhelyről minden egyes ügyfél személyre szabott kezdőlapot kap. Ezeknek az oldalaknak az építőelemei több WebSphere Application Servertől származnak. Az érzékeny vállalati üzleti logikát tartalmazó és védett adatbázisokkal összekötött alkalmazásszerverek tűzfal mögött vannak elkülönítve.
17. ábra - Egy hatékony, online banki megoldást szemléltet, amely hasonlít a Vállalattól fogyasztóhoz hálózat című részben bemutatott vállalkozás-fogyasztó hálózatra. Az ügyfélkérések a tűzfalon keresztül a Dispatcher összetevőhöz jutnak, amely az internetes protokoll alapján választja szét a forgalmat. A HTTP-kérések átkerülnek a webszerverek helyettes szervereként viselkedő, aktív gyorsítótárazást végző proxyszerverek fürtjéhez. A mértékszerverek kolokálva vannak a proxyszerverekkel, így képesek terheléskiegyenlítési adatokat biztosítani a Dispatchernek. Ez az elrendezés csökkenti a hálózati terhelést a webszervereken, és egy további puffert hoz létre köztük és az Internet között.
A HTTPS-kérések egy biztonságos hálózatra továbbítódnak, ahol az ügyfelek személyes pénzügyi információkat érhetnek el, valamint online banki tranzakciókat végezhetnek el. A kiterjesztett proxyszerverek fürtje biztosítja a hely méretezhetőségét. Ezek a proxyszerverek a dinamikus webtartalom gyorsítótárazását és az Edge Side Includes (ESI) protokollnak megfelelően megírt oldaltöredékek összeállítását is támogatják. Az SSL kézfogásokat egy kriptográfiai kártya kezeli, amely jelentősen csökkenti a proxyszervertől várt feldolgozási teljesítményt. Az ügyfelek hitelesítését egy Access Manager (korábban Policy Director) irányítja.
A kérések feldolgozásának feladata alkalmazáskiszolgálókból álló fürtök között oszlik el, segítségükkel elkülönülnek az EJB összetevőkben tárolt üzleti funkciók, illetve a kiszolgáló kisalkalmazásokban és a JSP fájlokban megvalósított megjelenítési réteg. Minden egyes fürtöt egy külön munkamenetszerver kezel.
A következő példa Load Balancer és Caching Proxy összetevőt is tartalmaz.
FONTOS: A Caching Proxy az Edge összetevők minden telepítésekor elérhető, kivéve a következőket:
18. ábra Egy nagymennyiségű forgalom kezelésére, minden ügyfél számára személyre szabott tartalmat biztosító webportál hálózatot szemléltet. A különböző szerverek feldolgozási terhelésének minimalizálása érdekében a hálózat egyik része sem továbbít SSL-forgalmat. Mivel a portál nem kezel érzékeny adatokat, a biztonság nem kapott kiemelt figyelmet. Fontos, hogy az ügyfélazonosítókat, jelszavakat és beállításokat tartalmazó adatbázisok biztonságban és sértetlenül maradjanak, de ez az elvárás nem befolyásolja a webhely többi részének teljesítményét.
Az összes ügyfélkérés áthalad a tűzfalon, majd eljut a Dispatcher összetevőhöz, amely kiegyenlíti az aktív gyorsítótárazást folytató, a webszerverek számára köztes szerepet játszó proxyszerverfürt tagjainak terhelését. A mértékszerverek kolokálva vannak a proxyszerverekkel, így képesek terheléskiegyenlítési adatokat biztosítani a Dispatchernek.
A tényleges dinamikus webhely egy alkalmazásszerver-fürt, amely előállítja a proxyszervereknek összeállítás céljából átadott ESI töredékeket. A mérsékelt biztonsági elvárások miatt minden egyes alkalmazásszerver képes végrehajtani az összes a webhely összeállításához szükséges funkciót. Mindegyik alkalmazásszerver azonos. Ha egy alkalmazásszerver meghibásodik, a munkamenetszerver a kéréseket a többi szerverhez tudja továbbítani, magas szintű rendelkezésre állást biztosítva a teljes webhely számára. A konfiguráció a webhely gyors bővítését is lehetővé teszi, például abban az esetben, ha a portál valamilyen különleges eseményhez szolgáltat tartalmat, és emiatt megnő a forgalma. A webhelyhez a további proxyszervereket és alkalmazásszervereket rövid idő alatt hozzá lehet adni.
Az összes statikus tartalom, például a képfájlok és az egyszerű szövegek különálló webszervereken találhatók, így szükség esetén az összetettebb alkalmazásszerverek meghibásodásának kockázata nélkül lehet elvégezni a tartalom frissítését.
A következő példa Load Balancer és Caching Proxy összetevőt is tartalmaz.
FONTOS: A Caching Proxy az Edge összetevők minden telepítésekor elérhető, kivéve a következőket:
Ez a rész az Edge összetevők telepítésének eljárását ismerteti.
Ez a rész a következő fejezeteket tartalmazza:
Az Edge összetevők követelményei
Az Edge összetevők telepítése a telepítőprogram használatával
A Caching Proxy telepítése a rendszer csomagolóeszközeivel
A Load Balancer telepítése a rendszer csomagolóeszközeivel
A jelen témakör ismerteti az Edge összetevők hardver- és szoftverigényeit, valamint útmutatást ad a Caching Proxy Konfigurálás és adminisztráció lapok és a Load Balancer online súgójának webböngészővel végzett használatához .
A WebSphere Application Server, 6.1 Változat Edge összetevők hardver- és szoftverigényeiről a következő weboldalon talál információkat: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
SDK telepítő: A Java 2 SDK minden operációs rendszeren automatikusan települ a Load Balancer összetevővel.
A böngészővel szemben támasztott minimális elvárások
A Caching Proxy a Konfigurálás és adminisztráció lapok használatával végzett konfigurálásához a böngészőnek a következőkre kell képesnek lennie:
Linux és UNIX rendszerek esetében: Ha meg szeretné tekinteni a Mozilla és a Firefox böngészők javasolt változatait, akkor látogasson el a következő weboldalra és kövesse a hivatkozásokat a támogatott szoftverek weboldalára: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Windows rendszerek esetében: Ha meg szeretné tekinteni az Internet Explorer, Mozilla és Firefox böngészők javasolt változatait, akkor látogasson el a következő weboldalra és kövesse a hivatkozásokat a támogatott szoftverek weboldalára: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
KORLÁTOZÁS: Lehetséges, hogy az Adminisztrációs lapok bal oldali függőleges görgetősávját a böngésző nem tudja megjeleníteni, ha a kibontott elemek száma túl magas a böngésző ablakában való megjelenítéshez. Emiatt a lista alján található kibontott elemek a böngésző éppen megjelenített ablakából kitolódnak, és nem érhetőek el. A probléma megoldásához korlátozza a bal oldali menü kibontott elemeinek számát. Ha a kibontott elemek száma túl magas, húzzon össze néhány elemet, amíg a lista alján található elemek a böngésző ablakában meg nem jelennek.
A lapok megfelelő megjelenítéséhez a lapot éppen megjelenítő operációs rendszernek (amelyen a böngésző fut), tartalmaznia kell a lap nyelvének megfelelő betűkészletet. A böngésző felületének ugyanakkor nem muszáj a lapokkal azonos nyelvet használnia.
Tegyük fel például, hogy Solaris 9 rendszeren a proxyszerver egy kínai változata fut. A Solaris hoszton a Mozilla böngésző angol nyelvű felülete van betöltve. A böngésző helyileg alkalmas a Konfigurálás és adminisztráció lapok szerkesztésére. (A példában a böngészőnek szolgáltatott lapok karakterkészlete a proxyszerver által használttal egyezett meg, vagyis kínai volt; ugyanakkor lehetséges, hogy a lapokat nem sikerül megfelelően megjeleníteni, ha a böngésző és az alapjául szolgáló operációs rendszer nincs megfelelően konfigurálva a proxyszerver által küldött karakterkészlet megjelenítésére.)
Alternatívaként, ha a proxyszerverhez való távoli csatlakozás céljára rendelkezésre áll egy kínai nyelvi támogatással ellátott windowsos munkaállomás, akkor a windowsos munkaállomáson futtatni lehet a Netscape böngésző kínai változatát, és ezt a böngészőt lehet használni a lapokhoz tartozó értékek bevitelére. A második megoldás a rendszergazda számára a konzisztens nyelvi felület fenntartása szempontjából előnyösebb.
Az operációs rendszerek betűkészletének beállítása nagyban befolyásolja a különböző nyelvek böngészőkön belüli megjelenítését, különösen a duplabájtos karakterek esetében. Például az AIX rendszeren beállított, meghatározott kínai betűtípus nem pontosan úgy jelenik meg, mint a Windows platformon beállított kínai betűtípus. Emiatt rendellenességek merülhetnek fel a Konfigurálás és adminisztráció lapjain szereplő HTML szövegek és Java kisalkalmazások megjelenítésekor. A legjobb megjelenítés érdekében csak Windows operációs rendszeren futó böngészők használatát javasoljuk.
Megjegyzés a Mozilla 1.4 böngésző S/390 rendszeren vagy PowerPC-n való használatához
A Mozilla 1.4 böngészővel telepített Java bedolgozót frissíteni kell 1.4.2-es vagy újabb változatra, ellenkező esetben az Adminisztrációs lapok hibásan jelennek meg. A bedolgozó frissítéséhez tegye a következőket:
A Load Balancer online súgójának használatához a böngészőnek a következőket kell támogatnia:
Ha olyan böngészőt használ, amely nem felel meg ezeknek a követelményeknek, akkor lehetséges, hogy az oldalak hibás formázással jelennek meg, valamint a funkcióik hibásan működnek.
Ez a témakör az Edge összetevők a telepítőprogram használatával végzett telepítéséhez nyújt útmutatást.
A Java 2 SDK minden operációs rendszeren automatikusan települ a Load Balancer összetevővel.
A telepítés után a Caching Proxy csomagban található parancsfájlok az alapértelmezett konfigurációt használva megpróbálják elindítani a proxyszervert. Ha a 80-as port már használatban van, például más webszerver használja, a proxyszerver elindítása nem fog sikerülni.
FONTOS: A Caching Proxy az Edge összetevők minden telepítésekor elérhető, kivéve a következőket:
A telepítőprogram segítségével az Edge összetevőket a következő módon telepítheti Windows alapú rendszerre:
Ha az Edge összetevők már telepítve vannak, akkor az Összetevő kiválasztása ablak megnyílása előtt a Karbantartási lehetőségek ablak nyílik meg. Kattintson a Módosítás választógombra, majd kattintson a Tovább gombra. Megnyílik az Összetevő kiválasztása ablak.
Korlátozás: A Tab gombbal a licencszerződés ablakában az Elfogadom és a Nem fogadom el lehetőség között lehet váltani. A Tab gomb nem használható a Vissza, a Tovább és a Mégse navigációs lehetőség elérésére. Áthidaló megoldásként a Shift+Tab kombinációt használhatja ezeknek az elemeknek az elérésére. Emellett az Enter gomb csak a navigációs gombokon működik, tehát az Elfogadom vagy a Nem fogadom el kiválasztására a szóköz gombot kell használnia.
Ha a CD-lemezről végzi a telepítést, akkor az Edge összetevők Linux vagy UNIX rendszerre való telepítésére a következő módon használhatja a telepítőprogramot.
# ./installMegnyílik az üdvözlőablak.
A telepítőprogram megkezdi a kiválasztott Edge összetevők és a szükséges csomagok telepítését.
Korlátozás: A Tab gombbal a licencszerződés ablakában az Elfogadom és a Nem fogadom el lehetőség között lehet váltani. A Tab gomb nem használható a Vissza, a Tovább és a Mégse navigációs lehetőség elérésére. Áthidaló megoldásként a Shift+Tab kombinációt használhatja ezeknek az elemeknek az elérésére. Emellett az Enter gomb csak a navigációs gombokon működik, tehát az Elfogadom vagy a Nem fogadom el kiválasztására a szóköz gombot kell használnia.
Red Hat Linux 3.0 Update 3 rendszeren: Az Edge összetevők telepítőprogramjának futtatásakor a gombok nem működnek, ha lekicsinyíti, majd visszaállítja a grafikus felület panelét. A probléma megoldásához tegye a következőket:
Linux és UNIX rendszereken: Ha az Edge összetevőket a telepítőprogrammal telepíti, akkor az Edge összetevők eltávolításához is a grafikus felület eltávolítóját tudja használni. Ugyanakkor az Edge összetevők grafikus felületű eltávolítója nem használható a beépített parancsok használatával telepített frissítési csomagok eltávolítására. Először a beépített parancsok használatával (az operációs rendszer parancsaival) el kell távolítania a frissítési csomagot, a grafikus felület eltávolítójával csak ezt követően tudja eltávolítani az összetevőket.
A natív parancsok használatáról további információkat az alábbi helyeken talál: A Caching Proxy telepítése a rendszer csomagolóeszközeivel és A Load Balancer telepítése a rendszer csomagolóeszközeivel.
Ez a témakör a Caching Proxy a rendszer csomagolóeszközeivel való telepítéséhez nyújt segítséget.
A telepítés után a Caching Proxy csomagban található parancsfájlok az alapértelmezett konfigurációt használva megpróbálják elindítani a proxyszervert. Ha a 80-as port már használatban van, például más webszerver használja, a proxyszerver elindítása nem fog sikerülni.
FONTOS: A Caching Proxy az Edge összetevők minden telepítésekor elérhető, kivéve a következőket:
Az operációs rendszer csomagtelepítő rendszerét használva, a 2. táblázat részben található sorrend szerint telepítse a csomagokat. A feladat elvégzéséhez szükséges lépéseket a következő eljárás részletezi.
su - root Jelszó: jelszó
cd beillesztési_pont/csomag_könyvtára/
AIX rendszeren:
installp -acXd ./csomagnév
HP-UX rendszeren:
swinstall -s source/ csomagnév
Linux rendszeren:
rpm -i ./csomagnév
Solaris rendszeren:
pkgadd -d ./csomagnév
Összetevő | Telepített csomagok (az ajánlott sorrendben) |
---|---|
Caching Proxy |
|
Edge összetevők dokumentáció |
doc-en_US1 |
Megjegyzések:
|
A dokumentációs csomag csak angol nyelvű. Az Edge összetevő dokumentációjának fordításai az alábbi webhelyen érhetőek el: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
A csomagok eltávolítása:
AIX rendszerről:
installp -u csomagnév
Az összes Caching Proxy csomag eltávolításához a következő parancsot használja:
installp -u wses
HP-UX rendszerről:
swremove csomagnév
A telepített Caching Proxy csomagok listájának lekérdezéséhez a következő parancsot használja:
swlist | grep WSES
A csomagokat a telepítésükhöz képest fordított sorrendben kell eltávolítani.
Linux rendszerről:
rpm -e csomagnév
A telepített Caching Proxy csomagok listájának lekérdezéséhez a következő parancsot használja:
rpm -qa |grep -i wses
A csomagokat a telepítésükhöz képest fordított sorrendben kell eltávolítani.
Solaris rendszerről:
pkgrm csomagnév
A telepített Caching Proxy csomagok listájának lekérdezéséhez a következő parancsot használja:
pkginfo | grep WSES
A csomagokat a telepítésükhöz képest fordított sorrendben kell eltávolítani.
Ez a témakör a Load Balancer AIX, HP-UX, Linux és Solaris rendszerekre való telepítését foglalja össze:
A telepítés típusától függően a fejezetben felsorolt Load Balancer összetevőcsomagok közül nem mindegyik áll rendelkezésre.
A csomagok telepítésének javasolt sorrendje eltérő a Load Balancer for IPv4 and IPv6 telepítések esetében. Fontos megjegyezni, hogy a dispatcher összetevőcsomag után az adminisztrációs összetevőcsomagot kell telepíteni. A Load Balancer for IPv4 and IPv6 csomagok telepítésének javasolt sorrendje a rendszer' eszközökkel: alap, licenc, dispatcher összetevő, adminisztráció, dokumentáció, Metric Server
Ha a Load Balancer egy korábbi változatáról szeretne áttérni, vagy újra szeretné telepíteni az operációs rendszert, akkor a telepítés előtt a Load Balancer bármely korábbi konfigurációs fájlját vagy parancsfájlját elmentheti.
Ha a Load Balancer telepítése után kijelentkezik, akkor a következő bejelentkezésnél az összes Load Balancer szolgáltatást újra kell indítania.
5. táblázat listázza az Load Balancer AIX fájlkészletét és a telepítés javasolt sorrendjét a rendszer csomagtelepítő eszközének segítségével.
Load Balancer összetevők | AIX fájlkészletek |
---|---|
Alap | ibmlb.base.rte |
Adminisztráció (üzenetekkel) |
|
Illesztőprogram | ibmlb.lb.driver |
Licenc | ibmlb.lb.license |
Load Balancer összetevők (üzenetekkel) |
|
Dokumentáció (üzenetekkel) |
|
Metric Server | ibmlb.ms.rte |
A dokumentációs csomag csak angol nyelvű. Az Edge összetevő dokumentációjának fordításai az alábbi webhelyen érhetőek el: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
A Load Balancer AIX rendszerre végzett telepítése előtt győződjön meg a következőkről:
installp -u ibmlb; a korábbi változatok esetében a következő parancsot kell alkalmaznia:
installp -u ibmndHa meghatározott fájlkészleteket szeretne eltávolítani, akkor a csomagnév (ibmlb) megadása helyett sorolja fel a fájlkészleteket.
A termék telepítésekor az alábbiak közül bármely, illetve az összes elem telepítése közül választhat:
Javasoljuk, hogy a Load Balancer AIX rendszerre való telepítésére a SMIT eszközt használja, mert a SMIT képes biztosítani, hogy az összes üzenet automatikusan feltelepítődjön.
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Csomagok | Parancsok |
---|---|
Alap | installp -acXgd eszköz ibmlb.base.rte |
Adminisztráció (üzenetekkel) | installp -acXgd eszköz ibmlb.admin.rte ibmlb.msg.nyelv.admin |
Illesztőprogram | installp -acXgd eszköz ibmlb.lb.driver |
Licenc | installp -acXgd eszköz ibmlb.lb.license |
A Load Balancer összetevői (üzenetekkel). Tartalma: Dispatcher, CBR, Site Selector, Cisco CSS vezérlő és Nortel Alteon vezérlő összetevő. |
installp -acXgd eszköz ibmlb.összetevő.rte ibmlb.msg.nyelv.lb |
Dokumentáció (üzenetekkel) | installp -acXgd eszköz ibmlb.doc.rte ibmlb.msg.en_US.lb |
Metric Server | installp -acXgd eszköz ibmlb.ms.rte |
installp -ld device parancsot.
Ha CD lemezről telepít, a CD leválasztásához adja ki a következő parancsot:
unmount /cdrom
A következő paranccsal ellenőrizze, hogy termék telepítése megtörtént-e:
lslpp -h | grep ibmlb
Ha a teljes terméket telepítette, a parancs a következőket adja vissza:
ibmlb.base.rte
ibmlb.admin.rte
ibmlb.lb.driver
ibmlb.lb.license
ibmlb.összetevő.rte
ibmlb.doc.rte
ibmlb.ms.rte
ibmlb.msg.nyelv.admin
ibmlb.msg.en_US.doc
ibmlb.msg.nyelv.lb
A Load Balancer telepítési útvonalai a következők:
Ez a fejezet ismerteti, hogy hogyan telepítheti a Load Balancer terméket a termék CD lemezének segítségével HP-UX rendszerre.
Mielőtt elkezdené a telepítést, győződjön meg róla, hogy a szoftver telepítéséhez rendelkezik-e root jogosultsággal.
Ha egy korábbi változat már telepítve van a számítógépre, akkor azt el kell távolítania a jelenlegi változat telepítése előtt. Először győződjön meg róla, hogy a végrehajtót és a szervert egyaránt leállította. Ezt követően a Load Balancer eltávolításáról a következő részben talál részletes információkat: Útmutató a csomagok eltávolításához.
7. táblázat a Load Balancer összetevőhöz listázza a telepítőcsomagok neveit és a javasolt sorrendet, hogy a csomagok telepítését a rendszer csomagtelepítő eszközével végezhesse.
A HP-UX nem támogatja a Portugál brazil (pt_BR) területi beállítást. A HP-UX által támogatott területi beállítások a következők:
A művelet elvégzéséhez a következő lépésekre van szükség.
su - root Jelszó: jelszó
Adja ki a telepítő parancsot
swinstall -s /forrás csomag_neve
; ahol a forrás a csomag helyének abszolút elérési útvonala, a csomag_neve pedig a csomag neve.
Ha például a CD lemez gyökérkönyvtárából telepít, akkor a Load Balancer összetevő alapcsomagját (ibmlb.base) a következő paranccsal telepítheti:
swinstall -s /forrás ibmlb.base
Ha a CD rootjáról telepít, akkor Load Balancer összes csomagjának telepítéséhez adja ki a következő parancsot:
swinstall -s /forrás ibmlb
Az swlist paranccsal listáztassa ki az összes telepített csomagot. Például:
swlist -l fileset ibmlb
A csomagok eltávolításához használja az swremove parancsot. A csomagokat a feltelepítés sorrendjéhez képest fordított sorrendben kell eltávolítani. Például adja ki a következő parancsot:
swremove ibmlbAdott csomag eltávolításához (ilyen például a Cisco CSS vezérlő):
swremove ibmlb.cco
A Load Balancer telepítési útvonalai a következők:
Ez a fejezet a Load Balancer az Edge összetevők CD segítségével Linux rendszerre végzett telepítését tárgyalja.
A Load Balancer telepítése előtt győződjön meg a következőkről:
rpm -e csomagnévAz eltávolítást a csomagok telepítéséhez képes fordított sorrendben végezze el, biztosítva, hogy az adminisztrációs csomagok kerüljenek utolsóként eltávolításra.
A telepítőkészlet egy lblinux-változat.tar. formátumú fájl.
tar -xf lblinux-változat.tarAz eredmény a következő fájlkészlet lesz, .rpm kiterjesztéssel:
Ahol --
A dokumentációs csomag csak angol nyelvű. Az Edge összetevő dokumentációjának fordításai az alábbi webhelyen érhetőek el: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
rpm -i csomag.rpm
Red Hat Linux rendszerek esetében: Egy ismert Red Hat Linux probléma miatt a _db* RPM fájlokat is törölnie kell, vagy hiba fog történni.
Fontos, hogy az egyes összetevőkhöz a szükséges csomagokat a következő listában megadott sorrend szerint telepítse.
rpm -i --nodeps csomag.rpm
rpm -qa | grep ibmlb
Ha a teljes termék telepítve van, a parancs a következő kimenetet adja:
A Load Balancer telepítési útvonalai a következők:
Ha el kell távolítania a csomagokat, akkor az eltávolítást a csomagok telepítéséhez képest fordított sorrendben végezze, biztosítva, hogy az adminisztrációs csomagok kerüljenek utolsóként eltávolításra.
Ez a fejezet a Load Balancer az Edge összetevők CD segítségével Solaris rendszerre végzett telepítését ismerteti.
Mielőtt elkezdené a telepítést, győződjön meg róla, hogy rootként jelentkezett be, és a termék korábbi változata el van távolítva.
Az eltávolításhoz győződjön meg róla, hogy az összes végrehajtó és kiszolgáló le van állítva. Majd az adja ki a következő parancsot:
pkgrm csomagnév
pkgadd -d útvonalnévahol az -d útvonalnév a CD-ROM meghajtó eszközneve vagy az a merevlemezen található könyvtár, ahol a csomag található; például: -d /cdrom/cdrom0/.
Az alábbi a megjelenített csomagok listája és az a javasolt sorrend, amelyben telepíteni kell őket.
A dokumentációs csomag (ibmlbdoc) csak angol nyelvű. Az Edge összetevő dokumentációjának fordításai az alábbi webhelyen érhetőek el: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Ha az összes csomagot telepíteni szeretné, írja be az all parancsot, majd nyomja meg a Return gombot. Ha csak néhány összetevőt szeretne telepíteni, akkor szóközzel vagy vesszővel elválasztva adja meg a telepíteni kívánt csomagok nevét, majd nyomja meg a Return gombot. Előfordulhat, hogy meg kell változtatnia a meglévő könyvtárakra vagy fájlokra vonatkozó engedélyeket. Ekkor csak nyomja meg a Return gombot, vagy adjon igen választ. Az előfeltételek teljesítéséhez szükséges csomagokat külön kell telepítenie (ugyanis a telepítés ábécérend szerint történik, nem az előfeltételnek megfelelő sorrendben). Ha az all parancsot írta be, akkor minden parancssorban elég igen választ adnia, és a telepítés sikeresen befejeződik.
Ha csak a Dispatcher összetevőt szeretné telepíteni a dokumentációval és a Metric Server összetevővel, akkor a következő csomagokat kell telepítenie: ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc és ibmlbms.
pkginfo | grep ibm
A Load Balancer telepítési útvonalai a következők:
Ez a rész egy alapszintű, az Edge összetevőkre épülő bemutatóhálózat felépítésének folyamatát tárgyalja. Az ilyen hálózatokat nem éles környezetben való használatra tervezték. Az első hálózat konfigurálása révén a terméket először használó rendszergazdák számos a hálózat pereméhez kapcsolódó fogalmat ismerhetnek meg. Az egyes összetevők szolgáltatásairól és telepítéséről részletes információkat a Caching Proxy adminisztrációs kézikönyv és a Load Balancer adminisztrációs kézikönyv tartalmaz.
Az eljárás lehetővé teszi bármely az összetevő által támogatott számítógéprendszer bármelyik csomóponton való használatát.
Ez a rész a következő fejezeteket tartalmazza:
Caching Proxy hálózat összeállítása.
Load Balancer hálózat összeállítása.
19. ábra - Egy alapszintű proxyszerver hálózatot mutat be, három hálózati csomóponttal, három számítógéprendszer használatával. A hálózat egy dedikált tartalomhoszthoz csatolja a proxyszervert (IBM HTTP-szerver), amely a 2. szerveren található, és a proxyszerver szolgálja ki a hosztot. Ezt a munkaállomás és az 1. szerver között lévő Internet szemlélteti.
FONTOS: A Caching Proxy az Edge összetevők minden telepítésekor elérhető, kivéve a következőket:
A Caching Proxy hálózat felépítéséhez a következő lépéseket, az alábbi sorrendben kell elvégezni:
A következő számítógéprendszerekre és szoftverösszetevőkre van szükség:
Az alábbiak szerint telepítse és konfigurálja a Caching Proxy összetevőt:
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd
Amikor a rendszer felszólítja, adja meg a htadm programnak a felhasználónevet, a jelszót és a rendszergazda valódi nevét.
Az alábbiak szerint telepítse és konfigurálja a Caching Proxy összetevőt:
cd "Program Files\IBM\edge\cp\server_root\protect" htadm -adduser webadmin.passwd"
Amikor a rendszer felszólítja, adja meg a htadm programnak a felhasználónevet, a jelszót és a rendszergazda valódi nevét.
A munkaállomásról tegye a következőket:
A munkaállomásról tegye a következőket:
20. ábra - Egy alapszintű Load Balancer hálózatot szemléltet, amelyben három helyi munkaállomás található, és a Dispatcher összetevő MAC továbbító módszerével történik a webes forgalom két webszerver közötti kiegyenlítése. A konfigurációhoz hasonlóan végezhető bármely más TCP vagy állapotnélküli UDP alkalmazás forgalmának terheléskiegyenlítése is.
A Load Balancer hálózat kiépítésének lépéseit a következő sorrendben kell végrehajtani:
A következő számítógéprendszerekre és szoftverösszetevőkre van szükség:
Munkaállomás | Név | IP cím |
---|---|---|
1 | szerver1.vallalat.com | 9.67.67.101 |
2 | szerver2.vallalat.com | 9.67.67.102 |
3 | szerver3.vallalat.com | 9.67.67.103 |
Hálózati maszk = 255.255.255.0 |
Név= www.vallalat.com IP=9.67.67.104
A szerver2.vallalat.com és a szerver3.vallalat.com loopback csatolóján adjon hozzá egy álnevet a www.vallalat.com címhez.
ifconfig lo0 alias www.vallalat.com netmask 255.255.255.0
ifconfig lo0:1 www.vallalat.com 127.0.0.1 up
Ezzel a két webszerver munkaállomáson szükséges konfigurációs lépéseket befejezte.
Dispatcher konfigurációját a parancssorból, a konfigurációs varázslóval vagy a grafikus felhasználói felület (GUI) használatával adhatja meg.
Ha a parancssort használja, tegye a következőket:
dscontrol executor start
dscontrol cluster add www.vallalat.com
dscontrol port add www.vallalat.com:80
dscontrol server add www.vallalat.com:80:szerver2.vallalat.com
dscontrol server add www.vallalat.com:80:szerver3.vallalat.com
dscontrol executor configure www.vallalat.com
dscontrol manager start
A Dispatcher a szerverek teljesítménye alapján megkezdi a terheléskiegyenlítést.
dscontrol advisor start http 80
A Dispatcher összetevő biztosítja, hogy az ügyfélkérések ne kerüljenek meghibásodott webszerverhez.
A helyi szervereket tartalmazó alapkonfiguráció ezzel elkészült.
FONTOS: A Load Balancer for IPv4 and IPv6 telepítésével a Dispatcher parancs (dscontrol) szintaxisa megegyezik egy fontos kivétellel. A dscontrol parancsok határolója a kettőspont (:) helyett a @ szimbólum. (A kettősponttól eltérő határoló alkalmazására azért volt szükség, mert az IPv6 esetében a kettőspontot a címsémában használják.)
Példa (a korábbi Dispatcher konfigurációs példa alapján)
dscontrol port add www.vallalat.com@80
dscontrol server add www.vallalat.com@80@szerver2.vallalat.com
dscontrol server add www.vallalat.com@80@szerver3.vallalat.com
Ha Load Balancer for IPv4 and IPv6 telepítést használ, akkor további információkat a WebSphere Application Server Load Balancer adminisztrációs útmutató a Dispatcher Load Balancer for IPv4 and IPv6 rendszerre végzett telepítését tárgyaló fejezetében talál, amely a korlátokat és a beállítási eltéréseket is részletesen tárgyalja.
A konfiguráció varázsló használatakor kövesse az alábbi lépéseket:
dsserver
A varázsló lépésről lépésre haladva segíti Önt a Dispatcher alapszintű konfigurációjának összeállításában. A varázsló kérdéseket tesz fel a hálózatról, és végigvezeti Önt az adott szervercsoport forgalmának terheléskiegyenlítésére alkalmazható Dispatcher fürt létrehozásához szükséges lépéseken.
A konfiguráció varázsló a következő paneleket tartalmazza:
A grafikus felhasználói felület elindításához tegye a következőket:
dsserver