Első látásra az EBS hivatott megoldani azt a problémát, hogy az Amazon EC2 szerverek nem perzisztens háttértárral rendelkeznek, azaz egy esetleges lefagyáskor elvész a tartalmuk. S3-ra meg macerás mentegetni és visszatölteni.
De nem, nem erre való. Amazon EBS összefoglaló.
Méret: 1 GB - 1 TB. Elég.
Egy EBS diszket bármelyik EC2 példányhoz, akár egyszerre többhöz is fel lehet mountolni azzal a megkötéssel, hogy egy 'availability' zónán belül kell lennie a diszknek és a szervereknek. Ezt legegyszerűbben úgy lehet elképzelni, hogy az Amazon-nak több szerverparkja van, az EC2 szerverek létrehozásakor meghatározhatod, hogy melyikben jöjjön létre és a diszkednek is itt kell lennie. Ez érthető kompromisszum, hiszen ha egy fél USA választja el a lemezt a szervertől, az nem lesz izmos.
Ellenben a teljesítmény így sem túl nagy, erre a diszkre nem fogsz MySQL szervert telepíteni, hiába írtak erről több cikket. Az EBS network attached storage, így a limit a hálókártya (small EC2 példányoknál 250mbit, nagyobbaknál 1gbit) és így eszi a szervered sávszélét is. 70-120 MB/s sebesség érhető el vele, ami nem rossz, de a network attached dolog miatt adatbázis szervernek nem való, az I/O kérések indítása sokkal lassabb egy lokális lemeznél.
Lehet snapshotolni egy parancssal a teljes EBS diszk tartalmát az S3-ra, illetve snapshotból visszaállítani. Szuper feature, de hiába ment az S3-ra, mégsem fogod látni a többi fájlod között... csak az EC2 API-ból érhető el ez a tartalom és csak snapshot készítésére/visszaállítására használható, a fájlok böngészése csak az EBS diszken lehetséges. A snapshot inkrementális, azaz csak a megváltozott tartalmat menti, sokat spórol ezzel.
A snapshot-ok által lefoglalt S3 tárhely nehezen becsülhető, ha egyáltalán. A rendszer blokkokban ment, egy blokkban több fájl/több része lehet. Ha készítesz egy snapshot-ot és utána egy másikat, akkor a közös rész csak egyszer tárolódik. Ez sok helyet takarít meg, csak épp nem tudod kiszámolni a tárhelyigényt.
Snapshot készítésekor szépen elkezdi másolni az adatokat. Éppen ezért ha intenzíven írsz az EBS diszkre nem tudhatod, hogy épp milyen állapotot fog elmenteni. Ilyenkor tehát érdemes megszüntetni minden műveletet és utána elvégezni a snapshot-ot.
Erről nulla gyakorlati infó van, de mivel létezik az S3 snapshot feature, ne legyenek illúzióink. Gyanítom, hogy az EC2 példányok megbízhatósága körül lehet a dolog, azaz egy diszk akár 1-2 hónapig is elfuthat hiba nélkül, de számítani kell a bajra.
Azt mondják, hogy az EBS-en belül van redundancia, egy EBS diszk nem egy igazi HDD-t jelent, hanem több szolgál ki téged egyszerre, tehát egy HDD lehalása nem jelenti az EBS diszked meghibásodását.
Az EC2 oldalán az AFR rátával bűvészkednek és azt mondják, hogy ez tízszer jobb egy sima HDD értékénél, azaz 10-szer kevésbé hibásodik meg. Ez kb. megfelel egy tükrözött RAID-nek.
Na ezt a részét a büdös életben nem fogod megbecsülni. Már az EC2 tervezése is szopó, nade az EBS!
A tárhely ára 0.1 USD/GB, ez tiszta. És olcsóbb, mint az S3 (0.15/0.18), bár nem annyira megbízható és nagyteljesítményű, meg úgy egyáltalán, más célt szolgál.
Az EBS snapshotok készítése megegyezik az S3 árakkal, csak amint említettem nem fogod tudni, hogy egy snapshot mennyi helyet igényel.
Ezt az Amazon szolgáltatást se úgy fogd fel, mint sima hosting-ot. Az Amazon cuccokkal jó kis megbízható, skálázódó rendszereket lehet készíteni, de nem arra valók, hogy meglévő dolgokat egy-az-egyben feltegyél.
Kifejezetten Amazon-ra készített rendszerekkel érdemes használni, ez inkább egy fejlesztői platform, mintsem hosting szolgáltatás. Innentől fogva viszont megváltozik a leányzó fekvése és más szemmel tekintesz majd a képességeire.
iMect means internet, media and other cool things. iMect is a small company in Budapest, Hungary. We’ve a big footer on every page where you can discover what we do and what happens with us.
Az iMect jelentése: internet, média és egyéb király dolgok. Egy kis budapesti cég vagyunk. Minden oldalon van egy nagy lábléc, ahol felfedezheted, hogy mivel foglalkozunk.