Uitbreiden Jbod

[TonVH]

Normaliter ben ik een fan van Raid-0 maar in dit onderhavige geval voorzie ik (relatief) frequente uitbreidingen vanwege benodigde ruimte.

Jbod kan (nadat het gebruik er van met bijv. 2 HD's in een set) uitgebreid worden met x nieuwe HD's. Dit hoort dan soort on-the-fly te gebeuren waarmee ik bedoel dat de nieuwe HD eraan gehangen wordt, formatteren van uitsluitend alleen deze HD en vervolgens is de extra ruimte beschikbaar. De bestaande data op de oude HD's blijft dus intact.

Uiteraard kan ik dit uitproberen maar dat kost dan aardig wat uren. Dus vragen is sneller. Iemand die hier ervaring mee heeft?

[Ben(V)]

Heb er geen ervaring mee (ik begin niet aan jbod  ), maar volgens Synology kan het gewoon.

2. Uitbreiding met extra harde schijven

DiskStation ondersteunt de capaciteitsuitbreiding van volumes en schijfgroepen met de volgende RAID-types: Synology Hybrid RAID (SHR), JBOD, RAID 5, RAID 5+ Spare en RAID 6.

Zie:  http://www.synology.com/nl-nl/support/tutorials/559

[Birdy]

Effe checken, je zit toch nog op RAID0 (volgens ondertekening) en nog niet op JBOD ?
Maar goed, JBOD kun je gewoon uitbreiden.

[TonVH]

Het gaat om een mogelijke nieuwe configuratie.

Wat ik mij ook afvraag is volgende. Ik heb begrepen dat een bestand volledig op 1 HD moet staan. Maar wat gebeurt er als het gewoon niet past en dit tevoren niet bekend was. Bij voorbeeld als een bestand aangevuld wordt.

Heb wel wat Wiki's gelezen maar zie weinig over de werking en gevolgde logica.

[Ben(V)]

Nee een bestand staat bij een jbod niet per definitie op een hdd!

Als je een jbod maakt zal DSM alle beschibare blokken (van alle schijven dus) toekennen aan een enkel volume.
Het filesysteem ziet dan dus een enkele grote disk en zal willekeurig blokken alloceren en geen rekening houden met fysieke diskgrenzen, die ziet hij namelijk helemaal niet.

Verder is het zo dat als je een schijf eruit haalt (of defect raakt) hij het hele volume als corrupt ziet en je dus bij geen enkele file meer kunt.

[Birdy]

Ik heb begrepen dat een bestand volledig op 1 HD moet staan.

Dat zou kunnen dat je dat ergens gelezen hebt.

Maar wat gebeurt er als het gewoon niet past en dit tevoren niet bekend was. Bij voorbeeld als een bestand aangevuld wordt.

Als bovenstaande waar is, dan mag ik verwachten dat dit door het JBOD-Systeem netjes wordt opgelost.

Maar denk dat JBOD, zoals Ben(V) al heeft aangegeven, geen HD grenzen kent dus, waar het verhaal vandaan komt 

[TonVH]

Uit een ander draadje (http://www.synology-forum.nl/hardware-vragen/nadeel-bij-jbod/msg110241/#msg110241 Koopmans over Jbod) bleek dat er 1 HD kapot ging, toen niks bereikbaar, nieuwe HD erin en toen was de helft (dus op de oude niet defecte HD) er weer was.

Maar met alles wat ik nu op enkele forums heb doorgespit is het enige voordeel van Jbod dat er dynamisch HD's bij gehangen kunnen worden en verder lees ik voornamelijk kommer en kwel.

[Robert Koopman]

Wat mij vooral verbaasde was dat ook DSM kuren vertoonde.
Met 1 van de 2 schijven stuk in JBOD zou je dat toch niet verwachten.
Van de werkende schijf kon ik wel data redden.
Ik gebruik dit type indeling nu niet meer.

[Ben(V)]

Wat mij vooral verbaasde was dat ook DSM kuren vertoonde.

Zoals ik al zei, je hebt geen enkel controle over waar het filesysteem een file(of delen van een file) neerzet.
Als een deel van DSM op de defecte schijf terecht is gekomen dan heeft DSM uiteraard een probleem.

Wat er op de ene schijf en wat er op een andere komt is erg afhankelijk van hoe vol alles is en hoe vaak er mutaties doorgevoerd worden. Het file systeem probeert namelijk altijd blokken te vinden die naast elkaar liggen zodat de hele file niet over de hele disk gescatterd is, maar weet niets van het feit dat zijn volume over twee disken verdeelt is.

ALs persoonlijke note:
Ik kan me niet voorstellen dat je niet beter twee volumes in plaats van een jbod kunt gebruiken. Er is altijd wel een verdeling te maken van  waar wat moet komen.
Je hebt toch ook subdirectories op je volume staan?

[TonVH]

ALs persoonlijke note:
Ik kan me niet voorstellen dat je niet beter twee volumes in plaats van een jbod kunt gebruiken. Er is altijd wel een verdeling te maken van  waar wat moet komen.
Je hebt toch ook subdirectories op je volume staan?

Bestanden (die bij elkaar horen) bewust (dus in ogen van de gebruiker) over 2 of meer verschillende HD's plaatsen levert dezelfde nadelen/problemen/ellende op als het partitioneren van HD's (wat in sommige kringen nog steeds gepropageerd wordt). Met name het probleem wat in de tijd altijd met partitionering ontstaat en dat is de verdeling over HD's die toch verkeerd is ingeschat.

De gebruiker moet dan beslissen waar hij iets laat. Backups (vooral aut. systemen) worden nodeloos complex. kijkers moeten ook al weten waar het staat. Kortom allemaal zaken die vermeden worden door bijv Jbod/Raid-0. Temeer als bedacht wordt dat ik systemen zodanig concipieer dat ze vrijwel geen handmatig ingrijpen meer nodig hebben omdat alles via aut. procedures wordt afgehandeld.

Als HD's niet disproportioneel duurder werden als je een grotere wilt of nodig meent te hebben dan zouden deze technieken niet nodig zijn. Maar 2*3TB (2*100,=) is beduidend goedkoper dan 1*6TB (1*500,=).


Waarom denk ik (in deze spec. situatie) aan Jbod i.p.v. Raid-0? Omdat ik hoopte dat bij een onverhoopte crash reconstructie sneller zou kunnen want maar de helft reconstrueren. Ander voordeel is dat Jbod toelaat verschillende HD's te mixen.

Ik kom echter zo langzamerhand tot de conclusie dat de reconstructie wel eens veel meer tijd zou kunnen kosten.

[Birdy]

Hier een recent voorbeeld dat JBOD niet echt zaligmakend is:
http://www.synology-forum.nl/hardware-vragen/nas-start-niet-goed-op-is-onbereikbaar/15/

[TonVH]

Dank voor dat nuttige artikel.

Punt is echter dat ik (in tegenstelling tot veel anderen) geen enkele waarde hecht aan de voordelen van Raid-1 en hoger. Er is (een enkel geval daargelaten) geen enkele behoefte om naadloos door te kunnen werken als een enkele HD defect zou raken. Want omschakelen naar een 100% kloon die max. enkele uren oud is levert geen probleem op.

Ik gebruik dus Raid-0/Jbod om de simpele reden dat HD's boven de 4TB op dit moment (relatief) onbetaalbaar zijn terwijl HD's van 3 en 4 TB als zeer betaalbaar worden gezien. Heb je dus (bijv.) 6TB nodig dan is de oplossing 2*3TB in Raid-0/Jbod gebruiken.

Met losse volumes werken is m.i. net zo antiek als partitioneren. Het geeft alleen maar nadelen en problemen en was mooi en handig in de jaren '80 en '90 maar die liggen ver achter ons. Hooguit wil je gebruikers beperken in hun opslag maar daar zijn andere en betere methodes voor.


Ik heb me wat verdiept in Jbod vanwege de in potentie makkelijkere vergroting maar kom tot de conclusie dat dat voordeel totaal niet opweegt tegen de beperkingen en de trammelant bij een crash. Dan is Raid-0 makkelijker (want domweg alles opnieuw opbouwen) en bovendien hogere snelheden.


NB: bovenstaand geldt voor de situaties die ik tegenkom (home & SMB) voor grotere bedrijven kan ik mij andere criteria voorstellen maar die hebben meestal ruimere geldmiddelen.

[Birdy]

Ik respecteer je keuze, zeker in jou geval zoveel mogelijk opslag voor de redelijke prijs.

Ik persoonlijk zou niet zonder SHR (RAID5) willen (thuis situatie).
Heb 1x een HD-crash gehad en kon lekker verder draaien totdat ik de defecte HD kon vervangen en herstellen.
Dit gaf mij toch een zeer goed gevoel, ondanks dat ik ook nog backups maak van mijn belangrijkste data (dubbele veiligheid zeg maar).

[TonVH]

Ik heb een (100%) dagelijkse backup, wekelijkse (100%) backup en maandelijks circa 60% meest belangrijke. Tijdens de dagelijkse backup wordt niets weggegooid/overschreven maar gearchiveerd. Archief gooi ik om de zoveel tijd 'handmatig' leeg en wordt verder niet gebackupped. Backups worden allemaal volaut. vervaardigd dus geen kans op "geen tijd", "nu effe geen zin" of andere 'excuses'.

Ik kan binnen luttele minuten omschakelen naar een max. 4 uur oudere fullkloon.


Dat alles maakt SHR/Raid voor mij (en enkele soortgelijke gevallen) overbodig. Bovendien kan ik (door bovenstaande procedure) ook een dubbele HD-error opvangen.

[Ben(V)]

Ik kan je redenering wel volgen en je hebt helemaal gelijk over de prijzen van de grootste disken.
De vergelijking met partitionering gaat niet helemaal op, want dat werd juist gedaan om een deel van de disk af te schermen van de rest (OS en data) en dan was het OS deel altijd te klein.

Ik ken het gebruik van jouw data natuurlijk niet maar als je zegt dat het gebruik van verschillende volumes erg lastig is moet ik dat van je aannemen.

In jou geval zou ik dan toch voor jbod gaan en niet voor RAID0, want in een jbod configuratie kun je waarschijnlijk de files die niet over twee disken zijn verspreid nog wel terughalen als er een disk crashed.
Bij Raid 0 ben je gegarandeerd alles kwijt bij een crash van een disk. (RAID0 schrijft de blokken van een file om en om weg naar de verschillende disken).

Een paar tips:


As je niet veel mutaties hebt maar voornamelijk files bijschrijft zou je het volgende kunnen overwegen.
Ga pas uitbreiden met een volgende schijf als de eerste bijna vol is. Dit houd de files zoveel mogelijk op dezelfde schijf.
Als de schijf bijna vol is breid hem uit met JBOD en schrijf een grote dummy file weg die niet meer op de eerste disk passen. Dat is dan de enige file die over twee disken is verdeelt.

Maar zoals reeds gezegd dat heeft geen zin als er mutaties op de files komen.