🥇Uued objektiteenuse metrikad

Lennukite kindlus Nele-Dielilt

S3 objekti salvestamise meeskond Mail.ru pilvesalvestus võttis kokku artikli, millised kriteeriumid on objekti salvestamise valimisel olulised. Järgnevalt tekst autori vaatenurgast.

Kui jutt käib objekti salvestamisest, siis mõeldakse tavaliselt ainult ühele omadusele — hind TB/GB kohta. Muidugi, see näitaja on oluline, kuid see muudab lähenemise ühepoolses ja võrdleb objekti salvestust arhiivide hoidmise tööriistaga. Selline lähenemine vähendab ka objekti salvestuse tähtsust ettevõtte tehnoloogilises ökosüsteemis.

Objekti salvestuse valimisel tasub keskenduda viiele omadusele:

tootlikkus;
skaleeritavus;
S3 ühilduvus;
rikete reageerimine;
täpsus.

Need viis omadust on uued objekti salvestuse näitajad, sama olulised nagu hind. Vaatame neid kõiki lähemalt.

Tõhusus

Traditsioonilised objekti salvestused ei paista silma tootlikkuse poolest. Teenusepakkujad on pidevalt ohverdanud tootlikkuse odavate hindade nimel. Kuid kaasaegsete objektide salvestustega on kõik teisiti.

Erinevate salvestuste kiirus läheneb Hadoop'ile või isegi ületab seda. Kaasaegsed lugemise ja kirjutamise kiirusnõuded: 10 GB/s — kõvaketaste jaoks, kuni 35 GB/s — NVMe jaoks.

Selline ribalaius on piisav Spark'i, Presto, Tensorflow, Teradata, Vertica, Splunk'i ja teiste kaasaegsete analüütiliste õpikodade jaoks. Fakt, et MPP andmebaasid seadistatakse objekti salvestustele, näitab, et seda kasutatakse üha enam peamise salvestusena.

Kui teie salvestussüsteem ei paku vajalikku kiirus, ei saa te andmeid kasutada ega neist väärtust välja võtta. Isegi kui te ekstraheerite andmeid objekti salvestusest mälus töötlemise struktuuri, on ikka vajalik ribalaius andmete edastamiseks mällu ja sealt välja. Vananenud objekti salvestuste puhul on seda liiga vähe.

See on oluline punkt: uus tootlikkuse näitaja on ribalaius, mitte latentsus. See on vajalik skaleeritavatele andmetele ja see on norm tänapäeva andmeinfrastruktuuris.

Ja kuigi jõudlustestid on hea viis jõudluse määramiseks, ei saa seda täpselt mõõta enne rakenduse käivitamist keskkonnas. Ainult pärast seda saab öelda, kus kitsaskohad asuvad: tarkvaras, ketastes, võrgu või arvutusvõimsuse tasemel.

Skaleeritavus

Mastaapsust mõistetakse kui petabaiti, mis mahub ühte nimesse. Teenusepakkujad räägivad lihtsast mastaapsusest, kuid jätavad mainimata, et mastaapimise korral muutuvad massiivsed monoliitsed süsteemid habrasteks, keerukateks, ebastabiilseteks ja kulukateks.

Uus mastaapsuse näitaja on nimesid või kliente, keda saate teenindada. Seda mõõdet võetakse otse hüperkaalujatest, kus ladustamise ehitusplokid on väikesed, kuid mastaabivad miljardite üksusteni. Üldiselt on see pilvenäitajana.

Kui standardblokkide mõõtmed on väikesed, on neid lihtsam optimeerida, st tagada turvalisus, ligipääsukontroll, poliitikate, elutsükli ja värskenduste haldamine katkestusteta. Ja lõpuks tagada jõudlus. Ehitusploki suurus on funktsioon rikehaldamise juhtimisest, nii ehitatakse kõrge kättesaadavusega süsteeme.

Multikliendil on palju omadusi. Kuigi parameeter räägib sellest, kuidas organisatsioonid annavad ligipääsu andmetele ja rakendustele, kehtib see ka rakenduste ja nende isolatsiooni loogika kohta.

Kaasaegse multikliendiga seotud lähenemise omadused:

Lühikese aja jooksul võib klientide arv tõusta sadadest miljoniteni.
Kliendid on omavahel täielikult eraldatud. See võimaldab neil käivitada erinevaid versioone samast tarkvarast ja hoida objekte erinevate konfiguratsioonide, õiguste, funktsioonide, turvatasemete ja teenindusastmetega. See on hädavajalik uute serverite, uuenduste ja geograafiliste piirkondade skaleerimise korral.
Ahi on elastne mastaapimisega, ressursid pakutakse nõudmisel.
Iga operatsiooni haldab API ja automatiseeritakse inimeste sekkumiseta.
Tarkvara saab paigutada konteineritesse ja kasutada standartseid orkestreerimisse süsteeme, nagu Kubernetes.

Ühildub S3-ga

Amazon S3 API — de facto standard objektide salvestamiseks. Iga tarkvaratootja, kes pakub objektide salvestust, väidab, et on sellega ühilduv. Ühilduvus S3-s on binaarne: kas see on täielikult rakendatud või ei ole seda üldse.

