S3 objektlagringskommando översatt en artikel om vilka kriterier som är viktiga vid val av objektlagring. Följande är texten ur författarens perspektiv.
När det kommer till objektlagring tänker folk vanligtvis bara på en sak: priset per TB/GB. Naturligtvis är detta mått viktigt, men det gör tillvägagångssättet ensidigt och likställer objektlagring med ett arkivlagringsverktyg. Dessutom minskar detta tillvägagångssätt vikten av objektlagring för företagsteknologistacken.
När du väljer objektförvaring bör du vara uppmärksam på fem egenskaper:
- prestanda;
- skalbarhet;
- S3-kompatibel;
- svar på misslyckanden;
- integritet.
Dessa fem egenskaper är nya mätvärden för objektlagring, tillsammans med kostnad. Låt oss titta på dem alla.
Производительность
Traditionella föremålsbutiker saknar prestanda. Tjänsteleverantörer offrade det hela tiden i jakten på låga priser. Men med modern objektförvaring är saker och ting annorlunda.
Olika lagringssystem närmar sig eller till och med överskrider Hadoops hastighet. Moderna krav på läs- och skrivhastigheter: från 10 GB/s för hårddiskar, upp till 35 GB/s för NVMe.
Denna genomströmning är tillräcklig för Spark, Presto, Tensorflow, Teradata, Vertica, Splunk och andra moderna beräkningsramverk i analysstacken. Det faktum att MPP-databaser konfigureras för objektlagring tyder på att den i allt högre grad används som primär lagring.
Om ditt lagringssystem inte ger den hastighet du behöver kan du inte använda data och extrahera värde från den. Även om du hämtar data från objektlagring till en bearbetningsstruktur i minnet behöver du fortfarande bandbredd för att överföra data till och från minnet. Äldre objektbutiker har inte tillräckligt med det.
Detta är nyckelpunkten: det nya prestandamåttet är genomströmning, inte latens. Det krävs för data i stor skala och är normen i modern datainfrastruktur.
Även om riktmärken är ett bra sätt att fastställa prestanda, kan det inte mätas exakt innan programmet körs i miljön. Först efter det kan du säga exakt var flaskhalsen är: i programvara, diskar, nätverk eller på datornivå.
Skalbarhet
Skalbarhet hänvisar till antalet petabyte som passar in i ett namnområde. Vad leverantörer hävdar är enkel skalbarhet, vad de inte säger är att när de skalas blir massiva monolitiska system ömtåliga, komplexa, instabila och dyra.
Det nya måttet för skalbarhet är antalet namnområden eller klienter som du kan betjäna. Metriken är hämtad direkt från hyperscalers, där lagringsbyggstenarna är små men skala till miljarder enheter. I allmänhet är detta ett molnmått.
När byggstenarna är små är de lättare att optimera för säkerhet, åtkomstkontroll, policyhantering, livscykelhantering och icke-störande uppdateringar. Och i slutändan säkerställa produktiviteten. Byggstenens storlek är en funktion av felregionens styrbarhet, vilket är hur högfjädrande system byggs.
Flerbostad har många egenskaper. Även om dimensionen talar om hur organisationer ger tillgång till data och applikationer, hänvisar den också till själva applikationerna och logiken bakom att isolera dem från varandra.
Kännetecken för ett modernt förhållningssätt till multiklient:
- På kort tid kan antalet kunder växa från flera hundra till flera miljoner.
- Kunderna är helt isolerade från varandra. Detta gör att de kan köra olika versioner av samma programvara och lagra objekt med olika konfigurationer, behörigheter, funktioner, säkerhets- och underhållsnivåer. Detta är nödvändigt när du skalar till nya servrar, uppdateringar och geografier.
- Lagringen är elastiskt skalbar, resurser tillhandahålls på begäran.
- Varje operation styrs av ett API och automatiseras utan mänsklig inblandning.
- Programvara kan lagras i behållare och använda standardsystem för orkestrering som Kubernetes.
S3-kompatibel
Amazon S3 API är de facto standarden för objektlagring. Varje leverantör av programvara för objektlagring hävdar kompatibilitet med den. Kompatibiliteten med S3 är binär: antingen är den helt implementerad eller så är den inte det.
I praktiken finns det hundratals eller tusentals kantscenarier där något går fel när man använder objektlagring. Särskilt från leverantörer av proprietär programvara och tjänster. Dess huvudsakliga användningsfall är direkt arkivering eller säkerhetskopiering, så det finns få anledningar att anropa API:t, användningsfallen är homogena.
Programvara med öppen källkod har betydande fördelar. Den täcker de flesta kantscenarier, med tanke på storleken och variationen av applikationer, operativsystem och hårdvaruarkitekturer.
Allt detta är viktigt för applikationsutvecklare, så det är värt att testa applikationen med lagringsleverantörer. Öppen källkod gör processen enklare – det är lättare att förstå vilken plattform som är rätt för din applikation. Leverantören kan användas som en enda ingång till lagring, vilket innebär att den kommer att möta dina behov.
Öppen källkod betyder: applikationer är inte knutna till en leverantör och är mer transparenta. Detta säkerställer en lång applikationslivscykel.
Och några fler anteckningar om öppen källkod och S3.
Om du kör en big data-applikation förbättrar S3 SELECT prestanda och effektivitet med en storleksordning. Den gör detta genom att använda SQL för att bara hämta de objekt du behöver från lagringen.
Nyckelpunkten är stöd för bucket-meddelanden. Bucket-meddelanden underlättar serverlös datoranvändning, en viktig komponent i alla mikrotjänstarkitekturer som levereras som en tjänst. Med tanke på att objektlagring i själva verket är molnlagring, blir denna förmåga kritisk när objektlagring används av molnbaserade applikationer.
Slutligen måste S3-implementeringen stödja Amazon S3-krypterings-API:er på serversidan: SSE-C, SSE-S3, SSE-KMS. Ännu bättre, S3 stöder manipuleringsskydd som är verkligen säkert.
Svar på misslyckanden
Ett mått som förmodligen ofta förbises är hur systemet hanterar fel. Fel inträffar av en mängd olika anledningar, och objektlagring måste hantera dem alla.
Till exempel finns det en enda punkt av fel, måtten 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. Dessa inkluderar namnnoder eller metadataservrar - detta skapar en enda felpunkt.
Även där det finns flera punkter av misslyckande är förmågan att motstå katastrofala misslyckanden av största vikt. Diskar misslyckas, servrar misslyckas. Nyckeln är att skapa programvara utformad för att hantera fel som ett normalt tillstånd. Om en disk eller nod misslyckas kommer sådan programvara att fortsätta att fungera utan ändringar.
Inbyggt skydd mot dataradering och dataförsämring säkerställer att du kan förlora lika många diskar eller noder som du har paritetsblock – vanligtvis hälften av diskarna. Först då kommer programvaran inte att kunna returnera data.
Felet testas sällan under belastning, men sådan testning krävs. Simulering av ett lastfel visar de totala kostnaderna som uppstått efter felet.
Konsistens
Ett konsistenspoäng på 100 % kallas även strikt konsistens. Konsistens är en nyckelkomponent i alla lagringssystem, men stark konsistens är sällsynt. Till exempel är Amazon S3 ListObject inte strikt konsekvent, det är bara konsekvent i slutet.
Vad menas med strikt konsekvens? För alla operationer efter en bekräftad PUT-operation måste följande ske:
- Det uppdaterade värdet är synligt vid läsning från valfri nod.
- Uppdateringen är skyddad mot redundans för nodfel.
Det betyder att om du drar i kontakten mitt under en inspelning så kommer ingenting att gå förlorat. Systemet returnerar aldrig skadad eller inaktuell data. Detta är en hög nivå som är viktig i många scenarier, från transaktionsapplikationer till säkerhetskopiering och återställning.
Slutsats
Det här är nya objektlagringsmått som speglar användningsmönster i dagens organisationer, där prestanda, konsekvens, skalbarhet, feldomäner och S3-kompatibilitet är byggstenarna för molnapplikationer och big data-analys. Jag rekommenderar att du använder den här listan utöver priset när du bygger moderna datastackar.
Om Mail.ru Cloud Solutions objektlagring: .
Vad mer att läsa:
- .
- .
- .
Källa: will.com