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.
Nagy pénz, nagy szívás: útravaló csúcstámadó IT-soknak Az informatikai vezetősködés sokak álma, de az árnyoldalaival kevesen vannak tisztában.
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.