Monday, 23 November 2009

Storage - LUN Sizing & Standards

Just some quick questions to storage people on a topic that's been rumbling around here for some time :-
  1. Do you have standard sizes for LUNs in your storage estate? If so :-
    1. What was the rational behind having the standard?
    2. What is the actual sizing & layout standard?
    3. What was the rational behind the actual size & layout chose?
    4. Does it vary by storage type / location / product?
    5. Does it vary by application / dataset use?
  2. If you don't have standard LUN sizes :-
    1. Have you noticed any optional / support impacts or complexities?
    2. What benefits have you seen?
  3. How does your device layout & LUN sizing impact, or is impacted by :-
    1. Data replication strategies? (eg application, host agent, VM/FS, pathing, SAN, array etc)
    2. Procurement & purchasing models? (eg large pre-provisioned boxes, small boxes with chunk growth, ad-hoc project based etc)
  4. Do you envisage this situation changing in light of technologies such as :-
    1. Thin provisioning
    2. Wide striping
    3. Automated lun/sub-lun tiering (eg FAST, TSM etc)
    4. Space reclomation (eg ZPR etc)
    5. VM/FS improvements
    6. Some form of improved & useful SRM tools (yes I realise this is a big wish)
I'm interested to know, as we have historically tried to adopt standard RAID layouts, device sizing and LUN sizing - with the view that this eases, simplifies & speeds up storage operational and diagnostics tasks. But increasingly I'm thinking that this matters far less with the storage technologies now available.

Would welcome thoughts and comments?

1 comment:

  1. Ian, we have standards at present and often they get in the way of working in the most efficient manner. I agree with you that this will become less important as the technologies change. I can see a time when we allocate data-space to a service with perhaps high and low water-marks as guidance allowing the array/devices to provision/allocate/deallocate on demand.

    Certainly as we move to arrays which move blocks around according to access profiles, the allocation of LUNs becomes an archiac concept.

    As I have said numerous times, this all feels a bit like moving back into the world of the mainframe. Not a bad thing really as long as the processes put in move faster than glacial.