Trege OS-Disker, Raske Datadisker

Gjennom årene har jeg funnet at folk ofte feilaktig velger høytytende, svært pålitelig datalagring for en operativsystempartisjon, men velger treg, “kostnadseffektiv” lagring for kritiske datalagringsområder. Jeg er forbauset over hvor ofte jeg finner dette, og nå, med fremveksten av hypervisorer, ser jeg den samme atferden gjentatt der også – noe som forsterker de tidligere eksisterende problemene.

I mange systemer i dag har vi å gjøre med bare ett enkelt lagringsarray som deles av alle komponenter i systemet. I disse tilfellene møter vi ikke problemet med å ubalansere ytelsen til lagringssystemet vårt. Dette er en av de store fordelene med denne tilnærmingen og en viktig grunn til at den anbefales så sterkt. All ytelse er i en delt pool, og komponentene som trenger ytelsen har tilgang til den.

I mange tilfeller, enten i et forsøk på økt ytelse eller pålitelighetsdesign, eller av teknisk nødvendighet, finner jeg at folk skiller ut lagringsarrayene sine og plasserer hypervisorer og operativsystemer på ett array og data på et annet. Men det jeg finner sjokkerende er at arrays dedikert til hypervisoren eller operativsystemet ofte er svimeslående store i kapasitet og ekstremt høye i ytelse – ofte med 15 000 RPM spindler eller til og med solid state-disker til stor kostnad. Nesten alltid i RAID 1 (i henhold til vanlige standarder fra 1998.)

Det som må forstås her er at operativsystemer i seg selv faktisk ikke har noen lagrings-IO-krav. Det er en liten mengde, mest for systemlogging, men det er omtrent alt som trengs. Operativsystempartisjoner er nesten fullstendig statiske. Nødvendige komponenter lastes inn i minnet, for det meste ved oppstartstidspunktet, og er ikke tilgjengelige igjen. Selv i tilfeller der logging er nødvendig, sendes disse loggene mange ganger til et sentralt loggingssystem og ikke til systemlagringsområdet, noe som reduserer eller til og med eliminerer det behovet også.

Med hypervisorer er denne effekten enda mer ekstrem. Ettersom hypervisorer er langt lettere og mindre robuste enn tradisjonelle operativsystemer oppfører de seg mer som innebygde systemer og er i mange henseender faktisk innebygde systemer i mange tilfeller. Hypervisorer lastes inn i minnet ved systemoppstart, og mediet deres er nesten aldri nødvendig igjen mens et system kjører, bortsett fra for logging ved noen anledninger. Fordi hypervisorer er små i fysisk størrelse er til og med den totale tiden som trengs for å fullstendig lese av en full hypervisor fra lagring svært liten, selv på svært trege medier, fordi den totale størrelsen er svært liten.

Av disse grunnene er lagringsytelse av liten eller ingen betydning for operativsystemer og spesielt hypervisorer. Forskjellen mellom rask lagring og treg lagring påvirker egentlig bare systemoppstartstiden, der forskjellen på ett sekund eller tretti sekunder sjelden ville bli lagt merke til, om i det hele tatt. Når ville noen oppfatte til og med noen ekstra sekunder under oppstarten av et system? Og i de fleste tilfeller er oppstarter sjeldne hendelser som skjer høyst en gang i uken under en automatisert, rutinemessig systemomstart i et planlagt vedlikeholdsvindu, eller svært sjelden – noen ganger bare en gang hvert par år – for systemer som bare tas offline i nødstilfeller. Selv det tregeste tenkelige lagringssystemet er langt raskere enn nødvendig for denne rollen.

Selv treg lagring er generelt mange ganger raskere enn nødvendig for systemloggingsaktiviteter. I de sjeldne tilfellene der logging er svært intensiv har vi mange valg av hvordan vi kan takle dette problemet. Den mest åpenbare og vanlige løsningen er å sende logger til et disk-array annet enn det som brukes av operativsystemet eller hypervisoren. Dette er en svært enkel løsning og i siste instans svært praktisk i tilfeller der det er berettiget. Den andre vanlige og svært nyttige løsningen er rett og slett å unnlate å lagre logger på den lokale enheten i det hele tatt og sende dem til et eksternt logginnsamlingsverktøy som Splunk, Loggly eller ELK.

Den andre store bekymringen de fleste har rundt operativsystemene og hypervisorene sine er pålitelighet. Det er vanlig å fokusere mer innsats på å beskytte disse relativt uviktige aspektene av et system fremfor de ofte uerstattelige dataene. Operativsystemer og hypervisorer er imidlertid lett å gjenoppbygge fra bunnen av ved behov ved hjelp av nyinstallering og manuell rekonfigurasjon når nødvendig. Detaljene som kan gå tapt er generelt relativt trivielle å gjenskape.

