Vrealize, linked clones and multiple storage arrays

[pgerritse]

In our Vrealize environment users get access to a certain amount of resources (320 GB storage) through reservations. Lately we've added an extra storage array. Using storage policies we make sure windows and linux linked clones are stored on array1 while nested esx-i-vm and other vm's are stored on array 2. Somehow we feel that at least linked clones should be kept on one array to be efficient in terms of cache.

Now in the reservation for storage the multiple arrays are a problem as users now need 2 datastore clusters checked. In fact they need double storage reservations (2x 320GB) since we dont know what type of machines they will deploy. Also for users it's now unclear how much storage they have, since it depends on what they deploy, they could have 640GB if they make a perfect mix of linked clone vm's and esxi-vm's

We would like to give users storage through 1 datastore cluster in their reservation but still be able to push linked clone-deploys to one array (using storage policies? or would linked clones by default strive to stay on one array with their base image?)

We've tried to put the luns of two arrays in one datastore cluster, linked that one datastore cluster in reservations. And put the 2 policy's on lun-level, but unfortunately the storage policy on the datastore cluster cannot be empty.

Question: What would be design considerations for vrealize reservations with multiple arrays? Is there a way to use multiple arrays with reservations to one datastore cluster while still being able to direct certain vm's to specific arrays?

[daphnissov]

Two questions to start:

1. Why are you using linked clones? What is your use case?
2. Have you observed in your environment that linked clones perform poorly when the delta is stored on a different array as opposed to the same array?

[pgerritse]

1) Our 1000 students deploy for example a Windows 2016 blueprint 1000 times and do specific changes for their particular project/lab.

2) Good point. Do you expect that it doesnt make a difference?

[daphnissov]

Ok, just wanted to understand why you might be using linked clones in the first place. I'm not suggesting it does or doesn't make a difference, I just wanted to understand if you had a prior experience that made you think there was an issue. Best thing to do is just try having your linked clones operate on the same array and observe performance. If your array is sufficiently powerful and backed either entirely or mainly by flash, you may not have any issues whatsoever. You could continue to place datastores from both arrays into the same datastore cluster object and configure your reservation with space on there, in one place. The linked clone (delta) disk could be on the same array as the parent or it could be different. Again, you should see how that works in your environment. If you make sure that datastore cluster using sDRS is in fully-automated mode, vCenter will move any of the disks around as necessary. Plus, if you consider the latency metric (which is optional) in addition to the space metric (which is mandatory), this will further ensure the load is balanced around.

[pgerritse]

Thanks for your reply. Indeed it would be best to test this in our environment.

But what would you do:

Would you want to make sure that linked clones and their base file are always on the same array (but different luns)? Or do you think it makes no difference? (a lun on the same array or a lun on another array is still another lun-address right?)

And maybe others use vRealize reservations, linked clones and multiple storage arrays too. So I was looking for ideas, best practices and experiences in this scenario.

[daphnissov]

Linked clones aren't something that I come across very heavily in vRA, so maybe other users can chime in with their experiences there. But from a lower-level picture (vSphere), it *may* make very little difference if the base and linked clone disks are on different LUNs backed by the same array. I say may because it depends on the workload characteristics when it comes to queuing. Same thing with a different array. The thing to keep in mind if you separate them is how linked clones work from an I/O perspective to begin with. The base disk is always read-only. So wherever that resides is going to get beat up with read requests and no writes. For the linked clone (delta) disk, that starts off with as all write I/O. Depending on how long they last, what was written, and how that gets accessed, those will transition over to some reads (because you inevitably need to read the data you've written at some point). Therefore the I/O patterns may be different across those arrays. So if you are going to do that, make sure you're aware of that and ensure your storage can handle that workload appropriately.

[pgerritse]

Thanks for your thoughts on the subject. Am still hoping for experiences, insights and ideas from others.