En titt på Enterprise Performance för Intel SSD:er

Fallstudie: SSD:er i AnandTechs servermiljö

Under större delen av AnandTechs historia har vi haft vår egen serverinfrastruktur. En fördel med att driva vår egen infrastruktur är att vi kan få mycket praktisk erfarenhet av företagsmiljöer som vi annars skulle behöva rapportera om på distans.

När jag först började täcka SSD-enheter för fyra år sedan blev jag besatt av idén att migrera nästan alla system till något SSD-baserat. De första som gjorde bytet var våra CPU-testbäddar. Att flytta bort från mekaniska enheter säkerställde bättre standardkonsistens mellan körningar eftersom alla variationer i IO-belastningen lätt absorberades av det enorma utrymmet som en SSD erbjöd. Den heliga graalen var naturligtvis att migrera alla AnandTech-servrar till SSD:er. Under årens lopp verkar våra servrar dö i följande ordning: hårddiskar, nätaggregat, moderkort. Vi tenderar att stanna på en hårdvaruplattform tills systemen börjar visa tecken på sin ålder (t.ex. moderkort börjar dö), men det brukar vara tillräckligt länge för att vi stöter på ett irriterande antal hårddiskfel. En väl validerad SSD bör ha en förutsägbar felfrekvens, vilket gör den till en idealisk kandidat för en företagsmiljö där driftstopp är ganska kostsamt och i fallet med ett litet företag, mycket irriterande.

Vårt senaste serverflytt är en lång historia för en separat artikel, men för att sammanfatta flytten bytte vi nyligen värdleverantör och datacenter. Vår hårdvara låg tidigare på östkusten och det nya datacentret ligger mitt i landet. Hos vår gamla värd testade vi en ny molnplattform medan vårt nya hem skulle vara en blandning av en traditionell back-end med en virtualiserad front-end. Med en snäv tidsplan för flytten och ingen önskan att distribuera en lätt bärbar lösning i vårt gamla hem innan vi gjorde flytten stod vi inför en svår uppgift: hur flyttar vi fysiskt våra servrar halvvägs över landet med minimal stilleståndstid?

Tack och lov hade vår nya värd tillfällig hårdvara som mycket liknar vår nya infrastruktur som de var villiga att sätta webbplatsen på när vi flyttade vår hårdvara. Det enda undantaget var, som du kanske kan gissa, en relativ brist på SSD:er. Vår nya hårdvara använder en kombination av SSD:er för konsumenter och företag, men vår nya värd hade bara mekaniska enheter eller SSD:er av konsumentklass (Intel SSD 320s). Det faktum att vi hade kört webbplatsens databaser från en mekanisk drivenhet i flera år innebar att även ett litet antal konsumentenheter borde vara mer än kapabla att hantera belastningen. Jag minns tillbaka till några av våra tidigaste lektioner i SSD-utrymmet: en enda solid state-enhet kan erbjuda en storleksordning bättre slumpmässig IO-prestanda än till och med de snabbaste hårddiskarna. Sekventiell prestanda är vanligtvis närmare, men med moderna 3 Gbps SSD:er ser du fortfarande en fördel på ungefär 100 MB/s i sekventiell genomströmning jämfört med de snabbaste mekaniska enheterna.