Dette betyr ikke at disse systemfilsystemene ikke bør sikkerhetskopieres – selvfølgelig bør de det (i de fleste tilfeller.) Men bare i tilfelle sikkerhetskopiene også svikter, er det sjelden at tap av en OS-partisjon eller et filsystem virkelig betyr tragedie, men bare et ubehag. Det er måter å komme seg på i nesten alle tilfeller uten tilgang til de originale dataene, så lenge «data»-filsystemet er atskilt. Og på grunn av naturen til operativsystemer og hypervisorer er endring sjelden, så sikkerhetskopier kan generelt tas sjeldnere – muligens utløst manuelt bare når oppdateringer brukes!

Med mange moderne systemer i DevOps og cloud computing-rommene har det blitt svært vanlig å se på operativsystemer og hypervisor-filsystemer som fullstendig engangsbruk siden de defineres eksternt via et systemimage eller av et konfigurasjonsadministrasjonssystem. I disse tilfellene, som blir mer og mer vanlige, er det ikke behov for databeskyttelse eller sikkerhetskopier da hele systemet er designet for å bli gjenskapt, nesten umiddelbart, uten noen spesiell interaksjon. Systemet er fullstendig selvrepliserende. Dette trivialiserer ytterligere behovet for beskyttelse av systemfilsystemer.

Sett under ett har vi med mangelen på behov rundt ytelse og mangelen på behov rundt beskyttelse og pålitelighet primært håndtert gjennom enkel gjenoppretting, et systemfilsystem med svært ulike behov enn det vi vanligvis antar. Dette betyr ikke at vi bør være uforsiktige med lagringen vår – vi vil fortsatt unngå lagringssvikt mens et system kjører, og unødvendig gjenoppbygging er sløsing med tid og ressurser selv om det ikke viser seg å være katastrofalt. Så å finne en nøye balanse er viktig.

Det er selvfølgelig av disse grunnene at det å inkludere operativsystemet eller hypervisoren på det samme lagringsarrayet som data nå er vanlig praksis – fordi det er lite eller intet behov for lagringstilgang til systemfilene på samme tid som det er tilgang til datafilene, slik at vi oppnår stor synergi ved å få raske oppstartstider for OS og ingen negativ innvirkning på datatilgangstider når systemet er online. Dette er den primære måten systemdesignere i dag takler behovet for effektiv bruk av lagring på.

Når operativsystemet eller hypervisoren må separeres fra arrayene som holder data – noe som fortsatt kan skje av utallige grunner – søker vi generelt å oppnå rimelig pålitelighet til lav kostnad. Når vi bruker tradisjonell lagring (lokale disker) betyr dette å bruke små, trege, rimelige roterende disker for operativsystemlagring, generelt i enkel RAID 1-konfigurasjon. Et virkelig eksempel er bruken av 5400 RPM «miljøvennlige» SATA-disker i de minste størrelsene som er mulige. Disse trekker lite strøm og er svært rimelige å anskaffe. SSD-er og høyhastighets SAS-disker ville bli unngått da de koster en premie for beskyttelse som er irrelevant og ytelse som er fullstendig bortkastet.

I mindre tradisjonell lagring er det vanlig å bruke et rimelig, høy-tetthet SAN som konsoliderer lavprioritetlagringen for mange systemer på delte, trege arrays som ikke er replikert. Dette er bare effektivt i større miljøer som kan rettferdiggjøre den ekstra arkitekturdesignen og kan oppnå nok tetthet i lagringskonsolideringsprosessen til å skape de nødvendige kostnadsbesparelsene, men i større miljøer er dette relativt enkelt. SAN-boot-enheter kan utnytte svært rimelige arrays på tvers av mange servere for kostnadsbesparelser. I det virtuelle rommet kan dette bety et lavytelses datalager brukt for OS virtuelle disker og en annen, høytytende pool for virtuelle datadisker. Dette ville ha den samme effekten som SAN-boot-strategien men i en mer moderne setting og kunne enkelt utnytte SAN-arkitekturen under panseret for å oppnå det.

