Praktische RAID-keuzes voor Arrays op Basis van Schijven

Er is een werkelijk monumentale hoeveelheid informatie beschikbaar over RAID-opslagsystemen, waarin onderwerpen als risico, prestaties, capaciteit, trends, benaderingen en meer worden onderzocht. Hoewel het werk over dit onderwerp bijna duizelingwekkend is, kan de informatie worden teruggebracht tot een handvol gangbare, praktische opslagbenaderingen die vrijwel alle use cases dekken. Mijn doel hier is om een handige gids te bieden waarmee een professional zonder opslagachtergrond op een praktische en, het allerbelangrijkste, veilige manier RAID-beslissingen kan benaderen.

Voor de doeleinden van deze gids gaan we uit van opslagprojecten van niet meer dan vijfentwintig traditionele schijven (schijven met draaiende platters, formeel bekend als Winchester-schijven). Deze schijven kunnen gangbaar SFF (2,5″) of LFF (3,5″) zijn, SATA of SAS, consumenten- of ondernemingsklasse. We zullen solid-state drives niet behandelen, aangezien deze zeer verschillende eigenschappen hebben en hun eigen richtlijnen vereisen. Opslagsystemen die groter zijn dan ongeveer vijfentwintig schijven zouden niet vanuit standaardrichtlijnen moeten werken, maar dieper moeten ingaan op specifieke opslagbehoeften om een goede planning te waarborgen.

De richtlijnen hier zijn geschreven voor standaardsystemen in 2015. In de afgelopen twee decennia zijn de gangbare benaderingen van RAID-opslag dramatisch veranderd, en hoewel niet wordt verwacht dat de belangrijkste factoren die deze beslissingen beïnvloeden in de toekomst voldoende zullen veranderen om deze aanbevelingen te wijzigen, is het zeer wel mogelijk dat ze dat wel zullen doen. Een goed RAID-ontwerp uit 1998 is een zeer slecht RAID-ontwerp van vandaag. Het tempo van verandering in de branche is sinds die tijd aanzienlijk gedaald, en deze aanbevelingen zullen waarschijnlijk zeer lange tijd standhouden, zeer waarschijnlijk totdat opslag op basis van schijven niet langer beschikbaar of in elk geval populair is, maar zoals alle dingen zijn voorspellingen onderhevig aan grote verandering.

Over het algemeen gebruiken we wat een “One Big Array”-benadering wordt genoemd. Dat is een enkele RAID-array waarop alle systeem- en gegevenspartities worden aangemaakt. De noodzaak of wens om onze opslag op te splitsen in meerdere fysieke arrays is tegenwoordig grotendeels verdwenen en zou alleen onder niet-algemene omstandigheden moeten worden gedaan. Alleen in situaties waarin een zorgvuldige studie van de opslagbehoeften en een grondige analyse worden uitgevoerd, zouden we naar het opsplitsen van arrays moeten kijken. Het opsplitsen van arrays veroorzaakt veel waarschijnlijker schade dan dat het goed doet. Bij twijfel: vermijd opgesplitste arrays. Het doel van deze gids is om algemene vuistregels te bieden waarmee elke IT-professional een veilig en betrouwbaar opslagsysteem kan bouwen. Vuistregels dekken niet en kunnen niet elk scenario dekken; er bestaan altijd uitzonderingen. Maar het idee hier is om de overgrote meerderheid van de gevallen te dekken met beproefde benaderingen die zijn ontworpen rond moderne apparatuur, use cases en behoeften, terwijl we erop letten om aan de veilige kant te blijven – wanneer een keuze niet ideaal is, is deze nog steeds veilig. Geen van deze keuzes is op enigerlei wijze roekeloos; in het slechtste geval zijn ze overdreven behoudend.

