Vilka krav bör ställas på lagringskapacitet och prestanda?

Utgå från användningsområde och livslängd

Digital lagring fyller tre funktioner, och kraven på kapacitet och prestanda skiljer sig beroende på vilken som avses. Enligt guiden Digital arkivering på statensarkiv.se är lagring att förvara filer någonstans, utan garanti för ordning eller framtida läsbarhet. Backup är en säkerhetskopia för att kunna återställa material om något går fel, ofta kortlivad. Arkivering är långsiktigt bevarande med struktur, metadata och plan, så att informationen förblir användbar.

Kravspecifikationen börjar med tre frågor: Ska materialet bearbetas snabbt, med krav på svarstider och I/O-prestanda? Ska det kunna återställas efter en krasch, med krav på återställningstid, återställningspunkt och regelbundet testad återläsning? Eller ska det bevaras läsbart över tid, med krav på format, metadata och migreringsplan? Samma fil kan behöva uppfylla alla tre behoven, men kraven skrivs separat för varje ändamål.

Blanda inte ihop funktionerna i upphandlingen. Bevarandekraven ska ställas vid sidan av kraven på produktionslagring och backup, inte som en bilaga till dem.

Lagring, backup och arkivering – tre olika krav

Kapacitetsplanering: mät behov och planera för tillväxt

Kapacitetsbehovet fastställs genom analys av arbetsbelastningarna och löpande övervakning av resursanvändningen. Metodtipset för Azure Databricks-arkitektur är att analysera arbetsbelastningar och övervaka resursanvändningen för att avgöra hur mycket beräkning och lagring som behövs.

Mät minst fyra storheter över tid: lagrad datamängd och dess tillväxttakt, fördelningen mellan aktivt och kallt material enligt gällande retention, antalet samtidiga användare eller samtidiga jobb, och de batch- eller bearbetningsfönster inom vilka arbetet måste vara klart. Retentionen måste räknas in i kapacitetskalkylen: material som ska behållas i många år fortsätter att belasta lagringen även sedan det slutat användas aktivt.

Vid storskalig dokumenthantering dimensioneras systemet inte enbart av lagringsvolymen. En genomgång av prestandaoptimering för storskalig dokumenthantering beskriver strategier och metoder utifrån flera dimensioner såsom databehandling, lagring, nätverk och cachning. Ställ därför krav på att leverantören redovisar en kapacitetsplan som omfattar samtliga fyra, inte bara diskyta.

Prestandakrav som måste vara mätbara

Ett användbart prestandaindex delar in mätetalen i fyra grupper. Här behandlas tre av dem – genomströmning, svarstid och resurseffektivitet – medan den fjärde, skalbarhet, behandlas i nästa avsnitt. Genomströmning: antal dokument som bearbetas per sekund, dataöverföringshastighet, samtidig bearbetningskapacitet och resursanvändning. Svarstid: end-to-end-latens, bearbetningslatens, nätverkslatens och köväntetid. Resurseffektivitet: CPU-användning, minnesanvändning, storage IOPS och nätverksbandbreddsutnyttjande. Indelningen kan användas direkt som rubricering i kravspecifikationen, utan att några fasta tröskelvärden behöver hämtas utifrån.

Varje prestandakrav ska anges med mätmetod och mätvillkor: vilken datamängd som bearbetas, hur många samtidiga jobb som körs, vilken typ av beräkningsresurs som används, om kravet gäller medelvärde eller en percentil, samt mätperiodens längd. Utan mätvillkoren går det inte att avgöra om ett uppmätt värde uppfyller kravet eller bara speglar en tillfälligt låg belastning.

Resurseffektiviteten bör vara ett eget krav och inte bara en konsekvens av svarstiderna. Ett system kan uppfylla latenskraven och samtidigt förbruka CPU, minne, IOPS och nätverksbandbredd så att kostnaden per bearbetat dokument blir oproportionerlig. Ange därför trösklar för utnyttjandegraden vid normal drift och vad som ska hända när de överskrids.

Prestandakrav: mätetal i tre grupper

Flaskhalsar i lagring, nätverk och beräkning

Flaskhalsanalysen delas lämpligen i tre kategorier. Beräkningsflaskhalsar: CPU-intensiva uppgifter som bildbehandling eller modellinferens, algoritmisk komplexitet i tid och rum, otillräcklig parallellism på grund av seriell bearbetning samt resurskonkurrens mellan samtidiga uppgifter. Lagringsflaskhalsar: prestanda för disk-I/O, lagringskapacitet för stora filer, databasprestanda vid frågor och transaktioner samt nätverkslagringslatens vid distribuerad lagring. Nätverksflaskhalsar: bandbreddsgräns, fördröjningar i överföringen och maximalt antal anslutningar.

Kräv att leverantören dokumenterar vilka kvoter och gränser som gäller för tjänsten. Be om en förteckning över vilka av dessa gränser som är relevanta för den egna lösningen och hur de övervakas innan de nås. De styrande tjänstbegränsningarna beskrivs närmare i avsnittet Skalbarhet.

Be också om en beskrivning av vad som går sönder först när en flaskhals slår till. Vid mättnad av disk-I/O, databas eller nätverksbandbredd är det avgörande att veta vilka funktioner som degraderas – batchkörningar, interaktiva sökningar eller inlämning av nya dokument – och vilka larm som utlöses. Det svaret hör hemma i kravspecifikationen som en obligatorisk bilaga, inte som marknadsföringsmaterial.

