Langsomme OS-drev, Hurtige Datadrev

Gennem årene har jeg fundet ud af, at folk ofte fejler på siden af højtydende, meget pålidelig datalagring til en operativsystempartition, men vælger langsom, “omkostningseffektiv” lagring til kritiske datalagringsområder. Jeg er forbløffet over, hvor ofte jeg finder dette, og nu, med fremkomsten af hypervisorer, ser jeg den samme adfærd gentages der som godt – hvilket forværrer de allerede eksisterende problemer.

I mange systemer i dag har vi kun et enkelt lagerarray delt af alle systemkomponenter. I disse tilfælde er vi ikke over for problemet med at ubalancere vores lageresystems ydeevne. Dette er en af de store fordele ved denne tilgang og en vigtig grund til, at den er så stærkt anbefalet. Al ydeevne er i en delt pulje, og de komponenter, der har brug for ydeevnen, har adgang til den.

I mange tilfælde, enten i et forsøg på øget ydeevne eller pålidelighed i designet, eller af teknisk nødvendighed, finder jeg, at folk adskiller deres lagerarrays og placerer hypervisorer og operativsystemer på et array og data på et andet. Men hvad jeg finder forbløffende er, at arrays dedikeret til hypervisoren eller operativsystemet ofte er betagende store i kapacitet og ekstremt højtydende – ofte med 15.000 RPM-spindler eller endda solid state-drev til stor udgift. Næsten altid i RAID 1 (som per de fælles standarder fra 1998.)

Hvad der skal forstås her, er, at operativsystemer i sig selv effektivt ikke har nogen krav til lager-IO. Der er en lille mængde, mest til systemlogning, men det er stort set alt, hvad der er brug for. Operativsystempartitioner er næsten fuldstændig statiske. Nødvendige komponenter indlæses i hukommelsen, mest ved opstart, og tilgås ikke igen. Selv i tilfælde, hvor logning er nødvendig, sendes disse logs mange gange til et centralt logningssystem og ikke til systemets lagerområde, hvilket reducerer eller endda fjerner det behov som godt.

Med hypervisorer er denne effekt endnu mere ekstrem. Da hypervisorer er langt lettere og mindre robuste end traditionelle operativsystemer, opfører de sig mere som indlejrede systemer og er faktisk i mange tilfælde indlejrede systemer på mange måder. Hypervisorer indlæses i hukommelsen ved systemopstart, og deres medie er næsten aldrig nødvendigt igen, mens et system kører, undtagen til logning ved lejligheder. Fordi hypervisorer er små i fysisk størrelse, er selv den samlede tid, der er nødvendig for at læse en komplet hypervisor af lageret, meget lille, selv på meget langsomt medie, fordi den samlede størrelse er meget lille.

Af disse grunde er lagringensydeevne af ringe eller ingen betydning for operativsystemer og især hypervisorer. Forskellen mellem hurtig lagring og langsom lagring påvirker virkelig kun systemets opstartstid, hvor forskellen på ét sekund eller tredive sekunder sjældent vil blive bemærket, om overhovedet. Hvornår ville nogen bemærke selv flere ekstra sekunder under starten af et system, og i de fleste tilfælde er opstarter sjældne begivenheder, der sker højst én gang om ugen under en automatiseret, rutine-systemgenstart i et planlagt vedligeholdelsesvindue, eller meget sjældent, nogle gange kun én gang hvert par år, for systemer, der kun tages offline i nødsituationer. Selv det langsomste tænkelige lagersystem er langt hurtigere end nødvendigt til denne rolle.

Selv langsom lagring er generelt mange gange hurtigere end nødvendigt til systemlogningsaktiviteter. I de sjældne tilfælde, hvor logning er meget intens, har vi mange valg for, hvordan vi tackler dette problem. Den mest oplagte og almindelige løsning her er at sende logs til et drevarray, der ikke er det, der bruges af operativsystemet eller hypervisoren. Dette er en meget nem løsning og i sidste ende meget praktisk i tilfælde, hvor det er berettiget. Den anden fælles og meget nyttige løsning er ganske enkelt at undlade at opbevare logs på den lokale enhed overhovedet og sende dem til et eksternt logindsamlingsværktøj som Splunk, Loggly eller ELK.

Den anden store bekymring, de fleste mennesker har om deres operativsystemer og hypervisorer, er pålidelighed. Det er almindeligt at fokusere mere indsats på at beskytte disse relativt uvigtige aspekter af et system frem for de ofte uerstattelige data. Operativsystemer og hypervisorer er dog let at genopbygge fra bunden, når det er nødvendigt, ved hjælp af friske installationer og manuel rekonfiguration, når det er nødvendigt. De detaljer, der kan gå tabt, er generelt relativt trivielle at genskabe.

