Extra redundancy


jonp

Recommended Posts

  • 4 weeks later...
  • Replies 68
  • Created
  • Last Reply

Top Posters In This Topic

Could this also be expanded to having two arrays in one machine?

 

Possible by using xen and passthrough, but native multiple array support would mean I could split the array into 2.

 

If P+Q parity is implemented what benefit is there to having multiple arrays?  Only reason I can think of is if we also implemented different raid levels for the array, e.g., raid-1.

Link to comment

?  triple parity?  TBD.

Would developing this delay the release of an unraid version with daul parity?  If it's all the same, go for it, awesome. I'd only use 2 parity drives, but I'm sure there are those who would sleep easier at night with 3 parity drives. 

Link to comment

Could this also be expanded to having two arrays in one machine?

 

Possible by using xen and passthrough, but native multiple array support would mean I could split the array into 2.

 

If P+Q parity is implemented what benefit is there to having multiple arrays?  Only reason I can think of is if we also implemented different raid levels for the array, e.g., raid-1.

 

One could split their arrays up to smaller legacy drives in one array and larger newer drives in the second. This could help to maximize parity checks and parity rebuilds performance. This could minimize risks as the drives get older they're not impacting the newer larger drive array pools, just the smaller older drive array pool.

Link to comment

Forgot to mention that eventually one could replace the entire old drive array pool (for example one made up by 4 2TB drives with one being parity) with a single 6TB data drive in the new array.

 

This could possibly make for upgrading of drive sizes a little more manageable when drive sizes double or triple like they have from 2TB to 6TB.

Link to comment

Could this also be expanded to having two arrays in one machine?

 

If P+Q parity is implemented what benefit is there to having multiple arrays?  Only reason I can think of is if we also implemented different raid levels for the array, e.g., raid-1.

 

While there may be conceptual reasons folks want to use separate arrays (keep one kind of data on one;  another on another);  I don't think this is needed.    With dual parity, there are two major data integrity issues solved:  (1)  You can compute exactly where a parity error has occurred, so it's no longer necessary to assume it's always on the parity drive;  and (2)  the system is fault-tolerant during a drive rebuild (the major benefit).      Dual fault-tolerance isn't designed to let you wait until you have 2 drives fail before buying more drives -- it's designed to minimize the chances of data loss while you're replacing ONE failed drive.

 

If folks want multiple arrays on the same system, just use VM's for the 2nd, 3rd, etc. arrays -- and pay Limetech for the extra licenses  :)    [They can even do it for free if they restrict the array size to 12TB of protected data]

 

Link to comment

Could this also be expanded to having two arrays in one machine?

 

Possible by using xen and passthrough, but native multiple array support would mean I could split the array into 2.

 

If P+Q parity is implemented what benefit is there to having multiple arrays?  Only reason I can think of is if we also implemented different raid levels for the array, e.g., raid-1.

 

 

Being the OCD perfectionist at times. I often wanted to create multiple arrays rather then one large one.

compartmentalizing  1 5 disk removable chassis and controller to an array.

I would rather have 4 protected arrays then one large one.

 

 

It was more for management of disks wires controllers and speed per data set type.

movies, music, source and home folders. etc, etc.

Link to comment

It was more for management of disks wires controllers and speed per data set type.

movies, music, source and home folders. etc, etc.

 

I'd think these can easily be managed by using separate shares for each category.  If you feel a need to have different categories on specific disks, then that's easily accomplished by simply using the "Includes" setting for each share.    There's no real reason to do that, but many of us tend to do it anyway (I do the same thing).

 

 

I would rather have 4 protected arrays then one large one.

 

Remember that 4 protected arrays means either 4 parity disks (with single parity) or 8 parity disks (with dual parity).    I'd FAR rather have one array with dual parity than 4 arrays with single parity.  A 20-disk array with dual parity has a lower statistical chance of data loss than a 5-disk array with single parity -- and if you had 4 of those 5-disk arrays it'd be an even greater disparity.

Granted that if you used dual parity on the 5-disk arrays it'd be quite a bit lower yet ... but then you'd be getting only 2/3rds of the storage capacity from your 20 disks that you'd have with a 20-disk array.  [12 disks for data instead of 18]

 

 

 

 

Link to comment

It was more for management of disks wires controllers and speed per data set type.

movies, music, source and home folders. etc, etc.

 

I'd think these can easily be managed by using separate shares for each category.  If you feel a need to have different categories on specific disks, then that's easily accomplished by simply using the "Includes" setting for each share.    There's no real reason to do that, but many of us tend to do it anyway (I do the same thing).

 

 

I have way too many small files.  I don't use the usershares.

 

