S3 objektumtárolási csapat cikket írt arról, hogy milyen kritériumokat érdemes figyelembe venni az objektumtárolás kiválasztásakor. Most az író szavaival következik a szöveg.
Amikor az objektumtárolásról van szó, az emberek általában csak egy tényezőre gondolnak – az árra TB-ra/Gb-ra. Természetesen ez a mutató fontos, de egydimenziós megközelítést ad, és az objektumtárolást archív tárolási eszközként kezeli. Ezen megközelítés hátránya, hogy csökkenti az objektumtárolás fontosságát a vállalati technológiai stackben.
Az objektumtárolás választásakor öt jellemzőre érdemes figyelni:
- teljesítmény;
- méretezhetőség;
- S3 kompatibilitás;
- hibakezelés;
- integritás.
Ezek az öt jellemző új metrikák az objektumtárolásban, amelyek a költséggel egyenrangúak. Vizsgáljuk meg mindegyiket.
Teljesítmény
A hagyományos objektumtárolók teljesítménye nem kiemelkedő. A szolgáltatók folyamatosan feláldozták a teljesítményt az alacsony árakért. Azonban a modern objektumtárolás egy más dimenziót képvisel.
A különböző tárolók sebessége közelíti a Hadoop-ot, sőt akár meg is haladja azt. A modern olvasási és írási sebesség követelményei: 10 GB/s a merevlemezek esetében, akár 35 GB/s az NVMe-nél.
Ez a sávszélesség elegendő a Spark, Presto, Tensorflow, Teradata, Vertica, Splunk és más modern számítási keretrendszerek számára az analitikai stackben. Az a tény, hogy az MPP-alapú adatbázisokat objektumtárolásra állítják be, azt mutatja, hogy egyre inkább alapvető tárolóként használják.
Ha a tárolórendszere nem biztosítja a szükséges sebességet, nem tudja a nyers adatokat használni, és értéket nyerni belőlük. Még akkor is, ha az objektumtárolóból adatokat nyer ki egy memóriában történő feldolgozó struktúrába, akkor is szükséges a sávszélesség a memóriába történő adatátvitelhez és onnan való kiszolgáláshoz. Az elavult objektumtárolóknál ez nem elegendő.
Ez a kulcspont: az új teljesítménymutató a sávszélesség, nem a késleltetés. Szükséges a méretezhető adatokhoz, és ez a normális a modern adat-infrastruktúrában.
Bár a teljesítménytesztek jó módszerek a teljesítmény meghatározására, annak pontos mérésére nem lehetőség az alkalmazás futtatása előtt a környezetben. Csak utána lehet megmondani, hol van a szűk keresztmetszet: a szoftverben, a lemezeken, a hálózaton vagy a számítási szinten.
Skálázhatóság
A skálázhatóság alatt azt értjük, mennyi petabájt helyezhető el egy névtérben. A szolgáltatók könnyű skálázhatóságra hívják fel a figyelmet, de elhallgatják, hogy a nagyobb méret növekedésével a hatalmas monolitikus rendszerek törékennyé, bonyolultabbá, instabillá és költségessé válnak.
Az új skálázhatósági mutató a névterek vagy kliensek száma, amelyeket kiszolgálhat. Ezt a metrikát közvetlenül a hiperskálázóktól veszik, ahol az tárolóelemek kicsiek, de milliárdokig skálázhatóak. Összességében ez egy felhőalapú metrika.
Amikor a szabványos blokkok kicsik, könnyebb őket optimalizálni, azaz biztosítani a biztonságot, a hozzáférési kontrollt, a politikák, az életciklus és a frissítések kezelését megszakítás nélkül. Így végül biztosítható a teljesítmény. A blokk mérete a hibaállóság szempontjából kezelhetőség funkciója, így épülnek fel a nagy rendelkezésre állású rendszerek.
A többbérlős struktúrák sok jellemzővel bírnak. Bár a mutató arról szól, hogy a szervezetek miként biztosítanak hozzáférést az adatokhoz és az alkalmazásokhoz, ez alkalmazásokra és azok izolálásának logikájára is vonatkozik.
A modern többbérlős megközelítés jellemzői:
- Rövid idő alatt a kliensek száma néhány százról több millióra nőhet.
- A kliensek teljesen el vannak szeparálva egymástól. Ez lehetővé teszi számukra, hogy különböző verziókat futtassanak ugyanazon szoftverből, és tárgyakat különböző konfigurációkkal, engedélyekkel, funkciókkal, biztonsági szintekkel és karbantartással tároljanak. Ez szükséges, amikor új kiszolgálókat, frissítéseket és földrajzi régiókat skáláznak.
- A tárolás rugalmasan skálázható, az erőforrások igény szerint nyújtottak.
- Minden műveletet API irányít, és automatizált, emberi beavatkozás nélkül.
- A szoftverek konténerekben helyezhetők el, és használhatók a standard orchestration rendszerek, például a Kubernetes.
S3-kompatibilitás
Az Amazon S3 API gyakorlatilag az objektumtárolók szabványa. Minden objektumtároló szoftverszolgáltató kijelenti a kompatibilitást vele. Az S3 kompatibilitása bináris: vagy teljes mértékben megvalósították, vagy egyáltalán nincs.
A gyakorlatban számos határhelyzet fordulhat elő, amikor az objektumtároló használata során valami nem működik. Különösen a tulajdonosi szoftver- és szolgáltatás-szolgáltatóknál. Fő használati esetük a közvetlen archíválás vagy biztonsági mentés, ezért az API hívásainak száma korlátozott, a felhasználási lehetőségek homogének.
Jelentős előnyei vannak a nyílt forráskódú szoftvernek. Ez lefedi a legtöbb határhelyzetet, figyelembe véve az alkalmazások, operációs rendszerek és hardverarchitektúrák méretét és sokféleségét.
Mindez fontos az alkalmazásfejlesztők számára, ezért érdemes tesztelni az alkalmazás működését a tárolószolgáltatóknál. A nyílt forráskód megkönnyíti a folyamatot - könnyebb megérteni, hogy melyik platform illeszkedik az alkalmazásához. A szolgáltató egységes belépési pontként használható a tárolókhoz - tehát kielégíti az igényeit.
A nyílt forráskód azt jelenti: az alkalmazások nincsenek a szolgáltatóhoz kötve, és átláthatóbbak. Ez biztosítja az alkalmazás hosszú élettartamát.
Egyéb megjegyzések a nyílt forráskódú szoftver és az S3 kapcsán.
Ha nagy adatokat kezelő alkalmazást indít, az S3 SELECT nagymértékben javítja a teljesítményt és a hatékonyságot. Ez azért lehetséges, mert SQL-t használ az objektumtárolóból csak azoknak az objektumoknak az előállításához, amelyekre szüksége van.
Kulcsfontosságú tényező a tároló értesítések támogatása. A tároló értesítések megkönnyítik a szerver nélküli számításokat - ez fontos összetevője minden, mint szolgáltatás nyújtott mikroszolgáltatás-architektúrának. Figyelembe véve, hogy az objektumtároló gyakorlatilag felhőtárolás, ez a lehetőség döntő jelentőségű, amikor az objektumtárolót felhőalkalmazások használják.
Végül, az S3 megvalósításnak támogatnia kell az Amazon S3 API titkosítási interfészeit a szerver oldalon: SSE-C, SSE-S3, SSE-KMS. Még jobb, ha az S3 támogatja az illetéktelen hozzáférés ellen nyújtott védelmet, amely valóban biztonságos.
A hibákra adott reakció
Egy olyan mutató, amelyet valószínűleg gyakran figyelmen kívül hagynak, az, ahogyan a rendszer kezelni a hibákat. A hibák különböző okokból előfordulhatnak, és az objektumtárolónak mindegyiket kezelnie kell.
Például létezik egyetlen hibapont, ennek a metrikája nulla.
Sajnos sok objektumtároló rendszer speciális csomópontokat használ, amelyeket aktiválni kell a klaszter megfelelő működéséhez. Ilyenek a névcsomópontok vagy a metadat szerverek – ez egyetlen hibapontot teremt.
Még ott is, ahol több hibapont is van, elsődleges fontosságú a katasztrofális hibák kezelésének képessége. A lemezek meghibásodnak, a szerverek leállnak. A kulcsfontosságú szempont az olyan szoftver létrehozása, amely a hibákat normál állapotként kezeli. Ha egy lemez vagy csomópont hibásodik meg, ez a szoftver változatlanul fog működni.
Beépített adatvesztés és degradáció elleni védelem garantálja: annyi lemezt vagy csomópontot veszthet, amennyi paritásblokkjuk van – ez általában a lemezek felét jelenti. Csak akkor nem tudja a szoftver visszaállítani az adatokat.
A meghibásodás ritkán ellenőrizhető terhelés alatt, de ez a vizsgálat kötelező. A terhelés alatti hibamodellezés megmutatja a hibát követő összköltségeket.
Konzisztencia
A 100% -os konzisztenciát szigorú konzisztenciának is nevezik. A konzisztencia kulcsfontosságú eleme bármilyen tárolórendszernek, de a szigorú konzisztencia meglehetősen ritka. Például az Amazon S3 ListObject nem szigorúan konzisztens, csak végső soron konzisztens.
Mi is az a szigorú konzisztencia? A megerősített PUT művelet után a következőket kell végrehajtani minden műveletnél:
- Az aktualizált érték látható bármely csomópont olvasásakor.
- A frissítés védett a csomópont hibája elleni mentéssel.
Ez azt jelenti, hogy ha a csatlakozót kihúzzuk a felvétel közepén, akkor semmi sem veszhet el. A rendszer soha nem ad vissza sérült vagy elavult adatokat. Ez egy magas mérce, amely sok forgatókönyv számára jelentőséggel bír: tranzakciós alkalmazásoktól a biztonsági mentésekig és helyreállításokig.
Zárás
Ezek az új objektumtárolási metrikák tükrözik a modern szervezetek használati modelljeit, ahol a teljesítmény, következetesség, skálázhatóság, leállási tartományok és az S3 kompatibilitás építőelemei a felhőalkalmazásoknak és a nagy adatelemzésnek. Javaslom, hogy ezt a listát a díjjal együtt használja a modern adattárak létrehozásakor.
A Mail.ru Cloud Solutions objektumtárolóiról: .
Mit érdemes még olvasni:
- .
- .
- .
Forrás: habr.com
