Trage OS-schijven, Snelle Gegevensschijven

In de loop der jaren heb ik gemerkt dat mensen vaak kiezen voor hoogwaardige, zeer betrouwbare gegevensopslag voor een besturingssysteempartitie, maar trage, “kosteneffectieve” opslag kiezen voor kritieke gegevensopslag. Ik sta versteld van hoe vaak ik dit zie gebeuren, en nu, met de komst van hypervisors, zie ik datzelfde gedrag ook daar herhaald worden – wat de reeds bestaande problemen verergert.

In veel systemen hebben we tegenwoordig te maken met slechts één enkele opslagarray die door alle componenten van het systeem wordt gedeeld. In deze gevallen lopen we niet tegen het probleem aan dat we de prestaties van ons opslagsysteem uit balans brengen. Dit is een van de grote voordelen van deze benadering en een belangrijke reden waarom deze zo sterk wordt aanbevolen. Alle prestaties bevinden zich in een gedeelde pool en de componenten die de prestaties nodig hebben, hebben er toegang toe.

In veel gevallen, of het nu is uit een poging tot verbeterd ontwerp voor prestaties of betrouwbaarheid of uit technische noodzaak, merk ik dat mensen hun opslagarrays opsplitsen en hypervisors en besturingssystemen op de ene array zetten en gegevens op de andere. Maar wat ik schokkend vind, is dat arrays die aan de hypervisor of het besturingssysteem zijn gewijd, vaak verbluffend groot zijn in capaciteit en uiterst hoog in prestaties – vaak met 15.000 RPM-schijven of zelfs solid-state drives tegen hoge kosten. Bijna altijd in RAID 1 (volgens de gangbare standaarden uit 1998).

Wat hier begrepen moet worden, is dat besturingssystemen zelf in feite geen opslag-IO-vereisten hebben. Er is een kleine hoeveelheid, voornamelijk voor systeemlogging, maar dat is ongeveer alles wat nodig is. Besturingssysteempartities zijn bijna volledig statisch. Vereiste componenten worden in het geheugen geladen, voornamelijk tijdens het opstarten, en worden daarna niet meer benaderd. Zelfs in gevallen waarin logging nodig is, worden deze logs vaak naar een centraal loggingsysteem gestuurd en niet naar de opslagruimte van het systeem, wat die behoefte vermindert of zelfs wegneemt.

Bij hypervisors is dit effect zelfs nog extremer. Aangezien hypervisors veel lichter en minder robuust zijn dan traditionele besturingssystemen, gedragen ze zich meer als embedded systemen en zijn ze in veel opzichten in veel gevallen daadwerkelijk embedded systemen. Hypervisors laden tijdens het opstarten van het systeem in het geheugen en hun medium is daarna vrijwel nooit meer nodig terwijl een systeem draait, behalve soms voor logging. Omdat hypervisors klein zijn in fysieke omvang, is zelfs de totale tijd die nodig is om een volledige hypervisor van de opslag te lezen zeer klein, zelfs op zeer traag medium, omdat de totale omvang zeer klein is.

Om deze redenen zijn opslagprestaties van weinig tot geen belang voor besturingssystemen en in het bijzonder hypervisors. Het verschil tussen snelle opslag en trage opslag heeft eigenlijk alleen invloed op de opstarttijd van het systeem, waarbij het verschil tussen één seconde of dertig seconden zelden zou worden opgemerkt, als het al wordt opgemerkt. Wanneer zou iemand zelfs een paar extra seconden tijdens het opstarten van een systeem waarnemen, en in de meeste gevallen zijn opstarts zeldzame gebeurtenissen die hooguit eenmaal per week plaatsvinden tijdens een geautomatiseerde, routinematige systeemherstart binnen een gepland onderhoudsvenster, of zeer zelden, soms slechts eenmaal in de paar jaar, voor systemen die alleen in noodgevallen offline worden gehaald. Zelfs het traagst denkbare opslagsysteem is veel sneller dan voor deze rol noodzakelijk is.