Het eerste scenario dat we zouden moeten overwegen, is wanneer uw gegevens er niet toe doen. Dit klinkt misschien als een vreemde zaak om te overwegen, maar het is een zeer belangrijk scenario. Er zijn veel gevallen waarin gegevens die naar schijf worden weggeschreven als vluchtig worden beschouwd en niet beschermd hoeven te worden. Dit is gangbaar voor reconstrueerbare gegevens, zoals werkruimte voor rendering, tussentijdse berekeningsruimtes of caches – situaties waarin het uitgeven van geld om gegevens te beschermen verspilling is en het acceptabel zou zijn om verloren gegevens simpelweg opnieuw aan te maken in plaats van ze te beschermen. Dit kan een geval zijn waarin downtime geen probleem is en de gegevens statisch of vrijwel statisch zijn, en in plaats van te besteden om downtime te verminderen, maken we ons alleen druk om het beschermen van de gegevens via back-upmechanismen, zodat we, als een array uitvalt, de array simpelweg volledig herstellen. In deze gevallen is de voor de hand liggende keuze RAID 0. Het is zeer snel, zeer eenvoudig en biedt de meest kosteneffectieve capaciteit. Het enige nadeel van RAID 0 is dat het fragiel is en geen bescherming biedt tegen gegevensverlies bij schijfuitval of zelfs bij een URE (die gegevenscorruptie zou veroorzaken, net zoals een desktopschijf dat kent).

Opgemerkt moet worden dat een uitzondering op de “One Big Array”-benadering die gangbaar zou zijn, zich voordoet in systemen die RAID 0 gebruiken voor gegevens. Er zou een zeer goed argument te maken zijn voor een kleine schijfarray die is gewijd aan het OS en de applicatiegegevens die omslachtig opnieuw te installeren zouden zijn bij verlies van de array, en die op RAID 1 wordt gehouden, waarbij de RAID 0-gegevensarray daarvan gescheiden is. Op deze manier zou herstel zeer snel kunnen zijn, in plaats van dat het hele systeem volledig vanaf nul opnieuw moet worden opgebouwd in plaats van simpelweg de gegevens opnieuw aan te maken.

Ervan uitgaande dat we de gevallen hebben uitgesloten waarin de gegevens geen bescherming vereisen, gaan we voor alle resterende gevallen ervan uit dat de gegevens behoorlijk belangrijk zijn en dat we ze tegen een bepaalde prijs willen beschermen. We gaan ervan uit dat het beschermen van de gegevens zoals ze op de live opslag bestaan belangrijk is, over het algemeen omdat we downtime willen vermijden of omdat we de gegevensintegriteit willen waarborgen, aangezien de gegevens op schijf niet statisch zijn en een array-uitval ook gegevensverlies zou betekenen. Met deze aanname gaan we verder.

Als we een array van slechts twee schijven hebben, is het antwoord zeer eenvoudig: we kiezen RAID 1. Er is bij deze omvang geen andere optie, dus er valt geen beslissing te nemen. In theorie zouden we onze arrays holistisch moeten plannen en niet nadat het aantal schijven is bepaald; het aantal schijven en het gekozen type array zouden samen moeten worden bepaald, en niet eerst schijven kopen en vervolgens het gebruik bepalen op basis van dat willekeurige aantal, maar chassis voor twee schijven komen zo vaak voor dat het de moeite waard is om dit als geval te noemen.

Evenzo is bij een array van vier schijven de enige echte keuze om te overwegen RAID 10. Er is geen behoefte aan verdere evaluatie. Selecteer simpelweg RAID 10 en ga verder.

Een lastig geval is een array van drie schijven. Het komt zeer, zeer zelden voor dat we beperkt zijn tot drie schijven, aangezien het enige gangbare chassis dat tot drie schijven beperkt was de Apple Xserve was, en deze is al geruime tijd uit de markt, dus de noodzaak om met besluitvorming rond arrays van drie schijven om te gaan zou uiterst onwaarschijnlijk moeten zijn. In gevallen waarin we drie schijven hebben, is het vaak het beste om advies in te winnen, maar de meest gangbare benaderingen zijn om een vierde schijf toe te voegen en ergo RAID 10 te kiezen, of, als er geen capaciteit van meer dan één schijf nodig is, om alle drie de schijven in een enkele drievoudige-spiegel RAID 1 te plaatsen.

