RAID ZFS vs mdadm: komplett sammenligning for Linux-servere

Når du vurderer å sette opp en server lagring alvorlig i LinuxFør eller siden oppstår tvilen: Bør jeg gå for ZFS eller bruke mdadm med LVM og tradisjonell RAID? Ved første øyekast virker de som to måter å gjøre det samme på, men i virkeligheten responderer de på svært forskjellige filosofier og har direkte implikasjoner for ytelse, enkel administrasjon, pålitelighet og selvfølgelig hvor fredelig du vil sove når en disk begynner å svikte.

I denne artikkelen skal vi rolig bryte ned forskjellene mellom ZFS og mdadm (Linux-programvare-RAID)Gjennomgang av praktiske tilfeller, styrker og svakheter ved hver løsning, hvordan de oppfører seg med forskjellige RAID-nivåer (RAID0, RAID1, RAID5/6, RAID10, RAIDZ1/Z2…), hva som skjer med sikkerhetskopier, stille datakorrupsjon, RAM- eller CPU-bruk, og til og med hvordan hurtigbuffermoduser påvirker ytelsen. O_DIRECT i virtualiseringsmiljøer.

Hva er RAID, og ​​hvorfor er det viktig når man sammenligner ZFS og mdadm

Før vi går inn på ZFS og mdadm, er det verdt å huske nøyaktig hva en RAID løser og Hvilke ting løser den ikke, uansett hvor mye de noen ganger forveksles med sikkerhetskopierRAID står for «Redundant Array of Independent Disks», og det opprinnelige formålet var å kombinere flere små disker til én logisk enhet som tilbyr mer ytelse, mer brukbar kapasitet eller redundans mot fysiske feil.

Et RAID kan kombinere forskjellige teknikker som striping (distribuere data i blokker på tvers av flere disker), speiling og paritetAvhengig av hvordan du blander disse delene, får du forskjellige RAID-nivåer: RAID0 prioriterer ytelse, RAID1 den eksakte kopien på en annen disk, RAID5/6 distribuert paritet for å balansere plass og feiltoleranse, RAID10 blander speiling og striping, osv.

Nøkkelen er å forstå at RAID øker tilgjengeligheten og reduserer virkningen av en diskfeilMen det er ikke en erstatning for et godt sikkerhetskopieringssystem. Du kan miste data på grunn av logisk korrupsjon, utilsiktet sletting, ransomware eller en katastrofal feil på flere disker, og RAID vil ikke redde deg fra det.

Videre er ikke alle RAID-systemer implementert på samme måte: RAID-maskinvare med dedikerte kontrollere, kjerneintegrert RAID-programvare (mdadm) og hybridløsninger som ZFS eller Btrfs som kombinerer volumbehandler og filsystem i ett lag.

ZFS: Filsystem og volumbehandler i én pakke

ZFS er ikke bare «en annen type RAID»: Det er et 64-bits filsystem med en integrert volumbehandlerDette betyr at den, i motsetning til mdadm, ikke bare grupperer disker, men også vet hvordan data lagres på blokk- og metadatanivå, og kan ta intelligente beslutninger om integritet, hurtigbuffer, øyeblikksbilder eller komprimering.

I ZFS lager du en lagringsbasseng (zpool) bestående av én eller flere vdev-er. Hver vdev kan være et sett med disker i RAIDZ1, RAIDZ2, speil osv. De klassiske RAID-nivåene er fortsatt der, men med andre navn: RAIDZ1 ser ut som en RAID5, RAIDZ2 som en RAID6 og ZFS-speil tilsvarer RAID1- eller RAID10-kombinasjoner når du bruker flere speilte vdev-er.

Når du har zpoolen, ZFS monterer automatisk det tilknyttede filsystemetDet er ikke nødvendig å opprette en blokkenhet, deretter en LVM og deretter et separat filsystem. Du kan opprette datasett og zvols (blokkvolumer) i poolen, med forskjellige kvoter, komprimering eller egenskaper for hver.

