Enterprise Computing: LUN Sizing and Standards
Enterprise Storage, GestaltIT — By Chris Evans on November 24, 2009 at 10:34 PMIanHF talked recently about LUN sizes and establishing standards across the enterprise. The choice of LUN size is a subject I’ve bored people with ad nauseum over the years and this is a good opportunity to go over it again.
Why Bother?
Ian’s post goes into more detail than the scope I intend to cover here. In fact, all I’m concerned with is LUN size. I don’t mind if it’s 1GB or 100Gb as a standard (well, I do, but that’s another post), all I care about is keeping a consistent LUN size across vendor technologies. Here’s why.
Host Based Migration
None standard LUN sizes mean host-based replication. It means using tools at the host level (like Veritas Storage Foundation) to restructure the data onto new LUNs. Worse, it could mean simply bulk copying of data at the host level, with outages to boot.
Good Advice
Here’s my advice. Pick a consistent LUN size. Choose one that works across all of your storage platforms at the block level, so when you want to move data by virtualisation or other vendor tools, you can achieve it without having to restructure the data.
I’m involved again with a client/customer I left about 3 years ago. At the time, I recommended taking the hit and migrating their disparate infrastructures to a consistent LUN size. They didn’t take my advice and they still have the same LUN size pain points they did 3 years ago. It means the migration process to move off old technology is more complex and expensive than it needs to be.
It’s amazing how such as simple change can be so impactful and how many organisations choose to ignore it.
Tags: IanHF, LUN size, migrations
(No Ratings Yet)
Loading ...
Tweet This
Digg This
Save to delicious
Stumble it
5 Comments
This is solid advice, for enabling heterogeneous replication and also for avoiding fragmentation when LUNs get decommissioned.
I wonder how you square it with virtual or “thin” provisioning: is it still one consistent size across the organization only that it now consists of two sizes, the starting allocated size and the max?
Tzvika
LUN sizes don’t need to change with Thin Provisioning; the thinness factor just has an affect on how pools of disks are managed. I’m referring to the size of the LUN as the host sees it.
Chris
I agree. Standard LU sizes simplify not only storage migrations, but also storage allocations and reallocations. I can list many other reasons. I tried to implement standard LU sizes four years ago between our enterprise and modular arrays, but was unsuccessful due to an incompatibility with an older enterprise frame. By the time I discovered this, the migration was well underway and thus too late to correct. The time now has come to replace all of our storage arrays and this time I will be setting a standard LU size. Yes, it may be a pain, but the benefits are too numerous.
Great idea!! , although you need to consider the size on drives that are changing constantly, which force sometimes choose different partition sizes.
Regards
Alex
Alex
I agree that over time, as drive sizes increase, LUN sizes will too. That should be part of the process. However this change should only occur infrequently and can be tied into a BAU storage replacement process.
Regards
Chris