Gå til innhold

Organiser hjemmenettverket


Anbefalte innlegg

At ZFS-array ikke jobber direkte mot en fysisk disk, men gjennom virtuelle enheter som kan bestå av både enkeltdisker og ulike raid-nivåer er jo bare utrolig praktisk. Har man f.eks. et array med én zpool bestående av fire disker i raid-Z og ønsker å utvide dette, kan man f.eks. bare kjøpe to nye disker, lage en ny zpool av disse og koble dem til det eksisterende ZFS-arrayet. Dette vil nå bestå at to zpools, hvor ett har raid-5 og ett har raid-1.

 

At det bare tar noen sekunder å initialisere en ny vpool, sammenliknet med timer og dager kontra et vanlig raid er jo også en fordel...

 

Ja ZFS er bedre enn Raid, og på noen områder er den også bedre enn DE/Greyhole, men DE/Greyhole har fordeler som gjør at det er en utmerket løsning for hjemmeservere. Du sier f.eks. at det bare er å kjøpe inn to disker og sette disse opp i ett Zpool mirror så "mister" du jo 50% av lagringsplassen. I DE/Greyhole så foregår dupliseringen på sharenivå slik at du f.eks. kan duplisere alle bildene du har tatt, men la være å duplisere alle podcastene du har lastet ned.

 

