What are the current best practices for file server VM with large volumes

[Geokes]

I need to create a VM to host a 2TB volume filled with pdf and office documents.

The hosts are ESXi 4.1 with Eqallogic multipthing 4x 1GB NIC connected to the iSCI network, jumbo frames

2x X5570, 32GB RAM

LAN connection 10GB CX4

The storage is iSCSi 2x PS6000 forming a single pool (4x 1Gbps NIC on each)

The choices I have to make:

OS: Windows Ent. 2003R2x64 or 2008R2

RAM: 4Gb or more?

Number of CPUs: 1 or more

Volume type RDM or VMDK

[vmroyale]

Hello and welcome to the forums.

I need to create a VM to host a 2TB volume filled with pdf and office documents.

2TB - 512 bytes is the maximum size for a LUN presented to ESXi - this is for VMFS or a RDM.

OS: Windows Ent. 2003R2x64 or 2008R2

My personal preference would be 2008 R2.

RAM: 4Gb or more?

I would start with 1 GB on a file server, unless you have benchmark or baseline data that suggests you really need more than this.

Number of CPUs: 1 or more

I would start with 1 and monitor it.

Volume type RDM or VMDK

Either approach will work. Your backup strategy could come into play, depending on if you are going to leverage the EQ for back ups or not. If you need to grow beyond the 2 TB - 512 bytes limit soon, you could present the iSCSI volumes directly to the Windows Server via the Microsoft iSCSI initiator. This will get you around the current limit, but may impact your backup strategies as well. The backup strategy will sway the final decision, so how are you going to be backing this up?

Good Luck!

[Geokes]

Thanks for the quick reply!

I'm at the point where I have to decide on the backup strategy as well (without knowing all the implication)

The SAN storage array will replicate the data to the DR site.

The local backup media is fast disk (a couple of Dell servers with MD1000s attached)

Currently connected to the 10GB LAN. I can also connect them to the SAN network if there is a benefit.

Besides file level data, there are also smaller VMs with complex software configurations and some physical servers (which need image level backup). Exchange and MS SQL will come into the picture eventually.

I was looking into the performance monitoring aspect of ESX and that gets complicated fast too! Would you have some links for a good starting point?

[vmroyale]

I was looking into the performance monitoring aspect of ESX and that gets complicated fast too! Would you have some links for a good starting point?

The "[Performance Troubleshooting for VMware vSphere 4 and ESX 4.0|http://communities.vmware.com/docs/DOC-10352]" document is an excellent starting point.

[Cyberfed27]

I recently setup a file server with a 1.5TB volume. So I will share my thoughts on your questions..

OS: Windows Ent. 2003R2x64 or 2008R2 --->Server 2008 offers a more managable interface for file shares/permissions, etc... so if you see yourself using a lot of groups and security permissions server 2008 may be a better choice. Security is enhanced on 2008 plus you might as well 'keep up with the times' and run 2008.

We chose 2008 R2

RAM: 4Gb or more? -

---

> 4GB for a 2008 R2 box should be more than enough. 2008 is a little bit more of a hog than 2003 for RAM.

We went with 4GB and after reviewing it for awhile the system doesn't even need that much.

Number of CPUs: 1 or more -

---

> 1 vCPU should be fine for now unless this thing is pounded HARD

We are running 1 vCPU and have had no issues

Volume type RDM or VMDK

We went with a 1.5 TB RDM, but that's because the 1.5TB volume was migrated from a physical server to a VM. The volume lives on a fibre SAN. So we just brought it in as a RDM.

Also if down the line we decide to do a clustered file share the RDM will be needed vs a VMDK.

Hope that helps!

[Geokes]

Thanks for all the answers, I guess there is no single correct one in this case.

I'll try RDM and will monitor the VM performance.

Still interested to hear how people use all the cools toys VMware has to offer.

[AlexTheBoss]

I make it a point to NEVER create partitions larger than 250GB (other than VMFS volumes to store virtual disks) for many reasons. The two that come to mind are A) If a filesystem check is ever forced of a partition, a smaller partition completes quicker resulting in less down time; and B) If I ever have to do a full volume restore, my backup software cannot do a block level restore to a mounted volume, so smaller volumes mean that I can get some of the data back online while others are restoring.

I know that for convenience sake it is easy to just put everything into one volume and some people think they have to do that. But many times if you put a little thought into organizing your data you'll find that isn't always necessary.

Of course, I don't know you're environment so that may not be possible. But it's at least something to consider.

[Kahonu84]

I was kinda thinking along the same line. You have a good chance now to remedy any design flaws that may have existed in the past.