Zelfs trage opslag is over het algemeen vele malen sneller dan noodzakelijk is voor systeemloggingactiviteiten. In die zeldzame gevallen waarin de logging zeer intensief is, hebben we veel keuzes om dit probleem aan te pakken. De meest voor de hand liggende en gangbare oplossing hier is om logs naar een andere schijfarray te sturen dan die welke door het besturingssysteem of de hypervisor wordt gebruikt. Dit is een zeer eenvoudige oplossing en uiteindelijk zeer praktisch in gevallen waarin dit gerechtvaardigd is. De andere gangbare en zeer nuttige oplossing is om de logs simpelweg helemaal niet op het lokale apparaat te bewaren en ze naar een externe logverzamelingstool zoals Splunk, Loggly of ELK te sturen.

De andere belangrijke zorg die de meeste mensen hebben rond hun besturingssystemen en hypervisors is betrouwbaarheid. Het is gangbaar om meer inspanningen te richten op het beschermen van deze relatief onbelangrijke aspecten van een systeem dan op de vaak onvervangbare gegevens. Besturingssystemen en hypervisors zijn echter gemakkelijk vanaf nul opnieuw op te bouwen wanneer dat nodig is, met behulp van verse installaties en, indien nodig, handmatige herconfiguratie. De details die verloren zouden kunnen gaan, zijn over het algemeen relatief triviaal om opnieuw aan te maken.

Dit betekent niet dat deze systeembestandssystemen niet geback-upt zouden moeten worden, dat zouden ze natuurlijk wel moeten (in de meeste gevallen). Maar zelfs voor het geval dat de back-ups ook mislukken, is het zelden zo dat het verlies van een OS-partitie of -bestandssysteem werkelijk een ramp betekent, maar slechts een ongemak. Er zijn in vrijwel alle gevallen manieren om te herstellen zonder toegang tot de originele gegevens, zolang het “gegevens”-bestandssysteem maar gescheiden is. En vanwege de aard van besturingssystemen en hypervisors zijn veranderingen zeldzaam, dus back-ups kunnen over het algemeen minder frequent zijn, mogelijk alleen handmatig getriggerd wanneer er updates worden toegepast!

Met veel moderne systemen in de DevOps- en cloudcomputing-omgevingen is het zeer gangbaar geworden om besturingssysteem- en hypervisorbestandssystemen als volledig wegwerpbaar te beschouwen, aangezien ze op afstand worden gedefinieerd via een systeemimage of door een configuratiebeheersysteem. In deze gevallen, die steeds gangbaarder worden, is er geen behoefte aan gegevensbescherming of back-ups, aangezien het hele systeem is ontworpen om vrijwel onmiddellijk opnieuw te worden aangemaakt, zonder enige speciale interactie. Het systeem is volledig zelfreplicerend. Dit trivialiseert de behoefte aan bescherming van het systeembestandssysteem verder.

Alles bij elkaar genomen, het gebrek aan behoefte rond prestaties en het gebrek aan behoefte rond bescherming en betrouwbaarheid, dat primair wordt afgehandeld door eenvoudige heraanmaak, en wat we hebben is een systeembestandssysteem met heel andere behoeften dan we gewoonlijk aannemen. Dit betekent niet dat we roekeloos moeten zijn met onze opslag; we willen nog steeds opslaguitval voorkomen terwijl een systeem draait, en onnodig opnieuw opbouwen is een verspilling van tijd en middelen, ook al blijkt het niet rampzalig te zijn. Het zorgvuldig vinden van een evenwicht is dus belangrijk.

Het is natuurlijk om deze redenen dat het opnemen van het besturingssysteem of de hypervisor op dezelfde opslagarray als de gegevens nu gangbare praktijk is – omdat er weinig tot geen behoefte is aan opslagtoegang tot de systeembestanden op hetzelfde moment dat er toegang is tot de gegevensbestanden, dus we krijgen een grote synergie door snelle opstarttijden voor het OS te verkrijgen en geen nadelig effect op de toegangstijden tot de gegevens zodra het systeem online is. Dit is het belangrijkste middel waarmee systeemontwerpers tegenwoordig de behoefte aan efficiënt gebruik van opslag aanpakken.

