Virtualizáció és magas rendelkezésre állás – 4

Az előző cikkben az AD-t elemeztük, de persze komolyan senki sem gondolhatja – virtualizáció ide vagy oda – hogy egyetlen kiszolgálóra bízza ezt a szolgáltatást. Most nézzük meg, hogy egy alapvetően más módszert alkalmazó szoftvernél mi a helyzet. Az IIS rendelkezésre állásának növelésére hagyományosan NLB-t alkalmaznak. Az AD mintájára készítsük el újra a táblázatunkat

Kieső komponens IIS – NLB, fizkai IIS – VMware HA-val IIS – Hyper-V clusterrel IIS – VMware FT-vel IIS – NLB-vel és VMware HA-val IIS NLB-vel és Hyper-V clusterrel IIS NLB-vel és FT-vel
Adatbázis                                   
Alkalmazás   x                                         x           x            x
Operációs rendszer   x                                         x           x            x
Szerver hardver   x          x         x         x             x(*)           x(*)           x
SAN kapcsolat   x(*)          x         x         x             x          x           x
SAN tároló   x(*)          x(*)         x(*)        x(*)             x(*)          x(*)           x(*)
Teljes telephely   x(*)          x(*)         x(*)        x(*)             x(*)          x(*)           x(*)

Szinte teljesen azonos táblázatot kaptunk, mint az előző cikkben. Az eredeti táblázatból tudjuk, hogy az NLB nem foglalkozik azzal, hogy az IIS átal szolgáltatott tartalom mennyire jó, ha az IIS fut, akkor az NLB könyörtelen oszt rá felhasználókat, akik hibaüzeneteket kapnak vissza.

Az IIS leállását semelyik virtualizációs technológia sem veszi észre: ha működik az operációs rendszer, de az IIS nem, az a host cluster megoldásokat nem zavarja.. Az NLB elhagyása még akkor is elfelejtendő, ha csak a rendelkezésre állásra ügyelünk és a terheléselosztással nem is számolunk.

Ha visszahozzuk az NLB-t, akkor jobbára visszakapjuk az eredeti, virtualizáció nélküli megoldásunkat, de azért a szerver hardverek kiesésénél nem árt ügyelni a cluster helyes konfigurációjára. Mind a VMware HA esetén, mind pedig a Hyper-V-nél be KELL konfigurálni az anti-affinitás szabályokat, amellyel elérhetjük, hogy a két vagy több VM, amely IIS-t futtat NLB-vel, lehetőleg külön fizikai szerveren fusson, ellenkező esetben egy esetleges szerver meghibásodás mindenképpen leállással jár – a fizikai környezetben ilyen szituáció nem fordulhat elő. A VMware megoldásánál tehát mindenképp Distributed Resource Schedulerre (DRS) van szükség, ez viszont csak a drágább kiadásokban érhető el. Ez pedig súlyos következményekkel jár: egy virtualizált NLB farmnak lehet kisebb a rendelkezésre állása, egy fizikai implementációhoz mérve – Vmware fault-tolerant ide vagy oda. Az én végkövetkeztetésem: az NLB nem váltható ki semmilyen host cluster megoldással, és még együttes alkalmazásuk is odafigyelést igényel.

Folytatjuk…..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: