S3 objektlagringskommando oversatt en artikkel om hvilke kriterier som er viktige ved valg av objektlagring. Det følgende er teksten fra forfatterens perspektiv.
Når det kommer til objektlagring, tenker folk vanligvis bare på én ting: pris per TB/GB. Selvfølgelig er denne metrikken viktig, men den gjør tilnærmingen ensidig og sidestiller objektlagring med et arkivlagringsverktøy. I tillegg reduserer denne tilnærmingen viktigheten av objektlagring for bedriftsteknologistabelen.
Når du velger gjenstandslagring, bør du være oppmerksom på fem egenskaper:
- opptreden;
- skalerbarhet;
- S3-kompatibel;
- respons på feil;
- integritet.
Disse fem egenskapene er nye beregninger for objektlagring, sammen med kostnad. La oss se på dem alle.
Производительность
Tradisjonelle gjenstandslagre mangler ytelse. Tjenesteleverandører ofret det hele tiden i jakten på lave priser. Men med moderne gjenstandslagring er ting annerledes.
Ulike lagringssystemer nærmer seg eller til og med overskrider Hadoops hastighet. Moderne krav til lese- og skrivehastigheter: fra 10 GB/s for harddisker, opptil 35 GB/s for NVMe.
Denne gjennomstrømningen er tilstrekkelig for Spark, Presto, Tensorflow, Teradata, Vertica, Splunk og andre moderne datarammeverk i analysestakken. Det faktum at MPP-databaser blir konfigurert for objektlagring antyder at det i økende grad blir brukt som primærlagring.
Hvis lagringssystemet ditt ikke gir den hastigheten du trenger, kan du ikke bruke dataene og trekke ut verdier fra dem. Selv om du henter data fra objektlagring til en prosesseringsstruktur i minnet, vil du fortsatt trenge båndbredde for å overføre dataene til og fra minnet. Eldre objektbutikker har ikke nok av det.
Dette er nøkkelpoenget: den nye ytelsesberegningen er gjennomstrømning, ikke ventetid. Det kreves for data i stor skala og er normen i moderne datainfrastruktur.
Selv om benchmarks er en god måte å bestemme ytelsen på, kan den ikke måles nøyaktig før applikasjonen kjøres i miljøet. Først etter det kan du si hvor nøyaktig flaskehalsen er: i programvare, disker, nettverk eller på databehandlingsnivå.
Skalerbarhet
Skalerbarhet refererer til antall petabyte som passer inn i ett navneområde. Det leverandører hevder er enkel skalerbarhet, det de ikke sier er at når de skaleres, blir massive monolittiske systemer skjøre, komplekse, ustabile og dyre.
Den nye beregningen for skalerbarhet er antall navneområder eller klienter du kan betjene. Metrikken er hentet direkte fra hyperskalere, der lagringsbyggesteinene er små, men skaleres til milliarder av enheter. Generelt er dette en skyberegning.
Når byggeklossene er små, er de lettere å optimalisere for sikkerhet, tilgangskontroll, policyadministrasjon, livssyklusadministrasjon og ikke-forstyrrende oppdateringer. Og til slutt sikre produktivitet. Størrelsen på byggeblokken er en funksjon av kontrollerbarheten til sviktområdet, som er hvor svært motstandsdyktige systemer er bygget.
Flerleie har mange kjennetegn. Mens dimensjonen snakker om hvordan organisasjoner gir tilgang til data og applikasjoner, refererer den også til applikasjonene selv og logikken bak å isolere dem fra hverandre.
Kjennetegn ved en moderne tilnærming til multiklient:
- På kort tid kan antallet kunder vokse fra flere hundre til flere millioner.
- Klienter er fullstendig isolert fra hverandre. Dette lar dem kjøre forskjellige versjoner av samme programvare og lagre objekter med forskjellige konfigurasjoner, tillatelser, funksjoner, sikkerhets- og vedlikeholdsnivåer. Dette er nødvendig når du skalerer til nye servere, oppdateringer og geografier.
- Lagringen er elastisk skalerbar, ressurser leveres på forespørsel.
- Hver operasjon styres av et API og er automatisert uten menneskelig innblanding.
- Programvare kan hostes i containere og bruke standard orkestreringssystemer som Kubernetes.
S3-kompatibel
Amazon S3 API er de facto-standarden for objektlagring. Hver leverandør av programvare for objektlagring hevder kompatibilitet med den. Kompatibilitet med S3 er binær: enten er den fullstendig implementert eller ikke.
I praksis er det hundrevis eller tusenvis av kantscenarier der noe går galt ved bruk av objektlagring. Spesielt fra leverandører av proprietær programvare og tjenester. Dens viktigste brukstilfeller er direkte arkivering eller sikkerhetskopiering, så det er få grunner til å kalle API, brukstilfellene er homogene.
Programvare med åpen kildekode har betydelige fordeler. Den dekker de fleste kantscenarier, gitt størrelsen og variasjonen av applikasjoner, operativsystemer og maskinvarearkitekturer.
Alt dette er viktig for applikasjonsutviklere, så det er verdt å teste applikasjonen med lagringsleverandører. Åpen kildekode gjør prosessen enklere – det er lettere å forstå hvilken plattform som er riktig for applikasjonen din. Leverandøren kan brukes som et enkelt inngangspunkt til lagring, noe som betyr at den vil møte dine behov.
Åpen kildekode betyr: applikasjoner er ikke knyttet til en leverandør og er mer transparente. Dette sikrer en lang brukslivssyklus.
Og noen flere merknader om åpen kildekode og S3.
Hvis du kjører en big data-applikasjon, forbedrer S3 SELECT ytelsen og effektiviteten med en størrelsesorden. Den gjør dette ved å bruke SQL for å hente bare objektene du trenger fra lagring.
Nøkkelpunktet er støtte for bøttevarsler. Bucket-varslinger forenkler serverløs databehandling, en viktig komponent i enhver mikrotjenestearkitektur som leveres som en tjeneste. Gitt at objektlagring effektivt er skylagring, blir denne muligheten kritisk når objektlagring brukes av skybaserte applikasjoner.
Til slutt må S3-implementeringen støtte Amazon S3 server-side krypterings-APIer: SSE-C, SSE-S3, SSE-KMS. Enda bedre, S3 støtter sabotasjebeskyttelse som er virkelig sikker.
Respons på feil
En beregning som sannsynligvis ofte blir oversett er hvordan systemet håndterer feil. Feil skjer av en rekke årsaker, og objektlagring må håndtere dem alle.
For eksempel er det et enkelt feilpunkt, metrikken for dette er null.
Dessverre bruker mange objektlagringssystemer spesielle noder som må være aktivert for at klyngen skal fungere skikkelig. Disse inkluderer navnenoder eller metadataservere - dette skaper et enkelt feilpunkt.
Selv der det er flere feilpunkter, er evnen til å motstå katastrofale feil avgjørende. Disker svikter, servere svikter. Nøkkelen er å lage programvare designet for å håndtere feil som en normal tilstand. Hvis en disk eller node svikter, vil slik programvare fortsette å fungere uten endringer.
Innebygd beskyttelse mot datasletting og dataforringelse sikrer at du kan miste like mange disker eller noder som du har paritetsblokker – vanligvis halvparten av diskene. Først da vil ikke programvaren kunne returnere data.
Feilen testes sjelden under belastning, men slik testing er obligatorisk. Simulering av en lastfeil vil vise de totale kostnadene som påløper etter feilen.
Konsistens
En konsistensscore på 100 % kalles også streng konsistens. Konsistens er en nøkkelkomponent i ethvert lagringssystem, men sterk konsistens er sjelden. For eksempel er Amazon S3 ListObject ikke strengt konsistent, det er bare konsistent på slutten.
Hva menes med streng konsistens? For alle operasjoner etter en bekreftet PUT-operasjon, må følgende skje:
- Den oppdaterte verdien er synlig når du leser fra en hvilken som helst node.
- Oppdateringen er beskyttet mot redundans for nodefeil.
Det betyr at hvis du trekker ut støpselet midt i et opptak, vil ingenting gå tapt. Systemet returnerer aldri ødelagte eller utdaterte data. Dette er en høy bar som betyr noe i mange scenarier, fra transaksjonsapplikasjoner til sikkerhetskopiering og gjenoppretting.
Konklusjon
Dette er nye objektlagringsmålinger som gjenspeiler bruksmønstre i dagens organisasjoner, der ytelse, konsistens, skalerbarhet, feildomener og S3-kompatibilitet er byggesteinene for skyapplikasjoner og big data-analyse. Jeg anbefaler å bruke denne listen i tillegg til pris når du bygger moderne datastabler.
Om Mail.ru Cloud Solutions objektlagring: .
Hva annet å lese:
- .
- .
- .
Kilde: www.habr.com