VMware vSphere

 View Only
Expand all | Collapse all

storage best practice ?

  • 1.  storage best practice ?

    Posted May 05, 2012 06:53 PM

    Guys

    i have a question , im setting up a new cloud with a bmc automation tool , i have 40 hosts and will split them into 8 hosts esx clusters.... the automation tool team claims that the best for them is to have one single set of luns (big ones with 40TB) that is shared between all the 40 hosts...isnt it a best practice that each cluster can see only it's own set of luns?  (the luns are fc/vmfs)

    any suggestions?



  • 2.  RE: storage best practice ?

    Posted May 05, 2012 08:45 PM

    Well your automation tool is wrong on so many fronts.

    40 TB LUN is not a good idea. Unless your are planning on running 20 2TB VMDKs on it (still to much). And if you will be running regular sized VM's it way to much, even for a VAAI capable array.

    Read this regarding locking mechanisms on VMFS. http://blogs.vmware.com/vsphere/2012/05/vmfs-locking-uncovered.html

    You don't want to many VM's on any given LUN or you will eventually get latency problems.

    Size your LUNs according to the VM's that will populate it.

    Yes I would recommend on having specific LUNs for each cluster, but you can map it to the other hosts (for failover).

    Is this for a View setup? Just asking as you are sizing the clusters at 8 hosts.

    Good luck.



  • 3.  RE: storage best practice ?

    Posted May 05, 2012 08:50 PM

    It would also be worth checking your SAN configuration maximums, as some arrays may have issues with too many connections per volume.



  • 4.  RE: storage best practice ?

    Posted May 05, 2012 09:35 PM

    the array is a emc vnx ,  it's a vblock system



  • 5.  RE: storage best practice ?

    Posted May 05, 2012 08:59 PM

    yes i know that... im sizing 8 hosts per cluster because of nexus1k limitations , n1k limits to 2k vethernet interfaces and each VM has 3 nics so i can have 666 vms per 8 hosts cluster

    you think i would be okay if i share 2TB luns between all those clusters? the environment is not a vmware view and will offer multiple vms with different sizes.

    :smileyhappy:



  • 6.  RE: storage best practice ?

    Posted May 05, 2012 09:14 PM

    Aaa the infamous Nexus :smileyhappy:

    Yes it would be OK to share 2TB luns between all these clusters.

    But I would plan the size of the LUNs according to the application it will be hosting, e.g:

    • SQL will require its personal datastore for logs etc, among other setups.
    • Oracle has its recommendations
    • Exchange also... any tier 1 applications requires careful planning as a matter of fact.
    • You can create larger LUNs for not-so-busy fileservers
    • If you will be creating sub 100 GB machines you could go over "sweetspot" for VMs per Datastore ratio. (sweetspot is dependant on so many variables (VAAI, array type, cache etc.))

    Also you can always sVMotion machines off a datastore, delete them and recreate smaller/larger ones. :smileyhappy:



  • 7.  RE: storage best practice ?

    Posted May 05, 2012 09:43 PM

    vlarus

    but regarding perfomance the best is to have each cluster with it;s own set of luns right?

    i dont want to make an exception to the infratructure because of the automation tool ... they will have to find a way to solve this.

    the problem its a cloud with a lot of diferent tenants ... the portal will provision the vms autmatically  , so i must have s very generic system im not sure if we will be able to control what the user is running on their vms (sql , oracle , web server)

    any toughts?



  • 8.  RE: storage best practice ?

    Posted May 05, 2012 11:39 PM

    I agree with you "each cluster with its own set of luns right".

    Some references to support you with your storage guys: "Storage Considerations for VMware vCloud Director" (http://www.vmware.com/files/pdf/techpaper/VMW_10Q3_WP_vCloud_Director_Storage.pdf) search for "Summary of Best Practices"

    Moreover vCloud does not supprot Storage DRS (http://kb.vmware.com/kb/2005726) so share big LUNs across clusters make quite difficult to manage VMs performances on the storage side.

    HTH

    Sam



  • 9.  RE: storage best practice ?

    Posted May 06, 2012 12:25 AM

    we are using BMC CLM in this case , not vcloud director , is there anything similar for clm?



  • 10.  RE: storage best practice ?

    Posted May 06, 2012 12:48 AM

    OK, I supposed you will use CLM on top of vCloud as presented here: http://www.vmware.com/files/pdf/vmware_BMC_Cloud_Lifecycle_Management_and_vCloud_Director_DS.pdf

    I just see this landing about ofr the VMware-BMC partnership http://www.vmware.com/solutions/partners/alliances/bmc-resources.html

    Anyway, since vSphere will handle physical components I still support the scenario 1 cluster 1 set of LUNs.

    You may want to read this post about multiple DRS cluster to a Single Storage DRS (http://frankdenneman.nl/2012/04/connecting-multiple-drs-clusters-to-a-single-storage-drs-datastore-cluster/), it is always VMware related.

    My 2 cents

    Sam



  • 11.  RE: storage best practice ?

    Posted May 06, 2012 09:24 AM

    If this is vCloud director under the BMC Life Management it still needs to follow best practices for vClouds.

    So I would not recommend 2TB luns as at this time in the "cloud" infrastructure. Most of the VM's that will be stored there will be regular sized VM's.

    As I'm not that familiar with BMC I can only infer my own knowledge regarding vCloud.

    When designing vCloud its best to have an idea of how the ratio of VM's disk size will be, and then create LUNs accordingly.

    If you take a look at the vCAT page 27:

    When considering the number of virtual machines to place on a single datastore, some of the following factors should be considered in conjunction with any recommended VMs-per-LUN ratio:
    • Average virtual machine workload/profile (in particular, the amount of I/O).
    • Typical virtual machine size (including configuration files, logs, swap files, and snapshot files).
    • VMFS metadata.
    • Max requirement for IOPs and throughput per LUN, dependency on storage array and design.
    • Max RTO, if a LUN is lost—that is, your backup and restore design.

    Table 23. Datastore Size Estimation Factors – res-pod1 Cluster

    Variable

    Value

    Maximum Number of VMs per Volume

    15

    Average Size of Virtual Disk(s) per VM

    40GB

    Average Memory Size per VM

    2GB

    Safety Margin

    20% (to avoid warning alerts)

    For example,

    ((15 * 40GB) + (15 * 2GB))+ 20% = (600GB + 30GB) * 1.2 = 636GB

    So this is something that needs careful planning or you will probably hit storage bottlenecks from IO hungry tenants. Just make sure to turn on Storage I/O control as well.

    So to make it short:

    1. As this is a vCloud, make sure datastores are specific to clusters. No sharing as SVMotion isn't supported or recommended.
    2. Create smaller LUNs than 2 TB, based on your planned average VM size.

    ps. If BMC does not need vCloud as a base, please scratch these recommendations and check BMC documentation :smileyhappy:

    Good luck