Voor alle overige gevallen hebben we dus te maken met vijf tot vijfentwintig schijven. Aangezien we de situaties hebben uitgesloten waarin RAID 0 en RAID 1 van toepassing zouden zijn, blijven we over met alle gangbare scenario's die neerkomen op RAID 6 en RAID 10, en deze vormen de overgrote meerderheid van de gevallen. De keuze tussen RAID 6 en RAID 10 wordt de grootste uitdaging waarmee we te maken krijgen, aangezien we uitsluitend moeten kijken naar onze “zachte” behoeften op het gebied van betrouwbaarheid, prestaties en capaciteit.

De keuze tussen RAID 6 en RAID 10 zou niet ongelooflijk moeilijk moeten zijn. RAID 10 is ideaal voor situaties waarin prestaties en veiligheid de prioriteiten zijn. RAID 10 heeft veel snellere schrijfprestaties en is veilig ongeacht het gebruikte schijftype (goedkope consumentenschijven kunnen nog steeds uiterst veilig zijn, zelfs in grote arrays). RAID 10 schaalt goed naar uiterst grote omvang, veel groter dan met vuistregels zou moeten worden geïmplementeerd! RAID 10 is de veiligste van alle keuzes; het is snel en veilig. De voor de hand liggende nadelen zijn dat RAID 10 minder opslagcapaciteit biedt uit dezelfde schijven en kostbaarder is op basis van capaciteit. Vermeld moet worden dat RAID 10 alleen een even aantal schijven kan gebruiken; schijven worden in paren toegevoegd.

RAID 6 is over het algemeen veilig en snel, maar nooit zo veilig of zo snel als RAID 10. RAID 6 lijdt specifiek onder de schrijfprestaties en is daarom zeer slecht geschikt voor werklasten zoals databases en zwaar gemengde belastingen zoals in grote virtualisatiesystemen. RAID 6 is kosteneffectief en legt een sterke nadruk op beschikbare capaciteit in vergelijking met RAID 10. Wanneer de budgetten krap zijn of de capaciteitsbehoeften zwaarder wegen dan de prestaties, is RAID 6 een ideale keuze. Zelden is het verschil in veiligheid tussen RAID 10 en RAID 6 een zorg, behalve in zeer grote systemen met schijven van consumentenklasse. RAID 6 is onderhevig aan een extra risico met schijven van consumentenklasse waar RAID 10 niet door wordt beïnvloed, wat enige zorg over de betrouwbaarheid kan rechtvaardigen in grotere RAID 6-systemen, zoals die boven ongeveer 40 TB wanneer er consumentenschijven worden gebruikt.

Met name in het mkb-segment zal de meerderheid van de systemen RAID 10 gebruiken, simpelweg omdat arrays zelden groter dan vier schijven hoeven te zijn. Wanneer arrays groter zijn, is RAID 6 de gangbaardere keuze vanwege enigszins krappe budgetten en de over het algemeen geringe zorg over prestaties. Zowel RAID 6 als RAID 10 zijn veilige en effectieve oplossingen voor vrijwel alle gebruiksscenario's, waarbij RAID 10 domineert wanneer prestaties of extreme betrouwbaarheid de sleutel zijn en RAID 6 domineert wanneer kosten en capaciteit de sleutel zijn. En vergeet natuurlijk niet om, wanneer de opslagbehoeften zeer uniek of zeer groot zijn, zoals groter dan vijfentwintig schijven in een array, een opslagconsultant in te schakelen, aangezien het scenario gemakkelijk zeer complex kan worden. Opslag is een van de plekken waar het loont om extra nauwgezet te zijn, aangezien er zoveel van afhangt, fouten zo gemakkelijk te maken zijn en de flexibiliteit om het achteraf te wijzigen zo gering is.