Felhőbeli kihívások: Heterogenitás

  • 9 perc

A felhő-adatközpontok többféle összetevő, köztük számítógépek, hálózatok, operációs rendszerek, kódtárak és programozási nyelvek összességei. Elméletileg, ha az adatközpont összetevő változatosak és különbözőek, akkor a felhőt heterogén felhőnek nevezik. Ellenkező esetben a felhő homogén felhőnek számít. A gyakorlatban a homogenitás nem mindig áll fenn, elsősorban két okból:

  • A felhőszolgáltatók általában az informatikai erőforrások több, különböző időszakokban beszerzett generációját tartják fenn.
  • A felhőszolgáltatók egyre több virtuális technológiát alkalmaznak a felhőikben a kiszolgálók konszolidálása, a rendszer kihasználtságának javítása és a felügyelet egyszerűsítése érdekében. A nyilvános felhők többnyire virtualizált adatközpontok. Várhatóan a magánfelhőkben is a virtualizált környezetek válnak a megszokottá.1

A heterogenitás a virtualizált környezetek közvetlen velejárója, és több virtuális gép hasonló fizikai gépeken való közös elhelyezése is okozhatja. Képzeljünk el például két egyforma, A és B fizikai gépet. Ha az A gépen egy, a B gépen pedig 10 virtuális gépet helyeznek el, akkor a második számítógép terhelése akkor is nagyobb lesz az elsőénél, ha egyforma virtuális gépeken fut ugyanaz a program. A különböző virtuális gépek és a nagy erőforrásigényű programok használata még valószínűbb a felhőben, és a helyzet ott még ennél is rosszabb. Különösen meggyőző környezet lehet az Azure, amelyben több mint 30 virtuálisgép-típus5 érhető el több millió, különböző programokat használó felhasználó számára. Ez a helyzet nyilván még nagyobb heterogenitást okoz. Röviden, a felhőben a heterogenitás a norma, és az is marad.

A heterogenitás többszörösen is probléma az elosztott programok felhőbeli futtatása szempontjából. Az elosztott programokat úgy kell megtervezni, hogy elfedjék a mögöttes hardverek, hálózatok, operációs rendszerek és programozási nyelvek heterogenitását. Az elosztott tevékenységek a homogenitás illúziójának köszönhetően képesek kommunikálni, enélkül az üzenetátadás és az elosztott programok egész koncepciója kudarcra lenne ítélve. Elég az adatok ábrázolásának problémájára gondolni: a tevékenységek által váltott üzenetek általában primitív adattípusokat, például egész számokat tartalmaznak. Sajnos nem minden számítógép tárolja egyformán az egész számokat. Arról van szó, hogy egyes számítógépek a csökkenő helyiértékű (big-endian) sorrendet használják, amelyben a legnagyobb helyiértékű bit áll az első helyen, mások a növekvő helyiértékűt (little-endian), amelyben a legértékesebb áll leghátul. A lebegőpontos számok is mások lehetnek a különböző számítógép-architektúrákban. Újabb problémát jelent a karaktereket ábrázoló kódok halmaza. Egyes rendszerek ASCII-karaktereket használnak, mások a Unicode szabványt. Egyszóval, az elosztott programoknak el kell simítaniuk a heterogenitást, hogy létezni tudjanak. Az elosztott programokba beépíthető, a heterogenitás elsimítására szolgáló rész elterjedt megnevezése a köztes szoftver (middleware). A köztes szoftverek többsége szerencsére az internetes protokollokkal van implementálva, amelyek maguk is elfedik a mögöttes hálózat különbségeit. Köztes szoftverre példa a Simple Object Access Protocol (SOAP)2. A SOAP egy sémát definiál egy önleíró szöveges formátum, a kiterjeszthető jelölőnyelv (Extensible Markup Language, XML) használatára, amellyel az üzenetek tartalma úgy ábrázolható, hogy a különböző gépeken futó elosztott tevékenységek kommunikálni tudjanak. Egy másik példa a reprezentáción alapuló állapotátvitel (Representational State Transfer), röviden REST.