Til slutt, og mest dramatisk, er det en generell tommelfingerregel med hypervisorer å installere dem på SD-kort eller USB-pinner i stedet for til tradisjonell lagring, da ytelse- og pålitelighetsbehovene deres er så mye mindre selv enn tradisjonelle operativsystemer. Normalt, hvis en disk av denne typen skulle svikte mens et system kjørte, ville det faktisk fortsette å kjøre uten noe problem da disken aldri brukes etter at systemet har startet opp innledningsvis. Det ville bare være under en omstart at et problem ville bli funnet, og på det tidspunktet kunne en reserve-oppstartenhet brukes, for eksempel et sekundært SD-kort eller USB-pinne. Dette er den offisielle anbefalingen for VMware vSphere, anbefales ofte av Microsoft-representanter for HyperV, og støttes offisielt gjennom HyperVs OEM-leverandører, og anbefales ofte – men ikke så bredt støttet – for Xen, XenServer og KVM-systemer. Å bruke SD-kort eller USB-pinner til hypervisorlagring gjør effektivt en virtualiseringsserver til et innebygd system. Selv om dette kan virke unaturlig for systemadministratorer som er vant til å tenke på tradisjonelle disker som en nødvendighet for servere, er det viktig å huske at enterprise-klasse, svært kritiske systemer som rutere og svitsjer varer i tiår og bruker nøyaktig den samme strategien av nøyaktig de samme grunnene.

En vanlig strategi for hypervisorer i denne innebygde stilen med SD-kort eller USB-pinner er å ha to slike enheter – som faktisk kan være ett SD-kort og én USB-pinne – hver med en kopi av hypervisoren. Hvis en enhet svikter, er det å starte opp fra den andre enheten nesten like effektivt som et tradisjonelt RAID 1-system. Men i motsetning til de fleste tradisjonelle RAID 1-oppsett, har vi også et relativt enkelt middel for å teste systemoppdateringer ved å bare oppdatere én oppstartenhet om gangen og teste prosessen før vi oppdaterer den andre oppstartenheten, noe som gir oss en pålitelig, godt testet reserve i tilfelle en versjonsoppdatering går galt. Denne prosessen var faktisk vanlig på store UNIX RISC-systemer der oppstartenheter ofte var lokale programvare-RAID 1-sett som støttet en lignende praksis, spesielt vanlig i AIX- og Solaris-kretser.

Det bør også bemerkes at selv om denne tilnærmingen er beste praksis for de fleste hypervisor-scenarioer, er det faktisk ingen grunn til at den ikke kan anvendes på fulle operativsystemfilsystemer også, bortsett fra at det ofte er mer arbeid. Noen OS-er, spesielt Linux og BSD, er svært dyktige til å installeres på en innebygd måte og kan enkelt tilpasses for installasjon på SD-kort eller USB-pinne med litt planlegging. Denne tilnærmingen er slett ikke vanlig, men det er ingen teknisk grunn til at den – under de rette omstendighetene – ikke ville være en utmerket tilnærming, bortsett fra det faktum at nesten aldri bør et OS installeres på fysisk maskinvare i stedet for på toppen av en hypervisor. I de tilfellene der fysiske installasjoner er nødvendige er denne tilnærmingen ekstremt gyldig.

Når du designer og planlegger for lagringssystemer, husk å være oppmerksom på hva lese- og skrivemønstrene virkelig vil se ut som når et system kjører. Og husk at lagring har endret seg ganske dramatisk siden mange tradisjonelle retningslinjer ble utviklet, og ikke all kunnskapen som ble brukt til å utvikle dem gjelder fortsatt i dag eller gjelder i like stor grad. Tenk på ikke bare hvilke lagringsdelsystemer som vil forsøke å bruke lagringsytelse, men også hvordan de vil samhandle med hverandre (for eksempel, vil to systemer aldri be om lagringstilgang samtidig, eller vil de kollidere regelmessig) og om tilgangsytelsen deres er viktig. Generelle operativsystemfunksjoner kan være ekstremt trege på en databaseserver uten negativ innvirkning; alt som betyr noe er hastigheten som en database kan aksesseres med. Selv tilgang til applikasjonsbinærfiler er ofte irrelevant da de, når de er lastet inn i minnet, forblir der og bare minnehastigheten påvirker den pågående ytelsen.

Ingenting av dette er ment å antyde at det anbefales å separere OS og datalagringsundersystemer fra hverandre – det er det ofte ikke. Jeg har tidligere skrevet om hvordan konsolidering av disse undersystemene ganske hyppig er den beste fremgangsmåten, og det gjelder fortsatt nå. Men det er også mange rimelige tilfeller der det gir mening å skille visse lagringsbehov fra hverandre – ofte når vi har å gjøre med storskala systemer der vi kan senke kostnadene ved å dedikere kostbar lagring til visse behov og rimelig lagring til andre behov. Det er i disse tilfellene jeg ønsker å demonstrere at operativsystemer og hypervisorer bør anses som den laveste prioriteten med tanke på både ytelse og pålitelighet, bortsett fra i de mest ekstreme tilfellene.