Du er heller ikke avhengig av å bruke disker av samme størrelse. Det er du riktignok ikke i ZFS heller, men da mister du lagringsplass. (1x 1TB og 1x500GB disk i Raid1 gir f.eks. bare 500GB lagringsplass i RaidZ1, men i DE vil du kan 1,5TB og fortsatt kunne duplisere data over flere disker.

 

Og selv om 3 av 4 disker i poolet dør så vil du fortsatt ha dataen som ligger på den 4. disken.

 

Det tar heller ikke noe voldsomt med tid å legge til en ny harddisk, du bare plugger den inn og trykker på legg til og så tar det kanskje ett par minutter før den er klar (har aldri tatt tida så har ikke nøyaktig tall).

 

Personlig dupliserer jeg ikke noe data på filserveren da jeg ikke ser noe poeng i det, isteden har jeg full backup av min 30TB filserver på disker som er lagret en annen plass. Og når vi får fiber iløpet av våren vil jeg også bruke Crashplan for å ta backup av filserveren.

Lenke til kommentar
Videoannonse
Annonse

At ZFS-array ikke jobber direkte mot en fysisk disk, men gjennom virtuelle enheter som kan bestå av både enkeltdisker og ulike raid-nivåer er jo bare utrolig praktisk. Har man f.eks. et array med én zpool bestående av fire disker i raid-Z og ønsker å utvide dette, kan man f.eks. bare kjøpe to nye disker, lage en ny zpool av disse og koble dem til det eksisterende ZFS-arrayet. Dette vil nå bestå at to zpools, hvor ett har raid-5 og ett har raid-1.

Problemet er jo at det er en veldig lite effektiv måte å gjøre det på. Jeg har nå tre 1,5TB-disker i Raid-Z-konfigurasjon, og kunne gjerne tenkt meg å legge til en til i samme zpool, og få redundans også på denne disken.

 

Men det kan jeg ikke. Skal jeg da utivde plassen, må jeg kjøpe to disker, og legge de til som en egen raid-z-vdev i den eksisterende zpoolen. Det medøfrer at jeg kaster bort 2TB (om jeg kjøper TB-disker), og det er selvfølgelig ikke ønskelig. I tillegg må jeg ha to disker gående i stedet for en, noe som krver en ekstra sata-port og mer strøm. Det er det største ankepunktet mot ZFS slik jeg ser det,for det rammer der ZFS er best ellers: fleksibiliteten og sømløsheten. Jeg vil (og bør) kunne kjøpe 1,5TB til og få ~1.5TB mer i lagringsplass. Så vidt jeg har fått med meg, er det funksjonalitet som er/skal være i btrfs.

 

For en hjemmebruker/mindre bedrifter kan det være et ganske stort ankepunkt

 

hvakrg: Litt usikker på om Greyhole innebærer noen performance penalty om du kjører programmer på den som oppretter mye empfiler eller liknende, men så lege du kan montere det i filsystemet, kan hva som helst kjøres på det. Så vidt jeg forstod, kan man det, selv om det primære bruksområdet er samspill med samba. Linuxprogrammer forholder seg ikke til partisjonsbokstaver, men til stier i filsystemet (uansett hvilke fysiske disker disse ligger på.)

 

Det som virket veldig upraktisk med greyhole, er jo at du bare får brukt halve plassen, dersom du vil ha redundans. Den lager en fysisk kopi på en annen disk derosm du velger å ha redundancy på en share.

Lenke til kommentar

hvakrg: Litt usikker på om Greyhole innebærer noen performance penalty om du kjører programmer på den som oppretter mye empfiler eller liknende, men så lege du kan montere det i filsystemet, kan hva som helst kjøres på det. Så vidt jeg forstod, kan man det, selv om det primære bruksområdet er samspill med samba. Linuxprogrammer forholder seg ikke til partisjonsbokstaver, men til stier i filsystemet (uansett hvilke fysiske disker disse ligger på.)

 

Det som virket veldig upraktisk med greyhole, er jo at du bare får brukt halve plassen, dersom du vil ha redundans. Den lager en fysisk kopi på en annen disk derosm du velger å ha redundancy på en share.

 

Ok, men da er det pga at Linux fungerer annerledes enn Windows på dette området og ikke pga at Greyhole har løst det Microsoft ikke klarte. Regner med at ting kommer til å endre seg når Kanskje dette er noe Microsoft ønsker å ordne med Jupiter?

 

Noen vil kanskje kalle det upraktisk, men det at man faktisk får en fullverdig kopi på en annen disk og derfor er sikret mot problemer som kan oppstå om man på gjenoppbygge ett Raid gjør det verdt det. Og når man selv får bestemme hvilke shares en vil duplisere.

Lenke til kommentar

Joda, det er jo smak og behag. Selv er jeg fornøyd så lenge jeg har redundans, det er ok for meg å ikke bare kunne nappe ut en disk og putte den i en annen maskin. Med softwareløsninger som ZFS eller linux software raid kan man gjenopprette raidet på ulike systemer uten å vøre avhengig av et bestemt chipset/kontrollerkort, og det er godt nok for meg.

Lenke til kommentar
Problemet er jo at det er en veldig lite effektiv måte å gjøre det på. Jeg har nå tre 1,5TB-disker i Raid-Z-konfigurasjon, og kunne gjerne tenkt meg å legge til en til i samme zpool, og få redundans også på denne disken.

Noen kjappe google-søk1 og google-søk1 gir disse treffene:

 

http://lildude.co.uk/growing-a-zfs-root-pool

http://rskjetlein.blogspot.com/2009/08/expanding-zfs-pool.html

 

Ser ut at en kan både utvide en eksisterende zpool ved å legge til en ekstra disk og oppgradere et zpool ved å bytte ut én og én disk. Men det skal vel sies at metodene føles litt "hacker-aktig" og jeg er ikke sikker på om jeg ville gjort det med kritiske data...

Endret av indeksregulert
Lenke til kommentar

Joda, det er jo smak og behag. Selv er jeg fornøyd så lenge jeg har redundans, det er ok for meg å ikke bare kunne nappe ut en disk og putte den i en annen maskin. Med softwareløsninger som ZFS eller linux software raid kan man gjenopprette raidet på ulike systemer uten å vøre avhengig av et bestemt chipset/kontrollerkort, og det er godt nok for meg.

 

ZFS er fint det, og jeg hadde nok brukt det om det var på windows, og kanskje også på linux. Men det har sine ulemper, i at det mangler felksibilitet, en slags hybrid hadde jo vært helt krem. Det kan også nevnes at man som oftest ikke er avhengig av et kontrollerkort i praksis, det finnes gjenopprettingsprogrammer som gjør jobben selv om kontrollerkortet har tatt kvelden.

 

AtW

Lenke til kommentar
Ja ZFS er bedre enn Raid, og på noen områder er den også bedre enn DE/Greyhole, men DE/Greyhole har fordeler som gjør at det er en utmerket løsning for hjemmeservere. Du sier f.eks. at det bare er å kjøpe inn to disker og sette disse opp i ett Zpool mirror så "mister" du jo 50% av lagringsplassen. I DE/Greyhole så foregår dupliseringen på sharenivå slik at du f.eks. kan duplisere alle bildene du har tatt, men la være å duplisere alle podcastene du har lastet ned.

Nå er ikke jeg typen som pleier å lagre podcaster på filserveren, i midt tilfelle har jeg uansett utelukkende data jeg ønsker å ha redundans på lagret på filserveren. Så hos meg vil en raid-løsning definitivt være det beste.

 

I tilfeller hvor en kun trenger redundans på en brøkdel av filene en lagrer på filserveren er jeg helt enig i at en løsning som DE vil være en bedre metode.

Lenke til kommentar

http://lildude.co.uk/growing-a-zfs-root-pool

http://rskjetlein.blogspot.com/2009/08/expanding-zfs-pool.html

 

Ser ut at en kan både utvide en eksisterende zpool ved å legge til en ekstra disk og oppgradere et zpool ved å bytte ut én og én disk. Men det skal vel sies at metodene føles litt "hacker-aktig" og jeg er ikke sikker på om jeg ville gjort det med kritiske data...

Nei, hvis du leser likene du har lagt ved, ka du IKKE legge flere disker til et Raid-z /derfor har i stedet utvidet slizen ZFS root-en ligger på, men det hr ingen overføringsverdi til en lagringsserver der man bruker hele disken. Ellers er det helt riktig at man kan bytte ut en og en disk med en større en - men da må man bytte ut samtlige disker. Det kan gå greit for mine tre disker, men er neppe like aktuelt for et univeristet med 50 1.5TB-dsiker som trenger mer plass, f.eks. Skjønt, om man legger til fire i slenge, mister man jo bare 1/4 av plassen, og det er kanskje aktuelt om man har såpass mange disker i utgangspunktet.

 

 

Joda, det er jo smak og behag. Selv er jeg fornøyd så lenge jeg har redundans, det er ok for meg å ikke bare kunne nappe ut en disk og putte den i en annen maskin. Med softwareløsninger som ZFS eller linux software raid kan man gjenopprette raidet på ulike systemer uten å vøre avhengig av et bestemt chipset/kontrollerkort, og det er godt nok for meg.

 

ZFS er fint det, og jeg hadde nok brukt det om det var på windows, og kanskje også på linux. Men det har sine ulemper, i at det mangler felksibilitet, en slags hybrid hadde jo vært helt krem. Det kan også nevnes at man som oftest ikke er avhengig av et kontrollerkort i praksis, det finnes gjenopprettingsprogrammer som gjør jobben selv om kontrollerkortet har tatt kvelden.

AtW

Hvilken fleksibilitet har software-raid på linx som ZFS ikke har, bortsett fra muligheten til å utvide raid arrays? Og det er vel også avhengig av at du ka utvide filsystemet som ligger oppå raidet, det er jo ikke alltid noen smertefri prosess heller.

 

 

hvakrg: man kan så vidt jeg vet kjøre ni disker i ett vdev og bare miste en niendel av plassen til redundans, selv om det er anbefalt med to. Det er en ganske god deal.

 

Et annet problem med ZFS, i hvert fall om man vil bruke det i FreeBSD, er at samtlige nye 3TB-dsiker lyver om sektorstørrelsen for å være kompatilbe med dumme OS (krem, Windows). Det kreverer visst noe settingstweaking

Lenke til kommentar

Problemet er vel snarere at man ikke kan boote fra de uten å partisjonere de opp i windows. Personlig fatter jeg ikke hvorfor de går i den fella gang på gang, hvor mange ganger de siste 15 årene har harddiskstørrelse møttt en eller ennane vegg som burde vært designet ut lenge før det ble et praktisk problem? 3 eller 4?

 

AtW

Lenke til kommentar

Ja, man kan kjøre det man vil på Raid i Windows-verdenen også, men Raid har sine ulemper og fungerer på en annen måte enn DE/Greyhole. Jeg har ikke noe voldsomt med innsikt hva anngår Greyhole annet enn at det åpenbart er kraftig inspirert av DE.

Greyhole har mer funksjonalitet enn DE. Du kan se sammenligning av funksjonalitet her:

http://code.google.com/p/greyhole/wiki/MigrateFromWHS

Greyhole gjør dette i software oppå Samba, i motsetning til lvm, zfs og btrfs som er lavnivåløsninger implementert rett i kjernen. Utfra det du sier vil Greyhole gi deg alt du er ute etter.

De fikk problemer med at Windowsprogrammer var bygget for driveletter oppsettet og ikke for "shares".
Helt utrolig, det var jeg ikke klar over. I linux er dette ikke noe problem, programmer kan installeres og kjøres hvor som helst. Shares kan mappes opp akkurat som en hvilken som helst annen mappe.
Det jeg lurer på er om Greyhole har løst dette på en eller annen måte og om dette er løst i selve Greyhole, eller om måten Linux er bygget på gjør at det ikke er ett problem.
Ja. Det er overhodet ikke noe problem på linux.

 

Ellers virker det som om det er en del forvirring rundt tekniske løsninger. Spesielt er det viktig å være klar over forskjellen på redundans og back-up. Det som Greyhole og DE tilbyr er redundans på deler av datasettet uten at diskene trenger ha samme størrelse. Det fritar deg ikke fra behovet for back-up! Hvis du lager en JBOD, og en disk dør, så mister du alle dataene med LVM, akkurat som med Raid0. Med Greyhole eller DE kan du fortsatt lese data fra de andre diskene, men da har du ingen kontroll på hvilke data som er berget eller ikke. Derfor er denne funksjonaliteten kun av interesse hvis du har viktige data som du ikke tar back-up av. Jeg regner med at dere alle tar back-up av alt dere nødig vil miste, da er det heller ikke noe stort poeng i å kunne lese ut filer fra de andre diskene, du vil uansett ønske å rulle tilbake alt fra back-up.

Lenke til kommentar

Jeg er ikke enig i den analysen. Akkurat som jeg ikke er enig i holdningen "raid er kun for oppetid, ikke for sikkerhet". Enhver design som minsker mengden data som ødelegges er bra. Kanskje har du lagt til noe som du ikke har fått tatt backup av enda, kanskje er det ett problem med backupen. Det skader aldri å ødelegge så lite data som overhode mulig, i tilfelle man er uheldig nok til at noe annet skulle skjære seg også, det handler rett og slett om sannsynligheten for datatap. Den er mindre om du har igjen 75% av dataene på kilden enn om du har igjen 0%. Uansett om man har backup.

 

AtW

Lenke til kommentar
De fikk problemer med at Windowsprogrammer var bygget for driveletter oppsettet og ikke for "shares".
Helt utrolig, det var jeg ikke klar over. I linux er dette ikke noe problem, programmer kan installeres og kjøres hvor som helst. Shares kan mappes opp akkurat som en hvilken som helst annen mappe.

 

Ja, det det der er faktisk helt utrolig, i windows kan man jo ha veldig lange UNC-paths også, men vanlige paths med drive-letter kan bare være 255 tegn, en vesentlig begrensing. Og det er ikke akkurat som de ikke har hatt årevis på å ordne opp...

 

AtW

Lenke til kommentar

Jeg er ikke enig i den analysen. Akkurat som jeg ikke er enig i holdningen "raid er kun for oppetid, ikke for sikkerhet". Enhver design som minsker mengden data som ødelegges er bra. Kanskje har du lagt til noe som du ikke har fått tatt backup av enda, kanskje er det ett problem med backupen. Det skader aldri å ødelegge så lite data som overhode mulig, i tilfelle man er uheldig nok til at noe annet skulle skjære seg også, det handler rett og slett om sannsynligheten for datatap. Den er mindre om du har igjen 75% av dataene på kilden enn om du har igjen 0%. Uansett om man har backup.

Jeg er enig i at redundans ikke bare er oppetid, men også sikkerhet. Kombinert med Back-up som er godt satt opp (typisk cron-jobb med inkrementell back-up) gir det meget god sikring mot datatap. Den ekstra gevinsten med å ha funksjonaliteten du etterspør ser jeg da som minimal, du vil etter all sannsynlighet aldri få behov for det.
Lenke til kommentar

Enhver design som minsker mengden data som ødelegges er bra. (snip)

Den ekstra gevinsten med å ha funksjonaliteten du etterspør ser jeg da som minimal, du vil etter all sannsynlighet aldri få behov for det.

Hovedkortet på min (hjemmebygde) WHS tok kvelden her før jul, og jeg fant ikke noe erstatningskort som var såpass likt at jeg ville ta sjansen på å prøve å boote systemet med det.

Løsningen ble å bygge opp WHS med ny hardware og så ta de gamle diskene én for én og kopiere over de filene jeg var interessert i å beholde. Ettersom alle WHS-diskene er NTFS-formattert var dette trivielt. [Dette er vel ikke lenger tilfelle i WHS 2011.]

 

Jeg hadde backup av alt av viktighet, og det var ikke noe på de gamle diskene jeg ikke kunne leve uten, men det var allikevel en del ting på dem som var "kjekt å ha" og som det var enklere/raskere å kopiere fra diskene enn å erstatte på andre måter. Når ulykken først var ute, så var det en relativt enkel recovery-prosess.

Lenke til kommentar

Selv er jeg veldig fan av det *nix med mdadm og lvm kan tilby.

Jeg skal snart igang med å sette opp ny server hjemme med følgende oppsett:

2x1TB 7200rpm i RAID-1 til systemdisk (egne lvs for root, boot, swap, home og backup)

4x2TB 5400rpm i RAID-5 til lagring av store filer

 

Fordelen med LVM slik jeg ser det, er at når mitt raid-5 er fullt,

kan jeg sette opp enda et raid-5 og legge det til i poolen og vips har jeg mye ledig displass.

 

Jeg har også planer om å bruke RAID-1 arrayet til lagring av backups fra de andre maskinene i huset (har foreløpig lite mengde data som er viktig å ta vare på),

når dette raidet er fullt, kan jeg sette inn to stk disker til i RAID-1 og legge til i poolen.

 

I tillegg kommer jeg til å bruke CrashPlan for de aller viktigste filene (noen av dem vil også ligge hos dropbox).

Lenke til kommentar

Hovedkortet på min (hjemmebygde) WHS tok kvelden her før jul, og jeg fant ikke noe erstatningskort som var såpass likt at jeg ville ta sjansen på å prøve å boote systemet med det.

Irrelevant problem på linux, flytt over diskene til et hvilket som helst hovedkort, og de booter typisk opp. Driverne ligger i kjernen, og hardware probes ved hver boot. Med snapshot funksjonalitet ville du hatt kopi av hele dritten i tillegg. Jeg vil anbefale deg å pensjonere din WHS på et eller annet tidspunkt til fordel for en mer robust løsning. Du har nok mer enn nok kompetanse til å sette opp et linuxbasert alternativ.
Lenke til kommentar

hvakrg: man kan så vidt jeg vet kjøre ni disker i ett vdev og bare miste en niendel av plassen til redundans, selv om det er anbefalt med to. Det er en ganske god deal.

 

En grunnregel på RaidZ/Raid5 er vel 4+1, altså 5 disker i ett raidsystem. Går man over dette bør/skal man bruke f.eks. Raid6/RaidZ2. Man kan kjøre flere disker, men risikoen øker for hver disk.

 

Ser ut at en kan både utvide en eksisterende zpool ved å legge til en ekstra disk og oppgradere et zpool ved å bytte ut én og én disk. Men det skal vel sies at metodene føles litt "hacker-aktig" og jeg er ikke sikker på om jeg ville gjort det med kritiske data...

 

Man kan ikke legge til en ekstra disk med mindre man kjører ett "JBOD" Zpool uten redudans, og du mister all data om en disk dør. Og oppgradering av enkeltdisker i ett pool hjelper heller ikke på størrelsen.

 

Dersom du har ett RaidZ pool med 5 2TB disker så har du ca 8TB lagringsplass. Dersom du bytter ut en av disse diskene med en 3TB disk har du fortsatt bare 8TB lagringsplass pga at den nye disken blir "nedgradert" til å være like stor som de andre. Først når alle diskene er erstattet med 3TB disker vil du ha ca 12TB tilgjengelig. På ett "JBOD" Zpool så kan du bytte ut og få den ekstra plassen med en gang, men da har som sagt uansett ingen redundans og all data forsvinner om en disk dør.

 

Greyhole har mer funksjonalitet enn DE. Du kan se sammenligning av funksjonalitet her:

 

Jada, har ikke sagt noe annet, men at ideen til Greyhole kom fra DE er det vel ingen tvil om. Ikke at det er noe galt med det.

Lenke til kommentar

Joda, btrfs fsck finnes, men den har begrenset funksjonalitet. Meego bruker btrfs som standard, Fedora har støttet det en god stund. Personlig vil jeg porte over mine hjemmemaskiner til btrfs ved neste ubuntu release i april.

 

Du bør ta en nærmere titt på Amahi, den er et godt alternativ til FreeNAS:

http://www.amahi.org/

Du får meg stadig til å kraftig vurdere noe annet enn MS løsninger, og det liker jeg godt :). Men et raskt spørsmål, når man jobber mye med MS løsninger og må opprettholde kompetanse der er det greit å kunne kjøre begge verdener.

 