En av ZFS' viktigste styrker er modellen deres for kopiering ved skriving (COW)Den overskriver aldri blokker på plass, men skriver i stedet den nye versjonen til en annen blokk og oppdaterer metadataene på slutten. Dette bidrar til å unngå det klassiske "skrivehull"-problemet i RAID 5/6, der et strømbrudd under en skriveoperasjon etterlater pariteten i en inkonsekvent tilstand.

Videre inkluderer ZFS innebygde funksjoner som du i mdadm/LVM/EXT4-verdenen måtte implementere med flere ekstra lag, for eksempel lette øyeblikksbilder, kloner, transparent komprimering, deduplisering, dataskrubbing med sjekksummer og avanserte hurtigbuffere. Zvols integreres veldig bra med hypervisorer for VM-lagring.

mdadm og LVM: Klassisk programvare-RAID i Linux

mdadm er standard Linux-verktøyet for administrasjon MD RAID (også kalt Linux-programvare-RAID)Det fungerer på blokknivå, uten å involvere et filsystem. Med mdadm oppretter du en /dev/mdX-enhet som grupperer flere fysiske disker eller partisjoner, og oppå den enheten legger du deretter filsystemet du ønsker (EXT4, XFS, osv.) eller en LVM.

Filosofien her er modulær: mdadm håndterer RAID, LVM håndterer logiske volumer, og filsystemet er kun ansvarlig for lagring av data.Dette gir mye fleksibilitet, men det betyr også flere lag og flere ting å konfigurere manuelt (fstab, skript osv.). boot, overvåkingspolicyer, Osv.).

Den grunnleggende syntaksen til mdadm følger en ganske logisk struktur: mdadm dispositivoDe vanligste modusene er --create for å opprette et nytt RAID, --assemble å sette sammen en eksisterende, --manage å administrere en aktiv matrise, --grow å utvide, og --detail for å se informasjon.

For eksempel vil det å opprette en RAID1 med to disker se omtrent slik ut: mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1Hvis arrayet allerede finnes og må monteres etter en omstart, bruker du --assemble som indikerer RAID-enheten og medlemsdiskene.

For mer avanserte konfigurasjoner kombineres ofte mdadm med LVM, slik at RAID-en gir en stor lagringsblokk og LVM lar deg dele den inn i flere logiske volumer av forskjellige størrelser, som filsystemer deretter monteres på og får tjenester på, virtuelle maskinerOsv

Viktige forskjeller mellom ZFS og mdadm: arkitektur og funksjoner

Den første store forskjellen er at ZFS integrerer RAID, volumbehandler og filsystemmens mdadm bare håndterer programvare-RAID-aspektet. Dette har en direkte innvirkning på hva slags ting du kan gjøre «native» med hver løsning.

I mdadm, hvis du vil øyeblikksbilder, volumkloning eller tynn provisjonering For virtuelle maskiner må du ty til LVM-tynne, snapshot-filsystemer (som Btrfs), eller flere lag. ZFS tilbyr alt dette som standard: ethvert datasett kan ha øyeblikksbilder og kloner i løpet av sekunder, og zvols integreres veldig bra med hypervisorer for VM-lagring.

En annen viktig forskjell er dataintegritetmdadm beskytter mot diskfeil takket være RAID, men den overvåker ikke hva som skjer i filsystemet eller legger til sjekksummer på datablokknivå. ZFS, derimot, beregner sjekksummer for alle datablokker og metadata, og under scrubs verifiserer den at det som leses samsvarer med det som forventes, og korrigerer fra en annen disk hvis den oppdager stille korrupsjon.

Det endrer også måten å utvide eller administrere lagringI mdadm kan du skalere RAID-nivåer ved å legge til disker og deretter endre størrelsen på LVM og filsystemet, men det er en delikat og relativt langsom prosess. ZFS lar deg legge til nye vdevs i zpoolen for å øke kapasiteten; hver vdev har imidlertid sin egen RAID-konfigurasjon, og datadistribusjon gjøres på vdev-nivå, noe du bør vurdere når du designer poolen.