Eftersom vi inte ville ta itu med några potentiella IO-prestandaproblem, bestämde vi oss för att distribuera ett gäng Intel SSD:er av konsumentklass på våra tillfälliga DB-servrar som vår värd hade till hands. Detta är inte ovanligt, i själva verket betjänas en stor andel av företagets arbetsbelastning helt bra av konsument-SSD. Det är bara de absolut tyngsta arbetsbelastningarna som kräver eMLC- eller SLC-enheter. Med tanke på att vi skulle stanna på den här plattformen under en kort period, fanns det inget behov av eMLC/SLC-enheter. Som vi vet från år av hantering av SSD:er har NAND-celler en begränsad livslängd. Konsumentklass MLC NAND är bra för cirka 5 000 program/raderingscykler per cell, medan MLC (eMLC/MLC-HET) i företagsklass kan ge dig över 6 gånger så mycket. Medan de flesta klientarbetsbelastningar aldrig når 5000 p/e-cykler, kan en tillräckligt stor företagsarbetsbelastning definitivt nå den punkten. Det är inte bara hur mycket du skriver, det är också hur mycket varje skrivning förstärks. Kom ihåg att även om NAND är programmerad på sidnivå (4KB – 8KB), kan den bara raderas på blocknivå (512KB – 2048KB). Denna obalans i skriv/raderingsgranularitet innebär att du till slut måste skriva mer till NAND än du har skickat till värden (t.ex. gå till skriv 8KB men måste läsa, ändra, skriva ett helt 2048KB block eftersom det inte finns några tomma block block att skriva till). Förhållandet mellan NAND och värdskrivningar kallas skrivförstärkning. Kombinationen av arbetsbelastning och skrivförstärkning är det som avgör livslängden på alla SSD-enheter, men i företagsvärlden är det något du faktiskt måste vara uppmärksam på.

Skrivförstärkning runt 1 kan vara realistisk för klientens (läs tunga) arbetsbelastning, men inte i företaget

Vår värd hade åtta Intel SSD 320 (120GB) till hands som vi kunde använda för våra tillfälliga databasservrar. Ur prestandasynpunkt borde dessa enheter vara mer än tillräckligt för att hantera vår arbetsbelastning, men skulle de vara tillförlitliga?

Det enklaste sättet att bekämpa skrivförstärkning är att öka mängden ledig yta på en SSD. NAND som inte är användaradresserbar kan användas för bakgrundsoperationer och hjälper till att säkerställa att det finns tomma block att skriva till så ofta som möjligt. Om skrivning sker på tomma mot fulla block, minskar skrivförstärkningen avsevärt.

Vi distribuerade Intel SSD 320s partitionerade ner till 100 GB vardera. Nyfiken på hur de har hållit ut under de senaste ~9 dagarna som de har kört som vår primära miljö, installerade och körde jag Intels SSD Toolbox på våra DB-servrar.

Som jag nämnde i vår recension av Intels SSD 710 kan du faktiskt mäta saker som skrivförstärkning, värdskrivningar och beräknad livslängd med hjälp av SMART-attribut på de senaste Intel SSD:erna. Detta fungerar inte på Intel SSD 510, X25-E eller första generationens X25-M, men på alla andra Intel SSD:er kommer det att fungera.

De viktiga attributen är E1, E2, E3 och E4 (dessa är hexadecimala representationer av SMART-attributnumren 225 – 228). E2 – E4 är alla timerberoende, medan E1 ger dig en indikation på hur mycket du har skrivit till NAND under enhetens livslängd. Jag kommer snart in på de timerbaserade räknarna, men när vi ursprungligen ställde in servrarna hade jag inte förutseendet att återställa räknarna för att få en exakt uppskattning av skrivförstärkningen på vår arbetsbelastning. Istället ska jag titta på det totala antalet skrivna bytes och använda några interna uppskattningar för skrivförstärkning för att mäta livslängden.

De åtta enheterna är uppdelade på två databasservrar som kör två olika applikationer (en för huvudsidan och en för forumen/annonserna). Den senare mer tungt lastad men båda är ganska krävande. De fyra enheterna är konfigurerade i en RAID10 för att öka kapaciteten och erbjuda viss redundans. En enkel RAID1 av större enheter skulle vara bra, men 120 GB-enheter är allt vi hade till hands vid den tiden. Det totala antalet skrivningar på alla enheter under de senaste 9 dagarna dokumenteras i tabellen nedan:

Varje enhet i den första DB-servern har sett cirka 570 GB skrivningar på 9 dagar, eller ungefär 63 GB/dag. Enheterna i den andra DB-servern har gått igenom 1,03 TB skrivningar under samma tidsperiod eller 114 GB/dag. Observera att båda arbetsbelastningarna är en storleksordning större än en genomsnittlig konsumentbelastning på 5 – 10 GB/dag. Därmed inte sagt att vi inte kan köra dessa arbetsbelastningar på konsument-SSD:er, vi måste bara vara försiktiga.