Wanneer het besturingssysteem of de hypervisor gescheiden moet worden van de arrays die de gegevens bevatten, wat nog steeds om talloze redenen kan gebeuren, streven we er over het algemeen naar om tegen lage kosten een redelijke betrouwbaarheid te verkrijgen. Bij het gebruik van traditionele opslag (lokale schijven) betekent dit het gebruik van kleine, trage, goedkope draaiende schijven voor besturingssysteemopslag, over het algemeen in een eenvoudige RAID 1-configuratie. Een praktijkvoorbeeld is het gebruik van 5400 RPM “milieuvriendelijke” SATA-schijven in de kleinst mogelijke formaten. Deze verbruiken weinig stroom en zijn zeer goedkoop in aanschaf. SSD's en SAS-schijven met hoge snelheid zouden worden vermeden, aangezien ze een meerprijs vragen voor bescherming die irrelevant is en prestaties die volledig worden verspild.

Bij minder traditionele opslag is het gangbaar om een goedkope SAN met hoge dichtheid te gebruiken, waarbij de opslag met lage prioriteit voor veel systemen wordt geconsolideerd op gedeelde, trage arrays die niet worden gerepliceerd. Dit is alleen effectief in grotere omgevingen die het aanvullende architectuurontwerp kunnen rechtvaardigen en die voldoende dichtheid in het opslagconsolidatieproces kunnen bereiken om de noodzakelijke kostenbesparingen te creëren, maar in grotere omgevingen is dit relatief eenvoudig. SAN-bootapparaten kunnen gebruikmaken van zeer goedkope arrays over veel servers voor kostenbesparingen. In de virtuele ruimte zou dit een datastore met lage prestaties kunnen betekenen die wordt gebruikt voor virtuele OS-schijven en een andere, hoogwaardige pool voor virtuele gegevensschijven. Dit zou hetzelfde effect hebben als de boot-SAN-strategie, maar in een modernere setting, en zou gemakkelijk de SAN-architectuur onder de motorkap kunnen benutten om dit te bereiken.

Tot slot, en het meest dramatisch, is het bij hypervisors een algemene vuistregel om ze te installeren op SD-kaarten of USB-sticks in plaats van op traditionele opslag, aangezien hun prestatie- en betrouwbaarheidsbehoeften zelfs nog veel geringer zijn dan die van traditionele besturingssystemen. Normaal gesproken, als een schijf van deze aard zou uitvallen terwijl een systeem draait, zou het systeem zonder enig probleem blijven draaien, aangezien de schijf nooit meer wordt gebruikt zodra het systeem aanvankelijk is opgestart. Pas tijdens een herstart zou er een probleem worden ontdekt en op dat moment zou er een back-up-bootapparaat kunnen worden gebruikt, zoals een tweede SD-kaart of USB-stick. Dit is de officiële aanbeveling voor VMware vSphere, wordt vaak aanbevolen door vertegenwoordigers van Microsoft voor HyperV en wordt officieel ondersteund via de OEM-leveranciers van HyperV, en wordt vaak aanbevolen, maar niet zo breed ondersteund, voor Xen-, XenServer- en KVM-systemen. Het gebruik van SD-kaarten of USB-schijven voor hypervisoropslag verandert een virtualisatieserver in feite in een embedded systeem. Hoewel dit onnatuurlijk kan aanvoelen voor systeembeheerders die gewend zijn om traditionele schijven als een noodzaak voor servers te beschouwen, is het belangrijk om te onthouden dat zeer kritieke systemen van ondernemingsklasse zoals routers en switches tientallen jaren meegaan en exact dezelfde strategie om exact dezelfde redenen gebruiken.

