3 Replies Latest reply on May 4, 2018 10:59 AM by OsburnM

    vrops 6.7 Allocation Model

    sxnxr Expert

      Since deploying 6.7 in or lab i have been working on a workaround to get the allocation model working again. To do this i have created several supermetrics that i wish to share

       

      Cluster level metrics

       

      The below will get the total physical cores in a cluster and divide that by the number of hosts in the cluster to get how many cores are in one host (${this,metric=cpu|corecount_provisioned}/${this, metric=summary|number_running_hosts})

       

      It will then take that away from the total cores in the cluster to give you the cores in a cluster with one host removed for HA

       

      Change the 1 at the end to what you want your over commit ratio to be to get the CPU usable

       

      (${this, metric=cpu|corecount_provisioned}-(${this,metric=cpu|corecount_provisioned}/${this, metric=summary|number_running_hosts}))*1

       

      The below is the same for memory. Change the 1.5 to what ever overcomit you need. the below if 50% and 1073741824 at the end converts it from kb to GB

       

      ((${this, metric=mem|host_provisioned}-(${this, metric=mem|host_provisioned}/${this, metric=summary|number_running_hosts}))*1.5)/1073741824

       

      The above two metric i use for reference the below two will give you the old capacity remaining. the first part is the same as the above but the -${this, metric=cpu|vcpus_allocated_on_all_vms}) at the end will remove all the VCPUs allocated to all VMs regardless of power state from the usable capacity again change the *1 to what ever the overcomit is

       

      (((${this, metric=cpu|corecount_provisioned}-(${this,metric=cpu|corecount_provisioned}/${this, metric=summary|number_running_hosts}))*1)-${this, metric=cpu|vcpus_allocated_on_all_vms})

       

      For the memory

       

      (((${this, metric=mem|host_provisioned}-(${this, metric=mem|host_provisioned}/${this, metric=summary|number_running_hosts}))*1.5)-${this, metric=mem|memory_allocated_on_all_vms})/1073741824

       

       

      Disk level metric

      The disk one will work with thick or thinned datastores. Change the 0.15 to include what ever buffer you want. In this case i remove 15%

       

      (${this, metric=capacity|total_capacity})-(${this, metric=capacity|total_capacity}*0.15)-(${this, metric=diskspace|disktotal, depth=1})

       

      Dont forget to only assign the CPU and memory metrics to the cluster level only and the disk to the datastore objects only. Never assign them to all objects. Hope this helps

        • 1. Re: vrops 6.7 Allocation Model
          sxnxr Expert

          made a change to the memory one to enable the next one. the /0.0009765625 converts it from TB to GB i prob could have just devided by one number but can be bother working it out

           

          ((((${this, metric=mem|host_provisioned}-(${this, metric=mem|host_provisioned}/${this, metric=summary|number_running_hosts}))*1.5)-${this, metric=mem|memory_allocated_on_all_vms})/1073741824)/0.0009765625

           

          The below takes the capacity remaining value for CPU and memory and works out how many deployments of 4 x 32 VMs you can do by using an if statement supermetric

           

          It reads as follows:

          if CPU capacity remaining supermetric /4 cpu is greater than or equal to memory remaining supermetric / 32 gb ram then display memory remaining supermetric / 32 gb else display CPU capacity remaining supermetric /4 cpu

           

          (${this, metric=Super Metric|sm_80000f35-b873-47cd-a3fc-b70398c2f06d, depth=1}/4)>=(${this, metric=Super Metric|sm_806ee4fa-322b-4a25-a0a0-11453c14a4b2}/32)?(${this, metric=Super Metric|sm_806ee4fa-322b-4a25-a0a0-11453c14a4b2}/32):(${this, metric=Super Metric|sm_80000f35-b873-47cd-a3fc-b70398c2f06d, depth=1}/4)

           

          All you have to do is create more changing the 4 and 32 in the SM to what you want.

           

          The SM IDs are specific to me so if you create you own capacity remaining SM use yours

          • 2. Re: vrops 6.7 Allocation Model
            OsburnM Enthusiast

            This is good stuff.  I decided to do something similar because of the 6.7 changes.

             

            Food for thought, I chose to use the vCenter HA Memory & CPU Resource Reserve percentages that are present on a cluster object, to account for how much is used for HA.  This way you don't need to adjust your SM and instead can use the value in vCenter cluster objects.  It also lets you have different HA numbers on different clusters w/o having multiple supermetrics.

             

            So for example the memory one looks like this:

            sum((${this, metric=mem|host_provisioned}-(${this, metric=mem|host_provisioned}*(${this, metric=configuration|dasConfig|admissionControlPolicy|memoryFailoverResourcesPercent}/100)))-(${this, metric=mem|memory_allocated_on_all_vms}))/1024/1024

             

            (total memory in the cluster of all hosts, minus the memory reserved by the HA percentage, minus the memory allocated to all VMs in the cluster)

             

            This SM results in the amount of physical ram available in the cluster, after accounting for the HA node as defined in vCenter. 

            • 3. Re: vrops 6.7 Allocation Model
              OsburnM Enthusiast

              Just to give you an idea, after creating vCPUs avail after HA and a RAM avail after HA supermetrics, and creating a metrics config xml, I updated/modified the Utilization dashboard and created a new "quick view" / dashboard that gives our team an easy Allocation model free cpu/memory way of seeing things.

               

              I wont go through step-by-step, but here's some pics of what I have setup and should be enough to get you going if you're inclined to do so...

              Cluster Utilization Overview.pngCluster Capacity Quickview.pngMetricConfigs.pngSM1.pngSM2.png