S3 objektumtárolási parancs lefordított egy cikket arról, hogy milyen szempontok fontosak az objektumtároló kiválasztásánál. A következő a szöveg a szerző szemszögéből.
Amikor az objektumtárolásról van szó, az emberek általában csak egy dologra gondolnak: a TB/GB árra. Természetesen ez a mérőszám fontos, de egyoldalúvá teszi a megközelítést, és egyenlővé teszi az objektumtárolást egy archív tárolóeszközzel. Ráadásul ez a megközelítés csökkenti az objektumtárolás jelentőségét a vállalati technológiai veremben.
Tárgytárolás kiválasztásakor öt jellemzőre kell figyelni:
- teljesítmény;
- méretezhetőség;
- S3 kompatibilis;
- válasz a kudarcokra;
- sértetlenség.
Ez az öt jellemző új mérőszám az objektumok tárolására, valamint a költségekre. Nézzük meg mindegyiket.
termelékenység
A hagyományos tárgytárolók nem teljesítenek. A szolgáltatók folyamatosan feláldozták az alacsony árakra törekedve. A modern tárgytárolásnál azonban más a helyzet.
A különféle tárolórendszerek megközelítik vagy meg is haladják a Hadoop sebességét. Az olvasási és írási sebességgel szemben támasztott modern követelmények: 10 GB/s-tól merevlemezekhez, 35 GB/s-ig NVMe-hez.
Ez az átviteli sebesség elegendő a Spark, Presto, Tensorflow, Teradata, Vertica, Splunk és más modern számítási keretrendszerekhez az analitikai veremben. Az a tény, hogy az MPP-adatbázisokat objektumtárolásra konfigurálják, arra utal, hogy egyre gyakrabban használják elsődleges tárolóként.
Ha a tárolórendszere nem biztosítja a szükséges sebességet, nem használhatja fel az adatokat, és nem nyerhet ki belőle értéket. Még akkor is, ha adatokat kér le az objektumtárolóból egy memórián belüli feldolgozási struktúrába, akkor is szüksége lesz sávszélességre az adatok memóriába és a memóriából történő átviteléhez. Az örökölt tárgytárolóknak nincs elég belőle.
Ez a kulcspont: az új teljesítménymutató az átviteli sebesség, nem a késleltetés. Ez szükséges a nagyarányú adatokhoz, és ez a norma a modern adatinfrastruktúrában.
Bár a benchmarkok jó módszer a teljesítmény meghatározására, nem mérhető pontosan, mielőtt az alkalmazást futtatná a környezetben. Csak utána lehet megmondani, hogy pontosan hol van a szűk keresztmetszet: szoftverben, lemezeken, hálózatban vagy számítástechnikai szinten.
Méretezhetőség
A méretezhetőség az egy névtérbe elférő petabájtok számát jelenti. A gyártók azt állítják, hogy könnyű skálázhatóság, de azt nem, hogy méretezésük során a hatalmas monolit rendszerek törékennyé, bonyolulttá, instabillá és drágává válnak.
A méretezhetőség új mérőszáma a kiszolgálható névterek vagy ügyfelek száma. A mérőszám közvetlenül a hiperskálázókból származik, ahol a tárolási építőelemek kicsik, de több milliárd egységre méretezhetők. Általában ez egy felhő mérőszáma.
Ha az építőelemek kicsik, könnyebben optimalizálhatók a biztonság, a hozzáférés-vezérlés, a házirend-kezelés, az életciklus-kezelés és a nem zavaró frissítések szempontjából. És végül biztosítsa a termelékenységet. Az építőelem mérete a meghibásodási régió irányíthatóságának függvénye, vagyis hogyan épülnek fel a rendkívül rugalmas rendszerek.
A több bérletnek számos jellemzője van. Míg a dimenzió arról beszél, hogy a szervezetek hogyan biztosítanak hozzáférést az adatokhoz és alkalmazásokhoz, magukra az alkalmazásokra és az egymástól való elkülönítésük logikájára is utal.
A többügyfeles megközelítés modern megközelítésének jellemzői:
- Rövid időn belül több százról több millióra nőhet az ügyfelek száma.
- Az ügyfelek teljesen el vannak szigetelve egymástól. Ez lehetővé teszi számukra, hogy ugyanazon szoftver különböző verzióit futtassák, és különböző konfigurációjú, engedélyekkel, funkciókkal, biztonsági és karbantartási szintekkel rendelkező objektumokat tároljanak. Ez akkor szükséges, ha új kiszolgálókra, frissítésekre és földrajzi területekre méretez.
- A tároló rugalmasan méretezhető, az erőforrásokat igény szerint biztosítjuk.
- Minden műveletet egy API vezérel, és emberi beavatkozás nélkül automatizálódik.
- A szoftver konténerekben tárolható, és szabványos hangszerelési rendszereket, például Kuberneteset használhat.
S3 kompatibilis
Az Amazon S3 API az objektumtárolás de facto szabványa. Minden objektumtároló szoftvergyártó állítja, hogy kompatibilis vele. Az S3-mal való kompatibilitás bináris: vagy teljesen implementálva van, vagy nem.
A gyakorlatban több száz vagy több ezer szélső forgatókönyv létezik, amikor valami elromlik az objektumtárolás használatakor. Különösen a védett szoftverek és szolgáltatások szolgáltatóitól. Fő használati esetei a közvetlen archiválás vagy biztonsági mentés, így kevés okunk van az API meghívására, a használati esetek homogének.
A nyílt forráskódú szoftvereknek jelentős előnyei vannak. Lefedi a legtöbb szélső forgatókönyvet, tekintettel az alkalmazások, operációs rendszerek és hardverarchitektúrák méretére és sokféleségére.
Mindez az alkalmazásfejlesztők számára fontos, ezért érdemes tárhelyszolgáltatókkal tesztelni az alkalmazást. A nyílt forráskód megkönnyíti a folyamatot – könnyebben megérthető, hogy melyik platform a megfelelő az alkalmazásához. A szolgáltató egyetlen belépési pontként használható a tárolóba, vagyis megfelel az Ön igényeinek.
A nyílt forráskód azt jelenti, hogy az alkalmazások nincsenek gyártóhoz kötve, és átláthatóbbak. Ez biztosítja az alkalmazás hosszú élettartamát.
És még néhány megjegyzés a nyílt forráskódról és az S3-ról.
Ha big data alkalmazást futtat, az S3 SELECT egy nagyságrenddel javítja a teljesítményt és a hatékonyságot. Ezt úgy teszi, hogy az SQL segítségével csak a szükséges objektumokat kéri le a tárhelyről.
A legfontosabb szempont a csoportos értesítések támogatása. A csoportos értesítések megkönnyítik a szerver nélküli számítástechnikát, amely minden szolgáltatásként szállított mikroszolgáltatási architektúra fontos összetevője. Tekintettel arra, hogy az objektumtárolás valójában felhőalapú tárolás, ez a képesség kritikussá válik, ha felhőalapú alkalmazások használják az objektumtárolást.
Végül az S3 megvalósításnak támogatnia kell az Amazon S3 szerveroldali titkosítási API-kat: SSE-C, SSE-S3, SSE-KMS. Még jobb, hogy az S3 támogatja a valóban biztonságos szabotázsvédelmet.
Válasz a kudarcokra
Valószínűleg gyakran figyelmen kívül hagyják azt a mutatót, hogy a rendszer hogyan kezeli a hibákat. Meghibásodások többféle ok miatt fordulhatnak elő, és az objektumtárolónak mindegyiket kezelnie kell.
Például egyetlen hibapont van, ennek a mérőszáma nulla.
Sajnos sok objektumtároló rendszer speciális csomópontokat használ, amelyeket engedélyezni kell a fürt megfelelő működéséhez. Ide tartoznak a névcsomópontok vagy a metaadat-kiszolgálók – ez egyetlen hibapontot hoz létre.
Még akkor is, ha több hibapont is van, a katasztrofális kudarcok ellenálló képessége a legfontosabb. A lemezek meghibásodnak, a szerverek meghibásodnak. A kulcs az, hogy olyan szoftvert hozzunk létre, amely a hibákat normál állapotként kezeli. Ha egy lemez vagy csomópont meghibásodik, az ilyen szoftver változtatások nélkül tovább működik.
A beépített adattörlés és adatromlás elleni védelem biztosítja, hogy annyi lemezt vagy csomópontot veszítsen el, ahány paritásblokkja van – általában a lemezek felét. Csak akkor a szoftver nem tud visszaadni adatokat.
A hibát ritkán tesztelik terhelés alatt, de szükséges. A terhelési hiba szimulációja megmutatja a hiba után felmerülő összes költséget.
Következetesség
A 100%-os konzisztencia pontszámot szigorú konzisztenciának is nevezik. A konzisztencia minden tárolórendszer kulcsfontosságú eleme, de az erős konzisztencia ritka. Például az Amazon S3 ListObject nem szigorúan konzisztens, csak a végén konzisztens.
Mit jelent a szigorú következetesség? A megerősített PUT műveletet követő összes műveletnél a következőknek kell történniük:
- A frissített érték bármely csomópontból történő olvasáskor látható.
- A frissítés védve van a csomóponthiba redundanciája ellen.
Ez azt jelenti, hogy ha a felvétel közepén kihúzza a dugót, semmi sem vész el. A rendszer soha nem ad vissza sérült vagy elavult adatokat. Ez egy magas léc, amely sok esetben számít, a tranzakciós alkalmazásoktól a biztonsági mentésig és helyreállításig.
Következtetés
Ezek olyan új objektumtárolási metrikák, amelyek a mai szervezetek használati mintáit tükrözik, ahol a teljesítmény, a konzisztencia, a méretezhetőség, a hibatartományok és az S3-kompatibilitás jelentik a felhőalkalmazások és a nagy adatelemzés építőköveit. Azt javaslom, hogy az ár mellett ezt a listát használja a modern adathalmok építésénél.
A Mail.ru Cloud Solutions objektumtárhelyről: .
Mit kell még olvasni:
- .
- .
- .
Forrás: will.com