VMWare (VSphere4.1) DataStore/Storage looking for suggestions/guideline

[vmquestions0]

Hi,

We are going to be virtualizing some of our physical server. I have compiled the following information in order for us to be able to establish a solid storage layout. 

I would appreciate any of the experts could review the list and provide the ones that we are missing, review the ones that don't make sense AND add anything that is not in the list and we have to consider.

vShpere 4.1 – DataStore/Storage

1.) VSphere4 Storage Size Limitations

Max size for VMFS datastore -> 64 TB
Max size for the a single file within the datastore -> 2 TB

Max LUN size is 2TB, Datastore and VMFS file system can be 64TB by using 32 2TB Extents. Each Extent is a seperate LUN.

2.) The DataStore has to be formatted with block size different than the default one in order to be able to have big files within the datastore.

3.) If we ever go over the 64 TB limit we can create another VMDS DataStore and merge them both since in VSP4 we can grow the datastore by getting another LUN (LUN extent - managed at the SAN level) that will be detected by vShpere4 allowing us to resize the datastore.

4.) Storage/Datastore best practices

-Each VMFS store should never be filled beyond 15-20% of its total capacity.

-Each VMFS store should also have as much free space as you have RAM allocated to each guest OS (memory SWAP). This is on top of the 15-20% of total capacity.

-Allow extra space for the snapshots in case that your backup application uses them. Veeam uses Snapshots so we have to allow space for the snap shoots to take place once Veeam is done with the backup the snapshoots will be removed. 

-Datastores on VShpere 4.1 can not be larger than 64TB

-We have to consider the IO from each machine. The hosts with greater IO to the SAN consider to create a separate disk group with LUNs for them.

-Keep smaller datastore (500GB or more) for smaller VMs and separate datastores for larger VMs for example SQL, Exchange, File Servers, etc...

-For datastore try to keep the same OS to take advantage of transparent page file sharing which will optimize memory by 10-20%.

Finally I have the following questions...

Some of the servers that are going to be virtualized (file servers, exchange, etc...) have their storage (DATA partition 😧 drive) already in the SAN.

A.) Our concern right now is how do we manage this situation, do we keep the DATA in the same place or do we virtualize the storage and create VMDK files and place them within the same VMFS datastore were we will be placing the OS drive? In other words what are the benefits and drawbacks of virtualizing the data storage VS leaving the data on its own LUN and present that to the ESX server and map it to the VM?

B.) The other query I have is:

We will be using Veeam v.5 in order to backup the VMs so it is my understanding that if we want to use the new feature for application backups (Exchange, SQL, etc...) we will have to have the server fully virtualized OS/DATA in order for the product to work? 

Regarless of the answer to the question above. Does it make sense to use Veeam to backup the C: (OS) and 😧 (DATA) with Veeam? Or does it makes more sense to use Veeam to backup C: (OS) and use our regular network backup solution to backup the 😧 partition o a raw format? What are the benefits and drawbacks?

Thank you again everyone for your input.

[AureusStone]

Hey here are some answers.

1) 2TB is the limit.  It is not considered a good practice to use extents.  If one LUN fails they all do.  32 extents would be insane.  If you need large LUNs you should go with RDMs.

2) When you format the LUNs choose a blocksize so that a single VMDK file can take up the entire LUNs.  Performance is about the same on any of the block sizes.

3) I hope not.

4) How much you fill your datastore depends on your org.  If you use thin provisioning then you have to be more careful.  Also note that if you have started the VM the swap will have already been placed on the LUN.

When considering the size for the LUNs you need to take in to account locks and IO.

If you can run VAAI then that is a good idea. Then you only have to take in to account IO.  Without using VAAI the average LUN size I see is between 500-800GB.

http://www.yellow-bricks.com/2010/11/23/vstorage-apis-for-array-integration-aka-vaai/

For your P2Vs if the LUNs are small you should P2V them and decomm the old LUNs.  If the LUNs are very large then maybe you should convert the C: and then present the data drive as a RDM.  Very large drives can be problematic to P2V.

[vmquestions0]

Hi,

Thanks you very much for your input, this is great feedback! I really appreciate it because I am pretty much alone on this one.

I am not quite understanding the following statement. Can you please clarify? 

When considering the size for the LUNs you need to take in to account locks and IO.

I have been ask by management to provide a list of the benefits and drawbacks of virtualizing the data storage VS leaving the data on its own LUN present it to the ESX server and map it to the VM? So in other words VMFS DataStores VS Raw LUNs for data volumes not OS drives.

Do you have any suggestions or guideline about this?

Thank you!

[vmquestions0]

Here is our situation some of our physical servers are are connected to the SAN already so their storage is already placed on a LUN, etc.

Most of these server are application mission critical servers they run Apps on top a MS Windows server and they are crucial for the business of the company.

For this type of servers it may be more efficient to P2V the server (OS drive) and then use VMDKs (pointers)  acting as the link to the physical RAW LUN.

That being said for the physical servers that have their DATA volumes as local storage we were thinking on virtualizing the OS and DATA and create VMDK files.

The ones that I am concerned about it are for the time being the File Servers.

The file servers DATA volumes are:

FileServer1 - 273GB total size with 189GB of used space.

Fileserver2 has to different DATA drives:

DATA1 -> 280GB total size and about 97.5 GB is being used.
DATA2 -> 800GB total size and 370 GB is being used.

So my question is do we virtualize the storage and make VMDK's or we move the data into the SAN and map the LUNs to the VMs as RAW LUNs?

I would like to create a list of the benefits and drawbacks of virtualizing the data storage VS leaving the data on its own LUN present it to the ESX server and map it to the VM? So in other words VMFS DataStores VS Raw LUNs for data volumes not OS drives.

Do you have any suggestions or guideline about this?

[nkrishnan]

Raw disk gives your virtual machine direct access to SAN.

Procedure to configure:

a Select the LUN that you want to use for the raw disk, and click Next.

b Select to store the LUN mapping files on the same datastore as the virtual machine files, or select a different a datastore, and click Next.

c Select the compatibility mode.

      Physical allows the guest operating system to access the hardware directly.

     Virtual allows the virtual machine to use VMware snapshots and other advanced

Hope it helps

Nithin

[vmquestions0]

I have being doing some research and I have found that for HA and vMotion / DRS to work, the VM has to use shared storage (iSCSI, FC or NFSv3).

This abstains the VMs using RDMs in physical compatibilty mode from using DRS/vMotion or HA since they are not located on shared storage.

In other words, both OS and Data partitions have to be converted to VMDKs for DRS/vMotion and HA to work.

Is my statement correct?

[DSTAVERT]

You can use virtual RDMs and still have access to HA, DRS and vMotion but unless there is some compelling reason to use RDMs I would add LUNs from your SAN as ESX(i) shared datastores and convert your existing physical machines to VMDKs on that storage.

[vmquestions0]

If possible can you please point me out to the article or vmware KB that confirms the compatbility that you have mentioned.

Thank you again for you help.

[DSTAVERT]

http://www.vmware.com/pdf/vsphere4/r40/vsp_40_availability.pdf