Til slutt er den daglige ledelsen annerledes: ZFS har kommandoer veldig sammenhengende og beskrivende (zpool, zfs)Mens mdadm har et kraftig, men noen ganger lite intuitivt CLI, er du også avhengig av filer som /etc/mdadm.conf og /etc/fstab for at alt skal fungere som det skal ved oppstart.

Ytelse: RAID10, RAID5/6, RAIDZ og brukstilfeller fra den virkelige verden

Når det gjelder ytelse, finnes det ikke ett enkelt vinnende svar, fordi Det kommer mye an på hvilken type disk det er (HDD, SATA) SSD, NVMe), RAID-nivå og tilgangsmønster (sekvensiell vs. tilfeldig, lesing vs. skriving, blokkstørrelse osv.). Likevel er det ganske klare mønstre.

På klassiske harddisker og SATA SSD-er, ZFS yter vanligvis veldig bra.Dens kopierings-på-skriv-design og I/O-grupperingsmetoden har en tendens til å konvertere mange tilfeldige operasjoner til sekvensielle, noe som passer utmerket for mekanikken til mekaniske harddisker. Videre kan den utnytte RAM, L2ARC (lesebuffer i SSD-er) og ZIL/SLOG (skriveintensjonsregister) for å jevne ut topper og forbedre latens.

Men når all primærlagring er rask NVMe, ZFS når ikke alltid 100 % av potensialet sittDen ble designet i en tid der diskforsinkelse ga god plass til CPU-beregninger mens man ventet på disken; med NVMe blir CPU-en noen ganger flaskehalsen, noe som resulterer i ytelse under det en enkelt NVMe-disk ville levert "på egenhånd".

Når det gjelder mdadm, viser faktiske tester at Den tilbyr solid ytelse, spesielt i RAID0, RAID1 og RAID10.Imidlertid kan den falle bak maskinvare-RAID og ZFS i noen scenarier med programvare-RAID5/6, spesielt i skriveintensive operasjoner der paritetsberegninger og journalføring er mer skadelig.

Det finnes brukstilfeller i den virkelige verden der en stor RAID10 med mdadm (for eksempel 16 x 2 TB disker i RAID10 som måler over 1 GB/s teoretisk gjennomstrømning) når ikke disse tallene i praktisk bruk (reell trafikk, kopier via 10 GbEosv.). Teorien sier én ting, men hele stakken (nettverksprotokoll, CPU, filsystem, hurtigbuffere) begrenser ofte den endelige ytelsen til under arrayets rå maksimum.

Pålitelighet og typiske problemer: skrivehull, O_DIRECT og stille korrupsjon

Utover MB/s-tallene, er det som virkelig skiller ZFS og mdadm fra hverandre hvordan de håndterer feil og «stygge» scenarierstrømbrudd under skriving, stille korrupsjon, kjernefeil eller applikasjoner som bruker direkte disktilgangsmoduser.

Den berømte RAID-skrivehull Dette påvirker RAID 5/6-implementeringer der strømbrudd kan føre til at en dataskriving og pariteten blir ufullstendig, noe som fører til interne inkonsekvenser som er vanskelige å oppdage. RAID-kontrollere i maskinvaren reduserer dette med batteribeskyttet skrivehurtigbufring (BBU), og ZFS unngår det takket være COW-modellen, som bare anser den nye versjonen av dataene som gyldig når alt er skrevet riktig.

I Linux-verdenen er mdadm avhengig av mekanismer som journalføring og bitmaps For å redusere risikoen, er den fortsatt mer sårbar for disse scenariene enn ZFS eller en god maskinvare-RAID med beskyttet mellomlagring. Dette er merkbart både i pålitelighet og ytelse under skriveintensive arbeidsbelastninger, der journalføring faller direkte på trege disker.

Et annet sensitivt tema er bruken av O_DIRECT (cache «ingen» i virtuelle maskiner) I virtualiseringsmiljøer, når en virtuell maskin får tilgang til lagring ved hjelp av direkte enhetstilgang, kan programvare-RAID-en (md/dm) ende opp med å videresende den samme minnepekeren som flere uavhengige skrivinger til hver disk. Hvis en annen tråd endrer minnet mens disse skrivingene pågår, kan hver disk ende opp med å registrere forskjellig innhold, noe som forringer eller ødelegger RAID-en.

