S3-lagringsobjektteamet har översatt en artikel om vilka kriterier som är viktiga vid val av lagringsobjekt. Här är texten från författaren.
När det kommer till lagringsobjekt tänker folk oftast bara på en egenskap — priset per TB/GB. Självklart är denna metrik viktig, men den ger en ensidig syn och likställer lagringsobjekt med ett verktyg för arkivering. Dessutom minskar detta synen på lagringsobjektets betydelse inom företagets teknologiska stack.
När du väljer lagringsobjekt bör du fokusera på fem egenskaper:
- prestanda;
- skalbarhet;
- kompatibilitet med S3;
- återhämtningsförmåga;
- integritet.
Dessa fem egenskaper är nya metrik för lagringsobjekt, i likhet med kostnad. Låt oss titta på dem alla.
Performance
Traditionella lagringsobjekt utmärker sig inte genom prestanda. Tjänsteleverantörer har ständigt offrat prestanda i jakten på låga priser. Men med moderna lagringsobjekt är det annorlunda.
Hastigheten för olika lagringslösningar närmar sig Hadoop eller till och med överträffar den. Moderna krav på läs- och skrivhastighet: från 10 GB/s för hårddiskar till 35 GB/s för NVMe.
Denna bandbredd är tillräcklig för Spark, Presto, Tensorflow, Teradata, Vertica, Splunk och andra moderna beräkningsramverk inom analys. Det faktum att MPP-databaser konfigureras för lagringsobjekt visar att det allt mer används som huvudlagring.
Om ditt lagringssystem inte kan tillhandahålla den önskade hastigheten, kan du inte använda data och extrahera värde från dem. Även om du extraherar data från lagringsobjekt till en minnesbearbetningsstruktur, krävs det fortfarande bandbredd för att överföra data till och från minnet. Det finns inte tillräckligt med det i föråldrade lagringsobjekt.
Detta är en nyckelpunkt: den nya prestandametriken är bandbredd, inte latens. Det behövs för skalbara data, och det är normen i modern datainfrastruktur.
Även om prestandatestning är ett bra sätt att avgöra prestanda kan den inte mätas exakt förrän applikationen körs i miljön. Endast efter detta kan man se var flaskhalsen finns: i programvaran, diskarna, nätverket eller på beräkningsnivå.
Skalbarhet
Med skalbarhet avses mängden petabyte som får plats i ett namnrymd. Leverantörer påstår att deras skalbarhet är enkel, men de målar över att massiva monolitiska system blir sköra, komplexa, instabila och dyra när de skalas.
Den nya metriska skalbarheten är antalet namnrymder eller kunder som du kan betjäna. Metriken hämtas direkt från hyperskalare, där byggstenarna är små men kan skalas upp till miljarder enheter. I allmänhet är detta en molnmetrik.
När standardblocken är små är det lättare att optimera dem, vilket innebär att säkerhet, åtkomstkontroll, policyhantering, livscykel och uppdateringar kan hanteras utan avbrott. Och i slutändan säkerställs prestandan. Storleken på byggstenen är en funktion av hanterbarheten i felområdet, detta är hur högätande system byggs.
Multitenancy har många egenskaper. Även om parameterna handlar om hur organisationer ger åtkomst till data och applikationer, relaterar de också till själva applikationerna och logiken för deras isolering från varandra.
Egenskaper hos den moderna synen på multitenancy:
- Under kort tid kan antalet kunder öka från några hundra till flera miljoner.
- Kunderna är helt isolerade från varandra. Detta gör att de kan köra olika versioner av samma mjukvara och lagra objekt med olika konfigurationer, behörigheter, funktioner, säkerhetsnivåer och kundservice. Detta är nödvändigt när nya servrar, uppdateringar och geografiska regioner skalas.
- Lagringen skalas elastiskt, resurser tillhandahålls på begäran.
- Varje operation hanteras av API och automatiseras utan mänsklig inblandning.
- Mjukvara kan placeras i containrar och använda standardiserade orkestreringssystem, som Kubernetes.
Kompatibilitet med S3
Amazon S3 API — den faktiska standarden för objektrepositorier. Varje leverantör av programvara för objektrepositorier påstår sig vara kompatibel med den. Kompatibilitet med S3 är binär: antingen är den fullt implementerad eller så är den inte det.
I praktiken kan det uppstå hundratals och tusentals gränsscenarier där något går fel vid användning av objektrepositorier. Detta är särskilt fallet med leverantörer av proprietär programvara och tjänster. Dess primära användningsscenarier är direkt arkivering eller säkerhetskopiering, så antalet orsaker till att anropa API:et är få och användningsfallen är homogena.
Stora fördelar med programvara med öppen källkod. Den täcker de flesta gränsscenarier med hänsyn till storlek och mångfald av applikationer, operativsystem och hårdvaruarkitektur.
Allt detta är viktigt för applikationsutvecklare, så det är värt att testa applikationens funktionalitet med lagringsleverantörer. Öppen källkod förenklar processen — det blir lättare att förstå vilken plattform som passar din applikation. Leverantören kan användas som en enda ingångspunkt till lagringslösningar, vilket innebär att den tillgodoser dina behov.
Öppen källkod betyder: applikationer är inte låsta till en specifik leverantör och är mer transparenta. Detta säkerställer en lång livslängd för applikationen.
Och några ytterligare kommentarer om öppen källkod och S3.
Om du kör en applikation för att hantera stora datamängder, ökar S3 SELECT prestandan och effektiviteten avsevärt. Detta beror på användningen av SQL för att extrahera endast de objekt som du behöver från lagringslösningen.
En nyckelpunkt är stödet för bucket-notifieringar. Bucket-notifieringar förenklar serverlösa beräkningar — en viktig komponent i varje mikrotjänstarkitektur som erbjuds som en tjänst. Med tanke på att objektrepositoriet i praktiken är en molnlagring gör denna funktionalitet det avgörande när molnapplikationer använder objektrepositorier.
Slutligen bör implementeringen av S3 stödja Amazon S3 API-gränssnitt för kryptering på serversidan: SSE-C, SSE-S3, SSE-KMS. Ännu bättre är om S3 stöder skydd mot obehörig åtkomst som verkligen är säkert.
Reaktion på fel
En indikator som troligtvis ofta förbises är hur systemet hanterar fel. Misslyckanden kan inträffa av olika anledningar, och objektlagret måste hantera dem alla.
Till exempel finns det en enda felpunkt, och mätningen för detta är noll.
Tyvärr använder många objektlagringssystem speciella noder som måste aktiveras för att klustret ska fungera korrekt. Detta inkluderar namn-noder eller metadata-servrar, vilket skapar en enda felpunkt.
Även där det finns flera felpunkter är förmågan att hantera katastrofala fel av yttersta vikt. Disken kan gå sönder, servrar kan falla. Nyckeln är att skapa programvara avsedd att hantera fel som ett normalt tillstånd. Vid disk- eller nodfel kommer sådan mjukvara att fortsätta fungera utan förändringar.
Inbyggt skydd mot radering och nedbrytning av data garanterar: du kan förlora så många diskar eller noder som du har paritet-block — vanligtvis hälften av diskarna. Endast då kan mjukvaran inte återföra data.
Fel brukar sällan testas under belastning, men sådan testning är nödvändig. Simulering av fel under belastning kommer att visa de totala kostnader som uppstår efter ett fel.
Konsistens
En konsistensindikator på 100 % kallas också strikt konsistens. Konsistens är en nyckelkomponent i alla lagringssystem, men strikt konsistens förekommer ganska sällan. Till exempel är Amazon S3 ListObject inte strikt konsistent, det är endast konsistent i slutet.
Vad menas med strikt konsistens? För alla operationer efter en bekräftad PUT-operation måste följande uppfyllas:
- Det uppdaterade värdet är synligt när det läses från vilken nod som helst.
- Uppdateringen är skyddad genom redundans mot nodfel.
Detta innebär: om man drar ut kontakten mitt under en skrivning förloras ingenting. Systemet återlämnar aldrig skadade eller föråldrade data. Detta är en hög standard som har betydelse för många scenarier: från transaktionsapplikationer till säkerhetskopiering och återställning.
Slutsats
Detta är nya metoder för objektlagring som återspeglar användningsmönster i moderna organisationer där prestanda, konsekvens, skalbarhet, felområden och kompatibilitet med S3 är byggstenar för molnapplikationer och big data-analyser. Jag rekommenderar att använda denna lista i kombination med priset vid skapandet av moderna datastack.
Om objektlagring Mail.ru Cloud Solutions: .
Vad mer att läsa:
- .
- .
- .
Källa: habr.com