Een gangbare strategie voor hypervisors in deze embedded stijl met SD-kaarten of USB-schijven is om twee van dergelijke apparaten te hebben, die in de praktijk een SD-kaart en een USB-schijf kunnen zijn, elk met een kopie van de hypervisor. Als één apparaat uitvalt, is opstarten naar het tweede apparaat vrijwel net zo effectief als een traditioneel RAID 1-systeem. Maar in tegenstelling tot de meeste traditionele RAID 1-opstellingen hebben we ook een relatief eenvoudig middel om systeemupdates te testen door slechts één bootapparaat tegelijk bij te werken en het proces te testen voordat we het tweede bootapparaat bijwerken, waardoor we een betrouwbare, goed geteste terugvaloptie hebben voor het geval een versie-update misgaat. Dit proces was eigenlijk gangbaar op grote UNIX RISC-systemen, waar bootapparaten vaak lokale software-RAID 1-sets waren die een soortgelijke praktijk ondersteunden, wat vooral gangbaar was in AIX- en Solaris-kringen.

Ook moet worden opgemerkt dat hoewel deze benadering de best practice is voor de meeste hypervisorscenario's, er eigenlijk geen reden is waarom deze niet ook op volledige besturingssysteembestandssystemen kan worden toegepast, behalve dat het vaak meer werk is. Sommige besturingssystemen, met name Linux en BSD, zijn zeer bedreven in het op een embedded manier worden geïnstalleerd en kunnen met een beetje planning gemakkelijk worden aangepast voor installatie op een SD-kaart of USB-schijf. Deze benadering is helemaal niet gangbaar, maar er is geen technische reden waarom dit onder de juiste omstandigheden geen uitstekende benadering zou zijn, behalve het feit dat een OS vrijwel nooit op fysieke hardware geïnstalleerd zou moeten worden in plaats van bovenop een hypervisor. In die gevallen waarin fysieke installaties noodzakelijk zijn, is deze benadering uiterst valide.

Houd bij het ontwerpen en plannen van opslagsystemen voor ogen hoe de lees- en schrijfpatronen er werkelijk uit zullen zien wanneer een systeem draait. En onthoud dat opslag sinds de ontwikkeling van veel traditionele richtlijnen vrij dramatisch is veranderd en dat niet alle kennis die is gebruikt om ze te ontwikkelen vandaag de dag nog van toepassing is of in gelijke mate van toepassing is. Denk niet alleen na over welke opslagsubsystemen opslagprestaties zullen proberen te gebruiken, maar ook over hoe ze met elkaar zullen interageren (vragen twee systemen bijvoorbeeld nooit op hetzelfde moment om opslagtoegang of zullen ze regelmatig met elkaar conflicteren) en of hun toegangsprestaties al dan niet belangrijk zijn. Algemene besturingssysteemfuncties kunnen op een databaseserver uitermate traag zijn zonder negatief effect; het enige dat telt is de snelheid waarmee een database kan worden benaderd. Zelfs toegang tot applicatiebinaries is vaak irrelevant, aangezien ook deze, zodra ze in het geheugen zijn geladen, daar blijven en alleen de geheugensnelheid de doorlopende prestaties beïnvloedt.

Niets hiervan is bedoeld om te suggereren dat het scheiden van OS- en gegevensopslagsubsystemen van elkaar wordt aangeraden; vaak is dat niet zo. Ik heb in het verleden geschreven over hoe het consolideren van deze subsystemen zeer vaak de beste handelwijze is, en dat blijft nu waar. Maar er zijn ook veel redelijke gevallen waarin het zinvol is om bepaalde opslagbehoeften van elkaar te scheiden, vaak bij het omgaan met grootschalige systemen waar we de kosten kunnen verlagen door dure opslag aan bepaalde behoeften te wijden en goedkope opslag aan andere behoeften, en het is in die gevallen waarin ik wil aantonen dat besturingssystemen en hypervisors, behalve in de meest extreme gevallen, beschouwd zouden moeten worden als de laagste prioriteit op het gebied van zowel prestaties als betrouwbaarheid.