I would rather have 4 protected arrays then one large one.

 

Remember that 4 protected arrays means either 4 parity disks (with single parity) or 8 parity disks (with dual parity).    I'd FAR rather have one array with dual parity than 4 arrays with single parity.  A 20-disk array with dual parity has a lower statistical chance of data loss than a 5-disk array with single parity -- and if you had 4 of those 5-disk arrays it'd be an even greater disparity.

Granted that if you used dual parity on the 5-disk arrays it'd be quite a bit lower yet ... but then you'd be getting only 2/3rds of the storage capacity from your 20 disks that you'd have with a 20-disk array.  [12 disks for data instead of 18]

 

 

 

It's my preference, I would rather have smaller protected arrays and compartmentalize it to certain controllers and chassis.

I have enough money for extra parity disks, so that point is moot on me.

 

 

In any case I don't see it happening, But I have reason for it.  It's mostly because of how I use my array and how much I write to it.  Plus the human perspective of managing smaller arrays contained in one controller per array.  There is a performance benefit to it if I have different arrays for different use with separate parity drives.

 

 

The statistics of a 20 drive dual parity vs 4 arrays of single parity do not interest me.  The data that's important to me is duplicated in a backup, so I'm wasting drives there anyway.

 

 

I also learned that lifting a 25 drive server in an emergency, is not all that easy when flood waters are coming in. At least I was able to grab some of the drives that I had forced to be in specific positions to save crucial information.

 

 

In my newer setup. I just went with multiple smaller machines. I have a number of HP Microservers to manage the burden.

Link to comment

Could this also be expanded to having two arrays in one machine?

 

Possible by using xen and passthrough, but native multiple array support would mean I could split the array into 2.

 

If P+Q parity is implemented what benefit is there to having multiple arrays?  Only reason I can think of is if we also implemented different raid levels for the array, e.g., raid-1.

 

One could split their arrays up to smaller legacy drives in one array and larger newer drives in the second. This could help to maximize parity checks and parity rebuilds performance. This could minimize risks as the drives get older they're not impacting the newer larger drive array pools, just the smaller older drive array pool.

 

 

This is one use case I can think of whereby having a second array would allow people to migrate to larger drives without actually ever being out of parity protection as well as speeding up rebuild times.

 

So I could duplicate my array with 4x4TB drives, set the array up and then rsync the drives.

 

Really this is to give people the option to have two arrays running from one UI.

Link to comment

I have enough money for extra parity disks, so that point is moot on me.

 

I wasn't commenting on the cost (didn't say a word about cost) -- I was noting that you'd only have 2/3rds of the storage capacity for the same total number of drives.    But I do agree that smaller arrays have some nice advantages.  My mini-ITX servers hold 7 drives each ... so with dual parity and 6TB drives that configuration will make a very nice 30TB server, which is likely what I'll "standardize" on for my next couple servers (one I'm building for a friend in Oct, and I plan to build myself another one soon afterwards).

 

 

I also learned that lifting a 25 drive server in an emergency, is not all that easy when flood waters are coming in.

 

Your Sandy experience definitely gives you a unique perspective on real-life disasters.  In fact, lifting a 25-drive server (or more accurately, NOT having to lift a 25-drive server)  IS indeed an excellent reason to use smaller arrays !!  I also am moving that direction ... my 2nd and 3rd servers are both mini-ITX units; and I'll likely stay with generally smaller systems (max of perhaps 10-12 drives) even with my larger builds.    I'm actually a big fan of mini-ITX units, but am still considering building one larger box for v6 with a bunch of VM's.

 

 

Link to comment

This is one use case I can think of whereby having a second array would allow people to migrate to larger drives without actually ever being out of parity protection as well as speeding up rebuild times.

 

So I could duplicate my array with 4x4TB drives, set the array up and then rsync the drives.

 

Really this is to give people the option to have two arrays running from one UI.

 

While this is true,  I don't think it justifies the effort to support multiple arrays on the same box.  It's already very simple to migrate to a new array without loss of parity ... it just requires that the new array be on new hardware, which is very often the case anyway.    And for smaller arrays (max of 12TB of data), you can even do it for free, as the Basic version of UnRAID can now support 12TB of protected data using 6TB drives.

 

Even without a 2nd UnRAID box, it's possible to migrate all of your data without losing your parity protection:  Simply remove ALL of the drives from the "old" array; backup your flash drive so you can restore the exact configuration if it should become necessary; and then, one-at-a-time, connect the data drives to a PC and use the free Linux Reader [ http://www.diskinternals.com/linux-reader/ ] to copy all of the data to your new array.    Should you encounter any issues with one of the disks, you can backup the flash drive from the new config; restore the original one; replace the drives from the old array; and you can then rebuild the failed disk or simply copy the data from it (using UnRAID's reconstructed data) to another location.

 

 

