Långsamma OS-diskar, Snabba Datadiskar

Genom åren har jag funnit att man ofta felar på sidan av högpresterande, mycket tillförlitlig datalagring för en operativsystemspartition men väljer långsam, “kostnadseffektiv” lagring för kritiska datalager. Jag förvånas över hur ofta jag ser detta inträffa och nu, i och med hypervisorernas intåg, ser jag samma beteende upprepas även där – vilket förvärrar de problem som redan fanns.

I många system idag hanterar vi endast en enda lagringsarray som delas av alla systemets komponenter. I dessa fall ställs vi inte inför problemet att obalansera vårt lagringssystems prestanda. Detta är en av de stora fördelarna med detta tillvägagångssätt och en viktig anledning till att det rekommenderas så starkt. All prestanda finns i en delad pool och de komponenter som behöver prestandan har tillgång till den.

I många fall, vare sig det är i ett försök till ökad prestanda- eller tillförlitlighetsdesign eller av teknisk nödvändighet, finner jag att man separerar sina lagringsarrayer och placerar hypervisorer och operativsystem på en array och data på en annan. Men det jag finner chockerande är att arrayer dedikerade till hypervisorn eller operativsystemet ofta är häpnadsväckande stora i kapacitet och extremt högpresterande – inte sällan med 15 000 RPM-spindlar eller till och med solid state-diskar till stor kostnad. Nästan alltid i RAID 1 (i enlighet med vanliga standarder från 1998).

Vad som behöver förstås här är att operativsystem i sig i praktiken inte har några krav på lagrings-IO. Det finns en liten mängd, mestadels för systemloggning, men det är ungefär allt som behövs. Operativsystemspartitioner är nästan helt statiska. Nödvändiga komponenter laddas in i minnet, mestadels vid uppstart, och nås inte igen. Även i fall där loggning behövs skickas dessa loggar många gånger till ett centralt loggningssystem och inte till systemets lagringsområde, vilket minskar eller till och med eliminerar även det behovet.

Med hypervisorer är denna effekt ännu mer extrem. Eftersom hypervisorer är långt lättare och mindre robusta än traditionella operativsystem beter de sig mer som inbyggda system och är i många avseenden faktiskt inbyggda system i många fall. Hypervisorer laddas in i minnet vid systemstart och deras media behövs nästan aldrig igen medan ett system körs, förutom för loggning vid vissa tillfällen. Eftersom hypervisorer är små i fysisk storlek är även den totala tid som krävs för att läsa en fullständig hypervisor från lagringen mycket kort, till och med på mycket långsamma media, eftersom den totala storleken är mycket liten.

Av dessa skäl är lagringsprestanda av liten eller ingen betydelse för operativsystem och i synnerhet hypervisorer. Skillnaden mellan snabb lagring och långsam lagring påverkar egentligen bara systemets uppstartstid, där skillnaden mellan en sekund eller trettio sekunder sällan skulle märkas, om ens alls. När skulle någon ens uppfatta flera extra sekunder under uppstarten av ett system, och i de flesta fall är uppstarter sällsynta händelser som inträffar som mest en gång i veckan under en automatiserad, rutinmässig omstart av systemet under ett planerat underhållsfönster, eller mycket sällan, ibland bara en gång vart femte år, för system som endast tas offline i nödsituationer. Även det långsammast tänkbara lagringssystemet är långt snabbare än vad som krävs för denna roll.

Även långsam lagring är i allmänhet många gånger snabbare än vad som krävs för systemloggningsaktiviteter. I de sällsynta fall där loggningen är mycket intensiv har vi många valmöjligheter för hur vi ska angripa detta problem. Den mest uppenbara och vanliga lösningen här är att skicka loggar till en annan diskarray än den som används av operativsystemet eller hypervisorn. Detta är en mycket enkel lösning och i slutändan mycket praktisk i fall där det är motiverat. Den andra vanliga och mycket användbara lösningen är att helt enkelt avstå från att alls behålla loggar på den lokala enheten och i stället skicka dem till ett fjärrbaserat logginsamlingsverktyg såsom Splunk, Loggly eller ELK.

Det andra stora bekymret som de flesta har kring sina operativsystem och hypervisorer är tillförlitlighet. Det är vanligt att lägga mer ansträngning på att skydda dessa relativt oviktiga delar av ett system än den ofta oersättliga datan. Operativsystem och hypervisorer byggs dock lätt om från grunden vid behov med hjälp av nyinstallationer och manuell omkonfigurering när så krävs. De detaljer som skulle kunna gå förlorade är i allmänhet relativt triviala att återskapa.