Det betyder ikke, at disse systemfilsystemer ikke bør sikkerhedskopieres; selvfølgelig bør de det (i de fleste tilfælde.) Men i tilfælde af, at sikkerhedskopierne også fejler, er det sjældent, at tabet af en OS-partition eller et filsystem virkelig er en katastrofe, men kun en ulempe. Der er måder at komme sig på i næsten alle tilfælde uden adgang til de originale data, så længe “data”-filsystemet er adskilt. Og på grund af operativsystemers og hypervisorers natur er ændring sjælden, så sikkerhedskopier generelt kan foretages sjældnere, muligvis udløst manuelt kun, når opdateringer anvendes!

Med mange moderne systemer i DevOps- og cloud computing-rummet er det blevet meget almindeligt at betragte operativsystemer og hypervisorfilsystemer som fuldstændig disponible, da de er defineret eksternt via et systemimage eller et konfigurationsstyringssystem. I disse tilfælde, som bliver mere og mere almindelige, er der ikke behov for databeskyttelse eller sikkerhedskopier, da hele systemet er designet til at blive genskabt, næsten øjeblikkeligt, uden nogen særlig interaktion. Systemet er helt selvreplikerende. Dette trivialiserer yderligere behovet for beskyttelse af systemfilsystemet.

Samlet set har vi med manglen på behov for ydeevne og manglen på behov for beskyttelse og pålidelighed, der primært håndteres gennem simpel genskabelse, et systemfilsystem med meget anderledes behov end vi normalt antager. Det betyder ikke, at vi bør være hensynsløse med vores lagring; vi ønsker stadig at undgå lagerafejl, mens et system kører, og unødvendig genopbygning er spild af tid og ressourcer, selv om det ikke viser sig at være katastrofalt. Så at finde en omhyggelig balance er vigtig.

Det er selvfølgelig af disse grunde, at det nu er almindelig praksis at inkludere operativsystemet eller hypervisoren på det samme lagerarray som data – fordi der er lille eller intet behov for lageradgang til systemfilerne på samme tid som der er adgang til datafilerne, og vi får stor synergi ved at opnå hurtige opstartstider for operativsystemet og ingen negativ indvirkning på dataaccesstider, når systemet er online. Dette er det primære middel, hvormed systemdesignere i dag tackler behovet for effektiv brug af lagring.

Når operativsystemet eller hypervisoren skal adskilles fra arrays, der holder data, hvilket stadig kan ske af utallige grunde, søger vi generelt at opnå rimelig pålidelighed til lav omkostning. Når vi bruger traditionel lagring (lokale diske) betyder dette brug af små, langsomme, billige spindeldrev til operativsystemlagring, generelt i simpel RAID 1-konfiguration. Et virkelighedseksempel er brugen af 5400 RPM “miljøvenlige” SATA-drev i de mindst mulige størrelser. Disse trækker lidt strøm og er meget billige at anskaffe. SSD'er og hurtige SAS-drev ville blive undgået, da de koster et præmium for beskyttelse, der er irrelevant, og ydeevne, der er fuldstændig spildt.

I mindre traditionel lagring er det almindeligt at bruge et billigt, højtætheds-SAN, der konsoliderer lavprioritetslagring for mange systemer på delte, langsomme arrays, der ikke er replikerede. Dette er kun effektivt i større miljøer, der kan retfærdiggøre den yderligere arkitektoniske design og kan opnå nok tæthed i lagringskonsolideringsprocessen til at skabe de nødvendige omkostningsbesparelser, men i større miljøer er dette relativt nemt. SAN-bootenheder kan udnytte meget billige arrays på tværs af mange servere for at spare omkostninger. I det virtuelle rum kunne dette betyde et lavtydende datalager brugt til OS-virtuelle diske og en anden, højtydende pulje til datavirtuelle diske. Dette ville have den samme effekt som SAN-boot-strategien, men i en mere moderne indstilling, og kunne let udnytte SAN-arkitekturen under hætten til at opnå det.