Det er til og med dokumentert et reelt tilfelle der En skriving til bytte pågår sammenfaller med utgivelsen av det minnetSwap-inngangen forkastes mens I/O fortsetter, og RAID-en ender opp med å markere arrayet som degradert. Teknisk sett O_DIRECT Den lover å «prøve å minimere effekten av mellomlagring», ikke å bryte konsistensen mellom replikaer, men i praksis er det en modus der du må være veldig forsiktig med MD RAID.

Hvis du unngår den hurtigbuffermodusen i virtuelle maskiner, eller vet nøyaktig hva du gjør, mdadm er helt gyldigDu bruker imidlertid litt mer RAM. Med ZFS, derimot, er hurtigbuffer og I/O-flytkontroll mye mer integrert i filsystemstakken, og risikoen for disse scenariene er betydelig redusert.

Praktiske eksempler: fra store RAID10-arrayer til ikke-redundante bassenger for virtuelle maskiner

For å se den filosofiske forskjellen mellom ZFS og mdadm, er det veldig nyttig å se gjennom virkelige bruksscenarier som gjenspeiler vanlige spørsmål fra administratorer og avanserte brukere.

I det første tilfellet har noen en server med Ubuntu og 16 x 2 TB disker i RAID10 ved bruk av mdadmRåhastigheten er utmerket, men den lider av et spesifikt pålitelighetsproblem: etter noen omstarter starter ikke arrayet opp ordentlig, noe som krever gjentatt demontering og gjenskaping. Dette er nettopp den typen situasjon RAID er ment å forhindre.

Noe av risikoen kommer fra det faktum at RAID10, slik det er satt opp nå, ikke tolererer det. to disker på rad feiler, og etterlater en hel stripe uten dataDet er akilleshælen til den spesifikke designen: den teoretiske feilbetingelsen som RAID10 ikke kan håndtere er oppfylt, og arrayet slutter å være rent gjenopprettbart.

I den situasjonen finnes det alternativer som å flytte til RAID50 (5 RAID5-striper med 3 disker hver, pluss en ekstra) eller RAID60 (2 RAID6-striper med 8 disker)Og ideen om å migrere alt til ZFS med tilsvarende konfigurasjoner oppstår også: fem 3-disk RAIDZ1 vdev-er (med en reservedisk) eller to 8-disk RAIDZ2 vdev-er, for å søke et kompromiss mellom ytelse og feiltoleranse.

Den logiske konklusjonen er at med så mange poster, Layoutdesignet er like viktig som den valgte teknologien.Et større antall vdevs gir vanligvis mer IOPS og gjennomstrømning, men øker også kompleksiteten ved håndtering av feil; et par store RAIDZ2 vdevs styrker feiltoleransen, men kan være noe mindre smidige under visse arbeidsbelastninger.

I et annet eksempel ønsker en administrator å sette opp et databasseng for virtuelle maskindisker der den absolutte prioriteten er å presse ut de 4 TB med kapasitet og oppnå god ytelse, uten å bekymre seg for mye om redundans, siden de virtuelle maskinene sikkerhetskopieres eksternt til annen lagring, til og med eksternt.

Avgjørelsen står mellom å sette opp en ZFS-pool i RAID0 eller en stabel basert på LVM-tynn på mdadm RAID0Begge tillater snapshots og tynn provisjonering for virtuelle maskiner, perfekt for online sikkerhetskopiering på plattformer som Proxmox. I dette tilfellet blir den typiske anbefalingen «ikke bruk RAID0 i produksjon» mindre relevant, fordi katastrofegjenoppretting er avhengig av eksterne sikkerhetskopier, ikke lokal robusthet.

Beslutningstakeren har omfattende erfaring med ZFS, men har knapt berørt mdadm/LVM. Dilemmaet her er ikke så mye pålitelighet (som allerede dekkes av sikkerhetskopier) som... enkel daglig administrasjon, plattformintegrasjon og vedvarende ytelse i virtualiseringsarbeidsbelastninger.

