Szerző: Voith Hunor

2015. augusztus 6. 17:30

Redfish: 25 év után jöhet az IPMI utódja

A DMTF kiadta a távoli szervermenedzsment új iparági standardjának szánt API 1.0-s verzióját. A Redfish a legfontosabb iparági szereplők teljes támogatását élvezi, alapjait a REST, a JSON és az OData adják, feladata a felügyelet és a hardverszintű menedzsment egységesítése lesz.

Leváltaná a mintegy negyed évszázados múltra visszatekintő IPMI (Intelligent Platform Management Interface) távoli szervermenedzsment-specifikációs szettet a legnagyobb iparági szereplőket tömörítő DMTF (Distributed Management Task Force). Az 1992-ben alapított szervezet célja a sokszor számos különböző gyártótól származó és egyedi interfészekkel, vezérlőkkel ellátott gépek együttműködésére, távoli (és alapvetően hardverközeli) menedzsmentjére használható, széles körben elfogadott szabványok, ajánlások kidolgozása.

A szervezet szerint mára nagyon eljárt az idő az IPMI felett, ami a legkisebb közös többszörös elvét követve egy meglehetősen leszűkített parancskészletet támogat, emiatt aztán az évek során a gyártók amellett, hogy az említett legkisebb közös többszörösként megtartották az IPMI-támogatást, egyre inkább a saját fejlesztésű, szállítóspecifikus menedzsmenteszközök felé mozdultak el (pl. Dell iDRAC, HP iLO) a szervere alacsony szintű beállításait illetően.

Mindent vivő munkahelyek

Mindig voltak olyan informatikai munkahelyek, melyek nagyon jól fekszenek az önéletrajzban.

Mindent vivő munkahelyek Mindig voltak olyan informatikai munkahelyek, melyek nagyon jól fekszenek az önéletrajzban.

A horizontális skálázási (scale-out, azaz egyre több szerver hozzáadása, nem pedig egy-egy node erőforrásainak növelése) szemlélet, az általános célú (és szépen lassan nyílt alapokra költöző) szerverek tömeges használata, a beszállító-függőség csökkentésére való törekvés azonban egyre inkább heterogén szerverparkokat eredményez, melyek egységesen végezhető, távoli menedzsmentje sok borsot tör az üzemeltetők orra alá.

A most bemutatott Redfish API legnagyobb vívmánya, hogy létrehozói modern, széles körben elfogadott és alkalmazott technológiákat – REST, JSON, OData – gyúrtak egy csomagba azért, hogy az interoperabilitást és a konzisztenciát egyaránt magas szintre emelhessék. A REST architektúratípus megkötéseinek (például egységes kliens-szerver interfész, állapotmentesség, a válaszok gyorsítótárazhatósága) megfelelő (azaz RESTful) alkalmazások fejlesztése az elmúlt pár évben látványosan megnőtt – ennek lényege, hogy ezek a lehető leginkább kihasználják egy adott hálózati protokoll már definiált funkcióit anélkül, hogy azt saját, szállítóspecifikus kiegészítésekkel (jellemzően SOAP alapokon) bővítenék. A HP például tavaly adta ki RESTful API-ját, de mivel a vállalat a DMTF oszlopos tagja is egyben, az idő előrehaladtával várhatóan folyamatosan átáll majd az új iparági szabványnak szánt API-ra.

A Redfish erőforrás-sémája

Szintén fontos momentum, hogy a szervermenedzsment-rendszerek esetében népszerű XML adatformátumot a Redfish a szintén nyelvfüggetlen, de tömörebb és az adminisztrátorok által könnyebben olvasható JSON-ra cseréli. Ezt a két építőkockát azonban valahogy össze is kell kötni, hiszen attól, hogy egyes szoftverarchitektúrák teljesítik a REST követelményeket, a megvalósítás terén már különbözhetnek (például az eredmény-reprezentációban vagy az elérhető lekérések számában). A JSON formátumban tárolt adatoknál szintén kell valami összekötő megoldás – attól, hogy a szintaxis adott, az adattömbön belül használt szemantika beszállítóként változhat.

A Redfish fejlesztését végző szövetség ezért az OData (Open Data Protocol) protokoll mellett döntött, ami nem meglepő, hiszen az OData pont az új menedzsment API sarokköveire (JSON, HTTP, univerzális erőforrás-azonosítók) épít, hogy a REST API-k közötti együttműködést megvalósítsa. A Redfish-en belül a protokollt és a JSON adatmodellt az API fejlesztői egymástól elválasztva kezelik, így az adatmodellt (melynek változtatására valószínűleg gyakrabban merül majd fel igény) a jövőben verzióváltás nélkül is ki lehet egészíteni.

Mivel egy napokban kiadott 1.0-s verzióról van szó, széles körű implementációjára nem a következő hónapokban érdemes számítani. Üzemeltetőknek viszont érdemes lehet minél előbb elkezdeni megismerkedni vele, mert a támogatói háttér miatt szinte biztos, hogy ez lesz a távoli szervermenedzsment következő, általános szabványa.

a címlapról