Endelig og mest dramatisk er det en generel tommelfingerregel med hypervisorer at installere dem på SD-kort eller USB-pendrev frem for til traditionel lagring, da deres ydeevne- og pålideligheds-behov er så meget mindre end selv traditionelle operativsystemer. Normalt, hvis et drev af denne art skulle fejle, mens et system kørte, ville det faktisk fortsætte med at køre uden problemer, da drevet aldrig bruges, når systemet først er bootet. Det er kun under en genstart, at et problem ville blive fundet, og på det tidspunkt kunne en backup-bootenhed bruges, såsom et sekundært SD-kort eller USB-stick. Dette er den officielle anbefaling for VMware vSphere, er ofte anbefalet af Microsoft-repræsentanter til HyperV og er officielt understøttet via HyperV's OEM-leverandører og anbefales ofte, men ikke så bredt understøttet, til Xen, XenServer og KVM-systemer. Brugen af SD-kort eller USB-drev til hypervisor-lagring forvandler effektivt en virtualiseringsserver til et indlejret system. Selv om dette kan føles unaturligt for systemadministratorer, der er vant til at tænke på traditionelle diske som en nødvendighed for servere, er det vigtigt at huske, at enterprise-klasse, meget kritiske systemer som routere og switches holder i årtier og bruger nøjagtig den samme strategi af nøjagtig de samme årsager.

En fælles strategi for hypervisorer i denne indlejrede stil-tilstand med SD-kort eller USB-drev er at have to sådanne enheder, som faktisk kan være et SD-kort og et USB-drev, hver med en kopi af hypervisoren. Hvis en enhed fejler, er opstart til den anden enhed næsten lige så effektiv som et traditionelt RAID 1-system. Men i modsætning til de fleste traditionelle RAID 1-opsætninger har vi også et relativt nemt middel til at teste systemopdateringer ved kun at opdatere én bootenhed ad gangen og teste processen, før den anden bootenhed opdateres, hvilket efterlader os med et pålideligt, godt testet tilbagefald i tilfælde af, at en versionsopdatering går galt. Denne proces var faktisk almindelig på store UNIX RISC-systemer, hvor bootenheder ofte var lokale software RAID 1-sæt, der understøttede en lignende praksis, særligt almindelig i AIX- og Solaris-kredse.

Det bør også bemærkes, at selv om denne tilgang er best practice for de fleste hypervisor-scenarier, er der faktisk ingen grund til, at den ikke kan anvendes på fulde operativsystemfilsystemer som godt, undtagen at det ofte er mere arbejde. Nogle operativsystemer, især Linux og BSD, er meget dygtige til at blive installeret på indlejret vis og kan let tilpasses til installation på SD-kort eller USB-drev med lidt planlægning. Denne tilgang er overhovedet ikke almindelig, men der er ingen teknisk grund til, at den i de rette omstændigheder ikke ville være en fremragende tilgang, undtagen at det næsten aldrig bør ske, at et operativsystem installeres på fysisk hardware frem for oven på en hypervisor. I de tilfælde, hvor fysiske installationer er nødvendige, er denne tilgang yderst gyldig.

Når du designer og planlægger lagersystemer, husk at være opmærksom på, hvad læse- og skrivensmønstre virkelig vil se ud som, når et system kører. Og husk, at lagring har ændret sig ret dramatisk siden mange traditionelle retningslinjer blev udviklet, og ikke al den viden, der blev brugt til at udvikle dem, gælder stadig i dag eller gælder lige meget. Tænk ikke kun på, hvilke lagerundersystemer der vil forsøge at bruge lagringensydeevne, men også på, hvordan de vil interagere med hinanden (for eksempel, anmoder to systemer aldrig om lageradgang på samme tid, eller vil de være i konflikt regelmæssigt), og om deres adgangsydeevne er vigtig. Generelle operativsystemfunktioner kan være exceedingly langsomme på en databaseserver uden negativ indvirkning; alt der betyder noget, er hastigheden, hvormed en database kan tilgås. Selv adgang til applikationsbinære filer er ofte irrelevant, da de også, når de er indlæst i hukommelsen, forbliver der, og kun hukommelseshastighed påvirker den løbende ydeevne.

Intet af dette er ment til at antyde, at adskillelse af operativsystem og datalagringsundersystemer fra hinanden er tilrådeligt; det er det ofte ikke. Jeg har tidligere skrevet om, hvordan konsolidering af disse undersystemer ret hyppigt er det bedste handlingsforløb, og det forbliver sandt nu. Men der er også mange rimelige tilfælde, hvor opdeling af visse lagringsbehov fra hinanden giver mening, ofte når man arbejder med storskala systemer, hvor vi kan sænke omkostningerne ved at dedikere dyr lagring til visse behov og billig lagring til andre behov, og det er i de tilfælde, hvor jeg ønsker at demonstrere, at operativsystemer og hypervisorer bør betragtes som den laveste prioritet med hensyn til både ydeevne og pålidelighed, undtagen i de mest ekstreme tilfælde.