Mellékleteink: HUP | Gamekapocs
Keres
Ősszel is lesz HWSW free! Alkalmazott AI meetup és agilis fejlesztői meetup a módszertanok dzsungeléből, szeptember 24-25-én.

Ha a dobozos szoftver nem skálázódik...

HWSW, 2013. május 12. 12:22
Ez a cikk több évvel ezelőtt születetett, ezért előfordulhat, hogy a tartalma már elavult.
Frissebb anyagokat találhatsz a keresőnk segítségével:

hirdetés

A Morgan Stanley szervezetének kiemelkedő mérete és különleges igényei miatt sokszor fejleszt egyedi megoldásokat. A virtuális gépeket központi vezérlőrendszert pedig itthon, Budapesten fejleszti a befektetési bank.

A Morgan Stanley sokkal inkább befektetési bankként, mintsem tech-cégként él a köztudatban, habár a vállalat hatalmas, jelentős részben önálló fejlesztéseken alapuló IT infrastruktúrát működtet. Az informatikai rendszerek nem pusztán “szükséges költségtényezőnek” számítanak, hanem a cég valódi versenyelőny megszerzését célozza meg velük. Cikksorozatunkban olyan területeket mutatunk be, ahol a vállalat IT szakemberei, köztük a budapesti csapat tagjai közvetlenül hozzájárulnak a Morgan Stanley sikereihez.

Fejlessz vagy vásárolj?

Ahogy azt a korábbi cikkben is említettük, a Morgan Stanley munkatársai minden összetettebb technológiai probléma kapcsán először kiértékelik a dobozos szoftver közvetlen felhasználásának, a nyílt forráskód integrálásának és továbbfejlesztésének, illetve a teljesen egyedi fejlesztésnek az előre látható előnyeit és hátrányait. A felmérésben döntő szerepet játszanak a különböző lehetséges megoldások bekerülési és karbantartási költségei, a befektetési bank további belső rendszereihez történő adoptálhatóság nehézségei, illetve (az infrastruktúrában különösen jellemző módon) a méretekből fakadó kihívások.

Ugyanez a kérdés merült fel a virtualizáció kapcsán is. A banki infrastruktúrában több tízezer virtuális gép működik, azonban a legtöbb üzemeltető szoftver csak néhány ezerig skálázódik megbízhatóan. Ez komoly kihívást jelent, több praktikus szempontból is:

  • egy adott virtuális gép állapotának szabályozása (lekérdezések, elindítás/leállítás, egyéb karbantartási tevékenységek) tisztán dobozos megoldásokkal több tíz kliensprogramban történő egyidejű, kézi kereséssel járna,
  • szinkronizációs pont nélkül a különböző operátorok munkája nehézkesen lenne koordinálható,
  • rengeteg konfigurációs feladat (például az egységes jogosultságkezelés) sok-sok kézi vesződséget, és ezzel együtt számtalan hibalehetőséget hordozna magában,
  • nehéz, vagy bizonyos feltételek mellett lehetetlen volna központi autentikációt, hitelesítést, és audit naplót megvalósítani.

A teljesen saját megoldás nulláról történő fejlesztése is felmerült. Ezzel viszont együtt járna az is, hogy a szóban forgó szoftverek elfogadhatóan működő képességeit részben újraimplementálják. Jelesül a nagy hypervisor szállítók adnak megoldást a klaszteren belüli terheléselosztásra, amely a fizikai erőforrások kihasználtságának és az ezekre irányuló igények függvényében élőben képes újrarendezni a terhelést jelentő virtuális gépeket. További, jellemzően jól működő funkció a vállalati szintű HA (high availability), amely egy fizikai szerver kiesése esetén a korábban ott futó VM-eket egy új hypervisor-on indítja el. Ezeknek a képességeknek az újraimplementálása nem szükségszerű és hosszabb távon a karbantartás költségeit érezhető szinten növelné.

Külső szoftver karmestere

