Gå til innhold

Hitachi øker til 4 TB


Anbefalte innlegg

FØler denne "hvilket merke er best"-diskusjonen er litt feil, det har vel aldri vært slik at det er MERKE det går på, det er heller MODELLER man bør holde seg unna. F.eks. var Seagate sin 7200.10-serie MEGET solid, blant det ypperste man kunne ha i maskinen - hvertfall ift driftssikkerhet. 7200.11 var trash, derimot. Summa summarum er det like greit å kjøpe det som er billigst dersom ikke internettet sier at det valget er en dårlig disk. Ellers er jo prisen på denne interessant, 3tb kommer til å nærme seg der de var før flommen (1000 kroner), og da sier det seg selv at ikke 4tb er verdt 3000. Det er "bare" snakk om 33% ekstra plass. Tipper prisen vil bli ca 2000 kroner for denne, dersom mine antagelser om 3tb-prisene holder stikk. Men... vil ha 5tb :p

 

Selvfølgelig, men vi vet jo i prinsippet ingenting om helt nye drives. Derfor er hvordan merket har levert i den siste tiden relevant i praksis. Alle produsentene driter seg ut jevnlig, men hitachi har levert god kvalitet lenge nå.

 

AtW

Lenke til kommentar
Videoannonse
Annonse

HAST + ZFS er fint det, men fjerner jo på ingen måte behovet for rebuild.

Raidet som ligger på laget over HAST ser ikkje at den eine noden har mista ein disk, ergo du trenger ikkje rebuild.

Nei sånn sett trenger jo ingen rebuild i det en disk krasjer... det er først når flere krasjer at det ville ha vært greit å ha bygd opp de som krasja tidligere. Så langt jeg vet kan ikke HAST speile over tilsvarende disk i f.eks et RAIDZ og selv om den kunne det så ville jo belastningen på motstående disk blitt signifikant.

 

Nei, HAST er ingen loadbalancer, det er master slave i full sync. Ergo ryker ein disk så køyrer raidet fint, og like kjapt som før då HAST bare bytter hovudnode. Når du bytter disk så synkroniserer du bare den eine disken. Synkroniseringshastigheita kan du justere sjølv. Drar du bare ned ein HAST node for vedlikehald så vil HAST bare synkronisere dei datablokkene som har blitt endra sidan sist. Kræsjer fleire disker samtidig så har du eit stort problem som er mykje viktigare å få ordna opp i :)

Jeg er forsåvidt ikke veldig uenig i hva du sier, men poenget er at man må kjøre like mye rebuild uansett hvor mye du bruker clustering teknologier som HAST på toppen. HAST er egentlig ikke relevant for diskusjonen. Det er laget under som er utfordringen og før eller siden vil du ha de utfordringene på både master og slave sammtidig. Det er bare litt lavere sannsynlighet.

 

HAST ligger på laget under filsystemet ikkje over. Ergo brukar du det saman med ZFS så er det rebuild bare i krisesituasjonar.

Lenke til kommentar

Du fatter det ikkje, det er ikkje som vanleg raid i det heile tatt.

 

Nei, jeg fatter virkelig ikke, la oss prøve å generalisere dette, man antar at fornuftig oppsett og fornuftige aloruitmer, man bruker en viss prosent av oppsettet til redundans. Uansett om det er ZFS, RAID og HAST eller ikke, så vil ett tap av disken føre til mindre (i verste fall ingen) redundans, denne redundansen må tilbakeføres, da må du kjøre en rebuild, ZFS eller raid.

 

AtW

Lenke til kommentar

Så utgangspunktet ditt er en magisk, udødelig nettverksdisk? Den vil vel aldri trenge noen form for redundans i hverken filsystem, raid eller Hasp ettersom den er udødelig?

 

Men seriøst, når en disk ryker så reduseres redundansen (antall speilinger, paritetsdata eller hva det nå måtte være). Denne reduksjonen må/bør på ett eller annet tidspunkt økes tilbake til sitt opprinnelige nivå. Hvordan mener du det skal skje? Paritetsdata, etc flytter seg ikke til en nymontert erstatningsdisk på et øyeblikk, sånn helt av seg selv.

Lenke til kommentar

Nei

 

For å si det enkelt, så speiler HAST ein nettverksdisk til ZFS. Poenget er at denne nettverksdisken aldri vil dø og du vil slippe å køyre resilver med ZFS.

 

La oss ta ett konkret eksempel da, du har ett HAST + ZFS-oppsett, det består av tilsammen 8 dysiske disker. Skisser opp hvordan du tenker ett fornuftig system er bygd opp på den måten, og hva som skjer om en av disse 8 diskene dør.

 

AtW

Lenke til kommentar

Då har du eit raid med 6 nettverksdisker og bak disse har du dei restaerane 12 fysiske diskane. Om ein disk dør så køyre raidet heilt fint. Om to disker dør så køyre raidet heilt fint så lenge ikkje dei to diskane som høyrde til nettverksdisken var dei som feila.

 

La meg formulere dette annerledes, du har 8 eller 12 disker tilsammen i hele oppsettet sitt, alt du eier er 8 eller 12 fysiske disker. Du kan sette opp de med ZFS, nettverk osv som du vil. Men du har kun disse fysiske diskene til disposisjon, ikke 12 disker, og 6 disker på ett nettverk ett annet sted. Tilsammen 12 eller 8 disker er det du har å sette opp ett system med.

 

1. Hvordan setter du opp dette

2. Hva gjør du rent konkret om du mister en fysisk disk, ikke "vil du ha tilgang til datene fortsatt", men hva du vil gjøre for å få oppsettet ditt opp på ett akseptabelt nivå igjen.

 

AtW

Lenke til kommentar

OK beklager jeg må innrømme at jeg ikke har lest om hast siden det var under utvikling. Men utfallet er uansett det samme. HAST kan sees på som et RAID 1 over nettverk der diskene er organisert i master slave heller enn likeverdige for å spare nettverkstrafikk. En rebuild for HAST blir identisk like en RAID 1 rebuild. Så om en kjører raid z med HAST så blir det som å kjøre RAID 51. striping med redundans over speil. Alle ulemper med økende data per spindel er relevant.

Lenke til kommentar

HAST vil resynkronisere den eine noden. Ellers er alt som før. Kor vanskeleg er det å forstå?

Det er enkelt å forstå. Poenget var at jeg (med flere) ikke forsto dette:

 

Rebuild tid med store disker? Bruk heller eit skikkeleg moderne lagringssystem som baserer seg på moderne tankegang. Så slepp du å tenkja på rebuild og alt heller bare fungerer.

 

Verken HAST eller ZFS er svaret på problemet med datamengder per spindel som øker raskere enn ytelsen per spindel.

 

For å løse rebuild problemet må en ha et system som ikke krever at erstattede disker må gjennoppbygges. For å løse restore problemet så er HAST et lite stykke på veien, men det stykket har vært oppgått av mange for lenge siden og flere leverer aktiv/aktiv på flere noder. Aktiv/passiv på to noder er ikke cutting edge. knapt nok moderne.

Endret av Anders Jensen
Lenke til kommentar

Du må jo erstatte tapt data på ein eller anna måte. Tingen er at med HAST så brukar du ikkje titalls timar med å vere i full sync igjen.

 

Det gjør du jo gjerne ikke med raid heller, jeg kan egentlig ikke se at man bruker kortere tid i det hele tatt enn feks å ha flere raid 1 i ett raid5-array, som er det tilsvarende(?) av det jeg tror du foreslår. (om man ikke forutsetter at man har lite data ihvertfall)

 

AtW

Endret av ATWindsor
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...