Objektumtár felhőszolgáltatásként
Most a tárolási rendszerek egy speciális osztályát vizsgáljuk meg, amely interneten szolgáltatott felhőszolgáltatásként lett kialakítva. A felhőbeli objektumtárak az eddigi felhőtárhelyekkel kapcsolatos értekezések fényében a kulcs-érték tárolók speciális, internetes szolgáltatásként nyújtott típusának tekinthetők.
A tár internetes szolgáltatásként való nyújtásához el kell vonatkoztatni a mögöttes tárolási megoldások adatait, és egy egyszerű, letisztult felületet kell biztosítani, amely használható alkalmazásokban. A felhő előnyeit kihasználók egyre nagyobb mértékben döntenek felhőobjektum-modellek mellett a felhőbeli tároláshoz.
Az objektumalapú tárrendszerek magasabb szinten vonatkoztatják el a meglévő fájlrendszeres módszert. Az objektumalapú tárolási rendszerek általában a meglévő fájlrendszerek rétegeire épülnek. Az ilyen tárrendszerekben nincsenek hierarchiák, egyszintű adatkörnyezetet alkalmaznak.
Egy objektum lehet egy általános tároló, amely bármilyen adattípust tárolhat. Az ilyen tetszőleges adatokhoz nehéz kialakítani a felületet, tárolási szempontból azonban könnyen definiálhatók alapszintű műveletek minden objektumhoz. Ezek a műveletek a létrehozás, az olvasás, a frissítés és a törlés (CRUD), amelyek általában REST vagy SOAP típusú hívásokat használó HTTP vagy más hálózati protokolltípussal elérhető API-val használhatók.
REST
A reprezentáción alapuló állapotátvitel (REST) egy állapot nélküli, ügyfél–kiszolgáló típusú, gyorsítótárazható kommunikációs protokollra alapul, és általában HTTP protokollal valósítható meg. Az állapot nélküli protokoll független műveletként kezeli a kéréseket, az ügyfél és a kiszolgáló közti kommunikációt pedig független kérés- és válaszpárként.
A REST egy hálózatba kötött alkalmazások kialakításához használható architektúratípus, és nem egyetlen protokoll. A REST egy hálózatba között alkalmazás entitásainak kommunikációjához készült kialakítási stratégia. A lényege, hogy a CORBA, WSDL vagy RPC helyett egy egyszerű mechanizmussal kapcsolja össze a hálózat gépeit és valósítsa meg az adatátvitelt. A REST-et használó felületeket RESTful-felületeknek nevezzük.
A RESTful-felületek HTTP-kérésekkel küldenek (létrehozás és/vagy frissítés), olvasnak (lekérdezések készítése és adatok beolvasása) és törölnek adatokat. A RESTful-felületek így használhatók CRUD-műveletekhez.
A REST-felületek a következő összetevőkből állnak:
- Egy egységes erőforrás-azonosító (URI), például egy HTTP URL-cím, amelyen keresztül a szolgáltatás elérhető.
- Egy internetes médiatípus a szolgáltatás által támogatott adatokhoz (általában XML vagy JSON).
- A webszolgáltatás által HTTP-metódusokkal támogatott műveletek (GET, PUT, POST és DELETE).
- Egy HTTP-alapú API.
Egy szolgáltatást egy RESTful-felülettel összekapcsoló program így szabványos HTTP GET, PUT, POST és DELETE kéréseket használhat. A REST-kérésekre hamarosan néhány példát is adunk.
A REST legfőbb előnyei:
- Egy platformfüggetlen megközelítés, amely ideális internetes környezethez.
- Egy nyelvtől független felület, hiszen az utasítások HTTP-n keresztül történnek, így például egy C#-ügyfél is kommunikálhat egy Python-kiszolgálóval.
- Szabványalapú kommunikáció, mivel HTTP-re alapul.
- Tűzfalak mellett is működik, amíg a HTTP- és HTTPS-forgalom nincs szűrve.
A REST felhőben tárolt adatok elérésére és kezelésére való használatával kapcsolatos további információkért lásd a RESTful webes API-tervezését.
Objektumtároló rendszerek
Az Azure Blob Storage egy példa a felhőbeli objektumalapú tárolásra. A Blob Storage segítségével a felhasználók objektumokat tárolhatnak tárolókban. Minden objektum létrehozható, olvasható és törölhető. Bár nem rendelkezik natív objektumfrissítési metódussal, a teljes Blob Storage-modellben törölhető és újra létrehozható egy teljes objektum a fájlok felülírásához hasonló módon.
Íme egy példa egy RESTful HTTP-hívásra, amely meghívja az Azure Blob Storage-ot, hogy hozzon létre egy mycontainer nevű tárolót. A HTTP-hívás tartalmazza az engedélyezési adatokat, amelyekkel az ügyfél hozzáférhet a gyűjtőhöz.
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container HTTP/1.1
Request Headers:
x-ms-version: 2011-08-18
x-ms-date: Sun, 25 Sep 2011 22:50:32 GMT
x-ms-meta-Name: StorageSample
Authorization: SharedKey myaccount:Z5043vY9MesKNh0PNtksNc9nbXSSqGHueE00JdjidOQ=
A Blob Storage feldolgozhatja a kérést, és az alábbi példához hasonló HTTP-választ küld vissza:
Response Status:
HTTP/1.1 201 Created
Response Headers:
Transfer-Encoding: chunked
Date: Sun, 25 Sep 2011 23:00:12 GMT
ETag: "0x8CB14C3E29B7E82"
Last-Modified: Sun, 25 Sep 2011 23:00:06 GMT
x-ms-version: 2011-08-18
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
A válaszban az Azure elismerte a kérést, egy „201 Created” üzenettel jelezve, hogy az sikeres volt, majd visszaküldte a kéréshez kapcsolódó adatokat.
A REST Azure Blob Storage-tal való használatáról további információt a Blob Storage REST API-jával kapcsolatban talál.
Felhőalapú objektumtárolási szabványok: CDMI
A felhőbeli objektumtárolók jelentős hátránya, hogy nem rendelkeznek közös objektumtárolási szabvánnyal.
A Storage Networking Industry Association (SNIA) egy nyílt szabványt próbál népszerűsíteni a felhőobjektumokhoz: ez a Cloud Data Management Interface (CDMI).
22. ábra: CDMI
A CDMI felcímkézett metaadatokkal (kulcs-érték párokkal) definiál adatobjektumokat és adattárolókat, és RESTful-felületeket használ, amelyekben JSON az adatcsere-formátum. A CDMI egy felhőtároló adatainak eléréséhez és kezeléséhez használható (22. ábra). A 23. bemutatja a felhőtárolóval való CDMI-s ügyfél-kommunikációt.
23. ábra: CDMI-ügyfél, amely egy CDMI-tárolófelhővel kommunikál
A CDMI-ügyfél HTTPS-en keresztül küldhet kérelmeket. A MimeType azt a CDMI-erőforrástípust jelzi, amelyet az ügyfél használ (objektum vagy tároló), majd szabványos HTTP-állapotkódokat küld vissza, amelyek a kérés állapotát jelzik.
A 24. ábra bemutatja a CDMI-modellt. A CDMI-erőforrások a gyökérhelyen találhatók, amelyet a gyökér URI-ja jelez: https://<offering>. A példában két tároló (A és B) látható, amelyek egy-egy objektumot tartalmaznak. Minden CDMI-entitás támogatja a metaadatokat. Ezt az entitásokhoz társított kulcs-érték címkék jelzik.
24. ábra: A CDMI-adatmodell
A CDMI emellett a következő erőforrástípusokat is támogatja:
- cdmi-capabilitiy: Egy speciális entitás, amely leírja az adott felhőtár képességeit. Ez az entitás fontos, és a felhő képességeinek felderítésére használható (például biztonsági mentés és replikáció).
- cdmi-domain: Lehetővé teszi tartományok létrehozását (például objektumhozzáférési engedélyekkel rendelkező felhasználók csoportjait).
- cdmi-queue: Lehetővé teszi olyan objektumok üzenetsorainak létrehozását, amelyek elsőként kifelé (FIFO) sorrendben működnek. Az alkalmazások ilyen várólistákkal implementálhatják az értesítési vagy üzenetkezelési rendszereket.
A CDMI a következő előnyöket kínálja:
- A szállítófüggetlen felhőobjektum-tárolási rendszere egyszerűbb adatmigrálást tesz lehetővé a felhők között.
- Lehetővé teszi a tárolók felhőbeli társhálózat-létesítését, ami azt jelenti, hogy a különböző felhőktől származó erőforrások összekapcsolhatók a zökkenőmentes adatmegosztás érdekében.
- Megfelel a meglévő szabványoknak, például az adatelérési RESTful-felületeknek, és több mögöttes tárabsztrakcióval is együttműködhet, például megosztott és hálózati fájlrendszerekkel.
- Ez egy érett szabvány, amely referenciaimplementációval és ISO-szabványosítással is rendelkezik.
A CDMI hátránya, hogy még nem vezették be széles körben. A CDMI szabványt számos tárolási cég támogatja, azonban a legtöbb szállító hivatalosan még nem támogatja, a szabvány eddigi sikere pedig nem egyértelmű.