Link to comment

I have enough money for extra parity disks, so that point is moot on me.

 

I wasn't commenting on the cost (didn't say a word about cost) -- I was noting that you'd only have 2/3rds of the storage capacity for the same total number of drives.    But I do agree that smaller arrays have some nice advantages.  My mini-ITX servers hold 7 drives each ... so with dual parity and 6TB drives that configuration will make a very nice 30TB server, which is likely what I'll "standardize" on for my next couple servers (one I'm building for a friend in Oct, and I plan to build myself another one soon afterwards).

 

 

I also learned that lifting a 25 drive server in an emergency, is not all that easy when flood waters are coming in.

 

Your Sandy experience definitely gives you a unique perspective on real-life disasters.  In fact, lifting a 25-drive server (or more accurately, NOT having to lift a 25-drive server)  IS indeed an excellent reason to use smaller arrays !!  I also am moving that direction ... my 2nd and 3rd servers are both mini-ITX units; and I'll likely stay with generally smaller systems (max of perhaps 10-12 drives) even with my larger builds.    I'm actually a big fan of mini-ITX units, but am still considering building one larger box for v6 with a bunch of VM's.

 

Just remember, more than two servers means more than one trip.  I'd size them to be as large as possible that you can still carry one in each hand.  Always easier when it is a balanced load too ;-)  Pre-install carrier handles too, or buy a "lan-party" case with built in handle.

Link to comment

yeah but only like 5 drives.  I have no doubt an aluminum 10-ish drive case with a handle wouldn't be too heavy to carry one in each hand :)

 

Not sure about the micro-ATX version, but the mini-ITX version easily holds 7 drives (5 in the built-in slots; one in the 5.25" bay; and one on top of the PSU cage.

 

Link to comment

There's only so much you can carry when you are running for your life or almost drowning.

When your life is on the line, your movies will not matter, what matters are the crucial documents and/or priceless family pictures/videos.  You may still need to have a hand free to carry a go bag!

 

I like the idea of smaller arrays for compartmentalizing, performance and portability.

I've learned not to put all my eggs in one basket and to make sure the most important basket will not impede an emergency condition.

 

From a business point of view, it probably doesn't justify the work for multiple smaller unRAID arrays in one machine.

Most people will want a larger array with multiple parity drives to save on the extra drives.

 

In comparison, our Veritas on Solaris solution creates multiple small RAID5 arrays, These are exposed as LUNS, which are then combined once more into larger arrays with the volume manager.

 

So from a business perspective, there are people doing this sort of thing with smaller arrays which are then exposed as one large volume. (see my blackblaze comment below).

Link to comment

Your Sandy experience is definitely a strong example of why off-site backups can be so important.    Then you don't need to carry anything (except your "go" bag).    Although I'm VERY well backed-up, that's one big hole in my strategy -- my really important personal data and photos are backed up in the cloud; but my server backups are all in my home (albeit in a fireproof/waterproof safe).  Hopefully I never experience a Sandy-like event !!    You clearly cannot, however, predict or foresee what CAN happen -- I just got back from a Norwegian cruise where I met someone who had been on the 58th floor of the North Tower of the World Trade Center on 11 Sep 2001 ... a VERY interesting experience that most of us certainly never want to have.

 

 

 

 

Link to comment

Your Go Bag should always have shoulder straps to leave your hands free. :)

 

I hadn't given this much thought but I could see a use where I get an external HD Chassis that can hold 4 or 5 disks, attach viw external sata or SAS, and have this populated with older smaller disks and data that isn't that valuable or used often.  I'm thinking TV shows that have ended, moves of a certain genra or rating below xx, old archived data that IO horde because you never know one day I might actually need that 3.5" floppy disk img, whatever.  That external box could be a self contained array, with the main array on newer and faster disks inside the main case.

Link to comment
  • 1 month later...

What about cloud parity feature as well?  :P

 

so if parity HD fail, then use cloud parity.. should be possible somehow.

Not sure what you are think about here.  To be viable you would need a system that can respond in a small number of milliseconds and cloud based systems cannot achieve this. 

 

Maybe you are thinking that parity is something other than what it is?  in unRAID it is a process that operates at the physical sector level and is file-/file system agnostic.

Link to comment

Sorry if this sounds silly, and being new I'll take that charge, but wouldn't the best way to have extra redundancy to leverage in-built striping and mirroring in btrfs? Either let us mirror or stripe the pool (I know, somewhat against the unRaid ethos here), or allow mirroring of parity drives.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.