S3 objektlagringskommando oversat en artikel om, hvilke kriterier der er vigtige ved valg af objektopbevaring. Det følgende er teksten fra forfatterens perspektiv.
Når det kommer til objektlagring, tænker folk typisk kun på én ting: Pris pr. TB/GB. Selvfølgelig er denne metrik vigtig, men den gør tilgangen ensidig og sidestiller objektlagring med et arkivlagringsværktøj. Derudover reducerer denne tilgang betydningen af objektlagring for virksomhedens teknologistack.
Når du vælger objektopbevaring, skal du være opmærksom på fem egenskaber:
- ydeevne;
- skalerbarhed;
- S3 kompatibel;
- reaktion på fejl;
- integritet.
Disse fem karakteristika er nye målinger for objektlagring sammen med omkostninger. Lad os se på dem alle.
Ydelse
Traditionelle objektbutikker mangler ydeevne. Tjenesteudbydere ofrede det konstant i jagten på lave priser. Men med moderne objektopbevaring er tingene anderledes.
Forskellige lagersystemer nærmer sig eller overstiger endda Hadoops hastighed. Moderne krav til læse- og skrivehastigheder: fra 10 GB/s for harddiske, op til 35 GB/s for NVMe.
Denne gennemstrømning er tilstrækkelig til Spark, Presto, Tensorflow, Teradata, Vertica, Splunk og andre moderne computerrammer i analysestakken. Det faktum, at MPP-databaser bliver konfigureret til objektlagring, tyder på, at det i stigende grad bliver brugt som det primære lager.
Hvis dit lagersystem ikke giver den hastighed, du har brug for, kan du ikke bruge dataene og udtrække værdi fra dem. Selvom du henter data fra objektlager til en in-memory-behandlingsstruktur, har du stadig brug for båndbredde til at overføre dataene til og fra hukommelsen. Ældre objektbutikker har ikke nok af det.
Dette er nøglepunktet: den nye præstationsmåling er gennemløb, ikke latens. Det er påkrævet for data i stor skala og er normen i moderne datainfrastruktur.
Mens benchmarks er en god måde at bestemme ydeevne på, kan den ikke måles nøjagtigt, før applikationen køres i miljøet. Først efter det kan du sige, hvor nøjagtigt flaskehalsen er: i software, diske, netværk eller på computerniveau.
Skalerbarhed
Skalerbarhed refererer til antallet af petabytes, der passer ind i ét navneområde. Hvad leverandører hævder er let skalerbarhed, hvad de ikke siger er, at når de skaleres, bliver massive monolitiske systemer skrøbelige, komplekse, ustabile og dyre.
Den nye metrik for skalerbarhed er antallet af navneområder eller klienter, du kan betjene. Metrikken er taget direkte fra hyperskalere, hvor lagerbyggestenene er små, men skaleres til milliarder af enheder. Generelt er dette en sky-metrik.
Når byggeklodserne er små, er de nemmere at optimere til sikkerhed, adgangskontrol, politikstyring, livscyklusstyring og ikke-forstyrrende opdateringer. Og i sidste ende sikre produktiviteten. Størrelsen af byggeklodsen er en funktion af styrbarheden af fejlregionen, som er, hvor meget modstandsdygtige systemer er bygget.
Multilejemål har mange kendetegn. Mens dimensionen taler om, hvordan organisationer giver adgang til data og applikationer, refererer den også til selve applikationerne og logikken bag at isolere dem fra hinanden.
Karakteristika ved en moderne tilgang til multi-klient:
- På kort tid kan antallet af kunder vokse fra flere hundrede til flere millioner.
- Klienter er fuldstændig isoleret fra hinanden. Dette giver dem mulighed for at køre forskellige versioner af den samme software og gemme objekter med forskellige konfigurationer, tilladelser, funktioner, sikkerheds- og vedligeholdelsesniveauer. Dette er nødvendigt, når du skalerer til nye servere, opdateringer og geografiske områder.
- Lageret er elastisk skalerbart, ressourcer stilles til rådighed efter behov.
- Hver operation styres af en API og er automatiseret uden menneskelig indgriben.
- Software kan hostes i containere og bruge standard orkestreringssystemer såsom Kubernetes.
S3 kompatibel
Amazon S3 API er de facto standarden for objektlagring. Hver leverandør af software til objektlagring hævder kompatibilitet med det. Kompatibilitet med S3 er binær: enten er den fuldt implementeret, eller også er den ikke.
I praksis er der hundredvis eller tusindvis af kantscenarier, hvor noget går galt, når du bruger objektlagring. Især fra udbydere af proprietær software og tjenester. Dens vigtigste use cases er direkte arkivering eller backup, så der er få grunde til at kalde API’en, use cases er homogene.
Open source-software har betydelige fordele. Det dækker de fleste kantscenarier, givet størrelsen og variationen af applikationer, operativsystemer og hardwarearkitekturer.
Alt dette er vigtigt for applikationsudviklere, så det er værd at teste applikationen hos lagerudbydere. Open source gør processen nemmere – det er nemmere at forstå, hvilken platform der passer til din applikation. Udbyderen kan bruges som et enkelt indgangssted til opbevaring, hvilket betyder, at den opfylder dine behov.
Open source betyder: applikationer er ikke bundet til en leverandør og er mere gennemsigtige. Dette sikrer en lang anvendelseslivscyklus.
Og et par flere bemærkninger om open source og S3.
Hvis du kører en big data-applikation, forbedrer S3 SELECT ydeevne og effektivitet med en størrelsesorden. Det gør den ved at bruge SQL til kun at hente de objekter, du har brug for, fra lageret.
Nøglepunktet er understøttelse af bucket-meddelelser. Bucket-meddelelser letter serverløs computing, en vigtig komponent i enhver mikroservicearkitektur, der leveres som en service. I betragtning af at objektlagring faktisk er cloud-lagring, bliver denne evne kritisk, når objektlagring bruges af cloud-baserede applikationer.
Endelig skal S3-implementeringen understøtte Amazon S3 server-side krypterings-API'er: SSE-C, SSE-S3, SSE-KMS. Endnu bedre, S3 understøtter manipulationsbeskyttelse, der er virkelig sikker.
Reaktion på fejl
En metrik, der sandsynligvis ofte overses, er, hvordan systemet håndterer fejl. Fejl sker af forskellige årsager, og objektlagring skal håndtere dem alle.
For eksempel er der et enkelt fejlpunkt, metrikken for dette er nul.
Desværre bruger mange objektlagringssystemer specielle noder, der skal aktiveres for at klyngen kan fungere korrekt. Disse omfatter navnenoder eller metadataservere - dette skaber et enkelt fejlpunkt.
Selv hvor der er flere fejlpunkter, er evnen til at modstå katastrofale fiaskoer altafgørende. Diske fejler, servere fejler. Nøglen er at skabe software designet til at håndtere fejl som en normal tilstand. Hvis en disk eller node fejler, vil sådan software fortsætte med at fungere uden ændringer.
Indbygget beskyttelse mod sletning af data og datanedbrydning sikrer, at du kan miste lige så mange diske eller noder, som du har paritetsblokke - normalt halvdelen af diskene. Først da vil softwaren ikke være i stand til at returnere data.
Fejlen testes sjældent under belastning, men en sådan test er påkrævet. Simulering af et belastningssvigt vil vise de samlede omkostninger, der er påløbet efter fejlen.
Konsistens
En konsistensscore på 100% kaldes også streng konsistens. Konsistens er en nøglekomponent i ethvert opbevaringssystem, men stærk konsistens er sjælden. For eksempel er Amazon S3 ListObject ikke strengt konsistent, det er kun konsistent i slutningen.
Hvad menes der med streng konsistens? For alle operationer efter en bekræftet PUT-operation skal følgende ske:
- Den opdaterede værdi er synlig, når du læser fra en hvilken som helst node.
- Opdateringen er beskyttet mod redundans for knudefejl.
Det betyder, at hvis du trækker stikket ud midt i en optagelse, vil der ikke gå noget tabt. Systemet returnerer aldrig beskadigede eller forældede data. Dette er en høj bar, der betyder noget i mange scenarier, fra transaktionsapplikationer til backup og gendannelse.
Konklusion
Disse er nye objektlagringsmetrikker, der afspejler brugsmønstre i nutidens organisationer, hvor ydeevne, konsistens, skalerbarhed, fejldomæner og S3-kompatibilitet er byggestenene til cloud-applikationer og big data-analyse. Jeg anbefaler at bruge denne liste ud over prisen, når du bygger moderne datastabler.
Om Mail.ru Cloud Solutions objektlagring: .
Hvad skal man ellers læse:
- .
- .
- .
Kilde: www.habr.com