Utan skrivförstärkning kunde vi köra på dessa konsumentenheter på obestämd tid. Med varje MLC NAND-cell som är bra för 5000 program/raderingscykler, kunde vi skriva till enheterna 5000 gånger innan vi började förlora NAND. Baserat på siffrorna ovan, skulle vi blåsa igenom ap/e-cykeln var ~2 dag på den första DB-servern och var ~1 dag på den andra servern.

Även om vi gärna antar att skrivförstärkning är bra och låg, är det i verkligheten inte det. Intels egna datablad berättar om skrivförstärkningen i värsta fall för 320:n:

Om du delar kolumnen till höger med kolumnen till vänster kommer du att få 125 program/raderingscykler per cell (om du definierar 1 TB som en biljon byte). Om vi ​​antar att varje cell är bra för 5000 p/e-cykler (Intels 25nm MLC NAND-spec) så betyder det att vi faktiskt skriver 40x vad vi tror att vi skriver. Detta 40x-värde ger oss en övre gräns för skrivförstärkning på Intels SSD 320. Det är mycket lägre än den teoretiska maximala skrivförstärkningen på 256 (skriver 2048KB för varje 8KB-skriv som skickas till värden), men det är säkert att säga att Intels firmware vann låt det inte bli så illa.

Skrivförstärkning på 40x är inte särskilt bra men det är inte heller särskilt realistiskt för de flesta arbetsbelastningar. Våra databasarbetsbelastningar är tunga men de är inte helt slumpmässiga skrivningar över alla LBA:er under enhetens livstid. Dessa arbetsbelastningar finns, men vi är helt enkelt inte ett exempel på en sådan. En mer realistisk, men fortfarande konservativ uppskattning för skrivförstärkning i vårt fall skulle vara 10x (bara baserat på några interna uppskattningar för skrivförstärkning). Den faktiska skrivförstärkaren är sannolikt mindre än hälften så men återigen, jag ville vara konservativ.

Att beräkna livslängd baserat på dessa data är ganska enkelt. Multiplicera det totala antalet byte skrivna med uppskattad skrivförstärkning och det är så vi kan skala upp/ned:

Med 10x skrivförstärkning tittar vi på ungefär 2,5 år för en uppsättning enheter och 1,4 år för den andra uppsättningen. Ur kostnadssynpunkt är det sannolikt billigare att gå vägen för konsumentkörning och proaktivt byta ut enheter jämfört med att hoppa till eMLC även om det inte alltid är önskvärt ur ett drifttidsperspektiv. Om våra skrivförstärkningsuppskattningar är avstängda (de är det) så kan du förvänta dig något mer i stil med 5 år för den första uppsättningen enheter och 3 för den andra uppsättningen.

Vi skulle kunna bekämpa skrivförstärkning genom att avsätta ännu mer reservyta för enheterna. Att partitionera dem som 80 GB eller till och med 60 GB-enheter skulle påtagligt minska skrivförstärkningen och ge oss ännu mer tid på dessa konsumentenheter.

Detta är inte så mycket ett problem för oss eftersom vår vistelse på 320-talet är tillfällig, men det väckte en intressant fråga. Eftersom företagets SSD-uthållighet är starkt beroende av skrivförstärkning, hur skulle Intels SandForce-baserade SSD 520 hantera företagets arbetsbelastning med tanke på att dess effektiva skrivförstärkning ofta är gånger mindre än 1x?

Om du kunde ha i genomsnitt 0,5x skrivförstärkning med Intels SSD 520, skulle din 5000 p/e cykel MLC NAND bete sig mer som 10000 p/e cykel NAND. Även om det fortfarande är brist på vad du får från eMLC, är det kanske tillräckligt för att vara en bättre balans mellan pris och prestanda för många SMB-företagskunder.

Det var dags att undersöka lite…