A választott megoldás egy magasan skálázódó platform tervezése, önálló kivitelezése és integrációja volt az elérhető üzemeltető szoftverrel. Ez a platform egységes belépési pontot ad a virtualizált infrastruktúrához, így leveszi az operátorok válláról azt a terhet, hogy annak egyes partícióit függetlenül kezeljék. Központi autentikációt, hitelesítést és audit naplót biztosít minden operátori tevékenységhez.

A platform feladata sokrétű. Folyamatosan követi és leltározza az összes virtuális gépet (mely hardveren, mennyi ideig futott, mikor indult el, mikor állt le), és azok kapcsolódó komponenseit (hosztokat és klasztereket). Minden komponens részére küldött parancs naplózásra kerül, így tetszőleges audit szükségessége esetén nem kell több tucat logot átfésülni a problémák után, elegendő a központi naplót átnézni.

A folyamatos, élő leltár azért is hasznos, mert így az üzemeltető mindig pontosan tudja, hogy egy-egy virtuális gép hol fut éppen, és mi az állapota. Ehhez a sok adminisztrációs felület egyenként történő elemzése értelemszerűen nem járható út. A saját megoldásban ezzel szemben egy jól paraméterezett lekérdezéssel komplex szűrési feltételeknek megfelelő lista kérhető a VM-ekről, illetve ugyanígy parancs is kiadható ugyanezen virtuális gépeknek – a platform gondoskodik a hozzájuk tartozó üzemeltető szoftvereknek történő továbbításról.

Az alkalmazás egy része Erlangban készült, a nyelv és a futtatókörnyezet kiváló konkurrencia-modelljének előnyeiből kiindulva. Más részek, így az adatgyűjtő és a parancstovábbító rész Perlben íródott. A fejlesztés során elkészült egy dinamikus jogosultságkezelő modul is, amely csak a felhasználó privilégiumainak megfelelő parancsokat és lekérdezéseket engedélyezi. Az egyes üzemeltetők csak azokhoz a VM-ekhez férnek hozzá, amelyek saját felelősségi körükbe tartoznak – például a Windows-rendszermérnökök csak a Windows VM-eket látják, a linuxos csapat pedig értelemszerűen csak a Linuxokat.

Agilis fejlesztés

Befektetési bankhoz képest viszonylag szokatlan módon, mindössze két hetes kiadási ciklusokkal fejlődik a rendszer. A sűrű release-ütem fontos előnye, hogy fenntartható egy folyamatos párbeszéd a fejlesztők és az üzemeltetők között. A kért funkciók gyorsan bekerülnek az éles rendszerbe, a visszajelzések alapján pedig meglepően rövid időn belül lehet javítani az esetleges hiányosságokat.

A belső „ügyfelek” és a fejlesztők szoros munkakapcsolatának köszönhetően a visszajelzések közvetlenül, informálisan is működnek. Egyes esetekben a fejlesztő szó szerint odaül az operátor mellé és megfigyeli, hogy hogyan használja az alkalmazást – mely parancsok esnek kézre, melyeket könnyű elgépelni, hol lassú az alkalmazás, van-e probléma a többszálúsítással.

A fejlesztés munkamenete is a gyors kiadási ütem kiszolgálását segíti elő. Nincs szigorú termékmenedzsment, a kisszámú felhasználó és a vezető fejlesztő között a kommunikáció közvetlen és hatékony. Befektetési bankról lévén szó az első az üzembiztonság, ezért elengedhetetlen a helyes változtatás kezelés. Minden forráskód Git alatt van, a változtatások átnézését a Gerrit webes alkalmazás segíti, amellyel egyszerűen követhetőek az előző kiadás és a kiadásra váró kód különbségei, így a jóváhagyás is gyorsan megszülethet az új verzió élesítésére. Ez egyébként néhány kattintás, a fejlesztő egy symlinket ír át és már éles is az új változat.

További információk a Morgan Stanley-ről: www.morganstanley.hu

[A Morgan Stanley megbízásából készített anyag.]

Facebook

Mit gondolsz? Mondd el!

Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.
A HWSW októberben induló gyakorlatorientált, 10 alkalmas, 30 órás online képzéseire most early bird kedvezménnyel lehet regisztrálni!