Detta betyder inte att dessa systemfilsystem inte bör säkerhetskopieras; det bör de naturligtvis (i de flesta fall). Men ifall att även säkerhetskopiorna skulle fallera är det sällsynt att förlusten av en OS-partition eller ett OS-filsystem verkligen innebär en tragedi, utan endast en olägenhet. Det finns sätt att återställa i nästan alla fall utan tillgång till de ursprungliga uppgifterna, så länge “data”-filsystemet är separat. Och på grund av operativsystems och hypervisorers natur är förändringar sällsynta, så säkerhetskopior kan i allmänhet göras mer sällan, möjligen utlösta manuellt endast när uppdateringar tillämpas!

Med många moderna system inom DevOps- och molntjänstområdet har det blivit mycket vanligt att betrakta operativsystems och hypervisorers filsystem som helt kasserbara, eftersom de definieras fjärrstyrt via en systemavbild eller av ett konfigurationshanteringssystem. I dessa fall, som blir allt vanligare, finns det inget behov av dataskydd eller säkerhetskopior, eftersom hela systemet är utformat för att återskapas, nästan ögonblickligen, utan någon särskild interaktion. Systemet är helt självreplikerande. Detta trivialiserar ytterligare behovet av skydd för systemfilsystemet.

Sammantaget, avsaknaden av behov kring prestanda och avsaknaden av behov kring skydd och tillförlitlighet som hanteras främst genom enkel återskapning, ger oss ett systemfilsystem med mycket andra behov än vi vanligtvis antar. Detta betyder inte att vi bör vara vårdslösa med vår lagring; vi vill fortfarande undvika lagringsfel medan ett system körs, och att bygga om i onödan är ett slöseri med tid och resurser även om det inte visar sig vara katastrofalt. Så att hitta en noggrann balans är viktigt.

Det är naturligtvis av dessa skäl som det att inkludera operativsystemet eller hypervisorn på samma lagringsarray som data nu är vanlig praxis – eftersom det finns litet eller inget behov av lagringsåtkomst till systemfilerna samtidigt som det sker åtkomst till datafilerna, så vi får god synergi genom att få snabba uppstartstider för OS:et och ingen negativ påverkan på dataåtkomsttiderna när systemet väl är online. Detta är det främsta sättet på vilket systemdesigner idag angriper behovet av effektiv lagringsanvändning.

När operativsystemet eller hypervisorn måste separeras från de arrayer som håller data, vilket fortfarande kan inträffa av otaliga skäl, strävar vi i allmänhet efter att uppnå rimlig tillförlitlighet till låg kostnad. Vid användning av traditionell lagring (lokala diskar) innebär detta att man använder små, långsamma, billiga roterande diskar för operativsystemslagring, i allmänhet i en enkel RAID 1-konfiguration. Ett verkligt exempel är användningen av 5 400 RPM “miljövänliga” SATA-diskar i minsta möjliga storlekar. Dessa drar lite ström och är mycket billiga att anskaffa. SSD:er och höghastighets-SAS-diskar skulle undvikas eftersom de kostar en premie för skydd som är irrelevant och prestanda som är helt bortkastad.

I mindre traditionell lagring är det vanligt att använda ett billigt SAN med hög densitet som konsoliderar lågprioriterad lagring för många system på delade, långsamma arrayer som inte replikeras. Detta är endast effektivt i större miljöer som kan motivera den ytterligare arkitektoniska designen och kan uppnå tillräcklig densitet i lagringskonsolideringsprocessen för att skapa de nödvändiga kostnadsbesparingarna, men i större miljöer är detta relativt enkelt. SAN-bootenheter kan utnyttja mycket billiga arrayer över många servrar för kostnadsbesparingar. I det virtuella utrymmet skulle detta kunna innebära ett lågpresterande datastore som används för virtuella OS-diskar och en annan, högpresterande pool för virtuella datadiskar. Detta skulle ha samma effekt som boot-SAN-strategin men i en mer modern miljö och skulle med lätthet kunna utnyttja SAN-arkitekturen under huven för att åstadkomma det.

