Oatway, Ted wrote:
IHAC that has 560+ LUNs that will be assigned to ZFS Pools and some
level of protection. The LUNs are provided by seven Sun StorageTek
FLX380s. Each FLX380 is configured with 20 Virtual Disks. Each Virtual
Disk presents four Volumes/LUNs. (4 Volumes x 20 Virtual Disks x 7 Disk
Arrays = 560 LUNs in total)
We want to protect against all possible scenarios including the loss of
a Virtual Disk (which would take out four Volumes) and the loss of a
FLX380 (which would take out 80 Volumes).
This means that your maximum number of columns is N, where N is the whole
device you could stand to lose before data availability is compromised.
In this case, that number is 7 (FLX380s).
Today the customer has taken some number of LUNs from each of the arrays
and put them into one ZFS Pool. They then create R5(15+1) RAIDz virtual
disks (??) manually selecting LUNs to try and get the required level of
redundancy.
Because your limit is 7, then a single parity solution like RAID-Z would
dictate that the maximum size should be RAID-Z (6+1). Incidentally, you
will be happier with 6+1 than 15+1 for most cases.
For 2-way mirrors, then you would want to go with rotating pairs of 1/2 of a
FLX380 array.
For RAID-Z2, dual parity, you would implement RAID-Z2(5+2). In general,
RAID-Z2 would give you the best data availability and data loss protection
along with relatively good available space. Caveat: I can't say when RAID-Z2
will be available for non-Express Solaris versions, I have zero involvement with
Solaris release schedules.
More constraints below...
The issues are:
1) This is a management nightmare doing it this way
automate
2) It is way too easy to make a mistake and have a RAIDz group
that is not configured properly
automate
NB. this isn't as difficult to change later with ZFS than with some
other LVMs. As long as the top-level requirements follow a consistent
design, changing the lower-level implementation can be done later online.
Worry about the top-level vdevs which will be dictated by the number of
FLX380s as shown above.
3) It would be extremely difficult to scale this type of
architecture if we later added a single FLX380 (6540) to the mix
The only (easy) way to scale while adding a single item, and still retain the
same availability characteristics, is to use a mirror.
To go further down this line of thought would require the customer
to articulate how they would rank the following requirements:
+ space
+ availability
+ performance
because you will need to trade these off.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
