Hálózat-virtualizáció EPISODE V - PART I North-bound APIs

Application Programming Interfaces - APIs

API-król az SDx bejegyzések során már röviden beszéltem, de most tegyük nagyító alá a témát, és nézzük meg az egyes API-k működését, hogyan kapcsolódnak az egyes orkesztrációs szintekhez (kontrollerekhez).

Tehát mindenkinek megvan, hogy az SDN architektúra referencia középpontja maga az SDN kontroller. Ez alapján azok az API-k amik a kontrollert alkalmazás oldalról érik el (tipikusan REST-API), észak-irányú API-nak - North-bound - amikkel pedig a kontrollerrel érjük el az infrastruktúrát azokat pedig déli-irányú API-nak - South-bound - szoktuk nevezni.

A fentiek alapján, és felhasználásuk szempontjából megpróbálom leírni ezeket a protokollokat, annyi extra csavarral, hogy bevezetem az integration-API fogalmát, ami bizonyos szempontból észak-irányú API-nak is tekinthető, de szerintem ez inkább külön kategória, mert ez kontroller, vagy kontroller jellegű alkalmazások összekötését teszi lehetővé.

North-bound API

• REST

Ne legyünk REST-ek, kicsit utána gondolni, hogy miért vált népszerűvé a HTTP/HTTPS alapokon működő REST API, ugyanis az internet világában már jól vizsgázott, kipróbált protokollról van szó.
Szóval a RESTful API-t röviden az alábbiakkal jellemezhetjük:

•  Kliens-Szerver alapú a működése, tehát azok az alkalmazások amelyek REST-API támogatnak, futtatnak valamilyen szerver process-t.
• Állapotmentes, tehát kliens-szerver kommunikáció során az összes olyan információt továbbítani kell, ami szükséges a végrehajtásához, nem épül fel session, illetve  nem tárolódik a szerveren állapot, ezek a paraméterek a kliensen tárolódnak.
• Cache-elhető, ami lényegében a felhasznált parancsok és paraméterek újrahasznosítását teszi lehetővé.
• Standardizált megkötött hierarchikus, rétegelt program felépítés, lehetővé teszi az automatizációt.
• Code-on-Demand funkció lehetővé teszi, hogy a kliensek letöltsék a program részeket, és végrehajtsák azt bizonyos script-ek alapján, így előtesztelhetővé teszi a rendszert.

Erőforrás

A legfontosabb eleme a REST-nek az információ absztrakciója erőforrásként, ami alatt azt értjük, hogy minden információ számára erőforrás azonosítót (resource id) tudunk hozzárendelni.
Az erőforrás állapota mint példul az időbélyeg, az erőforrás leírásához tartozik.
Tehát minden tranzakció során, leírást kell adnunk az elérendő erőforrásról, és az erőforráshoz kapcsolódó műveletekről.

Erőforrás metódusok

További fontos elemei a REST-nek az alábbi erőforrás metódusok HTTP:

• POST - Create 
• 201 (Created), 'Location' header with link to /customers/{id} containing new ID.
• 404 (Not Found), 409 (Conflict) if resource already exists..
• GET - Read
• 200 (OK), list of customers. Use pagination, sorting and filtering to navigate big lists.
• 200 (OK), single customer. 
• 404 (Not Found), if ID not found or invalid.
• PUT - Update/Replace
• 200 (OK) or 204 (No Content).
• 404 (Not Found), if ID not found or invalid.
• 405 (Method Not Allowed), unless you want to update/replace every resource in the entire collection.
• DELETE
• 200 (OK). 
• 404 (Not Found), if ID not found or invalid. 
• 405 (Method Not Allowed), unless you want to delete the whole collection—not often desirable. Forrás

REST !=HTTP

Fontos megjegyezni, hogy a REST API != HTTP-vel (nem egyenlő)!

Míg a HTTP kérések esetén nem annyira kötött a metódus meg a formátum, addig a REST esetén, ezek fontos kritériumok. Továbbá a RESTful API architektúrában az adat és funkció kötött erőforrások melyek hozzáférése URI (Uniform Resource Identifiers)-kon keresztül történik. Az erőforrás használatra egyszerű, jól definiált műveletekkel, vagy műveletek sorozatával kerül sor. Az erőforrás elérése a szerverk és kliensek között szabványos protokoll interfészen keresztül történik mint pl: HTTP/HTTPs.

SDN N-API == REST

Az olyan alkalmazások illesztését kell lehetővé tenni a SDN kontrollerhez, melyek a hálózatot dinamikusan szeretnék igénybe venni. Joggal merül fel a kérdés, hogy milyen alkalmazások lehetnek ezek?
Mondok egy példát:
Tételezzük fel, hogy szeretnénk dinamikusan fizikailag kizárni azokat a felhasználókat, akik nem felelnek meg a mi security követelményeinknek, esetleg malware-al fertőzött gépeket szeretnénk tiltani.
Erre jó megoldás lehet az AV (anti virus) szoftver illesztése egy olyan intelligenciához, ami hozzáfér a hálózathoz, a hálózatban fellelhető információkhoz és képes absztrakciót nyújtani a külső AV felé.

Arra a kérdésre, hogy ebben mennyi saját fejlesztést kell belerakni nem lehet egyértelmű egzakt választ adni, ugyanis az alábbiak befolyásolják:

• Hálózati megoldást szállító
• Alkalmazást szállító
• IT/Telekommunikációs rendszert fejlesztő és üzemeltető

cégek, gyártók.

Jól látszik a fentiek és ipari trendek alapján, hogy akármilyen SDN megoldást is szeretnénk készíteni, az északirányú integrációt REST API-al kell valószínűleg megvalósítani, ugyanis a gyártók, de még az opensource group-ok is leginkább ezt implementálják megoldásaikba.

innen folytatjuk...