This post is more than 5 years old
385 Posts
0
1760
64000 limit on DMX-4?
We are getting conflicting reports on the 64,000 device limit. The DMX-4 documentation lists that we can get 64,000 logical devices out of a system with mixed mirrored and Raid-5 devices.
The confusion comes with the assertion that we need to increase our LUN size from ~8GB to somewhere over 16GB. This is all based on the assumption that a single Raid-5 device counts as 4 addresses towards this 64,000 limit. Logically I would think a single Raid-5 LUN would count as one address towards this 64,000 limit because it will only provide 1 addressable LUN.
So does anyone know if the 64,000 limit is addressable devices or based on the logical splits?
The confusion comes with the assertion that we need to increase our LUN size from ~8GB to somewhere over 16GB. This is all based on the assumption that a single Raid-5 device counts as 4 addresses towards this 64,000 limit. Logically I would think a single Raid-5 LUN would count as one address towards this 64,000 limit because it will only provide 1 addressable LUN.
So does anyone know if the 64,000 limit is addressable devices or based on the logical splits?
mlee2
108 Posts
0
January 15th, 2008 20:00
O.K. Hopefully I can explain this without causing too many heads to spin around
We have a limit at each Enginuity family as to the maximum number of logical volumes that the SymmWin program can create and that microcode can support.
Simple answer: Enginuity 5772 for DMX-3 & DMX-4 can create & support 64,000 logical volumes (Symm Vols or symdevs).
This is 64,000 host accessible volumes i.e. volumes that can be assigned to channels (the Enginuity code can actually create a few more non-accessible volumes). This limit is regardless of the type of data protection selected. That is, I can have 64,000 unprotected BCV's or 64,000 Raid-6 14+2 logical volumes (or anything in-between).
The number of individual Raid members that make up a single Symmetrix Volume DON'T count towards this 64,000 SymmWin limit.
Note the ominous this limit....
Complex answer: What you also have at each Enginuity family is a microcode limit to the number of hyper volumes (currently 255) that you can create on a single physical drive (the maximum number of "splits"). Each split on a physical disk then becomes an "entity" that must be managed by the Disk Director / Adapter (DA) microcode. These entities are referred to as DA "targets" and every individual DA processor has a DA target "limit". The DA targets are NOT related to the individual volume size, an unprotected 65,520 cylinder volume and 3 cylinder volume only use one target each.
Question: So can I create 64,000 logical volumes on a DMX4-4500 and a DMX4-950 since both can run Enginuity 5772?. Of course, the volumes would be really small on the 950 (with its fewer drives / DAE's).
Answer: No. Regardless of the individual volume size the greater number of DA processors on a bigger box means a higher overall DA target limit for the entire Symmetrix.
Now this is where the type of data protection "kicks in". One unprotected volume uses one DA target, one 2-MIR protected volume uses two DA targets, one Raid-5 7+1 logical volume requires eight DA targets, etc, etc.
Question: Do I need to worry about the drive or DA target limits in microcode?
Answer: Typically not at all. Your friendly EMC Implementation Specialist will advise you on the number of logical volumes (for a given protection method) that you can create for a given Symmetrix Model. The DA target limits are particularly generous and the SymmWin program automatically caters for these limits when creating / laying out logical volumes on the Symmetrix backend.
Question: So why mention these limits at all?
Answer: Only to explain why the "one size fits all" answer of 64,000 logical volumes won't apply in every case and why the earlier EMC answers have differed AND why you need to buy a really big box
Hopefully this answers all your questions...
Best Regards,
Michael.
xe2sdc
2 Intern
2 Intern
•
2.8K Posts
0
January 15th, 2008 08:00
From what I can understand, someone told you that due to RAID5 you have to build bigger luns .. It's not a limit in the maximum symdev count but instead a limit in the maximum number of slices that the code can handle in every device. If I have a 300 Gb disk and I'm using raid5 7+1, I'm going to create a lot of small slices (each slice will be one seventh of the whole disk). Since I can create UP TO 255 slices on a device (If my memory isn't failing) I can create 255 slices, 1.17 gb each.
With 7 slices 1.17 gb each you can have volumes 8.2 Gb big .. And you are filling your drives with RAID slices.
But now let's to again the math for 500 gb drives .. If you use the same size as before, you can stlill build up to 255 slices, 1.17 gb each .. But you'll fill only 300 gb and not the full disk. You need to use bigger slices to fill the disk .. So you need to create bigger devices to fill your disks
I think that's the real reason to have bigger devices with bigger disks and RAID5
Cheers !!
bodnarg
385 Posts
0
January 15th, 2008 10:00
The confusion is we have not gotten a hard answer - the only answer we got implied that Raid-5 3+1 counts as 4 devices and then had a different technician refute this claim. Looking for a 3rd party to arbitrate
Reading the documentation it is not very clear. One section of the DMX-4 guide seems to reference that 64,000 equates to Symmetrix devices, but then when you read about Raid-5 it states that in the case of Raid-5 3+1 you have 4 hypervolumes which implies 4 devices to me :S
This just does not seem like this should be a hard thing to answer.
The heartburn this is causing is that we can't use SRDF because of the striped meta configuration we have and the fact that we'd lose to much storage.
We did ask about the code level and did not get a definitive answer, but I can't blame someone for not banking on something they can not control
PS The code question was asked, but in fairness
xe2sdc
2 Intern
2 Intern
•
2.8K Posts
0
January 15th, 2008 12:00
xe2sdc
2 Intern
2 Intern
•
2.8K Posts
0
January 16th, 2008 00:00
mlee2
108 Posts
0
January 16th, 2008 00:00
bodnarg
385 Posts
0
January 16th, 2008 05:00
Thank you for providing a complete answer to this question.
mlee2
108 Posts
0
January 16th, 2008 16:00
don't have any issue until you try and use higher
density Raid-5 like 7+1 or Raid-6 14+2 with smaller
LUN sizes.
RRR
2 Intern
2 Intern
•
5.7K Posts
0
January 17th, 2008 04:00
Why not ? You certainly CAN do SRDF with striped metas ! Maybe concattenated metas will perform better, but there's no rule that forbids you to use striped metas in SRDF configs.
bodnarg
385 Posts
0
January 17th, 2008 05:00
Basically not being able to take 4-member striped meta volumes with 7.73 GB LUNs and SRDF them to the newer larger 16GB LUNs without losing too much data. Not an issue for concatenated - but does not work nicely with SRDF
RRR
2 Intern
2 Intern
•
5.7K Posts
0
January 17th, 2008 06:00
Hmmm.... I'll suspend for now, but keep on reading all of your comments. Interesting.
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
January 17th, 2008 20:00
xe2sdc
2 Intern
2 Intern
•
2.8K Posts
0
January 17th, 2008 23:00
However in case of a target bigger then the source you don't waste space since most OS allows to resize the disks .. i'm pretty sure that at least AIX allows to use the extra capacity
The following primus solution explain how to manage bigger luns with AIX. Even if the primus refers to a metalun in a CX, the concept still applies: emc106920 and emc87880
Please note that applying the above mentioned primus will render useless the source devices since you won't ever be able to "failback" (since now the vg will span the whole capacity of the drives). Use with care !!
Cheers !
Message was edited by:
Stefano Del Corno
Message was edited by:
Stefano Del Corno
RRR
2 Intern
2 Intern
•
5.7K Posts
0
January 18th, 2008 02:00
And how other OSs deal with suddenly enlarged disks, it depends on the OS and the applications that deal with the luns.
RRR
2 Intern
2 Intern
•
5.7K Posts
0
January 18th, 2008 02:00
Windows as well, so that makes 2. Anyone any thoughts about UX, Linux, Solaris ?