MSA 2052 diskgroup and vmware

[homermg]

Hi all,

I'm just trying to understand my new MSA 2052.

So i have just created a raid 1 with two SSD'S within Pool A and Raid 5 Volume  also within Pool A Diskgroup for tiering purposes.

So the DIskgroup on Pool A has the total size of 24,1 TB = 2x Volumes ( Volume one = 20,9 TB and Volume two 3 TB) 

Both Volumes are now mounted and formated on Vmware. And i have already lots of vmdks on that volumes. So theroreticaly on this diskgroup is no more space to create new volumes. But it seems that my MSA2052 can see how match is exactly in use under vmware and give me the possibilty to create new volumes with the free remain space which is not in use ander vmware yet.  That is confusing me. If i gonna create a new volume now within this disgroup it will break all my vmware volumes i guess. Can someone explain me this behavior?

On my previous MSA P2000 system with linear vdisks it was pretty easy if you have a vdisk withs lets say 20 TB and two volunes on that vdisk with 15 TB and 5 TB no matter how much was in use or not you was not able to create any voluem on that vdisk.

Hope you can bring some light on that

Many thansk to all

[SUBHAJIT KHANBARMAN_1]

P2000 G3 is Linear array which means any volume space is fully allocated space. Any volume space can be directly mapped from the vdisk in particular.

MS2052 is Virtual Array which means any volume created is thin provision volume. Here volume gets created from Pool and Pool created with single or multiple Virtual Disk Groups (VDG) similar to Vdisk in Linear array. So from Pool perspective you see only space.

When any new write happens at the ESX side then space gets allocated from MSA at the backend. There is no space gets pre-allocated like P2000 Linear array. So no wastage of space.

So in this case whatever space that you see at the time of creation of volume this is called provisioned space and not actual allocation of storage space. So you don't know from which VDG, volume actually got the space for creation or at time of data write space gets allocated. This is abstract and that's why this is Virtualization.

In order to understand more on this I would suggest to go through MSA2052 SMU guide and best practice technical paper.

https://h20195.www2.hpe.com/v2/Getdocument.aspx?docname=a00015961enw

https://support.hpe.com/hpsc/doc/public/display?docId=a00017707en_us

https://support.hpe.com/hpsc/doc/public/display?docId=a00017710en_us

Hope this helps!
Regards
Subhajit

If you feel this was helpful please click the KUDOS! thumb below!

***********************************************************************************

[homermg]

ok got it,

but the volumes are formated already within vmware so the whole space should be now alocated no matter how many vmdk's are on it. I guess storage shouldn't care about vmdks as vmware already has blocked the volumes by formating it as vmfs5. Or im wromg? I guess the should be un allocated space. I think only when i mount the volume in vmware as a raw mapped than i would understand this behavior but not as a usual vmware formatted volume.

Please sse the screenshot

Many thanks for helping

[SUBHAJIT KHANBARMAN_1]

You could have taken one MSA volume and share outputs of the below commands as i don't go by SMU output for better understanding,

show volumes

show disk-groups

show pools

Also you could have share screenshot of the same MSA volume in ESX host and how much space consumed in VMDK level or Datastore level

Most important when you try to understand space related stuff you need to check what is the base value set at MSA and ESX. Please refer SMU guide and section "Size representations",

"Operating systems usually show volume size in base 2. Disk drives usually show size in base 10. Memory (RAM and ROM)
size is always shown in base 2. In the SMU, the base for entry and display of storage-space sizes can be set per user.
When entering storage-space sizes only, either base-2 or base-10 units can be specified. Base 10 is the default."

In order to check this, you can use MSA command,

show cli-parameters

********************************************************************************************************************************************

In general whatever space you see as Allocated in MSA that means data written in that space in Pool level or VDG level but the space shows as Unallocated means volume not yet written data in it. So unallocated space related to volume level

If I take your example, in case of Pool B total size = 8990GB

Provisioned size of volume named archive-volume = 8989.9GB

Allocated size of archive-volume = 907.9GB

This means unallocated size at the volume level = (8989.9-907.9)GB = 8082GB [This space not dedicated for any particular volume, this can be use by any volume part of that Pool]

you can see free space = 8082.6GB and uncommitted space = 566.2MB

So free space is nothing but sum of unallocated space + uncommitted space which is coming from Virtual pool

