S3-objektsopbevaringsholdet har oversat artiklen om, hvilke kriterier der er vigtige, når man vælger objektsopbevaring. Her er teksten fra forfatterens synspunkt.
Når der tales om objektsopbevaring, tænker folk som regel kun på én egenskab — prisen per TB/GB. Selvfølgelig er denne måling vigtig, men den gør tilgangen ensidig og ligestiller objektsopbevaring med et redskab til arkivering. Desuden reducerer en sådan tilgang vigtigheden af objektsopbevaring i virksomhedens teknologistak.
Når man vælger objektsopbevaring, er der fem egenskaber, man bør være opmærksom på:
- ydelse;
- skalerbarhed;
- kompatibilitet med S3;
- reaktion på fejl;
- integritet.
Disse fem egenskaber er nye målinger for objektsopbevaring, ligesom omkostninger. Lad os se nærmere på dem alle.
Ydeevne
Traditionelle objektsopbevaringssystemer skiller sig ikke ud med hensyn til ydelse. Udbydere har konstant ofret den i jagten på lave priser. Men med moderne objektsopbevaring er det anderledes.
Hastigheden for forskellige opbevaringsløsninger nærmer sig Hadoop eller endda overgår den. Moderne krav til læse- og skrivehastighed: fra 10 GB/s for harddiske op til 35 GB/s for NVMe.
Sådan en båndbredde er tilstrækkelig til Spark, Presto, Tensorflow, Teradata, Vertica, Splunk og andre moderne beregningsrammeværk i analysetech. Det faktum, at MPP-databaser konfigureres til objektsopbevaringssystemer, indikerer, at det i stigende grad bruges som hovedopbevaringssystem.
Hvis dit opbevaringssystem ikke leverer den nødvendige hastighed, kan du ikke bruge dataene og udtrække værdier fra dem. Selv hvis du overfører data fra objektsopbevaringen til en hukommelsesbehandlingsstruktur, kræves der stadig båndbredde til at sende data til og fra hukommelsen. De forældede objektsopbevaringssystemer har ikke tilstrækkelig kapacitet.
Dette er et centralt punkt: den nye ydelsesmåling er båndbredde, ikke latens. Den er nødvendig for skalerbare data, og det er normen i moderne datainfrastruktur.
Selv om ydeevnetests er en god metode til at bestemme ydeevne, kan den ikke præciseres nøjagtigt før applikationen kører i et miljø. Først derefter kan man sige, hvor flaskehalsen virkelig er: i softwaren, på disken, i netværket eller på beregningsniveau.
Skalering
Skalerbarhed refererer til antallet af petabyte, der kan rumme i et enkelt namespaces. Leverandører hævder, at skalerbarhed er let, men nævner ikke, at massive monolitiske systemer bliver skrøbelige, komplekse, ustabile og dyre, efterhånden som de skaleres.
Den nye måleenhed for skalerbarhed er antallet af namespaces eller kunder, du kan betjene. Metric tages direkte fra hyperscalers, hvor byggeklodserne til opbevaring er små, men kan skaleres op til milliarder enheder. Generelt er det en cloud-metrik.
Når standardblokke har små dimensioner, er de lettere at optimere, hvilket vil sige at sikre sikkerhed, adgangskontrol, politikhåndtering, livscyklus og opdateringer uden nedetid. Og i sidste ende sikre ydeevne. Størrelsen af byggeklodsen er en funktion af håndterbarheden af fejltoleransområdet; sådan bygges højtilgængelige systemer.
Multikundskab har mange karakteristika. Selvom parameteren handler om, hvordan organisationer giver adgang til data og applikationer, handler det også om selve applikationerne og den logik, der isolerer dem fra hinanden.
Egenskaber ved den moderne tilgang til multikundskab:
- På kort tid kan antallet af kunder vokse fra flere hundrede til flere millioner.
- Kunderne er helt isolerede fra hinanden. Dette gør det muligt for dem at køre forskellige versioner af den samme software og opbevare objekter med forskellige konfigurationer, tilladelser, funktioner, sikkerheds- og supportniveauer. Dette er nødvendigt, når nye servere, opdateringer og geografiske regioner skaleres.
- Lageret kan skaleres elastisk, og ressourcer leveres efter behov.
- Hver operation styres af API og automatiseres uden menneskelig indblanding.
- Software kan placeres i containere og bruge standard orkestreringssystemer som Kubernetes.
Kompatibilitet med S3
Amazon S3 API er i praksis standarden for objektlagring. Hver softwareleverandør for objektlagring hævder at være kompatibel med det. Kompatibilitet med S3 er binær: den er enten fuldt implementeret, eller også er den ikke.
I praksis kan der opstå hundrede og tusinde grænse-scenarier, når noget går galt ved brug af objektlagring. Især hos leverandører af proprietær software og tjenester. Dens primære anvendelsesscenarier er direkte arkivering eller backup, derfor er der ikke mange grunde til at kalde API'en, og brugsmulighederne er ensartede.
Der er betydelige fordele ved open source-software. Den dækker de fleste grænse-scenarier og tager højde for størrelsen og variabiliteten af applikationer, operativsystemer og hardwarearkitektur.
Alt dette er vigtigt for applikationsudviklere, så det er værd at teste applikationens funktionalitet med udbydere af lagringsløsninger. Open source forenkler processen — det er lettere at forstå, hvilken platform der passer til din applikation. Udbyderen kan bruges som et enkelt indgangspunkt til lagringsløsninger — hvilket betyder, at det vil opfylde dine behov.
Open source betyder: applikationer er ikke bundet til en bestemt leverandør og er mere gennemsigtige. Dette sikrer en lang livscyklus for applikationen.
Og et par flere bemærkninger om open source og S3.
Hvis du kører en applikation til store data, forbedrer S3 SELECT ydeevnen og effektiviteten betydeligt. Dette sker ved at anvende SQL til kun at hente de objekter fra lagringen, som du har brug for.
Et centralt punkt er understøttelsen af bucket-notifikationer. Bucket-notifikationer forenkler serverløs computing — en vigtig komponent i enhver mikroservice-arkitektur, der tilbydes som en tjeneste. Da objektlagring i virkeligheden er cloud-lagring, bliver denne funktion afgørende, når cloud-applikationer bruger objektlagring.
Endelig skal implementeringen af S3 understøtte Amazon S3 API-grænseflader til kryptering på serversiden: SSE-C, SSE-S3, SSE-KMS. Det er endnu bedre, hvis S3 understøtter beskyttelse mod uautoriseret adgang, som virkelig er sikker.
Reaktion på fejl
En indikator, som sandsynligvis ofte overses, er, hvordan systemet håndterer fejl. Fejl opstår af forskellige årsager, og objektlageret skal kunne håndtere dem alle.
For eksempel er der et enkelt fejlpunk, og denne metrisk er nul.
Desværre bruger mange objektslagringssystemer specialnoder, der skal aktiveres for, at klyngen fungerer korrekt. Det inkluderer navnenoder eller metadata-servere — hvilket skaber et enkelt fejlpunk.
Selv der, hvor der er flere fejlpunkter, er evnen til at modstå katastrofale fejl afgørende. Drev svigter, servere fejler. Nøglen er at skabe software, der er designet til at håndtere fejl som en normal tilstand. Når et drev eller en node svigter, vil denne software fortsætte med at fungere uden ændringer.
Indbygget beskyttelse mod sletning og datadegradering sikrer: du kan miste så mange drev eller noder, som du har paritetsblokke — normalt halvdelen af drevene. Først da kan softwaren ikke returnere data.
Fejl bliver sjældent testet under belastning, men sådan en test er obligatorisk. Simulering af fejl under belastning vil vise de samlede omkostninger, der påløber efter fejlen.
Konsistens
En konsistensmåling på 100% kaldes også streng konsistens. Konsistens er en nøglekomponent i enhver lagersystem, men streng konsistens er ret sjældent. For eksempel er Amazon S3 ListObject ikke strengt konsistent, det er kun konsistent til slut.
Hvad menes der med streng konsistens? For alle operationer efter en bekræftet PUT-operation skal følgende gælde:
- Den opdaterede værdi er synlig ved læsning fra enhver node.
- Opdateringen er beskyttet mod nodefejl ved hjælp af redundans.
Det betyder: hvis stikket trækkes midt i en skrivning, vil der ikke gå noget tabt. Systemet returnerer aldrig beskadigede eller forældede data. Dette er en høj standard, der er vigtig i mange scenarier: fra transaktionelle applikationer til backup og gendannelse.
Konklusion
Dette er nye metrikker for objektlagring, der afspejler brugsmønstre i moderne organisationer, hvor ydeevne, konsistens, skalerbarhed, fejltolerance og S3-kompatibilitet er byggestenene for cloud-applikationer og big data-analyse. Jeg anbefaler at bruge denne liste sammen med prisen, når du opretter moderne datastakke.
Om objektlagring i Mail.ru Cloud Solutions: .
Yderligere læsning:
- .
- .
- .
Kilde: habr.com