Hvordan ville det vært å eks. kombinere 2008R2 for domene og div. med dine anbefalninger som filservere? Før i tiden sverget jeg eks. til Novell for noen roller og MS til andre der hvor det var absolutt nødvendig/pålagt. Men jeg gikk alltid for å anbefale det "beste" produktet for rollen.

 

Det hadde for meg vært ypperlig med å kunne sette opp noen av dine anbefalninger som filserver samt evt. andre roller du måtte anbefale og kunne bruke 2008R2 AD og annet for Win7 klienter og opprettholdelse av kompetanse.

 

Nå er ikke jeg noen som er spesielt engstelig for kommandolinjer da det har vært min verden i alle år på forskjellige plattformer, og selv i MS verden gjør jeg helst arbeidsoppgaver i omtrent alle størrelsesordner via kommandolinje, scripting etc.

Men med lite tid og mye arbeidspress (budsjett/inntjening) til enhver tid, små barn etc. er det greit å ikke måtte bruke altfor mye tid på stadig syntaxknoting. Når jeg satt meg inn i basisen for RedHat ES for en 3-4 år siden synes jeg det var noe arbeidsomt å få et godt grep om alt rundt disk, raid, volum etc. i den verdenen men selvfølgelig fult forståelig. Det man ønsker er å ha et system hvor man ikke nødvendigvis må avlyse alle avtaler en hel helg for å på volumer opp å gå igjen. Desverre har jeg ikke fått tid/oppgaver til å jobbe særlig mer med RH utenfor de aller enkleste oppgaver på delvis etablerte systemer hvor det stort sett dreier seg om installasjon og oppsett av databaser og applikasjonsserver og er derfor fortsatt en skammelig noob i den sammenheng.

 

