Praktiske RAID-Valg for Spindel-Baserte Arrays

En virkelig monumental mengde informasjon florerer i referanse til RAID-lagringssystemer som utforsker emner som risiko, ytelse, kapasitet, trender, tilnærminger og mer. Selv om arbeidet med dette emnet er nesten overveldende, kan informasjonen destilleres til en håndfull vanlige, praktiske lagringsmetoder som vil dekke nesten alle brukstilfeller. Mitt mål her er å gi en praktisk guide som vil la en ikke-lagringspraktiker nærme seg RAID-beslutningstaking på en praktisk og, viktigst av alt, trygg måte.

For formålene med denne guiden vil vi anta lagringsprosjekter på ikke mer enn tjuefem tradisjonelle disker (roterende tallerken-disker som egentlig kalles Winchester-disker.) Disse diskene kan vanligvis være SFF (2,5″) eller LFF (3,5″), SATA eller SAS, forbruker- eller enterprise-klasse. Vi vil ikke ta for oss solid state-disker da disse har svært ulike egenskaper og krever sin egen veiledning. Lagringssystemer større enn omtrent tjuefem spindler bør ikke operere fra standardveiledning, men gå dypere inn i spesifikke lagringsbehov for å sikre korrekt planlegging.

Veiledningen her er skrevet for standardsystemer i 2015. I løpet av de siste to tiårene har de vanlige tilnærmingene til RAID-lagring endret seg dramatisk, og selv om det ikke forventes at nøkkelfaktorene som påvirker disse beslutningene vil endre seg nok i fremtiden til å endre disse anbefalingene, er det svært mulig at de vil det. Godt RAID-design fra 1998 er svært dårlig RAID-design i dag. Endringstakten i bransjen har falt betydelig siden den tid, og disse anbefalingene er sannsynligvis holdbare i svært lang tid – muligens til spindel-basert disklagring ikke lenger er tilgjengelig eller i det minste populær – men som alle ting er forutsigelser gjenstand for store endringer.

Generelt bruker vi det som kalles en “One Big Array”-tilnærming. Det vil si et enkelt RAID-array der alle system- og datapartisjoner opprettes. Behovet eller ønsket om å dele lagringen vår inn i flere, fysiske arrays er stort sett borte i dag og bør kun gjøres under ikke-generelle omstendigheter. Bare i situasjoner der det gjøres nøye studie av lagringsbehovene og grundig analyse, bør vi se på array-oppdeling. Array-oppdeling er langt mer sannsynlig å forårsake skade enn nytte. Når du er i tvil, unngå delte arrays. Målet med denne guiden er generelle tommelfingerregler for å la enhver IT-profesjonell bygge et trygt og pålitelig lagringssystem. Tommelfingerregler dekker ikke og kan ikke dekke alle scenarioer – unntak finnes alltid. Men tanken her er å dekke det store flertallet av tilfeller med utprøvde og pålitelige tilnærminger som er utformet rundt moderne utstyr, brukstilfeller og behov, mens man er oppmerksom på å feile på siden av sikkerhet – når et valg er mindre enn ideelt er det fortsatt trygt. Ingen av disse valgene er i det hele tatt uforsiktige; på det verste er de altfor konservative.

Det første scenariet vi bør vurdere er om dataene dine ikke betyr noe. Dette kan høres ut som en merkelig ting å vurdere, men det er et svært viktig scenario. Det er mange ganger der data lagret på disk anses som flyktige og ikke trenger å beskyttes. Dette er vanlig for rekonstruerbare data som arbeidsrom for rendering, mellomliggende beregningsrom eller cacher – situasjoner der det er bortkastet å bruke penger på å beskytte data, og det ville være akseptabelt å ganske enkelt gjenskape tapte data i stedet for å beskytte dem. Dette kan være et tilfelle der nedetid ikke er et problem og data er statiske eller nesten det, og i stedet for å bruke penger på å redusere nedetid bekymrer vi oss bare om å beskytte data via sikkerhetskopieringsmekanismer slik at hvis et array svikter gjenoppretter vi ganske enkelt arrayet fullstendig. I disse tilfellene er det åpenbare valget RAID 0. Det er svært raskt, svært enkelt og gir den mest kostnadseffektive kapasiteten. Den eneste ulempen med RAID 0 er at det er skjørt og gir ingen beskyttelse mot datatap i tilfelle diskfeil eller til og med en URE (som ville forårsake datakorrupsjon på samme måte som en stasjonær disk opplever.)

Det bør bemerkes at et unntak fra “One Big Array”-tilnærmingen som ville være vanlig er i systemer som bruker RAID 0 for data. Det ville være et svært godt argument for et lite disk-array dedikert til OS og applikasjonsdata som ville være tungvint å installere på nytt i tilfelle array-tap, som holdes på RAID 1 og at RAID 0-data-arrayet er atskilt fra det. På denne måten kan gjenoppretting være svært rask i stedet for å måtte fullstendig gjenoppbygge hele systemet fra bunnen av i stedet for å ganske enkelt gjenskape dataene.

