Windows Azure lépésről lépésre, 3. fejezet – interjú és részlet

A tervek szerint március 12-én megjelenik a „Windows Azure lépésről lépésre”, az első magyar nyelvű szakkönyv a Microsoft felhőplatformjáról. Mostantól kezdve egészen a megjelenés napjáig minden munkanapon foglalkozunk a könyvvel: rövid interjúkat készítünk az egyes fejezetek szerzőivel, és egy-egy részletet is közzéteszünk a könyvből. Ezúttal Safranka Mátyással beszélgetünk munkájáról, az Azure-ral való kapcsolatáról és a könyvben vállalt szerepéről.

Az előző bejegyzések:

Kérlek, mesélj magadról néhány mondatot, mivel foglalkozol és hol?

2004 óta dolgozom a Microsoftnál mint tanácsadó, a főiskola után egyből itt kezdtem. A pályafutásom során végig a Nagyvállalati Szolgáltatások (MCS) üzletágban dolgoztam, voltam tanácsadó, vezető tanácsadó és jelenleg az adatközpont és rendszerfelügyelet területért felelős architekt vagyok.

Mi a kapcsolatod a Windows Azure-ral?

Én az infrastruktúra terület irányából közelítem az Azure platformot, így a Microsoft adatközpont megoldásai és a GFS-el való ismerkedés kapcsán kerültünk először kapcsolatba. Ebből kifolyólag az Azure adatközpontok felépítése, felügyelete, illetve az Infrastructure-as-a-Service szolgáltatás virtuális gépei állnak az érdeklődésem középpontjában.

Mivel ismerteti meg az általad írt fejezet az olvasót?

Én két fejezettel járultam hozzá a könyvhöz, amelyek közül az egyik – az előzőek alapján nem meglepő módon – az Azure és az adatközpontok felépítésével foglalkozik. Kedvenc sorozatom, a Katasztrófák nyomában mintájára leírom a Windows Azure egyetlen komolyabb, a 2012-es év szökőnapján bekövetkezett kimaradásának történetét is.

Milyen újdonságokat látsz a saját területeden?

Az Azure IaaS szolgáltatás elérhetővé válásával a Microsoft jelenleg is elérhető teljes körű IaaS privát felhőmegoldása (amely a Windows Server 2012 és a System Center 2012 termékeken alapul) végre kiegészül a nyilvános felhő alapú IaaS-sel. Nagyvállalati ügyfeleink számára ez kinyitja a publikus és a hibrid felhőmegoldások lehetőségét. Ez egy nagyon érdekes és izgalmas terület lesz, mivel a Microsoft teljes körű megoldásai révén a vállalati rendszergazdák ugyanazokat a System Center felügyeleti eszközöket használhatják a helyi és a felhőerőforrások felügyeletére.

Részlet a 3. fejezetből:

Fabric Controller

Egy adatközpontban a kiszolgálók nagyjából ezres csoportokba vannak szervezve, amelyeket fürtnek (cluster) nevez az Azure üzemeltetési terminológia. Ezek nem keverendők össze a Windows Serverekben elérhető fürtökkel, mert bár a név ugyanaz, más fogalmat takar. Tehát ha egy adatközpontban 30 000 kiszolgáló van, akkor abban nagyjából 30 fürt van. Az Azure három típusú fürtöt különböztet meg:

  • Windows Azure Compute cluster – számítási kapacitás fürt
  • Windows Azure Storage cluster – társzolgáltatás fürt
  • Windows Azure SQL cluster – SQL adatbázis fürt

Ez három különböző hardver kialakítás, mindegyik más használati célra optimalizált kiszolgáló-konfigurációt jelent. Ezek felügyeletét és menedzselését azonban a típustól függetlenül egységesen a fabric controller (FC) látja el. A 3-5 ábrán látható egy összehasonlítás, amely bemutatja, hogy a felhőszolgáltatások világának komponensei hogyan feleltethetők meg az egykiszolgálós világnak.

safranka3-5

3-5 ábra: A felhő és egy számítógép felépítése

Az FC látja el az adatközpontok erőforrás-kezelését, mint ahogy az adott számítógép erőforrásainak kezelését a Windows kernel (az operációs rendszer) teszi. Az FC feladatai közé tartozik olyan feladatok ellátása, mint:

  • a hardverek provizionálása, vagyis az újonnan beüzemelt hardverek bevonása a fürtbe, vagy új fürtök létrehozása
  • a hálózat konfigurálása
  • a futtatott szolgáltatások, virtuális gépek provizionálása és kezelése
  • a komponensek egészségi állapotának figyelemmel kísérése.

Az ezres gépcsoportokból álló határok kialakítására azért van szükség, mert a felhő szolgáltatások nyújtásánál alapfilozófia, hogy bármi, bármikor elromolhat, és ha ez bekövetkezik, akkor minimalizálni akarjuk ennek a szolgáltatásra tett hatását, és legfőképpen elkerülni a tömeges vagy globális leállást. Ebben segít, ha az adatközpontot nem egyetlen nagy egészként, hanem több részre osztott egységként kezeljük, vagyis gyakorlatilag particionáljuk az adatközpontunkat. Ezzel meggátoljuk, hogy egy hiba az egész adatközpontra hatással legyen, vagy tovább terjedjen – hiszen az FC-ben vagy annak üzemeltetésében is lehet hiba –, illetve egy fürt kiesése egyszerűbbé teszi a hibakeresést is.

