Ekipi i ruajtjes objektive S3 përktheu një artikull se cilat kritere janë të rëndësishme gjatë zgjedhjes së një ruajtjeje objektive. Më poshtë është teksti nga këndvështrimi i autorit.
Kur flitet pĂ«r ruajtjen objektive, zakonisht njerĂ«zit mendojnĂ« vetĂ«m pĂ«r njĂ« karakteristikĂ« â çmimin pĂ«r TB/GB. Sigurisht, kjo metrikĂ« Ă«shtĂ« e rĂ«ndĂ«sishme, por e bĂ«n qasjen tĂ« njĂ«anshme dhe e redukton ruajtjen objektive nĂ« njĂ« mjet pĂ«r ruajtjen e arkivave. PĂ«r mĂ« tepĂ«r, njĂ« qasje e tillĂ« e zvogĂ«lon rĂ«ndĂ«sinĂ« e ruajtjes objektive nĂ« stack-un teknologjik tĂ« njĂ« ndĂ«rmarrjeje.
Kur zgjidhni një ruajtje objektive, ia vlen t'u kushtoni vëmendje pesë karakteristikave:
- performanca;
- shkallëzueshmëria;
- pajtueshmëria me S3;
- reagimi ndaj dështimeve;
- integriteti.
KĂ«to pesĂ« karakteristika janĂ« metrikat e reja tĂ« ruajtjes objektive, nĂ« tĂ« njĂ«jtin nivel me koston. Le tâi shqyrtojmĂ« tĂ« gjitha.
Performanca
Ruajtjet objektive tradicionale nuk dallohen për performancë të lartë. Ofruesit e shërbimeve e kanë sakrifikuar vazhdimisht atë në ndjekje të çmimeve të ulëta. Megjithatë, me ruajtjet objektive moderne, situata është krejt ndryshe.
ShpejtĂ«sia e ruajtjeve tĂ« ndryshme po i afrohet Hadoop ose madje e tejkalon atĂ«. KĂ«rkesat moderne pĂ«r shpejtĂ«sinĂ« e leximit dhe shkrimit janĂ«: nga 10 GB/s pĂ«r disqet e ngurta, deri nĂ« 35 GB/s pĂ«r NVMe.Â
Një kapacitet i tillë transmetimi është i mjaftueshëm për Spark, Presto, Tensorflow, Teradata, Vertica, Splunk dhe framework-e të tjera moderne llogaritëse në stack-un analitik. Fakti që bazat e të dhënave MPP konfigurohen mbi ruajtje objektive tregon se ajo po përdoret gjithnjë e më shpesh si ruajtje kryesore.
NĂ«se sistemi juaj i ruajtjes nuk ofron shpejtĂ«sinĂ« e nevojshme, nuk mund tâi pĂ«rdorni tĂ« dhĂ«nat dhe tĂ« nxirrni vlerĂ« prej tyre. Edhe nĂ«se i transferoni tĂ« dhĂ«nat nga ruajtja objektive nĂ« njĂ« strukturĂ« pĂ«rpunimi nĂ« memorie, pĂ«rsĂ«ri do tĂ« nevojitet kapacitet transmetimi pĂ«r tâi kaluar tĂ« dhĂ«nat drejt memories dhe prej saj. Ruajtjet objektive tĂ« vjetruara nuk e ofrojnĂ« mjaftueshĂ«m kĂ«tĂ«.
Ky është thelbi: treguesi i ri i performancës është kapaciteti i transmetimit, jo latenca. Ai është i domosdoshëm për të dhëna të shkallëzueshme dhe është standard në infrastrukturën moderne të të dhënave.
Megjithëse testet e performancës janë një mënyrë e mirë për ta vlerësuar atë, performanca nuk mund të matet me saktësi derisa aplikacioni të vihet në punë në mjedisin real. Vetëm atëherë mund të përcaktohet saktësisht ku ndodhet ngushtica: te softueri, te disqet, te rrjeti apo në nivelin e llogaritjes.
Shkallëzueshmëria
Shkallëzueshmëria nënkupton numrin e petabajtëve që mund të futen në një hapësirë emrash të vetme. Ofruesit flasin për shkallëzim të lehtë, por shpesh nuk përmendin se, me rritjen e shkallës, sistemet monolitike masive bëhen të brishta, të ndërlikuara, të paqëndrueshme dhe të kushtueshme.
Treguesi i ri i shkallëzueshmërisë është numri i hapësirave të emrave ose i klientëve që mund të shërbeni. Kjo metrikë vjen drejtpërdrejt nga hyperscaler-ët, ku blloqet bazë të ruajtjes janë të vogla, por mund të shkallëzohen deri në miliarda njësi. Në thelb, kjo është një metrikë cloud.
Kur blloqet standarde kanë përmasa të vogla, ato optimizohen më lehtë, pra bëhet më e thjeshtë të sigurohen mbrojtja, kontrolli i aksesit, menaxhimi i politikave, cikli i jetës dhe përditësimet pa ndërprerje të punës. Dhe, në fund, të garantohet performanca. Madhësia e bllokut bazë është funksion i menaxhueshmërisë së domenit të dështimit; pikërisht kështu ndërtohen sistemet me qëndrueshmëri të lartë.
Multitenancy ka shumë karakteristika. Edhe pse ky parametër tregon se si organizatat ofrojnë qasje në të dhëna dhe aplikacione, ai lidhet gjithashtu me vetë aplikacionet dhe me logjikën e izolimit të tyre nga njëri-tjetri.
Karakteristikat e qasjes moderne ndaj multitenancy:
- Brenda një kohe të shkurtër, numri i klientëve mund të rritet nga disa qindra në disa milionë.
- Klientët janë plotësisht të izoluar nga njëri-tjetri. Kjo u mundëson atyre të ekzekutojnë versione të ndryshme të të njëjtit softuer dhe të ruajnë objekte me konfigurime, leje, funksione, nivele sigurie dhe nivele shërbimi të ndryshme. Kjo është e domosdoshme kur shkallëzohen serverët e rinj, përditësimet dhe rajonet gjeografike.
- Ruajtja shkallëzohet në mënyrë elastike, ndërsa burimet ofrohen sipas kërkesës.
- Ădo operacion menaxhohet pĂ«rmes API dhe automatizohet pa ndĂ«rhyrje njerĂ«zore.
- Softueri mund të vendoset në kontejnerë dhe të përdorë sisteme standarde orkestrimi, si p.sh. Kubernetes.
Përputhshmëri me S3
Amazon S3 API Ă«shtĂ« de facto standardi pĂ«r ruajtjen e objekteve. Ădo ofrues i softuerit pĂ«r ruajtje objektesh deklaron pajtueshmĂ«ri me tĂ«. PajtueshmĂ«ria me S3 Ă«shtĂ« binare: ose zbatohet plotĂ«sisht, ose mungon.
Në praktikë, mund të ketë qindra e mijëra skenarë kufitarë ku, gjatë përdorimit të ruajtjes së objekteve, diçka shkon keq. Kjo ndodh veçanërisht te ofruesit e softuerit dhe shërbimeve pronësore. Skenarët kryesorë të përdorimit janë arkivimi i drejtpërdrejtë ose rezervimi, ndaj arsyet për thirrjen e API janë të pakta dhe rastet e përdorimit janë të njëtrajtshme.
Përparësi të dukshme ka softueri me kod të hapur. Ai mbulon shumicën e skenarëve kufitarë, duke marrë parasysh madhësinë dhe shumëllojshmërinë e aplikacioneve, sistemeve operative dhe arkitekturave harduerike.
E gjithĂ« kjo Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r zhvilluesit e aplikacioneve, prandaj ia vlen tĂ« testohet funksionimi i aplikacionit me ofruesit e ruajtjes. Kodi i hapur e thjeshton procesin: Ă«shtĂ« mĂ« e lehtĂ« tĂ« kuptohet se cila platformĂ« i pĂ«rshtatet aplikacionit tuaj. Ofruesi mund tĂ« pĂ«rdoret si pikĂ« unike hyrjeje nĂ« ruajtje, qĂ« do tĂ« thotĂ« se do tâi pĂ«rmbushĂ« nevojat tuaja.Â
Kodi i hapur do të thotë që aplikacionet nuk lidhen me një ofrues të vetëm dhe janë më transparente. Kjo siguron një cikël jetësor të gjatë për aplikacionin.
Dhe edhe disa vĂ«rejtje tĂ« tjera rreth kodit tĂ« hapur dhe S3.Â
Nëse po përdorni një aplikacion për përpunimin e Big Data, S3 SELECT e rrit ndjeshëm performancën dhe efikasitetin. Kjo arrihet duke përdorur SQL për të nxjerrë nga ruajtja vetëm ato objekte që ju nevojiten.
Pika kyçe është mbështetja për njoftimet e bucket. Njoftimet e bucket e thjeshtojnë serverless computing, një komponent i rëndësishëm i çdo arkitekture mikroshërbimesh që ofrohet si shërbim. Duke pasur parasysh se ruajtja e objekteve është në thelb ruajtje cloud, kjo mundësi bëhet vendimtare kur ruajtja e objekteve përdoret nga aplikacionet cloud.
SĂ« fundi, implementimi i S3 duhet tĂ« mbĂ«shtesĂ« ndĂ«rfaqet e enkriptimit nga ana e serverit tĂ« Amazon S3 API: SSE-C, SSE-S3, SSE-KMS. Edhe mĂ« mirĂ« nĂ«se S3 mbĂ«shtet mbrojtje nga qasja e paautorizuar qĂ« Ă«shtĂ« realisht e sigurt.Â
Reagimi ndaj dështimeve
NjĂ« tregues qĂ« ndoshta shpesh anashkalohet Ă«shtĂ« mĂ«nyra se si sistemi i pĂ«rballon dĂ«shtimet. DĂ«shtimet ndodhin pĂ«r arsye tĂ« ndryshme dhe ruajtja e objekteve duhet tâi menaxhojĂ« tĂ« gjitha.
Për shembull, nëse ekziston një pikë e vetme dështimi, kjo metrikë është zero.
PĂ«r fat tĂ« keq, shumĂ« sisteme tĂ« ruajtjes sĂ« objekteve pĂ«rdorin nyje tĂ« posaçme qĂ« duhet tĂ« jenĂ« aktive qĂ« klasteri tĂ« funksionojĂ« siç duhet. KĂ«tu pĂ«rfshihen nyjet e emrave ose serverĂ«t e metadata-ve â dhe kjo krijon njĂ« pikĂ« tĂ« vetme dĂ«shtimi.
Edhe kur parashikohen disa pika dĂ«shtimi, aftĂ«sia pĂ«r tâi pĂ«rballuar dĂ«shtimet katastrofike mbetet thelbĂ«sore. Disqet prishen, serverĂ«t dĂ«shtojnĂ«. Thelbi Ă«shtĂ« krijimi i softuerit tĂ« projektuar pĂ«r tâi trajtuar dĂ«shtimet si njĂ« gjendje normale pune. Kur dĂ«shton njĂ« disk ose njĂ« nyje, njĂ« softuer i tillĂ« vazhdon tĂ« funksionojĂ« pa ndryshime.
Mbrojtja e integruar kundĂ«r humbjes dhe degradimit tĂ« tĂ« dhĂ«nave garanton sa vijon: mund tĂ« humbni aq disqe ose nyje sa keni blloqe pariteti â zakonisht deri nĂ« gjysmĂ«n e disqeve. VetĂ«m atĂ«herĂ« softueri nuk do tĂ« jetĂ« mĂ« nĂ« gjendje tâi rikthejĂ« tĂ« dhĂ«nat.
Dështimi rrallë testohet nën ngarkesë, por një test i tillë është i domosdoshëm. Simulimi i një dështimi nën ngarkesë do të tregojë kostot e përgjithshme që lindin pas dështimit.
Konsistenca
Një nivel konsistence prej 100% quhet edhe konsistencë e fortë. Konsistenca është një komponent kyç i çdo sistemi ruajtjeje, por konsistenca e fortë është mjaft e rrallë. Për shembull, Amazon S3 ListObject nuk është rreptësisht konsistent; ai është konsistent vetëm në fund.
ĂfarĂ« nĂ«nkuptohet me konsistencĂ« tĂ« fortĂ«? PĂ«r tĂ« gjitha operacionet, pas njĂ« operacioni PUT tĂ« konfirmuar, duhet tĂ« vlejĂ« sa vijon:
- Vlera e përditësuar është e dukshme gjatë leximit nga çdo nyje.
- Përditësimi mbrohet me redundancë ndaj dështimit të një nyje.
Kjo do të thotë: nëse hiqet kablloja nga priza në mes të shkrimit, asgjë nuk humbet. Sistemi nuk kthen kurrë të dhëna të dëmtuara ose të vjetruara. Ky është një standard i lartë që ka rëndësi për shumë skenarë: nga aplikacionet transaksionale te backup-i dhe rikuperimi.
PĂ«rfundim
KĂ«to janĂ« metrika tĂ« reja pĂ«r ruajtjen objektore, tĂ« cilat pasqyrojnĂ« modelet e pĂ«rdorimit nĂ« organizatat moderne, ku performanca, konsistenca, shkallĂ«zueshmĂ«ria, domenet e dĂ«shtimit dhe pĂ«rputhshmĂ«ria me S3 janĂ« blloqet themelore pĂ«r aplikacionet cloud dhe analitikĂ«n e tĂ« dhĂ«nave tĂ« mĂ«dha. Ju rekomandoj ta pĂ«rdorni kĂ«tĂ« listĂ« krahas çmimit gjatĂ« ndĂ«rtimit tĂ« stack-eve moderne tĂ« tĂ« dhĂ«nave.Â
Rreth ruajtjes objektore të Mail.ru Cloud Solutions: .
ĂfarĂ« tjetĂ«r mund tĂ« lexoni:
- .
- .
- .Â
Burimi: habr.com
