Home | GestaltIT | Enterprise Computing: LUN Sizing and Standards

Enterprise Computing: LUN Sizing and Standards

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 0 Flares ×

IanHF 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.

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.
  • Tzvika Barenholz

    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?

  • Ron Major

    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.

  • Alex

    Great idea!! , although you need to consider the size on drives that are changing constantly, which force sometimes choose different partition sizes.
    Regards

    Alex

  • Chris Evans

    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

  • Chris Evans

    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

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 0 Flares ×