Hvad er lagringstest? Typer, Concepts & Eksempel
Thomas Hamilton
⚡ Smart opsummering
Lagringstestning verificerer, at en applikation skriver sine data til de korrekte mapper og har tilstrækkelig diskplads til at undgå uventede afslutninger, samtidig med at den måler, hvor hurtigt den underliggende lagring reagerer under realistisk belastning.
Hvad er lagringstest?
Opbevaringstest er en type softwaretestning, der bruges til at verificere, om den softwareapplikation, der testes, lagrer de relevante data i de relevante mapper, og om den har tilstrækkelig plads til at forhindre uventede afbrydelser på grund af utilstrækkelig diskplads. Det kaldes også test af lagerydelse.
Teknikken ligger på den ikke-funktionelle side af disciplinen: ligesom andre former for ikke-funktionel testning, siger det intet om, hvorvidt en funktion producerer det rigtige svar, og alt om, hvorvidt systemet kan fortsætte med at producere svar, efterhånden som datamængden og I/O-trykket vokser.
Hvorfor lagertestning?
Lagring er det langsomste lag, som de fleste applikationer berører, så en svaghed dér dukker op alle andre steder. Fire grunde retfærdiggør en dedikeret testcyklus.
- Langsom lagring betyder langsomme svartider, langvarige forespørgsler og lavere applikationstilgængelighed.
- Langsom lagring er en overhead for vedligeholdelsen af serverinfrastrukturen.
- Det hjælper at finde systemets praktiske lagringsgrænser før implementering.
- Det hjælper med at forstå, hvordan systemet reagerer, når en hardwareenhed udskiftes eller opgraderes.
Diagrammet nedenfor placerer lagertest i den kontekst – applikationen, filsystemet og den fysiske enhed sidder alle på den samme sti, og en forsinkelse hvor som helst på den når brugeren.
Typer af lagertestning
Der anvendes tre tilgange, og de adskiller sig primært i, hvor meget arbejdsbyrden ligner den virkelige applikation.
- Applikationstest: Applikationstest med eksempelforespørgsler i et produktionslignende miljø.
- Applikationssimulering: Udførelse af testen ved hjælp af standardsoftware, der opfører sig på samme måde som målapplikationen.
- Benchmarking: Udførelse af testningen ved hjælp af standard benchmarking-software, der genererer en syntetisk, gentagelig arbejdsbelastning.
Det første giver det mest realistiske resultat og det mindst bærbare; det tredje giver tal, der kan sammenlignes på tværs af enheder og leverandører, men siger ikke meget om, hvordan selve applikationen vil opføre sig.
Almindelig testning Concepts Involveret under opbevaringstestning
Hver af disse tre typer relaterer sig til et særskilt sæt af aktiviteter, som opsummeret nedenfor.
| Typer af lagertestning | Eksempel på almindelige lagertestaktiviteter |
| Applikationstest | Sammenlign OLTP-svartider Sammenlign batch-kørselstider Sammenlign vedvarende streaminghastigheder |
| Applikationssimulering | Test peak storage IOPS til databaser Test af maksimal lagerkapacitet i datastreamingmiljøer Test af lagerforsinkelse for beskeder eller andre enkelttrådede applikationer |
| Benchmarking | Test for datakorruption |
Nøglemålinger i lagringstestning
Lagringsresultater rapporteres gennem et lille sæt tal. At læse et enkelt af dem alene er den hurtigste måde at nå frem til en forkert konklusion, fordi de handler mod hinanden.
| metric | Hvad det måler | Hvor det betyder mest |
| IOPS | Læse- og skriveoperationer udført pr. sekund, uanset størrelse | Transaktionelle databaser og små tilfældige skrivninger |
| Latency | Tid mellem starten og afslutningen af en enkelt I/O-operation | Beskeder og enkelttrådede applikationsstier |
| gennemløb | Datamængde, der flyttes pr. sekund, normalt i MB/s | Batchkørsel, sikkerhedskopiering og streaming af arbejdsbelastninger |
| Kødybde | Antal udestående anmodninger udstedt på samme tid | Enhver kørsel, der skal afspejle reel samtidighed |
Kødybde fortjener særlig opmærksomhed. At udstede én anmodning ad gangen giver en nøjagtig latenstid for en enkelt anmodning, men et kunstigt lavt IOPS- og gennemløbstal, hvilket er grunden til, at en enhed kan se langsom ud i en test og hurtig i produktion, eller omvendt.
Sådan udfører du lagringstest
En lagringstest er kun så pålidelig som de forhold, den kører under. Sekvensen nedenfor sikrer, at resultaterne kan gentages.
- Trin 1) Definer målet. Afgør, om kørslen skal bevise databaseparathed, finde et gennemløbsloft eller sammenligne to enheder. Hvert mål indebærer en forskellig arbejdsbyrde, og at blande dem producerer tal, som ingen kan handle ud fra.
- Trin 2) Angiv realistisk størrelse på datasættet. Et arbejdssæt, der er lille nok til at passe i cachen, måler cachen, ikke lagerpladsen. Match produktionsdatavolumenet, eller overskrid i det mindste cachestørrelsen med en bred margin.
- Trin 3) Vælg læse-/skriveblandingen og -mønsteret. Tilfældig og sekventiel adgang opfører sig meget forskelligt på den samme enhed, ligesom 70/30 læse-skrive-blandinger og skrive-kun-bursts. Tag blandingen fra produktionsovervågning i stedet for fra en standard.
- Trin 4) Indstil kødybde og trådantal. Disse styrer, hvor meget samtidighed der når enheden, så registrer dem med hvert resultat — et citeret tal uden dem kan ikke gengives.
- Trin 5) Ryd caches og varm op. Slet server- og enhedscaches mellem kørsler, og kassér derefter det første interval, så steady-state-tal sammenlignes i stedet for tal fra første berøring.
- Trin 6) Løb længe nok. Korte kørsler skjuler skriveafsnittet, der opstår, når en SSD bruger sin skrivebuffer. Vedvarende kørsler eksponerer det.
- Trin 7) Overvåg hele stakken. Registrer processorudnyttelse, hukommelse og netværk sammen med lagertællere, så en flaskehals et andet sted ikke fejllæses som en lagergrænse.
- Trin 8) Gentag og sammenlign. Kør den identiske konfiguration mere end én gang, og gem loggene; ydeevneforskydning mellem builds er kun synlig mod en gemt baseline.
Da den samme disciplin gælder for enhver belastningsdrevet måling, planlægges disse kørsler normalt sammen med test af ydeevne og planlagt før releasekandidaten fryses.
Værktøjer til test af lagring
Værktøjsudstyr falder i to grupper, og de fleste teams har brug for begge.
- Syntetiske I/O-generatorer. Forsyningsvirksomheder såsom FIOIometer og sysbench udsteder en præcist beskrevet arbejdsbelastning — blokstørrelse, læse/skrive-mix, kødybde og varighed er alle deklareret, så en kørsel kan gentages præcist på en anden enhed.
- Værktøjer til indlæsning på applikationsniveau. Chauffører som f.eks. JMeter udføre selve applikationen, så lageret ser det samme adgangsmønster, som rigtige brugere opretter, inklusive de forespørgselsplaner og indeksadfærd, som et syntetisk værktøj ikke kan reproducere.
OperaTing-systemets tællere fuldender billedet. Uanset hvilket værktøj der genererer belastningen, skal lagertallene aflæses ved siden af processor-, hukommelses- og netværkstællere — adskillige lagertestteknikker, herunder benchmark test og volumentestning, afhænger af den full-stable visning for at fortolke et resultat korrekt.
Fejl under udførelse af lagringstest
De fleste ugyldige lagringsresultater tractilbage til et lille antal undgåelige fejl.
- Overvåger den forkerte serverydeevne, så tallene beskriver en maskine, der ikke er under test.
- Sammenligning af lagerenheder uden først at rydde servercachen, hvilket måler hukommelse i stedet for disk.
- Glemmer at overvåge processorudnyttelsen under test, hvilket skjuler en processorbundet flaskehals bag et lagerformet symptom.
- Test af lagringsydelse med filkopieringskommandoer, som er enkelttrådede, cache-assisterede og ikke gentagelige.
