- Do you have standard sizes for LUNs in your storage estate? If so :-
- What was the rational behind having the standard?
- What is the actual sizing & layout standard?
- What was the rational behind the actual size & layout chose?
- Does it vary by storage type / location / product?
- Does it vary by application / dataset use?
- If you don't have standard LUN sizes :-
- Have you noticed any optional / support impacts or complexities?
- What benefits have you seen?
- How does your device layout & LUN sizing impact, or is impacted by :-
- Data replication strategies? (eg application, host agent, VM/FS, pathing, SAN, array etc)
- Procurement & purchasing models? (eg large pre-provisioned boxes, small boxes with chunk growth, ad-hoc project based etc)
- Do you envisage this situation changing in light of technologies such as :-
- Thin provisioning
- Wide striping
- Automated lun/sub-lun tiering (eg FAST, TSM etc)
- Space reclomation (eg ZPR etc)
- VM/FS improvements
- Some form of improved & useful SRM tools (yes I realise this is a big wish)
Would welcome thoughts and comments?
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.
ReplyDeleteCertainly 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.