Dine anbefalninger?

Funksjonalitet og trygghet ift. dataintegritet og gjenoppretting av volumer ol. er en viktig faktor samt at adminterskelen helst ikke bør tilsvare måneder med prøving og feiling.

 

Samt hvordan anbefaler du å evt. "migrere" store volumer (mange TB med data fra w2k3 og win7) fra MS til det du anbefaler når man må bruke de samme diskene begge steder? Samt beste metoder om man kjøper inn nye disker for migreringen? Jeg "kjenner til" gamle og mye brukte løsninger som SAMBA ol. men å ha det som en permanent løsning for å sy samme disse verdner er vel ikke helt optimalt. Bruker gjerne slike løsninger for "migrering" av data men ellers vil jeg helst ha en så renhåring filserver som mulig.

 

 

EDIT:

Jeg har også et LSI8308 kort som gjerne skulle vært støttet i filserveren men det er på ingen måte noe must. Ellers er tanken på bruke en P35 eller P45 basert maskin til filserverformålet. Løftes opp fra en gammel P4 NW-C/W2K3 som delvis har stått i brakk med Win7/hw-Raid som en liten mellomrolle mens jeg bestemmer meg for videre strategi.

 

EDIT2:

Ellers har jeg lest litt om og kom borti løsninger som FlexRAID og unRaid fordi det bla. irriterte meg grundig at man ikke fikk SW basert Raid5 i Win7 Pro. (idiotisk segmentering i mine øyne). Dog falt jeg på HW Raid5 og MS Spanning (for mindre kritiske data) midlertidig.

Endret av Theo343
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...