Host Cluster to Datastore Cluster Design

[Uni_of_Newcastl]

Hi There,

We have a storage migration project at the moment I have an opportunity to redesign the existing "Host Clusters" and the "Datastore Clusters" mappings. Keeping in mind HA, DRS, different Tiers of storage, Management and all the best practices I'm thinking along the lines of the following (I've simplified this just for the example)

Host Clusters	Datastore Clusters
Production	Production-Tier1 - Datastore1 (ssd) - Datastore2 (ssd) - DatastoreX (ssd)
	Production-Tier2 - Datastore1 (15K disks) - Datastore2 (15K disks) - Datastore3 (15K disks)
Test	Production-Tier2 - Datastore10 (15K disks) - Datastore11 (15K disks) - Datastore12(15K disks)

Each hosts in the Production Compute cluster will see ALL datastores in the Production Tier 1 & 2 datastore clusters and vice versa I.E. fully meshed. There will be some shared standalone datastores that are seen by ALL hosts which will be used for Templates, ISO's, and sDRS migrations.

I'm curious what other companies are doing and if there's any gotcha issues with the above?

Cheers

[DavoudTeimouri]

Hi,

I think, it's a design that most companies use that for distribute resources.

But cluster design is related to hosts numbers, your HA slot size and others. For example, you need to N+1/N+2 for your failover or minimum 10% of your cluster resources as failover. Also It's related to your hardware, when you are using blade servers, it's better that you add hosts from different enclosures to clusters.

About datastore cluster design, based on my experiences, when you have large clusters, you need to limit access of each cluster to some datastores.

For example, if you have three clusters with 48 hosts, so each cluster have 16 hosts and you have 90 datastores, you should assign 30 or fewer datastores to each clusters. Of curse, you can assign all datastores to all hosts even on large clusters.

[JPM300]

Yup that looks pretty standard.

I would just make sure your templates Datastore has enough space to move any of your VM's in either enviroment.  This is just encase you want to live migrate the VM from 1 cluster to another without having to share out additional datastores.  However you could always just share the datastore temporarily, do the svMotion, then unshare it.  It's really optional, just something I thought I would touch on.

Also if you want you can create VM Storage Profiles then assign them to Datastores / VM's.  Currently with VM Storage Profiles it won't svmotion a VM over to the proper storage or anything like that, its mainly just for a compliance check.  For this reason most people don't use them but depending on how many Admin's you have in your vCenter doing operations it can come in handly.  Plus I think this feature will continue to be improved to allow for more dynamic control in the future, but I guess we'll see.  Figured I would just bring it up.

Good work!, and good luck with the migration

[vThinkBeyondVM]

I agree with other views. Plan looks good to me.

As in production environment all the datstores are shared with all the hosts, you may want to leverage SDRS for IO and Space balancing. Also for fair IOPS distribution across VMs, you can go for SIOC . SDRS & SIOC are vCenter features (You need to have valid licenses)

One lat line I did not understand is : "There will be some shared standalone datastores that are seen by ALL hosts which will be used for Templates, ISO's, and sDRS migrations."

sDRS migration : do you mean standalone datastores  just for SVMotion ?

[Uni_of_Newcastl]

Hi,

Host Clusters	Datastore Clusters
Production	Production-Critical-Tier1
	Production-Critical-Tier2
SQL	SQL-Tier1
	SQL-Tier2
Test	Test-Tier2

So I'll have the following data stores that can see ALL hosts in ALL clusters.

Standalone Datastores	Purpose
Datastore-Templates	This datastore will be visible to ALL hosts in ALL compute clusters. The purpose of this datastore is to store Templates & ISO files. This needs to be visible to all hosts so we can deploy a new vm to any compute cluster as required.
Datastore-DRS-Migration	This datastore will be visible to ALL hosts in ALL compute clusters. The purpose of this datastore is to facilitate storage DRS of a virtual machine from one compute cluster to another. At the moment all hosts can see all datastores and it's easy to just vmotion a vm from one cluster to another. After the storage migration if datastores are not shared by all hosts then this standalone datastore will be the bridge between separate clusters.
Datastore-SRM-Placeholder	This datastore is required by SRM to store small (1kB) VM placeholder files. Any host that will be used for protecting or recovering VMs needs access to the placeholder datastore. This will be seen by ALL hosts.

My only thought now is the design of the datastores for virtual machines that will be replicated for SRM. I was debating either (1) a datastore seen by all hosts or (2) separate datastores in each cluster for replicated vm's.

Cheers

[JPM300]

Yup, looks good to me.  Looks like you got everything you will need lined up.