Praktiliselt võib esineda sadu ja tuhandeid äärmuslikke stsenaariume, kus objektide salvestamise kasutamisel midagi läheb valesti. Eriti nagu see on juhtumiproprieetaarsete tarkvara ja teenuste pakkujatega. Selle põhieesmärgid on otse arhiivimine või varundamine, seega API-kutsed on harvad, kasutusvõimalused on ühtsed.

Olulised eelised avatud lähtekoodiga tarkvaral. See katab enamiku äärmuslikest stsenaariumitest, arvestades rakenduste, operatsioonisüsteemide ja riistvara arhitektuuri suurust ja mitmekesisust.

Kõik see on arendajatele oluline, seega tasub testida rakenduse toimimist salvestusteenuse pakkujatega. Avatud lähtekood lihtsustab seda protsessi — on lihtsam mõista, milline platvorm sobib teie rakendusele. Pakkujat saab kasutada ühtse sissepääsupunktina salvestustesse — see tähendab, et see rahuldab teie vajadusi.

Avatud lähtekood tähendab: rakendused ei ole seotud pakkujaga ja on läbipaistvamad. See tagab rakenduse pika elutsükli.

Ja veel paar märkust avatud lähtekoodist ja S3-st.

Kui käivitate rakenduse, mis töötleb suurt andmehulka, tõstab S3 SELECT märkimisväärselt jõudlust ja efektiivsust. See saavutatakse, kasutades SQL-i, et väljavõtteid salvestusest ainult neid objekte, mis on teile vajalikud.

Küsimus on teenusepakkujate toetuses hoiatuste kohta. Hoidla hoiatuste tugi lihtsustab serverivaba arvutust — oluliseks komponendiks mis tahes teenusena pakutavas mikroteenuste arhitektuuris. Arvestades, et objektide salvestus on sisuliselt pilvesalvestus, muutub see funktsioon otsustavaks, kui objektide salvestust kasutatakse pilve rakendustes.

Lõppkokkuvõttes peab S3 rakendus toetama Amazon S3 API serveripoolsete šifreerimise meetodeid: SSE-C, SSE-S3, SSE-KMS. Veel parem, kui S3 toetab tõeliselt turvalist volitamiskaitset.

Reaktsioon tõrgetele

Indikaator, mida tõenäoliselt sageli tähelepanuta jäetakse, on see, kuidas süsteem tegeleb tõrgetega. Tõrkeid esineb erinevatel põhjustel ning objektne salvestus peab nendega kõikide juhtumite korral toime tulema.

Näiteks on olemas üksik tõrgetepunkt, mille mõõdik on null.

Kahjuks kasutavad paljud objektide salvestussüsteemid spetsiaalseid sõlmi, mis peavad olema aktiveeritud klastrite õige töö tagamiseks. Need hõlmavad nimisõlmi või metaandmete servereid – see loob ainulaadse tõrgetepunkti.

Isegi seal, kus on ette nähtud mitu tõrgetepunkti, on esmatähtis võime taluda katastroofilisi tõrkeid. Kõvakettad ebaõnnestuvad, serverid ebaõnnestuvad. Peamine on luua tarkvara, mis on loodud tõrgete töötlemiseks normaalse seisundina. Kui kõvaketas või sõlm ebaõnnestub, töötab see tarkvara edasi ilma muutusteta.

Sisseehitatud kaitse kustutamise ja andmete degradatsiooni eest tagab, et: saate kaotada nii palju kõvakettaid või sõlmi, kui teil on pariteediblokke – tavaliselt on see pool kõvaketaste arvust. Ainult siis ei suuda tarkvara andmeid taastada.

Tõrkealased testid ei ole sageli koormuse all, kuid sellised testid on kohustuslikud. Koormuse all tõrke simuleerimine näitab kooskulutusi, mis tekivad pärast tõrget.

Konsistentsus

100% konsistentsuse näitajat nimetatakse ka rangeks konsistentsuseks. Konsistentsus on iga salvestussüsteemi võtmekomponent, kuid range konsistentsus esineb üsna harva. Näiteks Amazon S3 ListObject ei ole range konsistentsusega, see on konsistentne ainult lõpuks.

Mida tähendab range konsistentsus? Kõikide PUT-kinnitusejärgsete toimingute puhul peab olema järgnev:

Uuendatud väärtus on nähtav igast sõlmest lugemisel.
Uuendamine on kaitstud sõlme tõrke varundamise eest.

See tähendab: kui tõmmata pistik välja salvestamise keskel, siis ei kao midagi. Süsteem ei tagasta kunagi kahjustatud või aegunud andmeid. See on kõrge mõõt, mis on oluline paljudes stsenaariumides: alates tehingu rakendustest kuni varundamise ja taastamiseni.

Kokkuvõte

Need uued objektiteenuse metrikad, mis peegeldavad kasutusmudeleid tänapäevastes organisatsioonides, kus jõudlus, järjepidevus, skaleeritavus, tõrke domeenid ja S3 ühilduvus on pilve rakenduste ja suurandmete analüüsi ehitusplokid. Soovitan seda loeteluga koos hinna kasutamist ka tänapäevaste andmestikke loomisel.

Mail.ru Cloud Solutions objektiteenuse kohta: S3 arhitektuur. 3 aastat Mail.ru Cloud Storagei arengut.

Mida veel lugeda:

Allikas: habr.com