Slutligen, och mest dramatiskt, är det en allmän tumregel med hypervisorer att installera dem på SD-kort eller USB-minnen snarare än på traditionell lagring, eftersom deras behov av prestanda och tillförlitlighet är så mycket mindre än till och med traditionella operativsystems. Normalt sett, om en disk av detta slag skulle fallera medan ett system körs, skulle systemet faktiskt fortsätta att köras utan några problem, eftersom disken aldrig används när systemet väl har startat upp första gången. Det skulle endast vara vid en omstart som ett problem skulle upptäckas, och vid den tidpunkten skulle en reservbootenhet kunna användas, såsom ett sekundärt SD-kort eller USB-minne. Detta är den officiella rekommendationen för VMware vSphere, rekommenderas ofta av Microsoft-representanter för HyperV och stöds officiellt via HyperV:s OEM-leverantörer, och rekommenderas ofta, men har inte lika brett stöd, för Xen-, XenServer- och KVM-system. Att använda SD-kort eller USB-minnen för hypervisorlagring förvandlar i praktiken en virtualiseringsserver till ett inbyggt system. Även om detta kan kännas onaturligt för systemadministratörer som är vana att tänka på traditionella diskar som en nödvändighet för servrar, är det viktigt att komma ihåg att ytterst kritiska system av företagsklass som routrar och switchar håller i decennier och använder exakt samma strategi av exakt samma skäl.

En vanlig strategi för hypervisorer i detta inbyggda läge med SD-kort eller USB-minnen är att ha två sådana enheter, vilka faktiskt kan vara ett SD-kort och ett USB-minne, vardera med en kopia av hypervisorn. Om en enhet fallerar är det nästan lika effektivt att boota från den andra enheten som ett traditionellt RAID 1-system. Men till skillnad från de flesta traditionella RAID 1-uppsättningar har vi också ett relativt enkelt sätt att testa systemuppdateringar genom att uppdatera endast en bootenhet i taget och testa processen innan vi uppdaterar den andra bootenheten, vilket lämnar oss med en tillförlitlig, väl beprövad reservlösning ifall en versionsuppdatering går snett. Denna process var faktiskt vanlig på stora UNIX RISC-system där bootenheter ofta var lokala mjukvarubaserade RAID 1-uppsättningar som stödde en liknande praxis, särskilt vanligt i AIX- och Solaris-kretsar.

Det bör också noteras att även om detta tillvägagångssätt är best practice för de flesta hypervisorscenarier finns det egentligen ingen anledning till att det inte också skulle kunna tillämpas på fullständiga operativsystemsfilsystem, förutom att det ofta innebär mer arbete. Vissa operativsystem, särskilt Linux och BSD, är mycket lämpade för att installeras på ett inbyggt sätt och kan med lätthet anpassas för installation på SD-kort eller USB-minne med lite planering. Detta tillvägagångssätt är inte alls vanligt, men det finns ingen teknisk anledning till varför det, under rätt omständigheter, inte skulle vara ett utmärkt tillvägagångssätt, förutom det faktum att ett OS nästan aldrig bör installeras på fysisk hårdvara snarare än ovanpå en hypervisor. I de fall där fysiska installationer är nödvändiga är detta tillvägagångssätt ytterst giltigt.

När du designar och planerar lagringssystem, kom ihåg att vara uppmärksam på hur läs- och skrivmönster verkligen kommer att se ut när ett system körs. Och kom ihåg att lagring har förändrats ganska dramatiskt sedan många traditionella riktlinjer utvecklades och att inte all den kunskap som användes för att utveckla dem fortfarande gäller idag eller gäller i lika hög grad. Tänk inte bara på vilka lagringsundersystem som kommer att försöka använda lagringsprestanda, utan också på hur de kommer att interagera med varandra (till exempel, begär två system aldrig lagringsåtkomst samtidigt eller kommer de att hamna i konflikt regelbundet) och huruvida deras åtkomstprestanda är viktig eller inte. Allmänna operativsystemsfunktioner kan vara ytterst långsamma på en databasserver utan negativ påverkan; allt som spelar roll är hastigheten med vilken en databas kan nås. Även åtkomst till applikationsbinärfiler är ofta irrelevant eftersom även de, när de väl har laddats in i minnet, förblir där och endast minneshastigheten påverkar den löpande prestandan.

Inget av detta är avsett att antyda att det är att rekommendera att separera lagringsundersystemen för OS och data från varandra; ofta är det inte det. Jag har tidigare skrivit om hur det att konsolidera dessa undersystem ganska ofta är det bästa tillvägagångssättet, och det är fortfarande sant nu. Men det finns också många rimliga fall där det är vettigt att dela upp vissa lagringsbehov från varandra, ofta när man har att göra med storskaliga system där vi kan sänka kostnaden genom att dedikera dyr lagring till vissa behov och billig lagring till andra behov, och det är i de fallen som jag vill visa att operativsystem och hypervisorer bör betraktas som lägst prioriterade i fråga om både prestanda och tillförlitlighet, utom i de mest extrema fallen.