Általánosságban az egyik gép számára megfelelő kód nem feltétlenül felel meg egy másik felhőbeli gépnek, különösen akkor, ha a gépek utasításkészlet-architektúrája (ISA) is különbözik. Ironikusnak tűnhet, hogy a heterogenitást előidéző virtualizációs technológia hatékonyan felhasználható a probléma megoldásában. Egyes virtuális gépek egy felhasználói fürthöz inicializálva leképezhetők az eltérő mögöttes utasításkészlet-architektúrájú fizikai gépekre. Ettől kezdve a virtualizáció hipervizora gondoskodik a kiépített virtuális gépek ISA-i és a mögöttes fizikai gépek (esetleges) eltéréseinek emulálásáról. Minden emuláció a felhasználó szemszögéből átlátszóan történik. Végső soron a felhasználók mindig a saját operációs rendszereiket és kódtáraikat telepíthetik a rendszer olyan virtuális gépeire, így biztosítva a homogenitást az operációs rendszer és a kódtárak szintjén.

Az elosztott programok készítőinek figyelmét igénylő másik súlyos heterogenitási probléma a felhőben a változó teljesítmény3, 4. A változó teljesítmény azt jelenti, hogy ugyanazt az elosztott programot kétszer lefuttatva ugyanazon a fürtön a végrehajtási idők eltérhetnek. A végrehajtási idők aránya akár ötszörös is lehet egyazon alkalmazás esetében, ugyanazon a privát fürtön.4 A változó teljesítmény oka többnyire a felhőnek a virtuális környezetek következtében kialakuló heterogenitása, valamint az erőforrások iránti igény időbeli növekedése és csökkenése. Ennek következtében a felhőbeli virtuális gépek ritkán végzik ugyanakkora sebességgel a munkát, ezzel megakadályozva, hogy a tevékenységek (közel) állandó ütemben haladjanak. Ez a helyzet nyilván nehezen kezelhető terhelési egyenetlenségeket hozhat létre és rontja az összteljesítményt, mivel a programok teljesítménye nem egyenletes terhelés esetén a leglassabb tevékenységen múlik. Az elosztott programok megkísérelhetik azzal enyhíteni a problémát, hogy észlelik a lassú tevékenységeket, a megfelelő munkaigényes tevékenységeket pedig gyors virtuális gépekre ütemezik, hogy azok korábban fejeződjenek be. Konkrétabban két azonos munkát végző tevékenység is futhat két különböző virtuális gépen, és amelyik először befejeződik, az véglegesítve lesz, a másik pedig meg lesz szakítva. A Hadoop MapReduce hasonló stratégiát, az úgynevezett spekulatív végrehajtást alkalmazza ugyanennek a problémának a megoldására. A lassú és a gyors tevékenységeket és virtuális gépeket sajnos nem könnyű megkülönböztetni a felhőben. Megtörténhet, hogy egy adott virtuális gép terhelése a tevékenység futtatásakor ideiglenesen éppen kiugróan magas, de az is lehetséges, hogy a virtuális gép egyszerűen hibás. Elméletileg nem minden lassúnak észlelt csomópont hibás, a hibás és a lassú csomópontokat azonban nehéz megkülönböztetni.6 Ez a probléma okozza, hogy a Hadoop MapReduce heterogén környezetekben nem nyújt jó teljesítményt.5, 7 Ennek okait és a Hadoop spekulatív végrehajtását a Hadoop MapReduce-ról szóló szakasz ismerteti részletesen.


Hivatkozások

  1. M. Zaharia, A. Konwinski, A. Joseph, R. Katz, and I. Stoica (2008). A MapReduce teljesítményének javítása heterogén környezetekben OSDI
  2. G. Coulouris, J. Dollimore, T. Kindberg, and G. Blair (May 2011). Elosztott rendszerek: Fogalmak és tervezési Addison-Wesley
  3. B. Farley, V. Varadarajan, K. Bowers, A. Juels, T. Ristenpart, and M. Swift (2012). További információk a pénzért: A teljesítmény heterogenitásának kihasználása a nyilvános felhőkben SOCC
  4. M. S. Rehman és M. F. Sakr (2010. nov.). A Cloud Computing CloudCom kiépítési változatának kezdeti megállapításai
  5. Linuxos virtuális gépek méretei az Azure-ban
  6. A. S. Tanenbaum és M. V. Steen (2006. október 12.). Elosztott rendszerek: Principles and Paradigms Prentice Hall, Second Edition
  7. T. D. Braun, H. J. Siegel, N. Beck, L. L. Blni, M. Maheswaran, A. I. Reuther, J. P. Robertson, M. D. Theys, B. Yao, D Hensgen és R. F. Freund (2001. június). Tizenegy statikus heurisztika összehasonlítása a független feladatok osztályának heterogén elosztott számítási rendszerekre való leképezéséhez JPDC