Maskinvare-RAID versus ZFS og mdadm: CPU, hurtigbuffer og portabilitet

Sammenligningen kan heller ikke ignorere rollen til RAID-maskinvare med dedikerte kontrollere, veldig vanlig i merkevareservere (Dell, HP, osv.). Et Dell H710P-kort (som mange LSI-kontrollereDen har sin egen prosessor, hurtigbuffer (ofte 1 GB) og BBU for å sikre at hurtigbufferskrivinger overlever et strømbrudd.

Den store fordelen med maskinvare-RAID er at Operativsystemet ser bare én logisk diskDette forenkler kompatibiliteten betraktelig og tillater bruk av så godt som alle operativsystemer uten bryderiet med komplekse RAID-programvarekonfigurasjoner. Dessuten merker den sentrale CPU-en knapt pariteten og den tunge I/O-arbeidsmengden, ettersom kontrolleren håndterer alt.

Men til gjengjeld gifter du deg med den kontrollerende kvinnen: Hvis den går i stykker, trenger du ofte nøyaktig samme modell for å kunne gjenopprette arrayet.Med RAID-programvare som mdadm eller ZFS, flytter du ganske enkelt diskene til en annen server med Linux og nødvendige verktøy; arrayet kan oppdages og settes sammen uten for mye problemer.

Et annet praktisk problem med kontrollere er avhengighet av produsentens administrasjonsverktøy og -verktøyDisse er ikke alltid godt vedlikeholdt for moderne distribusjoner. De inkluderer vanligvis et konfigurasjonsmiljø før oppstart (kontroller-BIOS/UEFI), men på forbrukerhovedkort blir maskinvaren noen ganger ikke engang oppdaget riktig.

Når det gjelder ytelse, leverer RAID-maskinvaren vanligvis i tester med åtte 4 TB WD Red Plus-disker i RAID 6 forbedrede sekvensielle lese- og skrivehastigheterZFS følges tett, mens mdadm kommer sist, spesielt for komplekse skrivinger. Den sannsynlige årsaken er at ZFS og maskinvare-RAID adresserer skrivehullet og utnytter raske mellomlagringsplasser, mens mdadm nesten utelukkende er avhengig av fysiske disker for journalføring og gjenoppbygging.

Ressursforbruk: RAM, CPU og swap

En av de mest gjentatte kommentarene om ZFS er at «Han elsker RAM»Og det er sant: jo mer minne som er tilgjengelig for ARC (Adaptive Replacement Cache), desto bedre kan den mellomlagre lesninger og forbedre ytelsen. På krevende servere anbefales det også å bruke ECC-minne, slik at ZFS ikke trenger å håndtere RAM-feil som kan ødelegge integriteten til kontrollsummene.

Når det gjelder CPU, bruker ZFS litt mer enn mdadm, spesielt hvis du aktiverer komprimering, deduplisering, eller du bruker mange avanserte funksjonerMed moderne CPU-er er imidlertid denne kostnaden vanligvis helt håndterbar i de fleste hjemme- og småbedriftsmiljøer, spesielt sammenlignet med merverdien av dataintegritet og øyeblikksbilder.

Det bør også nevnes at ZFS Det er ikke en god idé å administrere bytte.Et slags kappløp kan oppstå: tilgjengelig RAM reduseres, systemet vil bruke mer swap, ZFS prøver å utvide ARC-en sin eller administrere mer metadata, noe som bruker enda mer RAM, og du går inn i en ubehagelig sløyfe. Derfor er det vanlig praksis på servere der all datalagring er på ZFS å opprettholde en liten RAID1 med mdadm bare for bytte og kanskje basissystemet.

På mdadm-siden er RAM-forbruket mer beskjedent, siden mesteparten av hurtigbufferintelligensen håndteres av filsystemet du installerer oppå (for eksempel EXT4 eller XFS). CPU-en lider også mindre med ren mdadmMed RAID5/6 vil imidlertid paritetsberegning alltid ha en kostnad, enten det er programvare eller maskinvare.

Uansett viser testene at selv med veteran-CPUer av typen dual-Opteron, CPU-topper under gjenoppbygging av programvare-RAID er vanligvis ikke katastrofale.Det er sjeldent at de er den absolutte flaskehalsen sammenlignet med hastigheten på diskene.

Enkel daglig administrasjon og læringskurve

For noen som starter helt fra bunnen av, mdadm kan virke skremmende på grunn av syntaksenMen når du først har lært deg fire grunnleggende kommandoer, blir det relativt enkelt å administrere RAID 1 og RAID 10. Det samme gjelder LVM: det er vanskelig i starten, men deretter kan du enkelt navigere mellom fysiske volumer, volumgrupper og logiske volumer.

ZFS har på sin side Flere nye konsepter i begynnelsen: pools, vdevs, datasett, zvols, ARC, L2ARC, ZIL/SLOG, egenskaper, snapshots, scrubs…Læringskurven er brattere, men til gjengjeld løses mange vanlige oppgaver (opprette et nytt datasett med komprimering, ta et øyeblikksbilde, replikere data til en annen server) med et par svært sammenhengende kommandoer.

I den daglige administrasjonen vinner ZFS over mange administratorer fordi CLI-en er utformet som en sammenhengende helhetKommandoer som zpool status, zpool scrub, zfs list, zfs snapshot o zfs send | zfs recv De dekker de fleste handlinger med liten innsats. Med mdadm og LVM er handlinger spredt over flere verktøy og spredte konfigurasjonsfiler.

En annen styrke ved ZFS er replikering av sikkerhetskopiKombinasjonen av øyeblikksbilder med zfs send/recv Den lar deg sende inkrementelle datastrømmer til en annen ZFS-server svært effektivt, og bare kopiere endrede blokker. For et miljø med flere NAS-enheter eller servere er det en stor fordel å ha denne innebygde funksjonaliteten.

Med mdadm og tradisjonelle filsystemer kan du også montere replikering (rsyncLVM-snapshotverktøy og løsninger backup spesialisert osv.), men ingenting som er så tett koblet til filsystemlogikken som ZFS.

I den automatiske oppstarts- og monteringsdelen er det viktig å huske at En mdadm RAID-matrise vil ikke monteres automatisk etter en omstart hvis den ikke er riktig deklarert. i /etc/mdadm.conf og /etc/fstab. Det samme gjelder for alle filsystemer du plasserer oppå det. I ZFS håndterer systemet selv montering av datasett i henhold til egenskapene deres, noe som forenkler ting noe.

Etter å ha sett alle disse delene, er det tydelig at mdadm skinner når du ønsker en klassisk, enkel og svært integrert programvare-RAID i Linux.Spesielt i RAID 1/10-konfigurasjoner eller når du har RAM-begrensninger og ønsker noe diskré og velprøvd. ZFS, derimot, føles som den ideelle «alt-i-ett»-løsningen når du bryr deg om både dataintegritet og fleksibiliteten til å ta øyeblikksbilder, klone, komprimere og replikere uten å være avhengig av tusen eksterne verktøy.

I miljøer med store arbeidsmengder på mekaniske disker eller SATA-disker tilbyr ZFS vanligvis utmerket ytelse, og hvis du legger til NVMe som en hurtigbuffer... L2ARC Eller, som en "spesiell" vdev for metadata og små filer, kan den skaleres veldig bra. Der den kanskje kommer til kort, er i veldig enkle konfigurasjoner på rene NVMe-disker, hvor andre tilnærminger eller til og med frittstående disker med gode sikkerhetskopier kan tilby mer ytelse for mindre kompleksitet.

For situasjoner der Maksimal absolutt ytelse er avgjørende, og lokal redundans er ikke kritisk.Noen ganger er det mer fornuftig å bruke separate disker, automatisere hyppige sikkerhetskopier og droppe RAID for den spesifikke delen. I andre tilfeller kommer valget mellom ZFS og mdadm ned til å veie tidligere erfaring, tilgjengelige maskinvareressurser og hvor mye du verdsetter bekvemmeligheten av å ha alt integrert kontra enkelheten og rensligheten til klassisk programvare-RAID.