Forutsatt at vi har eliminert tilfeller der dataene ikke krever beskyttelse, vil vi anta for alle gjenværende tilfeller at dataene er ganske viktige og at vi ønsker å beskytte dem til en viss kostnad. Vi vil anta at det er viktig å beskytte dataene slik de eksisterer på det aktive lageret, generelt fordi vi ønsker å unngå nedetid eller fordi vi ønsker å sikre dataintegritet fordi dataene på disk ikke er statiske og en array-feil også ville utgjøre tap av data. Med denne forutsetningen vil vi fortsette.

Hvis vi har et array med bare to disker er svaret svært enkelt: vi velger RAID 1. Det er ikke noe annet alternativ i denne størrelsen, så ingen beslutning å ta. I teorien bør vi planlegge arrayene våre helhetlig og ikke etter at antall disker er bestemt; antall disker og typen array bør velges sammen, ikke disker kjøpt og deretter bruk bestemt basert på det vilkårlige antallet. Men to-disk-chassis er så vanlige at det er verdt å nevne som et tilfelle.

På samme måte er det eneste reelle valget å vurdere for et fire-disk-array RAID 10. Det er ikke nødvendig med ytterligere evaluering. Velg ganske enkelt RAID 10 og fortsett.

Et vanskelig tilfelle er et tre-disk-array. Det er svært, svært sjeldent at vi er begrenset til tre disker, da det eneste vanlige chassiset begrenset til tre disker var Apple Xserve, og dette har vært ute av markedet en stund, så behovet for å ta beslutninger rundt tre-spindel-arrays bør være ekstremt usannsynlig. I tilfeller der vi har tre disker er det ofte best å søke veiledning, men de vanligste tilnærmingene er å legge til en fjerde disk og dermed velge RAID 10, eller hvis kapasitet på mer enn én disks verdi ikke er nødvendig, å sette alle tre diskene inn i et enkelt triple-speil RAID 1.

For alle andre tilfeller har vi derfor å gjøre med fem til tjuefem disker. Siden vi har eliminert situasjonene der RAID 0 og RAID 1 ville gjelde, sitter vi igjen med at alle vanlige scenarioer koker ned til RAID 6 og RAID 10, og disse utgjør det store flertallet av tilfeller. Å velge mellom RAID 6 og RAID 10 blir den største utfordringen vi vil møte, da vi utelukkende må se på våre “myke” behov for pålitelighet, ytelse og kapasitet.

Å velge mellom RAID 6 og RAID 10 bør ikke være utrolig vanskelig. RAID 10 er ideelt for situasjoner der ytelse og sikkerhet er prioritetene. RAID 10 har mye raskere skriveytelse og er trygt uavhengig av disktype som brukes (rimelige forbruker-disker kan fortsatt være ekstremt trygge, selv i store arrays.) RAID 10 skalerer godt til ekstremt store størrelser, mye større enn det som bør implementeres ved hjelp av tommelfingerregler! RAID 10 er det tryggeste av alle valg, det er raskt og sikkert. De åpenbare ulempene er at RAID 10 har mindre lagringskapasitet fra de samme diskene og er dyrere på grunnlag av kapasitet. Det må nevnes at RAID 10 bare kan bruke et jevnt antall disker; disker legges til i par.

RAID 6 er generelt trygt og raskt, men aldri så trygt eller raskt som RAID 10. RAID 6 lider spesifikt av skriveytelse, så det er svært dårlig egnet for arbeidsbelastninger som databaser og tungt blandede belastninger som i store virtualiseringssystemer. RAID 6 er kostnadseffektivt og gir et sterkt fokus på tilgjengelig kapasitet sammenlignet med RAID 10. Når budsjettene er stramme eller kapasitetsbehov dominerer over ytelse, er RAID 6 et ideelt valg. Sjelden er forskjellen i sikkerhet mellom RAID 10 og RAID 6 en bekymring, bortsett fra i svært store systemer med forbrukerklasse-disker. RAID 6 er utsatt for ekstra risiko med forbrukerklasse-disker som RAID 10 ikke er påvirket av, noe som kan berettige noe bekymring rundt pålitelighet i større RAID 6-systemer som de over omtrent 40 TB når forbruker-disker brukes.

I småbedriftsrommet spesielt vil flertallet av systemer bruke RAID 10 rett og slett fordi arrays sjelden trenger å være større enn fire disker. Når arrays er større er RAID 6 det mer vanlige valget på grunn av noe stramme budsjetter og generelt lav bekymring rundt ytelse. Både RAID 6 og RAID 10 er trygge og effektive løsninger for nesten alle bruksscenarioer, med RAID 10 som dominerer når ytelse eller ekstrem pålitelighet er nøkkelen, og RAID 6 som dominerer når kostnad og kapasitet er nøkkelen. Og selvfølgelig, når lagringsbehovene er svært unike eller svært store – for eksempel større enn tjuefem spindler i et array – husk å benytte en lagringskonsulent da scenariet lett kan bli svært komplekst. Lagring er ett område der det lønner seg å være ekstra grundig, da så mye er avhengig av det, feil er så enkle å gjøre, og fleksibiliteten til å endre det etterpå er så lav.