Tre kategorier av flaskhalsar

Skalbarhet och kapacitetsgränser

Skalbarhet bör preciseras i fyra begrepp. Horisontell skalbarhet: möjligheten att förbättra prestandan genom att lägga till noder. Vertikal skalbarhet: möjligheten att förbättra prestandan genom att uppgradera hårdvaran. Linjär skalbarhet: hur sambandet ser ut mellan prestandaförbättring och resursinvestering. Expansionsflaskhalsar: de faktorer som begränsar systemets expansion.

Konkreta kvoter måste ingå i kraven. Metodtipset för Azure Databricks beskriver att tjänstgränserna direkt begränsar arbetsbelastningens tillförlitlighet genom beräkningskluster, arbetsytekapacitet, lagringsdataflöde och begränsningar i nätverksbandbredd, och att arkitekturen proaktivt måste införliva kvoterna för att förhindra oväntade tjänstestörningar som kan stoppa skalningsåtgärder under hög efterfrågan. Metodtipset nämner också en klustergräns på 1 000 noder, ett maximalt antal arbetsytekluster och begränsningar i regional kapacitet. Kräv att det av anbudet framgår vilka kvoter som kan bli styrande, vem som ansvarar för att begära höjning och med vilken framförhållning.

Verifiera skalbarheten med tester vid flera belastningsnivåer och begär kurvan, inte ett enskilt mätvärde: hur förändras genomströmning och svarstid när antalet samtidiga jobb eller noder fördubblas, och var planar kurvan ut?

Exempel på styrande kvot: Azure Databricks

• Klustergräns — 1 000 noder

Tillförlitlighet, redundans och felhantering

Tillförlitlighetskrav syftar till att upprätthålla funktionaliteten genom att bygga upp tillräcklig motståndskraft och förmåga att snabbt återhämta sig från fel. En systematisk fellägeanalys (FMA) identifierar potentiella systemfel och fastställer motsvarande åtgärder för att upprätthålla motståndskraften i distribuerad databehandling.

Ställ krav på åtgärderna per felscenario, inte bara på att fel ska hanteras. För nodfel på klusterdrivnoden anger metodtipset automatisk omstart av kluster, kontrollpunkter för program och strukturerad direktuppspelning med feltolerant tillståndshantering. För fel i jobbkörningar anges återförsöksprinciper med exponentiell backoff, jobborkestrering med felhantering samt konfigurerade återförsöksvillkor. Kräv att motsvarande mekanismer är dokumenterade och testade för den egna miljön.

Skilj på driftssäkerhet och bevarande. Automatisk omstart, kontrollpunkter och återförsök skyddar den pågående driften och förkortar avbrott, men de gör inte materialet långsiktigt läsbart. Bevarandekraven beskrivs i avsnittet Bevarandekrav.

Felhantering per felscenario

Bevarandekrav: metadata, format och dokumentation

Digital arkivering handlar om att bevara information så att den går att hitta, läsa, förstå och lita på även långt senare. Enligt guiden på statensarkiv.se räcker det inte att lägga filer i en mapp, på en server eller i en molntjänst: för att något verkligen ska vara arkiverat krävs ordning, metadata, dokumentation och en plan för hur materialet ska kunna användas också när dagens system har bytts ut.

Ett dokument är mer än själva filen. För att en handling ska gå att förstå och lita på i framtiden kan den behöva uppgifter om vem som skapade den, när den skapades, vilken version det är, vilket system den kommer från och hur den har använts – informationen får inte skiljas från sitt sammanhang. Kravspecifikationen bör därför ange vilka metadatafält som ska fångas per handlingstyp, när de skapas och hur de följer med vid export.

Som referensram finns OAIS-referensmodellen (ISO 14721), bevarandemetadatastandarderna PREMIS och METS samt Riksarkivets föreskrifter om elektroniska handlingar, RA-FS 2009:1 och 2009:2, med bevarandeformat som PDF/A och TIFF. RA-FS 2009:1 handlar om en strategi och bevarandeplan för det digitala materialet. Riksarkivets sida Elektroniska handlingar samlar dessutom krav, rekommendationer, vägledningar och stöd för att framställa elektroniska handlingar med hänsyn till bevarandebehovet.

Gör bevarandekraven konkreta: vilka format som tillåts för respektive handlingstyp, hur filformat kontrolleras vid inlämning, vilken metadata som är obligatorisk, hur systemberoenden och dokumentation beskrivs, vem som ansvarar för migrering och hur ofta läsbarheten verifieras genom att materialet öppnas i ett annat system än det som skapade det.

Bevarandekrav i praktiken

Kravspecifikation och uppföljning

Skriv varje krav med fem delar: mätetal, mätvillkor, mätmetod, tröskelvärde och intervall för uppföljning. Ett krav på genomströmning utan angiven datamängd och samtidighet, eller ett krav på svarstid utan angiven percentil, går inte att verifiera och blir därför inte styrbart i avtalet.

Koppla kraven till övervakning och kvoter. Kräv att övervakningen larmar i god tid före de gränser som identifierats i avsnittet Skalbarhet, inte när de redan passerats.

Följ upp i två spår. Prestanda och kapacitet följs upp med återkommande belastningstester och avläsning av resursutnyttjande mot de trösklar som satts. Bevarandet följs upp med en bevarandeplan enligt RA-FS 2009:1 och med kontroller av att exporterat material kan hittas, läsas, förstås och verifieras oberoende av det ursprungliga systemet.

Fem delar i varje krav