Uncommitted space is the overall space minus the allocated and unallocated space.

Hope this helps!
Regards
Subhajit

If you feel this was helpful please click the KUDOS! thumb below!

***********************************************************************************

[homermg]

hmmm

ok lets try that this way please.

If you take a look at my screenshot you will see:

Virtual Pool A = 24,TB with two volumes on that ( Volume1= 20,9TB+ Volume2=2,9TB). I have mounted thos both volumes in VMware and formated with vmfs5.

Virtua Pool A = Alocated space 15.5 TB and Unulocated space 8,4 TB

I see the same now under Vmware =  ( Volume1= 20,9TB+ Volume2=2,9TB) = free space on both together = 8,4 TB

So MSA showing me the same as Vmware, so that is fine.

BUT under VMWARE this both volumes size are constant 

On MSA it looks like i still be able to create a volume with the unused space i see on my VMWRE as it showing me the unused space under vmware as unallocated space on MSA SMU. 

What Im not sure about is can i now create a third volume with the unallocated space? If some i guess it will distroy my VMware volumes. I hope you know what i mean.

Many Thanks!

[SUBHAJIT KHANBARMAN_1]

Thanks for your confirmation that what you see in MSA exactly matching in ESX as well. So one part is done - this means both system base value set at correct value.

Now you need to understand what is Thin Provision volume that will clear all your doubts. 

In MSA no one is stopping you to create third volume and that is not related or depend on how much unallocated space you have in the system.

You can create even 30TB volume with current condition eventhough you don't have that much space available in the system. This is the beauty of Thing provisioning. This means you have created 30TB provisioned volume - this means your volume can take space up to 30TB that doesn't mean you need 30TB space at the time of creation itself. In order to create a thin provison volume you just need some KB of size only. As in when you start writing data on it at the host filesystem level space will get allocated for that volume from Pool from which it got created at the backend.

Now anothing thing to make you understand, for any volume allocated space and unallocated space are committed space for that volume from the Pool from which it got created. This means if you have created 30TB volume then this is expected from that pool that it should be able to provide 30TB space to that volume. So Pool is committed to provide this much space to the volume. That's why unallocated space even though not yet allocated to the volume but this space committed to that volume. That doesn't mean committed unallocated space dedicated for any volume. Unallocated space in that Pool can be used by any volume part of that Pool.

Now any space which shows under uncommitted means this space part of the Pool but not required to be for any volume as unallocated space fullfil the requirement of committed space. Both uncommited space and unallocated space represents free space in the Pool.

So in your case if you really create any third volume with current condition and plan to use it then you can do so but make sure you closely monitor them and add more space to fulfill all volume commited space requirement as in when required.

In ESX if you see any MSA volume space.......this can't be fixed.......it must change........you can clearly see it...........you may be looking at the datastore screen only...........you need to explore more to see it properly

Hope this helps!
Regards
Subhajit

If you feel this was helpful please click the KUDOS! thumb below!

**********************************************************************************

[homermg]

Hi Subhajit,

yes I understamd that with the MSA thin provision space.

What still not clear is the VM datastore:

In ESX if you see any MSA volume space.......this can't be fixed.......it must change........you can clearly see it...........you may be looking at the datastore screen only...........you need to explore more to see it properly

I mean sure that is not fixed when i trasfer data on the vmware datstore i will have less availble free space. but When i mount a voulume to vmware i format that with a specific TB or GB amount, that is thick provisioned. An that formated capacity is not thin provision that is fix= thick.

That what i mean it can't be thin provision on msa and thick provisioned on vmware datastore

Hope that make sense?

[SUBHAJIT KHANBARMAN_1]

Ok now I got your doubt. Actually you are getting confused because you are seeing fixed space as formatted capacity inside VM or from Guest OS perspective. These are called thick disks, they behave similar to thinly provisioned disks. Disk blocks are only used on the back-end (array) when they get written to inside in the VM/Guest OS. Again, the Guest OS inside this VM thinks it has this maximum size from the start. There are two types of Thick disks in ESX apart from Thin disks and they are "Eager Zeroed Thick" and " Lazy Zeroed Thick". I would suggest to go through these concepts in VMWare - that will help you to understand more on this.

Hope this helps!
Regards
Subhajit

If you feel this was helpful please click the KUDOS! thumb below!

***********************************************************************************