UNSOLVED

AllBlack

updated

18 years ago

A

AllBlack

1 Rookie

74 Posts

0

1715

April 17th, 2008 15:00

LUN sizes

Hi there,

I'd like some opinions on recommended LUN sizes and limits etc.
Obviously most of it will depend on what they are used for.
In our environment most LUN sizes are created as 1Tb.
What are the benefits/drawbacks from this?
And what about one big LUN compared with a metalun spanning smaller LUN.

All feedback welcome!
  • dynamox

    11 Legend

    20419 Posts

    87439 Points

    762

    0

    Posted April 17th, 2008 16:00

    you know what everybody will say .."it depends" ;)

    can you give some info like OS , volume manager , application, replication requirements ..etc
  • AllBlack

    1 Rookie

    74 Posts

    762

    0

    Posted April 17th, 2008 16:00

    A bit hard to give characteristics as we have all kinds of flavours.

    A big one would be VMware ESX 3.5 that stores all its VMs on the SAN.
    Other than that Windows file servers that store users data.
    Another thing I expect to pop up soon is SQL database storage.

    Definitely concentrating on ESX now

    cheers
  • dynamox

    11 Legend

    20419 Posts

    87439 Points

    762

    1

    Posted April 17th, 2008 16:00

    look for this white paper "White Paper: CLARiiON Integration with VMware ESX Server - Applied Technology"

    also take a look at one particular thread called "Striped metaluns and performance" ...you are going to find a very good discussion there.
  • AllBlack

    1 Rookie

    74 Posts

    762

    0

    Posted April 17th, 2008 17:00

    Thanks, Will have a look at that
  • RRR

    6 Operator

    5739 Posts

    762

    0

    Posted April 18th, 2008 04:00

    Remember that ESX has a VMFS limit of 2TB and that is 2047GB. If you try to create a 2TB one, it's invisible for ESX (I tried that).
    Furthermore consider using RDM (Raw Device Mappings), so a VM get's a true Clariion LUN and not just a piece of a larger VMFS. For performance reasons you should consider spreading the load accross as many physical spindels as possible, however: larger RAID Groups have considerably longer "repair" times if a hot spare is invoked, since more disks need to be read to rebuild the missing data. Consider using METALUN's with RG's of 5 spindels (4+1). Each RG has it's own HS and rebuild times will be fair. If performance is not a big issue, use RAID5 (8+1), but remember that rebuild times will be longer.
  • RRR

    6 Operator

    5739 Posts

    762

    0

    Posted April 18th, 2008 06:00

    You can (I'm 96.3 percent certain about that), but I'm not sure if you can move to RDM.
    The source can be RDM, but the target is unsure.
  • dynamox

    11 Legend

    20419 Posts

    87439 Points

    762

    0

    Posted April 18th, 2008 06:00

    Rob,

    do you know if you can do storage vmotion with RDM devices ?
  • kelleg

    6 Operator

    4537 Posts

    762

    0

    Posted April 18th, 2008 12:00

    Also, please review these documents as well - The Best Practice for Fibre Channel Storage - see the section called "Sizing the Storage Requirements"


    EMC CLARiiON Best Practices for Fibre Channel Storage: FLARE Release 26 Firmware Update - Best Practices Planning

    http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H2358_clariion_best_prac_fibre_chnl_wp_ldv.pdf

    EMC CLARiiON Fibre Channel Storage Fundamentals - Technology Concepts and Business Considerations

    http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H1049_emc_clariion_fibre_channel_storage_fundamentals_ldv.pdf

    regards,

    glen kelley
  • SKT2

    2 Intern

    1340 Posts

    762

    0

    Posted April 18th, 2008 13:00

    we use max size of 100GB in HP-UX and Linux .. But there are some with 500GB LUNs used in ESX environment.

    those were choosed considering a lot performance reasons.
  • AllBlack

    1 Rookie

    74 Posts

    178

    0

    Posted April 20th, 2008 13:00

    Looks like a max. of 500Gb is the way to go for ESX, I am getting the same message from the VMware community. Thanks every one for their advice.

    I'll be back ;-)