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?
Posted by at 08:30
Labels:
Reactions: 

1 comments:

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

Subscribe to: Post Comments (Atom)