Egy ezer gépből álló fürtöt felügyelő FC fizikailag általában 5-7 tagból álló fürtben kerül megvalósításra a rendelkezésre állás biztosítása végett. Azért az öt az ideális választás, mert a többségi quorum elv alkalmazása miatt mindenképpen páratlan számú kiszolgáló kell. Ennek alapján a fürtöt felügyelő FC-k közül kiválasztásra kerül egy adott algoritmus szerint az aktuális master, akinek többségi szavazatra van szüksége ahhoz, hogy irányítóként működjön. Ez azt jelenti, hogy az FC fürtöt alkotó kiszolgálók számának 50%+1 szavazatára van szükség a kiválasztott master elfogadásához. Egy példán keresztül talán egyszerűbb megérteni:

Egy három tagból álló fürt tagjai között megszakad a kommunikáció: az egyik oldalon egy kiszolgáló (nevezzük „A”-nak), a másik oldalon két kiszolgáló (nevezzük őket „B”-nek és „C”-nek) reked. A hálózati kommunikáció elvesztésének pillanatában mindegyik kiszolgáló újraszámolja, hogy az algoritmus alapján ki a master. Tegyük fel, hogy az jön ki, hogy az „A”! Ahhoz, hogy az „A” valóban átvegye az irányítást, 50%+1 szavazatra van szüksége, tehát három tag esetén fel kell, hogy tudja venni a kapcsolatot még egy kiszolgálóval, aki szintén megerősíti, hogy jelenleg az „A” kiszolgáló a master. Nyilván ez nem történik meg, hiszen abból a feltételezésből indultunk ki, hogy az „A” elvesztette a kapcsolatot a másik kettő kiszolgálóval, tehát bár az algoritmus szerint az „A”-nak kellene a master szerepet felvennie, ezt nem teszi meg, mivel nem kapja meg a szükséges szavazatot. A „B” és „C” is kiszámolja, hogy „A”-nak kellene a masternek lennie, azonban mivel nem érik el az „A”-t, ezért újraszámolják. Ennek alapján az jön ki, hogy a „C” kiszolgálónak kell lennie a master-nek. Mivel a „B” és a „C” is erre az eredményre jut (az azonos algoritmus használatából eredően), és mivel nincs kapcsolat az első választott „A” felé”, ezért a „B” megadja a szükséges plusz egy szavazatot a „C” kiszolgálónak, aki ezzel felveszi az új master szerepét. Ez a többségi quorum elv. Az Azure FC-k esetében egy FC fürt nem három, hanem öt tagból áll. Vajon miért? Ha csak három lenne a fürtben, akkor egy upgrade vagy karbantartás során leállított FC kiszolgáló mellett kettő működő maradna. Ha ebből a kettőből egy meghibásodik, akkor a fürt teljes vezérlése és emiatt a teljes fürt is leáll. Az öt esetében a frissítés és karbantartás céljára leállított egy FC kiszolgáló mellett még egy FC kiszolgáló meghibásodása esetén is megvan a továbbműködéshez szükséges többségi szavazat (három az ötből).

Holnap a 4. fejezettel folytatjuk!

14 thoughts on “Windows Azure lépésről lépésre, 3. fejezet – interjú és részlet

  1. Visszajelzés: Windows Azure lépésről lépésre, 5. fejezet – interjú és részlet | Felhők között

  2. Visszajelzés: Windows Azure lépésről lépésre, 6. fejezet – interjú és részlet | Felhők között

  3. Visszajelzés: Windows Azure lépésről lépésre, 7. fejezet – interjú és részlet | Felhők között

  4. Visszajelzés: Windows Azure lépésről lépésre, 8. fejezet – interjú és részlet | Felhők között

  5. Visszajelzés: Windows Azure lépésről lépésre, 9. fejezet – interjú és részlet | Felhők között

  6. Visszajelzés: Windows Azure lépésről lépésre, 10. fejezet – interjú és részlet | Felhők között

  7. Visszajelzés: Windows Azure lépésről lépésre, 11. fejezet – interjú és részlet | Felhők között

  8. Visszajelzés: Windows Azure lépésről lépésre, 12. fejezet – interjú és részlet | Felhők között

  9. Visszajelzés: Windows Azure lépésről lépésre, 13. fejezet – interjú és részlet | Felhők között

  10. Visszajelzés: Windows Azure lépésről lépésre, 14. fejezet – interjú és részlet | Felhők között

  11. Visszajelzés: Windows Azure lépésről lépésre, 15. fejezet – interjú és részlet | Felhők között

  12. Visszajelzés: Windows Azure lépésről lépésre, 16-17. fejezet – interjú és részlet | Felhők között

  13. Visszajelzés: Windows Azure lépésről lépésre, 17. fejezet – interjú és részlet | Felhők között

  14. Visszajelzés: Windows Azure lépésről lépésre, 4. fejezet – interjú és részlet | Felhők között

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s