Unisphere on VMAX - Capacities

yes you are right. If you understand the above parameters, you can find out the actual usage. As a starter, you can add up allocated capacity of all pools to get the total allocated space to your hosts and sum of written capacity will tell you the actual used capacity.

Below is the sample data i have captured from SMC. if you sum up the total written of all devices, you will get the actual written capacity of VMAX.

regards,

Saurabh

Thank you Saurabh.

Would it be possible for you to provide me with a brief explanation of the following just to clear my confusion please:

- Total Capacity

- Free Capacity

- % Allocated

- Maximum Subscription

- % Subscription

- Enabled Capacity

- Allocated Capacity

Thanks

JS

Check this doc:

https://support.emc.com/docu7383_Best-Practices-for-Fast,-Simple,-Capacity-Allocation-with-EMC-Symmetrix-Virtual-Provisioning.pdf?language=en_US

page # 259

Thank you Saurabh. I dont know if this is confusing in general or if its just confusing me...

I could figure out the following:

Total Capacity = Sum of capacities of Data Devices (enabled or disabled) in the pool (which is the total physical capacity of the pool) - please confirm?

Free Capacity = Out of all the "enabled" Data Devices, how much is free? or our of ALL the Data Devices (enabled and disabled), how much is free - please confirm?

% Subscription = Couldn't figure it out - any ideas?

Enabled Capacity = We can enable or disable data devices in a Thin Pool. So the Enabled Capacity is the sum of ALL enabled data devices. - please confirm?

Allocated Capacity = Out of the "Enabled Capacity", how much are bound to Thin Devices - please confirm?

% Allocated = (Allocated Capacity / Enabled Capacity) x 100 - please confirm?

My main concern is, i am planning for storage expansion and i want to understand how much my TOTAL USABLE capacity is and how much is actually allocated to servers. I dont want to have my capacity "oversubscribed" for now.

Thanks

JS

"Allocated Capacity = Out of the "Enabled Capacity", how much are bound to Thin Devices - It is the amount of space you have allocated for tdev in a pool using the allocate command. If allocated to 100%, it means you have blocked the space in pool equal to your tdev size."

That can't possibly be. We are using Thin Pools and Fast VP and I am unable to bind any more volumes to a pool that is reported as using only 52% "Allocated Capacity". I would believe you if you said this is the amount of physical space consumed out of the DATA Volumes that make up the pool. My claim is further supported by observing that each DATA Volume is about 52% consumed in the Related Objects link in the Pool details.

That being said, is there truely a way to find out how much Capacity has been Allocated? I look at it like booking a flight. I have a 100 seats on the plane but I can over book it. Over booking it is fine as long as I don't have 101 or more people show up to fill the seats. It appears to me that I have no idea of knowing how many tickets I've sold for the flight though.

Yes for certain the subscription rate is set to 100%, because we are unable to do anything quickly (government) to address capacity needs if we oversubscribe the pool. According to the Unisphere console it reports me having consumed 52% of the allocated capacity. When in fact it is somewhere just shy of 100% since I am unable to bind any more volumes to that Pool. How do I find out what the real allocated capacity is?

Going back to my plane example, I have booked 100% of the seats for the pool in question, though Unisphere says I have only booked 52%. I believe that the 52% actually refers to having people sitting in 52% of the seats so if I wanted to overbook the flight I have 48% of the plane to work with since almost half of the consumable capacity hasn't been written to. From what I can tell there is no way to find out how many plane tickets I have truly sold (allocated capacity).

Bound/subscribed capacity == the sum of all the TDEVs bound to that pool. (Total fully inflated size, not thin)

Allocated capacity == the sum of all the actual data written to that specific pool.

Your allocated capacity is, as you stated, 52%. Your bound capacity is likely 99 or 100% since you say that you cannot bind any more. The problem with your plane example above is that the array is made up of multiple pools.You are only considering one of them in your example. Each pool has both a bound (subscribed) number and an allocated (written to) number.

Essentially what's happened here is that you've likely bound everything to FC, while FAST VP has then gone ahead and moved data around into other pools. So you've 100% bound your FC pool, but now some of that data is in other pools. Bound/subscribed does NOT take FAST VP into account. It is quite simply the summation of all bound TDEVs to that specific pool.

For example, you might have a 100GB TDEV bound to FC, but FAST VP has gone ahead and moved all that data into flash. In this example your 100GB TDEV is counting toward the subscribed % for FC but accounting for the allocated % in flash.

In your instance you should be looking at the capacity of the entire array when setting subscription limits. Either that, or start binding to other pools that have not yet met their subscription limit.

Where do I go to get the bound capacity for a pool? I am unable to find that.

edit:

It appears that I am using the incorrect terminology. It would appear that Unisphere calls the bound capacity, "% Subscription". Am I correct in thinking so?

You are correct. % Subscribed is the total amount of TDEVs bound to the pool.

In your case, I can see that you've bound ~169TB to your pool but currently have ~79TB of actual data in the pool.

If you have access to solutions enabler, this command will give you a very thorough listing of where your devices are bound and what pools their capacity is actually allocated from:

symcfg -sid xxxx list -thin -pool -detail -v -gb

Pay special attention to the the bottom of each column. The command will show you a summation at the end of the output for each pool which should match the numbers you're seeing above.

Is this pool part of a FAST VP configuration?

yes it is.

Your airplane ticket example might look something like this:

• Total or Usable = The total number of seats that can be allocated.  In our example lets say we have 167 seats that can be allocated on our airplane.
• Subscribed = The total number of tickets sold.  In our example lets say we have sold 177 tickets.  Our trend analysis shows us that on average 12% of tickets sold for this flight do not check in.  Our risk analysis believes this is tolerable and the business agrees to carry a maximum subscription of 106%.
  • When Subscription is more than 100% of what can be allocated there is no guarantee of a ticket becoming a seat.  Only premium customers are guaranteed a seat.  In VMAX Virtual Provisioning terms this premium represents any device that has had capacity pre-allocated.
• Allocated = The number of tickets converted to ticketed-seats for the flight.  Allocated will never be more than the total number of seats available and will be a mix of premium tickets and first come first served from economy.
• Written = The number of ticketed-seats with passengers recorded in the flight manifesto for take off.  This number can be less than the allocated number of ticketed-seats and less than the total number of seats that can be allocated.
  

I would recommend reading pages 67 to 71 of the document https://support.emc.com/docu31003_FAST-VP-for-Symmetrix-VMAX-Theory-and-Best-Practices-for-Planning-and-Performance.pdf?… that describes device binding, capacity management and subscription considerations when using FAST VP on VMAX.

Some notes:

• All thin devices should be bound to a single FC pool, and the pool level maximum subscription limit on this binding pool set to a percentage value that equals the total usable capacity of all thin pools in the FAST VP policy (see Page 71).
• To do this the calculation is: (TotalAllThinPoolCapacity/BindingPoolCapacity)*100
  • *100 is the equivalent of setting a 100% maximum subscription limit for the total capacity of all pools.
• Any pool where thin devices should not be bound should have their maximum subscription limit set to 0 to prevent accidental binding.
• FAST VP allocation by policy should be enabled to accommodate writes that result in a new VP allocation from one of the other pools with free space should the binding pool become full.
• By doing these actions, you would not be oversubscribing the total capacity available in all thin pools that are part of the FAST VP policy.....unless you multiply the output by more than 100 that would result in oversubscribing the total usable capacity from all thin pools.